Subject: Re: [Teas] WG Last Call for draft-ietf-lsr-isis-rfc5316bis

From: Yingzhen Qu <[email-masked]>
Date: Tue, 2 Mar 2021 12:05:01 -0800

I’ve read the draft and support the publication.

Thanks,
Yingzhen

> On Feb 17, 2021, at 7:30 AM, Christian Hopps <[email-masked]> wrote:
> 
> Hi LSR and TEAS,
> 
> This begins a joint WG last call for:
> 
>  https://datatracker.ietf.org/doc/draft-ietf-lsr-isis-rfc5316bis/
> 
> Please discuss any issues on the LSR mailing list. The WGLC will end March 3, 2021.
> 
> Authors, please indicate wether you are aware of any IPR related to this document to the list.
> 
> Thanks,
> Chris, Acee, (Lou and Pavan).
> _______________________________________________
> Teas mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/teas

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Tue, 2 Mar 2021 21:14:22 +0000

Hi Xiaodong,

You need to reply explicitly to the IPR poll. 

Thanks,
Acee

On 2/17/21, 10:31 AM, "Christian Hopps" <[email-masked]> wrote:

    Hi LSR and TEAS,

    Thanks,

---

From: Peter Psenak <[email-masked]>
Date: Wed, 3 Mar 2021 10:22:00 +0100

Hi,

I support the publication.

thanks,
Peter

---

From: Dhruv Dhody <[email-masked]>
Date: Wed, 3 Mar 2021 15:39:20 +0530

Hi,

I went through the diff with RFC5316. The changes look good. Some
minor comments -

(1) Is it wise to use normative keywords MUST and SHOULD in the
appendix? The text is from section 3.1 but can it be reworded in the
appendix? Also wondering if other changes (IANA, nits) could be listed
or we could call it "major change" :)

(2) IPv6 Local ASBR ID and IPv6 Router ID is used interchangeably i.e.
table in IANA section 6.2 does not use the same name as the table in
section 3.1

Hope this helps!

Thanks!

Dhruv

---

From: Donald Eastlake <[email-masked]>
Date: Wed, 3 Mar 2021 13:32:25 -0500

Hi,

I have a few comments. Sorry to send these so late in the process. I
support publication of this draft regardless of whether any action is
taken on my comments.

1. Since there are non-allocation actions, I suggest that the first
sentence of Section 6 be more like "IANA is requested to take the
following actions."

2. It should be called out as an explicit IANA action to replace all
References to "[RFC5316]" on the IANA IS-IS TLV Codepoints web page
with References to "[this document]".

3. Use of "new" throughout the document for codepoints that were
assigned for RFC 5316 more than a decade ago should be eliminated.

4. I generally think it is better for implementation requirements to
be in the main text rather than the IANA Considerations, so I suggest
moving "Note that all four sub-TLVs SHOULD NOT appear in TLVs 22, 23,
25, 222, or 223 and MUST be ignored if they are included in any of
these TLVs." up to near the end of Section 3.1.

2. I like diagrams and enjoy doing ASCII art, so I suggest replacing
the prose table at the beginning of 3.1 with the following. In any
case note that the usual IETF admonition regarding the reserved bits,
that they MUST be sent as zero and ignored on receipt, seems to be
missing in the document.

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   Router ID                                     (4 octets)    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   default metric                              | (3 octets)
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |S|D| Rsvd      |                                 (1 octet)
   +-+-+-+-+-+-+-+-+
   |sub-TLVs length|                                 (1 octet)
   +-+-+-+-+-+-+-+-+-+-+-+-
   | sub-TLVs ...                                    (0-246 octets)
   +-+-+-+-+-+-+-+-+-+-+-+-

     - S, D: Flooding-scope and up/down information discussed below.
     - Rsvd: 6 reserved bits that MUST be sent as zero and ignored
             on receipt.
     - sub-TLVs length: gives the total number of octets of sub-TLVs,
             which is variable from zero to 246 octets, as an unsigned
             integer. sub-TLVs are structured as shown below. sub-TLVs
             with an unknown type MUST be ignored. If the value of the
             sub-TLVs length field is larger than 246, or the last
             sub-TLV extends beyond the sub-TLVs length, the TLV is
             malformed and MUST be ignored.

   +-+-+-+-+-+-+-+-+
   | sub-type      |                                 (1 octet)
   +-+-+-+-+-+-+-+-+
   | sub-TLV length|                                 (1 octet)
   +-+-+-+-+-+-+-+-+-+-+-+-
   | sub-TLV value ...                               (variable)
   +-+-+-+-+-+-+-+-+-+-+-+-

