Re: [eX-bulk] : Re: configuration: writable MIB modules versus NETCONF/YANG modules - part 2

On 3 Mar 2014, at 13:37, Thomas Nadeau wrote:

> 	Sorry for not replying to this thread - been traveling and busy all 
> weekend...  One comment inline below:
>
>
>> Dear all,
>>
>> [I bcc'ed some people, with whom I discussed this issue privately. I 
>> want to make sure they're in the opsarea loop. Sorry, if you receive 
>> this email twice]
>>
>> I discussed the following statement with the IESG. I ideally wanted 
>> to have this statement approved as an IESG statement before the 
>> beginning of the week, but I realize that it might need some more 
>> discussion among the OPS community...
>> The OPS area recommends the use of NETCONF/YANG standards for 
>> configuration. IETF working groups are therefore encouraged to use 
>> the NETCONF/YANG standards for configuration, especially in new 
>> charters. SNMP MIB modules creating and modifying persistent 
>> configuration state should only be produced by working groups in 
>> cases of clear utility and consensus to use SNMP write operations for 
>> configuration.
>> Btw, one IESG member insisted on having "creating and modifying" 
>> instead of "modifying".
>>
>> Let me focus on a more important issue.
>> First let me make sure that we agree on one terminology. The 
>> NETCONF/YANG terminology is in RFC 6244:
>> o  Configuration data is the set of writable data that is required to
>> transform a system from its initial default state into its current
>> state [RFC4741].
>>
>> o  Operational state data is a set of data that has been obtained by
>> the system at runtime and influences the system's behavior similar
>> to configuration data.  In contrast to configuration data,
>> operational state is transient and modified by interactions with
>> internal components or other systems via specialized protocols.
>>
>> o  Statistical data is the set of read-only data created by a system
>> itself.  It describes the performance of the system and its
>> components.
>> Operational state data is sometimes called ephemeral (or 
>> non-persistent configuration data), as opposed to the "configuration 
>> data" that is persistent.
>> See RFC 6244 section 4.3.2.x for some useful examples.
>>
>> The statement has been carefully crafted to cover the 4 different 
>> cases:
>>
>>                                                                       
>> SNMP                                                         
>> NETCONF/YANG
>>                                        
>> +-----------------------------------------------------------------+--------------------------------------------------+
>>      Configuration data  | SHOULD NOT specify writable MIB modules    
>> |  SHOULD use NETCONF/YANG          |
>>                                        
>> |-----------------------------------------------------------------+--------------------------------------------------|
>> Operational State data  | Not clear guidelines at time point in time  
>> (*)   |   SHOULD use NETCONF/YANG         |
>>                                        
>> +---------------------------------------------------------------------------------------------------------------------+
>>
>> Let me focus on (*).
>> Some of you are telling: SNMPset is not enabled in networks, period. 
>> Don't specify new writable MIB modules, even for operational state 
>> data, it doesn't make sense.
>> Some others are telling: Note that this statement limits the 
>> discussion to configuration data. Note also that there is no standard 
>> way to modify operational state via NETCONF at this point in time (so 
>> it would be strange to discourage SNMP if there is no standardized 
>> alternative).
>>
>> I believe we need some more discussion on this specific point.  
>> Please share your point of view:
>> - Should we keep the statement as it is, but better explain it? 
>> (which might require more background, so maybe a draft instead of a 
>> brief statement)
>> - Should we extend the statement and remove "persistent" from this 
>> sentence: SNMP MIB modules creating and modifying persistent 
>> configuration state should only be produced by working groups in 
>> cases of clear utility and consensus to use SNMP write operations for 
>> configuration?
>> - Something else?
>
> 	This is precisely what is the question: is the SET operation enabled 
> in networks or not ?  I think the overwhelming answer is "no". The 
> discussions that are rabbit holing into questions like "what is 
> configuration?, "is it persistent, etc...?" are completely missing the 
> point. The simple issue at hand is the fact that boxes in networks are 
> programmed to reject ANY SNMP SET operations.  This is what Randy was 
> channeling from operators the other day as well. We really need to 
> listen to the operational feedback on this one.

I agree Tom.  The larger question, at the end of the day, is how many 
models do we want to continue support.  Do we want to define MIBs for 
statistics, and NETCONF for configuration, going forward, or do we want 
to, over time, standardize on a single data model infrastructure 
(YANG?), that can then generate NETCONF, and possibly MIBs, if MIBs are 
still desired for operational data collection?  I'm in favor of a common 
data model definition, that can then be rendered into whatever protocols 
are deemed appropriate by the implementer.

Christopher

>
> 	--Tom
>
>
>>
>> Regards, Benoit
>>
>>
>>
>>
>> _______________________________________________
>> OPS-AREA mailing list
>> [email protected]
>> https://www.ietf.org/mailman/listinfo/ops-area
>
> _______________________________________________
> OPS-AREA mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/ops-area


--
李柯睿
Check my PGP key here: http://www.asgaard.org/cdl/cdl.asc
Current vCard here: http://www.asgaard.org/cdl/cdl.vcf

_______________________________________________
OPS-AREA mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ops-area