Subject: Re: [dhcwg] AD Evaluation: draft-ietf-dhc-access-network-identifier

From: "Sri Gundavelli (sgundave)" <[email-masked]>
Date: Tue, 12 May 2015 21:21:52 +0000

Hi Brian,

Thanks for the review. Please see inline.

From: "Shwetha Bhandari (shwethab)" <[email-masked]<mailto:[email-masked]>>
Date: Friday, May 8, 2015 at 10:09 PM
To: Sri Gundavelli <[email-masked]<mailto:[email-masked]>>, Jouni Korhonen <[email-masked]<mailto:[email-masked]>>, "Bernie Volz (volz)" <[email-masked]<mailto:[email-masked]>>, "Mark Grayson (mgrayson)" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [dhcwg] AD Evaluation: draft-ietf-dhc-access-network-identifier

Hi All,

To address  Brian's comments as part of AD eval, please find my comments inline, and suggest how we should move forward:

* This document references RFC 6021, but 6021 has been obsoleted by 6991.
[Done]

[Authors] OK

* Section 4.3.1 says that the SSID MUST be provided if the access
technology is 802.11.  However, it is not as strict when the access
technology is 3GPP or 3GPP2.  Should those access technologies also use
MUST-level requirements on the value?  Would it be useful to identify
the acceptable values in this option for all access technologies listed
here?

http://www.iana.org/assignments/mobility-parameters/mobility-parameters.xhtml#mobility-parameters-10

[Authors]

The below text should include all the dominant access technology types.

3GPP —> GERAN, UTRAN, E-UTRAN,
3GPP2 —> 1xRTT, HRPD, eHRPD
Wi-Fi —> 802.11a/b/g/n

OLD:
      The type of the Network Name is dependent on the access technology
      to which the mobile node is attached.  If it is 802.11 access, the
      Network Name MUST be the SSID of the network.  If the access
      network is 3GPP access, the Network Name is the PLMN Identifier of
      the network.  If the access network is 3GPP2 access, the Network
      Name is the Access Network Identifier [ANI].

NEW:
      The type of the Network Name is dependent on the access technology
      to which the mobile node is attached.  For IEEE 802.11 based networks,
      the network name will be the SSID of the network. For 3GPP access based
      it is the PLMN Identifier of the access network and for 3GPP2 access, the
      Network Name is the Access Network Identifier [ANI].

* Section 4.4.1 (and 5.3.1) provide an option for conveying the
Operator's Vendor ID.  Where does this Vendor ID come from?  Is there a
stable reference for Vendor IDs in this context?

[Authors] We can add the following reference to  PEN.

   [SMI]      IANA, "PRIVATE ENTERPRISE NUMBERS", SMI Network Management
              Private Enterprise Codes,
              <http://www.iana.org/assignments/enterprise-numbers>.

We can borrow some text from the PMIP ANI RFC, RFC 6757. Also, we need to keep this format consistent with RFC6757

OLD:

Length
      4.

  Operator Enterprise ID (4-Octets)
      The operator's Vendor ID.

NEW:

  Length
          Variable

           Operator-Identifier as a variable-length Private Enterprise
           Number (PEN) [SMI] encoded in a network-byte order.  The
           maximum PEN value depends on the ANI Length and is calculated
           using the formula: maximum PEN = 2^((ANI_length-1)*8)-1.  For
           example, the ANI Length of 4 allows for encoding PENs from 0
           to 2^24-1, i.e., from 0 to 16777215, and uses 3 octets of
           Operator-Identifier space.

* Section 4.4.2 (and 5.3.2) provide the Realm, but there is no
discussion of what Realm means.  Adding some context would be useful.

[Authors] Its just a domain name. We can provide an example

OLD:

   Operator Realm
      Realm of the operator.  Realm names are required to be unique, and
      are piggybacked on the administration of the DNS namespace.
      Realms are encoded using a domain name encoding defined in
      [RFC1035].

NEW

   Operator Realm
      Realm of the operator (Ex: @EXAMPLE.COM).  Realm names are required to be unique, and
      are piggybacked on the administration of the DNS namespace.
      Realms are encoded using a domain name encoding defined in
      [RFC1035].

* Given the Motivation and Security Considerations sections, is there
really a deployment model where these options should be inserted by the
DHCP client?  It seems to me that the client really isn't in a position
to know if/when this option should be included in its DHCP message.

[Authors] It is true, its mostly the network provided information. There was working group discussion on this and there was suggestion to allow the client report these options, however with the ability for the network to override it.

On 4/13/15, 8:07 AM, "Brian Haberman" <[email-masked]<mailto:[email-masked]>> wrote:

All,
     I have completed my AD Evaluation of
draft-ietf-dhc-access-network-identifier as a part of the publication
process.  This is a well-written document and I only have a few
comments/questions on it.  Once these are resolved, the document can
continue through the publication process...

* This document references RFC 6021, but 6021 has been obsoleted by 6991.

* Section 4.3.1 says that the SSID MUST be provided if the access
technology is 802.11.  However, it is not as strict when the access
technology is 3GPP or 3GPP2.  Should those access technologies also use
MUST-level requirements on the value?  Would it be useful to identify
the acceptable values in this option for all access technologies listed
here?

http://www.iana.org/assignments/mobility-parameters/mobility-parameters.xhtml#mobility-parameters-10

* Section 4.4.1 (and 5.3.1) provide an option for conveying the
Operator's Vendor ID.  Where does this Vendor ID come from?  Is there a
stable reference for Vendor IDs in this context?

* Section 4.4.2 (and 5.3.2) provide the Realm, but there is no
discussion of what Realm means.  Adding some context would be useful.

* Given the Motivation and Security Considerations sections, is there
really a deployment model where these options should be inserted by the
DHCP client?  It seems to me that the client really isn't in a position
to know if/when this option should be included in its DHCP message.

Regards,
Brian

---

From: Brian Haberman <[email-masked]>
Date: Wed, 13 May 2015 10:24:22 -0400

Hi Sri,
     I have snipped this down to just the one place where I still have
questions/concerns...

On 5/12/15 5:21 PM, Sri Gundavelli (sgundave) wrote:
> 
> * Given the Motivation and Security Considerations sections, is
> there really a deployment model where these options should be
> inserted by the DHCP client?  It seems to me that the client really
> isn't in a position to know if/when this option should be included in
> its DHCP message.
> 
> [Authors] It is true, its mostly the network provided information.
> There was working group discussion on this and there was suggestion
> to allow the client report these options, however with the ability
> for the network to override it.
> 

Can someone point out one scenario where the DHCP client would know to
put these options in its request?  With proxy mobility as the
motivation, the client has no idea when these options are needed.  In
that case, these options are added by the relay/server when configured.
Or am I missing something?

Regards,
Brian

---

From: "Sri Gundavelli (sgundave)" <[email-masked]>
Date: Wed, 13 May 2015 14:32:31 +0000

Hi Brian,

Thanks. I agree with your comment and the initial versions of the draft
did not include this scenario either.

May be Shwetha can summarize the discussion (during her presentation) that
lead to the inclusion of this scenario.

Regards
Sri