Andy says:
> I think it is useful to be able to retrieve state data with
> the same protocol that is used to edit configuration. Several
> people at the BOF said the same thing. I think the data retrieval
> will be used for lightweight operations, like checking interface status.
>I don't think SNMP developers that have already written comprehensive
> monitoring applications will rewrtie their code to use netconf instead.
> Router vendors are not going to pull out SNMP monitoring support because
> of netconf.
I strongly agree with Andy that we should be able to retrieve state data. The design of this new protocol must take into consideration the movement of data other than configuration. I think we would be overly short sighted if we focused only on the near term problem and we do not consider the complete problem. We don't necessarily have to solve the entire problem but I think we need to understand what is required so that we set the right path to solving the problems.
The question that needs to be answered is whether the type of data (config, state, etc.) being moved is a data model problem or a protocol problem. I believe that it is mostly a data model problem but I also think we need to understand if there are requirements placed on the protocol to facilitate this operation.
> I disagree that we don't know what an XML data model might
> look like. Look at the XMLCONF examples. Look at the Junoscript
> draft. Several vendors are already creating XML data models
> on their own.
I mostly agree with you here Andy. We know what the structure of information in an XML data model will look like. Look at XML Schema for a pretty good example. What we do not know is what data modeling features are required and how they may impact the protocol. For example, does the config/state data split affect the data model, the protocol, or both? I don't know but I think that it is a good question to have the answer to before we make any decisions.
> Andy
Cheers, /gww