Re: [trill] Alexey Melnikov's Discuss on draft-ietf-trill-directory-assist-mechanisms-11: (with DISCUSS)

Alexey Melnikov <aamelnikov@fastmail.fm> Thu, 19 January 2017 09:39 UTC

Return-Path: <aamelnikov@fastmail.fm>
X-Original-To: trill@ietfa.amsl.com
Delivered-To: trill@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7F218127ABE; Thu, 19 Jan 2017 01:39:04 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.72
X-Spam-Level:
X-Spam-Status: No, score=-2.72 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=fastmail.fm header.b=i1rWVLI/; dkim=pass (1024-bit key) header.d=messagingengine.com header.b=cb70xgFN
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 8tu6X1n8F2Nc; Thu, 19 Jan 2017 01:39:02 -0800 (PST)
Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 485E4128B38; Thu, 19 Jan 2017 01:39:02 -0800 (PST)
Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailout.nyi.internal (Postfix) with ESMTP id AA61420875; Thu, 19 Jan 2017 04:39:01 -0500 (EST)
Received: from frontend2 ([10.202.2.161]) by compute7.internal (MEProxy); Thu, 19 Jan 2017 04:39:01 -0500
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=fastmail.fm; h=cc :content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-sender :x-me-sender:x-sasl-enc:x-sasl-enc; s=mesmtp; bh=9v1olWQcsxK4YWs JdgcLZk7uoGE=; b=i1rWVLI/WShxbTe485hym6J5gjEBsD+yIwAfMOBNiF2HIv+ bWwqqE65zpNpHzEgxVu9BMck+O4Ih4vRhg6FEYfZj1iApU4m093K/R2wCjHbweBN yfm6csbqGsgALFlhgVhvM7jp/uWaPq/axZVEJIAFvTTzoaPHk2NFfXmT0070=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc:x-sasl-enc; s= smtpout; bh=9v1olWQcsxK4YWsJdgcLZk7uoGE=; b=cb70xgFNyMg8/QER1qOk Je/mn3pCu03Vt/AwH+c5UqtPVzFAAbgUWB90mwJI7bUiA5ghjalKW7fyvunPXaZI jDnGwudJH/BRVSPhbjshOhmjI4Fn9Hn35ToA8sjQcEN5x5Y8z4neMBJTdsNqu7rO 0kMDrMwcaAgmDmm+n2Ru3WI=
X-ME-Sender: <xms:NYmAWDd6bQJ4eUR8mBkns_tXMN87KwGqsV0eJjVFCHu0KQBec0pRpA>
X-Sasl-enc: sIkLpf4/XXJfgeo0K0KwJbmXhmRdFJ207ilmuBvGc7pj 1484818741
Received: from [10.232.42.151] (unknown [185.69.144.232]) by mail.messagingengine.com (Postfix) with ESMTPA id 4CD5E2475F; Thu, 19 Jan 2017 04:39:01 -0500 (EST)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (1.0)
From: Alexey Melnikov <aamelnikov@fastmail.fm>
X-Mailer: iPhone Mail (13G35)
In-Reply-To: <CAF4+nEGP9+3kq7J3Zs1EfNJ+cP8ZCbSg5Vuc+0zvxNbrCSNJtA@mail.gmail.com>
Date: Thu, 19 Jan 2017 09:48:48 +0000
Content-Transfer-Encoding: quoted-printable
Message-Id: <09692183-AC90-4862-8EA9-86A176C69EF8@fastmail.fm>
References: <148476684392.2033.546851999767154453.idtracker@ietfa.amsl.com> <CAF4+nEGP9+3kq7J3Zs1EfNJ+cP8ZCbSg5Vuc+0zvxNbrCSNJtA@mail.gmail.com>
To: Donald Eastlake <d3e3e3@gmail.com>
Archived-At: <https://mailarchive.ietf.org/arch/msg/trill/jbe2rfA0GHz91jWiE9ABFck2xNE>
Cc: "trill-chairs@ietf.org" <trill-chairs@ietf.org>, draft-ietf-trill-directory-assist-mechanisms@ietf.org, The IESG <iesg@ietf.org>, "shares@ndzh.com" <shares@ndzh.com>, "trill@ietf.org" <trill@ietf.org>
Subject: Re: [trill] Alexey Melnikov's Discuss on draft-ietf-trill-directory-assist-mechanisms-11: (with DISCUSS)
X-BeenThere: trill@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: "Developing a hybrid router/bridge." <trill.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/trill>, <mailto:trill-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/trill/>
List-Post: <mailto:trill@ietf.org>
List-Help: <mailto:trill-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/trill>, <mailto:trill-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 19 Jan 2017 09:39:04 -0000

Hi Donald,

> On 19 Jan 2017, at 05:16, Donald Eastlake <d3e3e3@gmail.com> wrote:
> 
> Hi Alexey,
> 
>> On Wed, Jan 18, 2017 at 2:14 PM, Alexey Melnikov <aamelnikov@fastmail.fm> wrote:
>> Alexey Melnikov has entered the following ballot position for
>> draft-ietf-trill-directory-assist-mechanisms-11: Discuss
>> 
>> When responding, please keep the subject line intact and reply to all
>> email addresses included in the To and CC lines. (Feel free to cut this
>> introductory paragraph, however.)
>> 
>> ----------------------------------------------------------------------
>> DISCUSS:
>> ----------------------------------------------------------------------
>> 
>> In Section 3.1 there is a Version field. What are the condition(s) for
>> bumping this version number? What backward compatibility guaranties are
>> expected (if any)? How would version negotiation be done?
> 
> Well, I could say that the answers to all of your questions are about
> the same for this Version field as they are for the RBridge Channel
> Header version field [RFC7178], the TRILL Header version field
> [RFC6325], and many other version fields in IETF protocols but you
> probably wouldn't consider that a very good answer.
> 
> I suppose if text was being added along this lines, it should say that
> the version number must be incremented for a specification that does
> not just specify new field values where that is allowed in version
> zero but cannot be correctly parsed beyond the version nibble. Since
> the protocol is a request/response protocol, the responder should
> indicate the highest version number they understand but the response
> must be valid in the version number specified in the request including
> the possibility of indicating a valid error saying that the version is
> not implemented. Thus all implementations of version X would need to
> be able to at least send such an error for all versions from 0 through
> X-1. Then you would add an explicit suberror code in Section 3.6.3 for
> unimplemented version. For a version zero implementation, that would
> be returned for any higher version.
> 
> However, I don't expect an incremented version number to be needed
> anytime soon. Was it your intent with this DISCUSS to get something
> like the above added to the draft?

Yes, exactly along the lines of your text above.