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

Alexey Melnikov <> Thu, 19 January 2017 09:39 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 7F218127ABE; Thu, 19 Jan 2017 01:39:04 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.72
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: (amavisd-new); dkim=pass (1024-bit key) header.b=i1rWVLI/; dkim=pass (1024-bit key) header.b=cb70xgFN
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 8tu6X1n8F2Nc; Thu, 19 Jan 2017 01:39:02 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 485E4128B38; Thu, 19 Jan 2017 01:39:02 -0800 (PST)
Received: from compute7.internal (compute7.nyi.internal []) by mailout.nyi.internal (Postfix) with ESMTP id AA61420875; Thu, 19 Jan 2017 04:39:01 -0500 (EST)
Received: from frontend2 ([]) by compute7.internal (MEProxy); Thu, 19 Jan 2017 04:39:01 -0500
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed;; 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=; 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 [] (unknown []) by (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 <>
X-Mailer: iPhone Mail (13G35)
In-Reply-To: <>
Date: Thu, 19 Jan 2017 09:48:48 +0000
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <> <>
To: Donald Eastlake <>
Archived-At: <>
Cc: "" <>,, The IESG <>, "" <>, "" <>
Subject: Re: [trill] Alexey Melnikov's Discuss on draft-ietf-trill-directory-assist-mechanisms-11: (with DISCUSS)
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: "Developing a hybrid router/bridge." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 19 Jan 2017 09:39:04 -0000

Hi Donald,

> On 19 Jan 2017, at 05:16, Donald Eastlake <> wrote:
> Hi Alexey,
>> On Wed, Jan 18, 2017 at 2:14 PM, Alexey Melnikov <> 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.)
>> ----------------------------------------------------------------------
>> ----------------------------------------------------------------------
>> 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.