I have reviewed this document as part of the Operational directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written with the intent of improving the operational aspects of the IETF drafts. Comments that are not addressed in last call may be included in AD reviews during the IESG review. Document editors and WG chairs should treat these comments just like any other last call comments. My assessment: ready with minor changes I think the draft is clear and straightforward. My concern has primarily to do with the possibility of someone defining a new transition mechanism at an unknown point in the future. In a perfect world, we have more than enough, but... There is a list of option codes in section 1.5. IANA (in the IANA Considerations) should be requested to create a registry and detail those values as it's initial contents. Values that are not in that list are currently considered "invalid", as in If an invalid OPTION_V6_S46_PRIORITY option is received, the client MAY proceed with configuring the provisioned S46 mechanisms as if OPTION_V6_S46_PRIORITY had not been received. As I read the specification, the addition of a new option code to the registry MAY result in older option codes being ignored by a client that implements the MAY. Something that WAS working STOPs working, and has to be debugged as subscribers contact the provider with trouble tickets. IMHO, the older option codes should continue to be accepted, and the new (or unimplemented) option ignored. I would suggest that the above be changed to If an unknown OPTION_V6_S46_PRIORITY option is received, the client SHOULD skip it and continue processing other listed options if they exist. One could argue for "MUST". If I am misinterpreting the specification, it at least needs appropriate clarification on this point. Attachment: signature.asc Description: Message signed with OpenPGP using GPGMail