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

Martin Bjorklund <mbj@tail-f.com> Tue, 30 April 2013 08:38 UTC

Return-Path: <mbj@tail-f.com>
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6AE3A21F9ABF; Tue, 30 Apr 2013 01:38:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.189
X-Spam-Level:
X-Spam-Status: No, score=-2.189 tagged_above=-999 required=5 tests=[AWL=-0.143, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6+tY+MsrRHra; Tue, 30 Apr 2013 01:38:41 -0700 (PDT)
Received: from mail.tail-f.com (de-2007.d.ipeer.se [213.180.74.102]) by ietfa.amsl.com (Postfix) with ESMTP id 2E67C21F9AE2; Tue, 30 Apr 2013 01:38:40 -0700 (PDT)
Received: from localhost (138.162.241.83.in-addr.dgcsystems.net [83.241.162.138]) by mail.tail-f.com (Postfix) with ESMTPSA id 47F1C12008B7; Tue, 30 Apr 2013 10:38:39 +0200 (CEST)
Date: Tue, 30 Apr 2013 10:38:39 +0200 (CEST)
Message-Id: <20130430.103839.1231060720297181226.mbj@tail-f.com>
To: tbray@textuality.com
From: Martin Bjorklund <mbj@tail-f.com>
In-Reply-To: <CAHBU6iu_BzHCJxJnXCEU_fRuwkp=UghLwG7hsgaMKMFSq=yzag@mail.gmail.com>
References: <CAHBU6iu_BzHCJxJnXCEU_fRuwkp=UghLwG7hsgaMKMFSq=yzag@mail.gmail.com>
X-Mailer: Mew version 6.5rc2 on Emacs 23.4 / Mule 6.0 (HANACHIRUSATO)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=iso-2022-jp
Content-Transfer-Encoding: 7bit
X-Mailman-Approved-At: Tue, 30 Apr 2013 09:34:09 -0700
Cc: draft-ietf-netmod-interfaces-cfg.all@tools.ietf.org, iesg@ietf.org, apps-discuss@ietf.org
Subject: Re: [apps-discuss] Apps Area review of draft-ietf-netmod-interfaces-cfg-10
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss>
List-Post: <mailto:apps-discuss@ietf.org>
List-Help: <mailto:apps-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 30 Apr 2013 08:38:46 -0000

Hi,

Thank you for your review.  Comments inline.

Tim Bray <tbray@textuality.com> wrote:
> 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...

Ok, I will fix this.

> 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”?

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

> I have to say that this looks like a hash table indexed by name rather than
> 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