Re: [Gen-art] Gen-ART review of draft-korhonen-mip4-service-07

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

Just to let people know, version -07 addresses all of my comments on -06.

Thanks,

Spencer


>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: [e-mail]
> ?)
>
> 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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/gen-art
> 


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