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 <RAMAKRISHNADTV@xxxxxxxxxxx>
> wrote:
>
> > 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.
>
> 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***