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
- [i2rs] nits review of draft-ietf-i2rs-yang-networ… Juergen Schoenwaelder
- Re: [i2rs] nits review of draft-ietf-i2rs-yang-ne… Susan Hares
- Re: [i2rs] nits review of draft-ietf-i2rs-yang-ne… Alexander Clemm (alex)
- Re: [i2rs] nits review of draft-ietf-i2rs-yang-ne… Juergen Schoenwaelder