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

[Ballot comment]
I support Lars' discuss.

Deployment of advanced IS-IS security mechanisms (e.g., RFC 5310 authentication) is something I
personally advocate.  However, if an IS-IS deployment were to deploy these mechanisms solely to support
advertisement of some generic information this may exacerbate any performance implications for the IS-IS
deployment and could be used to launch denial of service attacks.  That is, deploying IS-IS security mechanisms
*because* of the generic information would be costly for the IS-IS implementation and would violate the usual
precept of "security commensurate with need".

I think a paragraph in the security considerations that addresses this issue would be appropriate.

[Ballot comment]
I dislike overloading protocols with exchanges of information that do not relate to the protocol functionality. However, at this phase, if the working group was chartered to do this work, I can accept such an extention as the GENINFO advertising of generic information. Separating it in a generic advertising extension rather than consuming from the expensive TLV space for each extension not related to routing is the right thing to do.

Maybe the introduction should say something about the motivation for such a generic container within IS-IS and make possible recommendations of what future extensions using this container should include (or should not include).

[Ballot discuss]
Most of the items in my original DISCUSS were addressed with edits which I find fully acceptable. Thanks for addressing these.

I still am left with my first issue which I would like to see discussed by the IESG and maybe addressed before approving the document.

I dislike overloading protocols with exchanges of information that do not relate to the protocol functionality. However, at this phase, if the working group was chartered to do this work, I can accept such an extention as the GENINFO advertising of generic information. However, in this specific case I do not see anything in the IS-IS WG charter that indicates that this work is within the WG goals. On the contrary the phrase

'The IS-IS Working Group is chartered
to document current protocol implementation practices and
improvements,
as well as to propose further extensions to be used within the scope
of
IS-IS and IP routing.'

may be read as saying the generic information advertising is not within the scope.

I do not even see the document on the Goals and Milestones list. Does it hide under another name? Is there any other record about this item being reviewed and approved by the IESG as a chartered item?

Maybe the introduction should say something about the need for such a generic container within IS-IS and possible recommendations of what future extensions using this container should include (or should not include).

[Ballot comment]
Thank you for this draft, it is a necessary addition to the IS-IS family and for your work to address my Discusses and Comments.

I have two small, non-blocking Comments remaining that could be looked at if the authors continue to work on the document.

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

---

This Comment moved from the Discuss...

I feel a bit of a lack discusion of backwards compatibility.
You need to cover how a legacy implementation will react to seeing the
new GENINFO TLV (a reference to an existing RFC will do), and then
consider how this will apply to the utility of the extension (for
example, if all speakers participating in the IS-IS instance must be
upgraded - I think they will because otherwise they will not see the
flags fields in the new TLV).

It would be helpful to add a brief statement in Section 4 along the lines of:

"According to the rules of [RFC4971] a legacy implementation receiving a GENINFO TLV will ..."

[Ballot discuss]
I support the publication of this document and I think it is a good
and proper addition to the ISIS protocol.

However, I have a specific technical concern. Section 6 says:

  The IS-IS WG of the IETF acts as the authority to determine whether
  information proposed to be advertised in IS-IS LSPs falls under this
  definition.

But then Section 8 says:

  Registration procedure is "Specification Required" as defined
  in [RFC5226]

If we are expecting to verify that the information falls under the
right category, then Specification Required does not appear to be
the right IANA rule. Or am I missing something?

[Ballot discuss]
The sole statement in the security considerations:

  This document raises no new security issues for IS-IS.

I don't think that is quite true, albeit in a rather cyclic manner.

First, I believe that the use of IS-IS as a transport does have security implications that need to be considered
when specifying a new geninfo application ID. It would be helpful to describe the limitations implied by this transport,
and when additional security mechanisms can be employed to extend the scope.  For example, the standard IS-IS
cleartext password  might be insufficient for some types of data, requiring deployment of RFC 5304 or 5310 authentication mechanisms.

