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

[Donald Eastlake <[e-mail]>]

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   [phone] (cell)
 155 Beaver Street, Milford, MA 01757 USA
 [e-mail]


On Thu, Jan 19, 2017 at 4:48 AM, Alexey Melnikov <[e-mail]> wrote:
> 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.
>
>