On 9/6/2017 2:05 PM, Martin Bjorklund wrote: > Kent Watsen <[email protected]> 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 [email protected] https://www.ietf.org/mailman/listinfo/netmod
