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@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf