I can only disagree. That wasn't the original intent, and the inconsistency is clearly causing confusion.
Scott > -----Original Message----- > From: Gould, James <[email protected]> > Sent: Monday, June 27, 2022 9:57 AM > To: Hollenbeck, Scott <[email protected]>; [email protected]; > [email protected] > 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 > [email protected] <applewebdata://13890C55-AAE8-4BF3-A6CE- > B4BA42740803/[email protected]> > > 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- > [email protected] on behalf of [email protected]> > 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 <[email protected]> On Behalf Of Mario Loffredo > > Sent: Thursday, June 16, 2022 2:57 AM > > To: [email protected] > > 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 > > > [email protected] > > > 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 > > [email protected] > > 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 > [email protected] > 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 _______________________________________________ regext mailing list [email protected] https://www.ietf.org/mailman/listinfo/regext
