Subject: [i2rs] nits review of draft-ietf-i2rs-yang-network-topo-01.txt

From: Juergen Schoenwaelder <[email-masked]>
Date: Fri, 2 Oct 2015 01:30:38 +0200

A few notes from a quick read of this I-D:

- There are multiple places where the text says network.yang but
  really means ietf-network.yang. The same for network-topology.yang
  and ietf-network-topology.yang.

- The 'organization' and 'contact' are TBD or WILL-BE-DEFINED-LATER.
  I think this needs to be filled in now.

- There is probably a need to add some copyright etc. text to the
  module descriptions.

- Instead of putting I-D names into reference clauses, please insert
  instructions for the RFC editor so that the editor knows which
  things need to be replaced with RFC numbers.

- The description of the typedef link-id says 'The identifier may be
  opaque.' What does that mean? It is an inet:uri after all. If two
  systems populate a link-id, how are they going to come up with the
  same identifier? Is the SHOULD realistic to achieve? The same
  comment applies to the typedef tp-id.

- I am not sure whether the security considerations are sufficient.  I
  think it would be fair to point out that topology information is
  most likely information that requires proper protection. See also
  section 3.4 of RFC6087 which points to the template:

  http://trac.tools.ietf.org/area/ops/trac/wiki/yang-security-guidelines

- Reference 6021 has been obsoleted by RFC 6991.

- Reference 6241 is cited but not in the references section.

- The IANA considerations section is missing. You need to do IANA
  registrations of the YANG module name and the namespace URN.

- RFC 2119 terms are used but not 'imported'.

- There are references without citations: [yang-json], [restconf].

- I do not really understand why RFC1195, RFC2328, and RFC3209 are
  normative references. Even RFC6241 and RFC7223 may not be normative.
  Well, RFC6241 is not cited at all so it should be removed anyway
  (ah, bad for my h-index).

- Make sure idnits is happy.

I have asked the YANG doctors to comment on section 3.5.

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103         <http://www.jacobs-university.de/>

---

From: "Susan Hares" <[email-masked]>
Date: Thu, 1 Oct 2015 23:01:52 -0400

Juergen: 

Thank you for the quick review.  The authors will revise this draft so look
for it's announcement. 

Sue 

-----Original Message-----
From: i2rs [mailto:[email-masked]] On Behalf Of Juergen Schoenwaelder
Sent: Thursday, October 01, 2015 7:31 PM
To: [email-masked]
Subject: [i2rs] nits review of draft-ietf-i2rs-yang-network-topo-01.txt

/js

_______________________________________________
i2rs mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/i2rs

---

From: "Alexander Clemm (alex)" <[email-masked]>
Date: Fri, 9 Oct 2015 22:18:50 +0000

Hi Juergen,

thank you for your notes.  

Quick comments inline

--- Alex

-----Original Message-----
From: i2rs [mailto:[email-masked]] On Behalf Of Juergen Schoenwaelder
Sent: Thursday, October 01, 2015 4:31 PM
To: [email-masked]
Subject: [i2rs] nits review of draft-ietf-i2rs-yang-network-topo-01.txt

<ALEX> Will clean this up.
</ALEX>

<ALEX> OK
</ALEX>

<ALEX> OK
</ALEX>

<ALEX> OK
</ALEX>

<ALEX> Basically, this says that there may be different convenions 
used to pick identifiers, and we are not prescribing a specific 
convention.  You may have different systems which choose to populate 
link-ids differently, but they are different systems and 
refer to different links.  
</ALEX>

<ALEX> OK, we can expand.
</ALEX>

<ALEX> OK, will fix
</ALEX>

<ALEX> OK, will fix
</ALEX>

<ALEX> OK, will fix
</ALEX>

<ALEX> OK
</ALEX>

<ALEX> I am not sure why they would not be normative - they are standards track?  What would be the criteria to list them otherwise?  
(And, we can try to add a citation for RFC 6241 to make your h-index happy)
</ALEX>

- Make sure idnits is happy.
<ALEX>OK, we'll try to make that happy too.
</ALEX>

/js

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 13 Oct 2015 10:25:07 +0200

> refer to different links.  

The description says:

   The identifier SHOULD be chosen such that the same link in a
   real network topology will always be identified through the
   same identifier, even if the model is instantiated in
   separate datastores.

Your answer does not match this text. So my comment remains open.
 
> (And, we can try to add a citation for RFC 6241 to make your h-index happy)

A reference is normative if the reference is required to implement the
specification correctly. This is orthogonal to a document's status.
Usually, normative references of standards-track documents are
standards-track documents but this is not strictly required (such
cases are called a downrefs and trigger special procedures). And it is
perfectly fine to standards-track non-normative references. In other
words, you should ask for each reference whether it is essential to
implement this specification correctly or not. In this case, I think
RFC 6020 and RFC 6991 are (not that RFC 6991 has obsoleted RFC 6020).
You probably also need to cite RFC 2119 if you use MUST/SHOULD
language and add the boilerplate paragraph somewhere. All references
that are not cited should be removed.

/js