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

[Martin Bjorklund <[e-mail]>]

Hi,

Some comments inline.

Jan Lindblad via Datatracker <[e-mail]> 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