Greetings, While reviewing this document during AUTH48, please resolve (as necessary) the following questions, which are also in the source file.
1) <!-- [rfced] Regarding how you would like your name to appear: It appears as "Jürgen Schönwälder" in the Authors' Addresses section but as "Juergen Schoenwaelder" in the YANG modules. It looks like "Juergen Schoenwaelder" was used in other RFCs that you have authored, but those were prior to the current format. At this point, non-ASCII characters can be used. Which form do you prefer for this document and going forward? --> 2) <!-- [rfced] Please insert any keywords (beyond those that appear in the title) for use on https://www.rfc-editor.org/search. --> 3) <!--[rfced] Abstract: May we update "version of the document" to simply "This document"? Also, perhaps "includes" is better than "adds". Original: This version of the document adds several new type definitions and obsoletes RFC 6991. Perhaps: This document includes several new type definitions and obsoletes RFC 6991. --> 4) <!-- [rfced] We updated the "types for counters, gauges, date and time related types" as follows to improve readability of the sentence. We also updated "uuids, dotted-quads, or language tags" to "UUIDs, dotted-quad notation, and language tags". Please review and let us know any concerns. Original: * The "ietf-yang-types" module defines generally useful data types such as types for counters, gauges, date and time related types, or types for common string values such as uuids, dotted-quads, or language tags. Current: * The "ietf-yang-types" module defines generally useful data types such as types for counters and gauges, types related to date and time, and types for common string values (e.g., UUIDs, dotted-quad notation, and language tags). --> 5) <!-- [rfced] We updated "IP address related types, domain-name and host-name types, uri and email types" as follows for clarity. Please review. Original: * The "ietf-inet-types" module defines data types relevant for the Internet protocol suite such as IP address related types, domain- name and host-name types, uri and email types, as well as types for values in common protocol fields such as port numbers. Updated: * The "ietf-inet-types" module defines data types relevant for the Internet protocol suite such as types related to IP address, types for domain name, host name, URI, and email, and types for values in common protocol fields (e.g., port numbers). --> 6) <!--[rfced] In Tables 1 and 2, for clarity may we change the column title from "Introduced" to "Introduced in", where it lists the RFC that introduced the type? --> 7) <!-- [rfced] We have a couple of questions about this sentence. Original: The ietf-yang-types YANG module references [IEEE-802-2001], [ISO-9834-1], [RFC2578], [RFC2579], [RFC2856], [RFC3339], [RFC4122], [RFC4502], [RFC5131], [RFC5646], [RFC7950], [RFC8294], [RFC9557], [W3C.xpath], and [W3C.xmlschema11-2]. a) We do not see a reference to [RFC8294] in the YANG module. Should [RFC8294] be removed from this sentence (and from the references section), or should it be cited in the YANG module? b) The sentence above uses [W3C.xpath] and [W3C.xmlschema11-2], but the YANG module uses "XPATH" and "XSD-TYPES" (see below). For the ease of the reader, we updated the citation tags to [XPATH] and [XSD-TYPES] to match the YANG module. If you prefer to align these in a different way, please let us know. Original: "XPATH: XML Path Language (XPath) Version 1.0"; ... XSD-TYPES: XML Schema Definition Language (XSD) 1.1 Part 2: Datatypes"; --> 8) <!-- [rfced] The text below appears in RFC 6991, but perhaps it can be revised to be more clear and readable. Please review the following suggestions and let us know your thoughts. a) Suggestion: Revise the introductory clause (i.e., "If..., then"). Note: This text appears twice in this document. Original: If such other times can occur, for example, the instantiation of a schema node of type counter64 at times other than re-initialization, then a corresponding schema node should be defined, with an appropriate type, to indicate the last discontinuity. Perhaps: If discontinuities occur at times other than re-initialization (for example, at the instantiation of a schema node of type counter64), then a corresponding schema node should be defined, with an appropriate type, to indicate the last discontinuity. b) Suggestion: Split into two sentences rather than use multiple parentheses. Original: If the information being modeled subsequently decreases below (increases above) the maximum (minimum) value, the gauge32 also decreases (increases). Perhaps: If the information being modeled subsequently decreases below the maximum value, the gauge32 also decreases; likewise, if the information increases above the minimum value, the gauge32 also increases. c) Suggestion: Update "in case a server follows automatically" as shown below. Original: Such changes might happen periodically in case a server follows automatically daylight saving time (DST) time zone offset changes. Perhaps: Such changes might happen periodically if a server automatically follows daylight saving time (DST) time zone offset changes. --> 9) <!-- [rfced] "ISO 8601" is mentioned in this description clause, but we do not see it in the corresponding reference clause (which only contains RFC 3339, RFC 9557, RFC 2579, and XSD-TYPES). If a reference for ISO 8601 is needed, please provide it. Original: "The date-and-time type is a profile of the ISO 8601 standard for representation of dates and times using the Gregorian calendar. --> 10) <!-- [rfced] We updated "as a sequence octets" to "as a sequence of octets" (i.e., added "of"). Please let us know if this is incorrect. Original: description "Represents media- or physical-level addresses represented as a sequence octets, each octet represented by two hexadecimal numbers. Perhaps: description "Represents media- or physical-level addresses represented as a sequence of octets, each octet represented by two hexadecimal numbers. --> 11) <!--[rfced] In yang-identifier, would you like to clarify "an earlier version of this definition"? If this is referring to the definition in RFC 6991, then may that be stated? Current: An earlier version of this definition excluded all identifiers starting with any possible combination of the lowercase or uppercase character sequence 'xml', as required by YANG 1 defined in RFC 6020. Perhaps: In RFC 6991, this definition excluded all identifiers starting with any possible combination of the lowercase or uppercase character sequence 'xml', as required by YANG 1 defined in RFC 6020. --> 12) <!--[rfced] FYI, the YANG modules have been updated per the formatting option of pyang. Please let us know any concerns. --> 13) <!--[rfced] The following lines are too long for the line limit of the text output (72 characters in the text, which means 69 characters within the sourcecode element in the XML file). Please let us know how these lines should be updated. a) typedef date-and-time (2 characters longer) + 'T(0[0-9]|1[0-9]|2[0-3]):[0-5][0-9]:([0-5][0-9]|60)(\.[0-9]+)?' b) typedef time (1 character longer) '(0[0-9]|1[0-9]|2[0-3]):[0-5][0-9]:([0-5][0-9]|60)(\.[0-9]+)?' c) typedef time-no-zone (2 characters longer) '(0[0-9]|1[0-9]|2[0-3]):[0-5][0-9]:([0-5][0-9]|60)(\.[0-9]+)?' Perhaps: '(0[0-9]|1[0-9]|2[0-3]):[0-5][0-9]:([0-5][0-9]|60)' + '(\.[0-9]+)?'; d) typedef domain-name (1 character longer) pattern '((([a-zA-Z0-9_]([a-zA-Z0-9\-_]){0,61})?[a-zA-Z0-9]\.)*' --> 14) <!--[rfced] Mentions of RFCs 6531 and 6532 a) RFC 6532 is mentioned in the description clause below, but RFC 6531 is listed in the reference clause. Which is correct? Original: description "The email-address type represents an internationalized email address. The email address format is defined by the addr-spec ABNF rule in RFC 5322 section 3.4.1. This format has been extended by RFC 6532 to support internationalized email addresses. Implementations MUST support the internationalization extensions of RFC 6532. Support of the obsolete obs-local-part, obs-domain, and obs-qtext parts of RFC 5322 is not required. The domain part may use both A-labels and U-labels (see RFC 5890). The canonical format of the domain part uses lowercase characters and U-labels (RFC 5890) where applicable."; reference "RFC 5322: Internet Message Format RFC 5890: Internationalized Domain Names in Applications (IDNA): Definitions and Document Framework RFC 6531: SMTP Extension for Internationalized Email"; b) Neither RFC 6532 nor RFC 6531 appear in the following sentence in Section 4 or in the references section. We will update this sentence and add an entry in the informative references section based on the reply to the question above. Original: The ietf-inet-types YANG module references [RFC0768], [RFC0791], [RFC0952], [RFC1034], [RFC1123], [RFC1930], [RFC2317], [RFC2474], [RFC2780], [RFC2782], [RFC3289], [RFC3305], [RFC3595], [RFC3927], [RFC3986], [RFC4001], [RFC4007], [RFC4271], [RFC4291], [RFC4340], [RFC4592], [RFC5017], [RFC5322], [RFC5890], [RFC5952], [RFC6793], [RFC8200], [RFC9260], [RFC9293], and [RFC9499]. --> 15) <!-- [rfced] For these sentences, would pointing to the specific registries be more helpful to readers? If so, please provide the registry names and URLs. Original: Port numbers are assigned by IANA. The current list of all assignments is available from <https://www.iana.org/>. ... Protocol numbers are assigned by IANA. The current list of all assignments is available from <https://www.iana.org/>."; ... IANA maintains the AS number space and has delegated large parts to the regional registries. --> 16) <!-- [rfced] Should "a length bytes" be updated to "a length byte"? Original: Since the encoding consists of labels prefixed by a length bytes and there is a trailing NULL byte, only 253 characters can appear in the textual dotted notation. Perhaps: Since the encoding consists of labels prefixed by a length byte and there is a trailing NULL byte, only 253 characters can appear in the textual dotted notation. --> 17) <!-- [rfced] Is "parts" to best word choice here? Is "rules" better? Or perhaps "parts" should be deleted? Original: Support of the obsolete obs-local-part, obs-domain, and obs-qtext parts of RFC 5322 is not required. Perhaps ("rules"): Support for the obsolete obs-local-part, obs-domain, and obs-qtext rules in RFC 5322 is not required. Or (delete "parts"): Support for the obsolete obs-local-part, obs-domain, and obs-qtext in RFC 5322 is not required. --> 18) <!-- [rfced] Are the parentheses around "(fully qualified)" needed here? Original: The host-name type represents (fully qualified) host names. ... "The host type represents either an IP address or a (fully qualified) host name."; Perhaps: The host-name type represents fully qualified host names. ... "The host type represents either an IP address or a fully qualified host name."; --> 19) <!-- [rfced] Should "IP protocol" be updated to "Internet Protocol" here? Original: description "This value represents the version of the IP protocol. Perhaps: description "This value represents the version of the Internet Protocol. --> 20) <!-- [rfced] The Security Considerations section does not match the recommended text at https://wiki.ietf.org/group/ops/yang-security-guidelines. Please review and let us know if any updates are needed. --> 21) <!-- [rfced] Would you like the references to be alphabetized or left in their current order? --> 22) <!-- [rfced] RFC 4122 has been obsoleted by RFC 9562. May we replace instances of RFC 4122 with RFC 9562? --> 23) <!-- [rfced] This reference has been withdrawn (see https://www.iso.org/standard/51424.html). It has been replaced by ISO/IEC 9834-1:2012 (see https://www.iso.org/standard/58055.html). May we update this reference to the most current version? Original: [ISO-9834-1] ISO/IEC 9834-1:2008, "Information technology - Open Systems Interconnection - Procedures for the operation of OSI Registration Authorities: General procedures and top arcs of the ASN.1 Object Identifier tree", 2008. --> 24) <!-- [rfced] This reference has been superseded (see (https://ieeexplore.ieee.org/document/984782/versions). The new version is IEEE Std 802-2024 (see https://ieeexplore.ieee.org/document/10935844). May we update this reference to the most current version? Original: [IEEE-802-2001] IEEE Std 802-2001, "IEEE Standard for Local and Metropolitan Area Networks: Overview and Architecture", June 2001. --> 25) <!-- [rfced] We updated "[RFC6020]" here to "[RFC6021]". Please confirm that this is correct. Original: The following people contributed significantly to the original version of this document published as [RFC6020]: Andy Bierman, Martin Bjorklund, Balazs Lengyel, David Partain and Phil Shafer. Perhaps: The following people contributed significantly to the original version of this document, which was published as [RFC6021]: Andy Bierman, Martin Bjorklund, Balazs Lengyel, David Partain, and Phil Shafer. --> 26) <!-- [rfced] Does "various versions of this document" refer to (1) the draft versions of draft-ietf-netmod-rfc6991-bis or (2) RFCs 6021 and 6991? Original: Helpful comments on various versions of this document were provided by the following individuals: Andy Bierman, Martin Bjorklund, Benoit Claise, Joel M. Halpern, Ladislav Lhotka, Lars-Johan Liman, and Dan Romascanu. Perhaps (if draft versions): Helpful comments on various draft versions of this document were provided by the following individuals: Andy Bierman, Martin Björklund, Benoît Claise, Joel M. Halpern, Ladislav Lhotka, Lars-Johan Liman, and Dan Romascanu. --> 27) <!-- [rfced] Terminology a) We note inconsistencies in the terms below throughout the text. Should these be uniform? If so, please let us know which form is preferred. local time reference point local time zone reference point AS number space autonomous system number space b) Is "NULL" correct here? Or should it be updated to "null"? Original: Since the encoding consists of labels prefixed by a length bytes and there is a trailing NULL byte, only 253 characters can appear in the textual dotted notation. c) The RPC has been advised that "ASCII" should be used instead of "US-ASCII". May we change instances of "US-ASCII" in the description clauses below to "ASCII"? Original: Domain-name values use the US-ASCII encoding. Their canonical format uses lowercase US-ASCII characters. ... Objects using the uri type MUST be in US-ASCII encoding, Perhaps: Domain-name values use the ASCII encoding. Their canonical format uses lowercase ASCII characters. ... Objects using the uri type MUST be in ASCII encoding, d) Should some instances of "Internet protocol" be updated to "Internet Protocol" (capitalized)? Please review whether instances are referring to IP, rather than Internet protocols in general. e) FYI, we added a hyphen to "range restricted" (9 instances). Please let us know if you prefer otherwise. For example: Original: This type should be range restricted in situations where only non-negative time periods are desirable, ... Current: This type should be range-restricted in situations where only non-negative time periods are desirable, ... --> 28) <!-- [rfced] FYI - We have added expansion(s) for the following abbreviation(s) per Section 3.6 of RFC 7322 ("RFC Style Guide"). Please review each expansion in the document carefully to ensure correctness. Media Access Control (MAC) --> 29) <!-- [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. Updates of this nature typically result in more precise language, which is helpful for readers. Note that our script did not flag any words in particular, but this should still be reviewed as a best practice. --> Thank you. Rebecca VanRheenen and Alice Russo RFC Production Center On Dec 1, 2025, at 10:45 PM, [email protected] wrote: *****IMPORTANT***** Updated 2025/12/01 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 * [email protected] (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). * [email protected], 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, [email protected] 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/rfc9911.xml https://www.rfc-editor.org/authors/rfc9911.html https://www.rfc-editor.org/authors/rfc9911.pdf https://www.rfc-editor.org/authors/rfc9911.txt Diff file of the text: https://www.rfc-editor.org/authors/rfc9911-diff.html https://www.rfc-editor.org/authors/rfc9911-rfcdiff.html (side by side) Diff of the XML: https://www.rfc-editor.org/authors/rfc9911-xmldiff1.html Tracking progress ----------------- The details of the AUTH48 status of your document are here: https://www.rfc-editor.org/auth48/rfc9911 Please let us know if you have any questions. Thank you for your cooperation, RFC Editor -------------------------------------- RFC9911 (draft-ietf-netmod-rfc6991-bis-18) Title : Common YANG Data Types Author(s) : J. Schönwälder, Ed. WG Chair(s) : Kent Watsen, Lou Berger Area Director(s) : Mohamed Boucadair, Mahesh Jethanandani -- auth48archive mailing list -- [email protected] To unsubscribe send an email to [email protected]
