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

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

Hello all,

Sorry for the delay.

Response comments to the "rfced" questions are in the inline. Marked with initials "KD".
@[e-mail] please give them a once over and let me know if you disagree with anything.

### 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: [e-mail] <[e-mail]> 
Sent: Thursday, April 11, 2024 11:29 PM
To: Kyzer Davis (kydavis) <[e-mail]>; [e-mail]; [e-mail]
Cc: [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

Authors,

While reviewing this document during AUTH48, please resolve (as necessary) the following questions, which are also in the XML file.

1) <!--[rfced] Brad and Kyzer: we have updated the header to use only
     your first initial as this is the most frequently used format for
     author names.  Please let us know any objections.-->

KD: Fine with me.

2) <!--[rfced] We have the following questions/comments about this text
     in the Abstract and Introduction:

Original:
   This specification defines the UUIDs (Universally Unique IDentifiers)
   and the UUID Uniform Resource Name (URN) namespace.  UUIDs are also
   known as GUIDs (Globally Unique IDentifiers). 

a) to reduce redundancy and align with the same text in RFC 4122, we have updated this text as follows.

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

b) Because this is the only mention of "URN namespace" in the document:

Original:
  The IANA URN namespace registration [URNNamespaces] for UUID filed in
  [RFC4122] should be updated to reference this document.

please confirm that this sentence should appear as is.

-->

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

Why:
This is because the document describes UUIDs as a general concept *and* also allocates a URN Namespace for UUID.
The heavy lifting for that second item of "URN Namespace" was accomplished by the previous doc so the text required here is minimal.
Note: The previous document *also* described UUIDs as a general concept. The previous abstract failed to convey this properly. So I wanted to ensure this abstract/intro fixed this by stating that the document covers both topics.

> this is the only mention of "URN namespace"
We detail it in Section 7 where the doc states that previous RFCs URN Namespace remains intact and will be updated to this document. 
We can add another reference earlier in Figure 4's title.
OLD:
Figure 4: Example URN UUID

NEW: 
Figure 4: Example URN Namespace for UUID

3) <!--[rfced] We had a few questions regarding the use of "DCE
     specification" in the document:

a) Will the reader understand what the "DCE specification" refers to in the sentences below?  Or should some sort of citation be added?

KD: Unfortunately, this was not cited in the original RFC either... so I personally do not know what this references to cite it properly. While the original document may be lost to time, but the best citation I can surmise would be [C309], Appendix A.

b) Do "DCE specification" and "OSF DCE specification" refer to the same thing?

Original:
   This specification is derived from the DCE specification with the
   kind permission of the OSF (now known as The Open Group).

Original:
   Information from earlier versions of the DCE specification have been
   incorporated into this document.

Original:
   This document draws heavily on the OSF DCE specification for UUIDs.

KD: Yes, okay to change "DCE" to "OSF DCE"

-->

4) <!-- [rfced] We have cut author names in this list as readers can find
     this information in full using the citation tag.  Please let us
     know any objections.


Original:
   1.   [ULID] by A.  Feerasta
   2.   [LexicalUUID] by Twitter
   3.   [Snowflake] by Twitter
   4.   [Flake] by Boundary
   5.   [ShardingID] by Instagram
   6.   [KSUID] by Segment
   7.   [Elasticflake] by P.  Pearcy
   8.   [FlakeID] by T.  Pawlak
   9.   [Sonyflake] by Sony
   10.  [orderedUuid] by IT.  Cabrera
   11.  [COMBGUID] by R.  Tallent
   12.  [SID] by A.  Chilton
   13.  [pushID] by Google
   14.  [XID] by O.  Poitrey
   15.  [ObjectID] by MongoDB
   16.  [CUID] by E.  Elliott

Current:
   1.   [ULID]
   2.   [LexicalUUID]
   3.   [Snowflake] 
   4.   [Flake] 
   5.   [ShardingID] 
   6.   [KSUID] 
   7.   [Elasticflake]
   8.   [FlakeID]
   9.   [Sonyflake]
   10.  [orderedUuid]
   11.  [COMBGUID]
   12.  [SID]
   13.  [pushID] 
   14.  [XID]
   15.  [ObjectID]
   16.  [CUID]
-->

KD: Okay with me.


