Subject: Re: [Lsr] WG Last Call for draft-ietf-lsr-isis-rfc7810bis-00

From: "Ketan Talaulikar (ketant)" <[email-masked]>
Date: Tue, 17 Jul 2018 13:54:39 +0000

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

-----Original Message-----
From: Lsr <[email-masked]> On Behalf Of Acee Lindem (acee)
Sent: 18 June 2018 17:38
To: Les Ginsberg (ginsberg) <[email-masked]>; Christian Hopps <[email-masked]>; [email-masked]
Cc: [email-masked]; [email-masked]
Subject: Re: [Lsr] WG Last Call for draft-ietf-lsr-isis-rfc7810bis-00

Hi Les, 
Yes - the Working Group Last call has completed. We'll find a shepherd and request publication.
Thanks,
Acee 

On 6/15/18, 10:49 AM, "Les Ginsberg (ginsberg)" <[email-masked]> wrote:

    WG chairs -
    
    Can we consider WG last call completed? (It has been more than 3 weeks...)
    
    Would really like to get this small but important correction published ASAP

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

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Tue, 17 Jul 2018 17:30:05 +0000

Ketan -

Thanx for taking on the role of shepherd.

I am attaching some proposed diffs which I think addresses your concern.
Let me know if this suffices and we can publish an update.

   Les

> From: Ketan Talaulikar (ketant)
> Sent: Tuesday, July 17, 2018 6:55 AM
> To: Acee Lindem (acee) <[email-masked]>; Les Ginsberg (ginsberg)
> <[email-masked]>; Christian Hopps <[email-masked]>; [email-masked]
> Subject: RE: [Lsr] WG Last Call for draft-ietf-lsr-isis-rfc7810bis-00
> 
> 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.
> 
> 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
>

---

From: "Ketan Talaulikar (ketant)" <[email-masked]>
Date: Tue, 17 Jul 2018 18:29:26 +0000

Hi Les,

This sounds good. I would suggest being liberal in receive (i.e. accept and interpret the incorrect encoding) and there is no need to send that erroneous encoding.

Thanks,
Ketan

-----Original Message-----
From: Les Ginsberg (ginsberg) 
Sent: 17 July 2018 13:30
To: Ketan Talaulikar (ketant) <[email-masked]>; Acee Lindem (acee) <[email-masked]>; Christian Hopps <[email-masked]>; [email-masked]
Cc: [email-masked]; [email-masked]
Subject: RE: [Lsr] WG Last Call for draft-ietf-lsr-isis-rfc7810bis-00

Ketan -

   Les

> 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
>

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Tue, 17 Jul 2018 21:06:32 +0000

Ketan -

I don't want to be overly prescriptive here.
The need for supporting backwards compatibility is limited by the amount of existing deployment by implementations that chose the "length 5" solution - and hopefully any such issues will be short-lived as the problematic implementations get upgraded.

But If there is a need for backwards compatibility it is possible that both transmit/receive are required. This is a judgment call for implementers and the new text in the draft is not meant to tell implementers what they SHOULD do - only to remind them that this may be an issue which they will have to consider. If they think receive only is sufficient that's fine, but it is beyond what I think the draft needs to say.

   Les

> Sent: Tuesday, July 17, 2018 11:29 AM
> To: Les Ginsberg (ginsberg) <[email-masked]>; Acee Lindem (acee)
> <[email-masked]>; Christian Hopps <[email-masked]>; [email-masked]
> This sounds good. I would suggest being liberal in receive (i.e. accept and
> interpret the incorrect encoding) and there is no need to send that erroneous
> encoding.
> 
> Thanks,
> Ketan
> 
> To: Ketan Talaulikar (ketant) <[email-masked]>; Acee Lindem (acee)
> <[email-masked]>; Christian Hopps <[email-masked]>; [email-masked]

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Tue, 17 Jul 2018 21:17:15 +0000

FWIW - I agree with Les. We really don't want to support both interpretations of the ambiguous encoding. 
Thanks,
Acee 

On 7/17/18, 5:06 PM, "Les Ginsberg (ginsberg)" <[email-masked]> wrote:

    Ketan -

    
       Les

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Tue, 17 Jul 2018 21:31:34 +0000

V1 has been posted with the additional text.

Hope this clears any issues with the shepherd's report.

    Les

> From: Lsr <[email-masked]> On Behalf Of Les Ginsberg (ginsberg)
> Sent: Tuesday, July 17, 2018 2:07 PM
> The need for supporting backwards compatibility is limited by the amount of
> existing deployment by implementations that chose the "length 5" solution - and
> hopefully any such issues will be short-lived as the problematic implementations
> get upgraded.
> 
> But If there is a need for backwards compatibility it is possible that both
> transmit/receive are required. This is a judgment call for implementers and the
> new text in the draft is not meant to tell implementers what they SHOULD do -
> only to remind them that this may be an issue which they will have to consider. If
> they think receive only is sufficient that's fine, but it is beyond what I think the
> draft needs to say.
> 
>    Les
> 
> 
> > This sounds good. I would suggest being liberal in receive (i.e.
> > accept and interpret the incorrect encoding) and there is no need to
> > send that erroneous encoding.
> >
> > Thanks,
> > Ketan
> >
> > > I was reviewing this draft as the Shepherd. It is a fairly simple
> > > and straightforward bis update to RFC7810 to fix an encoding error.
> > >
> > > 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
> > >
> > > On 6/15/18, 10:49 AM, "Les Ginsberg (ginsberg)"
> > > <[email-masked]>
> > wrote:
> > >
> > >     WG chairs -
> > >

---

From: "Ketan Talaulikar (ketant)" <[email-masked]>
Date: Tue, 24 Jul 2018 15:44:54 +0000

Hi Les,

It does and thanks for the update.

Thanks,
Ketan

-----Original Message-----
From: Les Ginsberg (ginsberg) 
Sent: 17 July 2018 17:32
To: Les Ginsberg (ginsberg) <ginsberg=[email-masked]>; Ketan Talaulikar (ketant) <[email-masked]>; Acee Lindem (acee) <[email-masked]>; Christian Hopps <[email-masked]>; [email-masked]
Cc: [email-masked]; [email-masked]
Subject: RE: [Lsr] WG Last Call for draft-ietf-lsr-isis-rfc7810bis-00

    Les

> The need for supporting backwards compatibility is limited by the 
> amount of existing deployment by implementations that chose the 
> "length 5" solution - and hopefully any such issues will be 
> short-lived as the problematic implementations get upgraded.
> 
> But If there is a need for backwards compatibility it is possible that 
> both transmit/receive are required. This is a judgment call for 
> implementers and the new text in the draft is not meant to tell 
> implementers what they SHOULD do - only to remind them that this may 
> be an issue which they will have to consider. If they think receive 
> only is sufficient that's fine, but it is beyond what I think the draft needs to say.
> 
>    Les
> 
> 
> > > 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
> > >
> > >     Can we consider WG last call completed? (It has been more than 
> > > 3
> > > weeks...)
> > >