Service Selection for Mobile IPv6
RFC 5149

[Ballot discuss]
Use of vanilla UTF-8 for an identifier raises canonicalization issues
that can result in interoperability problems.  Accented characters can
be encoded in a pre-composed or de-composed forms that are equivalent,
for example.

In general, I'd suggest use of NFKC from
  http://www.unicode.org/reports/tr15/
although any of the normalization forms there would be acceptable with
reason, as would SASLprep (RFC 4013) or Nameprep (RFC 3491) although the
latter two are probably less stable options.

[Ballot comment]
Section 3., paragraph 7:

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

  It would be good to explicitly mention that a maximum length is in
  effect for this field.

[Ballot comment]
The draft says Experimental while the tracker say informational. I'm fine either way but just wanted to make sure the intended things was happening.

[Ballot discuss]
There seems to be a conflict between the RFC 2119 statements in sections 3 and 4.1.

From section 3:

  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.

From Section 4.1:

  A mobile node or a Proxy Mobile IPv6 client MAY include the Service
  Selection mobility option into a Binding Update message.  The option
  is used to identify the service to be associated with the binding
  registration and SHOULD only be included into the initial Binding
  Update message sent to a home agent.

The MAY statements are consistent, but the "SHOULD be included at least"
and "SHOULD only" send an inconsistent message.  The text in 4.1 implies
that this option SHOULD NOT be used in any message other than the
initial Binding Update message sent to a home agent.

These statements need to be aligned.

[Ballot discuss]
There seems to be a conflict between the RFC 2119 statements in sections 3 and 4.1.

From section 3:

  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.

From Section 4.1:

  A mobile node or a Proxy Mobile IPv6 client MAY include the Service
  Selection mobility option into a Binding Update message.  The option
  is used to identify the service to be associated with the binding
  registration and SHOULD only be included into the initial Binding
  Update message sent to a home agent.

The MAY statements are consistent, but the "SHOULD be included at least"
and "SHOULD only" send an inconsistent message.  The text in 4.1 implies
that this option SHOULD NOT be used in any message other than the
initial Binding Update message sent to a home agent.

[Ballot discuss]
There seems to be a minor conflict between the RFC 2119 statements in sections 3 and 4.1.

From section 3:

  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.

From Section 4.1:

  A mobile node or a Proxy Mobile IPv6 client MAY include the Service
  Selection mobility option into a Binding Update message.  The option
  is used to identify the service to be associated with the binding
  registration and SHOULD only be included into the initial Binding
  Update message sent to a home agent.

The MAY statements are consistent, but the "SHOULD be included at least"
and "SHOULD only" send an inconsistent message.  The text in 4.1 implies
that this option SHOULD NOT be used in any message other than the
initial Binding Update message sent to a home agent.

IANA Last Call comments:

QUESTION: This document is requesting an assignment in a registry
that requires Standards Action, per RFC3775. Will this document
be reclassified as standards track?

If this were a standards track document, upon approval, the
IANA would make the following assignment in the "Mobile IPv6
parameters" registry located at
http://www.iana.org/assignments/mobility-parameters
sub-registry "Mobility Options"

Value | Description | Reference
----- + -----------------------------------------+ ---------
TDB | Service Selection | [RFC-korhonen-mip6-service-
04]

We understand the above to be the only IANA Action for this
document.

PROTO Write-up

(1.a) Who is the Document Shepherd for this document? Has the
Document Shepherd personally reviewed this version of the document
and, in particular, does he or she believe this version is ready
for forwarding to the IESG for publication?

No shepherd has been appointed yet.


(1.b) Has the document had adequate review both from key members of
the interested community and others? Does the Document Shepherd
have any concerns about the depth or breadth of the reviews that
have been performed?

No shepherd has been appointed yet. However, the document has
been presented in IETF meetings and comments received during the
presentation and email discussions have been addressed.


(1.c) Does the Document Shepherd have concerns that the document
needs more review from a particular or broader perspective, e.g.,
security, operational complexity, someone familiar with AAA,
internationalization or XML?

No shepherd has been appointed yet.


(1.d) Does the Document Shepherd have any specific concerns or
issues with this document that the Responsible Area Director
and/or the IESG should be aware of? For example, perhaps he or
she is uncomfortable with certain parts of the document, or has
concerns whether there really is a need for it. In any event, if
the interested community has discussed those issues and has
indicated that it still wishes to advance the document, detail
those concerns here.

