[dhcwg] Updated draft-ietf-dhc-dhcpv6-subid-01.txt

["Bernie Volz \(volz\)" <[e-mail]>]

Hello:

I have just submitted
ftp://ftpeng.cisco.com/volz/draft-ietf-dhc-dhcpv6-subid-01.txt to
hopefully address the IESG discuss items
(https://datatracker.ietf.org/public/pidtracker.cgi?command=print_ballot
&ballot_id=1836&filename=draft-ietf-dhc-dhcpv6-subid).

The differences of significance from the -00 draft are below.

- Bernie

---
 
-   The subscriber-id is an NVT ASCII [4] string.  The semantic contents
-   of the subscriber-id field are of course provider-specific.  This
-   specification does not establish any semantic requirements on the
-   data in the string.
+   The subscriber-id information is only intended for use within a
+   single administrative domain and is only exchanged between the relay
+   agents and DHCPv6 servers within that domain.  Therefore, the format
+   of and encoding of the data in the option is not standardized and
+   this specification does not establish any semantic requirements on
+   the data.  This specification only defines the option for conveying
+   this information from relay agents to DHCPv6 servers.
+
+   However, as the DHCPv4 Subscriber-ID suboption [4] specifies NVT
+   ASCII [5] encoded data, in environments where both DHCPv4 [6] and
+   DHCPv6 are being used, it MAY be beneficial to use that encoding.
 
---
 
-         subscriber-id    A NVT ASCII string. It MUST NOT be null
-                          terminated.
+         subscriber-id    The subscriber's identity.
 
---

 4.  DHCPv6 Relay Agent Behavior
 
    DHCPv6 relay agents MAY be configured to include a Subscriber-ID
-   option in relayed (RELAY-FORW) DHCPv6 messages.  The subscriber-id
-   strings themselves are assigned and configured through mechanisms
-   that are outside the scope of this memo.
+   option in relayed (RELAY-FORW) DHCPv6 messages.  How the
+   subscriber-id is assigned and the mechanisms used to configure it
are
+   outside the scope of this memo.
+
 
 5.  DHCPv6 Server Behavior
 
    This option provides additional information to the DHCPv6 server.
-   The DHCPv6 server, if it is configured to support this option, MAY
-   use this information in addition to other relay agent option data,
-   other options included in the DHCPv6 client messages, and physical
-   network topology information in order to assign IP addresses,
-   delegate prefixes, and/or other configuration parameters to the
-   client.  There is no special additional processing for this option.
+   The DHCPv6 server MAY use this information, if available, in
addition
+   to other relay agent option data, other options included in the
+   DHCPv6 client messages, and physical network topology information in
+   order to assign IP addresses, delegate prefixes, and/or other
+   configuration parameters to the client.  There is no special

--- 
6.  Security Considerations
 
-   See [1] section 21.1, on securing DHCPv6 messages sent between
-   servers and relay agents, and section 23, on general DHCPv6 security
-   considerations.
+   As the subscriber-id option is only exchanged between relay agents
+   and DHCPv6 servers, [1] section 21.1, provides details on securing
+   DHCPv6 messages sent between servers and relay agents.  And, [1]
+   section 23, provides general DHCPv6 security considerations.
 
---
 
-   [4]  Postel, J. and J. Reynolds, "Telnet Protocol Specification",
-        STD 8, RFC 854, May 1983.
-
-   [5]  Johnson, R., Palaniappan, T., and M. Stapp, "Subscriber-ID
+   [4]  Johnson, R., Palaniappan, T., and M. Stapp, "Subscriber-ID
         Suboption for the Dynamic Host Configuration Protocol (DHCP)
         Relay Agent Option", RFC 3993, March 2005.
 
+   [5]  Postel, J. and J. Reynolds, "Telnet Protocol Specification",
+        STD 8, RFC 854, May 1983.
+
+   [6]  Droms, R., "Dynamic Host Configuration Protocol", RFC 2131,
+        March 1997.

_______________________________________________
dhcwg mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/dhcwg