Jim, I didn't say that "lunarNIC_level_0" isn't supported. What I *am* saying is that both authors of the document agree that the existing text contains an editorial error that should be fixed such that the two sections of 9083 are consistent. We could just as easily change all instances of "lunarNIC" to "lunarNIC_level_0". That is the simplest path forward that doesn't require changing the original intention of the text. With the editorial error corrected we can decide if something else needs to be done to clarify how extensions are identified.
Don't forget that the WG did, in fact, reach consensus on the existing text when we went through the process to publish it as a Standard. "come to consensus on the desired extension registry approach or approaches" implies more significant changes to the existing text that can't be addressed with errata. If that's what the WG wants to do, fine, but we'd better make our mind up about that sooner rather than later. Scott > -----Original Message----- > From: Gould, James <[email protected]> > Sent: Wednesday, June 15, 2022 1:59 PM > 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 believe the first step is to come to consensus on the desired extension > registry approach or approaches. I personally like the use of > "lunarNIC_level_0" in the rdapConformance to ensure that versioning of the > specification is fully supported. Approach B could be used to allow for the > registered prefix "lunarNIC" to support the versioned rdapConformance > value of "lunarNIC_level_0". Approach C decouples the prefixes from the > identifier, so both the prefixes and the versioned identifier would be > registered. Updating "lunarNIC_level_0" to "lunarNIC" in RFC 9083 doesn't > address the versioning issue. > > -- > > 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/1Vo_prxoZlgMn8n- > d5tRNZLs8IMVwvIdRLWAsc8s3x5kUlfPvUAfGG1R9VSZZNwwpUgsNKglJCpiDP > eFwBSZBKI4YSrEii3FEBUQowZ7sug1iltQCyWun0NzZ3J2Pc5cpHefSd6Rsyxb_od > LmFg4jwJvB3kGsuwS_jHfZ3B2gS6K-OggLd3TEZVliRULU1rLr9- > 6T9WbPHS2B3HnX6HNavcu67j9491BURhFuYYYd8bvMlMFUrQ5GURBZwxvue > _-c/http%3A%2F%2Fverisigninc.com%2F> > > On 6/15/22, 1:27 PM, "regext on behalf of Hollenbeck, Scott" <regext- > [email protected] on behalf of [email protected]> > wrote: > > 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/1YfJ- > 5LkVa3_5e2919NGv3HEyQy1AoEJ85v6gRz0tFZA0RXar6_Be- > zQoFAL0wMeZscZWEZJviAtI80kqxbdAVGXbuyEWNIIHNvaf4rRa- > WfawQjzoVSkJsMFmkxcrbEHSLKsRFsj63qrJ8fTXUta2zy5yiiuXzsiQAmJFxKCiJu > dRDLfaCI_02bRNSDyvOwEWBccERhzp9KGqZgjvPpQrbcCOauHRjWfg- > ipxnTEVxEhOAE- > djs02lBSoMdQN6nJ/https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo% > 2Fregext > _______________________________________________ regext mailing list [email protected] https://www.ietf.org/mailman/listinfo/regext