No shepherd has been appointed yet.


(1.e) How solid is the consensus of the interested community behind
this document? Does it represent the strong concurrence of a few
individuals, with others being silent, or does the interested
community as a whole understand and agree with it?

The document represents a consensus with the individuals working
on the area described in the document.

(1.f) Has anyone threatened an appeal or otherwise indicated extreme
discontent? If so, please summarise the areas of conflict in
separate email messages to the Responsible Area Director. (It
should be in a separate email because this questionnaire is
entered into the ID Tracker.)

No.

(1.g) Has the Document Shepherd personally verified that the

No shepherd has been appointed yet.

document satisfies all ID nits? (See
http://www.ietf.org/ID-Checklist.html and
http://tools.ietf.org/tools/idnits/).

yes.

Boilerplate checks are not
enough; this check needs to be thorough. Has the document met all
formal review criteria it needs to, such as the MIB Doctor, media
type and URI type reviews?

Yes.

(1.h) Has the document split its references into normative and
informative?

Yes.

Are there normative references to documents that are
not ready for advancement or are otherwise in an unclear state?

No.

If such normative references exist, what is the strategy for their
completion? Are there normative references that are downward
references, as described in [RFC3967]?

No.

If so, list these downward references to support the Area Director
in the Last Call procedure for them [RFC3967].

The document has split references with no downward or dependent
references.


(1.i) Has the Document Shepherd verified that the document IANA
consideration section exists and is consistent with the body of
the document? If the document specifies protocol extensions, are
reservations requested in appropriate IANA registries? Are the
IANA registries clearly identified? If the document creates a new
registry, does it define the proposed initial contents of the
registry and an allocation procedure for future registrations?
Does it suggested a reasonable name for the new registry? See
[I-D.narten-iana-considerations-rfc2434bis]. If the document
describes an Expert Review process has Shepherd conferred with the
Responsible Area Director so that the IESG can appoint the needed
Expert during the IESG Evaluation?

No shepherd has been appointed yet.

The required IANA registry additions are clearly identified and
listed in the IANA considerations section. There is no need to
create a new registry and the document does not describe a future
Expert Review process.


(1.j) Has the Document Shepherd verified that sections of the
document that are written in a formal language, such as XML code,
BNF rules, MIB definitions, etc., validate correctly in an
automated checker?

No shepherd has been appointed yet.

The document does not contain definitions in any formal language.


(1.k) The IESG approval announcement includes a Document
Announcement Write-Up. Please provide such a Document
Announcement Writeup? Recent examples can be found in the
"Action" announcements for approved documents. The approval
announcement contains the following sections:

Technical Summary

This document describes a Service Selection Mobility Option for
both
conventional Mobile IPv6 and Proxy Mobile IPv6 that is intended to
assist home agents to make a specific service selection for the
mobility service subscription during the binding update procedure.
introduction. The service selection may affect home agent routing
decisions, Qos and policy treatment of service related IP flows in
the
home agent and also Home Address or Home Network Prefix assignment
policies.

Working Group Summary

This document is an individual submission. The document was
presented
in MIP6 WG meetings and interest raised especially from Proxy
Mobile
IPv6 deployment scenarios. The document was proposed to be a WG
work
item. However, the decision of adoption as a WG work item got
postponed
due time schedule challenges with the current MIP6 WG charter.


Document Quality

There are no publicly known implementations yet. There is certain
level of interest from 3GPP SAE work to adopt the document as a
part of their architecture.


Personnel

No shepherd has been appointed yet.
The responsible Area Director is Jari Arkko.

AD review:

Jouni asked me to AD sponsor this document. Here's
my review.

I support the extension proposed in the document,
but there are a number of issues relating to how
these values are defaulted, tight coupling to MN-NAI,
whether these options appear in the first or all
messages, and a few other things.

I expect a revised ID. I proposed text for some of the
issues that below, in some cases you need to still work
on it.

Substantial:

> >    o  In absence of the Service Selection option the home agent may
> >      provide, based on operator policies, a default service.  For
> >      example, a plain Internet access could be an operator's default
> >      mobility service.
> > 

The fact that there is no standard "default" and the proliferation
of various operator conventions and policies has caused significant
problems in GPRS and UMTS data access. I would not like to repeat
this mistake here.

One of way of avoiding this problem is to mandate that you do
have a default. Suggested edit:

OLD:
In absence of the Service Selection option the home agent may
provide, based on operator policies, a default service. For
example, a plain Internet access could be an operator's default
mobility service.
NEW:
In absence of the Service Selection option the home agent MUST
act as if the default service, plain Internet access had been
requested. There is no absolute requirement that this default service be
allowed to all customers, but it is highly RECOMMENDED in
order to avoid having normal users employ operator-specific
configuration values in order to get basic service.

> > The Service Selection option should be used in
> >    combination with the Mobile Node Identifier option during the initial
> >    Binding Update at the beginning of the mobility session.
I do not see a reason to make this MNID specific. Also, the
concept of a mobility session isn't necessarily well-defined, if
home agents can reboot, etc. Reformulated:

OLD:
The Service Selection option should be used in
combination with the Mobile Node Identifier option during the initial
Binding Update at the beginning of the mobility session.
NEW:
The Service Selection option should be used in every Binding
Update that makes a registration to the home agent.

And then you should probably add text somewhere to
talk about the case where the service id suddenly changes
and this no longer fits with the home address allocation, etc.

> >    The Service Selection mobility option can be included in any Mobile
> >    IPv6 Mobility Header message.
This is inconsistent with Section 2. I'm not sure I see a need
for this option to appear in other messages than the BU.
Please reformulate.


> >    This option MAY be included in the initial Binding Update message
> >    when registering to a home agent at the beginning of the mobility
> >    session.  The MN-NAI option SHOULD be included in the Binding Update
> >    message when the Service Selection option is used.  Sending the
> >    Service Selection option in any Binding Update message is not
> >    prohibited.

See above for tight coupling to MN-NAI option or the initial
BUs.

> > It should be noted that sending this option to
> >    correspondent nodes makes little or no sense unless the home agent
> >    and the correspondent nodes share the same knowledge of provided
> >    mobility services.
Be more specific. SHOULD NOT be sent? Presumably, depending
on what kind of service you got, you will or will be able to reach the
CNs directly. In either case, it should be OK to attempt RO.

> >    o  Identifier: A variable length service identifier string used to
> >      identify the requested service.  The Identifier string is encoded
> >      as a host name or a fully qualified domain name as defined in [4]
> >      and [5].  The Identifier MAY be resolveable by DNS.
> >
> >      'internet', 'internet.example.com', 'voip.example.com' and
> >      'voip.companyxyz.example.com' are valid examples of Service
> >      Selection option Identifier strings.  At minimum the Identifier
> >      must be unique among the home agents the mobile node is authorized
> >      to register to.
> > 

Something like "internet" would not be unique among the home
agents, if I the mobile node is allowed to use two different
operators, for instance.

Are there existing APN conventions in GPRS networks that are
based on domain names? Or are you inventing a convention here?

Another alternative might be to just say "UTF-8" and that the
value is up to a local policy. And unique within a particular
home agent.

> > The Service
> >    Selection option is intended to be used with the MN-NAI option, but
> >    it is also possible to use Home Address to identify the mobile node
> >    as defined in [1].
See above about the coupling to MN-NAI.

Editorial:

> >    Mobile IPv6 [1] has a Mobile Node Identifier option (MN-NAI) [6] that
> >    provides a flexible way to identify mobile nodes using other
> >    identifiers than IPv6 addresses.  Example of such identifier is a
> >    Network Access Identifier (NAI) [2].
There are multiple ways of identifying the mobile node, and the NAI is
just one of them. Suggested rewrite:

OLD:
Mobile IPv6 [1] has a Mobile Node Identifier option (MN-NAI) [6] that
provides a flexible way to identify mobile nodes using other
identifiers than IPv6 addresses. Example of such identifier is a
Network Access Identifier (NAI) [2].
NEW:
Mobile IPv6 [1] can identify mobile nodes in various ways, including
home addresses [1], Network Access Identifiers (NAIs) [2, 3], and
credentials suitable for IKEv2 [RFC 4877].


> > The service selection may affect home
> >    agent routing decisions and Home Address or Home Network Prefix
> >    assignment policies.
Or firewall and security policies. Suggested edit:

OLD:
The service selection may affect home
agent routing decisions and Home Address or Home Network Prefix
assignment policies.
NEW:
The service selection may affect home
agent routing decisions, Home Address or Home Network Prefix
assignment policies, firewall settings, and security policies.