[CCAMP] Benjamin Kaduk's No Objection on draft-ietf-ccamp-layer0-types-08: (with COMMENT)

Benjamin Kaduk via Datatracker <noreply@ietf.org> Tue, 01 December 2020 23:33 UTC

Return-Path: <noreply@ietf.org>
X-Original-To: ccamp@ietf.org
Delivered-To: ccamp@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B2DD3A0C3A; Tue, 1 Dec 2020 15:33:44 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Benjamin Kaduk via Datatracker <noreply@ietf.org>
To: "The IESG" <iesg@ietf.org>
Cc: draft-ietf-ccamp-layer0-types@ietf.org, ccamp-chairs@ietf.org, ccamp@ietf.org, Daniele Ceccarelli <daniele.ceccarelli@ericsson.com>, daniele.ceccarelli@ericsson.com
X-Test-IDTracker: no
X-IETF-IDTracker: 7.23.0
Auto-Submitted: auto-generated
Precedence: bulk
Reply-To: Benjamin Kaduk <kaduk@mit.edu>
Message-ID: <160686562369.24294.3917522744750193218@ietfa.amsl.com>
Date: Tue, 01 Dec 2020 15:33:44 -0800
Archived-At: <https://mailarchive.ietf.org/arch/msg/ccamp/uLEFVHuigwIYetjUBes8ODOz85g>
Subject: [CCAMP] Benjamin Kaduk's No Objection on draft-ietf-ccamp-layer0-types-08: (with COMMENT)
X-BeenThere: ccamp@ietf.org
X-Mailman-Version: 2.1.29
List-Id: Discussion list for the CCAMP working group <ccamp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ccamp>, <mailto:ccamp-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ccamp/>
List-Post: <mailto:ccamp@ietf.org>
List-Help: <mailto:ccamp-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ccamp>, <mailto:ccamp-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 01 Dec 2020 23:33:51 -0000

Benjamin Kaduk has entered the following ballot position for
draft-ietf-ccamp-layer0-types-08: 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:


Section 1.2

   YANG module ietf-layer0-types (defined in Section 3) references
   [RFC6163], [RFC7205], and [RFC7698].

RFC 7205 looks like a typo for 6205 -- I don't think that "Use Cases for
Telepresence Multistreams" is relevant for WSON.  That said, we
reference 6205 many times in the rest of the document, so (IIUC) we
don't need to mention it here in order to have a reference in the
document outside of the module itself?

Section 2

I'm not sure how appropriate RFC 6205 is as a reference for all of the
indicated terms; e.g., I don't see mention of "start", "end", "range",
or "hop" as applying to labels, there.

Section 3

     grouping l0-label-range-info {
         "Information for layer 0 label range.";

nit(?): "information for" makes me expect that this will be describing
the range itself, but the contained type and priority seem to be more
metadata about the range than the range itself.  To me, writing
"Information about the layer 0 label range" would feel more natural.

     grouping flexi-grid-label-range-info {
         "Info of Flexi-grid-specific label range";

nit: "Info of" seems rather colloquial; the same "Information about"
construction I suggested above seems like it would work well here, since
this is also a -label-range-info grouping.

It seems unusual to me (admittedly, not a YANG expert) that the
descriptions for min-slot-width-factor and max-slot-width-factor
separately refer to a "range" when each one only provides half of the
range.  I guess this is related to Erik's comment.

              Minimum slot width should be smaller than or equal to
              Maximum slot width. ";

Similarly, this restriction seems like one that can be expressed as a
YANG "must" directive, which it looks like Rob already noted.

Section 4

   modules.  It is critical consider how imported definitions will be
   utilized and accessible via RPC operations, as the resultant schema
   will have data nodes that can be writable, or readable, and will have

nit: "critical to consider"

Section 8.2

Don't RFCs 6163, 6205, 7698, and 8363 need to be normative since they
are used as references for YANG elements?