[Isis-wg] Alvaro Retana's No Objection on draft-ietf-isis-auto-conf-04: (with COMMENT)

Alvaro Retana <aretana@cisco.com> Fri, 07 April 2017 20:31 UTC

Return-Path: <aretana@cisco.com>
X-Original-To: isis-wg@ietf.org
Delivered-To: isis-wg@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 5A4A8124BFA; Fri, 7 Apr 2017 13:31:09 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Alvaro Retana <aretana@cisco.com>
To: "The IESG" <iesg@ietf.org>
Cc: draft-ietf-isis-auto-conf@ietf.org, Hannes Gredler <hannes@gredler.at>, isis-chairs@ietf.org, isis-wg@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 6.49.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <149159706927.11119.12965682520855681020.idtracker@ietfa.amsl.com>
Date: Fri, 07 Apr 2017 13:31:09 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/isis-wg/uNTrmSQZWAn1c_iZmGy47h5PTHM>
Subject: [Isis-wg] Alvaro Retana's No Objection on draft-ietf-isis-auto-conf-04: (with COMMENT)
X-BeenThere: isis-wg@ietf.org
X-Mailman-Version: 2.1.22
List-Id: IETF IS-IS working group <isis-wg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/isis-wg>, <mailto:isis-wg-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/isis-wg/>
List-Post: <mailto:isis-wg@ietf.org>
List-Help: <mailto:isis-wg-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/isis-wg>, <mailto:isis-wg-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 07 Apr 2017 20:31:09 -0000

Alvaro Retana has entered the following ballot position for
draft-ietf-isis-auto-conf-04: 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-auto-conf/



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

I have a series of comments -- they don't add up to a DISCUSS, but I
think it is important that they are solved before publication.

(1) In Section 3.3. (Router-Fingerprint TLV), the format presented
doesn't actually show the "flags field", which is described in the text,
but it shows its contents.   The length is defined as "the length of the
value field", but the figure doesn't explicitly show the Value field.  It
is probably obvious that the flags field + Router Fingerprint = Value,
but it would be nice to be specific.

Suggestion: include the 1 octet "flags field" in the drawing -- if
needed, then show the detail (where the S and A bits are) in the
description of the field.


(2) What about the other bits in the Flag field, how should they be
registered in the future (if needed)?  Please ask IANA to define a
registry for them.

(3) Section 3.1. (IS-IS Default Configuration) mentions several TLVs that
MUST NOT be used...and Section 3.3. (Router-Fingerprint TLV) says that
this TLV MUST NOT be included in an LSP with a non-zero LSP number.  What
should a receiving node do if any of those conditions are not true?

(4) s/3.4.3.  IS-IS System ID Duplication Detection and Resolution/3.4.3.
 IS-IS System ID Duplication Detection

(5) I thought the point of this document was for use in "unmanaged
deployments.  It allows IS-IS to be used without the need for any
configuration by the user."  But Section 3.5. (Additional IS-IS TLVs
Usage Guidelines) has recommendations for configuration options,
including manually configured adjacencies (which should not be allowed
according to Section 3.4.2. (Adjacency Formation)).  Isn't this against
the stated reasons for this document?

(6) Authentication is one of those features that could be manually
configured -- but the default is no authentication.  There's a
higher-than-usual risk of a node listening on the network (probably a
bigger problem for the user traffic), but also one that could listen to
the Hellos and purposefully trigger the duplicate resolution mechanism to
continuously run.  This risk should be highlighted in the Security
Considerations because it is newly introduced here. [Robert Sparks
pointed this risk out during his GenArt review.]