> On Jan 25, 2017, at 6:18 AM, Benoit Claise <[email protected]> wrote: > > On 1/24/2017 8:26 PM, Martin Bjorklund wrote: >> Kent Watsen <[email protected]> <mailto:[email protected]> wrote: >>> Hi Andy, >>> >>> I think this discussion has come to a head. Please submit an updated >>> 6087bis as soon as you can. Some comments: >>> >>> >>> 1) on the 3rd line below, should the text clarify that --ietf is only for >>> IETF modules? Yes, and in addition yangvalidator.com <http://yangvalidator.com/> should stop complaining about module names and namespaces for modules that belong to other SDOs.
mef-cfm.yang:1: warning: RFC 6087: 4.1: the module name should start with one of the strings "ietf-" or "iana-" mef-cfm.yang:3: warning: RFC 6087: 4.8: namespace value should be "urn:ietf:params:xml:ns:yang:mef-cfm" >>> Also, how does the MUST here jive with the SHOULD in Section 4.10? >>> >>> - MUST use CODE BEGINS for a real module >>> - MUST NOT use CODE BEGINS for an example module >>> - MUST pass pyang --ietf for a real module >>> - MUST pass pyang for example module >>> >>> >>> 2) related to #1, Section 5 says "In general, modules in IETF Standards >>> Track specifications MUST comply with all syntactic and semantic >>> requirements of YANG [RFC7950]." >>> >>> First, what does "In general...MUST" mean? - maybe the >>> sentence should start with "Modules in IETF..."? >>> >>> Second, can we add a statement for non-IETF SDOs that might >>> have other conventions/restrictions? Would we recommend >>> --strict for starters, until they can add an SDO-specific >>> flag (e.g., --<sdo>) to pyang? >> We wouldn't talk about any specific tool; > Note that the document does already. > See section 4.4: > The 'pyang' compiler can be used to produce the tree diagram, using > the '-f tree' command line parameter. > > If the YANG module is comprised of groupings only, then the tree > diagram SHOULD contain the groupings. The 'pyang' compiler can be > used to produce a tree diagram with groupings using the '-f tree > --tree-print-groupings" command line parameters. > Reviewing this yesterday, I was wondering: why not speak of yanglint? > In discussion with Radek about this, he mentioned: > yes, libyang supports the tree format. However, in some details it differs > from pyang: > > - instead of the module prefixes, we use module names to avoid prefix > collisions. > - additionally, the default values (of the the leaf/leaf-lists/choice) are > printed > regards, Benoit >> we'd just talk about >> compliance with this document. Other SDOs will have to decide on >> their own rules, but we can suggest that they use all our rules except >> the naming convention for modules and namespaces. >> >> >>> 3) The first paragraph in Section 4.6 isn't clear, how about this? >>> >>> OLD >>> This section contains the module(s) defined by the specification. >>> These modules SHOULD be written using the YANG syntax defined in >>> [RFC7950]. YANG 1.0 [RFC6020] MAY be used if no YANG 1.1 constructs >>> or semantics are needed in the module. >>> >>> NEW >>> This section contains the module(s) defined by the YANG specification. >>> These modules SHOULD be written using the YANG 1.1 [RFC7950] syntax; >>> YANG 1.0 [RFC6020] syntax MAY be used if no YANG 1.1 constructs >>> or semantics are needed in the module. >>> >>> Note: this reads better, but I wonder, since YANG 1.0 syntax is a >>> subset of YANG 1.1 syntax, what is really being said here? - that >>> yang-version statement is optional? Or maybe, instead of focusing >>> on syntax, the statement should regard the version of YANG used? >> The point is that yang-version 1.1 SHOULD be used, and yang-version 1 >> MAY be used. >> >>> 4) Lastly, picking up on this discussion: >>> >>> https://www.ietf.org/mail-archive/web/netmod/current/msg17277.html >>> <https://www.ietf.org/mail-archive/web/netmod/current/msg17277.html>. >>> >>> can add an Informational reference to RFC 4151 in Section 5.9? >>> Maybe something like this: >>> >>> OLD >>> >>> The following examples are for non-Standards-Track modules. The >>> domain "example.com" SHOULD be used in all namespace URIs for example >>> modules. >>> >>> http://example.com/ns/example-interfaces >>> <http://example.com/ns/example-interfaces> >>> >>> http://example.com/ns/example-system >>> <http://example.com/ns/example-system> >>> >>> NEW >>> >>> The following URIs exemplify what might be used by non Standards >>> Track modules. Note that the domain "example.com" SHOULD be used >>> by example modules in IETF drafts. >>> >>> Example URIs using URLs per RFC 3986 [RFC3986]: >>> >>> http://example.com/ns/example-interfaces >>> <http://example.com/ns/example-interfaces> >>> http://example.com/ns/example-system >>> <http://example.com/ns/example-system> >>> >>> Example URIs using tags per RFC 4151 [RFC4151]: >>> >>> tag:example.com,2017:example-interfaces >>> tag:example.com,2017:example-system >> I would like to see urn:example:<module-name>, that's what I usually >> use here. >> >> >> /martin >> . >> > > _______________________________________________ > netmod mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/netmod Mahesh Jethanandani [email protected]
_______________________________________________ netmod mailing list [email protected] https://www.ietf.org/mailman/listinfo/netmod
