-rfc-editor

… and it looks like the issues I brought up in 
https://mailarchive.ietf.org/arch/msg/lsr/i_oz5jSXFqSomn94zJFM2zqs5uw/ apply 
here too.

—John

On Jul 6, 2021, at 4:28 PM, Acee Lindem (acee) 
<[email protected]<mailto:[email protected]>> wrote:


LSR WG,

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

Thanks,
Acee
On 7/5/21, 5:54 PM, "RFC Errata System" 
<[email protected]<mailto:[email protected]>> wrote:

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

   --------------------------------------
   You may review the report below and at:
   
https://urldefense.com/v3/__https://www.rfc-editor.org/errata/eid6631__;!!NEt6yMaO-gk!RZqE3Vbriw47_8CY7h-yZO82_C8q2LvyvvM0zc_1YJQfXRrm_kFhSvu0PgU0QQ$

   --------------------------------------
   Type: Technical
   Reported by: Les Ginsberg <[email protected]<mailto:[email protected]>>

   Section: 5

   Original Text
   -------------
   OLD

   If link attributes are advertised 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. 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.

   An application-specific advertisement (Application Identifier Bit Mask
   with a matching Application Identifier Bit set) for an attribute MUST
   always be preferred over the advertisement of the same attribute with
   the zero-length Application Identifier Bit Masks for both standard
   applications and user-defined applications on the same link.

   Corrected Text
   --------------
   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 8920 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.

   --------------------------------------
   RFC8920 (draft-ietf-ospf-te-link-attr-reuse-16)
   --------------------------------------
   Title               : OSPF Application-Specific Link Attributes
   Publication Date    : October 2020
   Author(s)           : P. Psenak, Ed., L. Ginsberg, W. Henderickx, J. 
Tantsura, J. Drake
   Category            : PROPOSED STANDARD
   Source              : Link State Routing
   Area                : Routing
   Stream              : IETF
   Verifying Party     : IESG


_______________________________________________
Lsr mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/lsr

Reply via email to