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

From: "Alexey Melnikov" <[email-masked]>
Date: Wed, 18 Jan 2017 11:14:03 -0800

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

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-trill-directory-assist-mechanisms/

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

---

From: Donald Eastlake <[email-masked]>
Date: Thu, 19 Jan 2017 00:16:58 -0500

Hi Alexey,

> introductory paragraph, however.)

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?

Thanks,
Donald
===============================
 Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
 155 Beaver Street, Milford, MA 01757 USA
 [email-masked]

---

From: Alexey Melnikov <[email-masked]>
Date: Thu, 19 Jan 2017 09:48:48 +0000

Hi Donald,

> On 19 Jan 2017, at 05:16, Donald Eastlake <[email-masked]> wrote:
> 
> Hi Alexey,
> 

Yes, exactly along the lines of your text above.