On 02/08/2012 19:17, Robert Raszuk wrote: > Hi Brian, > > Perhaps we understand a different thing by "xml schema" As example what > I had in mind when asking this question was the example from "Appendix > A" of http://tools.ietf.org/html/draft-marques-l3vpn-schema-00 where > while perhaps not yet complete it does provide decent representation of > one of the popular service today. There are certainly cases where systematic metadata are useful; I can't judge whether VPN configuration is one of them, but I can easily believe it. In such a case, I suppose XML is as good a tool as ASN.1, ABNF or whatever else you might choose. > That's what I had mind asking why such appendix isn't a mandatory part > of each new protocol extension. That's an enormous leap that I just don't understand. Most protocols don't need that sort of configuration complexity. > It has very little to do with Web Services you may be referring to. Yes it does. It's exactly because of a doctrinaire approach that whatever it is, it should be represented by an XML schema, that WS-splat became such a horribly complex matter. Again: no problem with creating XML schemata where they are useful. But making them mandatory would be just as bad as making MIB modules mandatory, IMHO. Brian > > Many thx, > R. > >> I think anyone with intimate experience of the Web Services standards >> experiment (trying to use XML as if it was a Turing machine) would have >> extreme doubts about any proposal to impose such a requirement. >> >> It was not for no reason that many people came to refer to the Web >> Services family of standards as "WS-splat". The words "small" and >> "xml schema" don't really belong together, >> >> Regards >> Brian Carpenter >> >> On 02/08/2012 18:12, Robert Raszuk wrote: >>> Hi Dan, >>> >>>> We should be talking >>>> nowadays about a toolset rather than one tool that fits all. >>> >>> Just to clarify what I asked about .. I am not looking for a single tool >>> or single protocol to be used to configure everything. >>> >>> I am asking for small building block like xml schema (or something >>> similar) to be part of each new IETF proposal or protocol change. IMHO >>> only that can allow any further more fancy abstractions and tools to be >>> build and used in practice. >>> >>> Best regards, >>> R. >>> >>> >>> >>>> 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: ietf-bounces@xxxxxxxx [mailto:ietf-bounces@xxxxxxxx] On Behalf >>>> Of >>>>> Robert Raszuk >>>>> Sent: Thursday, August 02, 2012 7:25 PM >>>>> Cc: ietf@xxxxxxxx >>>>> 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. >>>>> >>>> >>>> >>>> >>> >>> >> >> > >