Re: Gen-ART Last Call review of draft-korhonen-mip4-service-06

["Spencer Dawkins" <spencer at wonderhamster.org>]

Hi, Jouni,

Thanks for your quick response - I'm OK with most of your proposed changes.

I should emphasize that my comments here are Last Call comments that you 
(and the document shepherd, and the AD) can decide to ignore - I'm just 
telling you what I'm seeing when I read the text.

Just to finish up:

> >  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 restrict
> >  simultaneous access to other services from an 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.
> >
> > Spencer: I wasn't clear on who this understanding is directed to - it 
> > almost reads like you're warning users that bad things might happen if 
> > you use a specific service, but surely the user specifies the service 
> > because an operator requires this?
>
> We had this discussion earlier on RFC5149.. and concerns were raised
> whether the Service Selection is a potential tool for enabling walled
> gardens etc. Thus this note here was added to emphasize that point.

I understand your point from your explanation, but can't get that 
understanding from the draft text. If you said

s/from a user point of view/from a user point of view (for example, a 
"walled garden")/

that would be as clear as your explanation.

> > 3.  Service Selection Extension
> >
> >  At most one Service Selection extension MAY be included in any Mobile
> >  IPv4 Registration Request message.  It SHOULD be included at least in
> >
> > Spencer: seems to be missing a qualifier: "When a non-default service is 
> > selected, the Service Selection extension SHOULD be included ..."?
> >
> > Spencer: If this is qualified, could the SHOULD be a MUST?
>
> Hmm.. right. New text would be:
>
>   At most one Service Selection extension MAY be included in any Mobile
>   IPv4 Registration Request message.  When a non-default service is 
> selected,
>   the Service Selection extension SHOULD be included at least in
>   the Registration Request message that is sent for the initial binding
>   registration when the mobile node and the home agent do not have an
>   existing binding.  The Service Selection extension MUST be placed in
>   the Registration Request message as follows:
>
> > Spencer: If it remains as SHOULD, what happens if the Service Selection 
> > extension is not included in the initial binding registration, but is 
> > included in subsequent binding registrations?
>
> The first RRQ would be treated as the selection of the "default
> service". The subsequent RRQs with the service selection would cause
> reauthorization & evaluation of the requested service. If the newly
> requested service conflicts with the "default service" from the HA
> point of view, then an appropriate error is returned and the binding
> is dropped.

I'm still confused by

> When a non-default service is selected,
>   the Service Selection extension SHOULD be included at least in
>   the Registration Request message that is sent for the initial binding
>   registration when the mobile node and the home agent do not have an
>   existing binding.

My understanding from your explanation is that, by definition, if you don't 
include the Service Selection extension, you aren't selecting a non-default 
service until you DO send an RRQ that includes the Service Selection 
extension - right? If I'm tracking you, you're talking about two cases at 
the same time - what happens if you DO include the extension in the first 
RRQ, and what happens if you DON'T include the extension in the first RRQ, 
then switch to a non-default service by including the Service Selection 
extension in a subsequent RRQ - that would be why I was confused.

I think your explanation is way clearer than the draft text - perhaps you 
could insert it into the draft text?

Thanks, and Happy New Year,

Spencer 


_______________________________________________
Ietf mailing list
Ietf at ietf.org
https://www.ietf.org/mailman/listinfo/ietf