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
