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

["Spencer Dawkins" <[e-mail]>]

Hi, Jouni,

Both of these are clearer - thanks for your patience.

Spencer


> 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