Re: [netmod] questions about draft-rtgyangdt-rtgwg-device-model-00

[Nadeau Thomas <[e-mail]>]

> On Aug 26, 2015:9:09 AM, at 9:09 AM, Acee Lindem (acee) <[e-mail]> wrote:
> 
> 
> 
> On 8/26/15, 8:09 AM, "Martin Bjorklund" <[e-mail]> wrote:
> 
>> Nadeau Thomas <[e-mail]> wrote:
>>> 
>>>> On Aug 26, 2015:6:26 AM, at 6:26 AM, Martin Bjorklund <[e-mail]>
>>>> wrote:
>>>> 
>>>> "Acee Lindem (acee)" <[e-mail]> wrote:
>>>>> 
>>>>> 
>>>>> On 8/26/15, 2:40 AM, "Juergen Schoenwaelder"
>>>>> <[e-mail]> wrote:
>>>>> 
>>>>>> On Tue, Aug 25, 2015 at 10:53:55PM -0400, Lou Berger wrote:
>>>>>> 
>>>>>>>> Hopefully, a decision to change all existing models (including
>>> vendor
>>>>>>>> models!) will be based on something more technical than the fact
>>> that
>>>>>>>> a group of people "really like it" some other way.
>>>>>>> 
>>>>>>> I'm equally unsure that having an argument of "I got there first"
>>> is a
>>>>>>> compelling argument given the number of folks (including vendors)
>>> who
>>>>>>> have stated willingness (or even support) for change.  I think
>>> having
>>>>>>> a
>>>>>>> major class of users stand up and say this is important should
>>> garner
>>>>>>> some notice.
>>>>>> 
>>>>>> Please keep in mind that we are talking about several published
>>>>>> proposed standards that have been implemented and deployed. I think
>>>>>> there must be convincing technical reasons to declare them broken
>>> and
>>>>>> to redo them.
>>>>> 
>>>>> Other than adding /device at the top, we are not obsoleting RFC
>>>>> 7223.
>>>> 
>>>> This doesn't make sense.  The YANG model is the contract.  You are
>>>> proposing changing the contract.  The fact is that you will be
>>>> obsoleting 7223 (and the other RFCs).  Existing devices and
>>>> applications will have to change in order to handle this new top-level
>>>> node (which will be in some other namespace I presume, unless your
>>>> proposal is one gigantic monolithic model).
>>>> 
>>>> 
>>>> /martin
>>> 
>>> 	Again I will ask: why is this bad?
>> 
>> My point above was in reply to the statement that "we are not
>> obsoleting RFC 7223" [because the change is so small?] - you would in
>> fact be obsoleting the model in 7223.
> 
> There have been other mechanisms discussed to relocate YANG models.
> Perhaps, one of these could be employed in lieu of obsoleting the existing
> models. 
> 
> Thanks,
> Acee 

	This is exactly what I want to get on the table.  If we can agree
on a mechanism/s to do relocate modules, then this might alleviate the
resistance to evolve models. The current issue aside, if you step back and look 
at the wider IETF situation around all the Yang models being created and
are RFCs, and the dependency graph that is created. You can then 
imagine a time after that point when others come along that evolve 
parts or entire modules.  We currently refer to this as “obsoleting”
all of the modules that it depends on, which is a very big problem using
the current RFC process.  Not only does it require a revision of all those
RFCs (due to obsoleting the previous ones) - and thus all the procedural/management
overhead that will incur - but the time lag from start to finish. And
this might happen for any new module. This is not scaleable going forward.

	—Tom



> 
> 
>> 
>> 
>> /martin
>