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
