Re: [radext] #187 (dynamic-discovery): Timeouts..

"radext issue tracker" <> Mon, 27 October 2014 10:50 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 9A97B1A90AF for <>; Mon, 27 Oct 2014 03:50:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.91
X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id HHd1AGrNY0LF for <>; Mon, 27 Oct 2014 03:50:36 -0700 (PDT)
Received: from ( [IPv6:2001:1890:123a::1:2a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 9C69A1A90A1 for <>; Mon, 27 Oct 2014 03:50:34 -0700 (PDT)
Received: from localhost ([::1]:52847 by with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from <>) id 1Xihsf-0001eQ-2u; Mon, 27 Oct 2014 03:50:33 -0700
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: "radext issue tracker" <>
X-Trac-Version: 0.12.3
Precedence: bulk
Auto-Submitted: auto-generated
X-Mailer: Trac 0.12.3, by Edgewall Software
X-Trac-Project: radext
Date: Mon, 27 Oct 2014 10:50:33 -0000
Message-ID: <>
References: <>
X-Trac-Ticket-ID: 187
In-Reply-To: <>
X-SA-Exim-Connect-IP: ::1
X-SA-Exim-Scanned: No (on; SAEximRunCond expanded to false
Subject: Re: [radext] #187 (dynamic-discovery): Timeouts..
X-Mailman-Version: 2.1.15
List-Id: RADIUS EXTensions working group discussion list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 27 Oct 2014 10:50:41 -0000

#187: Timeouts..

Comment (by

 I have changed the sentence to a relative, not an absolute statement:

 "much more in-depth guidance on DNS regarding timeouts, failure
 conditions, alteration of Time-To-Live (TTL) information than the Diameter

 which makes the sentence more true than before.

 On the second part, TTL higher than certificate lifetime, this is out of
 scope for this specification: this draft specifies an algorithm on
 extracting connection-relevant data from DNS - and only that. The lifetime
 of a certificate is learned only later, when this list is used to
 establish a RADIUS/TLS connection with a discovered endpoint.

 The place to put a TTL restriction would thus be RFC6614, chapter
 "Connection Setup". Unfortunately, that RFC is silent on this matter :-(

 Since RFC6614 is currently being discussed for re-issue from Experimental
 to Standards track, I suggest to introduce the corresponding change in
 that RFC's "bis".

 Please let me know if that works for you and close the ticket if so.

 Reporter:  |       Owner:
     Type:  defect                  |      Status:  new
 Priority:  major                   |   Milestone:
Component:  dynamic-discovery       |     Version:
 Severity:  -                       |  Resolution:
 Keywords:                          |

Ticket URL: <>
radext <>