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
Attachment:
pgpezJwZIJOir.pgp
Description: PGP signature
_______________________________________________ dhcwg mailing list dhcwg at ietf.org https://www.ietf.org/mailman/listinfo/dhcwg