Application-Specific Link Attributes Advertisement Using the Border Gateway Protocol - Link State (BGP-LS)
draft-ietf-idr-bgp-ls-app-specific-attr-16

[Ballot comment]
Thanks for all the work to help clear up my DISCUSS! Version 14 looks good, modulo some questions about §4.1 I've sent in a separate reply (but which are only COMMENT level).

--

Previous DISCUSS:

I'd like to DISCUSS some questions I have about the content of Section 4's IS-IS rules. I don't expect it will be difficult to resolve these, I just want to be sure we have the conversation.

1. In §4 (2.C),

      C.  The SRLGs advertised in IS-IS SRLG ASLA TLVs and the other
          link attributes advertised in IS-IS ASLA sub-TLVs are
          REQUIRED to be collated, on a per-application basis, for all
          applications that have their bit set in the SABM/UDABM in at
          least one of the aforementioned TLV types.
         
Is there some reason that there's no need to consider the case where both of the TLV types in question have zero-length application bit masks?

2. Later in the same paragraph,

                                                      When performing
          this collation, only the TLVs with the application's bit set
          in SABM/UDABM MUST be used when such TLVs are available from
          either TLV types.

I suspect you aren't saying what you mean, and the "only... MUST" construct is hard to puzzle out. Do you perhaps mean TLVs that don’t have the application's bit set MUST NOT be used? Because as you've written it,

- All TLVs with the bit set MUST be collated,
- Any TLVs without the bit set MAY be collated (by implication). Which doesn't seem very sensible AFAICT.

A possible rewrite, if I've understood your intention correctly, might be "When performing this collation, every TLV with the application's bit set in SABM/UDABM MUST be included, when such TLVs are available from either TLV type."

(Note also a minor fix for agreement in number, s/types/type/ in the last word.)

3. And still later in the same paragraph,

                              If the bit for an application is set in
          the SABM/UDABM of only one of the TLV types, then the
          attributes from the other TLV type with zero-length
          application bit mask MUST be also collated for that
          application, if such TLV is available.

I'm confused by the reference to a zero-length application bit mask. Can't the other TLV type have a nonzero-length application bit mask, but still have the application bit in question not set within the bit mask?

I guess probably what you mean is, if the other TLV type is present and has a zero-length application bit mask, since a zero-length SABM/UDABM basically is a wildcard, the equivalent of all bits being set (as I read RFC 8920).

If that's right, then a change seems in order, along the lines of

                              If the bit for an application is set in
          the SABM/UDABM of only one of the TLV types, and if the
          other TLV type has a zero-length application bit mask, then the
          attributes from the other TLV type with zero-length
          application bit mask MUST be also collated for that
          application, if such TLV is available.

I just interpolated the "and" clause. It's a bit wordy and could probably be further condensed, but I think it clarifies sufficiently.

On the other hand, if I'm not right about this (very possible) then I'd appreciate further discussion on what I got wrong, so we can figure out if the text needs clarification or if I just need a clue bat.

Previous COMMENT:

4. In §2 you reference "SABML". I was going to ask you to expand it on first use, but you only use it once. So, please just write it out in words as "SABM Length" and don't introduce an extra acronym.

5. In §3:

  All the BGP-LS Attribute TLVs defined in the table above are REQUIRED
  to be advertised as a top-level TLV in the BGP-LS Attribute for
  carrying link attributes specific to RSVP-TE.

I suggest “... when used to carry” instead of “... for carrying”. Also, “listed in the table”, not defined in it.

6. Much of §4 is dedicated to a special case for IS-IS:

  2.  In the case of IS-IS, the following specific procedures are to be
      followed:

It would be nice to spend a few words mentioning why IS-IS needs a special case and OSPF doesn't, so that the reader doesn't have to wonder. I'm guessing that this relates to the way IS-IS uses sub-TLVs for various things whereas OSPF doesn't, so you need rules to reconcile the values in IS-IS but not OSPF?

7. §4 (2.B) needs some adjectives, "IS-IS" and "BGP-LS", respectively, to make clear which flavor of "ASLA sub-TLV" you're talking about. I *think* that here,

      B.  When the ASLA sub-TLV has the RSVP-TE application bit set,
          then the link attributes for the corresponding ASLA sub-TLV
          MUST be encoded using the respective BGP-LS top-level TLVs as
          per [RFC7752] [RFC8571] [RFC9104].
         
the first reference to "ASLA sub-TLV" is the IS-IS flavor, and the second is to the BGP-LS flavor --  but please be specific.

8. In §4,

  These rules ensure that a BGP-LS originator performs the
  advertisement for all application-specific link attributes from the
  IGP nodes that support or do not support the ASLA extension.

I don't understand this sentence. :-( For one thing, applying simple logic to "IGP nodes that support or do not support the ASLA extension" we can rewrite it as "IGP nodes", full stop, since "support or do not support" covers the entire universe by definition. That would imply the sentence could be rewritten as

  These rules ensure that a BGP-LS originator performs the
  advertisement for all application-specific link attributes from the
  IGP nodes.
 
Which doesn't really help me. :-(

9. In §5,

  It is recommended that nodes supporting this specification are
  selected as originators of BGP-LS information when advertising the
  link-state information from the IGPs.

Do you mean only such nodes should be selected? Or is it that at least one such should be among those selected? Either is supportable, I think. Whatever the answer, please clarify the text correspondingly. Although, more generally I guess BGP-LS originators ought to support all the extensions in use in a given IGP, not limited to this one, so this is really a special case of a general principle.

10. In §5,

                                    They would, however, not be able to
  support neither the application-specific link attributes nor newer
  applications that may be encoded only using the ASLA TLV.
 
Drop the "not". Also, again this seems like a special case of a general principle -- of course a BGP-LS consumer that doesn't understand a given extension can't do the thing that the extension covers. But, it's fine to remind the reader of this.

11. In §8,

                            It is assumed that the IGP instances
  originating these TLVs will support all the required security (as
  described in [RFC8919] and [RFC8920]) to prevent any security issues
  when propagating the TLVs into BGP-LS.
 
I think purporting to "prevent any security issues" is a case of seriously overpromising. A very similar issue existed in draft-ietf-idr-bgp-ls-sbfd-extensions-08. Perhaps a similar fix could be applied, although in this case, when I took a quick look at RFCs 8919 and 8920 I didn't find any "required security" of note, so I'm really not sure what if anything is being actually promised by this sentence? Can you help me understand what properties I should be expecting?

