IETF Operations Network Management Area

Jon Saperia | 6 Jun 2007 14:52

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

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?
/jon

Romascanu, Dan (Dan) wrote:
>  
>  
>  
>  
>
>
> ________________________________
>
> 	From: Jon Saperia [mailto:saperia <at> jdscons.com] 
> 	
>
> 			XML-based management leverages lessons learned
> from the WWW. 
> 			While document-based rather than command-based,
> tasks can 
> 			often be grouped into a document-type interface,
> such as a 
> 			web page. With automated translation from XML
> into HTML (and 
> 			related technologies), we can work on developing
>
> 			task-based-document NM interfaces. 
> 			
> 			I think we need to spend more time thinking

(Continue reading)

headers

Andy Bierman | 6 Jun 2007 18:05

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

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>

> /jon

Andy

_______________________________________________
OPS-NM mailing list

(Continue reading)

headers

Jon Saperia | 6 Jun 2007 19:10

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


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?

(Continue reading)

headers

Andy Bierman | 6 Jun 2007 19:28

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

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>
>>
>>
>

(Continue reading)

headers

Jon Saperia | 6 Jun 2007 19:32

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

(Continue reading)

headers

David Harrington | 6 Jun 2007 15:07

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

Hi,

I was referring to the separation of config and state data, as
described in RFC4741.
I do think the distinction made in rfc4741 is not very clear, so work
would need to be done.

Would this result in duplication of information? Without a draft
making a specific proposal for this, I cannot say. It might.

dbh

> -----Original Message-----
> From: Jon Saperia [mailto:saperia <at> jdscons.com] 
> Sent: Wednesday, June 06, 2007 8:52 AM
> To: Romascanu, Dan (Dan)
> Cc: David Harrington; Andy Bierman; Ops-Nm
> Subject: Re: [OPS-AREA] RE: [OPS-NM] Comments on XSDMI BoF proposal
> 
> 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?
> /jon
> 
> Romascanu, Dan (Dan) wrote:
> >  
> >  
> >  
> >

(Continue reading)