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

I'm hearing these concrete issues based on your emails:

1. make it explicit that the id used, whether configured or
auto-generated, is expected to remain 'stable', which means committed
to some kind of non-volatile storage.

2. make it explicit that if the administrator depends on the relay-id
as part of client provisioning or identification, it must be available
in all the dhcp messages where the server depends on it. I think there
are several ways to deal with that: ignore RENEWs without opt-82;
permit RENEWs without checking opt-82; use server-id-override; use L2
relay.

wrt the question of the admin-configured relay-id value, I think
(personally) that it's overkill to prohibit use of a string until we've
invented and standardized a new DUID type that carries ... a string.
the id value is _meant_ to be opaque, so unless there's a real
technical reason why an admin-configured value could cause an
operational problem, I'd prefer to just leave it be.

Thanks,

Mark
On Wed, Sep 10, 2008 at 09:40:33AM -0400, Mark Stapp wrote:

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.

OK, that makes more sense.

My concern there right now is that the draft only says a relay agent
might format this new option as equal to a DUID, but gives no
directions for stable storage of that DUID or what context should be
driven to manufacture it (from packet contents or from the relay's
internal context such as its own interface addresses).

We've had problems with clients manufacturing a new DUID-LLT every
time they restart, and 3315 was pretty clear on this issue I thought.
I'm fairly concerned what we'll see if we're not clear. :)

It might make some sense, from Bernie's comments, to stick to DUID
types entirely and make "vendor or administratively supplied" id's
live under the vendor-identified DUID type, explicitly describing
the field contents as being the relay's DUID and subject to the same
rules that clients and servers use to generate their own.  If we need
a "manually configured NVT-ASCII string" DUID type, we could assign
one I think.

I got the idea somehow from the introduction and the later sections
that an admin might expect to see "sw5.etc:5/19" as the field
contents, being a switch identity concatenated with a port number,
and using that to form an identity with a lease.  I gather I'm
mistaken, and concat(relay-DUID, relay-interface-id) seems much more
reliable and extensible.

But this is a commonly requested and very useful feature, so if this
field is intended to be used in concert with other fields (relay agent
interface-id) to form an identity relationsihp with a lease, I think
we still have a RENEWING problem (maybe solved by referring to
RFC5107)?

_______________________________________________
dhcwg mailing list
dhcwg@ietf.org
https://www.ietf.org/mailman/listinfo/dhcwg" rel="nofollow">https://www.ietf.org/mailman/listinfo/dhcwg

_______________________________________________
dhcwg mailing list
dhcwg@ietf.org
https://www.ietf.org/mailman/listinfo/dhcwg