Thanks,
Donald
===============================
 Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
 2386 Panoramic Circle, Apopka, FL 32703 USA
 [email-masked]

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Wed, 3 Mar 2021 18:40:38 +0000

Speaking as WG member:

As long as we are revising, I'd suggest changing "ISIS" in the title and several times in the text to "IS-IS" consistent with other IS-IS RFCs (at least the newer ones). 
Thanks,
Acee

On 3/3/21, 1:32 PM, "Donald Eastlake" <[email-masked]> wrote:

    Hi,

        0                   1                   2                   3

       +-+-+-+-+-+-+-+-+
       | sub-type      |                                 (1 octet)
       +-+-+-+-+-+-+-+-+

    Thanks,
    Donald

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Wed, 3 Mar 2021 19:47:31 +0000

Dhruv -

Thanx for reviewing/supporting the draft.

Please see inline.

> -----Original Message-----

> From: Lsr <[email-masked]> On Behalf Of Dhruv Dhody

> Sent: Wednesday, March 03, 2021 2:09 AM

> To: Christian Hopps <[email-masked]>

> Cc: TEAS WG Chairs <[email-masked]>; [email-masked]; TEAS WG

> ([email-masked]) <[email-masked]>; [email-masked]; [email-masked]; lsr-

> [email-masked]

> Subject: Re: [Lsr] [Teas] WG Last Call for draft-ietf-lsr-isis-rfc5316bis

> or we could call it "major change" :)

[Les:] I personally do not have an issue using the normative keywords in the Appendix. Not doing so I think might trigger someone to ask if there is some inconsistency between the Appendix text and the text in the body of the draft. 😊

If you know of some prohibition against using such keywords in an Appendix please provide the reference.

The IANA change is a consequence of the introduction pf new  IPv6 Local ASBR identifier sub-TLV. I do not see the need to mention it in the Appendix.

I do not understand your comment about "major change". Could you explain?

[Les:] The use of " IPv6 Router ID" in Section 3.1 is inconsistent. I will fix that.

Thanx for pointing that out.

   Les

> On Wed, Feb 17, 2021 at 9:00 PM Christian Hopps <[email-masked]<mailto:[email-masked]>>

> wrote:

> > Please discuss any issues on the LSR mailing list. The WGLC will end March

> 3, 2021.

> > Authors, please indicate wether you are aware of any IPR related to this

> document to the list.

> > [email-masked]<mailto:[email-masked]>

> Lsr mailing list

> [email-masked]<mailto:[email-masked]>

> https://www.ietf.org/mailman/listinfo/lsr

---

From: Alvaro Retana <[email-masked]>
Date: Wed, 3 Mar 2021 12:05:45 -0800

On March 3, 2021 at 2:47:38 PM, Les Ginsberg wrote:
> > From: Lsr On Behalf Of Dhruv Dhody

Les:

Hi!

...
> [Les:] I personally do not have an issue using the normative keywords in
> the Appendix. Not doing so I think might trigger someone to ask if there is
> some inconsistency between the Appendix text and the text in the body of the
> draft. 😊
>

There's no specific prohibition against it -- in fact, sometimes an
appendix can be normative so it is completely appropriate to have
normative language.

In this case, the appendix is informative and the normative text is
only reflecting what the main body of the draft says (which is where
the specification is).  To avoid confusion about which piece of text
is normative, and keep consistency, I would recommend using quotes in
the appendix:

OLD>
   1.  The Router ID SHOULD be identical to the value advertised in the
   Traffic Engineering Router ID TLV (134) if available.

NEW>
   1.  The "Router ID SHOULD be identical" to the value advertised in the
   Traffic Engineering Router ID TLV (134) if available (Section 3.1).

Alvaro.

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Wed, 3 Mar 2021 20:47:01 +0000

