RE: Gen-ART LC Review of draft-ietf-dhc-relay-id-suboption-11

[RAMAKRISHNADTV <[e-mail]>]

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.

>>  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***