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

[[e-mail]]

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


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.

-->


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?

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.

-->


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


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.


-->


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


a) Would you like the abbreviations in Section 3.2 to be alphabetized?

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.

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?

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

-->


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


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

-->


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.

-->


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


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.

-->


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


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


-->


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


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


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.

-->


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.


-->


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


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


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


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


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


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


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


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


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


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.

-->


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


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

-->


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 


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


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

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.

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.

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


-->


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


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


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


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