Re: [netmod] WG Last Call draft-ietf-netmod-routing-cfg-12 (until 2013-12-20)

Martin Bjorklund <mbj@tail-f.com> Sun, 15 December 2013 21:03 UTC

Return-Path: <mbj@tail-f.com>
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7B6F41AC4AB for <netmod@ietfa.amsl.com>; Sun, 15 Dec 2013 13:03:43 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.539
X-Spam-Level:
X-Spam-Status: No, score=-0.539 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, RP_MATCHES_RCVD=-0.538] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gySfenbqvjtx for <netmod@ietfa.amsl.com>; Sun, 15 Dec 2013 13:03:41 -0800 (PST)
Received: from mail.tail-f.com (mail.tail-f.com [109.74.15.94]) by ietfa.amsl.com (Postfix) with ESMTP id 7523C1A1F62 for <netmod@ietf.org>; Sun, 15 Dec 2013 13:03:41 -0800 (PST)
Received: from localhost (unknown [193.12.32.88]) by mail.tail-f.com (Postfix) with ESMTPSA id 3C98A37C049; Sun, 15 Dec 2013 22:03:39 +0100 (CET)
Date: Sun, 15 Dec 2013 22:03:38 +0100
Message-Id: <20131215.220338.304654767.mbj@tail-f.com>
To: j.schoenwaelder@jacobs-university.de
From: Martin Bjorklund <mbj@tail-f.com>
In-Reply-To: <20131203151610.GB71692@elstar.local>
References: <20131203151610.GB71692@elstar.local>
X-Mailer: Mew version 6.5rc2 on Emacs 23.4 / Mule 6.0 (HANACHIRUSATO)
Mime-Version: 1.0
Content-Type: Text/Plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Cc: netmod@ietf.org
Subject: Re: [netmod] WG Last Call draft-ietf-netmod-routing-cfg-12 (until 2013-12-20)
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list <netmod.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/netmod>, <mailto:netmod-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/netmod/>
List-Post: <mailto:netmod@ietf.org>
List-Help: <mailto:netmod-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netmod>, <mailto:netmod-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 15 Dec 2013 21:03:43 -0000

Hi,

I have reviewed this document, and here are my comments:


I plan to implement this data model for a non-router (host).  In the
introduction and objectives section it is mentioned that this data
model is suitable for such a device.  I think the document should
include a section that discusses what such an implementation should
do.  For example, implement the "static" and "direct"
pseudo-protocols, allow exactly one user-controlled routing instance
(?), do not implement "multiple-ribs".  What does router-id mean for a
host?  Does a host have to implement the configuration tree for ribs?

-----------

In v{4,6}ur, the term "gateway" is used.  Should this be "next-hop"
instead?

-----------

In the document, term "netxhop" is used.  Should this be "next hop"
(in text) and "next-hop" (in data models).

-----------

5.1

   A routing instance together with its operational status is
   represented as an entry of the list "/routing-state/
   routing-instance", and identified by a unique numeric identifier.
   Configuration of that router instance appears as entry of the list
   "/routing/routing-instance" whose key is a routing instance name
   selected by the client.

But there is no numeric identifier anymore.

And: s/operational status/operational state/

-----------

Since the /routing-state/routing-instance list has a name, and the
name is the key, why does it also have an "id", and why is the "id"
used in references to the routing-instance?  When I invoke the
"active-route" operation, I have to first figure out the "id" of the
routing-instance, and then use this id.  It seems simpler to always
use the name.   Also, the "id" is optional, which makes it unsuitable
to be used as an identifier.

The same comment applies to /routing-state/ribs/rib.

Also, for the lists that do need an "id" (route, nexthop), the id leaf
needs to be mandatory.

-----------

In 5.4.1:

   Every routing instance MUST implement exactly one instance of the
   "direct" pseudo-protocol type.  The name of this instance MUST also
   be "direct".

Why does this name have to be "direct"?  I think this should be
removed or explained, b/c now if seems arbitrary.

------------

Editorial nit:  your yin2yang script adds (or doesn't strip) empty
lines in some cases:

       description
         "Return the current number of routes in a RIB.

          If the RIB with 'id' equal to 'rib-id' doesn't exist, then
          this operation SHALL fail with error-tag 'data-missing' and
          error-app-tag 'rib-not-found'.
         ";

-----------

Editorial: s/RIBS/RIBs/



/martin



Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> wrote:
> Hi,
> 
> I hereby like to start a WG last call for the document "A YANG Data
> Model for Routing Management":
> 
>   http://tools.ietf.org/html/draft-ietf-netmod-routing-cfg-12
> 
> Please indicate your support by Friday December 20th. We are not only
> interested in receiving defect reports, we are equally interested in
> statements of the form:
> 
>   "I have reviewed I-D XYZ and I found no issues"
>   "I have implemented the data model in I-D XYZ"
>   "I am implementing the data model in I-D XYZ"
>   "I am considering to implement the data model in I-D XYZ"
> 
> This is the 1st WG last call on this document.
> 
> /js