Re: [auth48] [AD]* AUTH48: RFC-to-be 9562 <draft-ietf-uuidrev-rfc4122bis-14> for your review

["Kyzer Davis (kydavis)" <[e-mail]>]

Sorry to go backwards in the email thread.

Comments inline with my initials.

New changes after review of: https://www.rfc-editor.org/authors/rfc9562-auth48diff.html

### Remove duplicate "bit"
OLD:    Fixed Bit-Length Dedicated Counter Bits (Method 1):
New:    Fixed Bit-Length Dedicated Counter (Method 1):

OLD: the fixed bit-length dedicated counter bits that are incremented for every UUID generation.
NEW: a fixed bit-length dedicated counter that is incremented for every UUID generation.

### Extra Period
OLD: UUIDs defined in this document..
NEW: UUIDs defined in this document.

Lastly, I did not see my previous note added or addressed... so re-copying it so it does not get missed.

### Requested change, Add IANA Link
I think the RFC be published with the IANA registry link that was created for section 7.
I don't think it was available at the time of the final draft we are reviewing.
Suggested text changes below. 

OLD: Finally, IANA should track UUID Subtypes and Special Case "Namespace IDs Values" as specified in Sections 7.1 and 7.2.
New: Finally, IANA will track UUID Subtypes and Special Case "Namespace IDs Values" as specified in Sections 7.1 and 7.2 at the following location: https://www.iana.org/assignments/uuid/uuid.xhtml

Thanks,

-----Original Message-----
From: Sarah Tarrant <[e-mail]> 
Sent: Thursday, April 18, 2024 5:49 PM
To: Kyzer Davis (kydavis) <[e-mail]>; Michael Richardson <[e-mail]>; Brad Peabody <[e-mail]>; [e-mail]
Cc: RFC Editor <[e-mail]>; [e-mail]; [e-mail]; [e-mail]; [e-mail]
Subject: [AD]* AUTH48: RFC-to-be 9562 <draft-ietf-uuidrev-rfc4122bis-14> for your review

Hello Kyzer, Michael, Brad, and *Murray,

*Murray - Please review the addition of erratum IDs to the following sentence:

   Further, [RFC4122] itself was in need of an overhaul to address a number of 
   topics such as, but not limited to, the following:
    1. Implementation of miscellaneous errata reports. Mostly around 
        bit-layout clarifications, which lead to inconsistent implementations 
        [Err1957], [Err3546], [Err4975], [Err4976], [Err5560], etc.

KD: Looks good.

Also, please review the addition of the following reference to the following text:

Reference:
   [IEEE802.11bh]
              IEEE, "IEEE Draft Standard for Information technology--
              Telecommunications and information exchange between
              systems Local and metropolitan area networks--Specific
              requirements - Part 11: Wireless LAN Medium Access Control
              (MAC) and Physical Layer (PHY) Specifications Amendment:
              Enhancements for Extremely High Throughput (EHT)",
              Electronic ISBN 978-1-5044-9520-2, March 2023,
              <https://standards.ieee.org/ieee/802.11bh/10525/>.

Current text:
   Implementations MAY leverage MAC address randomization techniques
   [IEEE802.11bh] as an alternative to the pseudorandom logic provided
   in this section.

KD: Looks good to me.

Kyzer, Michael, and Brad - Thank you for your replies. We have updated the document accordingly.

We have a few followup questions/comments.

A) FYI - Regarding:

>> 2) <!--[rfced] We have the following questions/comments about this text
>>    in the Abstract and Introduction:
.....
> KD: I think we should revise like so:
> Old Text:
> This specification defines a Uniform Resource Name namespace for Universally Unique IDentifiers (UUIDs) (also known as Globally Unique IDentifiers (GUIDs)).
> 
> New Text:
> This specification defines UUIDs (Universally Unique IDentifiers) (also known as Globally Unique IDentifiers (GUIDs)) and a Uniform Resource Name namespace for Universally Unique IDentifiers (UUIDs).

To avoid defining/expanding the term "Universally Unique IDentifiers (UUIDs)" twice, we updated to the following. Please let us know if there is any objection:

Current:
   This specification defines UUIDs (Universally Unique IDentifiers) 
   (also known as Globally Unique IDentifiers (GUIDs)) and a Uniform 
   Resource Name namespace for UUIDs.

KD: I like it. Good with me.

B) Regarding:
> 
> 
> 20) <!-- [rfced] RFC 1738 has been obsoleted by RFC 4248.  We have updated
>    to cite the latter.  Please let us know any objections.
> 
> Original:
>  [RFC1738]  Berners-Lee, T., Masinter, L., and M. McCahill, "Uniform
>             Resource Locators (URL)", RFC 1738, DOI 10.17487/RFC1738,
>             December 1994, <https://www.rfc-editor.org/info/rfc1738>.
> 
> Current:
>  [RFC4248]  Hoffman, P., "The telnet URI Scheme", RFC 4248, DOI 
>             10.17487/RFC4248, October 2005, 
>      <https://www.rfc-editor.org/info/rfc4248>.
> -->
> KD: 
> RFC4248 does not replace RFC1738 in the context of this doc.
> RFC3986 is better if we must swap one for the other.
> Though for context I believe RFC1738 is still the best reference.

We have reverted back to referencing RFC 1738. Would you like us to update the first instance to "[RFC1738] (obsoleted by [RFC4248])"?

