Re: [i2rs] draft-ietf-i2rs-ephemeral-state-07.txt - protocol identification

"Joel M. Halpern" <jmh@joelhalpern.com> Thu, 26 May 2016 17:42 UTC

Return-Path: <jmh@joelhalpern.com>
X-Original-To: i2rs@ietfa.amsl.com
Delivered-To: i2rs@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1B8B812D7EB for <i2rs@ietfa.amsl.com>; Thu, 26 May 2016 10:42:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.702
X-Spam-Level:
X-Spam-Status: No, score=-2.702 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=joelhalpern.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lF3hvYpwGV1c for <i2rs@ietfa.amsl.com>; Thu, 26 May 2016 10:42:34 -0700 (PDT)
Received: from maila2.tigertech.net (maila2.tigertech.net [208.80.4.152]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 924EC12D7E2 for <i2rs@ietf.org>; Thu, 26 May 2016 10:42:34 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by maila2.tigertech.net (Postfix) with ESMTP id 7972E24EA94; Thu, 26 May 2016 10:42:34 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=1.tigertech; t=1464284554; bh=HMpmCcfe0RurnCLUC7l1LN5geGfaxSlsHTtBwTgVml8=; h=Subject:To:References:From:Date:In-Reply-To:From; b=GVU50jKgjrsdYschqhYzAAjFUw/bzKYzDQDD/aIDa9fQemGBm/jpinrXLqF4VLX2f BlLFflSWbKkgEjh+m7yUoQR8krxrMNdG++3R/EYGSJSVK46AHz/SxdA0nucHM5NIkv RhwWOEJNlOehwRVMNXSunXpuR+tsfrB6YrbE9Bp4=
X-Virus-Scanned: Debian amavisd-new at maila2.tigertech.net
Received: from Joels-MacBook-Pro.local (209-255-163-147.ip.mcleodusa.net [209.255.163.147]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by maila2.tigertech.net (Postfix) with ESMTPSA id EE272247557; Thu, 26 May 2016 10:42:33 -0700 (PDT)
To: Susan Hares <shares@ndzh.com>, i2rs@ietf.org
References: <20160526013921.2840.56377.idtracker@ietfa.amsl.com> <cf09098f-0d65-18ff-d568-ee9c1d7cf230@joelhalpern.com> <03fc01d1b76f$6efd4540$4cf7cfc0$@ndzh.com>
From: "Joel M. Halpern" <jmh@joelhalpern.com>
Message-ID: <85ce0bf3-3e2e-23e6-4e14-5ed4bc423a18@joelhalpern.com>
Date: Thu, 26 May 2016 13:42:19 -0400
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:45.0) Gecko/20100101 Thunderbird/45.1.0
MIME-Version: 1.0
In-Reply-To: <03fc01d1b76f$6efd4540$4cf7cfc0$@ndzh.com>
Content-Type: text/plain; charset="windows-1252"; format="flowed"
Content-Transfer-Encoding: 7bit
Archived-At: <http://mailarchive.ietf.org/arch/msg/i2rs/vxzez6cfKKVqMpHC8qEgPQXTLgQ>
Subject: Re: [i2rs] draft-ietf-i2rs-ephemeral-state-07.txt - protocol identification
X-BeenThere: i2rs@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: "Interface to The Internet Routing System \(IRS\)" <i2rs.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/i2rs>, <mailto:i2rs-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/i2rs/>
List-Post: <mailto:i2rs@ietf.org>
List-Help: <mailto:i2rs-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/i2rs>, <mailto:i2rs-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 26 May 2016 17:42:36 -0000

First, I would prefer that we express our requirements, and let the 
protocol developers determine what is the best way of meeting those 
requirements.  That is what I want when I receive requirements, so I try 
to meet that standard when I send them.

As for a proposed mechanism, I would again separate pieces.  The I12RS 
Client needs to know if certain capabilities are present.  These include 
support for specific models (already present in netConf), support for 
specific additional capabilities such as Ephemeral handling, and support 
for the attribution mechanisms.  There may be others.  Depending upon 
how these needs are met, there are multiple ways to indicate these 
capabilities within the NetConf and YANG framework.

Further, and part of the reason for my concerns, is that I would want to 
know whether the I2RS agent is supporting YANG 1.0, YANG 1.1, or a 
future YANG 1.2 or 2.0.  Without having to change the I2RS "protocol" 
indication.

If we were really in a situation where I2RS support was a fork from the 
base protocols, then a protocol version would be appropriate.  That 
situation would be extremely unfortunate.  I believe we are avoiding that.

yours,
Joel

On 5/26/16 12:55 PM, Susan Hares wrote:
> Joel:
>
> I2RS protocol as a re-use protocol is specifying a set of changes to NETCONF
> or RESTCONF.  We have two ways it can be identified:
>
> 1) Implementations can "value" (I2RS protocol version) to query that
> indicates the NETCONF implementation or the RESTCONF implementation provides
> all the features requested by I2RS protocol requirements.
>
> 2) Implementations query the NETCONF implementation or the RESTCONF
> implementation supports all the features required for the I2RS protocol.
>
> It seemed reasonable to me to specify that NETCONF or RESTCONF set-up a
> value that implementations can query to indicate it supports I2RS protocol
> requirements.
>
> Did you have a better way to do this?
>
> Sue
>
> -----Original Message-----
> From: i2rs [mailto:i2rs-bounces@ietf.org] On Behalf Of Joel Halpern
> Sent: Wednesday, May 25, 2016 10:04 PM
> To: i2rs@ietf.org
> Subject: Re: [i2rs] draft-ietf-i2rs-ephemeral-state-07.txt - protocol
> identification
>
> Mostly, this looks very good.
>
> I find it odd and overspecified that the first requirement for netConf and
> Restconf is described as indicating I2RS support via the protocol version.
>
> It seems unlikely that the protocol version is the right way to represent
> this.  And it seems that the I2RS WG should specify the need, not the
> mechanism used to represent it.
>
> Yours,
> Joel
>
> On 5/25/16 9:39 PM, internet-drafts@ietf.org wrote:
>>
>> A New Internet-Draft is available from the on-line Internet-Drafts
> directories.
>> This draft is a work item of the Interface to the Routing System of the
> IETF.
>>
>>         Title           : I2RS Ephemeral State Requirements
>>         Authors         : Jeff Haas
>>                           Susan Hares
>> 	Filename        : draft-ietf-i2rs-ephemeral-state-07.txt
>> 	Pages           : 14
>> 	Date            : 2016-05-25
>>
>> Abstract:
>>    This document covers requests to the NETMOD and NETCONF Working
>>    Groups for functionality to support the ephemeral state requirements
>>    to implement the I2RS architecture.
>>
>>
>> The IETF datatracker status page for this draft is:
>> https://datatracker.ietf.org/doc/draft-ietf-i2rs-ephemeral-state/
>>
>> There's also a htmlized version available at:
>> https://tools.ietf.org/html/draft-ietf-i2rs-ephemeral-state-07
>>
>> A diff from the previous version is available at:
>> https://www.ietf.org/rfcdiff?url2=draft-ietf-i2rs-ephemeral-state-07
>>
>>
>> Please note that it may take a couple of minutes from the time of
>> submission until the htmlized version and diff are available at
> tools.ietf.org.
>>
>> Internet-Drafts are also available by anonymous FTP at:
>> ftp://ftp.ietf.org/internet-drafts/
>>
>> _______________________________________________
>> I-D-Announce mailing list
>> I-D-Announce@ietf.org
>> https://www.ietf.org/mailman/listinfo/i-d-announce
>> Internet-Draft directories: http://www.ietf.org/shadow.html or
>> ftp://ftp.ietf.org/ietf/1shadow-sites.txt
>>
> I2RS
>
> _______________________________________________
> i2rs mailing list
> i2rs@ietf.org
> https://www.ietf.org/mailman/listinfo/i2rs
>
>