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

From: [email-masked]
Date: Sat, 04 Jun 2011 10:04:24 -0700

A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Dynamic Host Configuration Working Group of the IETF.

	Title           : The DHCPv4 Relay Agent Identifier Suboption
	Author(s)       : Bharat Joshi
                          Mark Stapp
	Filename        : draft-ietf-dhc-relay-id-suboption-08.txt
	Pages           : 8
	Date            : 2011-06-04

   This draft defines a new Relay Agent Identifier suboption for the
   Dynamic Host Configuration Protocol&#39;s (DHCP) Relay Agent Information
   option.  The suboption carries a value that uniquely identifies the
   relay agent device within the administrative domain.  The value is
   typically administratively-configured in the relay agent.  The
   suboption allows a DHCP relay agent to include the identifier in the
   DHCP messages it sends.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-dhc-relay-id-suboption-08.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

This Internet-Draft can be retrieved at:
ftp://ftp.ietf.org/internet-drafts/draft-ietf-dhc-relay-id-suboption-08.txt

---

From: Bharat Joshi <[email-masked]>
Date: Sun, 5 Jun 2011 14:33:27 +0530

Hi All,

      This draft was under IESG review and a new revision was required as it had three DISCUSS points. Mark was not getting enough time to push this work. We needed this draft for Bulk Lease Query work and so we decided to help.

       Apart from the three DISCUSS position, there was a comment from Ted. Ted had suggested that the usage of DUID as relay-id as defined in this draft is not correct. DUID is typically tied down to the device and the use cases in this draft required same relay-id to be used if a relay-agent is replaced.

        In this revision, we have addressed all the DISCUSS positions. We have also removed both the relay-id type ASCII and DUID. We have introduced a new relay-id type OPAQUE. This new relay-id type can be administratively configured and is a series of octets.

        Now, as the above changes are more than minor changes, I think that it will first have to go through working-group. So I request people to review this draft ( only 5 pages ) and post their comments.

Regards,
Bharat
________________________________________
From: [email-masked] [[email-masked]] On Behalf Of [email-masked] [[email-masked]]
Sent: Saturday, June 04, 2011 10:34 PM
To: [email-masked]
Cc: [email-masked]
Subject: [dhcwg] I-D Action: draft-ietf-dhc-relay-id-suboption-08.txt

This Internet-Draft can be retrieved at:
ftp://ftp.ietf.org/internet-drafts/draft-ietf-dhc-relay-id-suboption-08.txt
_______________________________________________
dhcwg mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dhcwg

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

---

From: Pavan Kurapati <[email-masked]>
Date: Sun, 5 Jun 2011 20:31:46 +0530

Bharat,

Draft looks good. Just one minor editorial comment and one clarification
needed below.

> "DHCP typically identifies clients based on information in their
DHCP messages"

You might want to replace the first "DHCP" with DHCP server. If you do not
want to restrict to server here you may say network entity

I assume the inclusion of "type" field now is for any future consideration
of including other types like DUID? Else it seems redundant, now that we
have only 1 type in the sub-option.

Thanks,
Pavan

On Sun, Jun 5, 2011 at 2:33 PM, Bharat Joshi <[email-masked]>wrote:

> Hi All,
>
>      This draft was under IESG review and a new revision was required as it
> had three DISCUSS points. Mark was not getting enough time to push this
> work. We needed this draft for Bulk Lease Query work and so we decided to
> help.
>
>       Apart from the three DISCUSS position, there was a comment from Ted.
> Ted had suggested that the usage of DUID as relay-id as defined in this
> draft is not correct. DUID is typically tied down to the device and the use
> cases in this draft required same relay-id to be used if a relay-agent is
> replaced.
>
>        In this revision, we have addressed all the DISCUSS positions. We
> have also removed both the relay-id type ASCII and DUID. We have introduced
> a new relay-id type OPAQUE. This new relay-id type can be administratively
> configured and is a series of octets.
>
>        Now, as the above changes are more than minor changes, I think that
> it will first have to go through working-group. So I request people to
> review this draft ( only 5 pages ) and post their comments.
>
> Regards,
> Bharat
> From: [email-masked] [[email-masked]] On Behalf Of
> [email-masked] [[email-masked]]
> A New Internet-Draft is available from the on-line Internet-Drafts
> directories. This draft is a work item of the Dynamic Host Configuration
> Working Group of the IETF.
>

