Re: [Gen-art] Gen-ART LC Review of draft-ietf-dhc-relay-id-suboption-11

[Bharat Joshi <[e-mail]>]

Hi Ben,

        One reply in line.

        We will bring out another revision after taking care of your suggestions once we have some more review comments.

Regards,
Bharat

> Thanks for the timely response, and the background for the security
> language. 
> 
> This brings up one question, however. See inline: 
> 
> Thanks!
> 
> Ben.
> 
> On Dec 21, 2012, at 6:48 AM, RAMAKRISHNADTV <[e-mail]>
> wrote:
> 
> > Hi Ben,
> > 
> > Thank you for your review comments.
> > Please find my responses inline below.
> > 
> > Regards,
> > Ramakrishna DTV.
> > 
> >> -----Original Message-----
> >> From: Ben Campbell [mailto:[e-mail]]
> >> Sent: Thursday, December 20, 2012 2:45 AM
> >> To: [e-mail]
> >> Cc: [e-mail] Review Team; [e-mail] 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.
> 
> Is the SHOULD use 4030 language a new normative requirement, or is it
> simply describing existing requirements from 3046 or elsewhere?  If it's
> a new normative requirement, then I am fine with your answer and
> withdraw the concern. If not, then it would be better to use descriptive
> rather than normative language in this draft.
> 

Yes.

Also as mentioned by Ted, this draft is using a language similar to some existing RFCs.
**************** 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***