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

Ben Campbell <ben@nostrum.com> Thu, 30 November 2017 00:15 UTC

Return-Path: <ben@nostrum.com>
X-Original-To: dhcwg@ietfa.amsl.com
Delivered-To: dhcwg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F086D1272E1; Wed, 29 Nov 2017 16:15:20 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.879
X-Spam-Level:
X-Spam-Status: No, score=-1.879 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3q-zpBzGWACF; Wed, 29 Nov 2017 16:15:19 -0800 (PST)
Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 471E4124D6C; Wed, 29 Nov 2017 16:15:19 -0800 (PST)
Received: from [10.0.1.92] (cpe-66-25-7-22.tx.res.rr.com [66.25.7.22]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id vAU0FHJ9059823 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Wed, 29 Nov 2017 18:15:17 -0600 (CST) (envelope-from ben@nostrum.com)
X-Authentication-Warning: raven.nostrum.com: Host cpe-66-25-7-22.tx.res.rr.com [66.25.7.22] claimed to be [10.0.1.92]
From: Ben Campbell <ben@nostrum.com>
Message-Id: <4364B55F-0BC5-42B9-965D-FEF9D9AED9C5@nostrum.com>
Content-Type: multipart/signed; boundary="Apple-Mail=_1872BCC5-FEE9-40E2-948B-3EEF24220B61"; protocol="application/pgp-signature"; micalg="pgp-sha512"
Mime-Version: 1.0 (Mac OS X Mail 11.1 \(3445.4.7\))
Date: Wed, 29 Nov 2017 18:15:16 -0600
In-Reply-To: <200CE2CC-D6D1-40BA-843A-1193DFFDEE74@fugue.com>
Cc: The IESG <iesg@ietf.org>, draft-ietf-dhc-relay-port@ietf.org, dhcwg@ietf.org, dhc-chairs@ietf.org
To: Ted Lemon <mellon@fugue.com>
References: <151198969282.31355.16877065112899804068.idtracker@ietfa.amsl.com> <200CE2CC-D6D1-40BA-843A-1193DFFDEE74@fugue.com>
X-Mailer: Apple Mail (2.3445.4.7)
Archived-At: <https://mailarchive.ietf.org/arch/msg/dhcwg/imm9krSY7U1JFD4cmIudfz0ZWdw>
Subject: Re: [dhcwg] Ben Campbell's Discuss on draft-ietf-dhc-relay-port-08: (with DISCUSS and COMMENT)
X-BeenThere: dhcwg@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: <dhcwg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dhcwg>, <mailto:dhcwg-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dhcwg/>
List-Post: <mailto:dhcwg@ietf.org>
List-Help: <mailto:dhcwg-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dhcwg>, <mailto:dhcwg-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 30 Nov 2017 00:15:21 -0000

Hi Ted,

It explicitly proposes changes to changes language to 2131 and 3315. I’m not sure how to read that in any other way than updating 2131 and 3315.

Otherwise, if this is only intended for a specific context, it would help to have some language in the draft describing that scope. As written, I don’t see why a reader that was not involved in the creation of the draft would not assume it to be general purpose.

I’m almost convinced by the “same administrative domain” (although I think my “customer owned” cable modem has a relay, and it’s sort of fuzzy who’s administrative it belongs to :-) ). I think it would help to strengthen the language in 5.4 to make it clear what will break if people get this wrong.

Paragraph 2 of that section seems vague about when such a relay might choose a DHCP vs non-DHCP port. Is there some expectation that the relay would listen on both ports, in case of stray responses?

Ben.

> On Nov 29, 2017, at 3:19 PM, Ted Lemon <mellon@fugue.com> 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.
>