[mpls] Mirja Kühlewind's No Objection on draft-ietf-mpls-residence-time-14: (with COMMENT)

Mirja Kühlewind <ietf@kuehlewind.net> Wed, 01 March 2017 16:48 UTC

Return-Path: <ietf@kuehlewind.net>
X-Original-To: mpls@ietf.org
Delivered-To: mpls@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 04716129550; Wed, 1 Mar 2017 08:48:53 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
From: =?utf-8?q?Mirja_K=C3=BChlewind?= <ietf@kuehlewind.net>
To: "The IESG" <iesg@ietf.org>
X-Test-IDTracker: no
X-IETF-IDTracker: 6.46.1
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <148838693301.7079.14351576385669069452.idtracker@ietfa.amsl.com>
Date: Wed, 01 Mar 2017 08:48:53 -0800
Archived-At: <https://mailarchive.ietf.org/arch/msg/mpls/BtIfIQ5sp5J54Kr4lTpcaoFSeYs>
Cc: draft-ietf-mpls-residence-time@ietf.org, mpls@ietf.org, mpls-chairs@ietf.org
Subject: [mpls] =?utf-8?q?Mirja_K=C3=BChlewind=27s_No_Objection_on_draft-i?= =?utf-8?q?etf-mpls-residence-time-14=3A_=28with_COMMENT=29?=
X-BeenThere: mpls@ietf.org
X-Mailman-Version: 2.1.17
List-Id: Multi-Protocol Label Switching WG <mpls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mpls>, <mailto:mpls-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/mpls/>
List-Post: <mailto:mpls@ietf.org>
List-Help: <mailto:mpls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mpls>, <mailto:mpls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 01 Mar 2017 16:48:53 -0000

Mirja Kühlewind has entered the following ballot position for
draft-ietf-mpls-residence-time-14: 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:


High level comment:
Maybe extend the security section a bit and describe what can happen in
the worse case if the value has been modified to a too high or too low
value; and maybe even given some guidance on performing additional checks
to figure out if a given value is reasonable for a given path or not.

- Can you explain why PTPType, Port ID, and Sequence ID are needed in the
PTP Sub-TLV format if those values are already in the PTP packet itself
that follows?
- Why is it necessary to define PTP sub-TLV (and have a registry for one
value only)? Are you expecting to see more values here? What would those
values be?
- Similar to Spencer's question: Why don't you also define a Sub-TLV
format for NTP?
- sec 4.3: "RTM (capability) - is a three-bit long bit-map field with
      defined as follows:
      *  0b001..."
  Maybe I don't understand what a bit-map field is here but these are
more then 3 bits...?
- also sec 4.3.: "Value contains variable number of bit-map fields so
that overall
      number of bits in the fields equals Length * 8."
  However there is no field 'Value' in the figure... Also the following
explanation about future bit-maps is really confusing to me; why don't
you just say that the rest as indicated by the length field must be
padded with zeros...?
- Should section 4.8 maybe be a subsection of 4.7? This part confused me
a bit because the example seems to be generic but the rest is RSVP-TE
specific, right? Maybe move the example as a separate section before or
after the whole section 4...?

- Maybe change to title to: Residence Time Measurement (RTM) in MPLS
- There are (still) some not spelled out abbreviations (LDP, PW); in turn
others are extended twice (e.g. PTP)...
- In figure 1, I would rename 'Value' to 'Sub-TLV' and maybe also
indicate it as optional in the figure: Sub-TLV (optional)