Re: Basic ietf process question ...

Robert Raszuk <robert@raszuk.net> Thu, 02 August 2012 18:17 UTC

Return-Path: <robert@raszuk.net>
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1193111E8221 for <ietf@ietfa.amsl.com>; Thu, 2 Aug 2012 11:17:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.254
X-Spam-Level:
X-Spam-Status: No, score=-2.254 tagged_above=-999 required=5 tests=[AWL=0.345, BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r7a31dfmCyBa for <ietf@ietfa.amsl.com>; Thu, 2 Aug 2012 11:17:32 -0700 (PDT)
Received: from mail1310.opentransfer.com (mail1310.opentransfer.com [76.162.254.103]) by ietfa.amsl.com (Postfix) with ESMTP id 201EE11E821C for <ietf@ietf.org>; Thu, 2 Aug 2012 11:17:32 -0700 (PDT)
Received: (qmail 8399 invoked by uid 399); 2 Aug 2012 18:17:31 -0000
Received: from unknown (HELO ?130.129.17.10?) (pbs:robert@raszuk.net@130.129.17.10) by mail1310.opentransfer.com with ESMTPM; 2 Aug 2012 18:17:31 -0000
X-Originating-IP: 130.129.17.10
Message-ID: <501AC43A.3020307@raszuk.net>
Date: Thu, 02 Aug 2012 20:17:30 +0200
From: Robert Raszuk <robert@raszuk.net>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:14.0) Gecko/20120713 Thunderbird/14.0
MIME-Version: 1.0
To: Brian E Carpenter <brian.e.carpenter@gmail.com>
Subject: Re: Basic ietf process question ...
References: <20120802055556.1356.17133.idtracker@ietfa.amsl.com><CALaySJK6RE1pnk0RJZjpU8jHb9KKb3zOjGc5NqTcVyb7kTBOyw@mail.gmail.com><CAL0qLwZaoVDtt_8o1Qr5NqG-rBk6jkAMMVT+jUUoiD2rhEvmuw@mail.gmail.com> <501AA9DF.6010208@raszuk.net> <EDC652A26FB23C4EB6384A4584434A0407E24713@307622ANEX5.global.avaya.com> <501AB4F5.7030205@raszuk.net> <501AC2C7.6040707@gmail.com>
In-Reply-To: <501AC2C7.6040707@gmail.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Cc: "Romascanu, Dan \(Dan\)" <dromasca@avaya.com>, opsawg@ietf.org, ietf@ietf.org
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: robert@raszuk.net
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ietf>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 02 Aug 2012 18:17:33 -0000

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.

That's what I had mind asking why such appendix isn't a mandatory part 
of each new protocol extension.

It has very little to do with Web Services you may be referring to.

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@ietf.org [mailto:ietf-bounces@ietf.org] On Behalf
>>> Of
>>>> Robert Raszuk
>>>> Sent: Thursday, August 02, 2012 7:25 PM
>>>> Cc: ietf@ietf.org
>>>> 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.
>>>>
>>>
>>>
>>>
>>
>>
>
>