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

[jouni korhonen <[e-mail]>]

Hi Spencer,


On Dec 29, 2008, at 6:13 PM, Spencer Dawkins wrote:

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

Ok. Thanks. Will add this.


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

A new try:

    At most one Service Selection extension MAY be included in any  
Mobile
    IPv4 Registration Request message.  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. In absence of a
    specifically indicated service in the Registration Request for the
    initial binding registration, the home agent MUST act as if the  
default
    service, such as plain Internet access had been requested. The  
absence
    of the Service Selection extension in a Registration Request that
    refreshes an existing binding MUST be treated as if the existing  
service
    selection is maintained. The Service Selection extension MUST be  
placed
    in the Registration Request message as follows:


Cheers,
	Jouni


>
>
> Thanks, and Happy New Year,
>
> Spencer
>

_______________________________________________
Gen-art mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/gen-art