Original:
   For [RFC1738] uniform
      resource locators (URLs), one could provide a fully-qualified
      domain-name (FQDN) with or without the protocol identifier
      (www.example.com) or (https://www.example.com).

Perhaps:
   For Uniform Resource Locators (URLs) [RFC1738] (obsoleted 
      by [RFC4248]), one could provide a fully-qualified
      domain-name (FQDN) with or without the protocol identifier
      (www.example.com) or (https://www.example.com).

KD: I do not want to reference RFC4248 at all.
That is a larger discussion but I will try to keep it short
The gist is that somebody somewhere incorrectly marked RFC4248 as obsoleting RFC1738 when in reality what RFC4248 does is "help" facilitate the obsoletion of RFC1738.
The same thing rfc4266, rfc2368, rfc6270, rfc8089 all do.
What looks like happened is that rfc1738 was splintered into many smaller, more focused documents at one point.
RFC4248 is one part of what was in RFC1738. The part splintered out into RFC4248 (telnet URIs) is not relevant to this doc. 

If anything, I prefer the text "[RFC1738] (updated by [RFC3986])" because RFC3986 contains the splintered out parts that are important to this document.

C) Regarding:
> 
> 
> 31) <!-- [rfced] Terminology: Please review the following terminology
>    questions/comments and let us know how you'd like to proceed.
> 
> f) Please let us know if the slashes in the following terms can be updated to "and", "or", or "and/or" for clarity.
> 
>  application/language
>  format/components
>  formatting/encoding
>  sub-typing/versioning mechanisms
>  unicast/multicast
> 
> KD:
> AND/OR
>  application/language
> 
> AND
>  format/components
>  formatting/encoding
> 
> OR
>  sub-typing/versioning mechanisms
>  unicast/multicast
> -->

How would you like us to proceed with this question?

KD: The groupings I specified are how each should be changed. 
e.g 
"application/language change" to "application and/or language"
"format/components" change to "format and components"
Etc.

D) Regarding:
> 32) <!-- [rfced] Sourcecode / Artwork
> 
> b) In addition, please review each artwork element. Specifically, should any artwork element be tagged as sourcecode or another element?
> -->
> 
> KD:
> A: That is fine
> B: for the "<artwork>" tags I guess we can tag Figure 16 through 30 as "pseudocode" as well. The others do not need a tag. 

This type does not exist for the artwork element. We can update to sourcecode type="vector". Is that acceptable for Figures 16-30? More information is here: https://authors.ietf.org/en/rfcxml-vocabulary#sourcecode and https://authors.ietf.org/en/rfcxml-vocabulary#type-2

KD: Okay, I was confused. Please leave Figures 16-30 as is.

The updated files have been posted here (please refresh):
https://www.rfc-editor.org/authors/rfc9562.txt
https://www.rfc-editor.org/authors/rfc9562.pdf
https://www.rfc-editor.org/authors/rfc9562.html
https://www.rfc-editor.org/authors/rfc9562.xml

The relevant diff files have been posted here (please refresh):
https://www.rfc-editor.org/authors/rfc9562-diff.html (comprehensive diff) https://www.rfc-editor.org/authors/rfc9562-auth48diff.html (AUTH48 changes only)

Note that it may be necessary for you to refresh your browser to view the most recent version. 

For the AUTH48 status of this document, please see:
 https://www.rfc-editor.org/auth48/rfc9562

Thank you,
RFC Editor/st

> On Apr 17, 2024, at 5:04 PM, Brad Peabody <[e-mail]> wrote:
> 
> I concur with all of Kyzer’s answers, no objection from me.  (One 
> minor typo is probably obvious but will mention “Var/Var” was intended 
> to mean “Ver/Var” on point 26.)
> 
> Best, Brad
> 
> 
>> On Apr 17, 2024, at 7:10 AM, Kyzer Davis (kydavis) <[e-mail]> wrote:
>> 
>> I knew I would miss one. 
>> 
>> For 17:
>> Perhaps A works.
>> 
>> -----Original Message-----
>> From: Michael Richardson <[e-mail]>
>> Sent: Wednesday, April 17, 2024 9:58 AM
>> To: Kyzer Davis (kydavis) <[e-mail]>
>> Cc: [e-mail]; [e-mail]; [e-mail]; 
>> [e-mail]; [e-mail]; [e-mail]; 
>> [e-mail]
>> Subject: Re: AUTH48: RFC-to-be 9562 
>> <draft-ietf-uuidrev-rfc4122bis-14> for your review
>> 
>> 
>> Kyzer Davis (kydavis) <[e-mail]> wrote:
>>> 17) <!--[rfced] In the following text, which meaning is correct?
>> 
>>> Original:
>> 
>>> After generating the 48 bit fully randomized node value, implementations MUST set the least significant bit of the first octet of the node ID set to 1.
>> 
>>> Perhaps A (the least significant bit is set to 1):
>> 
>>> After generating the 48-bit fully randomized node value, implementations MUST set the least significant bit of the first octet of the node ID to 1.
>> 
>>> Perhaps B (the least significant bit is set to some value for the first octet of the node ID that is set to 1):
>> 
>>> After generating the 48-bit fully randomized node value, implementations MUST set the least significant bit of the first octet of the node ID set to 1.
>>   -->
>> 
>> I can't see which choice you have made.
>> 
>> 
>> --
>> Michael Richardson <[e-mail]>   . o O ( IPv6 IøT consulting )
>>          Sandelman Software Works Inc, Ottawa and Worldwide
>> 
>> 
>> 
>> 
>