Protocol Action: 'DHCPv6 Relay Agent Remote ID Option' to Proposed Standard

[The IESG <iesg-secretary at ietf.org>]

The IESG has approved the following document:

- 'DHCPv6 Relay Agent Remote ID Option '
   <draft-ietf-dhc-dhcpv6-remoteid-01.txt> as a Proposed Standard

This document is the product of the Dynamic Host Configuration Working Group. 

The IESG contact persons are Margaret Wasserman and Mark Townsley.

A URL of this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-dhc-dhcpv6-remoteid-01.txt

Technical Summary
 
   This memo defines a new Relay Agent Remote-ID option for the Dynamic
   Host Configuration Protocol for IPv6 (DHCPv6).  This option is the
   DHCPv6 equivalent for the Dynamic Host Configuration Protocol for
   IPv4 (DHCPv4) Relay Agent Option's Remote-ID suboption as specified
   in RFC 3046.
 
Working Group Summary
 
   This document is the work of the DHC WG.  The WG has consensus to
   publish this draft as a Proposed Standard.
 
Protocol Quality
 
   This document was reviewed for the IESG by Margaret Wasserman.

Note to RFC Editor
 
In section 3:

OLD:
   This option MAY be added by DHCPv6 relay agents which terminate
   switched or permanent circuits and have mechanisms to identify the
   remote host end of the circuit.

NEW:
   This option may be added by DHCPv6 relay agents which terminate
               ^^^
   switched or permanent circuits and have mechanisms to identify the
   remote host end of the circuit.


OLD:
   The remote-id field MAY be used to encode, for instance:

NEW:
   The remote-id field may be used to encode, for instance:
                       ^^^


OLD:
   Each vendor MUST assure that the remote-id is unique for their
   enterprise-number, as the octet sequence of enterprise-number
   followed by remote-id MUST be globally unique.  One way to achieve
   uniqueness might be to include the relay agent's DUID [1] in the
   remote-id.

NEW:
   Each vendor must assure that the remote-id is unique for their
               ^^^^
   enterprise-number, as the octet sequence of enterprise-number
   followed by remote-id must be globally unique.  One way to achieve
                         ^^^^
   uniqueness might be to include the relay agent's DUID [1] in the
   remote-id.


In Section 4:

OLD:
   DHCPv6 relay agents MAY be configured to include a Remote-ID option
   in relayed (RELAY-FORW) DHCPv6 messages.

NEW:
   DHCPv6 relay agents may be configured to include a Remote-ID option
                       ^^^
   in relayed (RELAY-FORW) DHCPv6 messages.


In Section 5:

OLD: 
   This option provides additional information to the DHCPv6 server.
   The DHCPv6 server, if it is configured to support this option, MAY
   use this information to select parameters specific to particular
   users, hosts, or subscriber modems.  The combined enterprise-number
   and remote-id SHOULD be considered an opaque value, with policies
   based on exact string match only; that is, the remote-id field SHOULD
   NOT be internally parsed by the server.

NEW:
   This option provides additional information to the DHCPv6 server.
   The DHCPv6 server, if it is configured to support this option, may
                                                                  ^^^
   use this information to select parameters specific to particular
   users, hosts, or subscriber modems.  The combined enterprise-number
   and remote-id SHOULD be considered an opaque value, with policies
   based on exact string match only; that is, the remote-id field SHOULD
   NOT be internally parsed by the server.


_______________________________________________
IETF-Announce mailing list
IETF-Announce at ietf.org
https://www1.ietf.org/mailman/listinfo/ietf-announce