Last Call Review of draft-ietf-dhc-access-network-identifier-08
review-ietf-dhc-access-network-identifier-08-opsdir-lc-morton-2015-05-28-00

Request Review of draft-ietf-dhc-access-network-identifier
Requested rev. no specific revision (document currently at 13)
Type Last Call Review
Team Ops Directorate (opsdir)
Deadline 2015-06-09
Requested 2015-05-28
Authors Shwetha Bhandari, Sri Gundavelli, Mark Grayson, Bernie Volz, Jouni Korhonen
Draft last updated 2015-05-28
Completed reviews Genart Last Call review of -08 by Francis Dupont (diff)
Genart Telechat review of -10 by Francis Dupont (diff)
Secdir Last Call review of -08 by Catherine Meadows (diff)
Opsdir Last Call review of -08 by Al Morton (diff)
Assignment Reviewer Al Morton
State Completed
Review review-ietf-dhc-access-network-identifier-08-opsdir-lc-morton-2015-05-28
Reviewed rev. 08 (document currently at 13)
Review result Has Issues
Review completed: 2015-05-28

Review
review-ietf-dhc-access-network-identifier-08-opsdir-lc-morton-2015-05-28

Authors, OPS-DIR,

I have reviewed "Access Network Identifier Option in DHCP"
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.

State: >Mostly Ready, please consider the comment below<

Despite having some exposure to both, iana PMIPv6 or DHCP expert
and so this is a high-level review.

This draft specifies the optional capability in DHCP to identify
access network ID and operator ID for the possible application of policy
on operator-specific handling, traffic management, or differentiated
services. Often these are carefully planned and controlled networking
capabilities, so some form of ID integrity protection would be welcome.
Thus, it's worrisome when the authors remind us in the Security 
Considerations section (9):

   ...DHCP itself is inherently unsecure and
   thus link-layer confidentiality and integrity protection should be
   employed to reduce the risk of disclosure and tampering.

maybe  s/should/SHOULD/ ? or stronger?  Other solutions or explanation welcome.

regards,
Al