Re: Basic ietf process question ...

Brian E Carpenter <brian.e.carpenter@gmail.com> Fri, 03 August 2012 06:58 UTC

Return-Path: <brian.e.carpenter@gmail.com>
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 959C021E8034; Thu, 2 Aug 2012 23:58:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.462
X-Spam-Level:
X-Spam-Status: No, score=-101.462 tagged_above=-999 required=5 tests=[AWL=0.229, BAYES_00=-2.599, RCVD_ILLEGAL_IP=1.908, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
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 cDg7TH6zMSrw; Thu, 2 Aug 2012 23:58:04 -0700 (PDT)
Received: from mail-wi0-f172.google.com (mail-wi0-f172.google.com [209.85.212.172]) by ietfa.amsl.com (Postfix) with ESMTP id 4D33821E8039; Thu, 2 Aug 2012 23:58:04 -0700 (PDT)
Received: by wibhm11 with SMTP id hm11so4597115wib.13 for <multiple recipients>; Thu, 02 Aug 2012 23:58:02 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=dbONaZKbFwOe0wVPYbEInwlodLIqmdwLE3wCA43X8vc=; b=C50MhQYZAsxht85VVXdVtTaKmvvcxdBL8Xh/NPu5/sB35iB7J/RTNLgt6AS3CGPy1j t3J8HRwEXur62kvW7HhG8Uehk+pLAfUjzHZGG+T4SKDUDRAGLMZUGci8Xnwyi1VEe/sX SwAfvEgPsGau1VgghlrAreoiruIQ0h/id6CvfTE07R2qTh4RWATjtWx8v4IBb316ZCKp low46WnwLpZ5BgFQtWRVV6dO9XJKXHpCmSaW1WuOc6fiY0sEAnYa4Ezn+YuJDR/mDikW K42xGLXqNwGlLOItbxwJxMx+VvfcAxUCrjzomQwqmG7Az8+c6laWp+qt2aZozon/1tno 76wA==
Received: by 10.216.101.68 with SMTP id a46mr335171weg.120.1343977082767; Thu, 02 Aug 2012 23:58:02 -0700 (PDT)
Received: from [192.168.1.64] (host-2-102-217-126.as13285.net. [2.102.217.126]) by mx.google.com with ESMTPS id cu1sm37903317wib.6.2012.08.02.23.58.00 (version=SSLv3 cipher=OTHER); Thu, 02 Aug 2012 23:58:01 -0700 (PDT)
Message-ID: <501B767B.6030501@gmail.com>
Date: Fri, 03 Aug 2012 07:58:03 +0100
From: Brian E Carpenter <brian.e.carpenter@gmail.com>
Organization: University of Auckland
User-Agent: Thunderbird 2.0.0.6 (Windows/20070728)
MIME-Version: 1.0
To: robert@raszuk.net
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> <501AC43A.3020307@raszuk.net>
In-Reply-To: <501AC43A.3020307@raszuk.net>
Content-Type: text/plain; charset="UTF-8"
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
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: Fri, 03 Aug 2012 06:58:06 -0000

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@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.
>>>>>
>>>>
>>>>
>>>>
>>>
>>>
>>
>>
> 
>