Hi Mahesh, Thanks for the reply! We have noted your approval of the current Security Considerations and the bug fix on the AUTH48 status page for this document (see https://www.rfc-editor.org/auth48/rfc9911).
Best regards, Rebecca VanRheenen RFC Production Center > On Dec 16, 2025, at 11:30 AM, Mahesh Jethanandani <[email protected]> > wrote: > > 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]