Donald -

Thanx for your careful review and your support of the draft.
Replies inline.

> From: Lsr <[email-masked]> On Behalf Of Donald Eastlake
> Sent: Wednesday, March 03, 2021 10:32 AM
> Cc: [email-masked]; [email-masked]; [email-masked]; lsr-
> [email-masked]; [email-masked]; [email-masked]
> Subject: Re: [Lsr] WG Last Call for draft-ietf-lsr-isis-rfc5316bis
> 
> Hi,
> 

[Les:] I understand your point.
However, in this case we are inheriting allocations made by RFC5316 AND adding a new code point for the new IPv6 local ASBR identifier sub-TLV.
Being 100% accurate requires identifying what has been done already vs what is new.
But once the RFC is published the text will change to " IANA has made..." (as it is in RFC 5316) for all the code points (new and old).
Having worked w IANA folks many times, I have great confidence that they will get things right even with the current less than 100% strictly accurate text - so I prefer not to invest time here.
Hope that is OK with you.

> with References to "[this document]".

[Les:] OK

> assigned for RFC 5316 more than a decade ago should be eliminated.

[Les:] Well, this document replaces RFC 5316. Which means future readers need not ever look at RFC 5316. In which case the distinction between what was "new" in 5316 and what is "new" in 5316bis becomes moot. 
So while I agree that strictly speaking you are correct I am not convinced that doing as you suggest aids clarity. 

> these TLVs." up to near the end of Section 3.1.

[Les:] I have looked at other documents with similar cases (i.e., a sub-TLV that is permitted in only a subset of the TLVs in the combined registry) and they do not have such a statement at all. The "N" indication in the registry columns is deemed sufficient.
I am therefore inclined to remove the Note altogether.

> that they MUST be sent as zero and ignored on receipt, seems to be

[Les:] OK
It was not done this way in RFC 5316. When writing bis documents I am biased to NOT changing existing presentation if there is no actual change in functionality to that section.
But I agree diagrams are easier to read and it would be more consistent with other sections of the document.

   Les

> [email-masked]

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Wed, 3 Mar 2021 20:50:07 +0000

OK

   Les

> From: Lsr <[email-masked]> On Behalf Of Acee Lindem (acee)
> Sent: Wednesday, March 03, 2021 10:41 AM
> To: Donald Eastlake <[email-masked]>; Christian Hopps
> <[email-masked]>
> As long as we are revising, I'd suggest changing "ISIS" in the title and several
> times in the text to "IS-IS" consistent with other IS-IS RFCs (at least the
> newer ones).
> Thanks,
> Acee
>

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Wed, 3 Mar 2021 20:54:38 +0000

Alvaro -

Thanx for chiming in.
Inline.

> From: Alvaro Retana <[email-masked]>
> Sent: Wednesday, March 03, 2021 12:06 PM
> To: Les Ginsberg (ginsberg) <[email-masked]>; Christian Hopps
> <[email-masked]>; Dhruv Dhody <[email-masked]>
> Cc: TEAS WG Chairs <[email-masked]>; [email-masked]; [email-masked]; lsr-
> [email-masked]; TEAS WG ([email-masked]) <[email-masked]>; teas-
> [email-masked]
> Subject: RE: [Lsr] [Teas] WG Last Call for draft-ietf-lsr-isis-rfc5316bis
> 
> > If you know of some prohibition against using such keywords in an
> Appendix
> > please provide the reference.
> 

[Les:] So I am willing to make the change. But I have to say that for me as a reader the use of quotes as you suggest does not aid clarity.
I have no idea why the entire sentence should not be quoted as without the unquoted portion of the sentence the meaning of the quoted part is incomplete.

??

   Les

---

From: Alvaro Retana <[email-masked]>
Date: Wed, 3 Mar 2021 13:08:51 -0800

Les:

The text is not the same:

§3.1 reads: "The Router ID SHOULD be identical to the value advertised in
the Traffic Engineering Router ID TLV [RFC5305].”

I’m sure you’ll do the right thing.

Thanks!

Alvaro.

>    Traffic Engineering Router ID TLV (134) if available (Section 3.1).

