Re: [radext] New DTLS document
Alan DeKok <aland@deployingradius.com> Thu, 02 May 2013 16:04 UTC
Return-Path: <aland@deployingradius.com>
X-Original-To: radext@ietfa.amsl.com
Delivered-To: radext@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8BBC921F8FF2 for <radext@ietfa.amsl.com>; Thu, 2 May 2013 09:04:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.979
X-Spam-Level:
X-Spam-Status: No, score=-101.979 tagged_above=-999 required=5 tests=[AWL=-0.620, BAYES_00=-2.599, SARE_LWSHORTT=1.24, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TmL-HWUCArEa for <radext@ietfa.amsl.com>; Thu, 2 May 2013 09:04:10 -0700 (PDT)
Received: from power.freeradius.org (power.freeradius.org [88.190.25.44]) by ietfa.amsl.com (Postfix) with ESMTP id 9C74D21F8FF1 for <radext@ietf.org>; Thu, 2 May 2013 09:04:10 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by power.freeradius.org (Postfix) with ESMTP id 60B912240E2B; Thu, 2 May 2013 18:04:09 +0200 (CEST)
X-Virus-Scanned: Debian amavisd-new at power.freeradius.org
Received: from power.freeradius.org ([127.0.0.1]) by localhost (power.freeradius.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oEKuNGn4dn50; Thu, 2 May 2013 18:04:09 +0200 (CEST)
Received: from Thor-2.local (bas1-ottawa11-1176121151.dsl.bell.ca [70.26.47.63]) by power.freeradius.org (Postfix) with ESMTPSA id 6B6BE2240297; Thu, 2 May 2013 18:04:08 +0200 (CEST)
Message-ID: <51828E77.9020303@deployingradius.com>
Date: Thu, 02 May 2013 12:04:07 -0400
From: Alan DeKok <aland@deployingradius.com>
User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228)
MIME-Version: 1.0
To: Jouni Korhonen <jouni.nospam@gmail.com>
References: <516EA97E.2000005@deployingradius.com> <C47910C2-BCEA-4DC2-A016-C98D67B62DD9@gmail.com> <A95B4818FD85874D8F16607F1AC7C628B4032E@xmb-rcd-x09.cisco.com> <0E1BBA4B-1985-43C3-800A-AF336CABEF30@gmail.com> <517FBD04.1050009@deployingradius.com> <B43B810F-DBF3-4CCD-BFA0-494E10819D2A@gmail.com>
In-Reply-To: <B43B810F-DBF3-4CCD-BFA0-494E10819D2A@gmail.com>
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit
Cc: radext@ietf.org, "Joseph Salowey (jsalowey)" <jsalowey@cisco.com>
Subject: Re: [radext] New DTLS document
X-BeenThere: radext@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: RADIUS EXTensions working group discussion list <radext.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/radext>, <mailto:radext-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/radext>
List-Post: <mailto:radext@ietf.org>
List-Help: <mailto:radext-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/radext>, <mailto:radext-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 02 May 2013 16:04:16 -0000
Jouni Korhonen wrote: > I would be ok to remove Section 5.1.2 entirely. Which means that the rest of the document needs to be updated, too. It talks about accepting UDP and DTLS on the same port. Section 5.1.2 is only *justification* for why that works. The other sections say *how* it's supposed to work. i.e. Deleting 5.1.2 means we'd have to delete more than half of Section 3, too. > However, if WG wants to keep > Section 5.1.2 I would add a note there that it is intended to be a short term > migration solution and can be turned off at some point of time. Implementations > and deployments are encouraged to switch to the RADIUS-DTLS port as soon as > possible. Would that be OK for the WG? I already added that in the latest rev. See Section 3: This section describes how clients and servers should transition to DTLS. There is a fair amount of discussion around this transition, as it is critical to get it correct. We expect that once implementations have transitioned to RADIUS/DTLS, the text in this section will no longer be relevant. If we're just going to turn off UDP, we don't need any transition path. We just break the network, and let everyone figure out what to do. The whole point of the text in Section 3 is to document how the transition path is handled. Including (if so desired) accepting UDP and DTLS on the same port. I can add duplicate text in Section 5.1.2. But the idea is for people to read the *entire* document, and act on it as a whole. Alan DeKok.
- Re: [radext] New DTLS document jouni korhonen
- [radext] New DTLS document Alan DeKok
- Re: [radext] New DTLS document Jouni Korhonen
- Re: [radext] New DTLS document Peter Deacon
- Re: [radext] New DTLS document Joseph Salowey (jsalowey)
- Re: [radext] New DTLS document Jouni Korhonen
- Re: [radext] New DTLS document Sam Hartman
- Re: [radext] New DTLS document Alan DeKok
- Re: [radext] New DTLS document Sam Hartman
- Re: [radext] New DTLS document Peter Deacon
- Re: [radext] New DTLS document Alan DeKok
- Re: [radext] New DTLS document Jouni Korhonen
- Re: [radext] New DTLS document Alan DeKok
- Re: [radext] New DTLS document Jouni Korhonen
- Re: [radext] New DTLS document Joseph Salowey (jsalowey)
- Re: [radext] New DTLS document Stig Venaas
- [radext] A way forward with the DTLS document - a… Jouni Korhonen
- Re: [radext] A way forward with the DTLS document… Bernard Aboba
- Re: [radext] A way forward with the DTLS document… Peter Deacon
- Re: [radext] A way forward with the DTLS document… Jim Schaad
- Re: [radext] A way forward with the DTLS document… Diego R. Lopez
- Re: [radext] A way forward with the DTLS document… Stig Venaas
- Re: [radext] A way forward with the DTLS document… Jouni Korhonen