Subject: [Gen-art] RE: Gen-ART LC review of draft-korhonen-mip6-service-04.txt

From: <[email-masked]>
Date: Thu, 1 Nov 2007 11:53:39 +0100

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.

>(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.

>...
>   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.

>...
>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.

>(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.

Cheers,
	Jouni

> -----Original Message-----
> From: Brian E Carpenter [mailto:[email-masked]] 
> Sent: Thursday, November 01, 2007 3:23 AM
> To: General Area Review Team
> Cc: Korhonen, Jouni /TeliaSonera Finland Oyj; Nilsson, Ulf 
> S.; [email-masked]; Jari Arkko
> Subject: Gen-ART LC review of draft-korhonen-mip6-service-04.txt
> 
> 
> 
> 

_______________________________________________
Gen-art mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/gen-art

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 02 Nov 2007 09:34:35 +1300

Thanks Jouni, comments in line.

>    authentication related options.

OK for me.

>>   mobility message authorization or authentication related options.

OK for me.

> 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 ;-)

> 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.

> 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

---

From: Jari Arkko <[email-masked]>
Date: Thu, 01 Nov 2007 23:12:45 +0200

>       operator-specific configuration values in order to get basic

The walls are indeed something to be concerned about
(and I have yet to see that garden anywhere...)

However, it is also a fact that there is a need to provide
connectivity to a particular network (such as a corporate
network) and that providers see this as a lucrative
service for them to offer. It is also fact that different
security policies are and firewalls are needed under
different circumstances. All of these things can be
achieved today, but at a greater cost for the providers
and lesser capabilities for the mobile nodes to affect the
choices. So I think we need to provide functionality
in this space.

The statement that you quote above is in the document
due to some fairly spectacular failures of past arrangements.

I would be interested in adding similar statements
that make recommendations about how and for what
purpose service separation should occur, and what
some of the potential issues are. For instance,
my phone as currently configured works great with the,
entire Internet, but fails to work with some operator
services, because the operator decided in their great
wisdom to offer those services only in a separate network.
My phone can deal with multiple networks easily, but
its almost impossible for a non-expert to get the config
right, and even experts get them wrong in many cases --
in my case I used the config scripts from the operator
as-is, and they still got it wrong by connecting me only
to the Internet.

Jari

---

From: Vijay Devarapalli <[email-masked]>
Date: Thu, 01 Nov 2007 14:36:54 -0700

>    authentication related options.

This is ok, but we still need some text that says, if the service
selection mobility option is used, it needs to appear only in the
initial BU and not required in the BUs sent to refresh a binding.

> that was my original idea.

Do we have to say "one"? For example, it might be possible to
provide two different services on the same Mobile IP tunnel. We
could leave this up to folks who might use this option.

Vijay

---

From: <[email-masked]>
Date: Fri, 2 Nov 2007 13:38:31 +0100

> >>> (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.
> >>
> > So excuse me if I forward this part of my review as a 
> public Last Call 
> > comment. I *do* appreciate this:
> The walls are indeed something to be concerned about (and I 
> have yet to see that garden anywhere...)
> 
> network) and that providers see this as a lucrative service 
> for them to offer. It is also fact that different security 
> policies are and firewalls are needed under different 
> circumstances. All of these things can be achieved today, but 
> at a greater cost for the providers and lesser capabilities 
> for the mobile nodes to affect the choices. So I think we 
> need to provide functionality in this space.
> 
> The statement that you quote above is in the document due to 
> some fairly spectacular failures of past arrangements.
> 
> I would be interested in adding similar statements that make 
> recommendations about how and for what purpose service 
> separation should occur, and what some of the potential 
> issues are. For instance, my phone as currently configured 
> works great with the, entire Internet, but fails to work with 
> some operator services, because the operator decided in their 
> great wisdom to offer those services only in a separate network.
> My phone can deal with multiple networks easily, but its 
> almost impossible for a non-expert to get the config right, 
> and even experts get them wrong in many cases -- in my case I 
> used the config scripts from the operator as-is, and they 
> still got it wrong by connecting me only to the Internet.

Right, we are well aware of these challenges. How about
extending the text under introduction section:

   ...
   assignment policies, firewall settings, and security policies.  The
   Service Selection option should be used in every Binding Update that
   makes a new registration to the home agent.

   Some of the potential use-cases were listed earlier in this section.
   The general aim is better manageability of services and service
   provisioning from both operators and service providers point of
   view. However, it should be understood that there are potential
   deployment possibilities where selecting a certain service may
   restricts simultaneous access to other services from a user point
   of view. For example, services may be located in different
   administrative domains or external customer networks that
   practice excessive filtering of inbound and outbound traffic. 

Cheers,
	Jouni

---

From: <[email-masked]>
Date: Fri, 2 Nov 2007 13:49:01 +0100

Vijay,

> > Thanks for the review! I have included answers & comments to your 
> > comments below:
> > 
> > whatever the HA understands as a default behavior & 
> connectivity gets 
> > applied.
> > What
> > about rephrasing:
> > 
> This is ok, but we still need some text that says, if the 
> service selection mobility option is used, it needs to appear 
> only in the initial BU and not required in the BUs sent to 
> refresh a binding.

IMO Section 4.1 mobile node considerations state this 
pretty clearly. Is that enough to be there or should it
also be under the option format description?

> >> 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?
> > 
> provide two different services on the same Mobile IP tunnel. 
> We could leave this up to folks who might use this option.

Do you mean that we would allow zero or more services in a (P)BU
and then how the HA processes that is up to deployment?

Cheers,
	Jouni

---

From: Vijay Devarapalli <[email-masked]>
Date: Fri, 02 Nov 2007 11:48:54 -0700

> also be under the option format description?

I think it is sufficient.

> and then how the HA processes that is up to deployment?

I think it should be possible for the MN to use the same
Mobile IP tunnel for more than one service if both services
are hosted on the same home agent. There might not need be
an immediate need for this, but I think we should support
this from the beginning. So we should allow the mobile node
to include multiple instances of service selection options
in the same binding update.

Vijay

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 03 Nov 2007 08:39:00 +1300

...
> in the same binding update.

I would think that if you wanted to make that change, it would
need to be a WG discussion - i.e. you should take this
discussion over to the WG list.

I'm not asking for that change - I just want the draft to
be completely clear.

     Brian