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

[Donald Eastlake <[e-mail]>]

Hi Alexey,

On Wed, Jan 18, 2017 at 2:14 PM, Alexey Melnikov <[e-mail]> 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?

Thanks,
Donald
===============================
 Donald E. Eastlake 3rd   [phone] (cell)
 155 Beaver Street, Milford, MA 01757 USA
 [e-mail]