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

[Juergen Schoenwaelder <[e-mail]>]

On Fri, Oct 09, 2015 at 10:18:50PM +0000, Alexander Clemm (alex) wrote:
> 
> - 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>

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.
 
> - 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>

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

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: [phone]         Campus Ring 1 | 28759 Bremen | Germany
Fax:   [phone]         <http://www.jacobs-university.de/>