Re: [Lsr] [Technical Errata Reported] RFC8919 (6630)

[[e-mail]]

Les,

Tl;DR: works for me. We are done. Thanks.

Please see inline [Bruno3]



Orange Restricted
From: Les Ginsberg (ginsberg) <[e-mail]>
Sent: Thursday, June 16, 2022 7:08 PM
To: DECRAENE Bruno INNOV/NET <[e-mail]>
Cc: Peter Psenak (ppsenak) <[e-mail]>; [e-mail]; [e-mail]; John E Drake <[e-mail]>; [e-mail]; [e-mail]; [e-mail]; John Scudder <[e-mail]>; [e-mail]; Acee Lindem (acee) <[e-mail]>
Subject: RE: [Technical Errata Reported] RFC8919 (6630)

Bruno –

Please see responses inline; [LES2}

From: [e-mail]<mailto:[e-mail]> <[e-mail]<mailto:[e-mail]>>
Sent: Thursday, June 16, 2022 8:39 AM
To: Les Ginsberg (ginsberg) <[e-mail]<mailto:[e-mail]>>
Cc: Peter Psenak (ppsenak) <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>; John E Drake <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>; John Scudder <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]>; Acee Lindem (acee) <[e-mail]<mailto:[e-mail]>>
Subject: RE: [Technical Errata Reported] RFC8919 (6630)

Les,

Thanks for considering my comments and for detail the time to answer.
Please see inline [Bruno2]



Orange Restricted
From: Les Ginsberg (ginsberg) <[e-mail]<mailto:[e-mail]>>
Sent: Wednesday, June 15, 2022 4:51 PM
To: DECRAENE Bruno INNOV/NET <[e-mail]<mailto:[e-mail]>>
Cc: Peter Psenak (ppsenak) <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>; John E Drake <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>; John Scudder <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]>; Acee Lindem (acee) <[e-mail]<mailto:[e-mail]>>
Subject: RE: [Technical Errata Reported] RFC8919 (6630)

Bruno –

Thanx for your (as always) meticulous review.
Responses inline.

From: Lsr <[e-mail]<mailto:[e-mail]>> On Behalf Of [e-mail]<mailto:[e-mail]>
Sent: Tuesday, June 14, 2022 9:12 AM
To: Les Ginsberg (ginsberg) <[e-mail]<mailto:[e-mail]>>
Cc: Peter Psenak (ppsenak) <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>; John E Drake <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>; John Scudder <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]>; Acee Lindem (acee) <[e-mail]<mailto:[e-mail]>>
Subject: Re: [Lsr] [Technical Errata Reported] RFC8919 (6630)

Les (and all co-authors)

1 ) Thank you for writing this bis draft.

2) I have reviewed the IS-IS document: both the diff and the full text.

Enclosed, to whom this may help, diff between the RFC and the draft

3) Reading the full text and trying to see how different person may interpret it, I may have further comments below.
Note that my only intention is to avoid different interpretations.

§4.2
“
   When SABM or UDABM Length is non-zero and the L-flag is NOT set, all
   applications specified in the bit mask MUST use the link attribute
   advertisements in the sub-TLV.”

I would propose to add: “They MUST NOT use legacy advertisement”
Motivation: MUST use X does not imply MUST NOT use Y.

[LES:] I think this needs to be considered in the context of multiple paragraphs. The existing text starts by discussing what to do if a single ASLA sub-TLV is present.
We have two cases:

Case 1:SABM/UDABM length is non-zero and L-flag is NOT set
The above paragraph defines what to do.

Case 2: SABM/UDABM length is non-zero and L-flag is set. The paragraph which follows the paragraph you quoted defines what to do.

