On Mon, Dec 21, 2015 at 7:40 AM, Juergen Schoenwaelder < [email protected]> wrote:
> On Mon, Dec 21, 2015 at 04:07:20PM +0100, Ladislav Lhotka wrote: > > > > > On 21 Dec 2015, at 15:47, Juergen Schoenwaelder < > [email protected]> wrote: > > > > > > I believe the model we have agreed on in RFC 6020 is this: > > > > > > - YANG modules in I-Ds are 'development' modules and not 'published' > > > modules. > > > > Section 10 makes no distinction between development and published > modules, except that for published modules a new "revision" statement MUST > be included in front of the existing "revision" statements. > > > > And I noted in my email that we may have to make section 11 of RFC > 6020bis more explicit. > > > > - It helps a lot during module development if 'development' modules > > > are actually implemented. Note that implementations of 'development' > > > modules are not intended to be 'deployed'. > > > > Absolutely, but this requires that development modules also carry > revision information - otherwise clients won't be able to figure out the > data model. > > > > I am against regulating development or investing effort to deal with > interoperability of development modules. If someone has to distinguish > the stuff running in your labs, I am sure he/she will find a way to do > so. > I agree with you. However, we do seem to aggressively extract YANG modules from documents and then ignore the source document completely. There is absolutely no way for a YANG compiler to tell the difference between a module extracted from an Internet Draft from a module extracted from an RFC. There is no "module-status" statement in YANG. module-status draft; module-status published; Perhaps this is overkill, but whining about module update rules constantly is getting old. Andy > > > - A 'published' module (something appearing in an RFC in the IETF) > > > will be subject to YANG update rules. > > > > Are you saying that other SDOs may adopt different rules, and that these > rules don't apply to proprietary modules? > > > > I believe that it is generally up to the organization publishing > modules to define what is a 'published module' and what is a > 'development module'. We can only reasonably define this for the > IETF. > > > > - 'Published' modules are expected to be 'implemented' and 'deployed'. > > > > > > - IETF WGs need to take care of the maintenance and interoperability > > > of what has been 'published', hence the module update rules. > > > > > > - Obviously, it is good to detect major flaws during 'development' and > > > hence the importance of early 'implementation' experience. > > > > > > Note that there are no formal module name or namespace assignements > > > until a module has been published as an RFC. A WG might put in a best > > > guess what the names might be but assignment and registration via IANA > > > happens during the publication process. > > > > > > Perhaps it helps to clarify in RFC6020bis that the updates rules apply > > > to published modules and not to modules under development. > > > > Yes, some clarification is needed in any case. > > > > Lada > > > > > > > > /js > > > > > > -- > > > Juergen Schoenwaelder Jacobs University Bremen gGmbH > > > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > > > Fax: +49 421 200 3103 <http://www.jacobs-university.de/> > > > > -- > > Ladislav Lhotka, CZ.NIC Labs > > PGP Key ID: E74E8C0C > > > > > > > > > > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > Fax: +49 421 200 3103 <http://www.jacobs-university.de/> > > _______________________________________________ > netmod mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/netmod >
_______________________________________________ netmod mailing list [email protected] https://www.ietf.org/mailman/listinfo/netmod
