Re: [yang-doctors] Yangdoctors last call review of draft-ietf-ospf-yang-09

"Acee Lindem (acee)" <acee@cisco.com> Tue, 13 March 2018 21:15 UTC

Return-Path: <acee@cisco.com>
X-Original-To: yang-doctors@ietfa.amsl.com
Delivered-To: yang-doctors@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6395B126CD6; Tue, 13 Mar 2018 14:15:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.53
X-Spam-Level:
X-Spam-Status: No, score=-14.53 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com
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 veuCy-_9qkYc; Tue, 13 Mar 2018 14:15:20 -0700 (PDT)
Received: from alln-iport-8.cisco.com (alln-iport-8.cisco.com [173.37.142.95]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D2409126CF6; Tue, 13 Mar 2018 14:15:17 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5744; q=dns/txt; s=iport; t=1520975717; x=1522185317; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=oQhDcle5ya6UVl5i79a77eFUvNouIE2J+AFHhD+Ng6g=; b=HiK8+GX8HjPemnQY/2gXJZs6ATrYqpfOTVztwTvyo8UtIxhJPRwB4aar YGRgOlHA7j/atGlvyu4JAmvpCvcKGsJYAk+6gRiva/k7xcGQz8HzmfZcz tyQ4RMM+LTXPusLvhsDGhK3l8fZxhhqZQDNICRH/dj18YuixN6DG+r6MQ 0=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DoAACFPqha/5tdJa1dGQEBAQEBAQEBA?= =?us-ascii?q?QEBAQcBAQEBAYMjLWVwKAqDRoodjXSBWymBFpQxghUKGAuFAgIagwYhNBgBAgE?= =?us-ascii?q?BAQEBAQJrJ4UkAQEEAQEhEToLEAIBCA4EBgICJgICAiULFQIOAgQBDQWFGA+sB?= =?us-ascii?q?oImiGGCBQWBDYQogi6DPCkMgnmDLgEBAwGEdTCCEiAEmlYJAoZCiiCBY4Q1iEm?= =?us-ascii?q?FYYQZhykCERMBgSsBHjhAgRJwFRkhKgGCGINRAQhtd44pgRgBAQE?=
X-IronPort-AV: E=Sophos;i="5.47,466,1515456000"; d="scan'208";a="83044209"
Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by alln-iport-8.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 13 Mar 2018 21:15:17 +0000
Received: from XCH-RTP-012.cisco.com (xch-rtp-012.cisco.com [64.101.220.152]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id w2DLFG4b002105 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 13 Mar 2018 21:15:17 GMT
Received: from xch-rtp-015.cisco.com (64.101.220.155) by XCH-RTP-012.cisco.com (64.101.220.152) with Microsoft SMTP Server (TLS) id 15.0.1320.4; Tue, 13 Mar 2018 17:15:15 -0400
Received: from xch-rtp-015.cisco.com ([64.101.220.155]) by XCH-RTP-015.cisco.com ([64.101.220.155]) with mapi id 15.00.1320.000; Tue, 13 Mar 2018 17:15:15 -0400
From: "Acee Lindem (acee)" <acee@cisco.com>
To: Martin Bjorklund <mbj@tail-f.com>, Ladislav Lhotka <lhotka@nic.cz>
CC: YANG Doctors <yang-doctors@ietf.org>, "draft-ietf-ospf-yang.all@ietf.org" <draft-ietf-ospf-yang.all@ietf.org>
Thread-Topic: [yang-doctors] Yangdoctors last call review of draft-ietf-ospf-yang-09
Thread-Index: AQHTuxBhx1yNvn+GQU2ozx/7VFKP1w==
Date: Tue, 13 Mar 2018 21:15:15 +0000
Message-ID: <1F5FF6F1-1309-4A89-9A79-4607C2423CEE@cisco.com>
References: <151255960762.30655.17225294251460480729@ietfa.amsl.com> <20171206.124611.1073986528289329597.mbj@tail-f.com>
In-Reply-To: <20171206.124611.1073986528289329597.mbj@tail-f.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.116.152.196]
Content-Type: text/plain; charset="utf-8"
Content-ID: <9BFFE9B14FDD934AABF1F79C21976F24@emea.cisco.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/yang-doctors/BkFEmCBinCFgV8imvz_cmgH7PwE>
Subject: Re: [yang-doctors] Yangdoctors last call review of draft-ietf-ospf-yang-09
X-BeenThere: yang-doctors@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Email list of the yang-doctors directorate <yang-doctors.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/yang-doctors>, <mailto:yang-doctors-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/yang-doctors/>
List-Post: <mailto:yang-doctors@ietf.org>
List-Help: <mailto:yang-doctors-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/yang-doctors>, <mailto:yang-doctors-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 13 Mar 2018 21:15:21 -0000

Hi Martin, 
We believe that https://datatracker.ietf.org/doc/draft-ietf-ospf-yang/ satisfies your comments. Please take a look.
Thanks,
Acee

On 12/6/17, 6:46 AM, "Martin Bjorklund" <mbj@tail-f.com> wrote:

    Ladislav Lhotka <lhotka@nic.cz> wrote:
    > Reviewer: Ladislav Lhotka
    > Review result: Ready with Issues
    > 
    > The data model defined in this document is a massive piece of work: it
    > consists of 11 YANG modules and defines around 1200 schema nodes. The
    
    11 YANG modules?  Isn't there just one?
    
    
    I would like to add two quick comments to Lada's review.
    
    o  Remove all "revision" statements except the one that says "initial
       revision".   The idea is to have one revision statement per
       published version (i.e., RFC).
    
    
    o  Many of the nodes have quite rudimentary descriptions, and the
       "reference" statement is rarely used.  For example:
    
             leaf lsa-id {
               type yang:dotted-quad;
               mandatory true;
               description "LSA ID.";
             }
    
       It seems as the description is put there just to keep the tools
       quiet.  I know that it is painful to write good descriptions, but
       it does help the consumer of the data model.
    
    
    /martin
    
    
    > "ietf-ospf@2017-10-30" module is compatible with the NMDA architecture.
    > 
    > **** Comments
    > 
    > 1. Unless there is a really compelling reason not to do so, the
    >    "ietf-ospf" should declare YANG version 1.1. For one,
    >    "ietf-routing" that is being augmented by "ietf-ospf" already
    >    declares this version. Some of my suggestions below also assume
    >    version 1.1.
    > 
    > 2. The "ietf-ospf" can work only with the new NMDA-compatible
    >    revisions of some modules, such as "ietf-interfaces" and
    >    "ietf-routing". I understand it is not desirable to import such
    >    modules by revision, but at least it should be mentioned in a
    >    description attached to every such import.
    > 
    > 3. Maybe the draft could mention that implementations should supply a
    >    default routing domain as a system-controlled resource.
    > 
    > 4. In "when" expressions, the module uses literal strings for
    >    identities. This is known to be problematic, the XPath functions
    >    derived-from() or derived-from-or-self() should be used instead.
    > 
    > 5. Some enumerations, such as "packet-type" and "if-state-type"
    >    define enum identifiers with uppercase letters and/or underscores,
    >    for example "Database-Description" or "LONG_WAIT". RFC6087bis
    >    recommends that only lowercase letters, numbers and dashes. I think
    >    this convention should be observed despite the fact that the
    >    current names are traditionally used in OSPF specs. The
    >    "ietf-routing" module also defines "router-id" even though the
    >    documents use "Router ID".
    > 
    > 6. The types of LSA headers are modelled as integers. While OSPF gurus
    >    probably know these numbers by heart, it is not very
    >    reader-frienly. So at least some references to documents defining
    >    these numbers should be provided, but my suggestion is to consider
    >    implementing them with identities. It seems it might also be useful
    >    to define some "abstract" identities for these types. For example,
    >    if "opaque-lsa" is defined, then the definition of container
    >    "opaque" could simply use
    > 
    >      when "derived-from(../../header/type, 'ospf:opaque-lsa')";
    > 
    >    instead of
    > 
    >       when "../../header/type = 9 or "
    >               + "../../header/type = 10 or "
    >               + "../../header/type = 11";
    > 
    > 7. The title of sec. 2.9 should be "OSPF Notifications" rather than
    >    "OSPF notification".
    > 
    > 
    > _______________________________________________
    > yang-doctors mailing list
    > yang-doctors@ietf.org
    > https://www.ietf.org/mailman/listinfo/yang-doctors
    >