The text then goes on to discuss how to handle multiple ASLA sub-TLVs. It defines “conflicts” and states what to do if a conflict occurs (use the first advertisement).
It also defines how to handle multiple advertisements for the same application – one of which has L-flag set and one of which has L-flag clear. In such a case the application MUST behave as if the L-flag is set.
I believe this covers the case you mention i.e., the defined rules make clear that both Legacy advertisements and ASLA sub-sub-TLVs cannot both be used for a given application.

I therefore do not think your suggested text is necessary.

[Bruno2] I agree that the use of ASLA attribute is well defined.
I was concerned with the use of sub-TLV not advertised in ASLA:
- before ASLA, all applications used to use the sub-TLV hosted in TLVs Advertising Neighbor Information
- my understanding is that, for a given application, once an ASLA without the L-flag is advertised, then application must stop using sub-TLVs in the TLVs Advertising Neighbor Information (rather than merge sub-TLVs present in ASLA an sub-TLVs present in TLVs Advertising Neighbor Information). IF that’s a correct understanding, I have not found the text specifying this (stop using the sub-TLV hosted in TLVs Advertising Neighbor Information).

[LES2:] How about adding the following text after the paragraphs describing the rules?

“The end result of the set of rules defined above is that for a given application either the attribute values advertised in ASLA sub-sub-TLVs are used or the attribute values advertised in Legacy sub-TLVs are used, but not both.”
[Bruno3] Works for me. Thank you.

[…]

---
§6.2


“Link attribute advertisements associated with zero-length Application
   Identifier Bit Masks for both standard applications and user-defined
   applications are usable by any application, subject to the
   restrictions specified in Section 4.2<https://datatracker.ietf.org/doc/html/draft-ginsberg-lsr-rfc8919bis#section-4.2>.  If support for a new
   application is introduced on any node in a network in the presence of
   such advertisements, the new application will use these
   advertisements, when the aforementioned restrictions are met.  If
   this is not what is intended, then existing link attribute
   advertisements MUST be readvertised with an explicit set of
   applications specified before a new application is introduced.”

Agreed.
But similarly, if zero-length application bit Mask are not used, the new application would typically not be able to use any of the existing advertisements (not having the bit set for the new application).
On the same line, I think implementations SHOULD allow, by configuration, the setting of any bit in the Bit Mask (including Applications not yet known by this implementation). This is to allow for new implementation to use advertisement from old implementations.

[LES:] You are correct – and this is what the text you have quoted discusses.
But I do not see how what you propose can be safely introduced. You are suggesting that an implementation that does not support “Application X” should provide a way to set the “X-bit” in existing ASLA advertisements that it originates. But since the implementation does not support X, it has no idea what links application X will be using nor what attributes/attribute values are valid for Application X.
??
[Bruno2] I’m proposing that the network operator could configure that an ASLA/attribute value be also usable for Application X. I’m not asking for the implementation to second guess my choice/configuration.
e.g. imaging that ASLA was written before the application “Segment Routing Policy” and that an implementation A does not support the new ASLA bit for this new application.  I feel that I would still want a transit node running implementation A to be able to signal that for application “Segment Routing Policy” I want to advertise a specific value”. That LSR does not need to know anything about the application “Segment Routing Policy”. Plus the specific value is provided and configured by the network operator.
For sure, the ingress node computing the SR Policy based on such attribute values, do need to understand the new ASLA bit.


I am guessing that what you are really concerned with is how to enable a new application in a non-disruptive manner given that two things have to happen:
a)Link attributes advertisements have to be updated to include the new Application
b)Nodes need to enable the application itself
[Bruno2] Indeed. But those two things may be needed independently on different nodes. E.g. using the above example, “b” is needed on the ingress node (or the PCE) computing the SR-Policy. “a” is needed on all transit nodes, including those which don’t know how to compute an SR-Policy. Requiring all transit nodes to support the new ASLA Standard Application bit name may be an issues in some deployments.
If feel that this is just a configuration aspect, but I’m not that familiar with the configuration. Looking on google, I’m assuming that in order to advertise a TE-metric specific for application Flex-algo, the cisco CLI is:     Router(config-isis-if-af)# te-metric flex-algo 50

