Subject: [apps-discuss] Apps Area review of draft-ietf-netmod-interfaces-cfg-10

From: Tim Bray <[email-masked]>
Date: Mon, 29 Apr 2013 21:44:09 -0700

I have been selected as the Applications Area Directorate reviewer for this
draft (for background on appsdir, please see 
http://trac.tools.ietf.org/area/app/trac/wiki/ApplicationsAreaDirectorate ).

Please resolve these comments along with any other Last Call comments you
may receive. Please wait for direction from your document shepherd or AD
before posting a new version of the draft.

Document: draft-ietf-netmod-interfaces-cfg-10
Title: A YANG Data Model for Interface Management
Reviewer: Tim Bray
Review Date: April 29

Summary: I see no objections to publication of this document as a
standards-track RFC

Note: I’m not an expert in Netconf/YANG stuff, so really my only comments
are on style, coherence, and XML-sanity.  However, the presentation was
clear enough to be be comprehensible to the non-expert.

Major Issues: Don’t see any

Minor Issues: Not obvious why all the examples are shuffled off into
Appendices, they’re pretty essential to understanding the spec.

Nits:

3. “The data model in the module "ietf-interfaces" has the following
structure...” - This is the first time the label “ietf-interfaces” has
appeared. Is it a well-known name from another spec or are we defining it
here?  If the former, please reference. If the latter, maybe say something
like “We define a module named "ietf-interfaces" whose data model has the
following structure...

3.1 “The data model for interfaces presented in this document uses a flat
list of interfaces.” - does this mean that the model in section 3. should
have “interface*” rather than just “interface” as a child of “interfaces”?
I have to say that this looks like a hash table indexed by name rather than
a “flat list” in the conventional software sense.

---

From: Martin Bjorklund <[email-masked]>
Date: Tue, 30 Apr 2013 10:38:39 +0200 (CEST)

Hi,

Thank you for your review.  Comments inline.

> like “We define a module named "ietf-interfaces" whose data model has the

Ok, I will fix this.

> have “interface*” rather than just “interface” as a child of “interfaces”?

In this tree diagram, the notion "interface [name]" means that it is a
YANG list, with "name" as key.

> a “flat list” in the conventional software sense.

It refers to the YANG term "list".  When we say "flat list" it means
that it is YANG list where each interface has its own entry in the
"flat list".  Another design approach could have been to represent
subinterfaces in a nested list.

/martin