Re: Basic ietf process question ...

Thomas Nadeau <tnadeau@lucidvision.com> Thu, 02 August 2012 17:18 UTC

Return-Path: <tnadeau@lucidvision.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 A972021E80DE for <ietf@ietfa.amsl.com>; Thu, 2 Aug 2012 10:18:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[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 eGjvLqRJCzla for <ietf@ietfa.amsl.com>; Thu, 2 Aug 2012 10:18:40 -0700 (PDT)
Received: from lucidvision.com (lucidvision.com [72.71.250.34]) by ietfa.amsl.com (Postfix) with ESMTP id CA4D821E803F for <ietf@ietf.org>; Thu, 2 Aug 2012 10:18:39 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by lucidvision.com (Postfix) with ESMTP id 5AF1B220DB17; Thu, 2 Aug 2012 13:18:39 -0400 (EDT)
X-Virus-Scanned: amavisd-new at www.lucidvision.com
Received: from lucidvision.com ([127.0.0.1]) by localhost (static-72-71-250-34.cncdnh.fios.verizon.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U2GeS6eyv-kq; Thu, 2 Aug 2012 13:18:39 -0400 (EDT)
Received: from tnadeau-sslvpn-nc.jnpr.net (natint3.juniper.net [66.129.224.36]) by lucidvision.com (Postfix) with ESMTP id A03EB220DB14; Thu, 2 Aug 2012 13:18:38 -0400 (EDT)
Content-Type: text/plain; charset="iso-8859-1"
Mime-Version: 1.0 (Mac OS X Mail 6.0 \(1485\))
Subject: Re: Basic ietf process question ...
From: Thomas Nadeau <tnadeau@lucidvision.com>
In-Reply-To: <501AA9DF.6010208@raszuk.net>
Date: Thu, 02 Aug 2012 10:18:36 -0700
Content-Transfer-Encoding: quoted-printable
Message-Id: <F18D336A-1E60-4E17-8638-2583D7F54170@lucidvision.com>
References: <20120802055556.1356.17133.idtracker@ietfa.amsl.com> <CALaySJK6RE1pnk0RJZjpU8jHb9KKb3zOjGc5NqTcVyb7kTBOyw@mail.gmail.com> <CAL0qLwZaoVDtt_8o1Qr5NqG-rBk6jkAMMVT+jUUoiD2rhEvmuw@mail.gmail.com> <501AA9DF.6010208@raszuk.net>
To: robert@raszuk.net
X-Mailer: Apple Mail (2.1485)
Cc: 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: Thu, 02 Aug 2012 17:18:40 -0000

	I am discussing this very topic in the Ops meeting today at 3. Please come by to discuss.

	--Tom


On Aug 2, 2012:9:25 AM, at 9:25 AM, Robert Raszuk <robert@raszuk.net> wrote:

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