Hi Megan, all,
Thanks for implementing the changes. Please find below some comments about some
of the changes:
# Now that the note is moved to be embedded in the template, the formatting
need to be clear to avoid copy/paste issues
CURRENT:
Note: RFC 8341 (or a future RFC that replaces it) MUST be listed
as a normative reference.
By default, RFC 4252, RFC 6241, RFC 8040, RFC 8446, RFC 9000, and
RFC 9907 (or future RFCs that replace any of them) are listed as
informative references unless normatively cited in other sections
of the document that specifies the YANG module.
NEW:
-- Note: RFC 8341 (or a future RFC that replaces it) MUST be listed
-- as a normative reference.
-- By default, RFC 4252, RFC 6241, RFC 8040, RFC 8446, RFC 9000, and
-- RFC 9907 (or future RFCs that replace any of them) are listed as
-- informative references unless normatively cited in other sections
-- of the document that specifies the YANG module.
# This change should be reverted back (two occurrences)
CURRENT:
revision 2013-07-15 {
description
"This revision adds the following new data types:
- yang:yang-identifier
- yang:hex-string
- yang:uuid
- yang:dotted-quad";
reference
"RFC 9911: Common YANG Data Types";
}
NEW:
revision 2013-07-15 {
description
"This revision adds the following new data types:
- yang:yang-identifier
- yang:hex-string
- yang:uuid
- yang:dotted-quad";
reference
"RFC 6991: Common YANG Data Types";
}
# The link that replaced the ref should include a revision
CURRENT:
Whenever referencing a specific version of an IANA-maintained YANG
module is needed, then URLs such as the following are used:
* https://www.iana.org/assignments/iana-bgp-l2-encaps
NEW:
Whenever referencing a specific version of an IANA-maintained YANG
module is needed, then URLs such as the following are used:
*
https://www.iana.org/assignments/yang-parameters/[email protected]
# Please update this title to match the reco in draft-ietf-opsawg-rfc5706bis
OLD: 6. Operations and Manageability Considerations
NEW: 6. Operational Considerations
Please see inline.
Cheers,
Med
> -----Message d'origine-----
> De : Megan Ferguson <[email protected]>
> Envoyé : vendredi 16 janvier 2026 03:43
> À : BOUCADAIR Mohamed INNOV/NET <[email protected]>;
> [email protected]
> Cc : [email protected]; [email protected];
> [email protected]; [email protected]; [email protected];
> [email protected]; [email protected]
> Objet : Re: [AD] AUTH48: RFC-to-be 9907 <draft-ietf-netmod-
> rfc8407bis-28> for your review
>
>
> Hi Med (and *AD),
>
> [*AD - please review and approve the addition of text to Section
> 3.9, the update to the example in Section 4.8, and the revisions
> to the template in Appendix B]
>
> Thank you for your detailed reply and guidance! We now have
> things narrowed down to a few follow up questions (see questions
> 1-7 below).
>
> We have been through both of your emails and made updates to the
> file accordingly (see links below).
>
> Note that we have also recorded Andy's approval at the AUTH48
> status page (see link below).
>
> Questions:
>
> 1) You mentioned questions 16(c)ii and 16(c)iii will require
> updates at the wiki page:
> >>
> >> ii) Numbering and textual differences:
> >>
> >> This document:
> >> These YANG-based management protocols (1) have to use a secure
> >> transport layer (e.g., SSH [RFC4252], TLS [RFC8446], and QUIC
> >> [RFC9000]) and (2) have to use mutual authentication.
> >>
> >> The wiki:
> >> These protocols have to use a secure transport layer (e.g., SSH
> >> [RFC4252], TLS [RFC8446], and QUIC [RFC9000]) and have to use
> mutual
> >> authentication.
> >
> > [Med] The wiki should be updated to use the version in the
> draft.
> >
> >>
> >> iii) Use of "reasonably":
> >>
> >> This document:
> >> All writable data nodes are likely to be sensitive or
> vulnerable in
> >> some network environments.
> >>
> >> The wiki:
> >> All writable data nodes are likely to be reasonably sensitive
> or
> >> vulnerable in some network environments.
> >>
> >
> > [Med] The wiki should be updated to use the version in the
> draft.
>
>
> We have noted this update on the AUTH48 status page and will
> verify the page matches the document prior to publication.
>
[Med] Thanks
>
> 2) You mentioned the following regarding questions 17(a) and
> 17(b):
>
> >> 17) <!--[rfced] Regarding the use of code markers:
> >>
> >> a) Please consider whether you want the <CODE BEGINS> and <CODE
> ENDS>
> >> markers to be added to any snippets in this document (i.e., if
> you
> >> want to add markers="true" to the sourcecode elements).
> >>
> >> We note Section 3.2.1 contains the following, but how it should
> be
> >> applied within this document is not clear:
> >> Example modules are not code components. The <CODE BEGINS>
> >> convention MUST NOT be used for example modules. However,
> example
> >> modules MUST be validated (Section 3.10).
> >>
> >> b) In contrast, regarding your note (about Section 3.7.1):
> >> * Added code markers for the security template.
> >>
> >> Why are the code markers being used for the security
> considerations
> >> template? It seems odd because it is prose, not code.
> >
> > [Med] This one was requested by the trust....
> >
> >>
> >> c) Similarly, why are code markers used for the templates in
> Sections
> >> 4.30.3.1 and 4.30.3.2?
> >
> > [Med] For the same reasons as above.
>
> Might it be possible to update to <BEGIN TEMPLATE TEXT> and <END
> TEMPLATE TEXT> instead? Additionally, should the following
> paragraph from the TLP should be included?
>
> From ...
>
> Section 9. Template Text
> a. Certain RFCs may contain text designated as "Template Text" by
> the inclusion of the following legend in the introduction to the
> RFC:
>
> "This RFC contains text intended for use as a template as
> designated below by the markers <BEGIN TEMPLATE TEXT> and <END
> TEMPLATE TEXT> or other clear designation. Such Template Text is
> subject to the provisions of Section 9(b) of the Trust Legal
> Provisions."
>
[Med] Works for me. Thanks
>
>
> 3) Regarding the reply to question 28(c):
>
>
> >> c) We note that templates in this document use a mix of filler
> >> numbers for RFCs (e.g., RFC IIII, RFC XXXX, FFFF). We suggest
> >> updating to use RFC XXXX throughout. Please let us know any
> >> objections.
> >
> > [Med] I need to check the full text as there are cases where
> using
> > XXXX does not work. For example,
> >
> > OLD:
> > revision date-initial {
> > description
> > "Initial version"; version.";
> > reference
> > "RFC YYYY: <Replace With Document Title>";
> >
> > CURRENT:
> > revision date-initial {
> > description
> > "Initial version"; version.";
> > reference
> > "RFC XXXX: <Replace With Document Title>";
> >
> > XXXX is referring to the RFC that first defined the modules,
> while YYYY is the RFC that defines an update.
> >
> > IIII is used per the convention in the terminology section:
> >
> > RFC IIII is used to refer to an RFC that defines an initial
> version
> > of an IANA-maintained module.
> >
> > BTW,
> >
> > OLD: "RFC YYYY: Common YANG Data Types";
> > CURRENT: "RFC 6991: Common YANG Data Types";
> >
> > Please change that one to
> >
> > NEW: "RFC 9911: Common YANG Data Types";
>
> We did see one update in your other email to use IIII. Please
> review and let us know if any further changes are necessary or if
> we can close this query out.
[Med] I think that we can close this one.
>
> 4) For 28d:
>
> >> d) Please review the use of module/model when it appears
> without YANG
> >> and confirm that these instances appear as intended.
> >
> > [Med] Will review that separately.
>
> Please let us know if any further changes are necessary once you
> complete your review.
[Med] We can update all "model" occurrences in the bullet list of 4.23.3 to
"module".
Also, make a similar change in 4.23.3.1 for two occurrences.
>
> 5) 28(e) and 28(f) ask about quotation around terms:
>
> >> e) We note that there may be some inconsistency in the double
> quotes
> >> around statement names. For example, these terms are not
> quoted at
> >> places in the text:
> >>
> >> import statement
> >> include statement
> >> normative reference statement
> >> XPath statement
> >> extension statement
> >> YANG statement
> >> YANG extension statement
> >> YANG conditional statement
> >> reference statement
> >> length statement
> >> module tag extension statement
> >
> > [Med] Please follow the same convention as in RFC8407 for these.
>
> Unfortunately, RFC 8407 has some inconsistencies here. A number
> of the items in the list above appear in both quotes and unquoted,
> with the latter being more prevalent. Other statement names like
> "description" and "revision" statement are majority quoted.
> Please let us know if one of the following options should be
> implemented:
> a) double quote all statement (and substatement?) names
[Med] We can double quote all statements for internal consistency then and also
with RFC7950.
Here is my proposal:
"import" statement
"include" statement
normative "reference" statement
"XPath" statement
"extension" statement
YANG statement
YANG "extension" statement
YANG conditional statement
"reference" statement
"length" statement
module-tag "extension" statement
> b) unquote all statement (and substatement?) names
> c) leave these untouched (better to match RFC 8407 than be
> consistent)
>
>
> >> NOTE 1: We have added some quotes to "revision" statement.
> Please
> >> review and confirm these changes.
> >
> > [Med] ACK
> >
> >>
> >> NOTE 2: We see that the quotes around require-instance
> statement were
> >> removed between RFC 8407 and this document. Please review and
> >> confirm this update is as intended.
> >
> > [Med] Can you please indicate which one? I don't see these in my
> diff.
>
> Please ignore - this is a misread.
[Med] Thanks.
> >
> >>
> >> NOTE 3: We sometimes see the use of YANG statement. Should
> these
> >> simply be statement?
[Med] We can leave these unchanged.
> >>
> >> "when" statement vs. "when" YANG statement "must" statement vs.
> >> "must" YANG statement
> >
> > [Med] These are inherited from 8407. We can leave these as is.
> >
> >>
> >> f) Further, there are some similar terms that may benefit from
> >> quotation review. We see:
> >>
> >> when expression vs. "when" expression must expression vs.
> "must"
> >> expression
>
> [rfced] Note also that we see "when" statement and "must"
> statement. Should these be updated to expression?
[Med] statement is actually more compliant with RFC7950.
Note that we
> updated to use "when" and "must" (with quotes) to match the
> majority use in RFC 8407.
>
[Med] Thanks.
> >> "enumeration" data type vs. enumeration data type vs.
> enumeration
>
> [rfced] Use in RFC 8407 was inconsistent. We have updated to use
> quotes where we felt appropriate.
[Med] ACK
>
> >> typedefs
> >> present vs. "not present"
>
> [rfced] We have left "not present" quoted to match RFC 8407.
[Med] ACK.
>
> >> anyxml vs. "anyxml"
> >> descendant data nodes vs. "descendant" axis
>
> [rfced] For anyxml and descendant, we have left instances of these
> data node names unquoted to match 8407. Note, however, we see
> "config false" data nodes.so RFC 8407 doesn't seem to be
> consistent on quoting names of data nodes.
>
> >> user-ordered list vs. user-ordered "list"
> >> leaf-list vs. "leaf-list"
>
> [rfced] For the above two related to lists, we have removed the
> quotation marks from one sentence as other instances in RFC 8407
> seemed to not use quotation marks.
>
> >> false vs. "false"
> >> true vs. "true"
>
> [rfced] Instance where these terms appear to be values have been
> quoted (which matches RFC 8407).
[Med] ACK
>
> >> "deprecated" vs. "status deprecated"
>
> [rfced] We have added quotation marks where these appears to be a
> setting. Please advise if any changes from simply "deprecated" to
> instead say "status deprecated" are desired.
[Med] The 2 uses in the doc are OK. However, when re-reading:
CURRENT:
The "/interfaces-state" hierarchy has
been marked "status deprecated". Models that mark their "/foo-
state" hierarchy with "status deprecated" will allow NMDA-
I wonder whether:
OLD: been marked "status deprecated".
NEW: been marked with "status deprecated".
>
> > [Med] Please use the same convention as in RFC8407 if possible.
> If not, I have a preference for the "word" variant. Thanks.
>
> 6) We did not see a reply to questions 29(b) and 29(c). Please
> let us know if any action is necessary on these items:
>
> >> b) Please review the use of quotation marks (both single quotes
> and
> >> double quotes) with these terms; specifically, should they be
> moved
> >> to outside the <tt> tag?
> >>
> >> For example, we see both:
> >>
> >> <tt>"<CODE BEGINS>"</tt> tag
> >>
> >> and
> >>
> >> <tt><CODE BEGINS></tt> convention
> >>
> >> c) Please review to ensure the usage of <tt> is consistent. It
> >> appears that there may be varying treatment of these terms.
>
[Med] Please use a consistent approach for all similar matters.
> 7) We saw your communication with IANA on January 12. Please let
> us know if any changes to the document are requested based on that
> discussion (we don't believe so, but please confirm).
>
> Please review our updates to these files carefully as we do not
> make changes once the document is published as an RFC.
>
> The files have been posted here:
>
> https://fra01.safelinks.protection.outlook.com/?url=https%3A%2F%2F
> www.rfc-
> editor.org%2Fauthors%2Frfc9907.txt&data=05%7C02%7Cmohamed.boucadai
> r%40orange.com%7Cd66b9dc3e92547af271108de54a90726%7C90c7a20af34b40
> bfbc48b9253b6f5d20%7C0%7C0%7C639041285260498342%7CUnknown%7CTWFpbG
> Zsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIs
> IkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C40000%7C%7C%7C&sdata=HZhP0VWMJ%
> 2Fnm5qYPjI5JvVZt%2BVzB4T%2B%2Bg%2BC2wI8P0g8%3D&reserved=0
>
> https://fra01.safelinks.protection.outlook.com/?url=https%3A%2F%2F
> www.rfc-
> editor.org%2Fauthors%2Frfc9907.pdf&data=05%7C02%7Cmohamed.boucadai
> r%40orange.com%7Cd66b9dc3e92547af271108de54a90726%7C90c7a20af34b40
> bfbc48b9253b6f5d20%7C0%7C0%7C639041285260508143%7CUnknown%7CTWFpbG
> Zsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIs
> IkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C40000%7C%7C%7C&sdata=pr4idBGA3d
> Y9U%2FJIsIXuWGWJNeBZVw5fFun0ssqRfP4%3D&reserved=0
>
> https://fra01.safelinks.protection.outlook.com/?url=https%3A%2F%2F
> www.rfc-
> editor.org%2Fauthors%2Frfc9907.html&data=05%7C02%7Cmohamed.boucada
> ir%40orange.com%7Cd66b9dc3e92547af271108de54a90726%7C90c7a20af34b4
> 0bfbc48b9253b6f5d20%7C0%7C0%7C639041285260517436%7CUnknown%7CTWFpb
> GZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiI
> sIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C40000%7C%7C%7C&sdata=MyDPrtxs5
> sPehWV1gne%2BVgM%2BY5NDptS5vPndDHQNkEU%3D&reserved=0
>
> https://fra01.safelinks.protection.outlook.com/?url=https%3A%2F%2F
> www.rfc-
> editor.org%2Fauthors%2Frfc9907.xml&data=05%7C02%7Cmohamed.boucadai
> r%40orange.com%7Cd66b9dc3e92547af271108de54a90726%7C90c7a20af34b40
> bfbc48b9253b6f5d20%7C0%7C0%7C639041285260526913%7CUnknown%7CTWFpbG
> Zsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIs
> IkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C40000%7C%7C%7C&sdata=e7gLhjSWQm
> sD26rfK81sF3QRZjcxNBryISXp20N60RI%3D&reserved=0
>
> The relevant diff files have been posted here:
>
> https://fra01.safelinks.protection.outlook.com/?url=https%3A%2F%2F
> www.rfc-editor.org%2Fauthors%2Frfc9907-
> diff.html&data=05%7C02%7Cmohamed.boucadair%40orange.com%7Cd66b9dc3
> e92547af271108de54a90726%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0%7C
> 0%7C639041285260536650%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnR
> ydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyf
> Q%3D%3D%7C40000%7C%7C%7C&sdata=K03JzuMBSejqwWudNvkuknSFdG%2F9F0m3U
> DWJRF4iNOU%3D&reserved=0 (comprehensive)
>
> https://fra01.safelinks.protection.outlook.com/?url=https%3A%2F%2F
> www.rfc-editor.org%2Fauthors%2Frfc9907-
> rfcdiff.html&data=05%7C02%7Cmohamed.boucadair%40orange.com%7Cd66b9
> dc3e92547af271108de54a90726%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0
> %7C0%7C639041285260546852%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGki
> OnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIj
> oyfQ%3D%3D%7C40000%7C%7C%7C&sdata=DGFvP8btn6dJhJfOIdmB%2B610aQD07T
> 7SkqZPo1811mo%3D&reserved=0 (comprehensive side by side)
>
> https://fra01.safelinks.protection.outlook.com/?url=https%3A%2F%2F
> www.rfc-editor.org%2Fauthors%2Frfc9907-
> auth48diff.html&data=05%7C02%7Cmohamed.boucadair%40orange.com%7Cd6
> 6b9dc3e92547af271108de54a90726%7C90c7a20af34b40bfbc48b9253b6f5d20%
> 7C0%7C0%7C639041285260556912%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hc
> GkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIld
> UIjoyfQ%3D%3D%7C40000%7C%7C%7C&sdata=SRPJHN4u5iI8%2B9gRfEEmcD5h8V%
> 2FFC4DrLPojtNYmc3c%3D&reserved=0 (AUTH48 changes only)
>
> https://fra01.safelinks.protection.outlook.com/?url=https%3A%2F%2F
> www.rfc-editor.org%2Fauthors%2Frfc9907-
> auth48rfcdiff.html&data=05%7C02%7Cmohamed.boucadair%40orange.com%7
> Cd66b9dc3e92547af271108de54a90726%7C90c7a20af34b40bfbc48b9253b6f5d
> 20%7C0%7C0%7C639041285260565792%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU
> 1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIs
> IldUIjoyfQ%3D%3D%7C40000%7C%7C%7C&sdata=POLaJc%2FsfODi%2FXUZ9hbA6v
> mNtxts%2BmNx58FcPv1%2FFK0%3D&reserved=0 (AUTH48 side by side)
>
> Please contact us with any further updates/questions/comments you
> may have.
>
> We will await approvals from each of the parties listed on the
> AUTH48 status page prior to moving forward to publication.
>
> The AUTH48 status page for this document is available here:
>
> https://fra01.safelinks.protection.outlook.com/?url=https%3A%2F%2F
> www.rfc-
> editor.org%2Fauth48%2Frfcxxxx&data=05%7C02%7Cmohamed.boucadair%40o
> range.com%7Cd66b9dc3e92547af271108de54a90726%7C90c7a20af34b40bfbc4
> 8b9253b6f5d20%7C0%7C0%7C639041285260575452%7CUnknown%7CTWFpbGZsb3d
> 8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOI
> joiTWFpbCIsIldUIjoyfQ%3D%3D%7C40000%7C%7C%7C&sdata=wXJZwLmQIuVT6w6
> bz%2F5nSQ9OHe%2BAMwsHMv0vXymXqw0%3D&reserved=0
>
> Thank you.
>
> Megan Ferguson
> RFC Production Center
>
>
> > On Jan 9, 2026, at 6:33 AM, [email protected] wrote:
> >
> > Re-,
> >
> > Please find below some comments about the edited version:
> >
> > # Section 3.8.3.2/5.1
> >
> > As we are adding a new registration to a new one, we need to
> also cite RFC9890:
> >
> > OLD:
> > IANA is requested to register the following YANG module in the
> "YANG
> > Module Names" registry [RFC6020] within the "YANG Parameters"
> > registry group.
> >
> > NEW:
> > IANA is requested to register the following YANG module in the
> "YANG
> > Module Names" registry [RFC6020][RFC9890] within the "YANG
> Parameters"
> > registry group.
> >
> > + list RFC9890 as normative.
> >
> > + update Section 5.1 as follows:
> >
> > OLD:
> > IANA has registered the following YANG modules in the "YANG
> Module
> > Names" registry [RFC6020] within the "YANG Parameters"
> registry
> > group.
> >
> > NEW:
> > IANA has registered the following YANG modules in the "YANG
> Module
> > Names" registry [RFC6020] [RFC9890] within the "YANG
> Parameters" registry
> > group.
> >
> >
> > # Section 3.12
> >
> > Some examples may be provided to illustrate malformed data
> instances. Such examples are not required to be validated.
> >
> > Please make this change:
> >
> > OLD:
> > Examples MUST be validated (Section 3.10).
> >
> > NEW:
> > Examples that are meant to illustrate valid data instance MUST
> be validated (Section 3.10).
> >
> > # Section 4.8
> >
> > The original text uses YYYY which was 6991bis draft. I suggest
> we make this change to mirror 9911:
> >
> > OLD:
> > revision 2023-01-23 {
> > description
> > "This revision adds the following new data types:
> > - yang:date-with-zone-offset
> > - yang:date-no-zone
> > - yang:time-with-zone-offset
> > - yang:time-no-zone
> > - yang:hours32
> > - yang:minutes32
> > - yang:seconds32
> > - yang:centiseconds32
> > - yang:milliseconds32
> > - yang:microseconds32
> > - yang:microseconds64
> > - yang:nanoseconds32
> > - yang:nanoseconds64
> > - yang:language-tag
> > The yang-identifier definition has been aligned with
> YANG 1.1.
> > Several pattern statements have been improved.";
> > reference
> > "RFC 6991: Common YANG Data Types";
> > }
> >
> > NEW:
> > revision 2025-12-22 {
> > description
> > "This revision adds the following new data types:
> > - yang:date
> > - yang:date-no-zone
> > - yang:time
> > - yang:time-no-zone
> > - yang:hours32
> > - yang:minutes32
> > - yang:seconds32
> > - yang:centiseconds32
> > - yang:milliseconds32
> > - yang:microseconds32
> > - yang:microseconds64
> > - yang:nanoseconds32
> > - yang:nanoseconds64
> > - yang:language-tag
> > The yang-identifier definition has been aligned with YANG
> > 1.1, and types representing time support the
> representation
> > of leap seconds. The representation of time zone offsets
> > has been aligned with RFC 9557. Several description and
> > pattern statements have been improved.";
> > reference
> > "RFC 9911: Common YANG Data Types"; }
> >
> > # Section 4.28
> >
> > Please revert to the OLD as this is consistent with the
> terminology used out there:
> >
> > CURRENT:
> > [RFC8819] specifies a method for associating tags with YANG
> modules.
> > Tags may be defined and associated at the time of module
> design, at
> > the time of implementation, or via user administrative
> control.
> >
> > NEW:
> > [RFC8819] specifies a method for associating tags with YANG
> modules.
> > Tags may be defined and associated at design time, at
> > implementation time, or via user administrative control.
> >
> > # Section 4.30.2
> >
> > Address a comment we received from Dhruv about the clarity of a
> statement:
> >
> > OLD:
> > An IANA-maintained module may use the "identityref" data type
> (e.g.,
> > [RFC8675]) or an enumeration data type (e.g., [RFC9108]).
> >
> > NEW:
> > An IANA-maintained module may use the "identityref" data type
> approach (e.g.,
> > [RFC8675]) or an enumeration data type approach (e.g.,
> [RFC9108]).
> >
> > # Section 4.30.3
> >
> > CURREN (2 occurrences):
> > description
> > "IPsec tunnel mode encapsulation.";
> >
> > Unless you IANA update the registry, I suggest to revert the
> change as that is correct.
> >
> > FWIW, the registry
> (https://fra01.safelinks.protection.outlook.com/?url=https%3A%2F%2
> Fwww.iana.org%2Fassignments%2Fianaiftype-mib%2Fianaiftype-
> mib&data=05%7C02%7Cmohamed.boucadair%40orange.com%7Cd66b9dc3e92547
> af271108de54a90726%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0%7C0%7C63
> 9041285260587805%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsI
> lYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3
> D%7C40000%7C%7C%7C&sdata=Erc%2FCDMwsYin1sjdE4bRmsFopkjWcm8YP8ObFS3
> 22dw%3D&reserved=0) says:
> >
> > ipsectunnelmode(19) -- IpSec tunnel mode encapsulation
> >
> > # Appendix B
> >
> > ## address a comment received from Kent + use https
> >
> > OLD:
> > "WG Web:
> <https://fra01.safelinks.protection.outlook.com/?url=http%3A%2F%2F
> datatracker.ietf.org%2Fwg%2Fyour-wg-
> name%2F&data=05%7C02%7Cmohamed.boucadair%40orange.com%7Cd66b9dc3e9
> 2547af271108de54a90726%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0%7C0%
> 7C639041285260600547%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRyd
> WUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%
> 3D%3D%7C40000%7C%7C%7C&sdata=mgkAl1JvtzY37s13oxVByG4I4pcnsiiPlVojT
> G8MU4M%3D&reserved=0>
> > WG List: <mailto:[email protected]>
> >
> > NEW:
> > "WG Web:
> https://fra01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fd
> atatracker.ietf.org%2Fwg%2Fyour-wg-
> name&data=05%7C02%7Cmohamed.boucadair%40orange.com%7Cd66b9dc3e9254
> 7af271108de54a90726%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0%7C0%7C6
> 39041285260611122%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUs
> IlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%
> 3D%7C40000%7C%7C%7C&sdata=x9TiwmQuDMDWSbqqgk%2BQZzoSB6Kv%2F0cGM5VW
> 1Iehs7E%3D&reserved=0
> > WG List: YOUR-WG-NAME <mailto:[email protected]>
> >
> >
> > ## instruction clarity
> >
> > OLD:
> > // RFC Ed.: replace XXXX with actual RFC number and remove
> > // this note
> >
> > // replace 'date-revision' with the module publication date
> > // the format is (YYYY-MM-DD)
> >
> > revision date-revision {
> > description
> > "What changed in this revision.";
> > reference
> > "RFC XXXX: <Replace With Document Title>";
> > }
> >
> > // RFC Ed.: Update with the RFC number and title
> > // of the RFC that defined the initial version of
> > // the module and remove this note
> >
> > revision date-initial {
> > description
> > "Initial version"; version.";
> > reference
> > "RFC YYYY: XXXX: <Replace With Document Title>";
> > }
> >
> > NEW:
> > // replace 'date-revision' with the module publication date
> > // the format is (YYYY-MM-DD)
> >
> > // RFC Ed.: replace XXXX with actual RFC number and remove
> > // this note
> >
> > revision date-revision {
> > description
> > "What changed in this revision.";
> > reference
> > "RFC XXXX: <Replace With Document Title>";
> > }
> >
> > // Authors: Update with the RFC number and title
> > // of the RFC that defined the initial version of
> > // the module and remove this note
> >
> > revision date-initial {
> > description
> > "Initial version"; version.";
> > reference
> > "RFC IIII: <Replace With Document Title>";
> > }
> >
> > # Appendix C
> >
> > I received a comment from Dhruv that the tel. number is to be
> checked
> >
> > CURRENT:
> > Tel: +1 424 254 5300
> >
> > Should that be updated to:
> >
> > NEW:
> > Tel: +1 310 301 5800
> >
> > I will re-review the full text once all the pending points are
> implemented.
> >
> > Thank you.
> >
> > Cheers,
> > Med
> >
> >> -----Message d'origine-----
> >> De : [email protected] <[email protected]>
> Envoyé :
> >> vendredi 9 janvier 2026 07:40 À : [email protected]; BOUCADAIR
> >> Mohamed INNOV/NET <[email protected]>;
> [email protected]
> >> Cc : [email protected]; [email protected]; netmod-
> >> [email protected]; [email protected];
> [email protected];
> >> [email protected] Objet : AUTH48: RFC-to-be 9907
> >> <draft-ietf-netmod-rfc8407bis-28> for your review
> >>
> >>
> >> *****IMPORTANT*****
> >>
> >> Updated 2026/01/08
> >>
> >> 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%
> >>
> 7C996760e6001541306f0b08de4f49f729%7C90c7a20af34b40bfbc48b9253b6f5
> >>
> d20%7C0%7C0%7C639035376376592486%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0e
> >>
> U1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCI
> >>
> sIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=vasp1mXIMbsWiId49xguONMnE0Olp
> >> zghBlEU%2BQiVzN0%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%7C996760e600154
> >>
> 1306f0b08de4f49f729%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0%7C0%7C6
> >>
> 39035376376615407%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUs
> >>
> IlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%
> >>
> 3D%7C0%7C%7C%7C&sdata=aHV8pdXYb0OZxacb2FSeFR6xQjWSGwO64t9RLC9DelY%
> >> 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%7C996760e
> >>
> 6001541306f0b08de4f49f729%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0%7
> >>
> C0%7C639035376376634975%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOn
> >>
> RydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoy
> >>
> fQ%3D%3D%7C0%7C%7C%7C&sdata=VVd7o6uyAaANuamDQ4Nf2P8iXJIc6r%2B%2FYP
> >> VMpINt6zE%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
> >>
> C996760e6001541306f0b08de4f49f729%7C90c7a20af34b40bfbc48b9253b6f5d
> >>
> 20%7C0%7C0%7C639035376376646646%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU
> >>
> 1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIs
> >>
> IldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=U1J9K5shZ7K8bDDmEqK7GxxslJ9trs
> >> 1u6oKtOo4cai0%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%7C996760e6001541306f0b08de4f49
> >>
> f729%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0%7C0%7C6390353763766571
> >>
> 41%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDA
> >>
> wMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C
> >>
> &sdata=NvMAAEzIM9wakQaKiJ1LMU2P1h%2BNWCTPQMcGS06mL0U%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
> >>
> https://fra01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fw
> ww.
> >> rfc-
> %2F&data=05%7C02%7Cmohamed.boucadair%40orange.com%7Cd66b9dc3e9254
> >>
> 7af271108de54a90726%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0%7C0%7C6
> 390
> >>
> 41285260640497%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlY
> iOi
> >>
> IwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C4
> 000
> >>
> 0%7C%7C%7C&sdata=wCf6LH37ECoXQ1gFoyEbQIxN84cxqZnSRojpeu6hfko%3D&re
> ser
> >> ved=0
> >>
> editor.org%2Fauthors%2Frfc9907.xml&data=05%7C02%7Cmohamed.boucadai
> >>
> r%40orange.com%7C996760e6001541306f0b08de4f49f729%7C90c7a20af34b40
> >>
> bfbc48b9253b6f5d20%7C0%7C0%7C639035376376666822%7CUnknown%7CTWFpbG
> >>
> Zsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIs
> >>
> IkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=bWEgtD%2FWD7jv
> >> rxBYi%2FA51ONcvqDVu0kJA7nyp3BGhcI%3D&reserved=0
> >>
> >>
> https://fra01.safelinks.protection.outlook.com/?url=https%3A%2F%2F
> >>
> https://fra01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fw
> ww.
> >> rfc-
> %2F&data=05%7C02%7Cmohamed.boucadair%40orange.com%7Cd66b9dc3e9254
> >>
> 7af271108de54a90726%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0%7C0%7C6
> 390
> >>
> 41285260653640%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlY
> iOi
> >>
> IwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C4
> 000
> >>
> 0%7C%7C%7C&sdata=QwswLs2Z15NaN3b%2BHgAgTCYkzfLbfOExle6sA5IlBzs%3D&
> res
> >> erved=0
> >>
> editor.org%2Fauthors%2Frfc9907.html&data=05%7C02%7Cmohamed.boucada
> >>
> ir%40orange.com%7C996760e6001541306f0b08de4f49f729%7C90c7a20af34b4
> >>
> 0bfbc48b9253b6f5d20%7C0%7C0%7C639035376376676702%7CUnknown%7CTWFpb
> >>
> GZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiI
> >>
> sIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=lXZMVFfTKrlqk
> >> 8j%2BLC3fWyTvy%2BeEzaPE6HQ9BN4dL1E%3D&reserved=0
> >>
> >>
> https://fra01.safelinks.protection.outlook.com/?url=https%3A%2F%2F
> >>
> https://fra01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fw
> ww.
> >> rfc-
> %2F&data=05%7C02%7Cmohamed.boucadair%40orange.com%7Cd66b9dc3e9254
> >>
> 7af271108de54a90726%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0%7C0%7C6
> 390
> >>
> 41285261034987%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlY
> iOi
> >>
> IwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C4
> 000
> >>
> 0%7C%7C%7C&sdata=KcrrueEsaD38sNdQSfs8rvUy25r677nNFJ1%2FBH%2FRRMA%3
> D&r
> >> eserved=0
> >>
> editor.org%2Fauthors%2Frfc9907.pdf&data=05%7C02%7Cmohamed.boucadai
> >>
> r%40orange.com%7C996760e6001541306f0b08de4f49f729%7C90c7a20af34b40
> >>
> bfbc48b9253b6f5d20%7C0%7C0%7C639035376376686295%7CUnknown%7CTWFpbG
> >>
> Zsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIs
> >>
> IkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=TDLXy1ifMxLudV
> >> fA9k1OTa2PilKpTPuxaBghT8f46ms%3D&reserved=0
> >>
> >>
> https://fra01.safelinks.protection.outlook.com/?url=https%3A%2F%2F
> >>
> https://fra01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fw
> ww.
> >> rfc-
> %2F&data=05%7C02%7Cmohamed.boucadair%40orange.com%7Cd66b9dc3e9254
> >>
> 7af271108de54a90726%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0%7C0%7C6
> 390
> >>
> 41285261066808%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlY
> iOi
> >>
> IwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C4
> 000
> >>
> 0%7C%7C%7C&sdata=TLTCHdbFggF8YBIVktjz%2FiMJkEMe6ScM72SroFQhp7I%3D&
> res
> >> erved=0
> >>
> editor.org%2Fauthors%2Frfc9907.txt&data=05%7C02%7Cmohamed.boucadai
> >>
> r%40orange.com%7C996760e6001541306f0b08de4f49f729%7C90c7a20af34b40
> >>
> bfbc48b9253b6f5d20%7C0%7C0%7C639035376376695228%7CUnknown%7CTWFpbG
> >>
> Zsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIs
> >>
> IkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=fdczpv1840OJBh
> >> bl62w7v6hnbgOzgjwVzuiknRksS8E%3D&reserved=0
> >>
> >> Diff file of the text:
> >>
> >>
> https://fra01.safelinks.protection.outlook.com/?url=https%3A%2F%2F
> >>
> https://fra01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fw
> ww.
> >> rfc-
> editor.org%2F&data=05%7C02%7Cmohamed.boucadair%40orange.com%7Cd66
> >>
> b9dc3e92547af271108de54a90726%7C90c7a20af34b40bfbc48b9253b6f5d20%7
> C0%
> >>
> 7C0%7C639041285261082781%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiO
> nRy
> >>
> dWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ
> %3D
> >>
> %3D%7C40000%7C%7C%7C&sdata=dtO6wCBwjlKJhJBlETuu7DOiQX0FGQUlPnyrkVh
> aG2
> >> s%3D&reserved=0%2Fauthors%2Frfc9907-
> >>
> diff.html&data=05%7C02%7Cmohamed.boucadair%40orange.com%7C996760e6
> >>
> 001541306f0b08de4f49f729%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0%7C
> >>
> 0%7C639035376376704453%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnR
> >>
> ydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyf
> >>
> Q%3D%3D%7C0%7C%7C%7C&sdata=dCxO4kAnhglm6k1A7pIFNQEWzeTe9JMIv%2BIv7
> >> YUjNjI%3D&reserved=0
> >>
> >>
> https://fra01.safelinks.protection.outlook.com/?url=https%3A%2F%2F
> >>
> https://fra01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fw
> ww.
> >> rfc-
> editor.org%2F&data=05%7C02%7Cmohamed.boucadair%40orange.com%7Cd66
> >>
> b9dc3e92547af271108de54a90726%7C90c7a20af34b40bfbc48b9253b6f5d20%7
> C0%
> >>
> 7C0%7C639041285261096952%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiO
> nRy
> >>
> dWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ
> %3D
> >>
> %3D%7C40000%7C%7C%7C&sdata=yUuSqvWya5AX1hO6T3EAEtj1%2BLb5mun%2FnQ%
> 2BF
> >> GipU6rQ%3D&reserved=0%2Fauthors%2Frfc9907-
> >>
> rfcdiff.html&data=05%7C02%7Cmohamed.boucadair%40orange.com%7C99676
> >>
> 0e6001541306f0b08de4f49f729%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0
> >>
> %7C0%7C639035376376714188%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGki
> >>
> OnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIj
> >>
> oyfQ%3D%3D%7C0%7C%7C%7C&sdata=T9T4ZyDP15ajWTytN9qPqBoANh4a5f7hCH%2
> >> FVv%2Fj4eds%3D&reserved=0 (side by side)
> >>
> >> Diff of the XML:
> >>
> >>
> https://fra01.safelinks.protection.outlook.com/?url=https%3A%2F%2F
> >>
> https://fra01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fw
> ww.
> >> rfc-
> editor.org%2F&data=05%7C02%7Cmohamed.boucadair%40orange.com%7Cd66
> >>
> b9dc3e92547af271108de54a90726%7C90c7a20af34b40bfbc48b9253b6f5d20%7
> C0%
> >>
> 7C0%7C639041285261110156%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiO
> nRy
> >>
> dWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ
> %3D
> >>
> %3D%7C40000%7C%7C%7C&sdata=43NbWChj3f3cgJmQB3Clzzh0vOkjY1wu5PC8VDI
> wK8
> >> M%3D&reserved=0%2Fauthors%2Frfc9907-
> >>
> xmldiff1.html&data=05%7C02%7Cmohamed.boucadair%40orange.com%7C9967
> >>
> 60e6001541306f0b08de4f49f729%7C90c7a20af34b40bfbc48b9253b6f5d20%7C
> >>
> 0%7C0%7C639035376376724785%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGk
> >>
> iOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUI
> >>
> joyfQ%3D%3D%7C0%7C%7C%7C&sdata=dqrKLsR6VUjQflKcN3R5D8WUjMrtiu4dNDK
> >> 5j5JNa6s%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
> >>
> https://fra01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fw
> ww.
> >> rfc-
> %2F&data=05%7C02%7Cmohamed.boucadair%40orange.com%7Cd66b9dc3e9254
> >>
> 7af271108de54a90726%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0%7C0%7C6
> 390
> >>
> 41285261123196%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlY
> iOi
> >>
> IwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C4
> 000
> >>
> 0%7C%7C%7C&sdata=oYPCucJuY1N22wscYuluFqx8M9lrPMA2LU4CmuCtGU4%3D&re
> ser
> >> ved=0
> >>
> editor.org%2Fauth48%2Frfc9907&data=05%7C02%7Cmohamed.boucadair%40o
> >>
> range.com%7C996760e6001541306f0b08de4f49f729%7C90c7a20af34b40bfbc4
> >>
> 8b9253b6f5d20%7C0%7C0%7C639035376376734635%7CUnknown%7CTWFpbGZsb3d
> >>
> 8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOI
> >>
> joiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=xnRiIUjtFLyhaLEH8MD
> >> 4%2FG1dEMc3c%2F%2FtFkPQg5twja8%3D&reserved=0
> >>
> >> Please let us know if you have any questions.
> >>
> >> Thank you for your cooperation,
> >>
> >> RFC Editor
> >>
> >> --------------------------------------
> >> RFC9907 (draft-ietf-netmod-rfc8407bis-28)
> >>
> >> Title : Guidelines for Authors and Reviewers of
> >> Documents Containing YANG Data Models
> >> Author(s) : A. Bierman, M. Boucadair, Ed., Q. Wu
> >> WG Chair(s) : Kent Watsen, Lou Berger
> >> Area Director(s) : Mohamed Boucadair, Mahesh Jethanandani
> >
> __________________________________________________________________
> ____
> > ______________________________________
> > 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.
> >
____________________________________________________________________________________________________________
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]
