Re: [dhcwg] [dhc] #12: Response to WG last call on draft-ietf-vpn-option (was: Response to WG last call on Draft-ietf-vpn-option)

["dhc issue tracker" <trac at tools.ietf.org>]

#12: Response to WG last call on draft-ietf-vpn-option
------------------------------+---------------------------------------------
 Reporter:  rdroms at cisco.com  |        Owner:  Bernie Volz
     Type:  defect            |       Status:  new        
 Priority:  major             |    Milestone:             
Component:  vpn-option        |      Version:             
 Severity:  In WG Last Call   |   Resolution:             
 Keywords:                    |  
------------------------------+---------------------------------------------
Changes (by rdroms at cisco.com):

  * component:  3315id-for-v4 => vpn-option


Old description:

> The following are all minor and could probably be addressed in a note to
> the IESG or even ignored:
>
> - Section 2, Terminology
> Add definition for "DHCP Proxy"?
>
> Remove "third-party" from definition of "DHCP relay agent". Also, add
> reference to RFC 3315.
>
> - Section 4, Overview of Virtual Subnet Selection Usage
> In first paragraph, for "This will affect a relay agent, in that it will
> have to ensure that the packets sent to and received from the DHCP
> client flow over the correct VPN", I wonder whether this wording implies
> more than just DHCP traffic. Technically, all a relay agent is concerned
> with is DHCP traffic. But as a relay is often on a router ....
>
> In the 2nd (full) paragraph on page 8, "in" is missing "... or a VSS
> option [in] the Relay-forward message ...".
>
> - Section 7.2, Returning the DHCPv4 Sub-Option
> In the first paragraph, understand should be understands in "... whether
> or not the DHCPv4 server understand[s] the VSS sub-option."
>
> - Section 8, Security
> The wording of "The VSS option could be used by a client in order to
> obtain an IP address from a VPN other than the one where it should." is
> a bit ackward I feel? Perhaps just state that a client's use of the
> option would allow it to obtain address(es) on any and multiple VPNs.
>
> - Section 9, IANA
> Usually this section requests what IANA should do so I'd change "IANA
> has assigned the value of TBD for the DHCPv6 VSS option defined in
> Section 3.3." to "IANA is requested to assign a value to the DHCPv6 VSS
> option defined in Section 3.3 [from the DHCPv6 option registry]."
>

> Again, all of these are extremely minor and I would like to see this
> document move forward.

New description:

 The following are all minor and could probably be addressed in a note to
 the IESG or even ignored:

 - Section 2, Terminology
 Add definition for "DHCP Proxy"?

 Remove "third-party" from definition of "DHCP relay agent". Also, add
 reference to RFC 3315.

 - Section 4, Overview of Virtual Subnet Selection Usage
 In first paragraph, for "This will affect a relay agent, in that it will
 have to ensure that the packets sent to and received from the DHCP
 client flow over the correct VPN", I wonder whether this wording implies
 more than just DHCP traffic. Technically, all a relay agent is concerned
 with is DHCP traffic. But as a relay is often on a router ....

 In the 2nd (full) paragraph on page 8, "in" is missing "... or a VSS
 option [in] the Relay-forward message ...".

 - Section 7.2, Returning the DHCPv4 Sub-Option
 In the first paragraph, understand should be understands in "... whether
 or not the DHCPv4 server understand[s] the VSS sub-option."

 - Section 8, Security
 The wording of "The VSS option could be used by a client in order to
 obtain an IP address from a VPN other than the one where it should." is
 a bit ackward I feel? Perhaps just state that a client's use of the
 option would allow it to obtain address(es) on any and multiple VPNs.

 - Section 9, IANA
 Usually this section requests what IANA should do so I'd change "IANA
 has assigned the value of TBD for the DHCPv6 VSS option defined in
 Section 3.3." to "IANA is requested to assign a value to the DHCPv6 VSS
 option defined in Section 3.3 [from the DHCPv6 option registry]."


 Again, all of these are extremely minor and I would like to see this
 document move forward.

--

-- 
Ticket URL: <http://trac.tools.ietf.org/wg/dhc/trac/ticket/12#comment:1>
dhc <http://tools.ietf.org/wg/dhc/>

_______________________________________________
dhcwg mailing list
dhcwg at ietf.org
https://www.ietf.org/mailman/listinfo/dhcwg