Re: [NGO] external module properties

[Phil Shafer <phil at juniper.net>]

"Randy Presuhn" writes:
>> From: "David Harrington" <ietfdbh at comcast.net>
>> On a side note, keep in mind that some managed elements may have
>> multiple components, such as blades in a chassis, and the versions
>> supported might differ, so a Netconf server might also need to know
>> which version to use to perform validation.
>...
>Over time, as more features are added or deprecated
>or obsoleted, exactly what each of these abstractions would entail will
>change.  The ways in which they will change will be determined by what,
>if any, rules exist controlling what can be changed from one version to
>another of "the same" module.

Given that we'll have multiple revisions of multiple modules running
on multiple blades within the same chassis, there's really no one
right answer to "what revision(s) are you running?".

The good news is that we've arrived at the "there's no right answer"
answer quickly, so maybe we can put some lines around what sorts
of problems we thing we can solve and what we need to delay for
later work.  Can we address the simple cases with normal netconf
capability exchange, the more complex cases with module discovery,
and the worse cases with module versioning rules?

In other areas of discussion, the revision strings currently in
YANG are yyyy-mm-dd (2007-06-09), giving much more information
that decimal numbers.

I think I'd be happy to see these revision numbers in the
capability URIs that are advertised, and we could either allow
the inclusion of multiple revisions strings in the capability
or say that if no revision strings are present, the revision
information isn't simple (multiple or non-static), and the
application should resort to the module discovery mechanism.

Thanks,
 Phil
_______________________________________________
NGO mailing list
NGO at ietf.org
https://www.ietf.org/mailman/listinfo/ngo