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(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf