Review of draft-ietf-pals-status-reduction-04

Jürgen Schönwälder <j.schoenwaelder@jacobs-university.de> Tue, 28 March 2017 07:35 UTC

Return-Path: <j.schoenwaelder@jacobs-university.de>
X-Original-To: ietf@ietf.org
Delivered-To: ietf@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id E6335129413; Tue, 28 Mar 2017 00:35:18 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
From: Jürgen Schönwälder <j.schoenwaelder@jacobs-university.de>
To: ops-dir@ietf.org
Cc: draft-ietf-pals-status-reduction.all@ietf.org, ietf@ietf.org, pals@ietf.org
Subject: Review of draft-ietf-pals-status-reduction-04
X-Test-IDTracker: no
X-IETF-IDTracker: 6.48.1
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <149068651891.30599.6466255675652833743@ietfa.amsl.com>
Date: Tue, 28 Mar 2017 00:35:18 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf/HdzoEkqicw6DXX84DO2c5wcmEJA>
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.22
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ietf/>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 28 Mar 2017 07:35:19 -0000

Reviewer: Jürgen Schönwälder
Review result: Has Nits

Disclaimer: I have not much clue about MPLS LSP PWs and hence I am
reading this from a perspective of a clueless outsider.

Section 1.2 is not really about terminology but instead it basically
expands acronyms. The section does not define any terms or does it
make it clear where terms are defined. A reader who does not know
T-PE
will not be pointed to a document that defines 'Terminating Provider
Edge Node of MS-PW'. I usally find terminology sections more useful
if
they say where definitions of terms get be found.

Section 3: s/the the/the/

Section 4: What is the 'Version' field in the message format?

Section 4: There is an 8-bit field marked U C Flags and I _assume_
the
U and C bits are the 'first' two bits and the 'remaining bits are the
flags managed by IANA. Perhaps make this clearer, e.g.:

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Last Received Seq Number     | Message Type  |U|C|   Flags   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Or alternatively simply name the entire 8-bit flags field like you do
in the text where you refer to Message Flags and then explain in the
text under the 'Message Flags' that the first two bits have a fixed
meaning.

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Last Received Seq Number     | Message Type  | Message Flags |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

This option carries less information but then you use 'Message Flags'
in several places and you also request an IANA registry for Message
Flags where the U and C bit are allocated. Looking at the IANA text,
it says 'bit position' 0 and 1. Not sure this is clear enough, you
seem to number bits in the order 0, 1, 2, ...

It turns out we have several slightly different labels further down
in
the document for this flags field throughout the document - this
makes
searching in the text difficult, please use a single consistent name
for this message field.

Section 8.2 says values 1 and 2 are defined in this document but then
it seems value 3 is also allocated, no?

Subsections of section 8 switches several times between decimal and
hexadecimal numbers. Perhaps things get clearer if a single number
system (e.g., hexadecimal) is used when talking about a specific
registry. Numbers like 134,217,728 look somewhat confusing, 0x8000000
seems simpler.