---

From: Bharat Joshi <[email-masked]>
Date: Mon, 6 Jun 2011 15:06:16 +0530

Pavan,

       Thanks a lot for the quick review.

       Will rephrase the sentence.

       Yes. 'type' field has been kept there to keep any future extensibility possible.

Regards,
Bharat
________________________________________
From: Pavan Kurapati [[email-masked]]
Sent: Sunday, June 05, 2011 8:31 PM
To: Bharat Joshi
Cc: [email-masked]
Subject: Re: [dhcwg] FW: I-D Action: draft-ietf-dhc-relay-id-suboption-08.txt

Bharat,

Draft looks good. Just one minor editorial comment and one clarification needed below.

> "DHCP typically identifies clients based on information in their DHCP messages"

You might want to replace the first "DHCP" with DHCP server. If you do not want to restrict to server here you may say network entity

I assume the inclusion of "type" field now is for any future consideration of including other types like DUID? Else it seems redundant, now that we have only 1 type in the sub-option.

Thanks,
Pavan

On Sun, Jun 5, 2011 at 2:33 PM, Bharat Joshi <[email-masked]<mailto:[email-masked]>> wrote:
Hi All,

Regards,
Bharat
________________________________________
From: [email-masked]<mailto:[email-masked]> [[email-masked]<mailto:[email-masked]>] On Behalf Of [email-masked]<mailto:[email-masked]> [[email-masked]<mailto:[email-masked]>]
Sent: Saturday, June 04, 2011 10:34 PM
To: [email-masked]<mailto:[email-masked]>
Cc: [email-masked]<mailto:[email-masked]>
Subject: [dhcwg] I-D Action: draft-ietf-dhc-relay-id-suboption-08.txt

[email-masked]<mailto:[email-masked]>

[email-masked]<mailto:[email-masked]>

---

From: Ted Lemon <[email-masked]>
Date: Mon, 6 Jun 2011 09:09:38 -0400

>       Yes. 'type' field has been kept there to keep any future extensibility possible.

It seems to me that the semantics of DUID are sufficiently different than the semantics of this option that it would not be useful to combine them.   Do you see some other use for the type field?

---

From: Bharat Joshi <[email-masked]>
Date: Mon, 6 Jun 2011 18:43:21 +0530

> It seems to me that the semantics of DUID are sufficiently different than the semantics of this option that it would not be useful to combine them.   Do you see some other use for the type field?

At present, we do not have any other use for this field. This 'type' was inspired from the previous revision of this document and we decided to keep it there thinking that more type of relay-ids may come in future.

Regards,
Bharat

---

From: Ted Lemon <[email-masked]>
Date: Wed, 8 Jun 2011 13:57:19 -0400

> At present, we do not have any other use for this field. This 'type' was inspired from the previous revision of this document and we decided to keep it there thinking that more type of relay-ids ma…

I think the bottom line is that if you can't figure out what the type field does, you should take it out.   We are not experiencing a shortage of DHCPv6 option codes, so there's no reason to keep complexity in the spec to account for an unknown future circumstance that may or may not come to exist.

---

From: Leaf yeh <[email-masked]>
Date: Thu, 09 Jun 2011 02:29:18 +0000

Ted - We are not experiencing a shortage of DHCPv6 option codes,...

Supposed you're talking about the space shortage of the DHCPv4 option codes.

---

From: Alexandru Petrescu <[email-masked]>
Date: Thu, 09 Jun 2011 11:44:32 +0200

> Ted - We are not experiencing a shortage of DHCPv6 option codes,...

Yes, we use 66 decimal 0x42 for a new yet-to-be-documented option, we
think 66 may be the first available (IANA, isc sw) and max seems to be
255 even though 1 more byte can there be.

Alex

> -----Original Message----- From: [email-masked]
> [mailto:[email-masked]] On Behalf Of Ted Lemon Sent:
> Thursday, June 09, 2011 1:57 AM To: Bharat Joshi Cc: [email-masked]
>> At present, we do not have any other use for this field. This
>> 'type' was inspired from the previous revision of this document
>> and we decided to keep it there thinking that more type of
>> relay-ids may come in future.
>
> I think the bottom line is that if you can't figure out what the
> type field does, you should take it out.   We are not experiencing a
> shortage of DHCPv6 option codes, so there's no reason to keep
> complexity in the spec to account for an unknown future circumstance
> that may or may not come to exist.
>
>
> _______________________________________________ dhcwg mailing list
> [email-masked] https://www.ietf.org/mailman/listinfo/dhcwg
> _______________________________________________ dhcwg mailing list
> [email-masked] https://www.ietf.org/mailman/listinfo/dhcwg
>