Second, deployment of advanced IS-IS security mechanisms (e.g., RFC 5310 authentication) is something I
personally advocate.  However, if an IS-IS deployment were to deploy these mechanisms solely to support
advertisement of some generic information this may exacerbate any performance implications for the IS-IS
deployment and could be used to launch denial of service attacks.  That is, deploying IS-IS security mechanisms
*because* of the generic information would be costly for the IS-IS implementation and would violate the usual
precept of "security commensurate with need".

I think a paragraph or two (total) in the security considerations that addresses both these issues would be appropriate.

[Ballot discuss]
The sole statement in the security considerations:

  This document raises no new security issues for IS-IS.

I don't think that is quite true, albeit in a rather cyclic manner.

First, I believe that the use of IS-IS as a transport does have security implications that need to be considered
when specifying a new geninfo application ID. It would be helpful to describe the limitations implied by this transport,
and when additional security mechanisms can be employed to extend the scope.  For example, the standard IS-IS
cleartext password  might be insufficient for some types of data, requiring deployment of RFC 5304 or 5310 authentication mechanisms.

Deployment of advanced IS-IS security mechanisms (e.g., RFC 5310 authentication) is something I personally
advocate.  However, if an IS-IS deployment were to deploy these mechanisms to support advertisement of generic
information this may exacerbate any performance implications for the IS-IS deployment and could be used to launch
denial of service attacks.  That is, deploying IS-IS security mechanisms for the generic information would be costly
for the IS-IS implementation and would violate the usual precept of "security commensurate with need".

I think a paragraph or two (total) in the security considerations that addresses both these issues would be appropriate.

[Ballot discuss]
Assuming that Lars' clarification (no impact on IS-IS) is implemented, I would agree with the sole statement in the
security considerations:

  This document raises no new security issues for IS-IS.

However, I believe that the use of IS-IS as a transport does have security implications that need to be considered
when specifying a new geninfo application ID. It would be helpful to describe the limitations implied by this transport,
and when additional security mechanisms can be employed to extend the scope.  For example, the standard IS-IS
cleartext password  might be insufficient for some types of data, requiring deployment of RFC 5304 or 5310 authentication mechanisms.

It should also be noted that if the applications forces deployment of additional security mechanisms (e.g., RFC 5310
authentication) this may exacerbate any performance implications for the IS-IS deployment.

I think a paragraph or two (total) in the security considerations that addresses these issues would be appropriate.

[Ballot comment]
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?

[Ballot discuss]
What is the current status of isis-mi? How stable is it? (Specifically, how likely is it that changes there would cause this document to have to return to the working group later?). I agree with other's suggestion that isis-mi should be a normative reference.

[Ballot discuss]
1. I dislike overloading protocols with exchanges of information that do not relate to the protocol functionality. However, at this phase, if the working group was chartered to do this work, I can accept such an extention as the GENINFO advertising of generic information. However, in this specific case I do not see anything in the IS-IS WG charter that indicates that this work is within the WG goals. On the contrary the phrase

'The IS-IS Working Group is chartered
to document current protocol implementation practices and
improvements,
as well as to propose further extensions to be used within the scope
of
IS-IS and IP routing.'

may be read as saying the generic information advertising is not within the scope.

I do not even see the document on the Goals and Milestones list. Does it hide under another name?

Is there any other record about this item being reviewed and approved by the IESG as a chartered item?

2. I am confused by the recommendation in 3.2:

> The use of additional levels of subTLVs is discouraged due to the
  inherent inefficiency in encoding introduced because the parent
  subTLV must encode the nested subTLV length.  While this inefficiency
  is small (one additional octet), it may be sufficient to extend the
  total information about a single application object beyond the
  carrying capacity of a single GENINFO TLV.  Given that each
  Application ID can utilize the full range of subTLV codepoints (0 to
  255) without conflict with any other application, the need to be
  frugal in the use of APPSUBTLV codepoints is greatly reduced.

The last phrase confuses me, as it seems to go against the rest of the paragraph. I would suggest a clear explanation at this point.

