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

"Susan Hares" <shares@ndzh.com> Fri, 02 October 2015 03:02 UTC

Return-Path: <shares@ndzh.com>
X-Original-To: i2rs@ietfa.amsl.com
Delivered-To: i2rs@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7EFDB1AC401 for <i2rs@ietfa.amsl.com>; Thu, 1 Oct 2015 20:02:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -98.455
X-Spam-Level:
X-Spam-Status: No, score=-98.455 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845, J_CHICKENPOX_74=0.6, USER_IN_WHITELIST=-100] autolearn=no
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 dZBBy4EVKb0i for <i2rs@ietfa.amsl.com>; Thu, 1 Oct 2015 20:02:04 -0700 (PDT)
Received: from hickoryhill-consulting.com (hhc-web3.hickoryhill-consulting.com [64.9.205.143]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 364541AC3FF for <i2rs@ietf.org>; Thu, 1 Oct 2015 20:02:04 -0700 (PDT)
X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=184.157.84.146;
From: Susan Hares <shares@ndzh.com>
To: 'Juergen Schoenwaelder' <j.schoenwaelder@jacobs-university.de>, i2rs@ietf.org
References: <20151001233038.GC29135@elstar.local>
In-Reply-To: <20151001233038.GC29135@elstar.local>
Date: Thu, 01 Oct 2015 23:01:52 -0400
Message-ID: <008701d0fcbe$b0621c70$11265550$@ndzh.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AQJIOnOOh0a34mp8OFw/IPbY8TChr51o7cLA
Content-Language: en-us
X-Authenticated-User: skh@ndzh.com
Archived-At: <http://mailarchive.ietf.org/arch/msg/i2rs/dpGlFhDfQYNX_ZGW7XFAMxQ0mF8>
Cc: "'Alexander Clemm (alex)'" <alex@cisco.com>, "'Eric Voit (evoit)'" <evoit@cisco.com>
Subject: Re: [i2rs] nits review of draft-ietf-i2rs-yang-network-topo-01.txt
X-BeenThere: i2rs@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "Interface to The Internet Routing System \(IRS\)" <i2rs.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/i2rs>, <mailto:i2rs-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/i2rs/>
List-Post: <mailto:i2rs@ietf.org>
List-Help: <mailto:i2rs-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/i2rs>, <mailto:i2rs-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 02 Oct 2015 03:02:05 -0000

Juergen: 

Thank you for the quick review.  The authors will revise this draft so look
for it's announcement. 

Sue 

-----Original Message-----
From: i2rs [mailto:i2rs-bounces@ietf.org] On Behalf Of Juergen Schoenwaelder
Sent: Thursday, October 01, 2015 7:31 PM
To: i2rs@ietf.org
Subject: [i2rs] nits review of draft-ietf-i2rs-yang-network-topo-01.txt

A few notes from a quick read of this I-D:

- There are multiple places where the text says network.yang but
  really means ietf-network.yang. The same for network-topology.yang
  and ietf-network-topology.yang.

- The 'organization' and 'contact' are TBD or WILL-BE-DEFINED-LATER.
  I think this needs to be filled in now.

- There is probably a need to add some copyright etc. text to the
  module descriptions.

- Instead of putting I-D names into reference clauses, please insert
  instructions for the RFC editor so that the editor knows which
  things need to be replaced with RFC numbers.

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

- I am not sure whether the security considerations are sufficient.  I
  think it would be fair to point out that topology information is
  most likely information that requires proper protection. See also
  section 3.4 of RFC6087 which points to the template:

  http://trac.tools.ietf.org/area/ops/trac/wiki/yang-security-guidelines

- Reference 6021 has been obsoleted by RFC 6991.

- Reference 6241 is cited but not in the references section.

- The IANA considerations section is missing. You need to do IANA
  registrations of the YANG module name and the namespace URN.

- RFC 2119 terms are used but not 'imported'.

- There are references without citations: [yang-json], [restconf].

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

- Make sure idnits is happy.

I have asked the YANG doctors to comment on section 3.5.

/js

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

_______________________________________________
i2rs mailing list
i2rs@ietf.org
https://www.ietf.org/mailman/listinfo/i2rs