Re: [dhcwg] I-D Action: draft-ietf-dhc-relay-id-suboption-08.txt

[Bharat Joshi <[e-mail]>]

Hi Bernie,

     Thanks a lot for the quick review. Please see my response in line.

Regards,
Bharat

>Hi ... I've decided to add the DHC WG as this is a document being worked
> on there.

Yes. No issues.

> Personally, I'd switch section 3.1 and 3.2 (bulk LQ is a much stronger
> argument for this). 

That make sense. I can surely do this in next revision.

> And, I doubt the IESG will be happy with this document and leaving the
> actual identifier as completely opaque!  How would this identifying data
> be assured to be unique if it is just defined as a 'series of octets'?

The draft suggest that this opaque identifier be administratively configured and there should be a mean to display this to the administrator. So we expect administrator to be able to take care of keeping it unique in their own administrative domain.

> I also fail to see why the DUID isn't being recommended as the standard
> format for this relay identifier? See RFC 5460 section 5.4,
> OPTION_RELAY_ID.

The previous version of this draft had suggested the use of DUID. But we had to remove it because our use cases required that same relay-id be used even if the device is replaced.

> And, thus do we really need a type field in the option? Isn't just a
> DUID sufficient?

That 'type' field was kept from the previous revision, for the future extensibility. At present, we feel that an opaque relay-id fulfils works for our use-cases but in future that may be other use-cases which might want to use a different type of relay-id.

In fact, Ted and Pavan had a similar comments. If most of the people feel that we can define a new sub-option when such a requirements comes, we can remove this 'type' field.

> I'd also say that for "compatibility" with DHCPv6, using the DUID as the
> relay identifier too would be really convenient and appropriate. This
> also means section 6 can probably be significantly scaled back - the
> only issue is the unicast RENEW.

I am not sure if using DUID for the use-cases mentioned in this draft will be appropriate. 

We had to come out with this new revision because it was pointed out that DUID cannot be used where same id is required even when the devices are replaced.

Once we decide upon whether we can use DUID or not, we can discuss other points which you have raised here.
**************** 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***