3. In section 3.3 - it would be useful to explain what a 'public document' is. Is this the same as what RFC 5226 considers a 'public specification' or is this something else?

4. In Section 6:

> The applicability statement above is expected to cover some
  information currently being advertised by IS-IS in previously defined
  TLVs.  It is expected and seen as desirable that an effort be made to
  migrate the advertisement of such information to utilize the
  procedures defined in this document.

Are there any examples? From an operational deployment point of view how would the exchange of information be migrated from advertising in exiting previoulsy defined TLVs to an Application ID in the new General Info TLV?

5. I disgree with the claim made in the Security Considerations section that 'This document raises no new security issues for IS-IS'. I believe that when defining new applications that exchange generic information using IS-IS there is a risk that the basic protocol exchange be impacted and this needs to be mentioned.

6. The process required in the IANA Consideration section is not fully in tune with the statement made in section 6:

> The IS-IS WG of the IETF acts as the authority to determine whether
  information proposed to be advertised in IS-IS LSPs falls under this
  definition.

Is it supposed that the IS-IS WG will stay active for a long period of time to make determination whether new requests fall or not within the categories covered by IS-IS Decision process? What process will the WG follow - ask for an RFC to be writte for each request?

To me the process defined in Section 8 seems to be sufficient - the "Specification Required" procedure as defined in [RFC5226] implies the nomination of a Designated Expert, and while writing an RFC is the best specification the procedure can expect, documents published outside of the RFC path can also serve the purpose.

[Ballot discuss]
Thank you for this draft, it is a necessary addition to the IS-IS family. I look forward to moving to a "Yes" ballot when we have cleared up a number of minor points.

Discuss updated after emails with the authors.

---

Section 2

  In order to minimize the impact advertisement of GENINFO may have on
  the operation of routing, such advertisements MUST occur in the
  context of a non-zero instance of the IS-IS protocol as defined in
  [I-D.ietf-isis-mi].  Exceptions to this restriction MAY be allowed
  subject to restrictions discussed later in this document.

In Section 5, this is presented as:

  Advertisement of GENINFO therefore MUST occur in the context of a
  non-zero instance of the IS-IS protocol as defined in
  [I-D.ietf-isis-mi].  Exceptions to this policy MAY be allowed only
  when there exists a standards track RFC which defines the
  application.

If you say "MUST" I don't think you can allow a variation using "MAY".

Suggest...

Section 2
OLD
  In order to minimize the impact advertisement of GENINFO may have on
  the operation of routing, such advertisements MUST occur in the
  context of a non-zero instance of the IS-IS protocol as defined in
  [I-D.ietf-isis-mi].  Exceptions to this restriction MAY be allowed
  subject to restrictions discussed later in this document.
NEW
  In order to minimize the impact advertisement of GENINFO may have on
  the operation of routing, such advertisements MUST occur in the
  context of a non-zero instance of the IS-IS protocol as defined in
  [I-D.ietf-isis-mi] except where the rules for the use of the zero
  instance set out later in this document are followed.
END

Section 5
OLD
  Advertisement of GENINFO therefore MUST occur in the context of a
  non-zero instance of the IS-IS protocol as defined in
  [I-D.ietf-isis-mi].  Exceptions to this policy MAY be allowed only
  when there exists a standards track RFC which defines the
  application.
NEW
  Advertisement of GENINFO MUST occur in the context of a non-zero
  instance of the IS-IS protocol as defined in [I-D.ietf-isis-mi]
  except when the use in the zero instance is defined in a Standards
  Track RFC.
END

---

3.3.  Standardization Requirements

  GENINFO is intended to advertise information on behalf of
  applications whose operations have been defined in public documents.
  GENINFO is NOT intended to be used for proprietary or experimental
  purposes.

  The public document MUST include a description of the subTLV
  allocation policy.

I support the intent of this text, but I don't think it is clear.
For example, an experimental RFC is a public document. A proprietary
use may be documented in a public document.

Since the rgeistration rules are "Specification Required", I suggest
you refer to this directly, and re-state what "Specification
Required" means.

