Re: [dhcwg] Ben Campbell's Discuss on draft-ietf-dhc-relay-port-08: (with DISCUSS and COMMENT)

["Naiming Shen (naiming)" <[e-mail]>]

Hi Ben,

Thanks for the review.

I agree with Ted’s comment on this. This is targeted mainly in a single admin domain.
If an operator wants to turn on this feature on a relay(s), he/she can find out if the
server or upstream relay supports this or not, and it’s easy to disable this feature
if it does not work (could also be bugs in software).

Also, the configuration of the feature is on the relay, the upstream relays and
server as long as has the software upgraded, they don’t need configuration. This
is similar to other DHCP relay options, for example, the ‘Agent Cirucit ID’ or
the ’Subscriber-ID” sub-option, which does not require relay do discovery to find
out if server supports that or not, and as soon as the server has the updated software,
it would automatically supports this.

For the other "UPDATES..” tag. I’m quoting Bernie’s comment in another thread:

	"We’ve already had this discussion and debate. It only UPDATES if you want to
	use this new capabilities, we don’t have a flag for that. UPDATES usually implies
	that you must do that."


Best Regards,
- Naiming

> On Nov 29, 2017, at 1:19 PM, Ted Lemon <[e-mail]> wrote:
> 
> Ben, the idea is that this is a very targeted approach for SDNs, not something that makes sense as a general update to the DHCP base specifications.   Since relays and servers are generally within the same administrative domain, there is little danger of actual interop issues—the operator is going to be customizing these settings very deliberately.   We also tend to assume that the DHCP server is pretty easy to update compared to relays or clients, so the fact that an updated relay might not work with a non-updated server isn't a major issue.   This isn't like TLS 1.3 where the server and the middleboxes are operated by agencies unknown to each other.
>