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