Hi Donald, > On 2 Mar 2017, at 22:45, Donald Eastlake <[email protected]> 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 +1-508-333-2270 (cell) > 155 Beaver Street, Milford, MA 01757 USA > [email protected] > > >> On Thu, Jan 19, 2017 at 4:48 AM, Alexey Melnikov <[email protected]> >> wrote: >> Hi Donald, >> >>> On 19 Jan 2017, at 05:16, Donald Eastlake <[email protected]> wrote: >>> >>> Hi Alexey, >>> >>>> On Wed, Jan 18, 2017 at 2:14 PM, Alexey Melnikov <[email protected]> >>>> 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. >> >> _______________________________________________ trill mailing list [email protected] https://www.ietf.org/mailman/listinfo/trill