If so, I’d like to be able to do :s/flex-algo/SABM 0b0001       in order to be able to configure this even if this node is not aware of the new Link Attribute  Applications X-bit (Flexible Algorithm)

        But this is a configuration capability, so no big deal if it’s not in the RFC
[LES2:]  It seems we agree that this is a configuration capability. I think this is therefore out of scope for this document.
[Bruno3] Works for me.
It also true that it is not possible to do what you suggest for all applications. Some applications (e.g., SRTE) only require application specific advertisements but do not require all nodes to be able to use them. But for other applications (e.g., flex-algo), it is of no use to advertise application specific attributes if the advertising node itself doesn’t support the application.
I hope we have closure here.
[Bruno3] yes. Thanks for discussion.

--Bruno

   Les


Thank you,
Regards,
--Bruno

How this is done is specific to an application. For example, in the case of flex-algo, it is possible to introduce ASLA advertisements for FLEX before advertising support for a given algo and/or advertising the associated FAD.
How some other application might address this issue is something that needs to be defined by the application. I don’t think this draft can define an application independent procedure.

   Les


Thank you,
Regards,
--Bruno


Orange Restricted
From: Les Ginsberg (ginsberg) <[e-mail]<mailto:[e-mail]>>
Sent: Monday, June 13, 2022 7:15 AM
To: DECRAENE Bruno INNOV/NET <[e-mail]<mailto:[e-mail]>>
Cc: Peter Psenak (ppsenak) <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>; John E Drake <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>; John Scudder <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]>; Acee Lindem (acee) <[e-mail]<mailto:[e-mail]>>
Subject: RE: [Technical Errata Reported] RFC8919 (6630)

Bruno (and everyone) –

V00 of the two bis drafts has been posted.

Name:                  draft-ginsberg-lsr-rfc8919bis
Revision:             00
Title:                     IS-IS Application-Specific Link Attributes
Document date:               2022-06-12
Group:                 Individual Submission
Pages:                  25
URL:            https://www.ietf.org/archive/id/draft-ginsberg-lsr-rfc8919bis-00.txt
Status:         https://datatracker.ietf.org/doc/draft-ginsberg-lsr-rfc8919bis/
Html:           https://www.ietf.org/archive/id/draft-ginsberg-lsr-rfc8919bis-00.html
Htmlized:       https://datatracker.ietf.org/doc/html/draft-ginsberg-lsr-rfc8919bis

Name:                  draft-ppsenak-lsr-rfc8920bis
Revision:             00
Title:                     OSPF Application-Specific Link Attributes
Document date:               2022-06-12
Group:                 Individual Submission
Pages:                  23
URL:            https://www.ietf.org/archive/id/draft-ppsenak-lsr-rfc8920bis-00.txt
Status:         https://datatracker.ietf.org/doc/draft-ppsenak-lsr-rfc8920bis/
Html:           https://www.ietf.org/archive/id/draft-ppsenak-lsr-rfc8920bis-00.html
Htmlized:       https://datatracker.ietf.org/doc/html/draft-ppsenak-lsr-rfc8920bis


If you want to see the diff from the respective RFCs, simply go to the IETF Diff tool:  https://tools.ietf.org/rfcdiff

Type “rfc8919” or “rfc8920” for “File1”.
Then provide the URL for the .txt document for the bis draft in “File2”.

   Les


From: [e-mail]<mailto:[e-mail]> <[e-mail]<mailto:[e-mail]>>
Sent: Thursday, June 2, 2022 9:26 AM
To: Les Ginsberg (ginsberg) <[e-mail]<mailto:[e-mail]>>
Cc: Peter Psenak (ppsenak) <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>; John E Drake <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>; John Scudder <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]>; Acee Lindem (acee) <[e-mail]<mailto:[e-mail]>>
Subject: RE: [Technical Errata Reported] RFC8919 (6630)

