Re: [Netconf] Review of draft-ietf-netconf-monitoring-02.txt
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Netconf] Review of draft-ietf-netconf-monitoring-02.txt



Balazs Lengyel wrote:
Hello,

Andy Bierman wrote:

2.1.1. capabilities
From RFC4741: "The device uses capabilities to announce the set of data models that the device implements." This to me means that the device MUST advertise all it's models as capabilities as well. So the models will be included both in the capabilities and the schemas branch. Please indicate this.
 <sharon>
Experience has shown that was a not the best way to get data model definitions. I don't think we need to repeat that advise here. We may want to remove it in an update to RFC4741. </sharon>

I think it is useful to send the module capabilities in the <hello>.
The very first the manager needs to do is get these module caps,
so it can make sure compatible versions of all the relevant modules
are loaded.  Unless the manager is using a proprietary mechanism
(e.g., identifying packages or profiles, not individual modules),
then it will take the same amount of bandwidth and memory for
the <get> as the <hello>.

 >
Andy
Andy, according to RFC4741 do you consider it mandatory to advertise all data models?
- yes
- no
- yes, but as this is a mistake, we should forget it?


No, it is not mandatory.
Only the 'base' capability is mandatory, indicating
support for the RFC 4741 version of NETCONF.

I think it is easier (at many levels) to define a standard data
model and standard <get-schema> RPC method, than it is to add
additional standard features to the <hello> message.
(E.g., I don't want to deal with access control for <hello> PDUs).

I think the NETCONF spec should remain silent on adding
proprietary <capability> elements, and the schema discovery
draft should be the only standard mechanism defined for this purpose.


Balazs

Andy


_______________________________________________
Netconf mailing list
Netconf at ietf.org
https://www.ietf.org/mailman/listinfo/netconf



Note: Messages sent to this list are the opinions of the senders and do not imply endorsement by the IETF.