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

["Kamran Raza (skraza)" <[e-mail]>]

Hi Martin,

Please see inline [skraza]:


On 2019-10-15, 8:26 AM, "Martin Bjorklund" <[e-mail]> wrote:

    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.

[skraza]: This should be decided on RTG area level so that all protocols follow the same approach. 
   We will defer this to RTG AD for guidance. Please also refer our response to Jan's review.
    
    
    
    
    /martin