Re: [dhcwg] dhc WG last callon draft-ietf-dhc-relay-id-suboption-00.txt

Just wanted to post the mail thread on which I had put up my suggestions:

http://www.ietf.org/mail-archive/web/dhcwg/current/msg08754.html

Thanks,

Bharat

From: Mark Stapp [mailto:mjs at cisco.com]
Sent: Wednesday, September 10, 2008 7:11 PM
To: Bharat Joshi
Cc: Bernie Volz (volz); David W. Hankins; DHC WG
Subject: Re: [dhcwg] dhc WG last callon draft-ietf-dhc-relay-id-suboption-00.txt

Hello,

yes, Bharat and I had a brief email thread back in August, and I'll publish a new version with some changes.

David: this isn't about cons'ing up new ids for clients. don't let an example from the text mislead you about what the data in the suboption is: it's just another relay suboption. I'll reorganize the examples to try to make the distinction between what the info is and how it might be used clerrer.

Regards,
Mark

Bharat Joshi wrote:

Hi,

    Yes. I also think it need to be a little bit more clear on certain things. I have pointed this out in the comments I sent on this draft few weeks back.

    Once those comments are taken care, I suggest to take this forward.

Thanks,

Bharat

________________________________________

From: dhcwg-bounces at ietf.org [dhcwg-bounces at ietf.org] On Behalf Of Bernie Volz (volz) [volz at cisco.com]

Sent: Wednesday, September 10, 2008 7:36 AM

To: David W. Hankins; DHC WG

Subject: Re: [dhcwg] dhc WG last        callon  draft-ietf-dhc-relay-id-suboption-00.txt

Wow. I don't really understand how you read that, but if you did, then

yes, this draft certainly needs some work!

I don't understand where the manufacturing the client's identifier

entered into the picture.

The point of that introduction was to say that a UNIQUE identifier for a

client might be formed using <relay-id><relay-port-id> -- such as for a

factory floor where a robot plugged into port 6 of switch xyz would

always be welding the door to the car regardless of what the

client-identifier or mac address is. Thus, you'd want to assign it the

"weld door to car" robot IP address.

There are already relay agent suboptions to identify the port

(remote-id, circuit-id). There isn't anything to unique identify the

relay (giaddr *might* be usable, but it has other purposes too and so is

dangerous and it is related to the network topology - for the relay

address on the server side, not the client side of the network).

Once generated, the relay-id would be stable. The remote-id/circuit-id

for a particular port would also. And, the server is expected to use the

relay-id/<remote-id or circuit-id> to identify the client in the server

-- not the client-id or mac-address.

---

There are other uses of this relay-agent id suboption -- such as the

DHCPv4 bulk leasequery work.

- Bernie

-----Original Message-----

From: dhcwg-bounces at ietf.org [mailto:dhcwg-bounces at ietf.org] On Behalf

Of David W. Hankins

Sent: Monday, September 08, 2008 5:19 PM

To: DHC WG

Subject: Re: [dhcwg] dhc WG last callon

draft-ietf-dhc-relay-id-suboption-00.txt

On Mon, Sep 08, 2008 at 03:47:44PM -0400, Ralph Droms wrote:

http://www.ietf.org/internet-drafts/draft-ietf-dhc-relay-id-suboption-00

.txt

The draft mentions in Introduction the use of the field in identifying

the client instead of the client-identifier or the chaddr field.

It doesn't seem to address or suggest server behaviour when a client

is RENEWING.  All the server would have at this stage is any identity

the client offers, which is sure to mismatch any relay-agent supplied

value, which is what the lease binding is suggested to be identified

against.

I think in particular the advice to generate a DUID for the client to

put in this field is a potentially misleading default, as for example

it would be fairly bad for a relay to manufacture a new DUID-LLT every

time it sees a given client.  I know of no reason why this would be

considered beneficial; presuming the client supplies a DUID, it would

always be preferrable.  If there is some beneficial reason for A

DUID-like identifier to be manufactured by a relay, perhaps it could

be described.

I think this draft could use some more work before going to IESG.

--

Ash bugud-gul durbatuluk agh burzum-ishi krimpatul.

Why settle for the lesser evil?  https://secure.isc.org/store/t-shirt/

--

David W. Hankins        "If you don't do it right the first time,

Software Engineer                    you'll just have to do it again."

Internet Systems Consortium, Inc.               -- Jack T. Hankins

_______________________________________________

dhcwg mailing list

dhcwg at ietf.org

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

_______________________________________________

dhcwg mailing list

dhcwg at ietf.org

https://www.ietf.org/mailman/listinfo/dhcwg