---

I feel a bit of a lack discusion of backwards compatibility.
You need to cover how a legacy implementation will react to seeing the
new GENINFO TLV (a reference to an existing RFC will do), and then
consider how this will apply to the utility of the extension (for
example, if all speakers participating in the IS-IS instance must be
upgraded - I think they will because otherwise they will not see the
flags fields in the new TLV).

It would be helpful to add a brief statement in Section 4 along the lines of:

"According to the rules of [RFC4971] a legacy implementation receiving a GENINFO TLV will ..."

---

Section 10.2

[I-D.ietf-isis-mi] looks like it is used as a normative reference in
Section 2.

[Ballot comment]
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].

[Ballot comment]
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.

[Ballot discuss]
Thank you for this draft, it is a necessary addition to the IS-IS family. I look forward to moving to a "Yes" ballot when we have cleared up a number of minor points.

---

Section 2

  In order to minimize the impact advertisement of GENINFO may have on
  the operation of routing, such advertisements MUST occur in the
  context of a non-zero instance of the IS-IS protocol as defined in
  [I-D.ietf-isis-mi].  Exceptions to this restriction MAY be allowed
  subject to restrictions discussed later in this document.

In Section 5, this is presented as:

  Advertisement of GENINFO therefore MUST occur in the context of a
  non-zero instance of the IS-IS protocol as defined in
  [I-D.ietf-isis-mi].  Exceptions to this policy MAY be allowed only
  when there exists a standards track RFC which defines the
  application.

If you say "MUST" I don't think you can allow a variation using "MAY".

---

Section 3

  o  Minimize the number of codepoints required

Does the GENINFO solution actually reduce the number of codepoints
required? I think you still need the same number because the same
number of things have to be identified.

Maybe

  o  Minimize the number of top-level codepoints required

---

Section 3.1

Do you need a registry for the Flags?

---

3.3.  Standardization Requirements

  GENINFO is intended to advertise information on behalf of
  applications whose operations have been defined in public documents.
  GENINFO is NOT intended to be used for proprietary or experimental
  purposes.

  The public document MUST include a description of the subTLV
  allocation policy.

I support the intent of this text, but I don't think it is clear.
For example, an experimental RFC is a public document. A proprietary
use may be documented in a public document.

Since the rgeistration rules are "Specification Required", I suggest
you refer to this directly, and re-state what "Specification
Required" means.

---

I feel a bit of a lack discusion of backwards compatibility.
You need to cover how a legacy implementation will react to seeing the
new GENINFO TLV (a reference to an existing RFC will do), and then
consider how this will apply to the utility of the extension (for
example, if all speakers participating in the IS-IS instance must be
upgraded - I think they will because otherwise they will not see the
flags fields in the new TLV).

And this leads me to worry about Section 6.

  The applicability statement above is expected to cover some
  information currently being advertised by IS-IS in previously defined
  TLVs.  It is expected and seen as desirable that an effort be made to
  migrate the advertisement of such information to utilize the
  procedures defined in this document.

In principle, this is fine, but I wonder how this change could be made
for deployed devices.

---

Section 10.2

[I-D.ietf-isis-mi] looks like it is used as a normative reference in
Section 2.

[Ballot comment]
(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.)

[Ballot discuss]
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.

[Ballot comment]
The abstract says "SHOULD be advertised" and "SHOULD be used", but conformance language does not belong in the abstract.

Please unpack acronyms on first use (TLV, PDU, LSP, etc.).

[Ballot discuss]
Section 5 states that "flooding of information not directly related to the use of the IS-IS protocol in support of routing degrades the operation of the protocol." Therefore I think the Security Considerations section needs to discuss the possibility of denial of service attacks, preferably with reference to RFC 4732.

IANA Last Call Comments:

IANA has a single question about the IANA Actions in this document.

IANA understands that there are two actions that need to be completed upon
approval of this document.

