ietf
[Top] [All Lists]

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

2009-10-30 12:27:07

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.


_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf

<Prev in Thread] Current Thread [Next in Thread>