On Tue, Mar 6, 2018 at 8:44 PM, Suresh Krishnan <sur...@kaloom.com> 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 "ietf-...@2016-03-20.yang" > ... > 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
_______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
