[Isis-wg] Mirja Kühlewind's No Objection on draft-ietf-isis-rfc4971bis-03: (with COMMENT)

"Mirja Kuehlewind" <ietf@kuehlewind.net> Wed, 17 August 2016 14:23 UTC

Return-Path: <ietf@kuehlewind.net>
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 6A57F12DD03; Wed, 17 Aug 2016 07:23:25 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
From: Mirja Kuehlewind <ietf@kuehlewind.net>
To: The IESG <iesg@ietf.org>
X-Test-IDTracker: no
X-IETF-IDTracker: 6.29.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <147144380526.12231.16184751507970029648.idtracker@ietfa.amsl.com>
Date: Wed, 17 Aug 2016 07:23:25 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/isis-wg/Xd7T-QFFLMl9wTTEvLgGDpysz2U>
Cc: isis-wg@ietf.org, chopps@chopps.org, isis-chairs@ietf.org, draft-ietf-isis-rfc4971bis@ietf.org
Subject: [Isis-wg] Mirja Kühlewind's No Objection on draft-ietf-isis-rfc4971bis-03: (with COMMENT)
X-BeenThere: isis-wg@ietf.org
X-Mailman-Version: 2.1.17
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: Wed, 17 Aug 2016 14:23:27 -0000

Mirja Kühlewind 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:
----------------------------------------------------------------------

I know this is a bis doc that mainly clarifies one point. However, as
there were also other smaller updates, here are some additional comments
that could be considered:

1) To me the text in section 2 reads like: if S is not set D should be
ignored. Is this correct? If so, it could be spelled out like this. If
not, what happens if S is not set but D is?

2) The text says: „Where a receiving system has two copies of a
CAPABILITY TLV from the
   same system that have different settings for a given attribute, the
   procedure used to choose which copy shall be used is undefined.“
  Why is there no default given here? Not defining something like this
can lead to problems. I would strongly recommend to define a default
behavior.

3) Further it says: „How partial support may impact the operation of the
   capabilities advertised within the Router CAPABILITY TLV is outside
   the scope of this document.“
   While it might be true that this is specific to the capability, I
would put a MUST requirement in here for future specifiactions: Partial
suport MUST be defined in the document that describes the subTLV.

4) On this sentence: „Routers that do not support the Router CAPABILITY
TLV MUST silently
   ignore the TLV(s) and continue processing other TLVs in the same
LSP.“
   What does "silently" mean here? Is it not allowed to log such an
event? I would recommend to either clarify that "silently" means here or
remove that word.

5) In this sentence: "If leaking of the CAPABILITY TLV is required, the
entire CAPABILITY
   TLV MUST be leaked into another level without change even though it
   may contain some sub-TLVs which are unsupported by the Router doing
   the leaking.“
  I would recomend to use the normative language differently to be clear
about what it applies to: 
"If leaking of the CAPABILITY TLV is required, the entire CAPABILITY
   TLV MUST NOT change sub-TLVs which are unsupported by the Router
doing
   the leaking.“

6) In section 5: „Note that an integrity mechanism, such as the one
   defined in [RFC5304] or [RFC5310], should be applied if there is high
   risk resulting from modification of capability information.“ 
  Why is that a SHOULD and what's a „high risk“?  It should me either
"MUST be applied at high risk" and defining what a high risk is, or it
should be "SHOULD be applied at (any) risk".