Subject: [Mipshop] Review of draft-das-mipshop-andsf-dhcp-options-02

From: "Devarapalli, Vijay" <[email-masked]>
Date: Tue, 16 Feb 2010 18:06:11 -0600

Hello,

I reviewed draft-das-mipshop-andsf-dhcp-options-02 and have a few minor
comments. Once the new version is submitted, I will forward the document to
the IESG.

Apologies for the delay in reviewing it.

> Abstract 
>     
>    This document defines new Dynamic Host Configuration Protocol
>    (DHCPv4 and DHCPv6) options that contain a list IP addresses and a
>    list of domain names that can be mapped to ANDSF (Access Network
>    Discovery and Selection Function) entities in an IP network. ANDSF
>    is being developed in 3GPP (Release-8) and provides inter-system
>    mobility policies and access network specific information to the
>    mobile nodes(MNs) [3GPPTS23.402].

Rephrase as

  This document defines new Dynamic Host Configuration Protocol
  (DHCPv4 and DHCPv6) options to enable a mobile node to discover
  Access Network Discovery and Selection Function (ANDSF) entities
  in an IP network. ANDSF is being developed in 3GPP and is used to
  provide inter-system mobility policies and access network
  specific information to the mobile nodes(MNs).  ANDSF is specified
  in [3GPPTS23.402].

I removed the reference to release 8, because I assume ANDSF is useful for
subsequent 3GPP releases too.

>  (2) Terminology and abbreviations used in this document
>     
>    ANDSF (Access Network Discovery and Selection Function): An entity
>    that contains data management and control functionality and provides
>    necessary network discovery and selection assistance data to the
>    user entity (UE) as per operator policy [3GPP TS 23.402].

What does "data management" mean? Can't you just say it is a server that
provides network discovery and selection assistance.
     
>    Access Network: A network that is accessed by the user entity(UE)
> 
>    3GPP Network : Third Generation Partnership Project specified network

Re-phrase as

  3GPP Network : A radio access network specified by 3GPP standards
  organization.

>    Non-3GPP Network: Network that is not specified by 3GPP network
>    (e.g., CDMA network)

Re-write as

  Non-3GPP Network : A radio access network specified outside 3GPP by
  other standards organizations.

> 1. Introduction 
> 
>     Access Network Discovery and Selection Function (ANDSF) is being
>     defined in 3GPP (Release-8) to provide necessary network discovery
>     and selection assistance data to the mobile nodes for multi-access
>    network scenarios where 3GPP access-network level solutions are not
>    sufficient for the mobile nodes to perform network discovery and
>    selection of non-3GPP networks[3GPPTS23.402].
> 
>    The information provided by ANDSF contains inter-system mobility
>    policies and access network specific data to assist the mobile
>    node with performing the inter-system handover. This set of
>    information can either be provisioned in the mobile node by the
>    home operator, or provided to the mobile node (MN) by the ANDSF
>    over the S14 reference point as defined in [3GPPTS23.402].

You should insert the word "dynamically" when you say provided to the mobile
node by the ANDSF function.

>    In 3GPP release-8, the ANDSF is located in the subscriber's home

Why mention release 8 so many times. This would be applicable to release 9
and 10 also, right? :)

>    operator network and needs to be known to the MN or discovered by
>    the MN. According to [3GPPTS23.402] the ANDSF is discovered through
>    interaction with the Domain Name Service function or the DHCP Server
>    function. 
> 
>    This document defines new DHCPv4 and DHCPv6 options called the ANDSF
>    IP Address Option and ANDSF Domain List Option, which allow the MN to
>    locate an ANDSF Server that hosts the desired service as required
>    by 3GPP.  

Re-write as 

   This document defines new DHCPv4 and DHCPv6 options called the ANDSF
   IP Address Option and ANDSF Domain List Option, which allow the MN to
   locate an ANDSF Server.

> 2. ANDSF IPv4 Address Option for DHCPv4
>     
>    This section describes the ANDSF IPv4 Address Option for DHCPv4.
>    The Option begins with an option code followed by a length and one
>    or more IP addresses. The value of the length octet does not
>    include itself or the option code.

Delete the sentence on the value of the length field. It is mentioned below.
It would be avoid describing it two places.

> 
>      0  1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
>                                      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>                                      | Option Code   |    Length     |
>      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>      |                     IP Address                                |
>      .                                                               .
>      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>      
>  
>          Option Code
>     
>                 OPTION-IPv4_Address-ANDSF(To Be Assigned) - 1 byte
>     
>          Length 
>         
>                 An 8-bit field indicating the length of the option
>                 excluding the 'Option Code' and the 'Length' fields
> 
>    When the total length of an ANDSF IPv4 Address Option exceeds 254
>    octets, the procedure outlined in [RFC3396] MUST be employed to
>    split the option into multiple, smaller options.

254 bytes is a lot. Would you ever return 63 IPv4 addresses for ANDSF
servers? Wouldn't it better to say just truncate the option to include a max
of just 63 IPv4 addresses, instead of recommending splitting the option into
multiple options?

> 3. ANDSF Domain Name List Option for DHCPv4
>     
>    This section describes the ANDSF Domain Name List Option for DHCPv4.
>    The general format of this option is depicted below:

Remove the word "general" from the above sentence.
 
