Hi Jürgen, all, One comment on this one:
> 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. FWIW, the "node" in the template was used because that text also covers groupings. For the specific context of this draft, it is completely fine that you make this change: OLD: The YANG module defines a set of types. These nodes are intended to be reused by other YANG modules. NEW: The YANG module defines a set of types. These types are intended to be reused by other YANG modules. Cheers, Med > -----Message d'origine----- > De : Jürgen Schönwälder <[email protected]> > Envoyé : dimanche 7 décembre 2025 14:47 > À : [email protected] > Cc : [email protected]; [email protected]; > [email protected]; [email protected]; auth48archive@rfc- > editor.org > Objet : Re: AUTH48: RFC-to-be 9911 <draft-ietf-netmod-rfc6991-bis- > 18> for your review > > > 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, rfc-editor@rfc- > editor.org 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://fra01.safelinks.protection.outlook.com/?url=https%3A%2F%2F > www. > > rfc- > editor.org%2Fsearch%2Frfc_search.php&data=05%7C02%7Cmohamed.boucad > > > air%40orange.com%7C6f5e655d62254bfe8cca08de35972ff9%7C90c7a20af34b > 40bf > > > bc48b9253b6f5d20%7C0%7C0%7C639007120628718376%7CUnknown%7CTWFpbGZs > b3d8 > > > eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIj > oiTW > > > FpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=E36m%2FNa65cIR8bEXqKNsiZ > AnvM > > xtDGTIyh7evdIFhqs%3D&reserved=0 --> > > 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://fra01.safelinks.protection.outlook.com/?url=https%3A%2F%2 > Fwww.iso.org%2Fstandard%2F70907.html&data=05%7C02%7Cmohamed.boucad > air%40orange.com%7C6f5e655d62254bfe8cca08de35972ff9%7C90c7a20af34b > 40bfbc48b9253b6f5d20%7C0%7C0%7C639007120628742040%7CUnknown%7CTWFp > bGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMi > IsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=BHgiUlrlHtWe > sqZkJJlVEumPe5LNcSKDKmvSnvjn%2Bec%3D&reserved=0>. > > [ISO8601:1988] > ISO, "Data elements and interchange formats -- > Information > interchange -- Representation of dates and times", > ISO 8601:1988, June 1988, > > <https://fra01.safelinks.protection.outlook.com/?url=https%3A%2F%2 > Fwww.iso.org%2Fstandard%2F15903.html&data=05%7C02%7Cmohamed.boucad > air%40orange.com%7C6f5e655d62254bfe8cca08de35972ff9%7C90c7a20af34b > 40bfbc48b9253b6f5d20%7C0%7C0%7C639007120628753734%7CUnknown%7CTWFp > bGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMi > IsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=6i%2B%2BAYDs > 37CcoXYicSH7sLZYPh6T0dwPIhj9jvsZR18%3D&reserved=0>. Also > available > from > <https://fra01.safelinks.protection.outlook.com/?url=https%3A%2F%2 > Fnvlpubs.nist.gov%2Fnistpubs%2FLegacy%2FFIPS%2F&data=05%7C02%7Cmoh > amed.boucadair%40orange.com%7C6f5e655d62254bfe8cca08de35972ff9%7C9 > 0c7a20af34b40bfbc48b9253b6f5d20%7C0%7C0%7C639007120628763127%7CUnk > nown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlA > iOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=v > JyXI38iqL8%2BMUsQP5ZMl3i%2FNnOfYt8SwzlZTBOxm7s%3D&reserved=0 > 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://fra01.safelinks.protection.outlook.com/?url=https%3A%2F%2 > Fwww.iso.org%2Fstandard%2F26780.html&data=05%7C02%7Cmohamed.boucad > air%40orange.com%7C6f5e655d62254bfe8cca08de35972ff9%7C90c7a20af34b > 40bfbc48b9253b6f5d20%7C0%7C0%7C639007120628772590%7CUnknown%7CTWFp > bGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMi > IsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=GmhJyvd6OzGJ > iv3d016LhMKSKPSPfE8%2FyK3xCoBmljg%3D&reserved=0>. > > 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://fra01.safelinks.protection.outlook.com/?url=https%3A%2F%2 > Fwww.iso.org%2Fstandard%2F26780.html&data=05%7C02%7Cmohamed.boucad > air%40orange.com%7C6f5e655d62254bfe8cca08de35972ff9%7C90c7a20af34b > 40bfbc48b9253b6f5d20%7C0%7C0%7C639007120628784274%7CUnknown%7CTWFp > bGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMi > IsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=RVwofAEl2eqF > j4OzMF9izV%2BqkQjoIwFa0KrYnZH2GSs%3D&reserved=0>. > > > 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://fra01.safelinks.protection.outlook.com/?url=https%3A%2F%2 > Fwww.iana.org%2F&data=05%7C02%7Cmohamed.boucadair%40orange.com%7C6 > f5e655d62254bfe8cca08de35972ff9%7C90c7a20af34b40bfbc48b9253b6f5d20 > %7C0%7C0%7C639007120628794812%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1h > cGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIl > dUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=3QlJ%2Bya7gzEAnOxB6ra4t2DAP24uBf > qgUglin83ncws%3D&reserved=0>. > > ... > > Protocol numbers are assigned by IANA. The current list of > > all assignments is available from > <https://fra01.safelinks.protection.outlook.com/?url=https%3A%2F%2 > Fwww.iana.org%2F&data=05%7C02%7Cmohamed.boucadair%40orange.com%7C6 > f5e655d62254bfe8cca08de35972ff9%7C90c7a20af34b40bfbc48b9253b6f5d20 > %7C0%7C0%7C639007120628804246%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1h > cGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIl > dUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=%2Fl4DUS%2B5cFjb%2F5Kk%2BgkgeD3T > sZuYd0cVLLsc6sr09o0%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://fra01.safelinks.protection.outlook.com/?url=https%3A%2F%2F > wiki.ietf.org%2Fgroup%2Fops%2Fyang-security- > guidelines&data=05%7C02%7Cmohamed.boucadair%40orange.com%7C6f5e655 > d62254bfe8cca08de35972ff9%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0%7 > C0%7C639007120628813703%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOn > RydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoy > fQ%3D%3D%7C0%7C%7C%7C&sdata=JkHwEMrwDjrIbfQ20cXLJsh8Vs5pNQ4YL8mQSO > VBpVE%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://fra01.safelinks.protection.outlook.com/?url=https%3A%2F%2F > www. > > > iso.org%2Fstandard%2F51424.html&data=05%7C02%7Cmohamed.boucadair%4 > 0ora > > > nge.com%7C6f5e655d62254bfe8cca08de35972ff9%7C90c7a20af34b40bfbc48b > 9253 > > > b6f5d20%7C0%7C0%7C639007120628823058%7CUnknown%7CTWFpbGZsb3d8eyJFb > XB0e > > > U1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCI > sIld > > > UIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=dYrFelNsmpoNqrbB%2BK1ZLWgQd6bx%2B > vs3a > > Rcr%2BtDPlUw%3D&reserved=0). It has been replaced by ISO/IEC > > 9834-1:2012 (see > https://fra01.safelinks.protection.outlook.com/?url=https%3A%2F%2F > www.iso.org%2Fstandard%2F58055.html&data=05%7C02%7Cmohamed.boucada > ir%40orange.com%7C6f5e655d62254bfe8cca08de35972ff9%7C90c7a20af34b4 > 0bfbc48b9253b6f5d20%7C0%7C0%7C639007120628831992%7CUnknown%7CTWFpb > GZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiI > sIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=i%2BmwCd6t5bX > 1oK1ltPWPLMsCOu7mdh8Fc6VozMX2cAw%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://fra01.safelinks.protection.outlook.com/?url=https%3A%2F%2 > Fiee > > > explore.ieee.org%2Fdocument%2F984782%2Fversions&data=05%7C02%7Cmoh > amed.boucadair%40orange.com%7C6f5e655d62254bfe8cca08de35972ff9%7C9 > 0c7a20af34b40bfbc48b9253b6f5d20%7C0%7C0%7C639007120628841058%7CUnk > nown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlA > iOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=z > QnpRatxq5zZn%2FuOINpUdzwYNvTcc7II1auwz3rjc1s%3D&reserved=0). The > new version is IEEE Std 802-2024 (see > https://fra01.safelinks.protection.outlook.com/?url=https%3A%2F%2F > ieeexplore.ieee.org%2Fdocument%2F10935844&data=05%7C02%7Cmohamed.b > oucadair%40orange.com%7C6f5e655d62254bfe8cca08de35972ff9%7C90c7a20 > af34b40bfbc48b9253b6f5d20%7C0%7C0%7C639007120628850117%7CUnknown%7 > CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXa > W4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=pJKPT0E > S8iffl8mK3hPps%2BzEgpwWhYKV3PFaiprBdyk%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://fra01.safelinks.protection.outlook.com/?url=https%3A%2F%2 > Fwww.rfc- > editor.org%2Fstyleguide%2Fpart2%2F%23inclusive_language&data=05%7C > 02%7Cmohamed.boucadair%40orange.com%7C6f5e655d62254bfe8cca08de3597 > 2ff9%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0%7C0%7C6390071206288594 > 72%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDA > wMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C > &sdata=mqhfFvpyACdBDZZyjgzq3xOAyhN%2Filxi3OnL6DmGI8E%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://fra01.safelinks.protection.outlook.com/?url=https%3A%2F%2 > Fwww.rfc- > editor.org%2Ffaq%2F&data=05%7C02%7Cmohamed.boucadair%40orange.com% > 7C6f5e655d62254bfe8cca08de35972ff9%7C90c7a20af34b40bfbc48b9253b6f5 > d20%7C0%7C0%7C639007120628868695%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0e > U1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCI > sIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=41HreGEhs10A4jzIR%2FylKZfxTZX > 2IJg9z%2FPKz20fpfk%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://fra01.safelinks.protection.outlook.com/?url=https%3A%2F%2F > trustee.ietf.org%2Flicense- > info&data=05%7C02%7Cmohamed.boucadair%40orange.com%7C6f5e655d62254 > bfe8cca08de35972ff9%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0%7C0%7C6 > 39007120628877741%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUs > IlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D% > 3D%7C0%7C%7C%7C&sdata=ZNHxM15HDoqNxA%2BUMJ%2FgEOQF7FPS%2F8M%2BUBPl > 5c0GZIY%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://fra01.safelinks.protection.outlook.com/?url=https%3A%2F%2 > Fauthors.ietf.org%2Frfcxml- > vocabulary&data=05%7C02%7Cmohamed.boucadair%40orange.com%7C6f5e655 > d62254bfe8cca08de35972ff9%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0%7 > C0%7C639007120628886988%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOn > RydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoy > fQ%3D%3D%7C0%7C%7C%7C&sdata=%2FkgZOOVAEsWtCydkI9NUCJ3dndNoG%2FDJlE > WcO6XhTQY%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://fra01.safelinks.protection.outlook.com/?url=https%3A%2F%2F > mailarchive.ietf.org%2Farch%2Fmsg%2Fietf-announce%2Fyb6lpIGh- > 4Q9l2USxIAe6P8O4Zc&data=05%7C02%7Cmohamed.boucadair%40orange.com%7 > C6f5e655d62254bfe8cca08de35972ff9%7C90c7a20af34b40bfbc48b9253b6f5d > 20%7C0%7C0%7C639007120628896526%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU > 1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIs > IldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=udlea1%2F6kuPMywEC1erqv41QTmL% > 2FT0rIISytDP%2B1xdg%3D&reserved=0 > > > > * The archive itself: > > > https://fra01.safelinks.protection.outlook.com/?url=https%3A%2F%2F > mailarchive.ietf.org%2Farch%2Fbrowse%2Fauth48archive%2F&data=05%7C > 02%7Cmohamed.boucadair%40orange.com%7C6f5e655d62254bfe8cca08de3597 > 2ff9%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0%7C0%7C6390071206289059 > 78%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDA > wMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C > &sdata=%2BTP98q1zVUHPlAyNZaMnEksscBpoXcD2W2G5fb8tZXQ%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://fra01.safelinks.protection.outlook.com/?url=https%3A%2F%2F > www.rfc- > editor.org%2Fauthors%2Frfc9911.xml&data=05%7C02%7Cmohamed.boucadai > r%40orange.com%7C6f5e655d62254bfe8cca08de35972ff9%7C90c7a20af34b40 > bfbc48b9253b6f5d20%7C0%7C0%7C639007120628915195%7CUnknown%7CTWFpbG > Zsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIs > IkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=yHJz3VV1Tc1rKP > 2FXzTMzouBSDq4fqmIJbLFNDmcd5U%3D&reserved=0 > > > https://fra01.safelinks.protection.outlook.com/?url=https%3A%2F%2F > www.rfc- > editor.org%2Fauthors%2Frfc9911.html&data=05%7C02%7Cmohamed.boucada > ir%40orange.com%7C6f5e655d62254bfe8cca08de35972ff9%7C90c7a20af34b4 > 0bfbc48b9253b6f5d20%7C0%7C0%7C639007120628924438%7CUnknown%7CTWFpb > GZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiI > sIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=WtHyOpoKP9JVi > nM2DBXBHTTJwfB78jzRHot9%2Fsutc%2FU%3D&reserved=0 > > > https://fra01.safelinks.protection.outlook.com/?url=https%3A%2F%2F > www.rfc- > editor.org%2Fauthors%2Frfc9911.pdf&data=05%7C02%7Cmohamed.boucadai > r%40orange.com%7C6f5e655d62254bfe8cca08de35972ff9%7C90c7a20af34b40 > bfbc48b9253b6f5d20%7C0%7C0%7C639007120628934902%7CUnknown%7CTWFpbG > Zsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIs > IkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=R7mYpVOzrR6Pfu > obQIXTBggbOrKnpHGZ99Ij0lRnGgA%3D&reserved=0 > > > https://fra01.safelinks.protection.outlook.com/?url=https%3A%2F%2F > www.rfc- > editor.org%2Fauthors%2Frfc9911.txt&data=05%7C02%7Cmohamed.boucadai > r%40orange.com%7C6f5e655d62254bfe8cca08de35972ff9%7C90c7a20af34b40 > bfbc48b9253b6f5d20%7C0%7C0%7C639007120628947161%7CUnknown%7CTWFpbG > Zsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIs > IkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=Yk7nNRnEQU93Bt > 7B6J2gJIYCOCNoFIWapgPc0kceceM%3D&reserved=0 > > > > Diff file of the text: > > > https://fra01.safelinks.protection.outlook.com/?url=https%3A%2F%2F > www.rfc-editor.org%2Fauthors%2Frfc9911- > diff.html&data=05%7C02%7Cmohamed.boucadair%40orange.com%7C6f5e655d > 62254bfe8cca08de35972ff9%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0%7C > 0%7C639007120628957450%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnR > ydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyf > Q%3D%3D%7C0%7C%7C%7C&sdata=KATpDJxtain%2FhZ%2B3h8VBTY6DRHtnCAeWdT% > 2FfAb3Qxcc%3D&reserved=0 > > > https://fra01.safelinks.protection.outlook.com/?url=https%3A%2F%2F > www.rfc-editor.org%2Fauthors%2Frfc9911- > rfcdiff.html&data=05%7C02%7Cmohamed.boucadair%40orange.com%7C6f5e6 > 55d62254bfe8cca08de35972ff9%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0 > %7C0%7C639007120628967474%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGki > OnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIj > oyfQ%3D%3D%7C0%7C%7C%7C&sdata=cn4oAeJJL%2BFGUXMKrIAi6w8lGBTr%2B3BG > 7y4%2BChEW1yo%3D&reserved=0 (side by side) > > > > Diff of the XML: > > > https://fra01.safelinks.protection.outlook.com/?url=https%3A%2F%2F > www.rfc-editor.org%2Fauthors%2Frfc9911- > xmldiff1.html&data=05%7C02%7Cmohamed.boucadair%40orange.com%7C6f5e > 655d62254bfe8cca08de35972ff9%7C90c7a20af34b40bfbc48b9253b6f5d20%7C > 0%7C0%7C639007120628977925%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGk > iOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUI > joyfQ%3D%3D%7C0%7C%7C%7C&sdata=z%2BNP8R2d%2FuToF1%2Bf4N6sKL7%2B116 > b196dX%2BI2Pcb1aKU%3D&reserved=0 > > > > > > Tracking progress > > ----------------- > > > > The details of the AUTH48 status of your document are here: > > > https://fra01.safelinks.protection.outlook.com/?url=https%3A%2F%2F > www.rfc- > editor.org%2Fauth48%2Frfc9911&data=05%7C02%7Cmohamed.boucadair%40o > range.com%7C6f5e655d62254bfe8cca08de35972ff9%7C90c7a20af34b40bfbc4 > 8b9253b6f5d20%7C0%7C0%7C639007120628987793%7CUnknown%7CTWFpbGZsb3d > 8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOI > joiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=m0%2BiaIfVDWcUbt%2B > 1iYkSspLzcwbiLKbGYXTqUADzwlY%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 ____________________________________________________________________________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged information that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and delete this message and its attachments. As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified. Thank you. -- auth48archive mailing list -- [email protected] To unsubscribe send an email to [email protected]
