Scott, The language of the RFCs will support any of the three approaches, where the key aspect that may or may not have been discussed originally in the working group is versioning. The only reference to versioning is the use of RDAP conformance "rdap_level_0" value and there is no mention of the use of versioning in the RDAP elements. The versioning gap is what is driving the discussion now.
Do you have a technical issue with supporting the registration of extension prefix identifiers (e.g., " lunarNIC") that ensures uniqueness of the RDAP elements (path segments, response members, etc.) along with the use of that prefix identifier to provide versioning in the RDAP conformance values (e.g., "lunarNIC_level_0", "lunarNIC_level_1", "lunarNIC_level_N")? A client can use the registered prefixes to easily identify the conformance value, which may include the version number. This is what is defined in Approach B, which is not as flexible as Approach C, but it ensures that there is a linkage between the extension elements and the RDAP conformance value. Support for Approach B does not require any change to 9083. -- 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://verisigninc.com/> On 6/27/22, 10:03 AM, "Hollenbeck, Scott" <shollenbeck=40verisign....@dmarc.ietf.org> wrote: I can only disagree. That wasn't the original intent, and the inconsistency is clearly causing confusion. Scott > -----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 _______________________________________________ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
