Hi Jürgen, Thank you for your reply. We are reviewing your responses to our questions and will get back to you shortly with updated files for review.
Best regards, Rebecca VanRheenen RPC 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]