5) <!--[rfced] We suggest listing the EIDs that this text is referring to
     for clarity.  Please let us know which errata apply in this sentence.  

Original:

   Further, [RFC4122] itself was in need an overhaul to address a number
   of topics such as but not limited to the following:

   1.  Miscellaneous erratas.  Mostly around bit layout clarifications
       which lead to inconsistent implementations.

Perhaps (with corresponding errata reference entries as described at
https://www.rfc-editor.org/styleguide/part2/#ref_errata):

   Further, [RFC4122] itself was in need an overhaul to address a number
   of topics such as, but not limited to, the following:

   1.  Implementation of miscellaneous errata reports (mostly bit-layout
       clarifications that lead to inconsistent implementations):
       [Err####], [Err###1], etc.


-->

KD: These are the following Errata relevant to that topic.
New: 
[Err1957], [Err3546], [Err4975], [Err4976], [Err5560].


6) <!-- [rfced] Regarding text in the "Abbreviations" section:


a) Would you like the abbreviations in Section 3.2 to be alphabetized?
KD: Yes, fine with me.

b) Regarding UUID and its versions:

i) Is it necessary to list all of the versions with UUID?  This seems common notation in RFCs.

Current:

   UUIDv1        Universally Unique Identifier Version 1

   UUIDv2        Universally Unique Identifier Version 2

   UUIDv3        Universally Unique Identifier Version 3

   UUIDv4        Universally Unique Identifier Version 4

   UUIDv5        Universally Unique Identifier Version 5

   UUIDv6        Universally Unique Identifier Version 6

   UUIDv7        Universally Unique Identifier Version 7

   UUIDv8        Universally Unique Identifier Version 8

ii) Throughout the text, we will update instances of "UUID version #"
to instead read as "UUIDv#" unless we hear objection.

KD:
i: At some point I was asked to explicitly add these mappings. They seem like a given but I see no harm in leaving them.
ii: That is fine with me though I do not want the section titles changed from "UUID version #".

c) We note that the abbreviation for SHA-1 contains a number of bits.
This leads us to a few questions:

i) Is this convoluting the 1:1 relationship between initialism and expansion?  That is, the other SHA abbreviations have a bit size that correlates to their abbreviation.

Perhaps:
SHA-1     Secure Hash Algorithm 1

or

Perhaps:
SHA-1     Secure Hash Algorithm 1 (160 bits)

ii) If a bit size is included for SHA-1, should a bit size be included for SHA-3?

KD: 
i: I am fine with "SHA-1     Secure Hash Algorithm 1 (160 bits)" stylization which can also be conveyed in SHA-2xx and SHA-3 abbreviation text for consistency.
ii: SHA-3 (and SHAKE) do not have a single number for size. They are arbitrary output lengths. So I am not sure how to put that in there but "(Arbitrary size)" is what I would use if I had to make all the SHA-#/SHAKE items consistent.

Notes: The relationship between size and name is only a "SHA-2" concept. This is how they define it in the references, so we follow suit.

d) We had the following questions/comments about the abbreviation MSB (Most Significant Bit):

i) Please note that we have lowercased "Most Significant Byte" to avoid confusion with this abbreviation.

ii) The tables in Sections 4.1 & 4.2 use "Msb#" format.  Should these be made "MSB#"?

iii) To match the guidance at
https://www.rfc-editor.org/styleguide/part2/#exp_abbrev, we generally use an abbreviation (instead of the expansion) once it has been introduced.  However, we often see the expansion of MSB with text interjected.  Should updates like the following be made (just examples, not all cases listed)?

Original:
the most significant 4 bits

the most significant 12 bits

first 48 most significant bits

The most significant 32 bits

Perhaps:
the 4 MSBs

the 12 MSBs

first 48 MSBs

The 32 MSBs

KD:
i: That is fine.
ii: Yes, MSB# works.
iii: The MSB abbreviation was really for the table headers where the text would be too long. Personally, I would like to keep the expanded text (and undo the change in section 5.6. back to "48 most significant bits" rather than "48 MSBs"

-->


7) <!-- [rfced] To avoid personifying the "bit definitions", may we
     update "While discussing UUID formats..." to "In terms of these
     UUID formats..."?

