Re: [auth48] AUTH48: RFC-to-be 9492 <draft-ietf-lsr-rfc8920bis-06> for your review

[Madison Church <[e-mail]>]

Hi all,

Acee, we have incorporated your requested updates. Please review and let us know if any additional updates or corrections are needed.

Jeff and Wim, we have noted your approvals on the AUTH48 status page for this document (https://www.rfc-editor.org/auth48/rfc9492).

Once we receive approval from Peter, we will move this document forward in the publication process.

Updated XML file:
https://www.rfc-editor.org/authors/rfc9492.xml

Updated output files:
https://www.rfc-editor.org/authors/rfc9492.txt
https://www.rfc-editor.org/authors/rfc9492.pdf
https://www.rfc-editor.org/authors/rfc9492.html

Diff file showing all changes made during AUTH48:
https://www.rfc-editor.org/authors/rfc9492-auth48diff.html

Diff files showing all changes:
https://www.rfc-editor.org/authors/rfc9492-diff.html (comprehensive diff)
https://www.rfc-editor.org/authors/rfc9492-rfcdiff.html (side-by-side diff)

Note that it may be necessary for you to refresh your browser to view the most recent version.

Thank you!
RFC Editor/mc

> On Sep 28, 2023, at 6:21 PM, Jeff Tantsura <[e-mail]> wrote:
> 
> The changes look good to me.
> Thanks!
> 
> Cheers,
> Jeff
> 
>> On Sep 28, 2023, at 16:04, Wim Henderickx (Nokia) <[e-mail]> wrote:
>> 
>>  @font-face { font-family: "Cambria Math"; } @font-face { font-family: Calibri; } p.MsoNormal, li.MsoNormal, div.MsoNormal { margin: 0cm; font-size: 10pt; font-family: Calibri, sans-serif; } a:link, span.MsoHyperlink { color: blue; text-decoration: underline; } span.apple-tab-span { } span.EmailStyle21 { font-family: Calibri, sans-serif; color: windowtext; } .MsoChpDefault { font-size: 10pt; } @page WordSection1 { size: 612pt 792pt; margin: 72pt; } div.WordSection1 { page: WordSection1; } I am good with the latest changes.
>>   From: Les Ginsberg (ginsberg) <[e-mail]>
>> Date: Thursday, 28 September 2023 at 15:14
>> To: Acee Lindem <[e-mail]>, Madison Church <[e-mail]>
>> Cc: Peter Psenak (ppsenak) <[e-mail]>, Wim Henderickx (Nokia) <[e-mail]>, [e-mail] <[e-mail]>, John E Drake <[e-mail]>, [e-mail] <[e-mail]>, [e-mail] <[e-mail]>, [e-mail] <[e-mail]>, [e-mail] <[e-mail]>, [e-mail] <[e-mail]>, [e-mail] <[e-mail]>
>> Subject: RE: AUTH48: RFC-to-be 9492 <draft-ietf-lsr-rfc8920bis-06> for your review
>>   CAUTION: This is an external email. Please be very careful when clicking links or opening attachments. See the URL nok.it/ext for additional information.
>>   I am fine with all of the changes Acee has proposed.
>>    Les
>>   From: Acee Lindem <[e-mail]> 
>> Sent: Thursday, September 28, 2023 1:34 PM
>> To: Madison Church <[e-mail]>
>> Cc: Les Ginsberg (ginsberg) <[e-mail]>; Peter Psenak (ppsenak) <[e-mail]>; [e-mail]; [e-mail]; John E Drake <[e-mail]>; [e-mail]; [e-mail]; [e-mail]; [e-mail]; [e-mail]; [e-mail]
>> Subject: Re: AUTH48: RFC-to-be 9492 <draft-ietf-lsr-rfc8920bis-06> for your review
>>   Hi Madison, 
>>   Actually, I spoke too soon and have some changes. I removed “new” in a few places where it was redundant. 
>> I also updated contact information and included a couple readability improvements. 
>>     *** rfc9492.txt.orig Thu Sep 28 15:47:08 2023
>> --- rfc9492.txt Thu Sep 28 16:27:18 2023
>> ***************
>> *** 27,33 ****
>>      attributes, the current advertisements do not support application-
>>      specific values for a given attribute, nor do they support indication
>>      of which applications are using the advertised value for a given
>> !    link.  This document introduces new link attribute advertisements in
>>      OSPFv2 and OSPFv3 that address both of these shortcomings.
>>        This document obsoletes RFC 8920.
>> --- 27,33 ----
>>      attributes, the current advertisements do not support application-
>>      specific values for a given attribute, nor do they support indication
>>      of which applications are using the advertised value for a given
>> !    link.  This document introduces link attribute advertisements in
>>      OSPFv2 and OSPFv3 that address both of these shortcomings.
>>        This document obsoletes RFC 8920.
>> ***************
>> *** 134,140 ****
>>      the router that is an RSVP-TE head end sees the link attribute being
>>      advertised for that link, it assumes RSVP-TE is enabled on that link,
>>      even though it is not.  If such an RSVP-TE head-end router tries to
>> !    set up an RSVP-TE path via that link, it will result in the path
>> !    setup failure.
>>        An additional issue arises in cases where both applications are
>> --- 134,140 ----
>>      the router that is an RSVP-TE head end sees the link attribute being
>>      advertised for that link, it assumes RSVP-TE is enabled on that link,
>>      even though it is not.  If such an RSVP-TE head-end router tries to
>> !    set up an RSVP-TE path via that link, it will result in a setup
>> !    failure for the path.
>>        An additional issue arises in cases where both applications are
>> ***************
>> *** 263,269 ****
>>   5.  Advertisement of Application-Specific Values
>>        To allow advertisement of the application-specific values of the link
>> !    attribute, a new Application-Specific Link Attributes (ASLA) sub-TLV
>>      is defined.  The ASLA sub-TLV is a sub-TLV of the OSPFv2 Extended
>>      Link TLV [RFC7684] and OSPFv3 Router-Link TLV [RFC8362].
>>   --- 263,269 ----
>>   5.  Advertisement of Application-Specific Values
>>        To allow advertisement of the application-specific values of the link
>> !    attribute, an Application-Specific Link Attributes (ASLA) sub-TLV
>>      is defined.  The ASLA sub-TLV is a sub-TLV of the OSPFv2 Extended
>>      Link TLV [RFC7684] and OSPFv3 Router-Link TLV [RFC8362].
>>   ***************
>> *** 299,305 ****
>>      +-                                                             -+
>>      |                            ...                                |
>>      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>> !    |                      Link Attribute sub-sub-TLVs              |
>>      +-                                                             -+
>>      |                            ...                                |
>>   --- 299,305 ----
>>      +-                                                             -+
>>      |                            ...                                |
>>      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>> !    |                      Link Attribute sub-TLVs                  |
>>      +-                                                             -+
>>      |                            ...                                |
>>   ***************
>> *** 373,379 ****
>>      previously defined link attributes can be kept and reused when
>>      advertising them in the ASLA sub-TLV.
>>   !    If the same attribute is advertised in more than one ASLA sub-TLVs
>>      with the application listed in the Application Identifier Bit Masks,
>>      the application SHOULD use the first instance of advertisement and
>>      ignore any subsequent advertisements of that attribute.
>> --- 373,379 ----
>>      previously defined link attributes can be kept and reused when
>>      advertising them in the ASLA sub-TLV.
>>   !    If the same attribute is advertised in more than one ASLA sub-TLV
>>      with the application listed in the Application Identifier Bit Masks,
>>      the application SHOULD use the first instance of advertisement and
>>      ignore any subsequent advertisements of that attribute.
>> ***************
>> *** 778,784 ****
>>      limited to prevent a denial-of-service (DoS) attack (distributed or
>>      otherwise) from overloading the OSPF control plane.
>>   !    This document defines a new way to advertise link attributes.
>>      Tampering with the information defined in this document may have an
>>      effect on applications using it, including impacting TE, which uses
>>      various link attributes for its path computation.  This is similar in
>> --- 778,784 ----
>>      limited to prevent a denial-of-service (DoS) attack (distributed or
>>      otherwise) from overloading the OSPF control plane.
>>   !    This document defines an improved way to advertise link attributes.
>>      Tampering with the information defined in this document may have an
>>      effect on applications using it, including impacting TE, which uses
>>      various link attributes for its path computation.  This is similar in
>> ***************
>> *** 795,801 ****
>>        *  the "OSPFv3 Extended-LSA Sub-TLVs" registry
>>   !    The new values defined in this document have been allocated using the
>>      IETF Review procedure as described in [RFC8126].
>>     14.1.  OSPFv2
>> --- 795,801 ----
>>        *  the "OSPFv3 Extended-LSA Sub-TLVs" registry
>>   !    The values defined in this document have been allocated using the
>>      IETF Review procedure as described in [RFC8126].
>>     14.1.  OSPFv2
>> ***************
>> *** 889,895 ****
>>      advertisements MUST be used and the specific conditions under which
>>      they MUST NOT be used.
>>   !    A new subsection discussing the use of zero-length Application
>>      Identifier Bit Masks has been added for greater consistency with
>>      [RFC9479].  See Section 12.2.
>>   --- 889,895 ----
>>      advertisements MUST be used and the specific conditions under which
>>      they MUST NOT be used.
>>   !    A subsection discussing the use of zero-length Application
>>      Identifier Bit Masks has been added for greater consistency with
>>      [RFC9479].  See Section 12.2.
>>   ***************
>> *** 1026,1038 ****
>>      should be considered as coauthors:
>>        Acee Lindem
>> !    Cisco Systems
>>      United States of America
>> !    Email: [e-mail]
>>          Ketan Talaulikar
>> !    Arrcus, Inc.
>>      India
>>      Email: [e-mail]
>>   --- 1026,1038 ----
>>      should be considered as coauthors:
>>        Acee Lindem
>> !    LabN Consulting, L.L.C.
>>      United States of America
>> !    Email: [e-mail]
>>          Ketan Talaulikar
>> !    Cisco Systems
>>      India
>>      Email: [e-mail]
>>   Thanks, 
>> Acee
>>       On Sep 27, 2023, at 5:14 PM, Madison Church <[e-mail]> wrote:
>> 
>> Hi Les,
>> 
>> Thank you for your reply! We have updated the document per your responses. We have a few followup questions/comments.
>> 
>> 1) Regarding this requested change:
>> 
>> 
>> 
>> 1)Section 5
>> 
>> "Standard Application Identifier Bit Mask:  Optional set of bits,
>>     where each bit represents a single standard application.  Bits are
>>     defined in the "Link Attribute Application Identifiers" registry,
>>     which is defined in [RFC8919]."
>> 
>> The reference should be updated to be the new RFC9479.
>> 
>> We have updated instances of [RFC8919] to [RFC9479]. Note that RFC-to-be 9479 is in AUTH48; we will publish this document at the same time as RFC-to-be 9479.
>> 
>> 
>> 2) Regarding this requested change:
>> 
>> 
>> 
>> 2)Section 5
>> 
>> "Bit 1 (S-bit):  Segment Routing Policy.  This is data plane
>>       independent."
>> 
>> This format does not match the same text in RFC9479(to be) which is currently shown as:
>> 
>> " S-bit:  Set to specify SR Policy (this is data plane independent)."
>> 
>> My personal preference is to keep the parentheses.
>> 
>> We have updated the S-bit definition as you suggest above to keep the parentheses; as you note, this matches the format in RFC-to-be 9479. Would you also like to use parentheses for the F-bit definition to match RFC 9479?
>> 
>> Current in this document:
>> Bit 2 (F-bit):  LFA.  Includes all LFA types.
>> 
>> Current in RFC 9479:
>> F-bit:  Set to specify an LFA (includes all LFA types).
>> 
>> 
>> 3) Regarding Question 7:
>> 
>> 
>> 
>> 7) <!-- [rfced] The following expansions are defined more than once
>> throughout the
>> document. May we use the abbreviated form for the following expansions
>> upon
>> first use per Section 3.6 of RFC 7322 ("RFC Style Guide")?
>> 
>> Loop-Free Alternates (LFAs)
>> Standard Application Bit Mask (SABM)
>> Segment Routing (SR)
>> traffic engineering (TE)
>> User Defined Application Bit Mask (UDABM) -->
>> 
>> Within the definition list in Section 5, we left the expanded forms of “Standard Application Identifier Bit Mask” and “User-Defined Application Identifier Bit Mask” as is to match the field names in the figure directly above.  If you prefer to use the abbreviated forms in the definition list, please let us know. Also, would it be correct to add “field” to the following entries for clarity as shown below?
>> 
>> Original:
>> SABM Length:  Standard Application Identifier Bit Mask Length in octets. 
>> 
>> UDABM Length:  User-Defined Application Identifier Bit Mask Length in
>>    octets. 
>> 
>> Perhaps:
>> SABM Length:  Length of the Standard Application Identifier Bit Mask field in
>>    octets. 
>> 
>> UDABM Length:  Length of the User-Defined Application Identifier Bit Mask 
>>    field in octets. 
>> 
>> 
>> Updated XML file:
>>   https://www.rfc-editor.org/authors/rfc9492.xml
>> 
>> Updated output files:
>>   https://www.rfc-editor.org/authors/rfc9492.txt
>>   https://www.rfc-editor.org/authors/rfc9492.pdf
>>   https://www.rfc-editor.org/authors/rfc9492.html
>> 
>> Diff file showing all changes made during AUTH48:
>>   https://www.rfc-editor.org/authors/rfc9492-auth48diff.html
>> 
>> Diff files showing all changes:
>>   https://www.rfc-editor.org/authors/rfc9492-diff.html
>>   https://www.rfc-editor.org/authors/rfc9492-rfcdiff.html (side-by-side diff)
>> 
>> Note that it may be necessary for you to refresh your browser to view the most recent version. 
>> 
>> For the AUTH48 status of this document, please see:
>>  https://www.rfc-editor.org/auth48/rfc9492
>> 
>> Thank you,
>> RFC Editor/mc
>> 
>> 
>>