[i2rs] FW: Shepherds's review of the draft-ietf-i2rs-yang-network-topo/

"Susan Hares" <shares@ndzh.com> Fri, 11 November 2016 19:47 UTC

Return-Path: <shares@ndzh.com>
X-Original-To: i2rs@ietfa.amsl.com
Delivered-To: i2rs@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id 782DE129CAF for <i2rs@ietfa.amsl.com>; Fri, 11 Nov 2016 11:47:04 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.946
X-Spam-Status: No, score=0.946 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845, HTML_MESSAGE=0.001] autolearn=no autolearn_force=no
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id WcnTnJPG22CK for <i2rs@ietfa.amsl.com>; Fri, 11 Nov 2016 11:47:02 -0800 (PST)
Received: from hickoryhill-consulting.com (50-245-122-97-static.hfc.comcastbusiness.net []) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D7567129CA8 for <i2rs@ietf.org>; Fri, 11 Nov 2016 11:47:01 -0800 (PST)
X-Default-Received-SPF: pass (skip=forwardok (res=PASS)) x-ip-name=;
From: "Susan Hares" <shares@ndzh.com>
To: <i2rs@ietf.org>
References: <016301d23c51$c1a7e8b0$44f7ba10$@ndzh.com>
In-Reply-To: <016301d23c51$c1a7e8b0$44f7ba10$@ndzh.com>
Date: Fri, 11 Nov 2016 14:44:34 -0500
Message-ID: <017101d23c54$08b6c1c0$1a244540$@ndzh.com>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_0172_01D23C2A.1FE4FF80"
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AQKXBSDx2dZzJusYsVkUBMOln74RZp9KnZuA
Content-Language: en-us
X-Authenticated-User: skh@ndzh.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/i2rs/-sKDpchDPPUtiT3ye43BfoLY5Zk>
Cc: 'Alex Clemm' <alex@clemm.org>, 'Alia Atlas' <akatlas@gmail.com>
Subject: [i2rs] FW: Shepherds's review of the draft-ietf-i2rs-yang-network-topo/
X-BeenThere: i2rs@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: "Interface to The Internet Routing System \(IRS\)" <i2rs.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/i2rs>, <mailto:i2rs-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/i2rs/>
List-Post: <mailto:i2rs@ietf.org>
List-Help: <mailto:i2rs-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/i2rs>, <mailto:i2rs-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 11 Nov 2016 19:47:04 -0000

Forwarding the shepherd's report.  I forgot to copy this to the WG. 


Sue Hares 


From: Susan Hares [mailto:shares@ndzh.com] 
Sent: Friday, November 11, 2016 2:28 PM
To: 'Alex Clemm'; jmedved@cisco.com
Cc: 'Benoit Claise'; 'Alia Atlas'
Subject: Shepherds's review of the draft-ietf-i2rs-yang-network-topo/


Alex and Jan: 


I apologize that my shepherd's review is so tardy.  In my Shepherd's review
I found the following things that you should correct: 


1)      Please add an  RFC2199 definition in the text and RFC2199 reference

2)      Please replace the Yang 1.0 reference with Yang 1.1 reference

3)      Please add an IANA considerations section 

4)      Please check you need the pre-2008 IPR 

5)      Add a model interactions section - I've provided some text 

6)      Fix references to other documents, 

7)      Fix the lines that "id-nits" complains about. 

8)      Please check that all the authors in the list are key contributors.
The IESG statement provides a normal limit of 5 authors on any draft. 


I've included below details on these issues, and some suggested text for
fixing them.   I believe that most of these can be fixed in a few days.  If
you would try to upload a document on 11/14 - I will try to push this
forward with the ADs so we can begin IETF LC shortly.  If we begin by 11/16,
we can put this on the 12/01/2016 telechat of the IESG. 







#1 - Add the following text to The Terminology section (see RFC8022) for
another example


   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   document are to be interpreted as described in [RFC2119
<https://tools.ietf.org/html/rfc2119> ].


#2 Change to Add New Yang reference - replace 6021 with RFC6991 

#3 - Add IANA Considerations as follows

  #xx IANA Considerations

   This document registers the following namespace URIs in the "IETF XML
   Registry" [RFC3688 <https://tools.ietf.org/html/rfc3688> ]:
   URI:  urn:ietf:params:xml:ns:yang:ietf-network
   Registrant Contact: The IESG.
   XML: N/A; the requested URI is an XML namespace.
   Registrant Contact: The IESG.
   XML: N/A; the requested URI is an XML namespace.
   This document registers the following YANG modules in the "YANG
   Module Names" registry [RFC6020 <https://tools.ietf.org/html/rfc6020> ]:
   Name:         ietf-network
   Namespace:    urn:ietf:params:xml:ns:yang:ietf-network 
   Prefix:       l3t
   Reference:    draft-ietf-i2rs-yang-network-topo-06.txt (RFC form) 
   Name:         ietf-network-topology 
   Namespace:    urn:ietf:params:xml:ns:yang:ietf-network-topology 
   Prefix:       lnk
   Reference:    draft-ietf-i2rs-yang-network-topo-06.txt (RFC form) 


#4  - do you really need this pre-2008 information - I do not think it is


63         This document may contain material from IETF Documents or IETF
64         Contributions published or made publicly available before
65         10, 2008.  The person(s) controlling the copyright in some of
66         material may not have granted the IETF Trust the right to allow
67         modifications of such material outside the IETF Standards
68         Without obtaining an adequate license from the person(s)
69         the copyright in such materials, this document may not be
70         outside the IETF Standards Process, and derivative works of it
71         not be created outside the IETF Standards Process, except to
72         it for publication as an RFC or to translate it into languages
73         than English.



#5 - Add interaction section with the following information (you can revise


Review of links to other yang models: 

 1) links to ietf-yang-types [rfc6991, ietf-inet-types [RFC6991]

2) links to topology model - ietf-network, ietf-network-topology -


Interaction with other Yang models: 

This is a protocol independent yang model with topology information by
design it does not link to the following configuration models;  

2)  ietf-interfaces model [RFC7223] 

3)  ietf-routing yang model [RFC8022]  

6) I2RS RIB (ephemeral state RIB) or configuration extended RIB  (


Topology information into the model without linking to these models.  


Why this is useful in ephemeral state:  The approach to not link to any
configuration model but to let topology process load information from OSPF
into the data model means that there is no model link between configuration
state and topology.  The assumption is the routing process uploading the
topology model knows how to do this.  The NETCONF or RESTCONF processes
simply reads, reports notifications, and logs the data. 


Writes from ephemeral state to the data models: These data models allow the
the NETCCONF/RESTCONF process to write a logical topology link.  Exactly how
this write operates depends on the routing process.  This model obeys the
requirements for the ephemeral state found in the document


#6 -  Fix the references to other documents  

          RFC6241 - needs an explicit link in the text 

          RFC6021 - needs to be replaced by RFC6991 

          draft-ietf-netconf-yang-push - needs to be updated 

           replace [topology-use-cases]  with


   7) Try to fix line nits - and rerun the nits program 

    [219, 244, 248, 257,,680]