-----Original Message-----
From: Gould, James <jgould=40verisign....@dmarc.ietf.org>
Sent: Monday, June 27, 2022 9:57 AM
To: Hollenbeck, Scott <shollenb...@verisign.com>; mario.loffr...@iit.cnr.it;
regext@ietf.org
Subject: [EXTERNAL] Re: Re: [regext] OK, What Next? (was RDAP Extensions
Approach Analysis v2)
Caution: This email originated from outside the organization. Do not click links
or open attachments unless you recognize the sender and know the content
is safe.
Scott,
I don't believe anything needs to be changed in 9083. Where "lunarNIC" is
the registered prefix identifier and the RDAP conformance value
"lunarNIC_level_0" might be used. This supports the use of the registered
prefix identifier and the needed versioning.
--
JG
James Gould
Fellow Engineer
jgo...@verisign.com <applewebdata://13890C55-AAE8-4BF3-A6CE-
B4BA42740803/jgo...@verisign.com>
703-948-3271
12061 Bluemont Way
Reston, VA 20190
Verisign.com <http://secure-
web.cisco.com/17L1JiCMWxihiqijR7XxolXXTLM51s_o4v4LJd8cJwrsx1htY2H80
EGH7i2Ensln_D7oZmX1Lmm3LMkoOx-
Sg1eCTr5jaMylS1ZgAFsT7wVnmCBs_TFiKYSaAvNZzoHuBov1ZjQLD8Mfh9skcr
Tq8dg2XhG4jb3sHN2-
gdEMQh_ozYxTl4jLeuMAB1Yy_OZ78eUtEJW0NWKTJmwv7moKrvdWhOZWP
kXvSKaIJmgMevrgIJioJZJnEr_S0qppCdxmn/http%3A%2F%2Fverisigninc.com
%2F>
On 6/27/22, 9:38 AM, "regext on behalf of Hollenbeck, Scott" <regext-
boun...@ietf.org on behalf of shollenbeck=40verisign....@dmarc.ietf.org>
wrote:
Mario, there's a basic problem with the approach you're suggesting below.
We
can't "correct RFC 9083 to make it consistent with what decided".
The "IESG Processing of RFC Errata for the IETF Stream" statement provides
guidance for what we can and cannot do:
https://secure-
web.cisco.com/1V_oFdQEIWuGT_dN8fQSYXCZzrWnfzH9rGieJ4s_OqWNMGS
7DXUn2eUGXSePIhNcBoUl-
o1RWtngwq8OSMZOnVCTGcmdz4zhbaD1Wf3vF5c6c7yfAd-
TVYYidTUBHczFr3K4l0sZaxH1tS1tQybTK6fUFYaTPxWcRe9-
eW5ySkLoOVOmnjYSnsTbyL9y2O5k3s3t8ub-6INo5aHL5vmd72uQQtEJ4-
k64WTfvwOUHHwdn4zPYWP5q10HqPDgscdWA/https%3A%2F%2Fwww.ietf.
org%2Fabout%2Fgroups%2Fiesg%2Fstatements%2Fprocessing-errata-ietf-
stream%2F
Note these statements:
"Errata are meant to fix "bugs" in the specification and should not be used
to
change what the community meant when it approved the RFC."
"Errata are classified as “technical” or “editorial”."
"Technical errata are expected to be things that would likely cause
significant misunderstandings of the technical specification and might
result
in faulty implementations if they are not corrected."
"Technical items that have a clear resolution in line with the original
intent
should be classified as Verified. If the resolution is not clear or
requires
further discussion, the report should be classified as Hold for Document
Update. In both cases, only items that are clearly wrong should be
considered."
"Changes that modify the working of a protocol to something that might be
different from the intended consensus when the document was approved
should
generally be Rejected. Significant clarifications should not be handled as
errata reports and need to be discussed by the relevant technical
community."
"Changes that modify the working of a process, such as changing an IANA
registration procedure, to something that might be different from the
intended
consensus when the document was approved should be Rejected."
What I'm proposing (report the inconsistency in 9083 and make the
"lunarNIC"
vs. "lunarNIC_level_0" thing consistent) is aligned with the above. The
current text is obviously causing significant misunderstandings of the
technical specification, and my proposed change* matches the intended
consensus when the document was approved. The desire to make more
significant
changes to 9083, to include any changes focused on how to identify and
manage
versioning, really needs to be addressed independently.
Scott
* I'm willing to request that instances of "lunarNIC" be changed to
"lunarNIC_level_0" if that's preferred. Andy and I believe that the
original
intent was for the values to be consistent, and this change would also
align
with use of "rdap_level_0".
> -----Original Message-----
> From: regext <regext-boun...@ietf.org> On Behalf Of Mario Loffredo
> Sent: Thursday, June 16, 2022 2:57 AM
> To: regext@ietf.org
> Subject: [EXTERNAL] Re: [regext] OK, What Next? (was RDAP Extensions
> Approach Analysis v2)
>
> Caution: This email originated from outside the organization. Do not
click
> links
> or open attachments unless you recognize the sender and know the
content
> is safe.
>
> Hi folks,
>
> I invite you to consider that, currently, rdap-reverse-search and,
> potentially,
> three other RDAP-related docs are blocked waiting for the end of this
> discussion.
>
> In addition, it seems to me more logical, first, to decide how RDAP
> exentions
> must be treated and, then, correct RFC 9083 to make it consistent with
what
> decided.
>
> Once agreed on which approach to follow, we could proceed in parallel
with
> the correction of RFC 9083 and the writing of a document defining the
> guidelines for extending RDAP.
>
> For the sake of completeness and comprehension, such a document
might
> include the scenarios Jasdip has described in his analysis.
>
>
> Best,
>
> Mario
>
>
> Il 15/06/2022 19:27, Hollenbeck, Scott ha scritto:
> > Thanks for doing all this work, Jasdip. Now we have to decide what to
do
> with
> > all of this information.
> >
> > As a first step, I think we need to submit errata to address issues
with
> > the
> > existing RFC(s). RFC 9083 uses both "lunarNIC" and "lunarNIC_level_0".
At
> a
> > minimum, Andy and I agree that "lunarNIC_level_0" should be replaced
> with
> > "lunarNIC".
> >
> > Rationale: Section 2.1 of RFC 9083 describes "lunarNIC" as an example
of
> > an
> > identifying prefix and includes examples of this value being used as an
> > extension prefix. Section 4.1 says "For example, if the fictional
Registry
> > of
> > the Moon wants to signify that their JSON responses are conformant
with
> their
> > registered extensions, the string used might be "lunarNIC_level_0". We
> believe
> > that 4.1 and 2.1 are inconsistent and that they can be made consistent
by
> > changing "lunarNIC_level_0" with "lunarNIC" in 4.1.
> >
> > Additional errata may be needed. If so, where, and what else needs to
be
> done?
> >
> > Scott
> > _______________________________________________
> > regext mailing list
> > regext@ietf.org
> > https://secure-web.cisco.com/1sPv-
>
dLzvvqhNDXbiOOjohSnIO97wGQlAwNMpaY3C1_JwFw8ZcW5yQKcqwEMjjI4a
> wA-Jl-e-tV4WSuYkK6ga2H5oLbNJuwp-O9KiMNKynBi1Mkn0Bv_AZ8rq2G-
>
Dajc2YkeBA8viu7YJWWAr4AL74OjYAIXKkLYhP7srUtpD9M94cWjRPcUMlQmtS
> DKU33bc5zTBP1RbMJOXmxIuxOlu8vd4DhsVN9gzqOWeoHdCi-
> uCH9HX3xgUp6w1-
>
zSiYr0K/https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fregext
>
> --
> Dr. Mario Loffredo
> Technological Unit “Digital Innovation”
> Institute of Informatics and Telematics (IIT)
> National Research Council (CNR)
> via G. Moruzzi 1, I-56124 PISA, Italy
> Phone: +39.0503153497
> Web: http://secure-
>
web.cisco.com/1tDmAE3yEIWzsMXoMIliAb7B8sxyrzbH1sGKAJgZa_qRqMiFfP
>
STq4tq2ieXF83omlH12rdACydGrVu4sEPz9UTOExDvMKGC4wsoXQx71DAE-
>
xr3l6jIFv200l9aKQE_149dEbt_ystXWGuWxMjIJXeEIce2zpyuBNc27m43gVjK_c
>
o23TUyEQWCsfQHD8H1lsLQpc3OGoz_05I0AwljSDG3vwc5vV8plppwhhkS2z9C
>
TqYsdnpctlwEXIYGToCuF/http%3A%2F%2Fwww.iit.cnr.it%2Fmario.loffredo
>
> _______________________________________________
> regext mailing list
> regext@ietf.org
> https://secure-web.cisco.com/1sPv-
>
dLzvvqhNDXbiOOjohSnIO97wGQlAwNMpaY3C1_JwFw8ZcW5yQKcqwEMjjI4a
> wA-Jl-e-tV4WSuYkK6ga2H5oLbNJuwp-O9KiMNKynBi1Mkn0Bv_AZ8rq2G-
>
Dajc2YkeBA8viu7YJWWAr4AL74OjYAIXKkLYhP7srUtpD9M94cWjRPcUMlQmtS
> DKU33bc5zTBP1RbMJOXmxIuxOlu8vd4DhsVN9gzqOWeoHdCi-
> uCH9HX3xgUp6w1-
>
zSiYr0K/https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fregext
_______________________________________________
regext mailing list
regext@ietf.org
https://secure-
web.cisco.com/1koVgFwXjNQjGlB5ua2nkhXLFmoQfAZZSy4Ue5jAsDqoUOHP
mudpISewmydg0IU9zTmDML1UyKWPHRngPuXl9tXvprC3IJTW3jb8hNx8SjP6
w3CbU_6myeF-
bp9fID6MF0u0_B5BY9sUyBWXO2jtv5_1XX4gSmyiJtmw_p8ErDyvYLK86eqS3La
0iodAi2MYhsKycTdH3QAXQa4qX0AGWh7oSMDw4GLSXT96X-
9yGQ5NuZFO6qecYM3ZVK32hg7o3/https%3A%2F%2Fwww.ietf.org%2Fmail
man%2Flistinfo%2Fregext
