I have been selected as the General Area Review Team (Gen-ART) reviewer
for this draft (for background on Gen-ART, please see
http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html).
Please resolve these comments along with any other Last Call comments
you may receive.

Document: draft-korhonen-mip6-service-04.txt
Reviewer: Brian Carpenter
Review Date: 2007-11-01
IETF LC End Date: 2007-11-19
IESG Telechat date: (if known)
Summary: Needs clarification

Comments: 

4 points of clarity and then two general comments.

3.  Service Selection Mobility Option

   The Service Selection mobility option MAY be included in any Binding
   Update message.  It SHOULD be included at least in the Binding Update
   message that is sent for the initial binding registration when the
   mobile node and the home agent do not have an existing binding.  If
   the Binding Update message includes any authorization related options
   (such as the Binding Authorization Data option [1]) or authentication
   related options (such as the Mobility Message Authentication option
   [8]), then the Service Selection option MUST appear before any
   mobility message authorization or authentication related options.

(1) I don't understand the SHOULD. Surely the default case (we just want
basic Internet access) doesn't need this option?

(2) The final MUST could be read in two ways. Does it need clarifying thus:

   [8]), then the Service Selection option _when present_ MUST appear before any
   mobility message authorization or authentication related options.

...
   o  Identifier: A variable length UTF-8 [3] encoded service identifier
      string used to identify the requested service.

      'ims', 'voip' and 'voip.companyxyz.example.com' are valid examples
      of Service Selection option Identifiers.  At minimum the
      Identifier MUST be unique among the home agents the mobile node is
      authorized to register to.

(3) Does this mean that a mobile node can request exactly one service? Or
is it possible to send more than one Service Selection mobility option 
with different identifiers, in order to request access to several
services? If it's restricted to one service, why?

...
4.3.  Correspondent Node Considerations

   Unless the correspondent node and the home agent share the same
   knowledge about mobility services the Service Selection option is
   more or less useless information to the correspondent node.  The
   correspondent node SHOULD silently ignore the Service Selection
   option.

(4) I find the first sentence pointless. The second sentence seems to
belong earlier, just after 
   The service selection option SHOULD NOT be send to a correspondent
   node.  
Also, why aren't these MUST (NOT) ?

(5) wrt to IANA's comment in the tracker, note that RFC 3775 says
  "Future values of the Option Type can be allocated using Standards
   Action or IESG Approval [10]."
so the IESG *can* approve this as Informational.

(6) A personal comment is that this proposal specifically allows
for the creation of walled gardens in service provision. That's
something an IAB workshop warned about some years ago
(RFC 3002 section 4.2), although mainly with respect to network
provision. The community might want to consider whether there's a
deeper issue than just the technical merit of this draft.