> 6.1.1 Mobile Node behavior
>     
>    The mobile node may perform an ANDSF discovery procedure either

Rephrase as

  The mobile node performs ANDSF discovery procedure either...

>   6.2.1 Mobile node behavior
>     
>    The mobile node may perform an ANDSF discovery procedure

Same as above.

>    either during initial association with a network or when the policy
>    and access network information is required from ANDSF. It may also
>    try to perform the ANDSF discovery when the network information is
>    outdated or mobile does not have any ANDSF information. MN SHOULD
>    always query for the IP address, unless the operator policy requires
>    to discover the FQDN, in which case the MN will need to request for
>    the domain name.

This is a repeat of the paragraph in section 6.1.1. Perhaps refer to the
text ins ection 6.1.1?

---

From: Subir Das <[email-masked]>
Date: Tue, 16 Feb 2010 21:52:36 -0500

Vijay,
Thanks for your review. We will update the draft and submit another version.
Some answers inline.

_Subir

> subsequent 3GPP releases too.
    Ok.
> provides network discovery and selection assistance.
    Yes, we can. However, we used the definition that is defined in 3GPP.
>   3GPP Network : A radio access network specified by 3GPP standards
    Ok.
>   other standards organizations.
     Ok.
> node by the ANDSF function.
    Ok.
> Why mention release 8 so many times. This would be applicable to release 9
    I agree and it is time to remove the release #. When we wrote the 
draft that time there was no release-9 ANDSF:-))
>    IP Address Option and ANDSF Domain List Option, which allow the MN to
     Ok.
> It would be avoid describing it two places.
    Ok.
> of just 63 IPv4 addresses, instead of recommending splitting the option into
  I agree that it is a lot but if it does not exceed 254 bytes, it will 
not happen anyway. I am fine either way.
> Remove the word "general" from the above sentence.
    Ok.
>   The mobile node performs ANDSF discovery procedure either...
    Ok
>>    The mobile node may perform an ANDSF discovery procedure
    Ok.
> This is a repeat of the paragraph in section 6.1.1. Perhaps refer to the
    Fine. We wanted to make it self contained.

---

From: "Devarapalli, Vijay" <[email-masked]>
Date: Tue, 16 Feb 2010 23:27:28 -0600

Hi Subir,

>     Yes, we can. However, we used the definition that is defined in 3GPP.

But the sentence as it reads now doesn't seem to make sense. Don't know what
"data management" is. I am sure 3GPP won't mind if we simplify the
terminology in the internet draft. :)

> not happen anyway. I am fine either way.

Lets remove it then. It is unlikely you would ever return that many IPv4
addresses.

Can you submit a new version in the next couple of days?

Vijayu

---

From: Jouni <[email-masked]>
Date: Wed, 17 Feb 2010 08:41:08 +0200

Hi,

While we are at this, I got some very late comments.

In a request (both DHCPv4 and DHCPv6), why the client has to include the ANDSF address & domain options in the request? If those are going to be only hints, then I would suggest using Parameter Request List (v4) and Option Request (v6) options. Less impact to the server.

If there is a particular reason to include the actual options in the requests, what goes inside those options in that case? You need to say something about that, at least to get the lengths right and some idea for the server what to do with the received values.

In DHCPv6 case, is the ADNSF discovery meant to take place during the normal address configuration phase, during the information-request exchange or either one? State that and the messages these options are actually applicable. A chart like inRFC3315 Appendix A would definitely make the document less ambiguous.

Last the intended status. Really a proposed standard?

- Jouni

On Feb 17, 2010, at 2:06 AM, Devarapalli, Vijay wrote:

> _______________________________________________
> Mipshop mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mipshop

---

From: Subir Das <[email-masked]>
Date: Wed, 17 Feb 2010 08:02:03 -0500

Ok.
    Ok
> Can you submit a new version in the next couple of days?
    I will do it this week.

---

From: "Devarapalli, Vijay" <[email-masked]>
Date: Wed, 17 Feb 2010 09:07:03 -0600

Hi Jouni,

> Last the intended status. Really a proposed standard?

Why not? We are allocating new DHCP options. Is your concern that this isn't
a WG document? AD-sponsored documents can be Proposed Standards too.

Vijay

---

From: Subir Das <[email-masked]>
Date: Wed, 17 Feb 2010 22:41:46 -0500

Jouni,
Thanks for your comments. Pl. see my answers inline.

regards,
-Subir

> In a request (both DHCPv4 and DHCPv6), why the client has to include the ANDSF address & domain options in the request? If those are going to be only hints, then I would suggest using Parameter Req…
    Agree and we can do it via PRL and ORO as well.
> If there is a particular reason to include the actual options in the requests, what goes inside those options in that case? You need to say something about that, at least to get the lengths right a…
    Agree.
> In DHCPv6 case, is the ADNSF discovery meant to take place during the normal address configuration phase, during the information-request exchange or either one? 
    It could be either one and we do mention it  in Section 6.2.1. If it 
is not clear, we will clarify it.
> State that and the messages these options are actually applicable. A chart like inRFC3315 Appendix A would definitely make the document less ambiguous.
>   
     We will mention the messages where these options are applicable and 
update the text as necessary. However, we may not need a table as 
informative annex.
> Last the intended status. Really a proposed standard?
     Proposed Standard.