[CCAMP] Robert Wilton's Discuss on draft-ietf-ccamp-mw-topo-yang-10: (with DISCUSS and COMMENT)

Robert Wilton via Datatracker <noreply@ietf.org> Tue, 13 February 2024 11:46 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 8A6A0C14F69F; Tue, 13 Feb 2024 03:46:52 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Robert Wilton via Datatracker <noreply@ietf.org>
To: The IESG <iesg@ietf.org>
Cc: draft-ietf-ccamp-mw-topo-yang@ietf.org, ccamp-chairs@ietf.org, ccamp@ietf.org, daniele.ietf@gmail.com, daniele.ietf@gmail.com
X-Test-IDTracker: no
X-IETF-IDTracker: 12.5.0
Auto-Submitted: auto-generated
Precedence: bulk
Reply-To: Robert Wilton <rwilton@cisco.com>
Message-ID: <170782481255.46821.7515679448354761138@ietfa.amsl.com>
Date: Tue, 13 Feb 2024 03:46:52 -0800
Archived-At: <https://mailarchive.ietf.org/arch/msg/ccamp/M3TmBK-MqO0ApjFC0QGquYYylS4>
Subject: [CCAMP] Robert Wilton's Discuss on draft-ietf-ccamp-mw-topo-yang-10: (with DISCUSS and COMMENT)
X-BeenThere: ccamp@ietf.org
X-Mailman-Version: 2.1.39
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, 13 Feb 2024 11:46:52 -0000

Robert Wilton has entered the following ballot position for
draft-ietf-ccamp-mw-topo-yang-10: Discuss

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/about/groups/iesg/statements/handling-ballot-positions/ 
for more information about how to handle DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-ccamp-mw-topo-yang/



----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

Hi,

Thanks for standardising another YANG model.  I'm balloting discuss because I
think that there is a small bug in the YANG module that needs to be fixed, but
otherwise I intend to move to Yes.

(1) p 10, sec 2.5.  Microwave Topology YANG Module

      augment "/nw:networks/nw:network/nw:node/tet:te"
           + "/tet:te-node-attributes" {
       when "/nw:networks/nw:network/nw:network-types"
          + "/tet:te-topology/mwt:mw-topology" {

I think that you probably need to change the when statement to a relative path,
otherwise it will be checking for any network having a microwave topology
rather that this network instance having a microwave topology.


----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

I also have a few non-blocking suggestions that may improve this document:

Minor level comments:

(2) p 16, sec Appendix A.  Microwave Topology Model with base topology models

    |  +--rw node* [node-id]
    |  |  +--rw node-id                   node-id
    |  |  +--rw supporting-node* [network-ref node-ref]
    |  |  |  +--rw network-ref  -> ../../../supporting-network/
   network-ref

I'm not sure whether a line length option has been specified to pyang when
generating the tree output, but that may help make it wrap better and become
more readable.  It might be worth adding a note to the RFC editor to see if you
can manually improve this tree diagram before RFC publication.  E.g., perhaps
the referenced path of some of the long leaf-refs should be elided altogether.

(3) p 18, sec Appendix A.  Microwave Topology Model with base topology models

A.1.  Instance data for 2+0 mode for a bonded configuration

Probably having a bit more of a description of what is being configured here,
e.g., referencing back to the diagram (if appropriate), may be helpful to
readers.

(4) p 24, sec Appendix A.  Microwave Topology Model with base topology models

A.2.  Instance data for 1+1 mode for a protected configuration

Similarly, having a bit more of a description of what is being configured here,
e.g., referencing back to the diagram (if appropriate), may be helpful to
readers.

(5) p 30, sec Appendix B.  Microwave Topology Model with example extensions

   This appendix provides examples of how the Microwave Topology Model
   can be used with the interface reference topology (ifref)

Do you want to explicitly state this as "This non-normative appendix", since I
presume that you only have, and only want to have, informative references to
those two RFCs?  You may also want to cite specific versions of those drafts
rather than the latest one.  You could also add a note to the RFC editor to
check/update this to the latest version of those drafts at the time of
publication.

(6) p 43, sec Appendix B.  Microwave Topology Model with example extensions

   This document was prepared using kramdown (thanks Martin Thomson).

Note the kramdown RFC tool is written/maintained by Carsten Bormann, Martin did
the github integrations.