Current:
   The UUID format is 16 octets (128 bits) in size; the variant bits
   in conjunction with the version bits described in the next sections
   determine finer structure.  While discussing UUID formats and
   layout, bit definitions start at 0 and end at 127, while octet
   definitions start at 0 and end at 15.

Perhaps:
   The UUID format is 16 octets (128 bits) in size; the variant bits
   in conjunction with the version bits described in the next sections
   determine finer structure.  In terms of these UUID formats and
   layout, bit definitions start at 0 and end at 127, while octet
   definitions start at 0 and end at 15.
-->

KD: I am fine with the change to "In terms of these UUID formats..."

8) <!--[rfced] Please review the use of "bits...will contain...bits".
     Should this be updated as follows?  Note: similar text occurs
     more than once in the document.

Original:
      12 bits that will contain the least significant 12 bits from the
      60 bit starting timestamp.  Occupies bits 52 through 63 (octets
      6-7).

Perhaps:
      The least significant 12 bits from the
      60 bit starting timestamp.  Occupies bits 52 through 63 (octets
      6-7).

-->

KD: Yes, okay to change.


9) <!--[rfced] This text seems to switch between singular and plural.
     Please review our suggested text and let us know if another
     rephrase is preferred.

Original:
   UUID version 2 is known as DCE Security UUIDs [C309] and [C311].
   As such, the definition of these UUIDs is outside the scope of this
   specification.

Perhaps:
   UUID version 2 is for DCE Security UUIDs (see [C309] and [C311]).
   As such, the definition of these UUIDs is outside the scope of this
   specification.

-->

KD: Yes, okay to change.


10) <!-- [rfced] May we update "number of Unix epoch timestamp" to "number
     of the Unix epoch timestamp" for readability?

Original:
   unix_ts_ms:
      48 bit big-endian unsigned number of Unix epoch timestamp in
      milliseconds as per Section 6.1.  Occupies bits 0 through 47
      (octets 0-5).

Perhaps:
   unix_ts_ms:
      48-bit big-endian unsigned number of the Unix Epoch timestamp in
      milliseconds as per Section 6.1.  Occupies bits 0 through 47
      (octets 0-5).
-->


KD: Yes, okay to change.

11) <!--[rfced] Please review the use of "RFC-compatible" in the following
     text.  Compatibility with the RFC document series in what way?

Original:
   UUID version 8 provides an RFC-compatible format for experimental or
   vendor-specific use cases.

-->

KD: We can remove "RFC-compatible".


12) <!-- [rfced] May we update the second sentence as follows for clarity?
     Please let us know if this alters the intended meaning or if
     there is another way to phrase this sentence.

Original:
      Implementations MAY alter the actual timestamp.  Some examples
      include security considerations around providing a real clock
      value within a UUID, to correct inaccurate clocks, to handle
      leap seconds, or instead of dividing a number of microseconds by
      1000 to obtain a millisecond value; dividing by 1024 (or some
      other value) for performance reasons.

Perhaps:
      Implementations MAY alter the actual timestamp. Some examples
      include security considerations around providing a real-clock
      value within a UUID to 1) correct inaccurate clocks, 2) handle
      leap seconds, or 3) obtain a millisecond value by dividing by
      1024 (or some other value) for performance reasons (instead of
      dividing a number of microseconds by 1000).
-->

KD: Yes, okay to change.

13) <!--[rfced] Would you like us to update to use superscript instead of
     "to the 12th power" in the following?

Original:
If we wish to
          encode this as 12 bits, we can take the count of possible values
          that fit in those bits (4096, or 2 to the 12th power),...


-->

KD: Yes, 2^12 stylized with superscript would be great.


14) <!--[rfced] Would this update to "historical documents" convey the
     correct meaning?

Original:
   Although some prefer to use the word "hash-based" to describe UUIDs
   featuring hashing algorithms (MD5 or SHA-1), this document retains
   the usage of the adjective "name-based" in order to maintain
   consistency with historical documents and existing implementations.

Perhaps:
   Although some prefer to use the word "hash-based" to describe UUIDs
   featuring hashing algorithms (MD5 or SHA-1), this document retains
   the usage of the term "name-based" in order to maintain consistency
   with previously published documents and existing implementations.
-->

KD: Yes, okay to change.

15) <!--[rfced] To what does "the previous version of this specification"
     refer? RFC 4122?