In any case, for the most part it seems fine to say your security model is the same as that of RFCs 8919 and 8920, since as we know BGP-LS tries to be just a re-rendering of the data from those suppliers. But, we should keep in mind this consideration from RFC 7752:

  Additionally, it may be considered that the export of link-state and
  TE information as described in this document constitutes a risk to
  confidentiality of mission-critical or commercially sensitive
  information about the network. 

Might it be worth reminding the reader that if there's any sensitive information contained in the new stuff you're propagating, they should take this warning to heart, since the scope across which the information is being propagated can increase considerably? I don't insist on this, I'm only raising it as a point to consider.


Nits and very minor comments --

12. The document talks about new this, new that. This probably won't age well -- keep in mind that the RFC this document will become will be around for decades, at which point none of this stuff will be "new".

It's obviously not a big deal but if it were my document I'd find a way to rewrite those "new" in a way that won't be instantly obsolete.

13. In §4,

                                The application-specific attribute
  value received via sub-TLVs within the ASLA TLV have preference over
  the value received via the top-level TLVs.
 
There's an agreement in number problem here -- perhaps rewrite as "An application-specific attribute value received via a sub-TLV within the ASLA TLV has precedence over the value received via a top-level TLV"?

[Ballot comment]
Thanks for all the work to help clear up my DISCUSS!

--

Previous DISCUSS:

I'd like to DISCUSS some questions I have about the content of Section 4's IS-IS rules. I don't expect it will be difficult to resolve these, I just want to be sure we have the conversation.

1. In §4 (2.C),

      C.  The SRLGs advertised in IS-IS SRLG ASLA TLVs and the other
          link attributes advertised in IS-IS ASLA sub-TLVs are
          REQUIRED to be collated, on a per-application basis, for all
          applications that have their bit set in the SABM/UDABM in at
          least one of the aforementioned TLV types.
         
Is there some reason that there's no need to consider the case where both of the TLV types in question have zero-length application bit masks?

2. Later in the same paragraph,

                                                      When performing
          this collation, only the TLVs with the application's bit set
          in SABM/UDABM MUST be used when such TLVs are available from
          either TLV types.

I suspect you aren't saying what you mean, and the "only... MUST" construct is hard to puzzle out. Do you perhaps mean TLVs that don’t have the application's bit set MUST NOT be used? Because as you've written it,

- All TLVs with the bit set MUST be collated,
- Any TLVs without the bit set MAY be collated (by implication). Which doesn't seem very sensible AFAICT.

A possible rewrite, if I've understood your intention correctly, might be "When performing this collation, every TLV with the application's bit set in SABM/UDABM MUST be included, when such TLVs are available from either TLV type."

(Note also a minor fix for agreement in number, s/types/type/ in the last word.)

3. And still later in the same paragraph,

                              If the bit for an application is set in
          the SABM/UDABM of only one of the TLV types, then the
          attributes from the other TLV type with zero-length
          application bit mask MUST be also collated for that
          application, if such TLV is available.

I'm confused by the reference to a zero-length application bit mask. Can't the other TLV type have a nonzero-length application bit mask, but still have the application bit in question not set within the bit mask?

I guess probably what you mean is, if the other TLV type is present and has a zero-length application bit mask, since a zero-length SABM/UDABM basically is a wildcard, the equivalent of all bits being set (as I read RFC 8920).

If that's right, then a change seems in order, along the lines of

                              If the bit for an application is set in
          the SABM/UDABM of only one of the TLV types, and if the
          other TLV type has a zero-length application bit mask, then the
          attributes from the other TLV type with zero-length
          application bit mask MUST be also collated for that
          application, if such TLV is available.

I just interpolated the "and" clause. It's a bit wordy and could probably be further condensed, but I think it clarifies sufficiently.

On the other hand, if I'm not right about this (very possible) then I'd appreciate further discussion on what I got wrong, so we can figure out if the text needs clarification or if I just need a clue bat.

Previous COMMENT:

4. In §2 you reference "SABML". I was going to ask you to expand it on first use, but you only use it once. So, please just write it out in words as "SABM Length" and don't introduce an extra acronym.

5. In §3:

  All the BGP-LS Attribute TLVs defined in the table above are REQUIRED
  to be advertised as a top-level TLV in the BGP-LS Attribute for
  carrying link attributes specific to RSVP-TE.

I suggest “... when used to carry” instead of “... for carrying”. Also, “listed in the table”, not defined in it.

6. Much of §4 is dedicated to a special case for IS-IS:

  2.  In the case of IS-IS, the following specific procedures are to be
      followed:

It would be nice to spend a few words mentioning why IS-IS needs a special case and OSPF doesn't, so that the reader doesn't have to wonder. I'm guessing that this relates to the way IS-IS uses sub-TLVs for various things whereas OSPF doesn't, so you need rules to reconcile the values in IS-IS but not OSPF?

7. §4 (2.B) needs some adjectives, "IS-IS" and "BGP-LS", respectively, to make clear which flavor of "ASLA sub-TLV" you're talking about. I *think* that here,

      B.  When the ASLA sub-TLV has the RSVP-TE application bit set,
          then the link attributes for the corresponding ASLA sub-TLV
          MUST be encoded using the respective BGP-LS top-level TLVs as
          per [RFC7752] [RFC8571] [RFC9104].
         
the first reference to "ASLA sub-TLV" is the IS-IS flavor, and the second is to the BGP-LS flavor --  but please be specific.

8. In §4,

  These rules ensure that a BGP-LS originator performs the
  advertisement for all application-specific link attributes from the
  IGP nodes that support or do not support the ASLA extension.

I don't understand this sentence. :-( For one thing, applying simple logic to "IGP nodes that support or do not support the ASLA extension" we can rewrite it as "IGP nodes", full stop, since "support or do not support" covers the entire universe by definition. That would imply the sentence could be rewritten as

  These rules ensure that a BGP-LS originator performs the
  advertisement for all application-specific link attributes from the
  IGP nodes.
 
Which doesn't really help me. :-(

9. In §5,

  It is recommended that nodes supporting this specification are
  selected as originators of BGP-LS information when advertising the
  link-state information from the IGPs.

Do you mean only such nodes should be selected? Or is it that at least one such should be among those selected? Either is supportable, I think. Whatever the answer, please clarify the text correspondingly. Although, more generally I guess BGP-LS originators ought to support all the extensions in use in a given IGP, not limited to this one, so this is really a special case of a general principle.

10. In §5,

                                    They would, however, not be able to
  support neither the application-specific link attributes nor newer
  applications that may be encoded only using the ASLA TLV.
 
Drop the "not". Also, again this seems like a special case of a general principle -- of course a BGP-LS consumer that doesn't understand a given extension can't do the thing that the extension covers. But, it's fine to remind the reader of this.

