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

[Alexey Melnikov <[e-mail]>]

Hi Donald,

> On 2 Mar 2017, at 22:45, Donald Eastlake <[e-mail]> wrote:
> 
> Hi Alexey,
> 
> Version -12, just posted, is intended to resolve your DISCUSS. My
> apologies for taking so long. Could you take a look?

I cleared. Thank you for the extra text.

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