Thanks Jouni, comments in line.
On 2007-11-01 23:53, [EMAIL PROTECTED] wrote:
Hi Brian,
Thanks for the review! I have included answers & comments to
your comments below:
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?
The default case does not need to include the option. In that case
whatever
the HA understands as a default behavior & connectivity gets applied.
What
about rephrasing:
The Service Selection mobility option MAY be included in any Binding
Update message. 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
when present MUST appear before any mobility message authorization or
authentication related options.
OK for me.
(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.
Yes. See above.
OK for me.
...
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?
The intention is that only one dedicated service per mobile ip tunnel
is allowed. This is because the selected service may affect the
allocation of the home address & home network prefix and thus the
routing in the HA. For each mobile ip tunnel we can assign only one
address / prefix.
If we were only after different QoS treatment or filtering of packets
then multiple options could probably be allowed.
The draft should say something about the number of service selection
options in the binding update. I would go for maximum one. At least
that was my original idea.
OK, then I think you should state this clearly. I assume a service
provider could offer overlapping bundles of services, like bundles
of cable channels ;-)
...
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) ?
There are deployment scenarios where correspondent nodes are within the
same administrative domain as the home agent. Then it is feasible and
possible that correspondent nodes do understand service selection
option and do different treatment of traffic based on that. So, In mu
opinion both MUST and MUST NOT would be too strong.
I think that needs to be explained then - at the moment the text is
a little contradictory.
(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.
Yes.
(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.
Well.. that is of course possible if some operator wants to do so.
Right, and I'm not saying the IETF can forbid this. I think it's
something the IETF should be aware that it's allowing, however.
So excuse me if I forward this part of my review as a public
Last Call comment. I *do* appreciate this:
o In absence of a specifically indicated service 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 subscribers, but it is highly
RECOMMENDED in order to avoid having normal subscribers employ
operator-specific configuration values in order to get basic
service.
Regards
Brian
Cheers,
Jouni
-----Original Message-----
From: Brian E Carpenter [mailto:[EMAIL PROTECTED]
Sent: Thursday, November 01, 2007 3:23 AM
To: General Area Review Team
Cc: Korhonen, Jouni /TeliaSonera Finland Oyj; Nilsson, Ulf
S.; [EMAIL PROTECTED]; Jari Arkko
Subject: Gen-ART LC review of draft-korhonen-mip6-service-04.txt
_______________________________________________
Gen-art mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/gen-art
