Hi Ben, Thank you for your review comments. Please find my responses inline below. Regards, Ramakrishna DTV. >-----Original Message----- >From: Ben Campbell [mailto:ben@xxxxxxxxxxx] >Sent: Thursday, December 20, 2012 2:45 AM >To: draft-ietf-dhc-relay-id-suboption.all@xxxxxxxxxxxxxx >Cc: gen-art@xxxxxxxx Review Team; ietf@xxxxxxxx List >Subject: Gen-ART LC Review of draft-ietf-dhc-relay-id-suboption-11 > >I am the assigned Gen-ART reviewer for this draft. For background on >Gen-ART, please see the FAQ at > ><http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>. > >Please resolve these comments along with any other Last Call comments >you may receive. > >Document: draft-ietf-dhc-relay-id-suboption-11 >Reviewer: Ben Campbell >Review Date: 2012-12-19 >IETF LC End Date: 2013-01-07 > >Summary: This draft is basically ready for publication as a proposed >standard. However, there is one comment from a prior review that I am >not sure whether is resolved. > >Major issues: > >None > >Minor issues: > >-- In Sean Turner's 2009 review of version 07 of the document [ >http://www.ietf.org/mail-archive/web/gen-art/current/msg04614.html ], he >made the following comment: > >> In the security considerations it says look to RFC 3046 and >> RFC 4030 for security considerations and then says SHOULD use the >relay >> agent authentication option from RFC 4030. RFC 3046 is targeted at >> network infrastructures that are "trusted and secure" and RFC 4030 >> allows the relay agent to be part of this trusted and secure network. >> If an implementation doesn't use the relay agent authentication >option, >> then the relay agent can't be part of the "trusted and secure" >network. RFC3046 created the relay agent information option. Relay agent information option exists only in the messages between relay agents and DHCP servers. RFC3046 is targeted at network infrastructures that are "trusted and secure" as far as the paths among relay agents and DHCP servers is concerned. In many deployments, relay agents and DHCP servers are under a single administrative control. By careful design and engineering of the network, it is possible to ensure that the network infrastructure comprising relay agents and DHCP server is trusted and secure. To achieve that, RFC4030 may be used but is not a MUST. If not, RFC4030 would already be a MUST for RFC3046 deployment. But that is not currently the case. >> This makes me think that the relay agent authentication option from >> RFC 4030 ought to be a MUST not a SHOULD? > >I can't tell from the resulting conversation if that comment is >addressed in the current text. Additional text has been added, but the >SHOULD remains. I'm willing to accept it has been addressed if the >author's say so--I only mention it to make sure it didn't fall through a >crack. > We have indeed discussed about this comment and addressed it. The following was a related comment from DHC WG Chair (Ted Lemon) (http://www.ietf.org/mail-archive/web/gen-art/current/msg04615.html): "This document makes no changes to practice that require more or less security than is provided by existing relay agent options in RFC3046. Thus, the security considerations in RFC3046 should be adequate." As Ted mentioned, our draft only proposes a new sub-option for relay-agent option which was originally created as part of RFC3046. So, the security considerations for RFC3046 apply to our draft as well. RFC3046 deployments may use RFC4030 as explained above. So, we indicated in our draft to refer to both RFC3046 and RFC4030. But there are no specific security issues in the new relay-id sub-option itself to make RFC4030 a MUST. >Nits/editorial comments: > >-- section 5, last paragraph: > >I suggest removing the scare quotes around "stability". If there are >concerns about whether such stability is real, it would be better to say >that directly. > There is no need for these scare quotes. We will remove them. >-- informative references: > >draft-ietf-dhc-dhcpv4-bulk-leasequery-06 is now 07 We will update this. > **************** CAUTION - Disclaimer ***************** This e-mail contains PRIVILEGED AND CONFIDENTIAL INFORMATION intended solely for the use of the addressee(s). If you are not the intended recipient, please notify the sender by e-mail and delete the original message. Further, you are not to copy, disclose, or distribute this e-mail or its contents to any other person and any such actions are unlawful. This e-mail may contain viruses. Infosys has taken every reasonable precaution to minimize this risk, but is not liable for any damage you may sustain as a result of any virus in this e-mail. You should carry out your own virus checks before opening the e-mail or attachment. Infosys reserves the right to monitor and review the content of all messages sent to or from this e-mail address. Messages sent to or from this e-mail address may be stored on the Infosys e-mail system. ***INFOSYS******** End of Disclaimer ********INFOSYS***