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

[Sarah Tarrant <[e-mail]>]

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.

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.

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.


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).


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?


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


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
>> 
>> 
>> 
>> 
>