Re: Gen-ART Review of draft-ietf-dhc-vpn-option-11.txt

[Kim Kinnear <kkinnear at cisco.com>]

Spencer,

Thank you for your review.  My comments
are preceded by Kim:, below.

At 06:55 PM 10/21/2009, Spencer Dawkins wrote:
>I have been selected as the General Area Review Team (Gen-ART)reviewer for
>this draft (for background on Gen-ART, please
>seehttp://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html).
>
>Please resolve these comments along with any other Last Call comments you
>may receive.
>
>Document: draft-ietf-dhc-vpn-option-11.txt
>Reviewer: Spencer Dawkins
>Review Date: 2009-10-21
>IETF LC End Date: 2009-10-16 (sorry!)
>IESG Telechat date: 2009-10-22 (double-sorry!)
>
>Summary: This draft is almost ready for publication as a Proposed Standard. I had two questions about 2119 language in section 5, as follows:
>
>5.  Relay Agent Behavior
>
>  A DHCPv4 relay agent SHOULD include a DHCPv4 VSS sub-option in a
>  relay-agent-information option [RFC3046], while a DHCPv6 relay agent
>  SHOULD include a DHCPv6 VSS option in the Relay-forward message.
>
>Spencer (minor): is this functionality supposed to work if either SHOULD is violated? I'm wondering why these are not MUSTs.

        Kim: No, the functionality described in this
        document will not work if either SHOULD is violated,
        though their may be some other way for the relay
        agent to get its needs met.  I guess that should
        be a MUST for this document, then.  I'll fix it.


>  The value placed in the Virtual Subnet Selection sub-option or option
>  SHOULD be sufficient for the relay agent to properly route any DHCP
>
>Spencer (minor): I don't think this is a 2119 SHOULD. I'm thinking "more like a statement of fact" - perhaps "will be sufficient"? If it's really 2119, why isn't it a MUST?

        Kim: The thinking here is that the relay agent
        can send everything it needs to route in the VSS option/sub-option.     
        But this was a SHOULD since it might have internal
        tables that remember state and so this might be
        a key into internal state that would allow it to
        work.  I'll clarify and fix this.

        Regards - Kim


>  reply packet returned from the DHCP server to the DHCP client for
>  which it is destined.
>