Original:
Looking at [X500] distinguished names (DNs), the previous version of this specification allowed either text based or binary distinguished encoding rules (DER) based names as inputs.

Perhaps:
Looking at [X500] distinguished names (DNs), [RFC4122] allowed either text-based or binary DER-based names as inputs.
-->

KD: Okay to change.

16) <!--[rfced] Should this actually be a citation with a corresponding
     reference entry?  If so, please provide the correct reference
     entry information as well as if it should be listed in the
     Normative or Informative section.

Original:
   Implementations MAY leverage MAC address randomization techniques
   (IEEE 802.11bh) as an alternative to the pseudo-random logic provided
   in this section.

-->

KD: Yes
Informative Reference.
Cite: https://standards.ieee.org/ieee/802.11bh/10525/


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


18) <!--[rfced] Is it necessary to include both of these paragraphs as
     they seem to convey the same information?

Original:
   All references to [RFC4122] in the IANA registries should be replaced
   with references to this document.  References to [RFC4122] document's
   Section 4.1.2 should be updated to refer to this document's
   Section 4.

   The IANA URN namespace registration [URNNamespaces] for UUID filed in
   [RFC4122] should be updated to reference this document.

Perhaps:
   All references to [RFC4122] in IANA registries (outside of those
   created by this document) have been replaced with references to
   this document, including the IANA URN namespace registration
   [URNNamespaces] for UUID.  References to Section 4.1.2 of [RFC4122]
   have been updated to refer to Section 4 of this document.


-->

KD: Yes, okay to change.


19) <!--[rfced] Is this use of "standards" referring to RFCs that are on
     the Standards Track?  Or is this the general use of the term?

Original:
Vendor-specific, application-specific, and deployment-specific values are unable to be registered.  Specification documents should be published in a stable, freely available manner (ideally located with a
URL) but need not be standards.
-->


KD: The general use of the term standards.

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.

21) <!--[rfced] RFC 7042 has been obsoleted by RFC 9542.  We have updated
     to point to the latter.  Please let us know any objections.-->

KD: This change is fine.

22) <!-- [rfced] Please review the title for reference [Snowflake] as the
     URL navigates to a page titled "snowflake-2010", and we were
     unable to find a URL with the title below.

Current:
   [Snowflake]
              Twitter, "Snowflake is a network service for generating
              unique ID numbers at high scale with some simple
              guarantees.", commit b3f6a3c, May 2014,
              <https://github.com/twitter-
              archive/snowflake/releases/tag/snowflake-2010>.
-->

KD: The title for this reference is from the "about" on main page of the website as commits don't really have titles (and are hard to cite).
I am fine with dropping the commit URL and citing the main GitHub link below, which does have that text.
https://github.com/twitter-archive/snowflake

23) <!-- [rfced] For reference [Microsoft], the provided URL navigates to
     a page titled "1.1 Glossary", where "curly braced GUID string" is
     defined lower on the page. To better match the title provided,
     may we update to the following URL with the title "2.3.4.3 GUID -
     Curly Braced String Representation"?

https://learn.microsoft.com/en-us/openspecs/windows_protocols/ms-dtyp/222af2d3-5c00-4899-bc87-ed4c6515e80d

Original:
   [Microsoft]
              Microsoft, "curly braced GUID string", 3 April 2023,
              <https://learn.microsoft.com/en-
              us/openspecs/windows_protocols/ms-dtyp/a66edeb1-52a0-4d64-
              a93b-2f5c833d7d92>.
-->

KD: Yes, a valid change.


24) <!-- [rfced] Please review the URL for reference [IBM_NCS] and let us
     know if you would like to update to the newest version of this
     manual:

https://www.ibm.com/docs/en/aix/7.3?topic=u-uuid-get-command

Current:
   [IBM_NCS]  IBM, "uuid_gen Command (NCS)", March 2023,
              <https://www.ibm.com/docs/en/aix/7.1?topic=u-uuid-gen-
              command-ncs>.
-->


KD: 7.1 page reference is correct.

25) <!--[rfced] May we update the pseudocode in Figure 15 as follows (note there are multiple changes):

