Re: [radext] #192 (bigger-packets): unclear meaning of "configured categories" of dynamically discovered servers
Stefan Winter <stefan.winter@restena.lu> Thu, 29 October 2015 11:56 UTC
Return-Path: <stefan.winter@restena.lu>
X-Original-To: radext@ietfa.amsl.com
Delivered-To: radext@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 333D51B2DC2 for <radext@ietfa.amsl.com>; Thu, 29 Oct 2015 04:56:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.909
X-Spam-Level:
X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01, WEIRD_PORT=0.001] autolearn=ham
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 Z1iGZ7waHLJP for <radext@ietfa.amsl.com>; Thu, 29 Oct 2015 04:56:10 -0700 (PDT)
Received: from smtprelay.restena.lu (smtprelay.restena.lu [IPv6:2001:a18:1::62]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 74E901B2DB0 for <radext@ietf.org>; Thu, 29 Oct 2015 04:56:10 -0700 (PDT)
Received: from aragorn.restena.lu (aragorn.restena.lu [IPv6:2001:a18:1:8::155]) by smtprelay.restena.lu (Postfix) with ESMTPS id D30CB43AA0; Thu, 29 Oct 2015 12:56:08 +0100 (CET)
To: Sam Hartman <hartmans@painless-security.com>
References: <065.dd4ffddd8d52391c04bbc2b328b97f76@trac.tools.ietf.org> <tsl7foqjbae.fsf@mit.edu> <55D6CC73.9020002@restena.lu> <tslr3mwhj9h.fsf@mit.edu>
From: Stefan Winter <stefan.winter@restena.lu>
Openpgp: id=AD3091F3AB24E05F4F722C03C0DE6A358A39DC66; url=http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xC0DE6A358A39DC66
X-Enigmail-Draft-Status: N1111
Message-ID: <56320958.2000403@restena.lu>
Date: Thu, 29 Oct 2015 12:56:08 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0
MIME-Version: 1.0
In-Reply-To: <tslr3mwhj9h.fsf@mit.edu>
Content-Type: multipart/signed; micalg="pgp-sha512"; protocol="application/pgp-signature"; boundary="fNRMcVNMbK6dpQjSoc3BF5BJ5KtwxbJw9"
Archived-At: <http://mailarchive.ietf.org/arch/msg/radext/D92_qXTw0f0nqfr2uALLwq-LSuU>
Cc: radext@ietf.org
Subject: Re: [radext] #192 (bigger-packets): unclear meaning of "configured categories" of dynamically discovered servers
X-BeenThere: radext@ietf.org
X-Mailman-Version: 2.1.15
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: <https://mailarchive.ietf.org/arch/browse/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, 29 Oct 2015 11:56:12 -0000
Hi, > I think the particular configuration you quote above might be a good fit > for a system that uses both Moonshot and eduroam. > Especially if you make it a bit finer grained by allowing each > consortuim/set of CAs/whatever you want to describe it as for DNS have > its own configuration. The "whatever you want" makes it difficult to prescribe how exactly a classification of servers should be done - and was the reason why I considered the wording unclear. > I think I need something like this as a minimum so I'd like to have a > related SHOULd in the spec. > I'd be happy to get input on what approaches would give me this but work > for you. Okay... We both agree that this parameter needs to be configurable. None of us really knows how "categories" should be defined exactly (nor do we know what will be useful classification criteria in the field). I think this is something actual implementations - and their customer demand - can and will sort out themselves. The important bit is that it must be configurable in principle IMHO; and that more than one global default is something to consider for an implementation. So how about this as a text proposal: OLD: If dynamic discovery mechanisms are supported, configuration SHOULD be provided for the maximum size of clients and servers in each dynamic discovery category. NEW: If dynamic discovery mechanisms are supported, the default maximum packet sizes for sending packets SHOULD be configurable. Implementations MAY choose to allow configuration of different defaults in different parts of their dynamic discovery configuration. How about that? Greetings, Stefan Winter -- Stefan WINTER Ingenieur de Recherche Fondation RESTENA - Réseau Téléinformatique de l'Education Nationale et de la Recherche 2, avenue de l'Université L-4365 Esch-sur-Alzette Tel: +352 424409 1 Fax: +352 422473 PGP key updated to 4096 Bit RSA - I will encrypt all mails if the recipient's key is known to me http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xC0DE6A358A39DC66
- [radext] #192 (bigger-packets): unclear meaning o… radext issue tracker
- Re: [radext] #192 (bigger-packets): unclear meani… Sam Hartman
- Re: [radext] #192 (bigger-packets): unclear meani… Stefan Winter
- Re: [radext] #192 (bigger-packets): unclear meani… Sam Hartman
- Re: [radext] #192 (bigger-packets): unclear meani… Stefan Winter
- Re: [radext] #192 (bigger-packets): unclear meani… radext issue tracker
- Re: [radext] #192 (bigger-packets): unclear meani… Sam Hartman
- Re: [radext] #192 (bigger-packets): unclear meani… Stefan Winter
- Re: [radext] #192 (bigger-packets): unclear meani… Sam Hartman
- Re: [radext] #192 (bigger-packets): unclear meani… Stefan Winter
- Re: [radext] #192 (bigger-packets): unclear meani… radext issue tracker
- Re: [radext] #192 (bigger-packets): unclear meani… radext issue tracker