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

["Sri Gundavelli (sgundave)" <[e-mail]>]

Hi Brian,

Thanks for the review. Please see inline.




From: "Shwetha Bhandari (shwethab)" <[e-mail]<mailto:[e-mail]>>
Date: Friday, May 8, 2015 at 10:09 PM
To: Sri Gundavelli <[e-mail]<mailto:[e-mail]>>, Jouni Korhonen <[e-mail]<mailto:[e-mail]>>, "Bernie Volz (volz)" <[e-mail]<mailto:[e-mail]>>, "Mark Grayson (mgrayson)" <[e-mail]<mailto:[e-mail]>>
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" <[e-mail]<mailto:[e-mail]>> 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