Last Call Review of draft-ietf-softwire-unified-cpe-04

Request Review of draft-ietf-softwire-unified-cpe
Requested rev. no specific revision (document currently at 08)
Type Last Call Review
Team Ops Directorate (opsdir)
Deadline 2016-08-25
Requested 2016-08-16
Authors Mohamed Boucadair, Ian Farrer
Draft last updated 2016-08-24
Completed reviews Genart Last Call review of -04 by Paul Kyzivat (diff)
Genart Telechat review of -06 by Paul Kyzivat (diff)
Secdir Last Call review of -04 by Ólafur Guðmundsson (diff)
Opsdir Last Call review of -04 by Fred Baker (diff)
Rtgdir Early review of -04 by John Scudder (diff)
Assignment Reviewer Fred Baker 
State Completed
Review review-ietf-softwire-unified-cpe-04-opsdir-lc-baker-2016-08-24
Reviewed rev. 04 (document currently at 08)
Review result Has Nits
Review completed: 2016-08-24


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

One could argue for "MUST".

If I am misinterpreting the specification, it at least needs appropriate clarification on this point.




 Message signed with OpenPGP using GPGMail