Original:

   # Gregorian to Unix Offset:
   # The number of 100-ns intervals between the
   # UUID epoch 1582-10-15 00:00:00
   # and the Unix epoch 1970-01-01 00:00:00
   # Greg_Unix_offset = 0x01b21dd213814000 or 122192928000000000

   # Unix 64 bit Nanosecond Timestamp:
   # Unix NS: Tuesday, February 22, 2022 2:22:22 PM GMT-05:00
   # Unix_64_bit_ns = 0x16D6320C3D4DCC00 or 1645557742000000000

   # Unix Nanosecond precision to Gregorian 100-nanosecond intervals
   # Greg_100_ns = (Unix_64_bit_ns/100)+Greg_Unix_offset

   # Work:
   # Greg_100_ns = (1645557742000000000/100)+122192928000000000
   # Unix_64_bit_ns = (138648505420000000-122192928000000000)*100

   # Final:
   # Greg_100_ns = 0x1EC9414C232AB00 or 138648505420000000
   
Perhaps:

   # Gregorian-to-Unix Offset:
   # The number of 100 ns intervals between the
   # UUID Epoch 1582-10-15 00:00:00
   # and the Unix Epoch 1970-01-01 00:00:00
   # Greg_Unix_offset = 0x01b21dd213814000 or 122192928000000000

   # Unix 64-bit Nanosecond Timestamp:
   # Unix NS: Tuesday, February 22, 2022 2:22:22 PM GMT-05:00
   # Unix_64_bit_ns = 0x16D6320C3D4DCC00 or 1645557742000000000

   # Unix Nanosecond precision to Gregorian 100-nanosecond intervals
   # Greg_100_ns = (Unix_64_bit_ns/100)+Greg_Unix_offset

   # Work:
   # Greg_100_ns = (1645557742000000000/100)+122192928000000000
   # Unix_64_bit_ns = (138648505420000000-122192928000000000)*100

   # Final:
   # Greg_100_ns = 0x1EC9414C232AB00 or 138648505420000000
-->

KD: Yes, changes are fine.

26) <!--[rfced] We see "Ver Var" in the title of Figure 19 and "Ver/Var"
     in the title of Figure 20.  Should these be made uniform?-->

KD: Yes, "Var/Var" is best for figure 19.

27) <!--[rfced] Please review Figure 24 for line breaking of "-2dee3e35"
     and let us know if any updates are necessary.-->

KD: No updates required. 

28) <!--[rfced] The structure of this list is difficult to parse.  We
     assume the citations apply to both algorithms listed before
     them.

Original:
These MAY leverage newer hashing algorithms, such as SHA-256 or
SHA-512 defined by [FIPS180-4], SHA-3 or SHAKE defined by [FIPS202], or even algorithms that have not been defined yet.

Perhaps A:
These MAY leverage newer hashing algorithms such as SHA-256 or SHA-512 (as defined by [FIPS180-4]), SHA-3 or SHAKE (as defined by [FIPS202]), or even algorithms that have not been defined yet.

Perhaps B:
These MAY leverage newer hashing algorithms, such as:
-SHA-256 or SHA-512 (defined by [FIPS180-4]),
-SHA-3 or SHAKE (defined by [FIPS202]), or -algorithms that have not yet been defined.

-->

KD: I am okay with "Perhaps A" text modification.


29) <!--[rfced] May we update this text for accuracy?

Original:
   A SHA-256 version of Appendix A.4 is detailed in Figure 28 as an
   illustrative example detailing how this can be achieved.

Perhaps:
   A SHA-256 version of the SHA-1 computation in Appendix A.4 is
   detailed in Figure 28 as an illustrative example detailing how this
   can be achieved.
-->

KD: Yes, Okay to change.


30)  <!--[rfced] Will the reader easily know to which section "the byte
      ordering section" refers?  Or would a pointer to the section's
      title be preferable?

Original:
   This document draws heavily on the OSF DCE specification for UUIDs.
   Ted Ts'o provided helpful comments, especially on the byte ordering
   section which we mostly plagiarized from a proposed wording he
   supplied (all errors in that section are our responsibility,
   however).

-->

KD: A carry over from the previous document. I am fine with removing all of the text after "helpful comments"
Remove: ", especially on the byte ordering
   section which we mostly plagiarized from a proposed wording he
   supplied (all errors in that section are our responsibility,
   however)."

31) <!-- [rfced] Terminology: Please review the following terminology
     questions/comments and let us know how you'd like to proceed.

a) Please review the following similar terms and let us know if/how any of them can be made consistent throughout.

