Scott, The question is how we handle versioning, which is an aspect not covered in the existing RFCs. The only version reference is in the RDAP Conformance definition in section 4.1 of RFC 9083 with "rdap_level_0" and "lunarNIC_level_0". If the use of "lunarNIC_level_0" was a mistake, then versioning is completely absent for extensions. A client can easily do a regular expression match with the RDAP conformance values since the prefixes should be unique. The reference to "The extension identifier is used as a prefix in JSON names and as a prefix of path segments in RDAP URLs" in RFC 7480 simply defines the primary key in the RDAP Extensions Registry and doesn't imply anything about the RDAP Conformance value in RFC 9083.
We've produced 3 approaches to deal with RDAP conformance versioning and the linkage with the RDAP elements. Approach A is a showstopper to me since it cascades versioning to all elements with no perceived value and with the cost of interoperability issues when the version number does change. The interoperability issues will result in the negative side effect of not changing the version number. Consider when a backward compatible enhancement is made, which should change the version number, but will either break existing clients by changing the version number or decide not to change the version number at all to signal support for the new enhancement. We need to ensure that versioning is fully supported and has the least impact to the clients. Approach B is a good compromise that has support, that fully supports versioning, and doesn't require any change to RFC 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, 11:37 AM, "Hollenbeck, Scott" <shollenbeck=40verisign....@dmarc.ietf.org> wrote: I don't think 7480 is unclear, Mario. Section 6 describes the syntax of the identifiers that are to be registered with IANA and used as prefixes. Section 8 then says, "The extension identifier is used as a prefix in JSON names and as a prefix of path segments in RDAP URLs." That's very clear in my mind. There's nothing there that says "you can add OPTIONAL information if you wish". For what it's worth, I've sent some off-list email to our chairs and our AD with a request for guidance here. We're not making progress with these back-and-forth discussions. Scott > -----Original Message----- > From: Mario Loffredo <mario.loffr...@iit.cnr.it> > Sent: Monday, June 27, 2022 11:18 AM > To: Hollenbeck, Scott <shollenb...@verisign.com>; > jgould=40verisign....@dmarc.ietf.org; 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 Scott, > > my opinion is that the confusion results from the ambiguity in what is written > in section 6 of RFC7480. > > Therefore, think first we need to unambiguously define: > > - the relationship between prefixes, IANA registered identifiers, version > numbers and rdapConformance values (substantially it means to select one > among the possible approaches and define everything formally) > > - how version numbers can be identified into the rdapConformance values > (should "_level_" be used as a separator? what should be used as a minor > version seprator?) > > Honestly, I'm not as knowledgeable as you about IETF procedures to set out > how to proceed; if we should correct RFC7480, write an RFC7480bis or write > another document. > > Surely, we need to make some clarifications. > > Then, depending on how RFC7480 will be updated, RFC9083 will be changed > or left as is. > > > Best, > > Mario > > > Il 27/06/2022 16:03, Hollenbeck, Scott ha scritto: > > 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 > > -- > 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/1- > 17dvbqGrX5UXBxH6HBjz1b4TKMBTn9HlySWeq_svs2xMR7gXDhnOqhehsgNu > rbhQJ9fRQv3DwH9z7iBpoICLCVt4V6Kgoubx4URhsd7Of8fziGF6EF80mNyvDN > WT8iQfL-bjnw0CICteA0r6u- > ERBEYaI9VbpsWMRNVeXJVRzLjQL2G3p2T6XRR7EMrK7eAzsvqYtYtc7ydqvY- > 2TLgArhVx_Rn-wIGXCU- > z1Mlb9ynumv0g7NAMEoYSqere4kA/http%3A%2F%2Fwww.iit.cnr.it%2Fmari > o.loffredo _______________________________________________ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
