Hi,
Some comments inline.
Jan Lindblad via Datatracker <noreply@xxxxxxxx> 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
