Looks good to me. Thanks, Paul -----Original Message----- From: Kyzer Davis (kydavis) <kydavis@xxxxxxxxx> Sent: Tuesday, August 29, 2023 12:17 PM To: Paul Leach <pauljleach@xxxxxxx>; Geoff Huston <gih@xxxxxxxxx> Cc: uuidrev@xxxxxxxx; dnsdir@xxxxxxxx; draft-ietf-uuidrev-rfc4122bis.all@xxxxxxxx; last-call@xxxxxxxx Subject: RE: [dnsdir] [Last-Call] Dnsdir telechat review of draft-ietf-uuidrev-rfc4122bis-10 Geoff, Paul, Michael, I have made the changes as per this discussion thread and the PR is open for review. https://github.com/ietf-wg-uuidrev/rfc4122bis/pull/138/files Let me know if there are any further changes to be made by commenting in this thread or adding a comment to the PR. I plan to submit this Friday so the draft can stay on track for the 9/7 telechat. Thanks! -----Original Message----- From: Paul Leach <pauljleach@xxxxxxx> Sent: Monday, August 28, 2023 8:25 PM To: Geoff Huston <gih@xxxxxxxxx> Cc: Kyzer Davis (kydavis) <kydavis@xxxxxxxxx>; uuidrev@xxxxxxxx; dnsdir@xxxxxxxx; draft-ietf-uuidrev-rfc4122bis.all@xxxxxxxx; last-call@xxxxxxxx Subject: RE: [dnsdir] [Last-Call] Dnsdir telechat review of draft-ietf-uuidrev-rfc4122bis-10 Geoff -- I also prefer the latter, because it gives guidance for implementing new namespaces. Best, Paul -----Original Message----- From: Geoff Huston <gih@xxxxxxxxx> Sent: Monday, August 28, 2023 12:53 PM To: Paul Leach <pauljleach@xxxxxxx> Cc: Kyzer Davis (kydavis) <kydavis@xxxxxxxxx>; uuidrev@xxxxxxxx; dnsdir@xxxxxxxx; draft-ietf-uuidrev-rfc4122bis.all@xxxxxxxx; last-call@xxxxxxxx Subject: Re: [dnsdir] [Last-Call] Dnsdir telechat review of draft-ietf-uuidrev-rfc4122bis-10 Hi Paul, I found the use of the term "canonical" without an explicit definition of its interpretation in the context of this specification to be unclear to me, and I was wondering what was meant. Ether the document can avoid using this this term as proposed by Kyzder, or include an explanation of the term along the lines of your text below, namely "A canonical sequence of octets is one that conforms to the specification for that name form's canonical representation. A name can have many usual forms, only one of which can be canonical. Implementers of _new_ name spaces for UUIDs need to use the specification for the canonical form of names in that space, or define such a canonical for the name space if it does not exoist" I prefer the latter personally, but I can live with either! kind regards, Geoff > On 28 Aug 2023, at 12:35 pm, Paul Leach via dnsdir <dnsdir@xxxxxxxx> wrote: > > I'm the author of those words in 4122, and I meant "canonical" in the ordinary English sense. Some sample definitions: > > Wikipedia: > The adjective canonical is applied in many contexts to mean 'according to the canon' - the standard, rule or primary source that is accepted as authoritative for the body of knowledge or literature in that context. > > Dictionary.com: > relating to, established by, or conforming to a canon or canons > > AED (fourth sense): > Conforming to orthodox or recognized rules > > Or, as it said in section 4.3 of RFC 4122 "as defined by the standards or conventions of its name space". > > So, to answer Geoff's question: a canonical sequence of octets is one that conforms to the specification for that name form's canonical representation. A name can have many usual forms, only one of which can be canonical, so it isn't just a fancy way of saying to use the "usual representation format". > > No amount of increasing the specificity for the UUID versions defined in UUID-REV will replace the need to tell implementers of _new_ name spaces that they need to use the specification for the canonical form of names in that space. (Or to define one for the name space if it doesn't exist.) For example, a new text string based namespace would have to specify the character encoding (e.g., ASCII, EBCDIC, UNICODE), what to do about cases, etc. > > Paul > > > -----Original Message----- > From: Uuidrev <uuidrev-bounces@xxxxxxxx> On Behalf Of Geoff Huston > Sent: Monday, August 28, 2023 11:02 AM > To: Kyzer Davis (kydavis) <kydavis@xxxxxxxxx> > Cc: uuidrev@xxxxxxxx; dnsdir@xxxxxxxx; > draft-ietf-uuidrev-rfc4122bis.all@xxxxxxxx; last-call@xxxxxxxx > Subject: Re: [Uuidrev] [Last-Call] Dnsdir telechat review of > draft-ietf-uuidrev-rfc4122bis-10 > > > >> On 28 Aug 2023, at 8:56 am, Kyzer Davis (kydavis) <kydavis@xxxxxxxxx> wrote: >> >> I agree with the previous email's points. >> >> Personally, I have never been a fan of "canonical" verbiage in the original document, so I suggest we remove it from the text. >> From what I can see "canonical" usage is just a fancy way of saying "Select a Name value formatted as per the underlying specs usual representation format". Sources: [1][2][3]. >> >> For example in UUIDv3, with "canonical" removed, the text would say: >>> UUIDv3 values are created by computing an MD5 [RFC1321] hash over a given name space value concatenated with the desired name value after both have been converted to a sequence of octets in network byte order. >> >> Then I can add a line above the Appendix callout for Namespaces with guidance on how to select said name value and representation from an underlying spec when there are many to choose from. > > I agree with this proposal > > > >> >>> Information around selecting a desired name value's representation/conveyance format within a given name space can be found in section 6.5, "A note on names". >>> Some common namespace values have been defined via Appendix A. >> >> Then repeat this for UUIDv5 and remove "canonical" from the v8 callout in 6.5. > > > Again, I agree with this. > > >> >> Finally, update the line about names and namespaces being equal to state to include a line about the representation format. >>> The UUIDs generated at different times from the same name (using the same name representation/conveyance format) in the same namespace MUST be equal. > > > again, this looks suitable for me > > > kind regards, > > Geoff > >> >> Off topic: I have opened an item #137 on the tracker to convert all "name space" to "namespace" since it is bugging me that the original document had both defined when the one with no space seems to be the better option. >> >> Define "canonical": >> [1] >> https://www/. >> g%2F&data=05%7C01%7C%7C1cca11e012164c3a72bb08dba8006c08%7C84df9e7fe9f >> 640afb435aaaaaaaaaaaa%7C1%7C0%7C638288491994497116%7CUnknown%7CTWFpbG >> Zsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0 >> %3D%7C3000%7C%7C%7C&sdata=hF71vSX2nCJ8pyDwu2tuy3sjs8DhDO0Vy13LW7avvT4 >> %3D&reserved=0 >> nu.org%2Fsoftware%2Flibc%2Fmanual%2Fhtml_node%2FByte-Order.html&data= >> 0 >> 5%7C01%7C%7C14f189a754284205632608dba7f110a0%7C84df9e7fe9f640afb435aa >> a >> aaaaaaaaa%7C1%7C0%7C638288426034758998%7CUnknown%7CTWFpbGZsb3d8eyJWIj >> o >> iMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C >> % >> 7C%7C&sdata=mIQmEa6HtWsw6sK0kGRbw8X6uB0LL30ewLnuqMQlsb8%3D&reserved=0 >> [2] >> https://en.w/ >> i%2F&data=05%7C01%7C%7C1cca11e012164c3a72bb08dba8006c08%7C84df9e7fe9f >> 640afb435aaaaaaaaaaaa%7C1%7C0%7C638288491994497116%7CUnknown%7CTWFpbG >> Zsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0 >> %3D%7C3000%7C%7C%7C&sdata=x6lFVqqG%2F75SpzFoVyVywzBYXwounqF6Sgz2s2N4z >> tc%3D&reserved=0 >> kipedia.org%2Fwiki%2FCanonicalization&data=05%7C01%7C%7C14f189a754284 >> 2 >> 05632608dba7f110a0%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C63828 >> 8 >> 426034758998%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2lu >> M >> zIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=xDqLukaRp5gdC >> S >> FzKzjue1H3kjzTRF%2FSabbV%2F6iS9z8%3D&reserved=0 >> [3] >> https://en.w/ >> i%2F&data=05%7C01%7C%7C1cca11e012164c3a72bb08dba8006c08%7C84df9e7fe9f >> 640afb435aaaaaaaaaaaa%7C1%7C0%7C638288491994497116%7CUnknown%7CTWFpbG >> Zsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0 >> %3D%7C3000%7C%7C%7C&sdata=x6lFVqqG%2F75SpzFoVyVywzBYXwounqF6Sgz2s2N4z >> tc%3D&reserved=0 >> kipedia.org%2Fwiki%2FCanonical_form&data=05%7C01%7C%7C14f189a75428420 >> 5 >> 632608dba7f110a0%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C6382884 >> 2 >> 6034758998%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMz >> I >> iLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=sm4JocW5hoZWh5X >> G >> Ab1%2FakeVGDEgichc6P5v0tnmkLY%3D&reserved=0 >> >> -----Original Message----- >> From: Geoff Huston <gih@xxxxxxxxx> >> Sent: Monday, August 28, 2023 11:17 AM >> To: Kyzer Davis (kydavis) <kydavis@xxxxxxxxx> >> Cc: uuidrev@xxxxxxxx; dnsdir@xxxxxxxx; >> draft-ietf-uuidrev-rfc4122bis.all@xxxxxxxx; last-call@xxxxxxxx >> Subject: Re: [Last-Call] Dnsdir telechat review of >> draft-ietf-uuidrev-rfc4122bis-10 >> >> Hi Kyzer, >> >> Thank for your clarification here. >> >> It looks like you have taken the text in section 4.3 of RFC4122 >> >> "Convert the name to a canonical sequence of octets (as defined by the standards or conventions of its name space); put the name space ID in network byte order." >> >> and rephrased it in this draft. >> >> My question remains - what is a "canonical" sequence of octets? Or even its opposite - what is a sequence of octets that is NOT "canonical"? >> >> In a standards document it seems reasonable to ask for extremely clear specifications, and I just don't understand what you are getting at with the use of the term "canonical" here. >> >> regards, >> >> Geoff >> >> >> >> >> >>> On 28 Aug 2023, at 6:39 am, Kyzer Davis (kydavis) <kydavis@xxxxxxxxx> wrote: >>> >>> Geoff and Michael, >>> >>> The entire sub-section in 6.5 titled "a note on names" was added in draft-08 to explicitly provide context around name usage, selection and provide a few examples from each of the called out dependencies. >>> >>> I can add a reference so the earlier sections that state "canonical sequence of octets in network byte order" have a link to 6.5's sub-section letting folks know where to go to understand what that means? >>> >>> Also, to note, I did not pick "canonical sequence of octets in network byte order" this is from the original specs; I am open to a different verbiage to describe this. >>> >>> Thanks, >>> >>> -----Original Message----- >>> From: Michael Richardson <mcr+ietf@xxxxxxxxxxxx> >>> Sent: Saturday, August 26, 2023 2:59 PM >>> To: Geoff Huston <gih@xxxxxxxxx>; dnsdir@xxxxxxxx; >>> draft-ietf-uuidrev-rfc4122bis.all@xxxxxxxx; last-call@xxxxxxxx; >>> uuidrev@xxxxxxxx >>> Subject: Re: [Last-Call] Dnsdir telechat review of >>> draft-ietf-uuidrev-rfc4122bis-10 >>> >>> >>> Geoff Huston via Datatracker <noreply@xxxxxxxx> wrote: >>>> "Section 5.3, 5.5 and 6.5 refer to "a canonical sequence of octets >>>> in network byte order". It is not specified what that canonical >>>> sequence is nor is there a reference to a document that specifies >>>> the canonical sequence for any of the name spaces." >>> >>> I think that we generally expect people to use a string, literally, "example.com" >>> and I think that the words "network byte order" might be what confuses. >>> >>> Maybe some people would use RFC1035 sequence of labels format though. >>> >>> In the end, it doesn't matter as along as the entity creating the name-based UUID says what they did. Still, I agree that it would be good if we gave more advice here. >>> >>> Are there some references you would suggest here, assuming that we just want a string. >>> >>> >>> -- >>> Michael Richardson <mcr+IETF@xxxxxxxxxxxx> . o O ( IPv6 IøT consulting ) >>> Sandelman Software Works Inc, Ottawa and Worldwide >>> >>> >>> >>> >> > > -- > Uuidrev mailing list > Uuidrev@xxxxxxxx > https://www.i/ > etf.org%2Fmailman%2Flistinfo%2Fuuidrev&data=05%7C01%7C%7C1cca11e012164 > c3a72bb08dba8006c08%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C63828 > 8491994497116%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2lu > MzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=x5d9UAOlIU1ex > UduHM0EMYmxgF4iDKFkatXoI3QiNkk%3D&reserved=0 > > -- > dnsdir mailing list > dnsdir@xxxxxxxx > https://www.i/ > etf.org%2Fmailman%2Flistinfo%2Fdnsdir&data=05%7C01%7C%7C1cca11e012164c > 3a72bb08dba8006c08%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C638288 > 491994497116%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luM > zIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=FLiLn2B1I0bwyA > 1devvYfqQQ85vlW4n7IktdIOpnlP4%3D&reserved=0 -- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