11. In §8,

                            It is assumed that the IGP instances
  originating these TLVs will support all the required security (as
  described in [RFC8919] and [RFC8920]) to prevent any security issues
  when propagating the TLVs into BGP-LS.
 
I think purporting to "prevent any security issues" is a case of seriously overpromising. A very similar issue existed in draft-ietf-idr-bgp-ls-sbfd-extensions-08. Perhaps a similar fix could be applied, although in this case, when I took a quick look at RFCs 8919 and 8920 I didn't find any "required security" of note, so I'm really not sure what if anything is being actually promised by this sentence? Can you help me understand what properties I should be expecting?

In any case, for the most part it seems fine to say your security model is the same as that of RFCs 8919 and 8920, since as we know BGP-LS tries to be just a re-rendering of the data from those suppliers. But, we should keep in mind this consideration from RFC 7752:

  Additionally, it may be considered that the export of link-state and
  TE information as described in this document constitutes a risk to
  confidentiality of mission-critical or commercially sensitive
  information about the network. 

Might it be worth reminding the reader that if there's any sensitive information contained in the new stuff you're propagating, they should take this warning to heart, since the scope across which the information is being propagated can increase considerably? I don't insist on this, I'm only raising it as a point to consider.


Nits and very minor comments --

12. The document talks about new this, new that. This probably won't age well -- keep in mind that the RFC this document will become will be around for decades, at which point none of this stuff will be "new".

It's obviously not a big deal but if it were my document I'd find a way to rewrite those "new" in a way that won't be instantly obsolete.

13. In §4,

                                The application-specific attribute
  value received via sub-TLVs within the ASLA TLV have preference over
  the value received via the top-level TLVs.
 
There's an agreement in number problem here -- perhaps rewrite as "An application-specific attribute value received via a sub-TLV within the ASLA TLV has precedence over the value received via a top-level TLV"?

[Ballot comment]
Thanks for all the work to help clear up my DISCUSS!

Previous DISCUSS:

I'd like to DISCUSS some questions I have about the content of Section 4's IS-IS rules. I don't expect it will be difficult to resolve these, I just want to be sure we have the conversation.

1. In §4 (2.C),

      C.  The SRLGs advertised in IS-IS SRLG ASLA TLVs and the other
          link attributes advertised in IS-IS ASLA sub-TLVs are
          REQUIRED to be collated, on a per-application basis, for all
          applications that have their bit set in the SABM/UDABM in at
          least one of the aforementioned TLV types.
         
Is there some reason that there's no need to consider the case where both of the TLV types in question have zero-length application bit masks?

2. Later in the same paragraph,

                                                      When performing
          this collation, only the TLVs with the application's bit set
          in SABM/UDABM MUST be used when such TLVs are available from
          either TLV types.

I suspect you aren't saying what you mean, and the "only... MUST" construct is hard to puzzle out. Do you perhaps mean TLVs that don’t have the application's bit set MUST NOT be used? Because as you've written it,

- All TLVs with the bit set MUST be collated,
- Any TLVs without the bit set MAY be collated (by implication). Which doesn't seem very sensible AFAICT.

A possible rewrite, if I've understood your intention correctly, might be "When performing this collation, every TLV with the application's bit set in SABM/UDABM MUST be included, when such TLVs are available from either TLV type."

(Note also a minor fix for agreement in number, s/types/type/ in the last word.)

3. And still later in the same paragraph,

                              If the bit for an application is set in
          the SABM/UDABM of only one of the TLV types, then the
          attributes from the other TLV type with zero-length
          application bit mask MUST be also collated for that
          application, if such TLV is available.

I'm confused by the reference to a zero-length application bit mask. Can't the other TLV type have a nonzero-length application bit mask, but still have the application bit in question not set within the bit mask?

I guess probably what you mean is, if the other TLV type is present and has a zero-length application bit mask, since a zero-length SABM/UDABM basically is a wildcard, the equivalent of all bits being set (as I read RFC 8920).

If that's right, then a change seems in order, along the lines of

                              If the bit for an application is set in
          the SABM/UDABM of only one of the TLV types, and if the
          other TLV type has a zero-length application bit mask, then the
          attributes from the other TLV type with zero-length
          application bit mask MUST be also collated for that
          application, if such TLV is available.

I just interpolated the "and" clause. It's a bit wordy and could probably be further condensed, but I think it clarifies sufficiently.

On the other hand, if I'm not right about this (very possible) then I'd appreciate further discussion on what I got wrong, so we can figure out if the text needs clarification or if I just need a clue bat.

Previous COMMENT:

4. In §2 you reference "SABML". I was going to ask you to expand it on first use, but you only use it once. So, please just write it out in words as "SABM Length" and don't introduce an extra acronym.

5. In §3:

  All the BGP-LS Attribute TLVs defined in the table above are REQUIRED
  to be advertised as a top-level TLV in the BGP-LS Attribute for
  carrying link attributes specific to RSVP-TE.

I suggest “... when used to carry” instead of “... for carrying”. Also, “listed in the table”, not defined in it.

6. Much of §4 is dedicated to a special case for IS-IS:

  2.  In the case of IS-IS, the following specific procedures are to be
      followed:

It would be nice to spend a few words mentioning why IS-IS needs a special case and OSPF doesn't, so that the reader doesn't have to wonder. I'm guessing that this relates to the way IS-IS uses sub-TLVs for various things whereas OSPF doesn't, so you need rules to reconcile the values in IS-IS but not OSPF?

7. §4 (2.B) needs some adjectives, "IS-IS" and "BGP-LS", respectively, to make clear which flavor of "ASLA sub-TLV" you're talking about. I *think* that here,

      B.  When the ASLA sub-TLV has the RSVP-TE application bit set,
          then the link attributes for the corresponding ASLA sub-TLV
          MUST be encoded using the respective BGP-LS top-level TLVs as
          per [RFC7752] [RFC8571] [RFC9104].
         
the first reference to "ASLA sub-TLV" is the IS-IS flavor, and the second is to the BGP-LS flavor --  but please be specific.

8. In §4,

  These rules ensure that a BGP-LS originator performs the
  advertisement for all application-specific link attributes from the
  IGP nodes that support or do not support the ASLA extension.

I don't understand this sentence. :-( For one thing, applying simple logic to "IGP nodes that support or do not support the ASLA extension" we can rewrite it as "IGP nodes", full stop, since "support or do not support" covers the entire universe by definition. That would imply the sentence could be rewritten as

  These rules ensure that a BGP-LS originator performs the
  advertisement for all application-specific link attributes from the
  IGP nodes.
 
Which doesn't really help me. :-(

