Advertising Generic Information in IS-IS
RFC 6823

Note: This ballot was opened for revision 04 and is now closed.

(Lars Eggert) Discuss

Discuss (2010-10-04 for -)
I'm missing a crystal clear statement in a very visible spot that the content exchanged in GENINFO TLVs MUST NOT alter the behavior or operation of the IS-IS protocol and/or state machine. In other words, GENINFO is not a tool for a vendor to extended IS-IS in non-interoperable ways. The document does hint that this is the intent in a few places; I'm simply asking for making this very, very clear.
Comment (2010-10-04 for -)
No email
send info
(Non-actionable comment: I will likely abstain on this document even when the above change is made. The reason is that I'm allergic against the current trend of adding kitchen-sink options that turn all kinds of formerly purpose-built protocols info generic "information exchange" mechanisms.)

(Stewart Bryant) Yes

(Adrian Farrel) (was Discuss) Yes

Comment (2010-10-04)
No email
send info
I don't think it is helpful to use RFC 2119 language in the Abstract.

---

I think that the RFC Editor will ask you to jiggle the content/section-
headings slightly. They have a preference for seeing Section 1 named
"Introduction".

---

A few acronyms need to be expanded on first use:
- TLV
- PDU

---

Section 3.1

            Application ID

                 An identifier assigned to this application via the
                 GENINFO-REG.

What is the "GENINFO-REG"?
How about:

            Application ID

                 An identifier assigned to this application via the
                 registration procedures described in Section 8.

---

Section 3.2

   The scope of the codepoints used in such subTLVs is defined by the
   GENINFO TLV codepoint AND the Application ID i.e. the subTLV
   codepoints are private to the application. 

The uppercase word "AND" has not definition.

Suggest

   The scope of the codepoints used in such subTLVs is defined by the
   combincation of the GENINFO TLV codepoint and the Application ID,
   i.e. the subTLV codepoints are private to the application.

(Jari Arkko) (was Discuss) No Objection

(Gonzalo Camarillo) (was Discuss) No Objection

(Ralph Droms) No Objection

(Wesley Eddy) No Objection

(Russ Housley) No Objection

(Tim Polk) (was Discuss) No Objection

Comment (2010-10-06)
No email
send info
I support Lars' discuss,

(Dan Romascanu) (was Discuss) No Objection

(Peter Saint-Andre) (was Discuss) No Objection

(Robert Sparks) (was Discuss) No Objection

Comment (2010-10-06)
No email
send info
I support Dan's discuss points. 

The document could better motivate the need for a generic container. Could it explicitly call out the existing messages that would have been candidates for the use of this mechanism if it existed at the time?

Would it make sense to add text reinforcing that elements not understanding this TLV would ignore-but-flood?

(Sean Turner) No Objection

Comment (2010-10-05 for -)
No email
send info
1) Never seen 2119 language in Abstract.  Is this allowed by the RFC editor?

2) Spell out LSP on first occurrence.

3) Sec 2: It's odd that there are requirements in the overview section.  Could this be reworked?

4) Sec 3 (and the rest of the document): RFC 5305 refers to sub-TLV not subTLV.  This document should align with 5305.

5) Sec 3.1: It would be nice if you assigned a word for the Flags: S (Scope), D (Down), I, and V.  It would be nice to assign a word to for "I" and "V" too.  How about Ipv4 for "I" and ipV6 for "V".

6) Sec 3.2: RFC 5035 has to following text about ignoring unknown sub-TLVs: "Unknown sub-TLVs are to be ignored and skipped upon receipt."  Does this draft want to use 2119 language to in fact require they be ignored?

7) Sec 3.2: r/AND/and

8) Sec 3.3: r/NOT/not

9) Sec 7: r/IS-IS/IS-IS [RFC1195].

(Ron Bonica) Abstain

Comment (2011-03-16)
No email
send info
I share Lars' allergy to using routing protocols to transport generic information. Maybe we should start thinking about a generic information transport protocol.