Les,

Many thanks for your diligent answer.

Looks very good to me. Thanks for doing the extra work.
(I was mainly checking whether we were not silently heading toward alternative 1 “do nothing”)

Open process/tooling question: is it possible to publish -00 and indicate that it replaces RFC8919? That way the datatracker would provide a diff compared to the existing RFC (similar to a patch draft) which would probably ease everyone’s work as I’m guessing that everyone would be interested in checking the type of change introduced, since at this point there are multiple implementations and deployments.

--Bruno



Orange Restricted
From: Les Ginsberg (ginsberg) <[e-mail]<mailto:[e-mail]>>
Sent: Thursday, June 2, 2022 6:06 PM
To: DECRAENE Bruno INNOV/NET <[e-mail]<mailto:[e-mail]>>; John Scudder <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]>; Acee Lindem (acee) <[e-mail]<mailto:[e-mail]>>
Cc: Peter Psenak (ppsenak) <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>; John E Drake <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>
Subject: RE: [Technical Errata Reported] RFC8919 (6630)

Bruno –

Thanx for following up on this.
To update you and the WG …

There was no followup/discussion to the email I sent on May 11, 2022 (which you included below).
I expressed a preference for using the Errata process.
John decided to reject the Errata – for the reasons he specified in the Errata themselves:

https://www.rfc-editor.org/errata/eid6630
https://www.rfc-editor.org/errata/eid6631

This leaves the authors in the position of choosing between two alternatives:

1)Do nothing

This clearly does not capture the clarifications which were discussed and agreed upon in the email thread:

https://mailarchive.ietf.org/arch/browse/lsr/?gbt=1&q=%22Proposed%20Errata%20for%20RFCs%208919%2F8920%22

2)Create bis drafts for the two RFCs – incorporating the agreed upon changes.

It is with some reluctance (see below) that we have decided to create bis drafts.
You can expect to see them “soon” – certainly before IETF 114.

NOTE: Personally, I do not find a “patch draft” very appealing – so not listing that as an alternative.

Why is there reluctance to create bis drafts?

Unfortunately, the IETF process as regards bis drafts, where the goal is simply clarification – not substantive changes, is overly burdensome. This is discussed in some detail in the thread below.
And the length of time required to reach new-RFC publication is typically multiple years – even when the content is not at all controversial.
As an example, see https://datatracker.ietf.org/doc/draft-ietf-lsr-isis-rfc5316bis/history/

But, we will do what we can.

   Les


From: [e-mail]<mailto:[e-mail]> <[e-mail]<mailto:[e-mail]>>
Sent: Thursday, June 2, 2022 2:51 AM
To: Les Ginsberg (ginsberg) <[e-mail]<mailto:[e-mail]>>; John Scudder <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]>; Acee Lindem (acee) <[e-mail]<mailto:[e-mail]>>
Cc: Peter Psenak (ppsenak) <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>; John E Drake <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>
Subject: RE: [Technical Errata Reported] RFC8919 (6630)

Hi Les, John, all,

Could we have an update on this?

> From: Lsr <[e-mail]<mailto:[e-mail]>> On Behalf Of John Scudder
[…]
> I think the changes could be processed either as a bis or as a so-called “patch” draft, i.e. one that looks substantially similar to the errata you submitted (a bunch of OLD: and NEW: blocks, for example) that Updates: RFC 8919.
[…]
> Do let me know if we agree in principle on this as a way forward; if so I’ll close the errata.

!! Hopefully, I’m not changing the meaning of John’s email with my above edit. Please correct me as needed.


1)      Since the errata has been closed, I’m assuming that there is an agreement to proceed with a new draft. Is this correct?

2)      Can we have a confirmation that the new draft is on its way? Possibly with an ETA?

We do faced multiple interop issues with this ASLA document, and from preliminary recent feedback this may not be over. So IMO the spec do need to be clarified.