bit-length counter
a counter bit-length (other uses of bit length as a noun are not hyphenated) fixed bit-length counter fixed-length counter method fixed-length dedicated counters 

KD:
I am fine with "bit-length" everywhere and for "fixed bit-length" to replace any "fixed-length" as well for consistency.
And for the one hard one where "bit" would be used twice:
OLD: Fixed-Length Dedicated Counter Bits (Method 1):
NEW: Fixed Bit-Length Dedicated Counter (Method 1):

b) We have updated to use "dot notation" (no hyphen) to match use in past RFCs.  Please let us know any objections.

KD: Yes, valid change.

c) For the following terms, may we update to use the form on the right to make these terms appear consistent throughout the text?

   namespace ID value > Namespace ID value
   namespace IDs > Namespace IDs 
   node ID and node identifier > Node ID

KD: Yes, valid cahgnes.

d) For instances of "Name "www.example.com"", is it intentional to capitalize "Name"?  We ask because this is the only instance where "Name" is capitalized.

KD: For this particular instance I believe capitalization of "Name" is fine.

e) Please review the use of the following terms with regard to
capitalization:

Gregorian epoch
Epoch time-based
Unix Epoch timestamp vs. Unix epoch timestamp custom timestamp epoch Gregorian epoch

Please consider epoch vs. Epoch and let us know if/how you'd like to update for consistency.  Please note that the pseudocode may be impacted by this choice.

KD: Capitalize Epoch everywhere (including the pseudocode)

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

-->

32) <!-- [rfced] Sourcecode / Artwork

a) We see type="code" was used for the sourcecode element in Appendix A.  We have updated to use "pseudocode".  If this is incorrect, please let us know.

See https://www.rfc-editor.org/materials/sourcecode-types.txt for the list of available types if necessary.  If the current list does not contain an applicable type, feel free to suggest additions for consideration. (Note that it is also acceptable to leave the "type"
attribute not set.)

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. 

33) <!--[rfced] Please review the following expansions we have added for
     abbreviations used throughout the document.  Please let us know
     if you would like to add any of these abbreviations to the
     abbreviations list in Section 3.2.

NCS - Network Control Signaling
-->

KD: Change NCS to "Network Computing System" which can be abbreviated as early as the abstract " Apollo Network Computing System (NCS)" since later in the text "Apollo NCS" already exists. 
Please ensure we fix this in Row 1 of Table 1 where NCS was expanded incorrectly.

34) <!--[rfced] Please review the "Inclusive Language" portion of the
     online Style Guide
     <https://www.rfc-editor.org/styleguide/part2/#inclusive_language>
     and let us know if any changes are needed.

In addition, please consider whether "tradition" should be updated for clarity.  While the NIST website <https://www.nist.gov/nist-research-library/nist-technical-series-publications-author-instructions#table1>
indicates that this term is potentially biased, it is also ambiguous.
"Tradition" is a subjective term, as it is not the same for everyone.

Current:
   Low Impact:
      A UUID collision generated a duplicate log entry, which results in
      incorrect statistics derived from the data.  Implementations that
      are not negatively affected by collisions may continue with the
      entropy and uniqueness provided by the traditional UUID format.
-->

KD: Replace "the traditional UUID format." with "UUIDs defined in this document."

Thank you.

RFC Editor/st/mf


*****IMPORTANT*****

Updated 2024/04/11

RFC Author(s):
--------------

Instructions for Completing AUTH48

