[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".
- Re: [Isis-wg] Mirja Kühlewind's No Objection on d… Les Ginsberg (ginsberg)
- [Isis-wg] Mirja Kühlewind's No Objection on draft… Mirja Kuehlewind