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

Donald Eastlake <d3e3e3@gmail.com> Thu, 02 March 2017 22:46 UTC

Return-Path: <d3e3e3@gmail.com>
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 BBB8A1293F8; Thu, 2 Mar 2017 14:46:14 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.45
X-Spam-Level:
X-Spam-Status: No, score=-2.45 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 TrcfxQMYP1cP; Thu, 2 Mar 2017 14:46:13 -0800 (PST)
Received: from mail-io0-x236.google.com (mail-io0-x236.google.com [IPv6:2607:f8b0:4001:c06::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 42E7F128E18; Thu, 2 Mar 2017 14:46:13 -0800 (PST)
Received: by mail-io0-x236.google.com with SMTP id 90so63953534ios.1; Thu, 02 Mar 2017 14:46:13 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=bzSTv6Fa8EwGWN8LrF/amfEPl35QBvVFkQbiCOPzAEs=; b=ArreKLcLVM2hruV6dpqgIy+wTog0MtL0AvzAVIcKxu4YJ/CxtsXNv8KLZ6aUe8DwA5 RNiZ8jXMltXQZZ0QA0462bSvq7OKchi3VeRqH1/4+0rpV5UD/U3PJqo8Ddn2tMsjbJoi eYBWEAnNdzTZTHId+eKmkCwQMitD+jSwMnzhwqqNjfqyqRuLtpoDU6RoqOb6QrNAl2mv 1SJdKgoHq6y/HRujjUdVAVWPK4xPLmBwzK5I8XgD1DP0PkuhNNkUqFiZq7sCLoEtxlze aKV+nAt+IjtneiDlW7E/G1TyIhq35wKAxs5VhzKVDQs3tLP23mlYjy1lzn7SGzQPkZ1s IsLw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=bzSTv6Fa8EwGWN8LrF/amfEPl35QBvVFkQbiCOPzAEs=; b=b7a7Mki2+SVczrRhWabfLqPj6sMo0LQFJglC+APmLr6uXDclk3bbvtYhbOqKkJaWpq cTtTXfOa/v55wb85u57sWvKCxT6vvlyUtVJqNnM/b73Qb6efL8pfbu0VWSRFcsyEteAe 8LYpDJxtOpZmrMG2vBqmcaNswA5DX7ww7dyq6YRVcjl7KkQIFFgFs3aDAemR8XXzTQzO uMuwiwXMcyiMxSjYqPOtZ6CC4YmwtmWkGPQnvmkmJh+kpDKUSM7x2oO13YccxiZbGSa8 EM+NLX4OZoh5711Xr4CoFJnJiniF22EfpmxVEKpzRPVIy6OZg/dkg6BExTt7mt+QCrjb ygNw==
X-Gm-Message-State: AMke39mzk0BUH0MTjYbChe61vZqy1uY6mWers/su+7Irjx6sIcuybrHS7WQ70PKSjTfBVX9yAAK3mr7WtexYMA==
X-Received: by 10.107.141.80 with SMTP id p77mr156591iod.97.1488494772544; Thu, 02 Mar 2017 14:46:12 -0800 (PST)
MIME-Version: 1.0
Received: by 10.107.135.215 with HTTP; Thu, 2 Mar 2017 14:45:56 -0800 (PST)
In-Reply-To: <09692183-AC90-4862-8EA9-86A176C69EF8@fastmail.fm>
References: <148476684392.2033.546851999767154453.idtracker@ietfa.amsl.com> <CAF4+nEGP9+3kq7J3Zs1EfNJ+cP8ZCbSg5Vuc+0zvxNbrCSNJtA@mail.gmail.com> <09692183-AC90-4862-8EA9-86A176C69EF8@fastmail.fm>
From: Donald Eastlake <d3e3e3@gmail.com>
Date: Thu, 2 Mar 2017 17:45:56 -0500
Message-ID: <CAF4+nEFkbsoYah_wm1F3eKQXyVvEuNcFMeoeWiMpTyKgNNHneg@mail.gmail.com>
To: Alexey Melnikov <aamelnikov@fastmail.fm>
Content-Type: text/plain; charset=UTF-8
Archived-At: <https://mailarchive.ietf.org/arch/msg/trill/_zOOtypLDFP6rnQtRLvDbPk7Zmo>
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, 02 Mar 2017 22:46:15 -0000

Hi Alexey,

Version -12, just posted, is intended to resolve your DISCUSS. My
apologies for taking so long. Could you take a look?

Thanks,
Donald
===============================
 Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
 155 Beaver Street, Milford, MA 01757 USA
 d3e3e3@gmail.com


On Thu, Jan 19, 2017 at 4:48 AM, Alexey Melnikov <aamelnikov@fastmail.fm> wrote:
> 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.
>
>