Folks –

Here is the relevant paragraph from the Appendix - some emphasis added.

“As a means of interoperating with implementations which do not
   conform to the corrections defined in this document, implementers may
   wish to consider temporarily supporting sending and/or receiving the
   form of the sub-TLVs using a length of 5 and including the RESERVED
   field.  However, the intent of this revision is to specify one and
   only one normative behavior.  Any existing implementations which
   encode the sub-TLVs using a length of 5 are expected to be revised to
   conform to the normative behavior specified in this document.”

Several things of note regarding this paragraph:

1)It was put in in response to a review comment from the Document shepherd:

<snip>
Hi All,

I was reviewing this draft as the Shepherd. It is a fairly simple and 
straightforward bis update to RFC7810 to fix an encoding error.

There is one point that I would like the authors and WG to consider.

The draft in the appendix talks about two interpretations of the erroneous 
sub-TLVs and from the conversation on the list I get the impression that there 
are at least two implementations out there which did different interpretations. 
Do we want to consider putting in a suggestion (i.e. not normative perhaps) 
that implementations updated to this specifications accept the sub-TLV with the 
Reserved field included and size 5? So they don't consider such an encoding as 
error or malformed on reception?

Thanks,
Ketan

<end snip>

I agreed with Ketan’s comment and so the text was added.

2)The text is very careful to comply with RFC 8174. It uses lowercase “may” – 
therefore clearly non-normative.  It also unambiguously states that 
implementations written using a length of 5 “are expected to be revised”.

3)If you read this from the POV of someone who implements the protocol 
extensions, I think this text is useful in providing context for what 
interoperability issues might be encountered in the field. Even though the 
implementation we know of that used a length of 5 has been fixed – there are 
still older versions of that code deployed.  It suggests – but clearly does NOT 
require - what could be done (at the implementer’s discretion) to deal with the 
non-conformant implementations.

I fail to see how this is in any way confusing.

I think the document is better off as is – but if you folks insist I will 
remove the text – though clearly I disagree with this choice.

    Les



From: Alvaro Retana <aretana.i...@gmail.com>
Sent: Thursday, December 20, 2018 4:01 AM
To: Acee Lindem (acee) <a...@cisco.com>; Les Ginsberg (ginsberg) 
<ginsb...@cisco.com>; Suresh Krishnan <sur...@kaloom.com>
Cc: lsr-cha...@ietf.org; lsr@ietf.org; The IESG <i...@ietf.org>; Ketan 
Talaulikar (ketant) <ket...@cisco.com>; draft-ietf-lsr-isis-rfc7810...@ietf.org
Subject: Re: Suresh Krishnan's No Objection on 
draft-ietf-lsr-isis-rfc7810bis-04: (with COMMENT)

On December 20, 2018 at 5:38:51 AM, Acee Lindem (acee) 
(a...@cisco.com<mailto:a...@cisco.com>) wrote:

We only know of one implementation that has the wrong encoding and we have 
fixed that one.

I then see no harm in removing the “generosity” paragraph.  As Suresh suggests, 
it will make the document even clearer.

Thanks!

Alvaro.

_______________________________________________
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Reply via email to