Hi Jürgen and Mahesh*, *Mahesh - As AD, please let us know if you approve leaving the Security Considerations section as is (i.e., not aligned with the boilerplate at https://wiki.ietf.org/group/ops/yang-security-guidelines). Jürgen prefers not to change it.
Jürgen - Thank you for responding to all of our questions. We have updated the document accordingly; see list of files below. We also have a few followup questions/comments for you. a) Regarding this suggestion: >> Since the first sentence already starts with "This document", what >> about this: >> >> NEW: >> >> This version >> includes several new type definitions and obsoletes RFC 6991. How about updating to use “It”? Perhaps (first sentence included for context): This document defines a collection of common data types to be used with the YANG data modeling language. It includes several new type definitions and obsoletes RFC 6991. b) Per your response to question #9, we added ISO 8601 to the reference clause for typedef date-and-time, added [ISO-8601] to the sentence before the YANG module, and added a corresponding informative reference entry. Please let us know if the reference should be normative instead. Also, note that ISO 8601:2000 has been withdrawn (see https://www.iso.org/standard/26780.html). Per your comments, we believe you still prefer to cite ISO 8601:2000, but please confirm. c) Regarding this: >> 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. >> --> > > Yes, this is clearer. We updated as shown above. Should RFC 6991 also be added to the corresponding reference clause for typedef yang-identifier? d) We believe we updated the long lines mentioned in question #13 correctly, but please review carefully. e) Regarding this question: >>> 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. >>> --> >> >> I prefer to not include more specific links as I have no idea how >> stable they may be. Understood. We could include registry titles but not specific links if you like (see suggestions below). We will go with your preference. Perhaps: Port numbers are assigned by IANA. The current list of all assignments is available from the "Service Name and Transport Protocol Port Number Registry” at <https://www.iana.org/>. … Protocol numbers are assigned by IANA. The current list of all assignments is available from the "Assigned Internet Protocol Numbers” registry at <https://www.iana.org/>.”; … IANA maintains the "Autonomous System (AS) Numbers” registry and has delegated large parts to the regional registries. — FILES (please refresh) — Updated XML file: https://www.rfc-editor.org/authors/rfc9911.xml Updated output files: https://www.rfc-editor.org/authors/rfc9911.txt https://www.rfc-editor.org/authors/rfc9911.pdf https://www.rfc-editor.org/authors/rfc9911.html Diff file showing all changes made during AUTH48: https://www.rfc-editor.org/authors/rfc9911-auth48diff.html https://www.rfc-editor.org/authors/rfc9911-auth48rfcdiff.html (side by side) Diff files showing all changes: https://www.rfc-editor.org/authors/rfc9911-diff.html https://www.rfc-editor.org/authors/rfc9911-rfcdiff.html (side by side) https://www.rfc-editor.org/authors/rfc9911-alt-diff.html (diff showing changes where text is moved or deleted) For the AUTH48 status of this document, please see: https://www.rfc-editor.org/auth48/rfc9911 Thank you, Rebecca VanRheenen RFC Production Center > On Dec 7, 2025, at 5:47 AM, Jürgen Schönwälder > <[email protected]> wrote: > > Dear RFC editor, > > sorry for the delay. I will go address your questions one by one, see > my comments inline. I also reviewed the diffs carefully. Thanks for > all your edits, much appreciated. I did not spot any errors that were > introduced. > > /js > > On Mon, Dec 01, 2025 at 10:46:38PM -0800, [email protected] wrote: >> 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? >> --> > > I think it is cool to be able to use the correct spelling of my name > even though it will make proper indexing harder but then I am used to > that struggle. So please use "Jürgen Schönwälder" in the Authors' > Addresses section. And perhaps we should then be consistent and also > use "Jürgen Schönwälder" in the YANG modules. > >> 2) <!-- [rfced] Please insert any keywords (beyond those that appear in >> the title) for use on https://www.rfc-editor.org/search/rfc_search.php --> > > yang, data types, address types, time types, date types > >> 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. >> --> > > Since the first sentence already starts with "This document", what > about this: > > NEW: > > This version > 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). >> --> > > OK > >> 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). >> --> > > OK > >> 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? >> --> > > Yes, please change. > >> 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? > > I do not recall why it is there, but since there is no reference to > RFC8294 anywhere else, it should be removed. Thanks for catching this. > >> 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"; >> --> > > Thanks, I appreciate this change. > >> 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. > > Yes, this reads better. > >> 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. > > Yes, this is clearer. > >> 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. >> --> > > OK > >> 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. >> --> > > Good catch. I think we should have a YANG reference clause to ISO 8601 > and then cite ISO 8601 in the text before the YANG module. RFC 3339 has > two versions and RFC 9557 three versions of the ISO 8601 standard: > > [ISO8601-1:2019] > ISO, "Date and time -- Representations for information > interchange -- Part 1: Basic rules", ISO 8601-1:2019, > February 2019, <https://www.iso.org/standard/70907.html>. > > [ISO8601:1988] > ISO, "Data elements and interchange formats -- Information > interchange -- Representation of dates and times", > ISO 8601:1988, June 1988, > <https://www.iso.org/standard/15903.html>. Also available > from <https://nvlpubs.nist.gov/nistpubs/Legacy/FIPS/ > fipspub4-1-1991.pdf>. > > [ISO8601:2000] > ISO, "Data elements and interchange formats -- Information > interchange -- Representation of dates and times", > ISO 8601:2000, December 2000, > <https://www.iso.org/standard/26780.html>. > > RFC 6991 was published in 2013, so the correct reference would be > ISO8601:1988 as this definition already did exist in RFC 6991. But > then the WG went through a long discussion to align these types with > RFC 9557, which seeks alignment with ISO8601:2000. So the proper > version to pick is likely ISO8601:2000. Hence, the reference statement > of the date-and-time type should include: > > ISO 8601: Data elements and interchange formats -- Information > interchange -- Representation of dates and times > > The text before the ietf-yang-types module should reference [ISO-8601] > and the reference section should have > > [ISO-8601] > ISO, "Data elements and interchange formats -- Information > interchange -- Representation of dates and times", > ISO 8601:2000, December 2000, > <https://www.iso.org/standard/26780.html>. > >> 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. >> --> > > Yes, this is good. > >> 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. >> --> > > Yes, this is clearer. > >> 12) <!--[rfced] FYI, the YANG modules have been updated per the >> formatting option of pyang. Please let us know any concerns. >> --> > > Looks good. > >> 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]+)?' > > I suggest to move the optional last part to a separate line: > > NEW > > + '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]+)?' > > Same here: > > NEW > '(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]+)?'; > > Yes, this is inline with what I suggested for the other cases. > >> d) typedef domain-name (1 character longer) >> pattern '((([a-zA-Z0-9_]([a-zA-Z0-9\-_]){0,61})?[a-zA-Z0-9]\.)*' >> --> > > Does this problem disappear if the pattern value starts on a new line? > Instead of > > pattern '((([a-zA-Z0-9_]([a-zA-Z0-9\-_]){0,61})?[a-zA-Z0-9]\.)*' > + '([a-zA-Z0-9_]([a-zA-Z0-9\-_]){0,61})?[a-zA-Z0-9]\.?)' > + '|\.'; > > we may get > > pattern > '((([a-zA-Z0-9_]([a-zA-Z0-9\-_]){0,61})?[a-zA-Z0-9]\.)*' > + '([a-zA-Z0-9_]([a-zA-Z0-9\-_]){0,61})?[a-zA-Z0-9]\.?)' > + '|\.'; > > and that should resolve the issue. > >> 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"; > > I think the text is correct and the reference is wrong. It should > be: > > OLD > RFC 6531: SMTP Extension for Internationalized Email"; > > NEW > RFC 6532: Internationalized Email Headers"; > >> 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]. >> --> > > Yes, please add [RFC6532]. > >> 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://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.iana.org%2F&data=05%7C02%7Cjschoenwaelder%40constructor.university%7C1add5c2ead7f422de6af08de316e8bf5%7Cf78e973e5c0b4ab8bbd79887c95a8ebd%7C0%7C0%7C639002548047961596%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=%2BsPR0mhk6M3%2FYONSPvtyYfhYESiITNUtIkg7J2IUr3c%3D&reserved=0>. >> ... >> Protocol numbers are assigned by IANA. The current list of >> all assignments is available from >> <https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.iana.org%2F&data=05%7C02%7Cjschoenwaelder%40constructor.university%7C1add5c2ead7f422de6af08de316e8bf5%7Cf78e973e5c0b4ab8bbd79887c95a8ebd%7C0%7C0%7C639002548047990795%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=%2FGCajNz2YzWFFv286sXZnAWRaDQ2wUPebvzV2TpEUHk%3D&reserved=0>."; >> ... >> IANA maintains >> the AS number space and has delegated large parts to the >> regional registries. >> --> > > I prefer to not include more specific links as I have no idea how > stable they may be. > >> 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. >> --> > > Yes, it should be 'a length byte'. > >> 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. >> --> > > I like the last version the most. ;-) > >> 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."; >> --> > > Yes, please remove the parenthesis. > >> 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. >> --> > > Yes, the proposed wording is better. > >> 20) <!-- [rfced] The Security Considerations section does not match the >> recommended text at >> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwiki.ietf.org%2Fgroup%2Fops%2Fyang-security-guidelines&data=05%7C02%7Cjschoenwaelder%40constructor.university%7C1add5c2ead7f422de6af08de316e8bf5%7Cf78e973e5c0b4ab8bbd79887c95a8ebd%7C0%7C0%7C639002548048010871%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=rhQjcKIJ%2FdTJgY9GSqDPxZgb9josZuugDpoFhI9uPFI%3D&reserved=0. >> Please review and let us know if any updates are needed. >> --> > > The guidelines that apply in this case would reduce to: > > The YANG module defines a set of types. These nodes are intended to > be reused by other YANG modules. The module by itself does not > expose any data nodes that are writable, data nodes that contain > read-only state, or RPCs. As such, there are no additional security > issues related to the YANG module that need to be considered. > > This text is a bit weird as it talks about nodes but types are not > nodes. Anyway, I think what we have is saying the same thing and it > got approved by the IESG so I prefer to not change it. > >> 21) <!-- [rfced] Would you like the references to be alphabetized >> or left in their current order? >> --> > > I have no strong opinion. The current order works well for me > personally. > >> 22) <!-- [rfced] RFC 4122 has been obsoleted by RFC 9562. May we replace >> instances of RFC 4122 with RFC 9562? >> --> > > Yes, this update seems to be safe. As far as I understand, they did not > change the overall structure of UUIDs in RFC 9562. > >> 23) <!-- [rfced] This reference has been withdrawn (see >> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.iso.org%2Fstandard%2F51424.html&data=05%7C02%7Cjschoenwaelder%40constructor.university%7C1add5c2ead7f422de6af08de316e8bf5%7Cf78e973e5c0b4ab8bbd79887c95a8ebd%7C0%7C0%7C639002548048027719%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=SN9yobE2X96AJ1ejFNq%2FxWGc79Nu3bIiic5ceaKwPes%3D&reserved=0). >> It has been replaced by ISO/IEC >> 9834-1:2012 (see >> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.iso.org%2Fstandard%2F58055.html&data=05%7C02%7Cjschoenwaelder%40constructor.university%7C1add5c2ead7f422de6af08de316e8bf5%7Cf78e973e5c0b4ab8bbd79887c95a8ebd%7C0%7C0%7C639002548048045837%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=eU7AznMEMgemshW524%2BYJLEM4XfXaxkzCExyVyxiQ3I%3D&reserved=0). >> >> 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. > --> > > I _assume_ this update is safe as we only refer to the general > structure of the OID tree. > >> 24) <!-- [rfced] This reference has been superseded (see >> (https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fieeexplore.ieee.org%2Fdocument%2F984782%2Fversions&data=05%7C02%7Cjschoenwaelder%40constructor.university%7C1add5c2ead7f422de6af08de316e8bf5%7Cf78e973e5c0b4ab8bbd79887c95a8ebd%7C0%7C0%7C639002548048063560%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=GSBA44PlaH1BVwC0m1qAEnP%2BEi%2BIEai35I0Akabqi44%3D&reserved=0). >> The new version >> is IEEE Std 802-2024 (see >> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fieeexplore.ieee.org%2Fdocument%2F10935844&data=05%7C02%7Cjschoenwaelder%40constructor.university%7C1add5c2ead7f422de6af08de316e8bf5%7Cf78e973e5c0b4ab8bbd79887c95a8ebd%7C0%7C0%7C639002548048080847%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=bmlsUiT8c0MX13eur1nydgJNWmxfr80ybOesQtp34qI%3D&reserved=0). >> >> 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. >> --> > > Updating to the latest version should be OK. > >> 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. >> --> > > Thanks for catching this bug. Yes, it should have been RFC 6021. > >> 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. >> --> > > The intended meaning was draft versions, so please go ahead with your > proposal. > >> 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 > > I prefer to use local time zone reference point. > >> AS number space >> autonomous system number space > > I suggest to use the longer version, "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. > > I guess it is actually a NUL byte. > >> 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, > > Well, so be it. > >> 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. > > I think all can be changed to "Internet Protocol". > >> 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, ... >> --> > > I trust you that range-restricted is better English. ;-) > >> 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) >> --> > > OK > >> 29) <!-- [rfced] Please review the "Inclusive Language" portion of the >> online >> Style Guide >> <https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.rfc-editor.org%2Fstyleguide%2Fpart2%2F%23inclusive_language&data=05%7C02%7Cjschoenwaelder%40constructor.university%7C1add5c2ead7f422de6af08de316e8bf5%7Cf78e973e5c0b4ab8bbd79887c95a8ebd%7C0%7C0%7C639002548048097935%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=KORFkyanvUViFSGzy9aUi1xgYVU2lzlLJDX6xczEx5E%3D&reserved=0> >> 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. >> --> > > I hope that the text does not discriminate anyone. ;-) > >> 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://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.rfc-editor.org%2Ffaq%2F&data=05%7C02%7Cjschoenwaelder%40constructor.university%7C1add5c2ead7f422de6af08de316e8bf5%7Cf78e973e5c0b4ab8bbd79887c95a8ebd%7C0%7C0%7C639002548048116394%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=6UV0PPToXwz7DndqTXbQszE5NkNLuG6pNXe8V1AcbiY%3D&reserved=0). >> >> 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://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftrustee.ietf.org%2Flicense-info&data=05%7C02%7Cjschoenwaelder%40constructor.university%7C1add5c2ead7f422de6af08de316e8bf5%7Cf78e973e5c0b4ab8bbd79887c95a8ebd%7C0%7C0%7C639002548048140814%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=bYi%2Fe14jCkOv3FYNWPOXKTD542OT5G7OFfLwSx5Ct%2BM%3D&reserved=0). >> >> * 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://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fauthors.ietf.org%2Frfcxml-vocabulary&data=05%7C02%7Cjschoenwaelder%40constructor.university%7C1add5c2ead7f422de6af08de316e8bf5%7Cf78e973e5c0b4ab8bbd79887c95a8ebd%7C0%7C0%7C639002548048164128%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=SoFn%2F8K7Ye6WhGjFyQhp0VuGc671ooFw%2BtSsWlRrPoo%3D&reserved=0>. >> >> * 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://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmailarchive.ietf.org%2Farch%2Fmsg%2Fietf-announce%2Fyb6lpIGh-4Q9l2USxIAe6P8O4Zc&data=05%7C02%7Cjschoenwaelder%40constructor.university%7C1add5c2ead7f422de6af08de316e8bf5%7Cf78e973e5c0b4ab8bbd79887c95a8ebd%7C0%7C0%7C639002548048182670%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=Rwc2DFq%2B5Z8Uri8Xz81WWLBz0mzQ0AqW1sfyfe8WHfo%3D&reserved=0 >> >> * The archive itself: >> >> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmailarchive.ietf.org%2Farch%2Fbrowse%2Fauth48archive%2F&data=05%7C02%7Cjschoenwaelder%40constructor.university%7C1add5c2ead7f422de6af08de316e8bf5%7Cf78e973e5c0b4ab8bbd79887c95a8ebd%7C0%7C0%7C639002548048201420%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=sXz6XKH7%2FDMtjJa4j7HjaAJ8xbbXeZs2p266KqdqAjo%3D&reserved=0 >> >> * 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://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.rfc-editor.org%2Fauthors%2Frfc9911.xml&data=05%7C02%7Cjschoenwaelder%40constructor.university%7C1add5c2ead7f422de6af08de316e8bf5%7Cf78e973e5c0b4ab8bbd79887c95a8ebd%7C0%7C0%7C639002548048218365%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=qPOlx%2Fc%2BlrnJTzj65Cvrssm0Aj5fmt7alENbfeHY0ug%3D&reserved=0 >> >> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.rfc-editor.org%2Fauthors%2Frfc9911.html&data=05%7C02%7Cjschoenwaelder%40constructor.university%7C1add5c2ead7f422de6af08de316e8bf5%7Cf78e973e5c0b4ab8bbd79887c95a8ebd%7C0%7C0%7C639002548048234837%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=rTXqd2xPU8nmuS0vgEW0pipUFc8VlhxvCAnNyVDuYmw%3D&reserved=0 >> >> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.rfc-editor.org%2Fauthors%2Frfc9911.pdf&data=05%7C02%7Cjschoenwaelder%40constructor.university%7C1add5c2ead7f422de6af08de316e8bf5%7Cf78e973e5c0b4ab8bbd79887c95a8ebd%7C0%7C0%7C639002548048252147%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=Im%2BfgOu0wJF4%2BlDmE6aKn8dBZa8iM0iA2%2BMcicW%2F82o%3D&reserved=0 >> >> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.rfc-editor.org%2Fauthors%2Frfc9911.txt&data=05%7C02%7Cjschoenwaelder%40constructor.university%7C1add5c2ead7f422de6af08de316e8bf5%7Cf78e973e5c0b4ab8bbd79887c95a8ebd%7C0%7C0%7C639002548048269825%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=BP%2Fyn7pB%2BfKbZPO7fXC2RWoY05gV8f5Zzb8Veno%2F8C4%3D&reserved=0 >> >> Diff file of the text: >> >> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.rfc-editor.org%2Fauthors%2Frfc9911-diff.html&data=05%7C02%7Cjschoenwaelder%40constructor.university%7C1add5c2ead7f422de6af08de316e8bf5%7Cf78e973e5c0b4ab8bbd79887c95a8ebd%7C0%7C0%7C639002548048293680%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=OkICW1n%2FSmUJtVRQJyD0gNgAJ5NJAvTNXhrB7%2BP9yG4%3D&reserved=0 >> >> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.rfc-editor.org%2Fauthors%2Frfc9911-rfcdiff.html&data=05%7C02%7Cjschoenwaelder%40constructor.university%7C1add5c2ead7f422de6af08de316e8bf5%7Cf78e973e5c0b4ab8bbd79887c95a8ebd%7C0%7C0%7C639002548048321658%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=IG2wdEKOYvv2BDzwX739DLx58q90av3%2Bq5HOZ55RvUU%3D&reserved=0 >> (side by side) >> >> Diff of the XML: >> >> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.rfc-editor.org%2Fauthors%2Frfc9911-xmldiff1.html&data=05%7C02%7Cjschoenwaelder%40constructor.university%7C1add5c2ead7f422de6af08de316e8bf5%7Cf78e973e5c0b4ab8bbd79887c95a8ebd%7C0%7C0%7C639002548048350311%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=i60NLBWw9Yweo1LOqVjJWZgW2zB%2FdvHj6vXZi0O8Qco%3D&reserved=0 >> >> >> Tracking progress >> ----------------- >> >> The details of the AUTH48 status of your document are here: >> >> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.rfc-editor.org%2Fauth48%2Frfc9911&data=05%7C02%7Cjschoenwaelder%40constructor.university%7C1add5c2ead7f422de6af08de316e8bf5%7Cf78e973e5c0b4ab8bbd79887c95a8ebd%7C0%7C0%7C639002548048376477%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=h3vGSr2bbCtAwiKCoHyyymYuk0xxSA7%2FdNq09brxyDw%3D&reserved=0 >> >> 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 >> > > -- > Jürgen Schönwälder Constructor University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > -- auth48archive mailing list -- [email protected] To unsubscribe send an email to [email protected]