First, in the TLV Codepoints Registry located at:
http://www.iana.org/assignments/isis-tlv-codepoints
the following assignment must be added to the registry:

Type Description IIH LSP SNP
---- ----------------------------------- --- --- ---
251 Generic Information n y n

Second, IANA understands that a new registry must be created for Application
Identifiers which may be used in the new Generic Information TLV. IANA
Question: would it be acceptable to make this new registry a part of the
collection of registries located at:
http://www.iana.org/assignments/isis-tlv-codepoints ?

IANA understands that the name of the new registry would be:
Application Identifiers for the Generic Information TLV
The reference would be the approved document and the registration procedure
would be Specification required.

The new registry would have four values:

ID Description Allowed in Reference
Instance Zero
=== ========================== ================= ===============

ID will always be an unsigned 16-bit number between 0 and 65535. Allowed in
Instance Zero is always either the letter "Y" or "N". The only initial value in
this registry is the number 0 which should simply be marked "reserved."

IANA understands that these are the only actions required upon approval of this
document.

This is a well written draft and I only have one comment:

This draft needs text to define the IANA criteria for allocating Application Identifiers and for the allocation of Application specific subTLVs.

The authors need to review RFC5226 section 4.1 and to update the IANA section to state the IANA policy that the WG intended for these codepoints.

The authors may wish to consider whether an Application Identifier specification should independently set the policy for the subTLV allocation, or whether this document should set a policy or an element of a policy that covers all subTLVs

The draft also needs text to describe the information that IANA are required to record in the AI and subTLV registry.

PROTO write up for: draft-ietf-isis-genapp-02.txt by Chris Hopps.

Shepherding WG-Chair: Chris Hopps (chopps@rawdofmt.org)

    Q1) Have the chairs personally reviewed this version of the
    Internet Draft (ID), and in particular, do they believe
    this ID is ready to forward to the IESG for publication?

A1) Yes.

    Q2) Has the document had adequate review from both key WG
    members and key non-WG members? Do you have any concerns
    about the depth or breadth of the reviews that have been
    performed?

A2) Adequately reviewed.

    Q3) Do you have concerns that the document needs more review
    from a particular (broader) perspective (e.g., security,
    operational complexity, someone familiar with AAA, etc.)?

A3) No concerns.

    Q4) Do you have any specific concerns/issues with this
    document that you believe the ADs and/or IESG should be
    aware of? For example, perhaps you are uncomfortable with
    certain parts of the document, or have concerns whether
    there really is a need for it. In any event, if your issues
    have been discussed in the WG and the WG has indicated it
    that it still wishes to advance the document, detail those
    concerns in the write-up.

A4) No concerns.

    5) How solid is the WG consensus behind this document? Does
    it represent the strong concurrence of a few individuals,
    with others being silent, or does the WG as a whole understand
    and agree with it?

A5) Strong Consensus.

    6) Has anyone threatened an appeal or otherwise indicated
    extreme discontent? If so, please summarise the areas of
    conflict in separate email to the Responsible Area Director.

A6) No.

    7) Have the chairs verified that the document adheres to
    all of the ID Checklist items ?

A7) Yes.

    8) Is the document split into normative and informative
    references?  Are there normative references to IDs, where
    the IDs are not also ready for advancement or are otherwise
    in an unclear state? (note here that the RFC editor will
    not publish an RFC with normative references to IDs, it
    will delay publication until all such IDs are also ready
    for publication as RFCs.)

A8) Yes.

    9) What is the intended status of the document? (e.g.,
    Proposed Standard, Informational?)

A9) Proposed Standard.

** Technical Summary

Increasing use of IS-IS for the flooding of information not directly used
by the primary protocol function has created a need for a generalized
method for incorporating said new information without impacting the primary
IS-IS protocol function. This specification provides this method.

** Working Group Summary

There consensus was strong for this specification. Discussions regarding
this specification primarily involved which extensions the specification
would apply to.

** Protocol Quality

There are currently no implementations of this specification. This
specification is required to be in place so that new applications may then
utilize it in their design.