9. In §5,

  It is recommended that nodes supporting this specification are
  selected as originators of BGP-LS information when advertising the
  link-state information from the IGPs.

Do you mean only such nodes should be selected? Or is it that at least one such should be among those selected? Either is supportable, I think. Whatever the answer, please clarify the text correspondingly. Although, more generally I guess BGP-LS originators ought to support all the extensions in use in a given IGP, not limited to this one, so this is really a special case of a general principle.

10. In §5,

                                    They would, however, not be able to
  support neither the application-specific link attributes nor newer
  applications that may be encoded only using the ASLA TLV.
 
Drop the "not". Also, again this seems like a special case of a general principle -- of course a BGP-LS consumer that doesn't understand a given extension can't do the thing that the extension covers. But, it's fine to remind the reader of this.

11. In §8,

                            It is assumed that the IGP instances
  originating these TLVs will support all the required security (as
  described in [RFC8919] and [RFC8920]) to prevent any security issues
  when propagating the TLVs into BGP-LS.
 
I think purporting to "prevent any security issues" is a case of seriously overpromising. A very similar issue existed in draft-ietf-idr-bgp-ls-sbfd-extensions-08. Perhaps a similar fix could be applied, although in this case, when I took a quick look at RFCs 8919 and 8920 I didn't find any "required security" of note, so I'm really not sure what if anything is being actually promised by this sentence? Can you help me understand what properties I should be expecting?

In any case, for the most part it seems fine to say your security model is the same as that of RFCs 8919 and 8920, since as we know BGP-LS tries to be just a re-rendering of the data from those suppliers. But, we should keep in mind this consideration from RFC 7752:

  Additionally, it may be considered that the export of link-state and
  TE information as described in this document constitutes a risk to
  confidentiality of mission-critical or commercially sensitive
  information about the network. 

Might it be worth reminding the reader that if there's any sensitive information contained in the new stuff you're propagating, they should take this warning to heart, since the scope across which the information is being propagated can increase considerably? I don't insist on this, I'm only raising it as a point to consider.


Nits and very minor comments --

12. The document talks about new this, new that. This probably won't age well -- keep in mind that the RFC this document will become will be around for decades, at which point none of this stuff will be "new".

It's obviously not a big deal but if it were my document I'd find a way to rewrite those "new" in a way that won't be instantly obsolete.

13. In §4,

                                The application-specific attribute
  value received via sub-TLVs within the ASLA TLV have preference over
  the value received via the top-level TLVs.
 
There's an agreement in number problem here -- perhaps rewrite as "An application-specific attribute value received via a sub-TLV within the ASLA TLV has precedence over the value received via a top-level TLV"?

[Ballot comment]
I've chosen to put these in as comments rather than discuss positions for now, since I don't necessarily think these comments should be blocking in nature, just there for due consideration.

In Section 2 second paragraph you have:

The format of this TLV is as follows and is similar to the
  corresponding ASLA sub-TLVs defined for OSPF and IS-IS in [RFC8920]
  and [RFC8919] respectively.

This gets a little confusing where further down only one of these RFC's is referenced as follows:

o  SABM Length : 1 octet field carrying the Standard Application
      Identifier Bit Mask Length in octets as defined in [RFC8920].
  o  UDABM Length : 1 octet field carrying the User-Defined Application
      Identifier Bit Mask Length in octets as defined in [RFC8920].
o  User-Defined Application Identifier Bit Mask : An optional set of
      bits (of size 0, 4, or 8 octets as indicated by the UDABM Length),
      where each bit represents a single user-defined application as
      defined in [RFC8919].

Various instances of this - Would the authors consider referencing both RFC's at each point so that readers are aware that the same thing applies across both ISIS and OSPF.