---

From: Bharat Joshi <[email-masked]>
Date: Thu, 9 Jun 2011 15:49:15 +0530

Ted,

> that may or may not come to exist.

BTW, we are looking at DHCPv4 here. We have used up 11 sub-option numbers as of now and so we still have around 244 available.

If we are not worried about the number of sub-options then we can remove the 'type' field. The only other reason for keeping 'type' field was to keep all type of relay-id under one single sub-option.

Let me know what do you think.

Regards,
Bharat

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Sun, 12 Jun 2011 15:03:51 -0500

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

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

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'?

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.

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

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.

- Bernie

-----Original Message-----
From: Bharat Joshi [mailto:[email-masked]] 
Sent: Friday, June 10, 2011 6:36 AM
To: Bernie Volz (volz)
Subject: FW: [dhcwg] I-D Action:
draft-ietf-dhc-relay-id-suboption-08.txt

Bernie,

      Mark told me that you had reviewed this draft and had provided
valuable inputs.

      We have made quiet a few changes from the last revision. Can you
please review this new revision and send any comments to DHC mailing
list?

      We need this draft for our 'DHCPv4 Bulk lease query' draft.

Thanks in advance,
Bharat

   Dynamic Host Configuration Protocol&#39;s (DHCP) Relay Agent
Information

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-dhc-relay-id-suboption-08
.txt

This Internet-Draft can be retrieved at:
ftp://ftp.ietf.org/internet-drafts/draft-ietf-dhc-relay-id-suboption-08.
txt
_______________________________________________
dhcwg mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dhcwg

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

---

From: Bharat Joshi <[email-masked]>
Date: Mon, 13 Jun 2011 12:15:25 +0530

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

Yes. No issues.

> Personally, I'd switch section 3.1 and 3.2 (bulk LQ is a much stronger

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

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

> format for this relay identifier? See RFC 5460 section 5.4,

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

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.

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

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Mon, 13 Jun 2011 07:59:50 -0500

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:[email-masked]] 
Sent: Monday, June 13, 2011 2:45 AM
To: Bernie Volz (volz)
Cc: Mark Stapp (mjs); [email-masked]
Subject: RE: [dhcwg] I-D Action:

Hi Bernie,

Regards,
Bharat

Yes. No issues.

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

> format for this relay identifier? See RFC 5460 section 5.4,

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

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.

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

---

From: Mark Stapp <[email-masked]>
Date: Mon, 13 Jun 2011 09:38:51 -0400

Hi Bernie,

yes, I'd also prefer to use a single suboption for this purpose.

on the issue of the use of DUID, there's a disagreement. I understood Ted to say 
that he objected very strongly to any text that proposed 'moving' a DUID from 
one device to another, or administratively managing DUIDs. I'll let Ted speak 
for himself, of course, but that's a fundamental issue for this draft.

the brief history is:

- initial draft just describes opaque identifier, offers two suggestions for 
assigning id: ascii string and DUID-generating algorithm
- someone in WG discussion (David Hankins, maybe?) asked that there be a 
type-byte. type byte was added.
- Ted realized that the draft was proposing to assign DUID generated as relay-id 
by one device to another device, and objected
- Bharat re-issued draft sort of back at initial state, with just opaque id, and 
no implication that DUID was appropriate

so the question is: can a DUID-based relay identifier be administered? if so, 
then we can return that suggestion to the draft. if not, we'll stick with 
'opaque'. in either case, we'll add text to make it clear that the identifier 
needs to be administratively-unique.

Thanks,
Mark

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Mon, 13 Jun 2011 09:05:12 -0500

>needs to be administratively-unique.

Regarding the DUID, that is a complex issue and question. For a device
with storage, if you moved the storage to another device, it would
retain the DUID. So, the DUID is not really something that is hardwired
in this case. Of course, this really only applies to DUID-LLT as that is
the only type that needs to be stored. (The other types are generated
from 'hardwired' data and thus need no storage.)

