[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [dhcwg] dhc WG last callon draft-ietf-dhc-relay-id-suboption-00.txt
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