Re: [Last-Call] Yangdoctors last call review of draft-ietf-core-sid-15

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Xufeng,

Thank you very much for the detailed review! 

Authors: please address Xufeng's comments together with the other Last Call comments received.

Thanks,
Francesca

On 26/03/2021, 00:40, "Xufeng Liu via Datatracker" <noreply@xxxxxxxx> wrote:

    Reviewer: Xufeng Liu
    Review result: Ready with Nits

    This is a review of the YANG module in draft-ietf-core-sid-15.

    Minor Issues, Nits, and Questions:

    1) This module uses the yang-data extension in RFC8040, which was the best
    choice a few years ago when this draft started. However, RFC8791 has been
    published so that the YANG structure extension is available now. Has the YANG
    structure extension been considered to replace the yang-data extension?

    2) The container sid-file is missing in the tree diagram in Section 4. RFC8340
    specifies the tree format to represent such a yang-data definition. If the YANG
    structure extension in RFC8791 is used, RFC8791 describes how the tree diagram
    looks like for such a YANG structure. Also, the top container would not be
    needed, because a YANG structure is encoded as a 'container'.

    3) In the container sid-file, the leaf module-name is optional. What is the
    assumption when it is not specified? It would be beneficial to clarify in the
    description statement.

    4) In the container sid-file, the leaf sid-file-version is optional. The
    description says that this number starts at zero. Let’s say that there are two
    .sid files, one of which does not have the version number and the other one has
    version number 0. Are they the same? If so, would it be better to have a
    default statement with a default value of 0?

    5) For “list dependency-revision”, the key is module-name. The  “mandatory
    true” statement is not necessary for this leaf because it is a key.

    6) Under the “list dependency-revision”, the leaf revision-identifier is
    specified as “mandatory”. What would this leaf be specified when a dependent
    module does not have a revision?

    7) “list assigment-ranges” should be “list assignment-ranges”. A letter ‘n’ is
    missing in the current YANG module because of a typo.

    8) For “list assignment-ranges”, the key is entry-point. The  “mandatory true”
    statement is not necessary for this leaf because it is a key.

    9) As a convention, the node names of “list assignment-ranges” and “list items”
    should be in the singular form, the same way as “list dependency-revision”, so
    that they would be “list assignment-range” and “list item”.

    10) Since a YANG SID value is globally unique, would it be beneficial to have a
    statement in the YANG file to describe the requirement formally? This can be
    easily done by adding the following statement under “list items”:
            unique "sid";

    11) The format of the YANG file needs to be adjusted. Some of the lines in the
    .yang file are longer than 69 characters. For example, at line 108 is:
           o  Any subsequent schema node name is in the namespace-qualified form
    To examine, the command “pyang --ietf --max-line-length 69 FILE” can be used.
    Before publishing, an RFC editor would normalize the format by using the
    command “pyang -f yang --keep-comments --yang-line-length 69 FILE”. It would be
    helpful to run this command now since it may change the lines to be longer than
    the limit of 69 characters.

    12) In the example in Appendix A, the four "module-revision" statements contain
    “.yang” after the date, not following the pattern rule of the
    revision-identifier. It seems that the sid generation tool did not take out the
    extension “.yang”.

    13) In Appendix A, the 5th item is:
     o  iana-crypt-hash@xxxxxxxxxxxxxxx (defined in [RFC7317])
    but in  RFC7317, the revision of  iana-crypt-hash is 2014-08-06

    14) The following is a thought that may have been discussed before and decided
    by the WG, but I’d mention it here anyway just in case: Since the scope of a
    .sid file is for a single YANG file (module), many of the data nodes start with
    the namespace of this particular module. The “schema-node-path” currently
    requires an identifier string to always start with a namespace. Because of this
    requirement, there are many repeated namespace strings in the identifiers of
    the items. If we assume that the default starting namespace is the module
    associated with the .sid file, we may shorten the .sid file?

    - Xufeng




-- 
last-call mailing list
last-call@xxxxxxxx
https://www.ietf.org/mailman/listinfo/last-call




[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Mhonarc]     [Fedora Users]

  Powered by Linux