Re: [netmod] two options for removing /foo-state trees?

["Acee Lindem (acee)" <[e-mail]>]

Ok - it is less painful if we only have to deprecate the *-state nodes.
However, what about secondary and tertiary implications of moving to NDMA?
If we change a path from “interface-state-ref” to “interface-ref” to
reference an interface, I’d hope no one would expect the old statement to
be kept around… 

Thanks,
Acee 

On 9/7/17, 10:40 AM, "netmod on behalf of Lou Berger"
<[e-mail] on behalf of [e-mail]> wrote:

>
>
>On 9/6/2017 2:05 PM, Martin Bjorklund wrote:
>> Kent Watsen <[e-mail]> wrote:
>>> ...
>
>>>  2) a new module name forces an update to other modules that
>>>     importing it (e.g., to resolve XPaths), that otherwise may
>>>     not need to be updated.
>> This is a major drawback!
>I think this is a compelling consideration.
>
>>
>>>  3) the approach doesn't follow what draft-dsdt-nmda-guidelines
>>>     says in guideline (c), but this seems to be a minor point.
>>>  4) republishing the old module with all nodes deprecated seems
>>>     off, but 7950 doesn't list 'status' as a substatement to
>>>     the 'module' statement, so what else can we do?
>>>
>>> Any other pros or cons?
>
>I think a pro is that for models that are not widely implemented or
>referenced, they are more aligned with how we expect new NMDA-compatible
>models to be structured.
>
>>>
>>>
>>> Another question is if all the modules have to be updated the
>>> same way
>> In general I'd say no.  An entirely new module might be the right
>> approach in some cases, but in the majority of cases not.
>I'd go the other way on this: the deprecate/obsolete/update approach
>should be followed for the few modules that are widely referenced.  All
>other modules should be replaced (via a name change) with NMDA
>structured modules.
>
>> For the routing modules, I don't think a new name is worth it.
>Do you see it as widely implemented?  Do others agree?
>
>>
>> /martin
>>
>>
>>> (which could block adoption of these drafts until we
>>> settled on an approach), or do we let each module update in a
>>> way that suites it best base on, e.g., how deployed it is, how
>>> often it's been imported by other drafts, etc.  Thoughts?
>>>
>>>
>>> Kent  // contributor
>>>
>>>
>>>
>...
>
>_______________________________________________
>netmod mailing list
>[e-mail]
>https://www.ietf.org/mailman/listinfo/netmod