Thanks,
--Bruno




Orange Restricted
From: Lsr <[e-mail]<mailto:[e-mail]>> On Behalf Of Les Ginsberg (ginsberg)
Sent: Wednesday, May 11, 2022 8:47 PM
To: John Scudder <jgs=[e-mail]<mailto:jgs=[e-mail]>>
Cc: Acee Lindem (acee) <[e-mail]<mailto:[e-mail]>>; Peter Psenak (ppsenak) <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>; John E Drake <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>
Subject: Re: [Lsr] [Technical Errata Reported] RFC8919 (6630)

John –

Don’t know if you have completed your review of the mailing list archives on this subject.

Given it is almost a year since the discussion, I had to review it myself. 😊
Here are some pointers:

The discussion started with an email from Bruno asking for some clarification:
https://mailarchive.ietf.org/arch/msg/lsr/DrehmMy9Ru7CNPTfAMmyCofXjTY/


This led to proposed Errata for RFC 8919/8920 – the discussion of which can be found here:

https://mailarchive.ietf.org/arch/browse/lsr/?gbt=1&q=%22Proposed%20Errata%20for%20RFCs%208919%2F8920%22

Given the protracted discussions on the drafts which became RFC 8919/8920, I am not eager to do a BIS draft simply to insert a clarification.

I do think the discussion of the Errata on the list could be considered as achieving consensus.
There are then two options:

1)Use the errata to document the clarifications

2)Use a “patch RFC”

I have never done a “patch RFC” – wasn’t even aware this option existed.  And I am not clear on how it is done procedurally – is this simply a new draft but everyone agrees to limit discussion given the “patch format”?

Frankly, I don’t see the difference between the Errata and the “patch RFC”- other than the latter is more work.
Certainly content-wise they are the same.
So your comment that Errata are only meant to address “bugs” doesn’t make it clear why a “patch RFC” is OK but an Errata that has the same textual changes is not.

I would prefer to use the Errata if possible.

Your thoughts?

    Les

From: Lsr <[e-mail]<mailto:[e-mail]>> On Behalf Of John Scudder
Sent: Tuesday, May 10, 2022 11:16 AM
To: Les Ginsberg (ginsberg) <[e-mail]<mailto:[e-mail]>>
Cc: Acee Lindem (acee) <[e-mail]<mailto:[e-mail]>>; Peter Psenak (ppsenak) <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>; John E Drake <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>
Subject: Re: [Lsr] [Technical Errata Reported] RFC8919 (6630)

Hi Les,

Yes that’s about right, except I think the changes could be processed either as a bis or as a so-called “patch” draft, i.e. one that looks substantially similar to the errata you submitted (a bunch of OLD: and NEW: blocks, for example) that Updates: RFC 8919.

The IESG has in the past discussed whether and how to avoid problems such as you describe, but so far to no effect. Because of such concerns — that even a closely-focused bis may be treated as open season for review comments unrelated to the substance of the actual changes — it’s pretty common practice for authors to use patch RFCs instead. IMO these are ugly to have floating around our document set, but our process creates a strong incentive to use them. As such, if you wanted to follow that approach I wouldn’t be against it, on the other hand if you view the bis as “the right thing” and you want to DTRT, I’d do what I can to encourage the IESG to keep their comments focused and not treat it as open season.

Hope that helps. Do let me know if we agree in principle on this as a way forward; if so I’ll close the errata.

Thanks,

—John

On May 10, 2022, at 1:08 PM, Les Ginsberg (ginsberg) <[e-mail]<mailto:[e-mail]>> wrote:


John –

If I interpret the essence of your comments correctly, you are expressing a preference that the proposed changes be handled via a BIS draft rather than an errata.

