[i2rs] FW: draft-ietf-i2rs-yang-l3-topology-04 - need revision -05 and IPR statements.

["Susan Hares" <[e-mail]>]

Attached is the Shepherd's report for
draft-ietf-i2rs-yang-l3-topology-04.txt.   I forgot to copy the messages to
the working group. 

 

Authors:

I apologize for the delay in getting this shepherd report done.  It should
have come during WG LC. 

 

Sue 

 

From: Susan Hares [mailto:[e-mail]] 
Sent: Friday, November 11, 2016 1:39 PM
To: [e-mail]; [e-mail]
Cc: 'Benoit Claise'; 'Alia Atlas'
Subject: RE: draft-ietf-i2rs-yang-l3-topology-04 - need revision -05 and IPR
statements. 

 

Alex and Jan:

 

I suggest you add a section on interaction with other yang modules.  I've
given you some ideas on how to comment in the text.  This type of text seem
to smooth the path of other yang modules going through the IESG. 

 

Sue Hares 

---------------

 

Interaction with other Yang models: 

This document references the following IETF standard models:
ietf-yang-types [rfc6991], ietf-inet-types [RFC6991].  It relies on the i2RS
topology models: ietf-network and ietf-network-topology
(draft-ietf-i2rs-yang-network-topo-06. 
 
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]  
4)  OSPF configuration yang module ( ietf-ospf or the ospf bfd)
[draft-ietf-ospf-yang] 
5) ISIS configuration yang module (idraft-ietf-isis-yang-isis-cfg) 
6) I2RS RIB (ephemeral state RIB) or configuration extended RIB  (
draft-acee-rtgwg-yang-rib-extend) 
 
It does important OSPF, ISIS, and statically configured 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
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
draft-ietf-i2rs-ephemeral-state.   
 

Sue 

 

From: Susan Hares [mailto:[e-mail]] 
Sent: Friday, November 11, 2016 12:23 PM
To: [e-mail]; [e-mail]
Cc: 'Benoit Claise'; 'Alia Atlas'
Subject: draft-ietf-i2rs-yang-l3-topology-04 - need revision -05 and IPR
statements. 

 

Alex: 

 

I apologize that it has taken me so long to do my shepherding checks.
Here's the fixes that need to 

1)      You need to add RFC2119 - to your reference as normative

2)      Add new yang RFC to reference in first line of introduction (see
below)

3)      Change your OSPF reference [Use RFC2328]

4)      You need to add an IANA section  - See my suggested text below

5)      Do you need pre-2008 IPR language?  

6)      Be aware we will get push back on the number of authors. 

Are there any authors that did not actively work on the yang or document? 

 

 

Sue 

 

 

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

 

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

 

#2 Change to Add New Yang reference 

Old/ This document introduces a YANG [RFC7950
<https://tools.ietf.org/html/rfc7950> ] [RFC6991
<https://tools.ietf.org/html/rfc6991> ] data model for

   Layer 3 network topologies, specifically Layer 3 Unicast/ 

New/ This document introduces a YANG [RFC7950
<https://tools.ietf.org/html/rfc7950> ] [RFC7223] [RFC6991
<https://tools.ietf.org/html/rfc6991> ] data model for

   Layer 3 network topologies, specifically Layer 3 Unicast
 
#3 change your OSPF reference to RFC2338 
 
 
115        different Layer 3 Unicast topology types.  For this purpose,
example
116        models are introduced that cover IS-IS [RFC1195] and OSPF
[RFC2178].
 
1312       [RFC2178]  Moy, J., "OSPF Version 2", RFC 2178, July 1997.
 
 
#4 - Add IANA Considerations as follows

  <https://tools.ietf.org/html/rfc8022#section-10> 10.  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-isis-topology
   Registrant Contact: The IESG.
   XML: N/A; the requested URI is an XML namespace.
 
   URI:   namespace "urn:ietf:params:xml:ns:yang:ietf-ospf-topology";
   Registrant Contact: The IESG.
   XML: N/A; the requested URI is an XML namespace.
 
   URI: "urn:ietf:params:xml:ns:yang:ietf-l3-unicast-topology";
   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-l3-unicast-topology
   Namespace:    urn:ietf:params:xml:ns:yang:ietf-isis-topology
   Prefix:       l3t
   Reference:    draft-ietf-i2rs-yang-l3-topology-04 (RFC form) 
 
   Name:         ietf-ospf-topology
   Namespace:    urn:ietf:params:xml:ns:yang:ietf-ipv4-unicast-routing
   Prefix:       ospft
   Reference:    draft-ietf-i2rs-yang-l3-topology-04 (RFC form) 
 

 

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

 

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