Skip to main content

Advertising Generic Information in IS-IS
draft-ietf-isis-genapp-04

Discuss


Yes

(Stewart Bryant)

No Objection

(Dan Romascanu)
(Gonzalo Camarillo)
(Jari Arkko)
(Peter Saint-Andre)
(Ralph Droms)
(Russ Housley)
(Wesley Eddy)

Abstain


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

Lars Eggert Former IESG member
Discuss
Discuss [Treat as non-blocking comment] (2010-10-04) Unknown
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.
Adrian Farrel Former IESG member
(was Discuss) Yes
Yes (2010-10-04) Unknown
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.
Stewart Bryant Former IESG member
Yes
Yes () Unknown

                            
Dan Romascanu Former IESG member
(was Discuss) No Objection
No Objection () Unknown

                            
Gonzalo Camarillo Former IESG member
(was Discuss) No Objection
No Objection () Unknown

                            
Jari Arkko Former IESG member
(was Discuss) No Objection
No Objection () Unknown

                            
Peter Saint-Andre Former IESG member
(was Discuss) No Objection
No Objection (2010-12-07) Unknown

                            
Ralph Droms Former IESG member
No Objection
No Objection () Unknown

                            
Robert Sparks Former IESG member
(was Discuss) No Objection
No Objection (2010-10-06) Unknown
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?
Russ Housley Former IESG member
No Objection
No Objection () Unknown

                            
Sean Turner Former IESG member
No Objection
No Objection (2010-10-05) Unknown
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].
Tim Polk Former IESG member
(was Discuss) No Objection
No Objection (2010-10-06) Unknown
I support Lars' discuss,
Wesley Eddy Former IESG member
No Objection
No Objection () Unknown

                            
Ron Bonica Former IESG member
Abstain
Abstain (2011-03-16) Unknown
I share Lars' allergy to using routing protocols to transport generic information. Maybe we should start thinking about a generic information transport protocol.