Re: [OPS-AREA] RE: Comments on XSDMI BoF proposal

Again thanks for the clarification.  I was less concerned about the 
finer point of what to represent than with the larger implication of 
doing all this via netconf instead of netconf and snmp.
/jon
Andy Bierman wrote:
> Jon Saperia wrote:
>>
>>
>> Andy Bierman wrote:
>>> Jon Saperia wrote:
>>>> Thanks for the clarification, lets see what Dave says.  If it is as 
>>>> you say, then I would say what is the justification for introducing 
>>>> duplication of information?
>>>
>>> What duplication are you talking about?
>>>
>>> BTW, I do not agree with the RFC 4741 definition of config
>>> because it is incomplete.
>>>
>>> I use a very NETCONF-centric definition, with 3 states:
>>>
>>>   config: Persistent Configuration
>>>           * saved in NV-storage
>>>           * included in <get-config>, <edit-config>, <copy-config>
>>>
>>>   tconfig: Transient Configuration (e.g., per-session configuration)
>>>           * not saved in NV-storage
>>>           * included in <get-config>, <edit-config>, <copy-config>
>>>
>>>   state: Non-Configuration Data
>>>           * not saved in NV-storage
>>>           * not included in <get-config>, <edit-config>, <copy-config>
>>>
>>>
>>
>> A reasonable interpretation of the last would be that it includes 
>> counters of various things, gauges , etc. Right?
>
> right.
> counters, ifOperStatus, timestamps, etc.
>
> However, there are corner-cases which could be used to argue
> that MAX-ACCESS of read-only does not always mean the object
> is classified as 'state' (e.g., agent-generated key or row index
> could be saved in NV-storage).
>
>>>> /jon
>>>
>>>
>>> Andy
>>>
>>
>
> Andy
>

-- 
Jon Saperia
(cell) 617-201-2655
(Eve.) 978-461-0264



_______________________________________________
OPS-NM mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/ops-nm