I don’t have an objection to that – and in some ways it makes sense to me.
However, I have not been pleased (in general) with the way that the IETF – and in particular the IESG review process– handles BIS drafts.
A BIS is created to address specific issues. But, based on past experience,  IESG review considers a BIS draft as an opportunity to revisit the draft in its entirety – even when that was clearly NOT the stated goal during WG review.
In a case such as this, I think the lack of agreed upon scope may be a major issue.

Any words of wisdom on this? 😊

   Les

From: John Scudder <[e-mail]<mailto:[e-mail]>>
Sent: Tuesday, May 10, 2022 9:20 AM
To: Acee Lindem (acee) <[e-mail]<mailto:[e-mail]>>; Les Ginsberg (ginsberg) <[e-mail]<mailto:[e-mail]>>
Cc: Peter Psenak (ppsenak) <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>; John E Drake <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>
Subject: Re: [Technical Errata Reported] RFC8919 (6630)

-rfc-editor

Hi All,

This kind of erratum requires careful consideration and I’d appreciate it if the WG were to weigh in. In particular, without reviewing the RFC and mailing list carefully (which I’ve not yet done, but will) it’s unclear to me if the proposed erratum meets this criterion:

“Errata are meant to fix "bugs" in the specification and should not be used to change what the community meant when it approved the RFC.” [1]

So to verify this erratum we’d need one of two things:

1. A solid reason why the erratum is a straight-up bug. An example of an erratum where this is unambiguously true is https://www.rfc-editor.org/errata/eid6866<https://urldefense.com/v3/__https:/www.rfc-editor.org/errata/eid6866__;!!NEt6yMaO-gk!DGhKp6_DX170iyhoOlLE83y4AOYlegZ0jktQIBmgAMFC0mcnlUyBUYf5awQk13zMkSQa__MPA_KloQ$>, where the RFC refers to a YANG leaf that simply doesn’t exist.
   At first reading, the present erratum isn’t obviously a bug.

2. Clear and unambiguous evidence in the written record (mainly, the mailing list archives) that the WG consensus was for what the erratum says, and not for the text in the RFC. Importantly, the authors’ saying “that is not what was intended” isn’t good enough to establish this. What must be established is what the WG had consensus for.

The bar is intentionally high for introducing changes to RFCs via the errata process. If neither of the above criteria can be fulfilled then I have to mark the erratum as rejected. In that case the recourse would be to write and process a short RFC that updates RFC 8919.

Thanks,

—John

[1] https://www.ietf.org/about/groups/iesg/statements/processing-errata-ietf-stream/<https://urldefense.com/v3/__https:/www.ietf.org/about/groups/iesg/statements/processing-errata-ietf-stream/__;!!NEt6yMaO-gk!DGhKp6_DX170iyhoOlLE83y4AOYlegZ0jktQIBmgAMFC0mcnlUyBUYf5awQk13zMkSQa__NcYIxF0g$>

On Jul 6, 2021, at 4:27 PM, Acee Lindem (acee) <[e-mail]<mailto:[e-mail]>> wrote:


LSR WG,

This Errata is an outcome of the Flex-Algorithm discussion - is there any further comment?

Thanks,
Acee

