Re: [yang-doctors] Yangdoctors last call review of draft-ietf-mpls-ldp-yang-06

Martin Bjorklund <mbj@tail-f.com> Tue, 15 October 2019 12:26 UTC

Return-Path: <mbj@tail-f.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 3ED2A12010D; Tue, 15 Oct 2019 05:26:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 2RDBYG3nm6OL; Tue, 15 Oct 2019 05:26:05 -0700 (PDT)
Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 129CD12008A; Tue, 15 Oct 2019 05:26:02 -0700 (PDT)
Received: from localhost (unknown [173.38.220.41]) by mail.tail-f.com (Postfix) with ESMTPSA id 659EC1AE02BD; Tue, 15 Oct 2019 14:26:00 +0200 (CEST)
Date: Tue, 15 Oct 2019 14:25:32 +0200 (CEST)
Message-Id: <20191015.142532.855473702701065549.mbj@tail-f.com>
To: janl@tail-f.com
Cc: yang-doctors@ietf.org, mpls@ietf.org, draft-ietf-mpls-ldp-yang.all@ietf.org, ietf@ietf.org
From: Martin Bjorklund <mbj@tail-f.com>
In-Reply-To: <157114122559.18000.6531210525259761076@ietfa.amsl.com>
References: <157114122559.18000.6531210525259761076@ietfa.amsl.com>
X-Mailer: Mew version 6.8 on Emacs 25.2
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/yang-doctors/lJ6jWDxwX9bk5uf-4yeXARn5rF8>
Subject: Re: [yang-doctors] Yangdoctors last call review of draft-ietf-mpls-ldp-yang-06
X-BeenThere: yang-doctors@ietf.org
X-Mailman-Version: 2.1.29
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, 15 Oct 2019 12:26:08 -0000

Hi,

Some comments inline.

Jan Lindblad via Datatracker <noreply@ietf.org>; wrote:

> #4) Weakly defined types for neighbor-list-ref, prefix-list-ref, peer-list-ref
> 
> These types are not leafrefs, but strings without any YANG substatements to
> define the format. The only thing the description does is to claim that the
> entities they refer to are outside the scope of this document. For an
> operator/programmer encountering this type, that isn't very helpful, and is not
> going to be interoperable.
> 
>   typedef neighbor-list-ref {
>     type string;
>     description
>       "A type for a reference to a neighbor address list.
>        The string value is the name identifier for uniquely
>        identifying the referenced address list, which contains a list
>        of addresses that a routing policy can applied. The definition
>        of such an address list is outside the scope of this
>        document.";
>   }
> 
> I'm not sure if this is fixable by sharpening the YANG module, but maybe more
> could be done to guide a confused reader. What would the user do to find out
> the format of this type and valid values? Add to the description.

If the target of such a reference is outside the scope of this
document, it is reasonable to also leave this leaf as outside the
scope of this document.  When a new module defines such a list, it can
easily augment this module with a proper leafref.   I.e., I suggest
that you can remove this leaf and perhaps explain in text how a future
module can add the reference.

> #6) MD5 key
> 
> There is a leaf md5-key of type string. Is this leaf sensitive from a security
> point of view? A plaintext string would not be ideal if that is the case.
> Choose a crypto type instead.

Or perhaps mark the node with nacm:default-deny-all.




/martin