Re: [regext] OK, What Next? (was RDAP Extensions Approach Analysis v2)

["Hollenbeck, Scott" <[e-mail]>]

I can only disagree. That wasn't the original intent, and the inconsistency is clearly causing confusion.

Scott

> -----Original Message-----
> From: Gould, James <jgould=[e-mail]>
> Sent: Monday, June 27, 2022 9:57 AM
> To: Hollenbeck, Scott <[e-mail]>; [e-mail];
> [e-mail]
> 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
> [e-mail] <applewebdata://13890C55-AAE8-4BF3-A6CE-
> B4BA42740803/[e-mail]>
>
> 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-
> [e-mail] on behalf of shollenbeck=[e-mail]>
> 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 <[e-mail]> On Behalf Of Mario Loffredo
>     > Sent: Thursday, June 16, 2022 2:57 AM
>     > To: [e-mail]
>     > 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
>     > > [e-mail]
>     > > 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: [phone]
>     > 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
>     > [e-mail]
>     > 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
>     [e-mail]
>     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