Hi Rebecca, > On Dec 11, 2025, at 9:42 AM, Rebecca VanRheenen > <[email protected]> wrote: > > 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.
I approve leaving the Security Considerations section as is. Separately, there is a typedef for ‘ipv6-address-link-local’ that has a bug in it. Juergen has proposed an update. I approve of that change also. Thanks > > 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 >> > Mahesh Jethanandani [email protected]
-- auth48archive mailing list -- [email protected] To unsubscribe send an email to [email protected]
