Re: [Lsr] Suresh Krishnan's No Objection on draft-ietf-lsr-isis-rfc7810bis-04: (with COMMENT)

["Les Ginsberg (ginsberg)" <[e-mail]>]

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 <[e-mail]>
Sent: Thursday, December 20, 2018 4:01 AM
To: Acee Lindem (acee) <[e-mail]>; Les Ginsberg (ginsberg) <[e-mail]>; Suresh Krishnan <[e-mail]>
Cc: [e-mail]; [e-mail]; The IESG <[e-mail]>; Ketan Talaulikar (ketant) <[e-mail]>; [e-mail]
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) ([e-mail]<mailto:[e-mail]>) 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.