Subject: [Isis-wg] Ben Campbell's No Objection on draft-ietf-isis-rfc4971bis-03: (with COMMENT)

From: "Ben Campbell" <[email-masked]>
Date: Tue, 16 Aug 2016 12:58:11 -0700

Ben Campbell has entered the following ballot position for
draft-ietf-isis-rfc4971bis-03: No Objection

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-rfc4971bis/

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

The first sentence in section 4 says:

   Routers that do not support the Router CAPABILITY TLV MUST silently
   ignore the TLV(s) and continue processing other TLVs in the same LSP.

Is this the authoritative text for a new requirement, or is that
preexisting behavior defined elsewhere? If the former, why would we
expect an implementation that does not implement this spec (perhaps the
implementors haven't read it) to honor this requirement? If the latter,
then please state it descriptively (i.e. without 2119 keywords),
preferably with a citation.

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Tue, 16 Aug 2016 20:31:51 +0000

Ben -

> -----Original Message-----
> From: Ben Campbell [mailto:[email-masked]]
> Sent: Tuesday, August 16, 2016 12:58 PM
> To: The IESG
> Cc: [email-masked]; Christian Hopps; [email-masked];
> [email-masked]; [email-masked]
> Subject: Ben Campbell's No Objection on draft-ietf-isis-rfc4971bis-03: (with
> COMMENT)
> 
> 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.)
> 
> 
> Is this the authoritative text for a new requirement, or is that preexisting
> behavior defined elsewhere? If the former, why would we expect an
> implementation that does not implement this spec (perhaps the
> implementors haven't read it) to honor this requirement? If the latter, then
> please state it descriptively (i.e. without 2119 keywords), preferably with a
> citation.
> 
[Les:] Repeating my previous reply to Alexey who had a similar comment:

"Ignoring TLVs/sub-TLVs that are not understood is fundamental to the IS-IS protocol and defined in the base spec ISO 10589 (which is referenced). Repeating this is strictly speaking unnecessary - but was done in the original RFC as a point of emphasis."

Normative language is quite appropriate here. It is what guarantees backwards compatibility when new TLVs are introduced.

   Les