Re: [netmod] Suresh Krishnan's Discuss on draft-ietf-netmod-rfc6087bis-18: (with DISCUSS and COMMENT)

[Andy Bierman <[e-mail]>]

On Tue, Mar 6, 2018 at 8:44 PM, Suresh Krishnan <[e-mail]> wrote:

> Suresh Krishnan has entered the following ballot position for
> draft-ietf-netmod-rfc6087bis-18: Discuss
>
> 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/iesg/statement/discuss-criteria.html
> for more information about IESG DISCUSS and COMMENT positions.
>
>
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-netmod-rfc6087bis/
>
>
>
> ----------------------------------------------------------------------
> DISCUSS:
> ----------------------------------------------------------------------
>
> * Section 4.25
>
> I think this might be a simple misunderstanding but I have no idea what
> compliance with this statement implies.
>
> "A YANG module MUST NOT be designed such that the set of modules found on a
> server implementation can be predetermined in advance."
>
> Can you please clarify?
>
>

OK to remove this sentence.
Not sure where it came from



>
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
>
> Section 3.2:
>   The date looks to be contradictory between the explanatory text
>
> "The following example is for the '2010-01-18' revision of the  'ietf-foo'
> module:"
>
> and the actual code component defined right after
>
>                    <CODE BEGINS> file "[e-mail]"
> ...
>                                  revision 2016-03-20 {
> ...
>


OK will update revision date



>
> * Section 4.8
>
> I went over this text several times to figure out what it means. Can you
> simplify this, or provide examples as to when revision dates are/are not
> to be
> updated.
>
>    It is not required to keep the full revision history of draft
>    versions (e.g., modules contained within Internet-Drafts).  That is,
>    within a sequence of draft versions, only the most recent revision
>    need be recorded in the module.  However, whenever a new (i.e.
>    changed) version is made available (e.g., via a new version of an
>    Internet-Draft), the revision date of that new version MUST be
>    updated to a date later than that of the previous version.
>
>
OK -- will clarify that the same revision-stmt can be reused in an Internet
Draft.
The revision date is updated if the module is changed.



> * Section 4.14.1.  Non-Presence Container
>
> So what is the guideline here? That there is no guideline?
>
>

that is intentional -- usage of NP containers needs to be reviewed on a
case-by-case basis
because like the text says, it is subjective as to what is inappropriate
usage of an NP-container.



> * Section 4.20
>
> What does "cannot" imply here? MUST NOT? SHOULD NOT?
>


MUST NOT -- per RFC 7950, 7.20.3



>
> "The YANG "deviation" statement cannot appear in IETF YANG modules"
>
>
>
Will change "cannot" to is not allowed to"


Andy