Subject: [i2rs] Alissa Cooper's No Objection on draft-ietf-i2rs-yang-l3-topology-08: (with COMMENT)

From: "Alissa Cooper" <[email-masked]>
Date: Wed, 18 Jan 2017 08:01:37 -0800

Alissa Cooper has entered the following ballot position for
draft-ietf-i2rs-yang-l3-topology-08: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-i2rs-yang-l3-topology/

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

= Section 2 =

HTTP and ReST are defined, but they aren't used anywhere else in the
document in a way that requires definition.

= Section 5 =

"case interface-name {
             leaf interface-name {
               type string;
               description
                 "A name of the interface.  The name can (but does not
                  have to) correspond to an interface reference of a
                  containing node's interface, i.e. the path name of a
                  corresponding interface data node on the containing
                  node reminiscent of data type if-ref defined in
                  RFC 7223. It should be noted that data type if-ref of
                  RFC 7223 cannot be used directly, as this data type
                  is used to reference an interface in a datastore of
                  a single node in the network, not to uniquely
                  reference interfaces across a network.";
             }
           }"

In RFC 7223 the data type appears to be called interface-ref, not if-ref.
Would an example of this in this document be, say, a MAC address? 

= Section 6.1.1 and 6.2.1 =

While notational explanations are given for "?," "*," etc., none is given
for "!".

= Section 9 =

This section is missing a discussion of the potential sensitivity of the
data this module exposes even in a read-only use case. Filling in the
template at https://trac.ietf.org/trac/ops/wiki/yang-security-guidelines
and adding the text to this section should get that covered.

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 18 Jan 2017 20:08:43 +0100

> Would an example of this in this document be, say, a MAC address? 

Now that I read this, I must say that I do not understand the
description at all. What does 'i.e. the path name of a corresponding
interface data node on the containing node reminiscent of data type
if-ref defined in RFC 7223.' tell me? If the intention here is that it
is unique across a network I think this should be stated more clearly,
that is, not as a sub-thought in a sentence trying to explain why
if-ref can't be used. And then, what is a 'network'?

And looking at the whole choice, the other options are not unique
either. For unnumbered-id, the description says "will correspond to
the ifIndex value of the interface" which very likely will clash for
different nodes. Also IP adresses may not always be unique 'across a
network'. So why do we have this "unique across a network" requirement
for the interface-name case? That is, we can't we use

/js

PS: Why is interface-name marked 'ro' in the tree diagram? It looks
    like a config true node.

-- 
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, 19 Jan 2017 14:22:07 -0500

Alissa and Juergen: 
Thank you for catching these errors. 

Sue Hares
(Shepherd) 

-----Original Message-----
From: Juergen Schoenwaelder [mailto:[email-masked]] 
Sent: Wednesday, January 18, 2017 2:09 PM
To: Alissa Cooper
Cc: The IESG; [email-masked]; [email-masked];
[email-masked]; [email-masked]
Subject: Re: [i2rs] Alissa Cooper's No Objection on
draft-ietf-i2rs-yang-l3-topology-08: (with COMMENT)

> Would an example of this in this document be, say, a MAC address? 

Now that I read this, I must say that I do not understand the description at
all. What does 'i.e. the path name of a corresponding interface data node on
the containing node reminiscent of data type if-ref defined in RFC 7223.'
tell me? If the intention here is that it is unique across a network I think
this should be stated more clearly, that is, not as a sub-thought in a
sentence trying to explain why if-ref can't be used. And then, what is a
'network'?

And looking at the whole choice, the other options are not unique either.
For unnumbered-id, the description says "will correspond to the ifIndex
value of the interface" which very likely will clash for different nodes.
Also IP adresses may not always be unique 'across a network'. So why do we
have this "unique across a network" requirement for the interface-name case?
That is, we can't we use

/js