[Les:] So I am willing to make the change. But I have to say that for me as
a reader the use of quotes as you suggest does not aid clarity.
I have no idea why the entire sentence should not be quoted as without the
unquoted portion of the sentence the meaning of the quoted part is
incomplete.

---

From: Donald Eastlake <[email-masked]>
Date: Wed, 3 Mar 2021 16:22:43 -0500

Hi Les,

See below at <de>

On Wed, Mar 3, 2021 at 3:47 PM Les Ginsberg (ginsberg) <[email-masked]>
wrote:

> However, in this case we are inheriting allocations made by RFC5316 AND
> adding a new code point for the new IPv6 local ASBR identifier sub-TLV.
> But once the RFC is published the text will change to " IANA has made..."
> (as it is in RFC 5316) for all the code points (new and old).
> Having worked w IANA folks many times, I have great confidence that they
> will get things right even with the current less than 100% strictly
> accurate text - so I prefer not to invest time here.

<de> I agree that IANA will fix this so it is OK to not change.

> [Les:] Well, this document replaces RFC 5316. Which means future readers
> need not ever look at RFC 5316. In which case the distinction between what
> was "new" in 5316 and what is "new" in 5316bis becomes moot.

 <de> I was not suggesting making any distinction between what is or isn't
new in 5316bis, except by implication in the IANA Considerations Section.
I actually just don't see any need to use the word "new" in this document.

> [Les:] I have looked at other documents with similar cases (i.e., a
> sub-TLV that is permitted in only a subset of the TLVs in the combined
> registry) and they do not have such a statement at all. The "N" indication
> in the registry columns is deemed sufficient.

<de> OK.

> It was not done this way in RFC 5316. When writing bis documents I am
> biased to NOT changing existing presentation if there is no actual change
> in functionality to that section.

<de> I think there are actually two intertwined changes: a change to
presentation and more specific RFC 2119 language. I think both are an
improvement so thanks for agreeing to them.

<de>Thanks,
Donald

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Wed, 3 Mar 2021 23:29:25 +0000

Alvaro –

Your comment was to put quotes:

<snip>
I would recommend using quotes in the appendix:

OLD>

NEW>

<end snip>

My response was:

<snip>
<end snip>

Now you point out that the body of the text says “[RFC5305]” whereas the appendix says “TLV 134”.
Fine – I can make them consistent.
Now, can you respond to my comment regarding the lack of clarity in using quotes?

Thanx.

   Les

From: Alvaro Retana <[email-masked]>
Sent: Wednesday, March 03, 2021 1:09 PM
To: Les Ginsberg (ginsberg) <[email-masked]>; Dhruv Dhody <[email-masked]>; Christian Hopps <[email-masked]>
Cc: TEAS WG Chairs <[email-masked]>; [email-masked]; [email-masked]; [email-masked]; [email-masked]; TEAS WG ([email-masked]) <[email-masked]>
Subject: RE: [Lsr] [Teas] WG Last Call for draft-ietf-lsr-isis-rfc5316bis

Les:

§3.1 reads: "The Router ID SHOULD be identical to the value advertised in the Traffic Engineering Router ID TLV [RFC5305].”

Thanks!

Alvaro.

---

From: Dhruv Dhody <[email-masked]>
Date: Thu, 4 Mar 2021 12:04:03 +0530

Hi Les,
On Thu, Mar 4, 2021 at 1:17 AM Les Ginsberg (ginsberg) <[email-masked]>
wrote:

