Subject: [Lsr] Murray Kucherawy's Discuss on draft-ietf-isis-te-app-14: (with DISCUSS and COMMENT)

From: Murray Kucherawy via Datatracker <[email-masked]>
Date: Mon, 08 Jun 2020 12:29:31 -0700

Murray Kucherawy has entered the following ballot position for
draft-ietf-isis-te-app-14: Discuss

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-isis-te-app/

----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

An easy one:

Sections 7.3 and 7.5 create new IANA registries with "Expert Review" rules, but
Section 7.5 provides no particular guidance to the Designated Expert about how
to review applications, as required by Section 4.5 of BCP 26.

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Since this document is in many parts a copy of
draft-ietf-ospf-te-link-attr-reuse, I'm only reviewing this delta between them
here:
https://www.ietf.org/rfcdiff?url1=draft-ietf-ospf-te-link-attr-reuse-14&url2=draft-ietf-isis-te-app-14

Section 2:
* "... expected to continue - so any discussion ..." -- change to "... expected
to continue.  Therefore, any discussion ..." * "... key points identified in
the introduction - which are:" -- change hyphen to a comma

Section 3:
* "... advertisements include sub-TLVs for TLVs ..." -- Please define or expand
"TLV" on first use. * Please just name the registries, rather than giving
multi-line URLs to them.

Section 3.1:
* As with the matching OSPF document, I don't see the benefit of citing current
registry contents rather than just referencing the registry.

Section 4.3:
* Interestingly, the entries for IPv4 are not capitalized (e.g., "interface
address"), but they are for IPv6 (e.g., "Interface Address").

Section 6.3.2:
* These two paragraphs read like they're in the wrong order.

Sections 7.1 and 7.2:
* These should refer back to Sections 4.2 and 4.3, respectively, where the new
values are fully described.

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Mon, 8 Jun 2020 21:00:53 +0000

Murray -

Thanx for the review.

Responses inline.

I'll post a new version once we have closed on all your comments.

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

> From: Murray Kucherawy via Datatracker <[email-masked]>

> Sent: Monday, June 08, 2020 12:30 PM

> To: The IESG <[email-masked]>

> Cc: [email-masked]; [email-masked]; [email-masked]; Acee

> Lindem (acee) <[email-masked]>; [email-masked]

> Subject: Murray Kucherawy's Discuss on draft-ietf-isis-te-app-14: (with

> DISCUSS and COMMENT)

> Sections 7.3 and 7.5 create new IANA registries with "Expert Review" rules,

> but

> Section 7.5 provides no particular guidance to the Designated Expert about

> how

> to review applications, as required by Section 4.5 of BCP 26.

[Les:] IS-IS registries are guided by RFC 7370 (referenced in Section 7 and in https://www.iana.org/assignments/isis-tlv-codepoints/isis-tlv-codepoints.xhtml ) - which does provide guidance to the experts.

There is some additional guidance in Section 7.3 because we want codepoints in the existing "sub-TLV of TLVs 22, 23, 25, 141, 222, and 223" registry to be in sync with the new registry whenever possible.

For Section 7.5 there really isn’t anything else to say beyond what RFC 7370 says.

??

> draft-ietf-ospf-te-link-attr-reuse, I'm only reviewing this delta between

> them

> https://www.ietf.org/rfcdiff?url1=draft-ietf-ospf-te-link-attr-reuse-<https://www.ietf.org/rfcdiff?url1=draft-ietf-ospf-te-link-attr-reuse-14&url2=draft-ietf-isis-te-app-14>

> 14&url2=draft-ietf-isis-te-app-14<https://www.ietf.org/rfcdiff?url1=draft-ietf-ospf-te-link-attr-reuse-14&url2=draft-ietf-isis-te-app-14>

[Les:] Done.

[Les:] "TLV" is marked as "well known" in https://www.rfc-editor.org/materials/abbrev.expansion.txt .

If you insist I will expand on first use, but not convinced it is necessary.

> * As with the matching OSPF document, I don't see the benefit of citing

> current

[Les:] The reason we list the existing code points is because we are using the same numeric values for the equivalent sub-sub-TLVs in the new ""sub-sub-TLV code points for application specific link attributes".

And we aren't listing all of the sub-TLVs currently defined - just the ones which historically have been used by RSVP-TE and which will also be used by the new Application Specific sub-TLV.

So I think there is value in listing the current code points of interest.

[Les:] You and Eric Vyncke must have the same eye doctor. 😊

Here is my response to Eric:

<snip>

You are correct in identifying this inconsistency - but note that the draft follows what is in https://www.iana.org/assignments/isis-tlv-codepoints/isis-tlv-codepoints.xhtml#isis-tlv-codepoints-22-23-25-141-222-223 .

It seems this discrepancy involves RFCs 5305 and 6119 as well.

<end snip>

[Les:] No - the second paragraph is clarifying the usage of the first. I have modified the first sentence of the second paragraph to be:

" These guidelines apply to cases where ..."

Does that help?

> * These should refer back to Sections 4.2 and 4.3, respectively, where the

> new

> values are fully described.

[Les:] Done.

   Les