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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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




_______________________________________________

Ietf@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf

[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]