> some inconsistency between the Appendix text and the text in the body of
> the draft. 😊
>
[Dhruv]: To me, the usefulness of this appendix is to find out what has
changed in this bis. Very useful for any reviewer or implementor. The other
option is to do rfcdiff :(

So in this context, I provided the above comments suggesting rewording the
text as a list of changes with rewording. Adding a reference to the
relevant section could be useful too. Feel free to ignore, if you think
this adds no value!

> The IANA change is a consequence of the introduction pf new  IPv6 Local
> ASBR identifier sub-TLV. I do not see the need to mention it in the
> Appendix.
>
>
>
> [Dhruv]: The current text says -

Appendix A.  Changes to RFC 5316

   This document makes the following changes to RFC 5316.

This gives an impression (to me) that *all* changes made are listed here.
Since that is not what is happening here, I suggested calling it -
Important or Major or Motivation to update RFC 5316, whatever you like....

Thanks!
Dhruv

>    Les
>
>
>
> > Hope this helps!
>
> >
>
> > Thanks!
>
> >
>
> > Dhruv
>
> >
>
> >
>
> >
>
> > On Wed, Feb 17, 2021 at 9:00 PM Christian Hopps <[email-masked]>
>
> > wrote:
>
> > >
>
> > > Hi LSR and TEAS,
>
> > >
>

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Thu, 4 Mar 2021 06:44:38 +0000

Dhruv –

<snip>
This gives an impression (to me) that *all* changes made are listed here. Since that is not what is happening here, I suggested calling it - Important or Major or Motivation to update RFC 5316, whatever you like....
<end snip>

Got it.
I will make that clear in the next revision.

Thanx.

   Les

From: Dhruv Dhody <[email-masked]>
Sent: Wednesday, March 03, 2021 10:34 PM
To: Les Ginsberg (ginsberg) <[email-masked]>
Cc: Christian Hopps <[email-masked]>; TEAS WG Chairs <[email-masked]>; [email-masked]; TEAS WG ([email-masked]) <[email-masked]>; [email-masked]; [email-masked]; [email-masked]
Subject: Re: [Lsr] [Teas] WG Last Call for draft-ietf-lsr-isis-rfc5316bis

Hi Les,
On Thu, Mar 4, 2021 at 1:17 AM Les Ginsberg (ginsberg) <[email-masked]<mailto:[email-masked]>> wrote:

Dhruv -

Please see inline.

> From: Lsr <[email-masked]<mailto:[email-masked]>> On Behalf Of Dhruv Dhody

> To: Christian Hopps <[email-masked]<mailto:[email-masked]>>

> Cc: TEAS WG Chairs <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>; TEAS WG

> ([email-masked]<mailto:[email-masked]>) <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; lsr-

> [email-masked]<mailto:[email-masked]>

[Dhruv]: To me, the usefulness of this appendix is to find out what has changed in this bis. Very useful for any reviewer or implementor. The other option is to do rfcdiff :(

So in this context, I provided the above comments suggesting rewording the text as a list of changes with rewording. Adding a reference to the relevant section could be useful too. Feel free to ignore, if you think this adds no value!

This gives an impression (to me) that *all* changes made are listed here. Since that is not what is happening here, I suggested calling it - Important or Major or Motivation to update RFC 5316, whatever you like....

Thanks!
Dhruv

   Les

---

From: Alvaro Retana <[email-masked]>
Date: Thu, 4 Mar 2021 09:09:49 -0800

On March 3, 2021 at 6:29:28 PM, Les Ginsberg wrote:

Les:

Hi!

...
> Now, can you respond to my comment regarding the lack of clarity in using

Sure.

I guess you mean this comment: "But I have to say that for me as a
reader the use of quotes as you suggest does not aid clarity."

Dhruv's comment was about using normative language in the appendix:

> > (1) Is it wise to use normative keywords MUST and SHOULD in the appendix?
> > The text is from section 3.1 but can it be reworded in the appendix?

He is absolutely correct in suggesting that the appendix could use
different words.  As I mentioned before, the appendix is just an
informative section, a good/nice-to-have explanation for the reader.
That means that it doesn't have to be an exact transcription of the
text (which you didn't have to start with), and it can simply be an
explanation.

The way I see it, using normative language in an informational
appendix is what makes the text lack clarity -- the quotes were meant
to help a little without asking you to make too many changes.  That
way it would at least be clear that the specification is made
elsewhere.

I know we may never agree on which direction to look at clarity.  We
have already spent too much time on this.

Alvaro.

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Thu, 4 Mar 2021 19:00:12 +0000

Alvaro -

Thanx for the clarification.
I will address this in the next revision.

   Les

> Sent: Thursday, March 04, 2021 9:10 AM
> Cc: TEAS WG Chairs <[email-masked]>; [email-masked]; TEAS WG
> ([email-masked]) <[email-masked]>; [email-masked]; [email-masked]; teas-
> [email-masked]
> appendix?