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

[Acee Lindem <[e-mail]>]

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] <mailto:[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
> 
>