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(_at_)infosys(_dot_)com>
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(_at_)nostrum(_dot_)com]
Sent: Thursday, December 20, 2012 2:45 AM
To:
draft-ietf-dhc-relay-id-suboption(_dot_)all(_at_)tools(_dot_)ietf(_dot_)org
Cc: gen-art(_at_)ietf(_dot_)org Review Team; ietf(_at_)ietf(_dot_)org 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***