On 7/5/21, 5:48 PM, "RFC Errata System" <[e-mail]<mailto:[e-mail]>> wrote:

   The following errata report has been submitted for RFC8919,
   "IS-IS Application-Specific Link Attributes".

   --------------------------------------
   You may review the report below and at:
   https://urldefense.com/v3/__https://www.rfc-editor.org/errata/eid6630__;!!NEt6yMaO-gk!V8pyJglE5nwp2XEvvZFMfNsgQt2U2UKisYFncXzo7IFZNV_oakn0wjZ0Ak22xg$<https://urldefense.com/v3/__https:/www.rfc-editor.org/errata/eid6630__;!!NEt6yMaO-gk!V8pyJglE5nwp2XEvvZFMfNsgQt2U2UKisYFncXzo7IFZNV_oakn0wjZ0Ak22xg$>

   --------------------------------------
   Type: Technical
   Reported by: Les Ginsberg <[e-mail]<mailto:[e-mail]>>

   Section: GLOBAL

   Original Text
   -------------
   Section 4.2:
   OLD

   If the SABM or UDABM Length in the Application Identifier Bit Mask
   is greater than 8, the entire sub-TLV MUST be ignored.

   (Later in Section 4.2)
   OLD

   If link attributes are advertised associated with zero-length
   Application Identifier Bit Masks for both standard applications and
   user-defined applications, then any standard application and/or any
   user-defined application is permitted to use that set of link
   attributes so long as there is not another set of attributes
   advertised on that same link that is associated with a non-zero-length
   Application Identifier Bit Mask with a matching Application Identifier
   Bit set.

   Section 6.2
   OLD

   Link attribute advertisements associated with zero-length Application
   Identifier Bit Masks for both standard applications and user-defined
   applications are usable by any application, subject to the
   restrictions specified in Section 4.2. If support for a new
   application is introduced on any node in a network in the presence
   of such advertisements, these advertisements are permitted to
   be used by the new application. If this is not what is intended,
   then existing advertisements MUST be readvertised with an explicit
   set of applications specified before a new application is introduced.


   Corrected Text
   --------------
   Section 4.2
   NEW

   If the SABM or UDABM Length in the Application Identifier Bit Mask
   is greater than 8, the entire sub-TLV MUST be ignored.

   When SABM or UDABM Length is non-zero and the L-flag is NOT set, all
   applications specified in the bit mask MUST use the link attribute
   advertisements in the sub-TLV.

   (Later in Section 4.2)
   NEW

   Link attributes MAY be advertised associated with zero-length
   Application Identifier Bit Masks for both standard applications and
   user-defined applications. Such link attribute advertisements MUST be
   used by standard applications and/or user defined applications when
   no link attribute advertisements with a non-zero-length Application
   Identifier Bit Mask and a matching Application Identifier Bit set are
   present for a given link. Otherwise, such link attribute advertisements
   MUST NOT be used.

   Section 6.2
   NEW

   Link attributes MAY be advertised associated with zero-length
   Application Identifier Bit Masks for both standard applications and
   user-defined applications. Such link attribute advertisements MUST be
   used by standard applications and/or user defined applications when
   no link attribute advertisements with a non-zero-length Application
   Identifier Bit Mask and a matching Application Identifier Bit set are
   present for a given link. Otherwise, such link attribute advertisements
   MUST NOT be used.

   Notes
   -----
   RFC 8919 defines advertising link attributes with zero
   length Standard Application Bit Mask (SABM) and zero length User
   Defined ApplicationBit Mask (UDABM) as a means of advertising link
   attributes that can be used by any application. However, the text uses
   the word "permitted", suggesting that the use of such advertisements
   is "optional". Such an interpretation could lead to interoperability
   issues and is not what was intended.

   The replacement text below makes explicit the specific conditions when
   such advertisements MUST be used and the specific conditions under
   which they MUST NOT be used.

   Instructions:
   -------------
   This erratum is currently posted as "Reported". If necessary, please
   use "Reply All" to discuss whether it should be verified or
   rejected. When a decision is reached, the verifying party
   can log in to change the status and edit the report, if necessary.

   --------------------------------------
   RFC8919 (draft-ietf-isis-te-app-19)
   --------------------------------------
   Title               : IS-IS Application-Specific Link Attributes
   Publication Date    : October 2020
   Author(s)           : L. Ginsberg, P. Psenak, S. Previdi, W. Henderickx, J. Drake
   Category            : PROPOSED STANDARD
   Source              : Link State Routing
   Area                : Routing
   Stream              : IETF
   Verifying Party     : IESG


_________________________________________________________________________________________________________________________



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.

_________________________________________________________________________________________________________________________



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.

_________________________________________________________________________________________________________________________

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.