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

[Alexey Melnikov <[e-mail]>]

Hi Donald,

> On 19 Jan 2017, at 05:16, Donald Eastlake <[e-mail]> wrote:
> 
> 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?

Yes, exactly along the lines of your text above.