Your document has now entered AUTH48.  Once it has been reviewed and approved by you and all coauthors, it will be published as an RFC.  
If an author is no longer available, there are several remedies available as listed in the FAQ (https://www.rfc-editor.org/faq/).

You and you coauthors are responsible for engaging other parties (e.g., Contributors or Working Group) as necessary before providing your approval.

Planning your review
---------------------

Please review the following aspects of your document:

*  RFC Editor questions

   Please review and resolve any questions raised by the RFC Editor 
   that have been included in the XML file as comments marked as 
   follows:

   <!-- [rfced] ... -->

   These questions will also be sent in a subsequent email.

*  Changes submitted by coauthors 

   Please ensure that you review any changes submitted by your 
   coauthors.  We assume that if you do not speak up that you 
   agree to changes submitted by your coauthors.

*  Content 

   Please review the full content of the document, as this cannot 
   change once the RFC is published.  Please pay particular attention to:
   - IANA considerations updates (if applicable)
   - contact information
   - references

*  Copyright notices and legends

   Please review the copyright notice and legends as defined in
   RFC 5378 and the Trust Legal Provisions 
   (TLP – https://trustee.ietf.org/license-info/).

*  Semantic markup

   Please review the markup in the XML file to ensure that elements of  
   content are correctly tagged.  For example, ensure that <sourcecode> 
   and <artwork> are set correctly.  See details at 
   <https://authors.ietf.org/rfcxml-vocabulary>.

*  Formatted output

   Please review the PDF, HTML, and TXT files to ensure that the 
   formatted output, as generated from the markup in the XML file, is 
   reasonable.  Please note that the TXT will have formatting 
   limitations compared to the PDF and HTML.


Submitting changes
------------------

To submit changes, please reply to this email using ‘REPLY ALL’ as all the parties CCed on this message need to see your changes. The parties
include:

   *  your coauthors
   
   *  [e-mail] (the RPC team)

   *  other document participants, depending on the stream (e.g., 
      IETF Stream participants are your working group chairs, the 
      responsible ADs, and the document shepherd).
     
   *  [e-mail], which is a new archival mailing list 
      to preserve AUTH48 conversations; it is not an active discussion 
      list:
     
     *  More info:
        https://mailarchive.ietf.org/arch/msg/ietf-announce/yb6lpIGh-4Q9l2USxIAe6P8O4Zc
     
     *  The archive itself:
        https://mailarchive.ietf.org/arch/browse/auth48archive/

     *  Note: If only absolutely necessary, you may temporarily opt out 
        of the archiving of messages (e.g., to discuss a sensitive matter).
        If needed, please add a note at the top of the message that you 
        have dropped the address. When the discussion is concluded, 
        [e-mail] will be re-added to the CC list and 
        its addition will be noted at the top of the message. 

You may submit your changes in one of two ways:

An update to the provided XML file
 — OR —
An explicit list of changes in this format

Section # (or indicate Global)

OLD:
old text

NEW:
new text

You do not need to reply with both an updated XML file and an explicit list of changes, as either form is sufficient.

We will ask a stream manager to review and approve any changes that seem beyond editorial in nature, e.g., addition of new text, deletion of text, and technical changes.  Information about stream managers can be found in the FAQ.  Editorial changes do not require approval from a stream manager.


Approving for publication
--------------------------

To approve your RFC for publication, please reply to this email stating that you approve this RFC for publication.  Please use ‘REPLY ALL’, as all the parties CCed on this message need to see your approval.


Files
-----

The files are available here:
   https://www.rfc-editor.org/authors/rfc9562.xml
   https://www.rfc-editor.org/authors/rfc9562.html
   https://www.rfc-editor.org/authors/rfc9562.pdf
   https://www.rfc-editor.org/authors/rfc9562.txt

Diff file of the text:
   https://www.rfc-editor.org/authors/rfc9562-diff.html
   https://www.rfc-editor.org/authors/rfc9562-rfcdiff.html (side by side)

For your convenience, we have created an alternate diff to accommodate moved/deleted text:
    https://www.rfc-editor.org/authors/rfc9562-alt-diff.html

Diff of the XML: 
   https://www.rfc-editor.org/authors/rfc9562-xmldiff1.html

The following files are provided to facilitate creation of your own diff files of the XML.  

Initial XMLv3 created using XMLv2 as input:
   https://www.rfc-editor.org/authors/rfc9562.original.v2v3.xml 

XMLv3 file that is a best effort to capture v3-related format updates
only: 
   https://www.rfc-editor.org/authors/rfc9562.form.xml


Tracking progress
-----------------

The details of the AUTH48 status of your document are here:
   https://www.rfc-editor.org/auth48/rfc9562

Please let us know if you have any questions.  

Thank you for your cooperation,

RFC Editor

--------------------------------------
RFC9562 (draft-ietf-uuidrev-rfc4122bis-14)

Title            : Universally Unique IDentifiers (UUID)
Author(s)        : K. Davis, B. Peabody, P. Leach
WG Chair(s)      : Jim Fenton, Michael Richardson

Area Director(s) : Murray Kucherawy, Orie Steele