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

["Bernie Volz (volz)" <[e-mail]>]

First, let me say that I'd MUCH prefer a type field over multiple
suboptions if we feel there is likely to be a need for multiple
identifiers. The reason is that with multiple suboptions, a relay would
potentially need to send more than one (in case a server didn't support
one of the newer suboptions) and it would be much more difficult to
determine which to use / which was used (from the server's / relay's
perspective).

Second, a DUID is tied to a device (at least the default DUID) but there
is nothing that says you can't configure a replacement device to use the
same DUID as the previous device - though obviously you have to be
careful to assure that the previous device no longer uses that DUID
(either because it is discarded or because it is re-initialized and
generates a new DUID, if DUID-LLT).

Third, I think if you stick with an opaque identifier, you would need to
be clear to add text that says something like a relay MUST NOT generate
this identifier nor use it until it is ADMINISTRATIVELY configured and
it is up to the administrator then to assure it is unique across the
administrative domain. There is nothing in the draft that states this.

Fourth, I think having a DUID based identifier is the best option for
most cases. If you want the industrial Ethernet environment where you
need something that is stable across devices, then add a type that
allows this administratively configured identifier. But as a general
relay identifier I would use the DUID.

So, you might define:
	Type = 1 - DUID (default type)
	Type = 2 - Opaque identifier (must only be used if
administratively configured on the device and requires administrator to
assure it is unique).

- Bernie

-----Original Message-----
From: Bharat Joshi [mailto:[e-mail]] 
Sent: Monday, June 13, 2011 2:45 AM
To: Bernie Volz (volz)
Cc: Mark Stapp (mjs); [e-mail]
Subject: RE: [dhcwg] I-D Action:
draft-ietf-dhc-relay-id-suboption-08.txt

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