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

[Suresh Krishnan <[e-mail]>]

Hi Les,
  Thanks for the quick response. Comments inline.

> On Dec 19, 2018, at 11:36 PM, Les Ginsberg (ginsberg) <[e-mail]> wrote:
> 
> Suresh -
> 
> Inline.
> 
>> -----Original Message-----
>> From: Suresh Krishnan <[e-mail]>
>> Sent: Wednesday, December 19, 2018 7:32 PM
>> To: The IESG <[e-mail]>
>> Cc: [e-mail]; Ketan Talaulikar (ketant)
>> <[e-mail]>; [e-mail]; [e-mail]; Ketan
>> Talaulikar (ketant) <[e-mail]>; [e-mail]
>> Subject: Suresh Krishnan's No Objection on draft-ietf-lsr-isis-rfc7810bis-04:
>> (with COMMENT)
>> 
>> Suresh Krishnan has entered the following ballot position for
>> draft-ietf-lsr-isis-rfc7810bis-04: No Objection
>> 
>> When responding, please keep the subject line intact and reply to all
>> email addresses included in the To and CC lines. (Feel free to cut this
>> introductory paragraph, however.)
>> 
>> 
>> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
>> for more information about IESG DISCUSS and COMMENT positions.
>> 
>> 
>> The document, along with other ballot positions, can be found here:
>> https://datatracker.ietf.org/doc/draft-ietf-lsr-isis-rfc7810bis/
>> 
>> 
>> 
>> ----------------------------------------------------------------------
>> COMMENT:
>> ----------------------------------------------------------------------
>> 
>> * Backward compatibility
>> 
>> There is text in Appendix A that provides guidance to implementers on how
>> to
>> handle TLVs with length 5 from RFC7810. I think this would be much more
>> helpful
>> inside the main body of the document. I was wondering how the backward
>> compatibility was handled until I read through the Appendix that lists the
>> *diffs*.
>> 
> 
> [Les:] I REALLY do not want to do this.
> 
> There is no intent to legitimize two different encodings. Implementations which encoded the problematic sub-TLVs with a length of 5 and a reserved byte were wrong - though obviously based on the flawed text in RFC 7810 it wasn't easy for a reader to realize that.

No worries. My comment was not blocking :-), but the document certainly does not clearly reflect your position. Either you want to support the old implementations or not. I am fine with either way but the text in the appendix is certainly leaning the other way towards backward compatibility. As long as the guidance is consistent, I certainly have no issues.

> 
> The obligation is on the implementations which used the 5 byte encoding to correct themselves and use the 4 byte encoding.
> There is no obligation on conformant implementations to be "generous" and allow for interoperating with implementations which used the 5 byte encodings.
> There might be business value in doing so - but that is outside the purview of specification. We use the appendix only to suggest that "generosity" be considered.

This is where you lost me. What is the actual guidance you want to provide? You said earlier “There is no intent to legitimize two different encodings” and then say here that implementations should be generous. That does sound like a “MAY” to me.

> 
> The main body of the document should not be cluttered with this. It needs to serve as the normative specification independent of the prior existence of RFC 7810.

Sure. Your call.

Thanks
Suresh