Re: Basic ietf process question ...

[Robert Raszuk <[e-mail]>]

Hi Joe,

Many thx for your comments.

Perhaps my intentions were not very well described. Personally I am not 
that much stuck on plain XML schema .. it could be expressed in any 
language IETF would choose to use. The point is not how to do it .. but 
to do it at the moment of bringing new protocol extension.

However for years the same functionality is completely different to 
configure using one vendor from other vendor (leave alone that even 
within single vendor there are complete different UIs to provision the 
same knob).

If anyone is even remotely serious about some form of common network OS 
IMHO the first step is to create unified configuration abstraction. The 
xml schema for each proto extension would be just a standard based API 
for configuration input.

Keep in mind that today routers are configured by scripts from central 
management clusters where there are tons of templates which in fact 
completely differ from vendor to vendor and their maintenance and 
keeping them up to date is a real pain.

Regards,
R.


> On 8/2/12 9:25 AM, "Robert Raszuk" <[e-mail]> wrote:
>
>> 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 ?
>
> For docs that use XML, requiring some form of schema makes sense.
> However, what we're finding at the application layer is that often times
> using JSON (see RFC 4627) ends up with better interoperability more
> quickly than using XML, except in the case of human-readable content like
> marked-up text.  See RFC 6120, Appendix A (http://goo.gl/CBv8G) for
> another example.
>
> For those that insist on XML, RelaxNG (http://goo.gl/MYnB1) is another
> language you can use to describe your XML, which is a little easier to
> learn than XSD.
>
> However, for implementors, if you start with the schema and blindly use it
> for conformance checking of real-world traffic, you are likely to have
> both performance and extensibility issues in practice.
>
> If folks at other layers in the stack would like input from Apps folks,
> I'm sure that we would be happy to share our lessons learned.  Join
> apps-discuss (http://goo.gl/0Otjv) and ask for help.
>