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

From: "Spencer Dawkins" <[email-masked]>
Date: Tue, 2 Dec 2008 15:18:56 -0600

I have been selected as the General Area Review Team (Gen-ART)
reviewer for this draft (for background on Gen-ART, please see
http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html).

Please resolve these comments along with any other Last Call comments
you may receive.

Document: draft-korhonen-mip4-service-06
Reviewer: Spencer Dawkins
Review Date: 2008-12-02
IETF LC End Date: 2008-12-24
IESG Telechat date: (not known)
Summary: This draft is on the right track for publication as Informational 
(should it be standards-track, if you're expecting this to be widely 
deployed? But I'll leave that to the IESG).

I do have comments, especially involving 2119 language.

Comments:

(Can Jouni's e-mail address really be
   Email: [email-masked]
?)

1.  Introduction

   This document describes a Service Selection Extension for Mobile IPv4
   that is intended to assist home agents to make specific service
   selections for the mobility service subscription during the
   registration procedure.  The service selection may affect home agent
   routing decisions, Home Address assignment policies, firewall
   settings, and security policies.  The Service Selection extension
   SHOULD be used in every Registration Request that makes a new
   registration to the home agent.  The Service Selection extension from
   the Registration Request MAY be echoed back in the Registration
   Reply.

Spencer: I don't usually see 2119 normative language in the introduction of 
Internet Drafts... at a minimum, these statements appear before the 
requirements key words are introduced in section 2. I THINK most of these 
requirements are restated later in the document anyway, so they could 
probably be dropped here.

   In absence of a specifically indicated service the home agent MUST
   act as if the default service, plain Internet access had been
   requested.  There is no absolute requirement that this default
   service be allowed to all subscribers, but it is highly RECOMMENDED
   in order to avoid having normal subscribers employ operator-specific
   configuration values in order to get basic service.

   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?

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?

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

   o  When present the extension MUST appear after the MN-NAI extension,
      if the MN-NAI is also present in the message

   o  If the extension was added by the mobile node to a Registration
      Request it MUST appear prior any authentication-enabling
      extensions [RFC3344][RFC4721]

Spencer (editorial): s/prior/before/ or s/prior/prior to/

   o  In the event the foreign agent adds the Service Selection
      extension to a Registration Request, the extension MUST appear
      prior to any Foreign-Home authentication-enabling extensions
      [RFC3344]

4.1.  Mobile Node Considerations

   A mobile node or its proxy representative MAY include the Service
   Selection extension into any Registration Request message.  The
   Service Selection extension can be used with any mobile node
   identification method.  The extension is used to identify the service
   to be associated with the mobility session and SHOULD only be

Spencer: this seems to be more restrictive than previous text that allowed 
the extension to be included in non-initial registration request messages...

   included into the initial Registration Request message sent to a home
   agent.  If the mobile node wishes to change the selected service, it
   is RECOMMENDED that the mobile node de-register the existing binding

Spencer: why RECOMMENDED and not REQUIRED? RECOMMENDED means that home 
agents must handle the case where the SHOULD isn't observed anyway.

   with the home agent before proceeding with a binding registration for
   a different service.  The provisioning of the service identifiers to
   the mobile node or its proxy representative is out of scope of this
   specification.

6.  IANA Considerations

   A new Mobile IPv4 skippable Extension type is required for the
   following new Extension described in Section 3.  The Extension type
   must be from the 'skippable Extension' range (128-255):

       Service Selection Extension       is set to TBD

   A new Mobile IPv4 registration denied by home agent error code is
   required.  The error code must be allocated from the 'Error Codes
   from the Home Agent' range (128-192):

       SERVICE_AUTHORIZATION_FAILED      is set to TBD

Spencer: (if you revise this draft, you probably want to use "TBD1", "TBD2", 
etc. so that it's clearer to IANA which "TBD" gets replaced with each 
allocated value) 

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

---

From: "jouni korhonen" <[email-masked]>
Date: Wed, 3 Dec 2008 08:50:13 +0200

Hi Spencer,

Thanks for the review! See some comments inline.

On Tue, Dec 2, 2008 at 11:18 PM, Spencer Dawkins
<[email-masked]> wrote:
> Summary: This draft is on the right track for publication as Informational (should it be standards-track, if you're expecting this to be widely deployed? But I'll leave that to the IESG).

I would have nothing against standards track RFC.

>  Email: [email-masked]

Yes, this is my valid gmail e-mail address ;)

> Spencer: I don't usually see 2119 normative language in the introduction of Internet Drafts... at a minimum, these statements appear before the requirements key words are introduced in section 2. I THINK most of these requirements are restated later in the document anyway, so they could probably be dropped here.

Ok, good point. I'll will remove the 2119 language from the Introduction.

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

> Spencer: seems to be missing a qualifier: "When a non-default service is selected, the Service Selection extension SHOULD be included ..."?
>

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.

> Spencer (editorial): s/prior/before/ or s/prior/prior to/

Ack.

> Spencer: this seems to be more restrictive than previous text that allowed the extension to be included in non-initial registration request messages...

Hmm.. earlier text said "..the Service Selection extension SHOULD be
included at least in the Registration Request message that is sent for
the initial binding registration.." I find these equally restricting.

> Spencer: why RECOMMENDED and not REQUIRED? RECOMMENDED means that home agents must handle the case where the SHOULD isn't observed anyway.

We wanted to leave the possibility of MNs changing the selected
service in fly without tearing down the binding (which would mean
break in the IP connectivity from MIP point of view). Depending on the
policies on the HA and the selected service, the change of the
"selected service" may not cause a change of the HoA. Since this
behavior is tied to deployment time policies and requires out of band
knowledge of the services on the MN, the general recommendation is to
bring the existing service down first.

> Spencer: (if you revise this draft, you probably want to use "TBD1", "TBD2", etc. so that it's clearer to IANA which "TBD" gets replaced with each allocated value)
>

Good point. I'll fix that.

Cheers,
      Jouni

---

From: "Spencer Dawkins" <[email-masked]>
Date: Mon, 29 Dec 2008 10:13:18 -0600

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:

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

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.

> point of view, then an appropriate error is returned and the binding

I'm still confused by

> When a non-default service is selected,
>   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

---

From: jouni korhonen <[email-masked]>
Date: Tue, 30 Dec 2008 11:28:22 +0200

Hi Spencer,

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

> 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:
>
>>> 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?
>>
> s/from a user point of view/from a user point of view (for example,  
> a "walled garden")/
>

Ok. Thanks. Will add this.

>>> Spencer: seems to be missing a qualifier: "When a non-default  
>>> service is selected, the Service Selection extension SHOULD be  
>>> included ..."?
>>>
>>> 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?
>>
> 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

---

From: "Spencer Dawkins" <[email-masked]>
Date: Tue, 30 Dec 2008 08:31:48 -0600

Hi, Jouni,

Both of these are clearer - thanks for your patience.

Spencer