Re: configuration: writable MIB modules versus NETCONF/YANG modules

"Thomas D. Nadeau" <[email protected]> Mon, 24 Feb 2014 08:16:02 -0500
Newsgroups gmane.ietf.ops
Message-ID <[email protected]>
	To be fair, Mikael is partially correct - there are modules being defined outside of the IETF process in external organizations like Open Daylight where the modules are being defined based on actual implementations. It is part of our mission in NETMOD and the other IETF WGs, to help bring these back into the IETF process by helping folks bring them in and have them standardized once real implementations have helped knock out most of the details. This is really not different from how the IETF process is supposed to work: running code, rough consensus.

	--Tom


> On Feb 24, 2014, at 6:48 AM, Benoit Claise <[email protected]> wrote:
> 
> Hi Mikael,
> 
> I share the same concern. If the process to produce RFC-based YANG modules is too heavy, then the YANG modules will be defined out of the IETF process.  Period.
> The good news is that YANG modules (based on some sort of consensus or running code) will be defined. The bad news is the IETF will not be relevant any longer.
> 
> Easing the YANG modules production at the IETF is a top of mind priority.
> 
> Regards, Benoit
> 
>>> On Thu, 20 Feb 2014, Andy Bierman wrote:
>>> 
>>> For instance, today an author can request protocol number allocations from
>>>> IANA etc. Wouldn't it make sense to have a similar model for extensions of
>>>> yang models?
>>> 
>>> Anybody can define their own YANG modules. IANA is not needed
>>> to publish non-IETF modules.
>> 
>> You completely missed my point. My point was to have yang modules defined in the same RFC as the proposed standard was defined in, and that a request would go out to some entity to approve the proposed yang model for whatever was being standardized. There would be a repository of IETF yang models somewhere, and these would no longer be published in RFC form, but by some other process. The IANA reference was just an example of existing such process/registry.
> 
> 
> _______________________________________________
> OPS-AREA mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/ops-area
>