I really don't see why you don't do both?

The default identifier that can be used by any device 'out of the box'
is the DUID type. Nothing has to be configured for the device to use
this.

If the administrator optionally configures an alternative 'opaque'
identifier, then the device uses that instead - with the understanding
that it is up to the administrator to assure that this identifier is
unique.

Hence, leave the type byte and have the two forms. You get both
capabilities - an identifier that can be used without any configuration
and an identifier that can be used in a case where a stable identifier
across multiple potential "replacement" devices works.

It is an interesting question as to whether we might want to think about
a DUID-OI (Opaque Identifier) at some point to accommodate "locally
administered" identifiers. These would NOT be allowed except when
administratively configured with the understanding that the
administrator must assure it is unique. This would then preclude the
need for a type byte in this suboption and also be useable by DHCPv6
relay agents. One could even envision that part of the identifier might
include a randomly generated value along the idea of the IPv6 Unique
Local Addresses (ULA) [probably just use the ULA?] as that could avoid
some issues when two administrative domains are collapsed into one.
Perhaps a draft I should think about writing? (If this has merit,
perhaps then your draft is simplified as all it needs to state is using
the DUID.)

The DUID-OI data format could be 6+<n> octets:
- 6 octets of the 48-bit ULA value (see RFC 4193 - this includes 7-bit
prefix (FC00::/7), L bit, and 40 bit Global ID.)
- <n> octets that follow which are the unique identifier.

- Bernie

-----Original Message-----
From: Mark Stapp (mjs) 
Sent: Monday, June 13, 2011 9:39 AM
To: Bernie Volz (volz)
Cc: Bharat Joshi; [email-masked]
Subject: Re: [dhcwg] I-D Action:

Hi Bernie,

on the issue of the use of DUID, there's a disagreement. I understood
Ted to say 
that he objected very strongly to any text that proposed 'moving' a DUID
from 
one device to another, or administratively managing DUIDs. I'll let Ted
speak 
for himself, of course, but that's a fundamental issue for this draft.

the brief history is:

- initial draft just describes opaque identifier, offers two suggestions
for 
assigning id: ascii string and DUID-generating algorithm
- someone in WG discussion (David Hankins, maybe?) asked that there be a

type-byte. type byte was added.
- Ted realized that the draft was proposing to assign DUID generated as
relay-id 
by one device to another device, and objected
- Bharat re-issued draft sort of back at initial state, with just opaque
id, and 
no implication that DUID was appropriate

so the question is: can a DUID-based relay identifier be administered?
if so, 
then we can return that suggestion to the draft. if not, we'll stick
with 
'opaque'. in either case, we'll add text to make it clear that the
identifier 
needs to be administratively-unique.

Thanks,
Mark

---

From: Ted Lemon <[email-masked]>
Date: Mon, 13 Jun 2011 10:33:55 -0700

On Jun 13, 2011, at 6:38 AM, Mark Stapp wrote:
> on the issue of the use of DUID, there's a disagreement. I understood Ted to say that he objected very strongly to any text that proposed 'moving' a DUID from one device to another, or administratively managing DUIDs. I'll let Ted speak for himself, of course, but that's a fundamental issue for this draft.

No, what I objected to was moving unique identifiers from device to device.   If you have a unique identifier, it identifies a device.   If you start moving it around, it loses that property.   The right way to use unique identifiers is to have a mapping between the identifier and whatever role it is that you want to assign to the thing that has been uniquely identified.

What you proposed, which I didn't particularly like, was simply putting the role identifier on the device.   The only reason I didn't like it is that it means we need to define some other identifier that's a unique identifier.  Perhaps a better way to put it is that I thought you were trying to uniquely identify the device, but it later turned out that that was not the case--you merely wanted to identify its role.

I still think it's better to uniquely identify the device, and have a central map between device identity and role.   But I agreed with you that if you really intended the semantics of the option to be that identifies the role of the device, and not the device, I would be okay with that.

However, if the identifier is a role identifier, and not a unique identifier, then you shouldn't use the term "UUID" to describe it, nor should you put a UUID in it, because in doing so you turn the UUID into a non-unique identifier.   And you shouldn't use a DUID, because a DUID is essentially a DHCP-specific UUID.

So yes, I object very strongly to defining an identifier that is "unique" but also might be transferred from device to device.   If you take away the uniqueness, I think what you're left with isn't useful to me, but I don't object to you defining it if it's useful to you.

