RE: Basic ietf process question ...

["Romascanu, Dan (Dan)" <[e-mail]>]

Hi,

The OPSAWG/OPSAREA open meeting this afternoon has an item on the agenda
concerning the revision of RFC1052 and discussing a new architecture for
management protocols. 


My personal take is that no one protocol, or one data modeling language
can match the operational requirements to configure and manage the wide
and wider range of hosts, routers and other network devices that are
used to implement IP networks and protocols. We should be talking
nowadays about a toolset rather than one tool that fits all. However,
this is a discussion that just starts. 

Regards,

Dan




> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]] On Behalf
Of
> Robert Raszuk
> Sent: Thursday, August 02, 2012 7:25 PM
> Cc: [e-mail]
> Subject: Basic ietf process question ...
> 
> All,
> 
> IETF documents have number of mandatory sections .. IANA Actions,
> Security Considerations, Refs, etc ...
> 
> Does anyone have a good reason why any new protocol definition or
> enhancement does not have a build in mandatory "XML schema" section
> which would allow to actually use such standards based enhancement in
> vendor agnostic way ?
> 
> There is a lot of talk about reinventing APIs, building network wide
OS
> platform, delivering SDNs (whatever it means at any point of time for
> one) ... but how about we start with something very basic yet IMHO
> necessary to slowly begin thinking of network as one plane.
> 
> I understand that historically we had/still have SNMP however I have
> never seen this being mandatory section of any standards track
document.
> Usually SNMP comes 5 years behind (if at all) making it obsolete by
> design.
> 
> NETCONF is great and very flexible communication channel for
> provisioning. However it is sufficient to just look at number of ops
> lists to see that those who tried to use it quickly abandoned their
> efforts due to complete lack of XML schema from each vendor they
happen
> to use or complete mismatch of vendor to vendor XML interpretation.
> 
> And while perhaps this is obvious I do not think that any new single
> effort will address this. This has to be an atomic and integral part
of
> each WG's document.
> 
> Looking forward for insightful comments ...
> 
> Best,
> R.
>