[Ballot comment]
Huge thanks to Scott Bradner for his OpsDir review of this document ( https://datatracker.ietf.org/doc/review-ietf-idr-bgp-ls-app-specific-attr-04-opsdir-early-bradner-2021-02-16/ ).
Due to a confluence of events, I was not able to do my regular level of review, and so, other than a quick skim of the document, I'm balloting based almost entirely on his review.

[Ballot comment]
Thank you to Paul Wouters for the SECDIR review.

** Section 2.  There is no text describing the Reserved bits.  Perhaps:

NEW
Reserved: This field is reserved.  It MUST be set to zero on transmission and MUST be ignored on receipt.

** Section 8.
It is assumed that the IGP instances
  originating these TLVs will support all the required security (as
  described in [RFC8919] and [RFC8920]) to prevent any security issues
  when propagating the TLVs into BGP-LS.

I concur with John Scudder’s analysis of this text and where it could use improvement.  He eloquently described it already so I won’t repeat it here.

[Ballot comment]
Thank you for the work on this document.

Many thanks to Kirsty Paine for her ART ART review: https://mailarchive.ietf.org/arch/msg/art/Gp7TtdCUrbmf6WJy4ATcmN_DYQI/, and thanks to the authors for addressing her comment.

Francesca

[Ballot comment]
Thank you for the work put into this document.

Special thanks to Keyur Patel for the shepherd's write-up including the WG consensus but I would have appreciated to see more about the intended status though.

[Ballot discuss]
I'd like to DISCUSS some questions I have about the content of Section 4's IS-IS rules. I don't expect it will be difficult to resolve these, I just want to be sure we have the conversation.

1. In §4 (2.C),

      C.  The SRLGs advertised in IS-IS SRLG ASLA TLVs and the other
          link attributes advertised in IS-IS ASLA sub-TLVs are
          REQUIRED to be collated, on a per-application basis, for all
          applications that have their bit set in the SABM/UDABM in at
          least one of the aforementioned TLV types.
         
Is there some reason that there's no need to consider the case where both of the TLV types in question have zero-length application bit masks?

2. Later in the same paragraph,

                                                      When performing
          this collation, only the TLVs with the application's bit set
          in SABM/UDABM MUST be used when such TLVs are available from
          either TLV types.

I suspect you aren't saying what you mean, and the "only... MUST" construct is hard to puzzle out. Do you perhaps mean TLVs that don’t have the application's bit set MUST NOT be used? Because as you've written it,

- All TLVs with the bit set MUST be collated,
- Any TLVs without the bit set MAY be collated (by implication). Which doesn't seem very sensible AFAICT.

A possible rewrite, if I've understood your intention correctly, might be "When performing this collation, every TLV with the application's bit set in SABM/UDABM MUST be included, when such TLVs are available from either TLV type."

(Note also a minor fix for agreement in number, s/types/type/ in the last word.)

3. And still later in the same paragraph,

                              If the bit for an application is set in
          the SABM/UDABM of only one of the TLV types, then the
          attributes from the other TLV type with zero-length
          application bit mask MUST be also collated for that
          application, if such TLV is available.

I'm confused by the reference to a zero-length application bit mask. Can't the other TLV type have a nonzero-length application bit mask, but still have the application bit in question not set within the bit mask?

I guess probably what you mean is, if the other TLV type is present and has a zero-length application bit mask, since a zero-length SABM/UDABM basically is a wildcard, the equivalent of all bits being set (as I read RFC 8920).

If that's right, then a change seems in order, along the lines of

                              If the bit for an application is set in
          the SABM/UDABM of only one of the TLV types, and if the
          other TLV type has a zero-length application bit mask, then the
          attributes from the other TLV type with zero-length
          application bit mask MUST be also collated for that
          application, if such TLV is available.

I just interpolated the "and" clause. It's a bit wordy and could probably be further condensed, but I think it clarifies sufficiently.

On the other hand, if I'm not right about this (very possible) then I'd appreciate further discussion on what I got wrong, so we can figure out if the text needs clarification or if I just need a clue bat.

[Ballot comment]
4. In §2 you reference "SABML". I was going to ask you to expand it on first use, but you only use it once. So, please just write it out in words as "SABM Length" and don't introduce an extra acronym.

5. In §3:

  All the BGP-LS Attribute TLVs defined in the table above are REQUIRED
  to be advertised as a top-level TLV in the BGP-LS Attribute for
  carrying link attributes specific to RSVP-TE.

I suggest “... when used to carry” instead of “... for carrying”. Also, “listed in the table”, not defined in it.

6. Much of §4 is dedicated to a special case for IS-IS:

  2.  In the case of IS-IS, the following specific procedures are to be
      followed:

It would be nice to spend a few words mentioning why IS-IS needs a special case and OSPF doesn't, so that the reader doesn't have to wonder. I'm guessing that this relates to the way IS-IS uses sub-TLVs for various things whereas OSPF doesn't, so you need rules to reconcile the values in IS-IS but not OSPF?

7. §4 (2.B) needs some adjectives, "IS-IS" and "BGP-LS", respectively, to make clear which flavor of "ASLA sub-TLV" you're talking about. I *think* that here,

      B.  When the ASLA sub-TLV has the RSVP-TE application bit set,
          then the link attributes for the corresponding ASLA sub-TLV
          MUST be encoded using the respective BGP-LS top-level TLVs as
          per [RFC7752] [RFC8571] [RFC9104].
         
the first reference to "ASLA sub-TLV" is the IS-IS flavor, and the second is to the BGP-LS flavor --  but please be specific.

8. In §4,

  These rules ensure that a BGP-LS originator performs the
  advertisement for all application-specific link attributes from the
  IGP nodes that support or do not support the ASLA extension.

I don't understand this sentence. :-( For one thing, applying simple logic to "IGP nodes that support or do not support the ASLA extension" we can rewrite it as "IGP nodes", full stop, since "support or do not support" covers the entire universe by definition. That would imply the sentence could be rewritten as

  These rules ensure that a BGP-LS originator performs the
  advertisement for all application-specific link attributes from the
  IGP nodes.
 
Which doesn't really help me. :-(

9. In §5,

  It is recommended that nodes supporting this specification are
  selected as originators of BGP-LS information when advertising the
  link-state information from the IGPs.

Do you mean only such nodes should be selected? Or is it that at least one such should be among those selected? Either is supportable, I think. Whatever the answer, please clarify the text correspondingly. Although, more generally I guess BGP-LS originators ought to support all the extensions in use in a given IGP, not limited to this one, so this is really a special case of a general principle.

10. In §5,

                                    They would, however, not be able to
  support neither the application-specific link attributes nor newer
  applications that may be encoded only using the ASLA TLV.
 
Drop the "not". Also, again this seems like a special case of a general principle -- of course a BGP-LS consumer that doesn't understand a given extension can't do the thing that the extension covers. But, it's fine to remind the reader of this.

11. In §8,

                            It is assumed that the IGP instances
  originating these TLVs will support all the required security (as
  described in [RFC8919] and [RFC8920]) to prevent any security issues
  when propagating the TLVs into BGP-LS.
 
I think purporting to "prevent any security issues" is a case of seriously overpromising. A very similar issue existed in draft-ietf-idr-bgp-ls-sbfd-extensions-08. Perhaps a similar fix could be applied, although in this case, when I took a quick look at RFCs 8919 and 8920 I didn't find any "required security" of note, so I'm really not sure what if anything is being actually promised by this sentence? Can you help me understand what properties I should be expecting?

In any case, for the most part it seems fine to say your security model is the same as that of RFCs 8919 and 8920, since as we know BGP-LS tries to be just a re-rendering of the data from those suppliers. But, we should keep in mind this consideration from RFC 7752:

  Additionally, it may be considered that the export of link-state and
  TE information as described in this document constitutes a risk to
  confidentiality of mission-critical or commercially sensitive
  information about the network. 

Might it be worth reminding the reader that if there's any sensitive information contained in the new stuff you're propagating, they should take this warning to heart, since the scope across which the information is being propagated can increase considerably? I don't insist on this, I'm only raising it as a point to consider.


Nits and very minor comments --

12. The document talks about new this, new that. This probably won't age well -- keep in mind that the RFC this document will become will be around for decades, at which point none of this stuff will be "new".

It's obviously not a big deal but if it were my document I'd find a way to rewrite those "new" in a way that won't be instantly obsolete.

13. In §4,

                                The application-specific attribute
  value received via sub-TLVs within the ASLA TLV have preference over
  the value received via the top-level TLVs.
 
There's an agreement in number problem here -- perhaps rewrite as "An application-specific attribute value received via a sub-TLV within the ASLA TLV has precedence over the value received via a top-level TLV"?

[Ballot comment]
Hi,

Thanks for the manageability considerations section.

Only one minor nit in section 5.  Deployment Considerations

  They would, however, not be able to
  support neither the application-specific link attributes nor newer
  applications that may be encoded only using the ASLA TLV.

I think that the "not" here is incorrect and should be deleted.

Rob

[Ballot comment]
# GEN AD review of draft-ietf-idr-bgp-ls-app-specific-attr-11

CC @larseggert

Thanks to Russ Housley for the General Area Review Team (Gen-ART) review
(https://mailarchive.ietf.org/arch/msg/gen-art/T9RNz1ar99diDYpCMY75m1asL2w).

## Comments

### Section 2, paragraph 5
```
    where:
```
It might be helpful to state the length of the (fixed-length) fields in
the bullet list below, so readers don't have to count bits in Figure 1.

### Inclusive language

Found terminology that should be reviewed for inclusivity; see
https://www.rfc-editor.org/part2/#inclusive_language for background and more
guidance:

* Term `traditional`; alternatives might be `classic`, `classical`, `common`,
  `conventional`, `customary`, `fixed`, `habitual`, `historic`,
  `long-established`, `popular`, `prescribed`, `regular`, `rooted`,
  `time-honored`, `universal`, `widely used`, `widespread`

## Nits

All comments below are about very minor potential issues that you may choose to
address in some way - or ignore - as you see fit. Some were flagged by
automated tools (via https://github.com/larseggert/ietf-reviewtool), so there
will likely be some false positives. There is no need to let me know what you
did with these suggestions.

### Boilerplate

Document still refers to the "Simplified BSD License", which was corrected in
the TLP on September 21, 2021. It should instead refer to the "Revised BSD
License".

### Grammar/style

#### Section 2, paragraph 14
```
rlying IGPs are also encoded in a similar manner in BGP-LS. The following ta
                            ^^^^^^^^^^^^^^^^^^^
```
Consider replacing this phrase with the adverb "similarly" to avoid wordiness.

## Notes

This review is in the ["IETF Comments" Markdown format][ICMF], You can use the
[`ietf-comments` tool][ICT] to automatically convert this review into
individual GitHub issues. Review generated by the [`ietf-reviewtool`][IRT].

[ICMF]: https://github.com/mnot/ietf-comments/blob/main/format.md
[ICT]: https://github.com/mnot/ietf-comments
[IRT]: https://github.com/larseggert/ietf-reviewtool

(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

The IANA Functions Operator has completed its review of draft-ietf-idr-bgp-ls-app-specific-attr-10. If any part of this review is inaccurate, please let us know.

The IANA Functions Operator understands that, upon approval of this document, there is a single action which we must complete.

In the BGP-LS Node Descriptor, Link Descriptor, Prefix Descriptor, and Attribute TLVs registry on the Border Gateway Protocol - Link State (BGP-LS) Parameters registry page located at:

https://www.iana.org/assignments/bgp-ls-parameters/

the existing, temporary registration for:

TLV Code Point: 1122
Description: Application-Specific Link Attributes TLV

will be made permanent and its reference changed to [ RFC-to-be ].

The IANA Functions Operator understands that this is the only action required to be completed upon approval of this document.

Note:  The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is meant only to confirm the list of actions that will be performed.

For definitions of IANA review states, please see:

https://datatracker.ietf.org/help/state/draft/iana-review

Thank you,

Michelle Thangtamsatid
IANA Services Specialist

The following Last Call announcement was sent out (ends 2022-05-13):

From: The IESG
To: IETF-Announce
CC: aretana.ietf@gmail.com, draft-ietf-idr-bgp-ls-app-specific-attr@ietf.org, idr-chairs@ietf.org, idr@ietf.org, keyur@arrcus.com, shares@ndzh.com
Reply-To: last-call@ietf.org
Sender:
Subject: Last Call:  (Application-Specific Attributes Advertisement with BGP Link-State) to Proposed Standard


The IESG has received a request from the Inter-Domain Routing WG (idr) to
consider the following document: - 'Application-Specific Attributes
Advertisement with BGP Link-State'
  as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive comments to the
last-call@ietf.org mailing lists by 2022-05-13. Exceptionally, comments may
be sent to iesg@ietf.org instead. In either case, please retain the beginning
of the Subject line to allow automated sorting.

Abstract


  Various link attributes have been defined in link-state routing
  protocols like OSPF and IS-IS in the context of the MPLS Traffic
  Engineering (TE) and GMPLS.  BGP Link-State (BGP-LS) extensions have
  been defined to distribute these attributes along with other topology
  information from these link-state routing protocols.

  New extensions have been defined for link-state routing protocols
  that enable distribution of application-specific link attributes for
  existing as well as newer applications such as Segment Routing.  This
  document defines extensions to BGP-LS to enable the advertisement of
  these application-specific attributes as a part of the topology
  information from the network.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-idr-bgp-ls-app-specific-attr/



No IPR declarations have been submitted directly on this I-D.

As required by RFC 4858, this is the current template for the Document
Shepherd Write-Up. Changes are expected over time.

This version is dated May 2, 2021.

(1) What type of RFC is being requested?  Why is this the proper type of RFC?  Is this type of RFC indicated in the title page header?

Proposed Standard.

(2) The IESG approval announcement includes a Document Announcement Write-Up.
Please provide such a Document Announcement Write-Up.
Recent examples can be found in the "Action" announcements for approved documents.

Technical Summary:
  Various link attributes have been defined in link-state routing
  protocols like OSPF and IS-IS in the context of the MPLS Traffic
  Engineering (TE) and GMPLS.  BGP Link-State (BGP-LS) extensions have
  been defined to distribute these attributes along with other topology
  information from these link-state routing protocols.  Many of these
  link attributes can be used for applications other than MPLS-TE or
  GMPLS.

  Extensions to link-state routing protocols have been defined for such
  link attributes that enable distribution of their application-
  specific values.  This document defines extensions to BGP-LS address-
  family to enable advertisement of these application-specific
  attributes as a part of the topology information from the network.

Working Group Summary:

The working group provided a normal consensus for BGP-LS drafts. This document has also passed Rtgdir and Opsdir reviews.

Document Quality:
Implementations: 2 implementations
https://trac.ietf.org/trac/idr/wiki/draft-ietf-idr-bgp-ls-app-specific-attr%20implementations

Note: 1 vendor has two different implementations.
WG was fine with single vendor


Personnel:

Who is the Document Shepherd? Keyur Patel
Who is the Responsible Area Director?  Alvaro Retana

(3) Briefly describe the review of this document that was performed by the Document Shepherd.
This document has been through the working group review and has received and incorporated all the necessary comments.  This document has also been reviewed by Andy Smith and Himanshu Shah as part of Rtgdir review and Scott Bradner as part of Opsdir review.

(4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed?
No.

(5) Do portions of the document need review from a particular or from broader perspective, e.g., security,
operational complexity, AAA, DNS, DHCP, XML, or internationalization? If so, describe the review that took place.

No.

(6) Describe any specific concerns or issues that the Document Shepherd has with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here.

No concerns.

(7) Has each author confirmed that any and all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have already been filed. If not, explain why?
  Ketan Talaulikar:
  https://mailarchive.ietf.org/arch/msg/idr/_9y0FOv86CD65LISiQNlioyehCI/

  Peter Psenak
  https://mailarchive.ietf.org/arch/msg/idr/Jh7eUcNUT6whcBTi_Opy6adZYW8/

  Jeff Tantsura
  https://mailarchive.ietf.org/arch/msg/idr/s4Hw-9cbl1zW4tN14JovVZ0H1NA/

(8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures.

No IPR disclosures.

(9) How solid is the WG consensus behind this document?
Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it?

The feedback on the document is strong from core group of BGP-LS IDR participants.

(10) Has anyone threatened an appeal or otherwise indicated extreme discontent?
If so, please summarise the areas of conflict in separate email messages to the Responsible Area Director.
(It should be in a separate email because this questionnaire is publicly available.)

no conflict.

(11) Identify any ID nits the Document Shepherd has found in this document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). Boilerplate checks are not enough; this check needs to be thorough.

no nits.

(12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.

no formal review required.

(13) Have all references within this document been identified as either normative or informative?

Yes.

(14) Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the plan for their completion?

No.

(15) Are there downward normative references references (see RFC 3967)? If so, list these downward references to support the Area Director in the Last Call procedure.

No.

(16) Will publication of this document change the status of any existing RFCs? Are those RFCs listed on the title page header, listed in the abstract, and discussed in the introduction? If the RFCs are not listed in the Abstract and Introduction, explain why, and point to the part of the document where the relationship of this document to the other RFCs is discussed. If this information is not in the document, explain why the WG considers it unnecessary.

No.

(17) Describe the Document Shepherd's review of the IANA considerations section, especially with regard to its consistency with the body of the document.

Confirm that all protocol extensions that the document makes are associated with the appropriate reservations in IANA registries.
Confirm that any referenced IANA registries have been clearly identified.
Confirm that newly created IANA registries include a detailed specification of the initial contents for the registry,
that allocations procedures for future registrations are defined, and a reasonable name for the new registry has been suggested (see RFC 8126).

New values in registry:    "BGP-LS Node Descriptor, Link Descriptor, Prefix Descriptor, and Attribute TLVs". 

This document requests allocation of code-point 1122 for Application-specific Link Attributes TLV from the above mentioned registries.

(18) List any new IANA registries that require Expert Review for future allocations.
Provide any public guidance that the IESG would find useful in selecting the IANA Experts for these new registries.

No new registries.

(19) Describe reviews and automated checks performed by the Document Shepherd to validate sections of the
document written in a formal language, such as XML code, BNF rules, MIB definitions, YANG modules, etc.

No formal language.

(20) If the document contains a YANG module, has the module been checked with any of the recommended
validation tools (https://trac.ietf.org/trac/ops/wiki/yang-review-tools) for syntax and formatting validation?
If there are any resulting errors or warnings, what is the justification for not fixing them at this time?
Does the YANG module comply with the Network Management Datastore Architecture (NMDA) as specified in RFC8342?

No Yang modules needed.

As required by RFC 4858, this is the current template for the Document
Shepherd Write-Up. Changes are expected over time.

This version is dated May 2, 2021.

(1) What type of RFC is being requested?  Why is this the proper type of RFC?  Is this type of RFC indicated in the title page header?

Proposed Standard.

(2) The IESG approval announcement includes a Document Announcement Write-Up.
Please provide such a Document Announcement Write-Up.
Recent examples can be found in the "Action" announcements for approved documents.

Technical Summary:
  Various link attributes have been defined in link-state routing
  protocols like OSPF and IS-IS in the context of the MPLS Traffic
  Engineering (TE) and GMPLS.  BGP Link-State (BGP-LS) extensions have
  been defined to distribute these attributes along with other topology
  information from these link-state routing protocols.  Many of these
  link attributes can be used for applications other than MPLS-TE or
  GMPLS.

  Extensions to link-state routing protocols have been defined for such
  link attributes that enable distribution of their application-
  specific values.  This document defines extensions to BGP-LS address-
  family to enable advertisement of these application-specific
  attributes as a part of the topology information from the network.

Working Group Summary:

The working group provided a normal consensus for BGP-LS drafts. This document has also passed Rtgdir and Opsdir reviews.

Document Quality:
Implementations: 2 implementations
https://trac.ietf.org/trac/idr/wiki/draft-ietf-idr-bgp-ls-app-specific-attr%20implementations

Note: 1 vendor has two different implementations.
WG was fine with single vendor


Personnel:

Who is the Document Shepherd? Keyur Patel
Who is the Responsible Area Director?  Alvaro Retana

(3) Briefly describe the review of this document that was performed by the Document Shepherd.
This document has been through the working group review and has received and incorporated all the necessary comments.  This document has also been reviewed by Andy Smith and Himanshu Shah as part of Rtgdir review and Scott Bradner as part of Opsdir review.

(4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed?
No.

(5) Do portions of the document need review from a particular or from broader perspective, e.g., security,
operational complexity, AAA, DNS, DHCP, XML, or internationalization? If so, describe the review that took place.

No.

(6) Describe any specific concerns or issues that the Document Shepherd has with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here.

No concerns.

(7) Has each author confirmed that any and all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have already been filed. If not, explain why?
  Ketan Talaulikar:
  https://mailarchive.ietf.org/arch/msg/idr/_9y0FOv86CD65LISiQNlioyehCI/

  Peter Psenak
  https://mailarchive.ietf.org/arch/msg/idr/Jh7eUcNUT6whcBTi_Opy6adZYW8/

  Jeff Tantsura
  https://mailarchive.ietf.org/arch/msg/idr/s4Hw-9cbl1zW4tN14JovVZ0H1NA/

(8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures.

No IPR disclosures.

(9) How solid is the WG consensus behind this document?
Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it?

The feedback on the document is strong from core group of BGP-LS IDR participants.

(10) Has anyone threatened an appeal or otherwise indicated extreme discontent?
If so, please summarise the areas of conflict in separate email messages to the Responsible Area Director.
(It should be in a separate email because this questionnaire is publicly available.)

no conflict.

(11) Identify any ID nits the Document Shepherd has found in this document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). Boilerplate checks are not enough; this check needs to be thorough.

no nits.

(12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.

no formal review required.

(13) Have all references within this document been identified as either normative or informative?

Yes.

(14) Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the plan for their completion?

No.

(15) Are there downward normative references references (see RFC 3967)? If so, list these downward references to support the Area Director in the Last Call procedure.

No.

(16) Will publication of this document change the status of any existing RFCs? Are those RFCs listed on the title page header, listed in the abstract, and discussed in the introduction? If the RFCs are not listed in the Abstract and Introduction, explain why, and point to the part of the document where the relationship of this document to the other RFCs is discussed. If this information is not in the document, explain why the WG considers it unnecessary.

No.

(17) Describe the Document Shepherd's review of the IANA considerations section, especially with regard to its consistency with the body of the document.

Confirm that all protocol extensions that the document makes are associated with the appropriate reservations in IANA registries.
Confirm that any referenced IANA registries have been clearly identified.
Confirm that newly created IANA registries include a detailed specification of the initial contents for the registry,
that allocations procedures for future registrations are defined, and a reasonable name for the new registry has been suggested (see RFC 8126).

New values in registry:    "BGP-LS Node Descriptor, Link Descriptor, Prefix Descriptor, and Attribute TLVs". 

This document requests allocation of code-point 1122 for Application-specific Link Attributes TLV from the above mentioned registries.

(18) List any new IANA registries that require Expert Review for future allocations.
Provide any public guidance that the IESG would find useful in selecting the IANA Experts for these new registries.

No new registries.

(19) Describe reviews and automated checks performed by the Document Shepherd to validate sections of the
document written in a formal language, such as XML code, BNF rules, MIB definitions, YANG modules, etc.

No formal language.

(20) If the document contains a YANG module, has the module been checked with any of the recommended
validation tools (https://trac.ietf.org/trac/ops/wiki/yang-review-tools) for syntax and formatting validation?
If there are any resulting errors or warnings, what is the justification for not fixing them at this time?
Does the YANG module comply with the Network Management Datastore Architecture (NMDA) as specified in RFC8342?

No Yang modules needed.

As required by RFC 4858, this is the current template for the Document
Shepherd Write-Up. Changes are expected over time.

This version is dated 1 November 2019.

(1) What type of RFC is being requested: Proposed Standard:

Why is this the proper type of RFC?
Is this type of RFC indicated in the title page header?

(2) The IESG approval announcement includes a Document Announcement Write-Up.
Please provide such a Document Announcement Write-Up.
Recent examples can be found in the "Action" announcements for approved documents.

Technical Summary:
  Various link attributes have been defined in link-state routing
  protocols like OSPF and IS-IS in the context of the MPLS Traffic
  Engineering (TE) and GMPLS.  BGP Link-State (BGP-LS) extensions have
  been defined to distribute these attributes along with other topology
  information from these link-state routing protocols.  Many of these
  link attributes can be used for applications other than MPLS-TE or
  GMPLS.

  Extensions to link-state routing protocols have been defined for such
  link attributes that enable distribution of their application-
  specific values.  This document defines extensions to BGP-LS address-
  family to enable advertisement of these application-specific
  attributes as a part of the topology information from the network.

  [Keyur - You may want to add additional details here]

Working Group Summary:

The working group provided a normal consensus for BGP-LS drafts.


Document Quality:
Implementations: 2 implementations
https://trac.ietf.org/trac/idr/wiki/draft-ietf-idr-bgp-ls-app-specific-attr%20implementations

Note: 1 vendor has two different implementations.
WG was fine with single vendor
[You may have to query again on the list.]

Personnel:

Who is the Document Shepherd? Keyur Patel
Who is the Responsible Area Director?  Alvaro Retana

(3) Briefly describe the review of this document that was performed by the Document Shepherd.
(TBD)

(4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed?
(TBD) -
[Sue's note: Early reviews have been requested from RTG-DIR, OPS-DIR, and SEC-DIR - due on 2/19/2021]
Usually it takes 40+ days to get to the bottom of Alvaro's queue - so it helps to get an early review in
case there are problems. ]

(5) Do portions of the document need review from a particular or from broader perspective, e.g., security,
operational complexity, AAA, DNS, DHCP, XML, or internationalization? If so, describe the review that took place.

[TBD] - no is generally my answer

(6) Describe any specific concerns or issues that the Document Shepherd has with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here.

(TBD)

(7) Has each author confirmed that any and all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have already been filed. If not, explain why?
  Ketan Talaulikar:
  https://mailarchive.ietf.org/arch/msg/idr/_9y0FOv86CD65LISiQNlioyehCI/

  Peter Psenak
  https://mailarchive.ietf.org/arch/msg/idr/Jh7eUcNUT6whcBTi_Opy6adZYW8/

  Jeff Tantsura
  https://mailarchive.ietf.org/arch/msg/idr/s4Hw-9cbl1zW4tN14JovVZ0H1NA/

(8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures.
No IPR disclosures

(9) How solid is the WG consensus behind this document?
Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it?

Solid group of BGP-LS IDR participants


(10) Has anyone threatened an appeal or otherwise indicated extreme discontent?
If so, please summarise the areas of conflict in separate email messages to the Responsible Area Director.
(It should be in a separate email because this questionnaire is publicly available.)

no conflict.

(11) Identify any ID nits the Document Shepherd has found in this document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). Boilerplate checks are not enough; this check needs to be thorough.
(TBD)

(12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.
(no formal review required)

(13) Have all references within this document been identified as either normative or informative?
(TBD)

(14) Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the plan for their completion?
(TBD)

(15) Are there downward normative references references (see RFC 3967)? If so, list these downward references to support the Area Director in the Last Call procedure.
(TBD)

(16) Will publication of this document change the status of any existing RFCs? Are those RFCs listed on the title page header, listed in the abstract, and discussed in the introduction? If the RFCs are not listed in the Abstract and Introduction, explain why, and point to the part of the document where the relationship of this document to the other RFCs is discussed. If this information is not in the document, explain why the WG considers it unnecessary.
(no new features)

(17) Describe the Document Shepherd's review of the IANA considerations section, especially with regard to its consistency with the body of the document.

Confirm that all protocol extensions that the document makes are associated with the appropriate reservations in IANA registries.
Confirm that any referenced IANA registries have been clearly identified.
Confirm that newly created IANA registries include a detailed specification of the initial contents for the registry,
that allocations procedures for future registrations are defined, and a reasonable name for the new registry has been suggested (see RFC 8126).

New values in registry:    "BGP-LS Node Descriptor, Link Descriptor, Prefix Descriptor, and Attribute TLVs"
(TBD on Check)

(18) List any new IANA registries that require Expert Review for future allocations.
Provide any public guidance that the IESG would find useful in selecting the IANA Experts for these new registries.

No new registries.

(19) Describe reviews and automated checks performed by the Document Shepherd to validate sections of the
document written in a formal language, such as XML code, BNF rules, MIB definitions, YANG modules, etc.

No formal language.

(20) If the document contains a YANG module, has the module been checked with any of the recommended
validation tools (https://trac.ietf.org/trac/ops/wiki/yang-review-tools) for syntax and formatting validation?
If there are any resulting errors or warnings, what is the justification for not fixing them at this time?
Does the YANG module comply with the Network Management Datastore Architecture (NMDA) as specified in RFC8342?

No Yang modules