Hi Juergen, thank you for your notes.
Quick comments inline --- Alex -----Original Message----- From: i2rs [mailto:[email protected]] On Behalf Of Juergen Schoenwaelder Sent: Thursday, October 01, 2015 4:31 PM To: [email protected] Subject: [i2rs] nits review of draft-ietf-i2rs-yang-network-topo-01.txt 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. <ALEX> Will clean this up. </ALEX> - The 'organization' and 'contact' are TBD or WILL-BE-DEFINED-LATER. I think this needs to be filled in now. <ALEX> OK </ALEX> - There is probably a need to add some copyright etc. text to the module descriptions. <ALEX> OK </ALEX> - 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. <ALEX> OK </ALEX> - 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. <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> - 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 <ALEX> OK, we can expand. </ALEX> - Reference 6021 has been obsoleted by RFC 6991. <ALEX> OK, will fix </ALEX> - Reference 6241 is cited but not in the references section. <ALEX> OK, will fix </ALEX> - The IANA considerations section is missing. You need to do IANA registrations of the YANG module name and the namespace URN. <ALEX> OK, will fix </ALEX> - RFC 2119 terms are used but not 'imported'. - There are references without citations: [yang-json], [restconf]. <ALEX> OK </ALEX> - 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). <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> 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/> _______________________________________________ i2rs mailing list [email protected] https://www.ietf.org/mailman/listinfo/i2rs _______________________________________________ i2rs mailing list [email protected] https://www.ietf.org/mailman/listinfo/i2rs
