Re: [netmod] Éric Vyncke's No Objection on draft-ietf-netmod-yang-instance-file-format-19: (with COMMENT)

[Balázs Lengyel <[e-mail]>]

Hello Eric,
See some more answers as BALAZS2.
Regards Balazs

-----Original Message-----
From: Eric Vyncke (evyncke) <evyncke=[e-mail]> 
Sent: 2021. október 5., kedd 23:19
To: Balázs Lengyel <[e-mail]>; The IESG <[e-mail]>; Benoit Claise <[e-mail]>
Cc: [e-mail]; Kent Watsen <[e-mail]>; [e-mail]; [e-mail]
Subject: Re: Éric Vyncke's No Objection on draft-ietf-netmod-yang-instance-file-format-19: (with COMMENT)

Hello Balázs,

Thank you for your quick reply and your actions. My comments are non-blocking anyway ;-) see my replies prefixed with EV>

Regards

-éric

On 05/10/2021, 18:10, "iesg on behalf of Balázs Lengyel" <[e-mail] on behalf of balazs.lengyel=[e-mail]> wrote:

    Hello Eric,
    Thank you for the thorough review. I used many of your comments to improve the draft. See my detailed answers below as BALAZS:
    Regards Balazs

    -----Original Message-----
    From: Éric Vyncke via Datatracker <[e-mail]> 
    Sent: 2021. október 5., kedd 13:27
    To: The IESG <[e-mail]>
    Cc: [e-mail]; [e-mail]; [e-mail]; Kent Watsen <[e-mail]>; [e-mail]
    Subject: Éric Vyncke's No Objection on draft-ietf-netmod-yang-instance-file-format-19: (with COMMENT)

    Éric Vyncke has entered the following ballot position for
    draft-ietf-netmod-yang-instance-file-format-19: No Objection

    When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.)


    Please refer to https://www.ietf.org/blog/handling-iesg-ballot-positions/
    for more information about how to handle DISCUSS and COMMENT positions.


    The document, along with other ballot positions, can be found here:
    https://datatracker.ietf.org/doc/draft-ietf-netmod-yang-instance-file-format/



    ----------------------------------------------------------------------
    COMMENT:
    ----------------------------------------------------------------------

    Thank you for the work put into this document.

    Please find below some non-blocking COMMENT points (but replies would be appreciated even if only for my own education), and some nits.

    I hope that this helps to improve the document,

    Regards,

    -éric

    == COMMENTS ==

    Generic comment about the use of the word "file" (which means an object in a file system for me) rather than something more generic (no suggestion to offer
    though) ?
    BALAZS: In most cases we do actually mean an object in a file system. 
    In some cases not: In UC6 Allowing YANG instance data to be carried within  other IPC message formats. 
    This is the exact reason while we differentiate between an instance-data-set and an instance-data-file. 
    An instance-data-set may be contained in a file, but may be transferred in a protocol message.

EV> indeed, so, should the title be updated s/file/data set/ ?
BALAZS2: I am reluctant to change the title this late in the process. Although your suggestion is reasonable, people might more easily recognize what an instance-data-file is than an what an instance-data-set means.

    -- Section 1 --
    The first 2 sentences are quite repetitive.
    BALAZS: The first sentence states that we need such data off-lie
    The second sentence states that this offline data may be needed in 3 different phases design, implementation or even later after the server and the YANG module is up and running, I just don't have access to it.
    Reworded to clarify this.

EV> thanks

    Is it about "offline delivery" or "exchange" ? At this point of reading the document, it is still unclear in my mind what it is about... The rest of the I-D made it clear.
    BALAZS: The draft is only about defining a format for YANG instance data. 
    Naturally once you have a data format it could be used both to deliver the information offline in a file or to exchange information using the format in an protocol message.
    Most use-cases mentioned are about Offline delivery.
    .

    Unclear which UC is either implemented or potential (even with the appendix); could also add forward references to the appendix UC). Should the
    implementation(s) be referenced if they are public ?
    BALAZS:  As stated in section 1. Use cases are listed only as examples. This draft is only about defining a format for YANG Instance Data.
    I know UC1,2,3 are already implemented by more than one company, but as this draft is only about the format, I don't think we should reference the implementations. 
    Also, UC1 is already utilized in 2 other internet drafts.

EV> nice to know, next time, you may want to have an 'implementation status' section (to be removed by the RFC editor).

    -- Section 1.1 --
    Unsure why a "data set" should be named? The choice of words does not seem the best fit (even though if I have no suggestions).
    BALAZS: Specific data sets need to be identified. What is it about? When was it prepared? 
EV> correct but it is also in the meta-data part (if not mistaken)
BALAZS2: Yes the name should be contained both in the filename and in the name metadata; so in my eyes that means this is a named dataset.
     I want a way to identify the specific data set. So, we give it a name (and a revision/timestamp).  This is why its named.
    Any better suggestion?

    -- Section 2 --
    Like some other ADs, I wonder why "The context data part MUST... except" is not a "SHOULD" as there are exceptions.

    What is the expected behaviour when the timestamp in the filename does not match the meta data ?
    BALAZS: We are following RFC7950 in which YANG related file names are recommended with a SHOULD but not prescribed with a MUST.
    Some people wanted to use separate timestamps when the instance-data-set is created and when it is put into an instance-data-file.
    This draft does not prescribe an expected behavior of the tools, it just defines the format.

    -- Section 2.1 --
    There is a "SHOULD" so when are exceptions/deviations acceptable ?
    BALAZS: Based on your and Murray's comments, this will be changed to MUST.

    The description of "simplified" is really too simple ;-)
    BALAZS: Added  "only the module name and revision-date is used "
EV> thanks

    I would also appreciate that the order of the list matches the following sub-sections order.
    BALAZS: OK, updated.

    Thank you for using RFC 8792.

    -- Section 4 --
    Did the authors think about adding the party creating the file and adding an optional signature in the file itself?
    BALAZS:  Not specifically. A basic format is defined, but it is indicated in section 2, that:
    "Some metadata items are defined in the YANG module "ietf-yang-instance-data", but other items MAY be used."

    == NITS ==

    -- Section 1 --
    The first 2 sentences are quite repetitive. Missing "." At the end of the 1st §
    BALAZS: The first sentence states that we need such data off-lie
    The second sentence states that this offline data may be needed in 3 different phases design, implementation or even later after the server and the YANG module is up and running, I just don't have access to it.
    Reworded to clarify this.
    Added last full stop.

    Why is "Factory Default Setting" capitalised ?
    BALAZS: OK, I decapitalize it (If there is such a word  :-)  ).

EV> I do not know either ;-)

    -- Section 1.2 --
    Why using the future tense "shall be" rather than "are" ?
    BALAZS: The principles are not facts that just exists, they are rather goals we fulfill by defining this format. . I though "shall" would be the correct   term.

    -- Section 2.1.1 and others --
    Suggest to warn the reader that the examples are further in the text in a different section.
    BALAZS: OK, will add it.

    -- Section 6 --
    A "," is missing.
    BALAZS: OK, will correct it