I would also say that this is another reason why this ought not to be an option with a "type" field.   The option as Mark was defining it was going to have a very constrained function.   It wasn't going to be a unique identifier.   So the idea that it would be extended to support new identifier types in the future doesn't make a whole lot of sense to me.

---

From: Ted Lemon <[email-masked]>
Date: Mon, 13 Jun 2011 10:34:15 -0700

> Supposed you're talking about the space shortage of the DHCPv4 option codes.

Yes, sorry, I have IPv6 on the brain at the moment, and forgot that we were talking about a DHCPv4 option.

---

From: Bharat Joshi <[email-masked]>
Date: Tue, 14 Jun 2011 22:16:04 +0530

Bernie,

> I really don't see why you don't do both?

Actually we end up removing DUID from the draft because we could not find a use-case for DUID as relay-id.

The two use-cases in this draft needs an administratively configured relay-id.

Can you think of any scenario where a DUID relay-id could be useful?

> across multiple potential "replacement" devices works.

The 'type' field came from previous revisions. I think we had unfortunately assumed that DHCP server may parse/interpret the relay-id and so this type field was kept here to indicate what kind of relay-id this sub-option is carrying.

After looking at the use cases again, we think we can remove it as DHCP server would never need to parse/interpret it and relay-agent will always know what it has used in relay-id sub-option.

Let me know what you think?

> perhaps then your draft is simplified as all it needs to state is using

Yes. I agree. This might be useful. Some time back I think Mark and I were discussing whether we need an administratively configured DUID which can be reused.

Thanks,
Bharat

> - <n> octets that follow which are the unique identifier.
__
-----Original Message-----
From: Mark Stapp (mjs)
Sent: Monday, June 13, 2011 9:39 AM
To: Bernie Volz (volz)
Cc: Bharat Joshi; [email-masked]
Subject: Re: [dhcwg] I-D Action:

Hi Bernie,

the brief history is:

Thanks,
Mark

---

From: Mark Stapp <[email-masked]>
Date: Tue, 14 Jun 2011 13:41:26 -0400

Bharat,
I originally introduced the reference to DUID to address a need that did seem 
real to me. it seemed reasonable to describe a couple of ways an admin might 
come up with an identifier. one possibility was "make one up - use a string that 
means something to you in your network." another possibility was "ask the device 
to generate an id that's got a really good chance of being robust and unique." I 
pointed to the DUID-generating algorithm as an example.

I do think it would/will be helpful if a device acting as a relay were willing 
to generate a relay-id. but I don't think that's an interoperability issue - it 
can always be a vendor value-add. all that's necessary is that the ids be 
administratively unique.

-- Mark

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Tue, 14 Jun 2011 13:03:18 -0500

I do think that we've discussed this to bits and it really is up to you
how you want to proceed.

- Bernie

-----Original Message-----
From: Bharat Joshi [mailto:[email-masked]] 
Sent: Tuesday, June 14, 2011 12:46 PM
To: Bernie Volz (volz); Mark Stapp (mjs)
Cc: [email-masked]
Subject: RE: [dhcwg] I-D Action:

Bernie,

> I really don't see why you don't do both?

Actually we end up removing DUID from the draft because we could not
find a use-case for DUID as relay-id.

The two use-cases in this draft needs an administratively configured
relay-id.

> across multiple potential "replacement" devices works.

The 'type' field came from previous revisions. I think we had
unfortunately assumed that DHCP server may parse/interpret the relay-id
and so this type field was kept here to indicate what kind of relay-id
this sub-option is carrying.

After looking at the use cases again, we think we can remove it as DHCP
server would never need to parse/interpret it and relay-agent will
always know what it has used in relay-id sub-option.

> perhaps then your draft is simplified as all it needs to state is
using

Yes. I agree. This might be useful. Some time back I think Mark and I
were discussing whether we need an administratively configured DUID
which can be reused.

Thanks,
Bharat

__
-----Original Message-----
From: Mark Stapp (mjs)
Sent: Monday, June 13, 2011 9:39 AM
To: Bernie Volz (volz)
Cc: Bharat Joshi; [email-masked]
Subject: Re: [dhcwg] I-D Action:

Hi Bernie,

the brief history is:

Thanks,
Mark