From nobody Tue May 3 05:22:14 2016 Return-Path: X-Original-To: radext@ietf.org Delivered-To: radext@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id A24A812D776; Tue, 3 May 2016 05:22:13 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "Mirja Kuehlewind" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.19.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160503122213.7493.37635.idtracker@ietfa.amsl.com> Date: Tue, 03 May 2016 05:22:13 -0700 Archived-At: Cc: stefan.winter@restena.lu, jouni.nospam@gmail.com, radext@ietf.org, radext-chairs@ietf.org, draft-ietf-radext-bigger-packets@ietf.org Subject: [radext] =?utf-8?q?Mirja_K=C3=BChlewind=27s_No_Objection_on_draft?= =?utf-8?q?-ietf-radext-bigger-packets-07=3A_=28with_COMMENT=29?= X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.17 List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 May 2016 12:22:13 -0000 Mirja Kühlewind has entered the following ballot position for draft-ietf-radext-bigger-packets-07: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-radext-bigger-packets/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Minor: A reference to RFC 6613 in the last paragraph of section 1 would be helpful. From nobody Tue May 3 06:56:21 2016 Return-Path: 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 3845012D80D for ; Tue, 3 May 2016 06:56:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.895 X-Spam-Level: X-Spam-Status: No, score=-2.895 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.996, WEIRD_PORT=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 Httkmd32iMEp for ; Tue, 3 May 2016 06:56:17 -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 BE60C12D15C for ; Tue, 3 May 2016 06:55:37 -0700 (PDT) Received: from aragorn.restena.lu (aragorn.restena.lu [IPv6:2001:a18:1:8::155]) by smtprelay.restena.lu (Postfix) with ESMTPS id 1038443ABA for ; Tue, 3 May 2016 15:55:36 +0200 (CEST) To: "radext@ietf.org" From: Stefan Winter Openpgp: id=AD3091F3AB24E05F4F722C03C0DE6A358A39DC66; url=http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xC0DE6A358A39DC66 Message-ID: <5728ADD7.80509@restena.lu> Date: Tue, 3 May 2016 15:55:35 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.7.0 MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="bVwKh9QoJKUaCwwecvRinRmxkD6dcUwnh" Archived-At: Subject: [radext] Review of draft-ietf-radext-datatypes-02 X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 May 2016 13:56:20 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --bVwKh9QoJKUaCwwecvRinRmxkD6dcUwnh Content-Type: multipart/mixed; boundary="iwSXgtKvAqp3sVDUvQOiOifNLGK11f3c6" From: Stefan Winter To: "radext@ietf.org" Message-ID: <5728ADD7.80509@restena.lu> Subject: Review of draft-ietf-radext-datatypes-02 --iwSXgtKvAqp3sVDUvQOiOifNLGK11f3c6 Content-Type: multipart/mixed; boundary="------------040600030204090905000503" This is a multi-part message in MIME format. --------------040600030204090905000503 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hello, I'm currently reviewing draft-ietf-radext-datatypes-02 as part of the shepherd write-up. I have a few questions/change requests below: * The introduction mentions a number of "war stories" of specifications that have left data type gaps or introduced ambiguities. The I-D correspondingly has an Updates relationship to these RFCs. I wonder: is this list meant to be exhaustive? I.e. are there no other RFCs with similar problems? Obviously, if there are others, then there should also be an Updates relationship to them. * 2.1.2 para 3 states that attributes can be allocated from standard or extended space. I believe we are at a point where the standard space is full and no allocations are made to standard space any more. I think the ambiguity in this paragraph has been overtaken by events and can simply go away. * 2.2 contains a link to "Section 2.6". That section does not exist; please update the link to point to something existing. * Section 3, last para is a bit confusing. You state that you do not create a data type for Location-Capable; but later in section 4, the data type "enum" is assigned to this attribute. Worse, the last sentence of the para speaks of "it's better to treat complex attributes as 'string= '". enum requires (MUST) all enumerated values to be defined. Looking at RFC5580, this is not really an enumeration, rather a bit field. 4 of the bits are defined, resulting in 16 different enumerated values, all of which need a unique name. Is that what you want to happen? Then the I-D at hand needs to make that enumerated list for Location-Capable since the original RFC did not. Or maybe this is actually a symptom of needing a data type "bit field" instead, where only the bits have a unique name? 3.8 ifid: any particular reason why interface IDs are limited to 8 octets length? Just wondering because I named the network interface of my workstation "workstation" and would not be able to use such a name in RADIUS with this definition. Looking at our firewall, we even have actual production interfaces with names such as "10G.privatetest" (for some VLAN). 3.10 Prefix - this appears to be variable length, and the length of the prefix is defined by Refix-Length. I don't understand why deployments are given the degree of freedom to decide whether they want to pad the prefix with trailing zeroes or not (which is enabled by the formulation "Bits outside of the Prefix-Length, ** if included **, MUST be zero.". Maybe that's just my naive thinking, but wouldn't it be more straightforward to mandate the Prefix sub-field to have exactly the length as specified in Prefix-Length, padded to *exactly* the next octet border? 3.11 Length is indicated as variable from 2 - 18 octets here. It looks to me like the max length possible is 4 octets (Prefix) + 1 octet (Reserved) + 6 bits (Prefix-Length), in total 5 octets and 6 bits. The Length description should be updated accordingly. As a second remark, I understand that the structure of the data types is taken from existing specs. However the structure of this data type is really awkward from a parsing point of view - fields delimited a full octet (like making Prefix-Length *8* bits long even if only values until 32 are used) would make the data type much prettier. * related to the same section: The RADIUS data type registry marks RFC6572 as the source of the ipv4prefix data type. I can't find a Prefix-Length which is 6 bit long in that RFC? Where exactly do I find the original 6-bit length in this complex data type? * 3.13: TLV-Length is (correctly) 3 or more octets, because TLV-Data must be at least one byte. An empty TLV-Data would lead to a TLV-Length of *2* though - but in this situation, the entire TLV is to be omitted. This makes the last sentence in the section a bit awkward: "TLVs having TLV-Length of zero (0) MUST NOT be sent; omit the entire TLV instead." This should either start with "TLVs having a TLV-Data of zero bytes length" or it should stat "TLVs having TLV-Length of two (2)" - both sentences are equivalent. * IANA considerations point to a wrong section: 3.1 is not the description of the new registry; you probably meant to xref to section 4.= 1. * same for the second para which should refer to 4.2, not 3.2. * 4.1: We occasionally make beauty contests for the numbers we assign ;-) So here is one: wouldn't it be much more pretty if "ipv4prefix" and "ipv4addr" were grouped together, like "ipv6prefix" and "ipv6addr" are? Since the "Value" column doesn't have an on-the-wire effect, it should be easy to shuffle those around. * I think we need to do something about "Acknowledgements" prior to sending this to IETF LC. The single word "Stuff" does not tell readers a whole lot ;-) * nit: s/Ascii/ASCII/g * nit: Section 3 : "We do not create specific data types for the 'tagged' attributes defines in" -> s/defines/defined/ I'm ending my review here, but will have another check of at least samples of all the attribute, data type and reference tuples in 4.2 at a later time. I guess some of the comments above will need a new I-D to tackle; I'll hold the shepherd write-up and the 4.2 checks until the new I-D is out. Greetings, Stefan Winter --=20 Stefan WINTER Ingenieur de Recherche Fondation RESTENA - R=C3=A9seau T=C3=A9l=C3=A9informatique de l'Education= Nationale et de la Recherche 2, avenue de l'Universit=C3=A9 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=3Dget&search=3D0xC0DE6A358A39DC66 --------------040600030204090905000503 Content-Type: application/pgp-keys; name="0x8A39DC66.asc" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="0x8A39DC66.asc" -----BEGIN PGP PUBLIC KEY BLOCK----- Version: GnuPG v2 mQINBFIplEwBEADTSz+DS8nio+RSvfSLLfaOnCGi1nqpn8Pb1laVUyEvnAAzZ5je miS88GxfiDH6hUGlWzcaW0hCfUHGiohr485adbjxRksPngWgAt/1bRxpifsW3zOb Fjgog01WWQV5Sihlwc4zr8zvYbFA5BJZ6YdkR9C5J015riv5OS30WTjA65SSXgYr b7zJWPwmegTFwE093uBFvC39waz3xYpVu5j87nO6w2MVQt/8sY2/2BFPEq+xfOaj l18UEwc7w8SCgnZdlVNcmEK4UBvJuwS/1lsR2JeQa8Gu1EDxC7PRgMgNXsDSWnnB e9aVmfG54+6ILe1QH2dwk9sPBQT5w2+vjijrb3Dv9ur+1kN+TNU2XE436jVpnnY/ 3OsLdix30STQn4Q/XOm7YoVMeDwwviefilRxzK0dXA+wKj92T68Od82CFxuZqPAg BCVmWfQM91iK9piqFK+QP+R3vF6+NGDBdwbe68iVKs0v5L8XmbxBQndjpmo+lo2a smBR2TAIfZHaKdgtBw13u3GPVVKlg/Mpko8ki9JOSem2aFyi3kQEVKptWgXT3POl 97DWJzsR5VyKz6GOx9kJAEISRyLZwm0wqh8+9LCza5oeIKW381lzq1b9x30vOh8C BSQQJ+cG9ko0yPHAj7Suw2TmPXx1qMctmE6Ahq82ZW30SljdZby8WQuR2wARAQAB tDxTdGVmYW4gV2ludGVyIChSRVNURU5BIGtleSAyMDEzKykgPHN0ZWZhbi53aW50 ZXJAcmVzdGVuYS5sdT6JAjkEEwECACMFAlIplEwCGwMHCwkIBwMCAQYVCAIJCgsE FgIDAQIeAQIXgAAKCRDA3mo1ijncZj7/D/99hVS+mJr8dSPCaDaUFFxBiT2eI1Lo R8VKEerTCRw5BsdL6pN2eRJZ9NmsqWo1ynWVHEzO91bNZ+oZGgyoNohcBAI7p+r0 qUTzkyqwdZO4kMm0pqKoM9xkP3tf2mjGujKjOz4Y7S7wnz2ZFokeUsecoRVJF/++ /qHnmeWLn44J1HUKLHYCjMu+QXGOgGXgz024jQ5eUrnPwzNp0Z90AFVHlWC+bymt y/ToIUUCQqS5Ff0jzdWLd8U695OG9iGvjBQT1LdEjsfbAwuKV5UcnpxNqUpUwKa5 9hdX5/2cMZP07FI1UXwnBlxa8rJfdb13FLjSKX4vUUHedYUZMjMPgcwl1a+zGE22 lHiSQWgP8QLA/W3BLsi22ERCEPZBfexOeOtaWIItDIz18fIaQoMDoRPshzar0JI2 CzLYsyeKySAtYJEHFVoLmMvhkwzBmgqA/BEswUA67CfCr1jFHRXdpmWM7YkyAmMa 9q6LwquWKS5+MXlUXe/3oZUcgpw/T9Uuy3Jo3RdS7B3jFcWaVr6KsO/A9u1gr/aY n5M+iJTQSj4vzqtkQaJTpSspRZoKa66HZt3IwSYiDiYZqtM83ynuj9kjnZzGfnuT aNIi996q6Mptr33mOzIE1wmMqnJYwTr3EcNtf483q/qrJwh5ES8Q9xY7aat/ZcSl 8fKubW4TlfVr8YhGBBARAgAGBQJSKZUGAAoJEPo5vdH/HhVmYTgAn24eoqO/O98o vNpt08Uab/+/tmYKAJ9kjXm9Njz5h33efzeelZUa484rr7kCDQRSKZRMARAAvBPp n7FQq7LQ5glohtbL6XIEo1U4X67S0TzUYieENSWSVYuWYIhCBldmWdmH8Bpj/qHe qdon7v+SLtR4WngzMR9toupKcFfHnbP9kpazTSB2ySHxXWGX1gJOpPXdCcg9iveK BHEsDn00ThTcPsvtXpnnzET16pXIvOXO0bxTmVZ4INIF1SWgvYma/g8kBbgXLpkj 8tOywBqFiiYPEZlDeCxDHiMgUDh6olda9K/0TZFTdMPUgjKuubfAeaDNCOrVt4Rj mFOaRLikcZocmgJhm3z/j25x7/mnNu+0di1H/S67YGQJ+pqCFInzIXDx7aRW2+JC iqsY2X3xOPWZZzjyis5SNnfOcPH3gt2hYz1fy+thsBGf4NgCN01JRqIJ2/MOQCgU dwh+9l8xqaJvCkUHM4hVh4W62MAe1u7UEqQbvvNEqxM5034vcvlE+/LRkrDCspw+ 2YJ9QyroLerVRwW5DVleP8Ifi8VB3yD80nqXYs9aqRy0BkDNIQ43ERhESMt8dJqr NkxgC6pemZrhNwyDh+hy2kPNGQh/iBpdKuH1o3E24TIZoV2v3YHvzob7aAYHddE/ PofAXhJW7I9mAs+HdWDmnI8ckuPDFpFH+Y/BFGvEXgcnJAJ1wEvf+4LuiIi0MHjR 4EWFn9vvoFDAIqD10h3FSd3D59HGtdSsNn4XaCsAEQEAAYkCHwQYAQIACQUCUimU TAIbDAAKCRDA3mo1ijncZhBtEACL036ddjc5pFoYIdoUY1vT8SMXJNquewCnL1qu DADzqDZFU5GNlQEy10krSfBwlTb9ahTtE0JFrOdZwUZtoa1Pgfr8nU6KOgrXPHbN jS/9dyc5CwGVVIpOavIm2CsMVDJ9LCF/NT+u/t1k6eGfHhPVl3dUQyDa/lzc1chK UIVQYQkFmr0A/iXP+29lFCaI+IeyU0bSdZhezDwUROn5vEx+fiPZyHDShCb+BxJv /o2LQp9JHenCiSbO+ioRZdxgbWfoKBuXOfmSStqMWXas/gZ5vS3xq72LNtKPRxgp jX3P8Zml1XDqpcBau7eK75VKE0Yd06YxnUIsbcEzInUc3uzW/u0DFpXYkMJb0XIv JyUt5yYPKfV13N8kSkPi5pLxm8yuftXMzfgeFMR7nafY3glTVj/TxElzg6xeZNqf C2ZjIbBtZg9ylHU8u8wwB+dX282crs0R3N9A064C71/cXlBqcjzjlKH2NUIWGxr+ od3TXFIFjszSU3NgMPKrWNhFLLwS81MpbkOe73s6aDhS8RDyNucoxtKXriLR+4Xi u4+pyj5ukYP1JqpB3ZobY/XZgCnJMye+7xeTpIDJ1LPORxM3NNAElyb26lxAK2P+ km+EpI0Zzz6rNSCfg5jYQ474+e/GBgaSG4MlaPoZ+XAfN46u1Xjjv1/AkkA4IA6m 5zP5og=3D=3D =3D3NUt -----END PGP PUBLIC KEY BLOCK----- --------------040600030204090905000503-- --iwSXgtKvAqp3sVDUvQOiOifNLGK11f3c6-- --bVwKh9QoJKUaCwwecvRinRmxkD6dcUwnh Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCgAGBQJXKK3YAAoJEMDeajWKOdxmVQIQALxJgvPTkztcnSwhTdn+RU3g Bk8QOXkZ3NGvRXlHVokYCJf68lUxwBnnML0BBIs8KiXrj9Z++lFe5rkIwutBbqZl 336JIJAMmp28ATNMNOliZ7s3uGZsHda8aZHiElR/k5x8j6BeXlKbx6YyYvP1wqXt K9uaeddkdDMijlL+E7NFCa6STqbEcFwSpco5QG2Vsl+u1aX9QlgKWazlGb3Rzq4v wwC7el6bCjRY7Kx+NYjaJgUOIMONKRktarIrK/kjqtDduoOnZWEBmB/ljyZcBjbD +Omgbmc0jjNn3yVUtngx+hWJ9TPRkgtAmH7kejX7rauf3/6+ABji8Ler3YPQM9PQ 3t002Pv9Cwz/BLa92u2vTh+/zxwdti3NWoPa1fMu1AZrKKKofc0GejRUuI6irZH6 1OiD80qOR+D3nq8kObuH55phKk38a8c4oalqsSFmzjIqLPSkQOJ9X9VnmJwsXqJg 87HY36J87yev0U3lqAEkykJ7Y2VwjUm/KY6QTkLZF3+blEZTKYW2CfwupUgMkyNo LFb6jCMOpbDiFxXbkg5TllJ2pmA0zaaioC44Tf7anLvCxlpr/CRm5+imj/Xx9GQw tVx8OiGflo2z9wLlHoKRF8JDncIZ9PrikMGMKWZ/i7UjjLvtQzIjzD/hdDwkOBeC bL6/KfIimevhxMDyIA35 =/p5y -----END PGP SIGNATURE----- --bVwKh9QoJKUaCwwecvRinRmxkD6dcUwnh-- From nobody Fri May 6 01:28:24 2016 Return-Path: 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 D218C12D143 for ; Fri, 6 May 2016 01:28:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.896 X-Spam-Level: X-Spam-Status: No, score=-7.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.996] 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 a2s3oK3FpuPg for ; Fri, 6 May 2016 01:28:20 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:123a::1:2a]) (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 2099712B03B for ; Fri, 6 May 2016 01:28:20 -0700 (PDT) Received: from localhost ([::1]:47381 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1ayb7Q-0002Sx-7L; Fri, 06 May 2016 01:28:16 -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.5 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.5, by Edgewall Software To: draft-ietf-radext-bigger-packets@tools.ietf.org, stefan.winter@restena.lu X-Trac-Project: radext Date: Fri, 06 May 2016 08:28:16 -0000 X-URL: https://tools.ietf.org/radext/ X-Trac-Ticket-URL: https://tools.ietf.org/wg/radext/trac/ticket/197#comment:1 Message-ID: <081.8988d2b62bb23e8ebd7ee3373d8be4a5@trac.tools.ietf.org> References: <066.c80912806059cac04d81d7d5f8c61136@trac.tools.ietf.org> X-Trac-Ticket-ID: 197 In-Reply-To: <066.c80912806059cac04d81d7d5f8c61136@trac.tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: draft-ietf-radext-bigger-packets@tools.ietf.org, stefan.winter@restena.lu, radext@ietf.org X-SA-Exim-Mail-From: trac+radext@trac.tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Resent-To: draft-ietf-radext-bigger-packets@ietf.org Resent-Message-Id: <20160506082820.2099712B03B@ietfa.amsl.com> Resent-Date: Fri, 6 May 2016 01:28:20 -0700 (PDT) Resent-From: trac+radext@trac.tools.ietf.org Archived-At: Cc: radext@ietf.org Subject: Re: [radext] #197 (bigger-packets): idnits comments for resolution with other IETF LC comments X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.17 Reply-To: radext@ietf.org List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 May 2016 08:28:22 -0000 #197: idnits comments for resolution with other IETF LC comments Changes (by stefan.winter@restena.lu): * status: new => closed * resolution: => fixed -- -------------------------------------+------------------------------------- Reporter: | Owner: draft-ietf-radext- stefan.winter@restena.lu | bigger-packets@tools.ietf.org Type: defect | Status: closed Priority: major | Milestone: Component: bigger-packets | Version: Severity: - | Resolution: fixed Keywords: | -------------------------------------+------------------------------------- Ticket URL: radext From nobody Fri May 6 01:41:50 2016 Return-Path: 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 729C912D1C9 for ; Fri, 6 May 2016 01:41:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.896 X-Spam-Level: X-Spam-Status: No, score=-7.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.996] autolearn=unavailable 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 8Gxgu965Pto6 for ; Fri, 6 May 2016 01:41:47 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:123a::1:2a]) (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 3897E12D18F for ; Fri, 6 May 2016 01:41:46 -0700 (PDT) Received: from localhost ([::1]:47702 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1aybKT-0002lu-UT; Fri, 06 May 2016 01:41:45 -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.5 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.5, by Edgewall Software To: draft-ietf-radext-bigger-packets@tools.ietf.org, stefan.winter@restena.lu X-Trac-Project: radext Date: Fri, 06 May 2016 08:41:45 -0000 X-URL: https://tools.ietf.org/radext/ X-Trac-Ticket-URL: https://tools.ietf.org/wg/radext/trac/ticket/198#comment:1 Message-ID: <081.2f56e070d289912a6bab104e1339bd83@trac.tools.ietf.org> References: <066.26d096299c5aef68d5a33f996b6b4144@trac.tools.ietf.org> X-Trac-Ticket-ID: 198 In-Reply-To: <066.26d096299c5aef68d5a33f996b6b4144@trac.tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: draft-ietf-radext-bigger-packets@tools.ietf.org, stefan.winter@restena.lu, radext@ietf.org X-SA-Exim-Mail-From: trac+radext@trac.tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Resent-To: draft-ietf-radext-bigger-packets@ietf.org Resent-Message-Id: <20160506084146.3897E12D18F@ietfa.amsl.com> Resent-Date: Fri, 6 May 2016 01:41:46 -0700 (PDT) Resent-From: trac+radext@trac.tools.ietf.org Archived-At: Cc: radext@ietf.org Subject: Re: [radext] #198 (bigger-packets): track secdir review comments X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.17 Reply-To: radext@ietf.org List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 May 2016 08:41:48 -0000 #198: track secdir review comments Changes (by stefan.winter@restena.lu): * status: new => closed * resolution: => fixed -- -------------------------------------+------------------------------------- Reporter: | Owner: draft-ietf-radext- stefan.winter@restena.lu | bigger-packets@tools.ietf.org Type: defect | Status: closed Priority: major | Milestone: Component: bigger-packets | Version: Severity: - | Resolution: fixed Keywords: | -------------------------------------+------------------------------------- Ticket URL: radext From nobody Fri May 6 17:44:43 2016 Return-Path: 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 9E59912D595 for ; Fri, 6 May 2016 17:44:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 KhbggE50CSw4 for ; Fri, 6 May 2016 17:44:39 -0700 (PDT) Received: from mail.networkradius.com (mail.networkradius.com [62.210.147.122]) by ietfa.amsl.com (Postfix) with ESMTP id BDB2E12D175 for ; Fri, 6 May 2016 17:44:39 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.networkradius.com (Postfix) with ESMTP id C1A5E1D47; Sat, 7 May 2016 00:44:38 +0000 (UTC) Received: from mail.networkradius.com ([127.0.0.1]) by localhost (mail-server.vmhost2.networkradius.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MbdpRPx3y2sQ; Sat, 7 May 2016 00:44:38 +0000 (UTC) Received: from [192.168.120.42] (unknown [23.233.24.114]) by mail.networkradius.com (Postfix) with ESMTPSA id 17AFC130E; Sat, 7 May 2016 00:44:37 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) From: Alan DeKok In-Reply-To: <5728ADD7.80509@restena.lu> Date: Fri, 6 May 2016 20:44:35 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <4608D6C5-268F-42C7-9C25-4DA241DAA5D2@deployingradius.com> References: <5728ADD7.80509@restena.lu> To: Winter Stefan X-Mailer: Apple Mail (2.3112) Archived-At: Cc: "radext@ietf.org" Subject: Re: [radext] Review of draft-ietf-radext-datatypes-02 X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 May 2016 00:44:42 -0000 On May 3, 2016, at 9:55 AM, Stefan Winter = wrote: > * The introduction mentions a number of "war stories" of = specifications > that have left data type gaps or introduced ambiguities. The I-D > correspondingly has an Updates relationship to these RFCs. I wonder: = is > this list meant to be exhaustive? I.e. are there no other RFCs with > similar problems? Obviously, if there are others, then there should = also > be an Updates relationship to them. The "Updates" line should reference all RFCs it updates. Mainly the = ones which have incomplete and/or inconsistent data types. But to be pedantic, the document updates *all* RFCs which define a = RADIUS attribute. It has to do this (arguably) in order to define a = data type for each attribute. Exactly what goes into the "Updates" line is a subject best left for = the list. > * 2.1.2 para 3 states that attributes can be allocated from standard = or > extended space. I believe we are at a point where the standard space = is > full and no allocations are made to standard space any more. I think = the > ambiguity in this paragraph has been overtaken by events and can = simply > go away. Point taken. I'll re-word it. > * 2.2 contains a link to "Section 2.6". That section does not exist; > please update the link to point to something existing. That should be Section 3.6 > * Section 3, last para is a bit confusing. You state that you do not > create a data type for Location-Capable; That reference should be to "Location-Information", which addresses = the later comments. > 3.8 ifid: any particular reason why interface IDs are limited to 8 > octets length? RFC 4291 Section 2.5.1 https://tools.ietf.org/html/rfc4291#section-2.5.1 > Just wondering because I named Local interface names are not "interface identifiers". > 3.10 Prefix - this appears to be variable length, and the length of = the > prefix is defined by Refix-Length. > I don't understand why deployments are given the degree of freedom to > decide whether they want to pad the prefix with trailing zeroes or not > (which is enabled by the formulation "Bits outside of the = Prefix-Length, ** if included **, MUST be zero.". Maybe that's just my naive = thinking, > but wouldn't it be more straightforward to mandate the Prefix = sub-field > to have exactly the length as specified in Prefix-Length, padded to > *exactly* the next octet border? The definition mirrors RFC 3162 I didn't want to re-define it in an = incompatible way here. > 3.11 Length is indicated as variable from 2 - 18 octets here. It looks > to me like the max length possible is 4 octets (Prefix) + 1 octet > (Reserved) + 6 bits (Prefix-Length), in total 5 octets and 6 bits. The > Length description should be updated accordingly. That's a cut & paste error from Section 3.10. Length for ipv4prefix = should be fixed to 6 octets, as per RFC 6572 Section 4.12. https://tools.ietf.org/html/rfc6572#section-4.12 > As a second remark, I understand that the structure of the data types = is > taken from existing specs. However the structure of this data type is > really awkward from a parsing point of view - fields delimited a full > octet (like making Prefix-Length *8* bits long even if only values = until > 32 are used) would make the data type much prettier. I think that's a safe change to make here. > * related to the same section: The RADIUS data type registry marks > RFC6572 as the source of the ipv4prefix data type. I can't find a > Prefix-Length which is 6 bit long in that RFC? Where exactly do I find > the original 6-bit length in this complex data type? RFC 6572. To be realistic... I think it's OK to update the "Reserved" field to = be 8 bits instead of 10. And to increase the size of the = "Prefix-Length" field to be 8 bits instead of 6, with the upper 2 bits = mandated to be zero. > * 3.13: TLV-Length is (correctly) 3 or more octets, because TLV-Data > must be at least one byte. An empty TLV-Data would lead to a = TLV-Length > of *2* though - but in this situation, the entire TLV is to be = omitted. > This makes the last sentence in the section a bit awkward: > "TLVs having TLV-Length of zero (0) MUST NOT be sent; omit the entire > TLV instead." > This should either start with "TLVs having a TLV-Data of zero bytes > length" or it should stat "TLVs having TLV-Length of two (2)" - both > sentences are equivalent. I'll use the second phrasing. > * IANA considerations point to a wrong section: 3.1 is not the > description of the new registry; you probably meant to xref to section = 4.1. Fixed. > * same for the second para which should refer to 4.2, not 3.2 Fixed. > * 4.1: We occasionally make beauty contests for the numbers we assign > ;-) So here is one: wouldn't it be much more pretty if "ipv4prefix" = and > "ipv4addr" were grouped together, like "ipv6prefix" and "ipv6addr" = are? > Since the "Value" column doesn't have an on-the-wire effect, it should > be easy to shuffle those around. Sure... the intention was mostly to define simple types before complex = types. But that's fine. > * I think we need to do something about "Acknowledgements" prior to > sending this to IETF LC. The single word "Stuff" does not tell readers = a > whole lot ;-) Fixed. > * nit: s/Ascii/ASCII/g Fixed. > * nit: Section 3 : "We do not create specific data types for the > 'tagged' attributes defines in" -> s/defines/defined/ Fixed. > I'm ending my review here, but will have another check of at least > samples of all the attribute, data type and reference tuples in 4.2 at = a > later time. Yes. The "integer" and "ipv4addr" ones should be fine. The "octets" and = "string" ones may be harder... I picked things which make sense, but... = that's just my $0.02. > I guess some of the comments above will need a new I-D to tackle; I'll > hold the shepherd write-up and the 4.2 checks until the new I-D is = out. Done (momentarily) Alan DeKok. From nobody Fri May 6 17:56:42 2016 Return-Path: X-Original-To: radext@ietf.org Delivered-To: radext@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 80B5E12B014; Fri, 6 May 2016 17:56:38 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.20.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160507005638.7360.27664.idtracker@ietfa.amsl.com> Date: Fri, 06 May 2016 17:56:38 -0700 Archived-At: Cc: radext@ietf.org Subject: [radext] I-D Action: draft-ietf-radext-datatypes-03.txt X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.17 List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 May 2016 00:56:38 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the RADIUS EXTensions of the IETF. Title : Data Types in the Remote Authentication Dial-In User Service Protocol (RADIUS) Author : Alan DeKok Filename : draft-ietf-radext-datatypes-03.txt Pages : 37 Date : 2016-05-06 Abstract: RADIUS specifications have used data types for two decades without defining them as managed entities. During this time, RADIUS implementations have named the data types, and have used them in attribute definitions. This document updates the specifications to better follow established practice. We do this by naming the data types defined in RFC 6158, which have been used since at least RFC 2865. We provide an IANA registry for the data types, and update the RADIUS Attribute Type registry to include a "Data Type" field for each attribute. Finally, we recommend that authors of RADIUS specifications use these types in preference to existing practice. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-radext-datatypes/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-radext-datatypes-03 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-radext-datatypes-03 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon May 9 00:15:08 2016 Return-Path: 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 7F81F12B074 for ; Mon, 9 May 2016 00:15:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.895 X-Spam-Level: X-Spam-Status: No, score=-2.895 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.996, WEIRD_PORT=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 yxgFkZbKh7NE for ; Mon, 9 May 2016 00:15:04 -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 EE9DB12B05E for ; Mon, 9 May 2016 00:15:01 -0700 (PDT) Received: from aragorn.restena.lu (aragorn.restena.lu [IPv6:2001:a18:1:8::155]) by smtprelay.restena.lu (Postfix) with ESMTPS id 31BA143AB6 for ; Mon, 9 May 2016 09:15:00 +0200 (CEST) To: radext@ietf.org References: <5728ADD7.80509@restena.lu> <4608D6C5-268F-42C7-9C25-4DA241DAA5D2@deployingradius.com> From: Stefan Winter Openpgp: id=AD3091F3AB24E05F4F722C03C0DE6A358A39DC66; url=http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xC0DE6A358A39DC66 Message-ID: <573038F4.2040505@restena.lu> Date: Mon, 9 May 2016 09:15:00 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.7.0 MIME-Version: 1.0 In-Reply-To: <4608D6C5-268F-42C7-9C25-4DA241DAA5D2@deployingradius.com> Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="qjkuRNqFIwhV5aE57BGU4ha8IdsIbLivL" Archived-At: Subject: Re: [radext] Review of draft-ietf-radext-datatypes-02 X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 May 2016 07:15:07 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --qjkuRNqFIwhV5aE57BGU4ha8IdsIbLivL Content-Type: multipart/mixed; boundary="LMoMbFVVjmX4hqvhCppkrEh0KiWCE5HQx" From: Stefan Winter To: radext@ietf.org Message-ID: <573038F4.2040505@restena.lu> Subject: Re: [radext] Review of draft-ietf-radext-datatypes-02 References: <5728ADD7.80509@restena.lu> <4608D6C5-268F-42C7-9C25-4DA241DAA5D2@deployingradius.com> In-Reply-To: <4608D6C5-268F-42C7-9C25-4DA241DAA5D2@deployingradius.com> --LMoMbFVVjmX4hqvhCppkrEh0KiWCE5HQx Content-Type: multipart/mixed; boundary="------------030907090106090406030903" This is a multi-part message in MIME format. --------------030907090106090406030903 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hi, >> * The introduction mentions a number of "war stories" of specification= s >> that have left data type gaps or introduced ambiguities. The I-D >> correspondingly has an Updates relationship to these RFCs. I wonder: i= s >> this list meant to be exhaustive? I.e. are there no other RFCs with >> similar problems? Obviously, if there are others, then there should al= so >> be an Updates relationship to them. > The "Updates" line should reference all RFCs it updates. Mainly the = ones which have incomplete and/or inconsistent data types. > > But to be pedantic, the document updates *all* RFCs which define a RA= DIUS attribute. It has to do this (arguably) in order to define a data t= ype for each attribute. > > Exactly what goes into the "Updates" line is a subject best left for = the list. Good point. FWIW, my take on it is: * if the only update to an attribute is the addition of the "data type" column, that's a trivial case and does not warrant an Updates relationshi= p. * everything else does. >> * Section 3, last para is a bit confusing. You state that you do not >> create a data type for Location-Capable; > That reference should be to "Location-Information", which addresses t= he later comments. most of them, yes. One point remains, now only pertaining to the mention of Location-Capable in section 4, where it's an "enum": This part of my review still isn't covered IMHO: "Looking at RFC5580, this is not really an enumeration, rather a bit field. 4 of the bits are defined, resulting in 16 different enumerated values, all of which need a unique name. Is that what you want to happen? Then the I-D at hand needs to make that enumerated list for Location-Capable since the original RFC did not. Or maybe this is actually a symptom of needing a data type "bit field" instead, where only the bits have a unique name?" > Local interface names are not "interface identifiers".=20 Thanks. That explains it nicely :-) >> 3.10 Prefix - this appears to be variable length, and the length of th= e >> prefix is defined by Refix-Length. >> I don't understand why deployments are given the degree of freedom to >> decide whether they want to pad the prefix with trailing zeroes or not= >> (which is enabled by the formulation "Bits outside of the Prefix-Lengt= h,> ** if included **, MUST be zero.". Maybe that's just my naive thinking= , >> but wouldn't it be more straightforward to mandate the Prefix sub-fiel= d >> to have exactly the length as specified in Prefix-Length, padded to >> *exactly* the next octet border? > The definition mirrors RFC 3162 I didn't want to re-define it in an = incompatible way here. Ok. >> 3.11 Length is indicated as variable from 2 - 18 octets here. It looks= >> to me like the max length possible is 4 octets (Prefix) + 1 octet >> (Reserved) + 6 bits (Prefix-Length), in total 5 octets and 6 bits. The= >> Length description should be updated accordingly. > That's a cut & paste error from Section 3.10. Length for ipv4prefix = should be fixed to 6 octets, as per RFC 6572 Section 4.12. > > https://tools.ietf.org/html/rfc6572#section-4.12 > >> As a second remark, I understand that the structure of the data types = is >> taken from existing specs. However the structure of this data type is >> really awkward from a parsing point of view - fields delimited a full >> octet (like making Prefix-Length *8* bits long even if only values unt= il >> 32 are used) would make the data type much prettier. > I think that's a safe change to make here. Great. > To be realistic... I think it's OK to update the "Reserved" field to = be 8 bits instead of 10. And to increase the size of the "Prefix-Length"= field to be 8 bits instead of 6, with the upper 2 bits mandated to be ze= ro. Definitely looks like a better choice parsing-wise. I guess if the PMIP people have a problem with that backwards-compatible change, they can complain during IETF LC. Do you want to explain why the difference in definition is a non-difference; or shall I just add a note to the shepherd review in case this comes up later? As one last comment on -03: you introduced a new nit :-) s/esstentially/essentially/ Greetings, Stefan Winter --=20 Stefan WINTER Ingenieur de Recherche Fondation RESTENA - R=E9seau T=E9l=E9informatique de l'Education National= e et de la Recherche 2, avenue de l'Universit=E9 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 recipie= nt's key is known to me http://pgp.mit.edu:11371/pks/lookup?op=3Dget&search=3D0xC0DE6A358A39DC66 --------------030907090106090406030903 Content-Type: application/pgp-keys; name="0x8A39DC66.asc" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="0x8A39DC66.asc" -----BEGIN PGP PUBLIC KEY BLOCK----- Version: GnuPG v2 mQINBFIplEwBEADTSz+DS8nio+RSvfSLLfaOnCGi1nqpn8Pb1laVUyEvnAAzZ5je miS88GxfiDH6hUGlWzcaW0hCfUHGiohr485adbjxRksPngWgAt/1bRxpifsW3zOb Fjgog01WWQV5Sihlwc4zr8zvYbFA5BJZ6YdkR9C5J015riv5OS30WTjA65SSXgYr b7zJWPwmegTFwE093uBFvC39waz3xYpVu5j87nO6w2MVQt/8sY2/2BFPEq+xfOaj l18UEwc7w8SCgnZdlVNcmEK4UBvJuwS/1lsR2JeQa8Gu1EDxC7PRgMgNXsDSWnnB e9aVmfG54+6ILe1QH2dwk9sPBQT5w2+vjijrb3Dv9ur+1kN+TNU2XE436jVpnnY/ 3OsLdix30STQn4Q/XOm7YoVMeDwwviefilRxzK0dXA+wKj92T68Od82CFxuZqPAg BCVmWfQM91iK9piqFK+QP+R3vF6+NGDBdwbe68iVKs0v5L8XmbxBQndjpmo+lo2a smBR2TAIfZHaKdgtBw13u3GPVVKlg/Mpko8ki9JOSem2aFyi3kQEVKptWgXT3POl 97DWJzsR5VyKz6GOx9kJAEISRyLZwm0wqh8+9LCza5oeIKW381lzq1b9x30vOh8C BSQQJ+cG9ko0yPHAj7Suw2TmPXx1qMctmE6Ahq82ZW30SljdZby8WQuR2wARAQAB tDxTdGVmYW4gV2ludGVyIChSRVNURU5BIGtleSAyMDEzKykgPHN0ZWZhbi53aW50 ZXJAcmVzdGVuYS5sdT6JAjkEEwECACMFAlIplEwCGwMHCwkIBwMCAQYVCAIJCgsE FgIDAQIeAQIXgAAKCRDA3mo1ijncZj7/D/99hVS+mJr8dSPCaDaUFFxBiT2eI1Lo R8VKEerTCRw5BsdL6pN2eRJZ9NmsqWo1ynWVHEzO91bNZ+oZGgyoNohcBAI7p+r0 qUTzkyqwdZO4kMm0pqKoM9xkP3tf2mjGujKjOz4Y7S7wnz2ZFokeUsecoRVJF/++ /qHnmeWLn44J1HUKLHYCjMu+QXGOgGXgz024jQ5eUrnPwzNp0Z90AFVHlWC+bymt y/ToIUUCQqS5Ff0jzdWLd8U695OG9iGvjBQT1LdEjsfbAwuKV5UcnpxNqUpUwKa5 9hdX5/2cMZP07FI1UXwnBlxa8rJfdb13FLjSKX4vUUHedYUZMjMPgcwl1a+zGE22 lHiSQWgP8QLA/W3BLsi22ERCEPZBfexOeOtaWIItDIz18fIaQoMDoRPshzar0JI2 CzLYsyeKySAtYJEHFVoLmMvhkwzBmgqA/BEswUA67CfCr1jFHRXdpmWM7YkyAmMa 9q6LwquWKS5+MXlUXe/3oZUcgpw/T9Uuy3Jo3RdS7B3jFcWaVr6KsO/A9u1gr/aY n5M+iJTQSj4vzqtkQaJTpSspRZoKa66HZt3IwSYiDiYZqtM83ynuj9kjnZzGfnuT aNIi996q6Mptr33mOzIE1wmMqnJYwTr3EcNtf483q/qrJwh5ES8Q9xY7aat/ZcSl 8fKubW4TlfVr8YhGBBARAgAGBQJSKZUGAAoJEPo5vdH/HhVmYTgAn24eoqO/O98o vNpt08Uab/+/tmYKAJ9kjXm9Njz5h33efzeelZUa484rr7kCDQRSKZRMARAAvBPp n7FQq7LQ5glohtbL6XIEo1U4X67S0TzUYieENSWSVYuWYIhCBldmWdmH8Bpj/qHe qdon7v+SLtR4WngzMR9toupKcFfHnbP9kpazTSB2ySHxXWGX1gJOpPXdCcg9iveK BHEsDn00ThTcPsvtXpnnzET16pXIvOXO0bxTmVZ4INIF1SWgvYma/g8kBbgXLpkj 8tOywBqFiiYPEZlDeCxDHiMgUDh6olda9K/0TZFTdMPUgjKuubfAeaDNCOrVt4Rj mFOaRLikcZocmgJhm3z/j25x7/mnNu+0di1H/S67YGQJ+pqCFInzIXDx7aRW2+JC iqsY2X3xOPWZZzjyis5SNnfOcPH3gt2hYz1fy+thsBGf4NgCN01JRqIJ2/MOQCgU dwh+9l8xqaJvCkUHM4hVh4W62MAe1u7UEqQbvvNEqxM5034vcvlE+/LRkrDCspw+ 2YJ9QyroLerVRwW5DVleP8Ifi8VB3yD80nqXYs9aqRy0BkDNIQ43ERhESMt8dJqr NkxgC6pemZrhNwyDh+hy2kPNGQh/iBpdKuH1o3E24TIZoV2v3YHvzob7aAYHddE/ PofAXhJW7I9mAs+HdWDmnI8ckuPDFpFH+Y/BFGvEXgcnJAJ1wEvf+4LuiIi0MHjR 4EWFn9vvoFDAIqD10h3FSd3D59HGtdSsNn4XaCsAEQEAAYkCHwQYAQIACQUCUimU TAIbDAAKCRDA3mo1ijncZhBtEACL036ddjc5pFoYIdoUY1vT8SMXJNquewCnL1qu DADzqDZFU5GNlQEy10krSfBwlTb9ahTtE0JFrOdZwUZtoa1Pgfr8nU6KOgrXPHbN jS/9dyc5CwGVVIpOavIm2CsMVDJ9LCF/NT+u/t1k6eGfHhPVl3dUQyDa/lzc1chK UIVQYQkFmr0A/iXP+29lFCaI+IeyU0bSdZhezDwUROn5vEx+fiPZyHDShCb+BxJv /o2LQp9JHenCiSbO+ioRZdxgbWfoKBuXOfmSStqMWXas/gZ5vS3xq72LNtKPRxgp jX3P8Zml1XDqpcBau7eK75VKE0Yd06YxnUIsbcEzInUc3uzW/u0DFpXYkMJb0XIv JyUt5yYPKfV13N8kSkPi5pLxm8yuftXMzfgeFMR7nafY3glTVj/TxElzg6xeZNqf C2ZjIbBtZg9ylHU8u8wwB+dX282crs0R3N9A064C71/cXlBqcjzjlKH2NUIWGxr+ od3TXFIFjszSU3NgMPKrWNhFLLwS81MpbkOe73s6aDhS8RDyNucoxtKXriLR+4Xi u4+pyj5ukYP1JqpB3ZobY/XZgCnJMye+7xeTpIDJ1LPORxM3NNAElyb26lxAK2P+ km+EpI0Zzz6rNSCfg5jYQ474+e/GBgaSG4MlaPoZ+XAfN46u1Xjjv1/AkkA4IA6m 5zP5og=3D=3D =3D3NUt -----END PGP PUBLIC KEY BLOCK----- --------------030907090106090406030903-- --LMoMbFVVjmX4hqvhCppkrEh0KiWCE5HQx-- --qjkuRNqFIwhV5aE57BGU4ha8IdsIbLivL Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCgAGBQJXMDj0AAoJEMDeajWKOdxmqMgP/iegQjHlLvYLkJb4QgtnvKLT 2iS7B6Rv6Fee+xwf3NYEK1PPfjiU7yPLMeo/AI5T6EabolQuIhjaP6X+na/BIHX7 xz0RifIz4Yw8zVnFN8fLSI49UiM2K747V63KwpDi/1TMcSBY1gpNnPqwmuOAtrCq /KFWiayHGUBFJcoVld+hltOzsA7+CVrIjNl/FJBFffdxIvrh55332D4PUNVGjVnO iomrQbxKM2AOyDGQzrcCWtsT9hvsx7EsTFXcx1poRO5OkKfNFCxh5BB6F0ZG6iXH eW86cnozA6iAg98+OJQElPPi9WUxpJhtWI1N7bZR+z+qkaRmZ79kXC3RDBSWyuFo fuGWmzD18zfNdL+luSbS7EUmU/QeDU9Zp3ogG7S0Nr5r71gBAUXb7/5X12qVCc9C 1P2Alxp9SfBsUXbgRjHRX/6NU+xRUU7HaBuoZfebzG1w6kPFL085UrBIIZPjbhsc lo+gVxof91LY2c08Dt6kBCU6G5OgbAX1qrhW8c9k187FwImqOZx0wgWUJcMKF0oL 0d+w2rx3Tt7QczvAK7iCGsoIDqpuvHWuWDdOVHr9VuAR26ZbIdowAgS1PmG7HIwA WbTLcBZsaQNQDAmWRxQgs2lM9lx8sRDe8h4i3VuqNOzVjTgCD4U89iDgH68HuYU1 KOXsBM2DX40opR+V4/sA =45we -----END PGP SIGNATURE----- --qjkuRNqFIwhV5aE57BGU4ha8IdsIbLivL-- From nobody Tue May 10 06:43:44 2016 Return-Path: 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 EA11712D187 for ; Tue, 10 May 2016 06:43:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 cYwQKD8bTUpW for ; Tue, 10 May 2016 06:43:39 -0700 (PDT) Received: from mail.networkradius.com (mail.networkradius.com [62.210.147.122]) by ietfa.amsl.com (Postfix) with ESMTP id A064412D17C for ; Tue, 10 May 2016 06:43:39 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.networkradius.com (Postfix) with ESMTP id D3D62A6C; Tue, 10 May 2016 13:43:38 +0000 (UTC) Received: from mail.networkradius.com ([127.0.0.1]) by localhost (mail-server.vmhost2.networkradius.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aX-LtXuXY9Zi; Tue, 10 May 2016 13:43:38 +0000 (UTC) Received: from [192.168.20.14] (69-196-165-104.dsl.teksavvy.com [69.196.165.104]) by mail.networkradius.com (Postfix) with ESMTPSA id 60F88AC; Tue, 10 May 2016 13:43:38 +0000 (UTC) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) From: Alan DeKok In-Reply-To: <573038F4.2040505@restena.lu> Date: Tue, 10 May 2016 09:43:37 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <69188D9F-C4E9-4624-96F3-EDC8EEBA061F@deployingradius.com> References: <5728ADD7.80509@restena.lu> <4608D6C5-268F-42C7-9C25-4DA241DAA5D2@deployingradius.com> <573038F4.2040505@restena.lu> To: Winter Stefan X-Mailer: Apple Mail (2.3112) Archived-At: Cc: radext@ietf.org Subject: Re: [radext] Review of draft-ietf-radext-datatypes-02 X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 May 2016 13:43:42 -0000 On May 9, 2016, at 3:15 AM, Stefan Winter = wrote: > Good point. FWIW, my take on it is: >=20 > * if the only update to an attribute is the addition of the "data = type" > column, that's a trivial case and does not warrant an Updates = relationship. > * everything else does. Sounds good to me. I'll take a look through the draft. > This part of my review still isn't covered IMHO: >=20 > "Looking at > RFC5580, this is not really an enumeration, rather a bit field. 4 of = the > bits are defined, resulting in 16 different enumerated values, all of > which need a unique name. Is that what you want to happen? Then the = I-D > at hand needs to make that enumerated list for Location-Capable since > the original RFC did not. > Or maybe this is actually a symptom of needing a data type "bit field" > instead, where only the bits have a unique name?" No, it's probably best to just make it an "integer" type. >> To be realistic... I think it's OK to update the "Reserved" field to = be 8 bits instead of 10. And to increase the size of the = "Prefix-Length" field to be 8 bits instead of 6, with the upper 2 bits = mandated to be zero. >=20 > Definitely looks like a better choice parsing-wise. I guess if the = PMIP > people have a problem with that backwards-compatible change, they can > complain during IETF LC. Yes. > Do you want to explain why the difference in definition is a > non-difference; or shall I just add a note to the shepherd review in > case this comes up later? I'll add a note to the document. > As one last comment on -03: you introduced a new nit :-) >=20 > s/esstentially/essentially/ Fixed, thanks. Alan DeKok. From nobody Wed May 18 00:49:46 2016 Return-Path: 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 95A1A12D14C; Wed, 18 May 2016 00:49:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -108.328 X-Spam-Level: X-Spam-Status: No, score=-108.328 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-1.426, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] 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 2K9H8p5AKFCq; Wed, 18 May 2016 00:49:37 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BC97912D125; Wed, 18 May 2016 00:49:37 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 99372180006; Wed, 18 May 2016 00:49:25 -0700 (PDT) To: aland@freeradius.org, dnelson@elbrysnetworks.com, aland@freeradius.org X-PHP-Originating-Script: 30:errata_mail_lib.php From: RFC Errata System Message-Id: <20160518074925.99372180006@rfc-editor.org> Date: Wed, 18 May 2016 00:49:25 -0700 (PDT) Archived-At: Cc: bclaise@cisco.com, radext@ietf.org, iesg@ietf.org, rfc-editor@rfc-editor.org Subject: [radext] [Errata Held for Document Update] RFC5080 (4623) X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 May 2016 07:49:39 -0000 The following errata report has been held for document update for RFC5080, "Common Remote Authentication Dial In User Service (RADIUS) Implementation Issues and Suggested Fixes". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=5080&eid=4623 -------------------------------------- Status: Held for Document Update Type: Technical Reported by: Alan DeKok Date Reported: 2016-02-22 Held by: Benoit Claise (IESG) Section: 2.2.1 Original Text ------------- For Accounting-Request packets, the default values for MRC, MRD, and MRT SHOULD be zero. These settings will enable a RADIUS client to continue sending accounting requests to a RADIUS server until the request is acknowledged. If any of MRC, MRD, or MRT are non-zero, then the accounting information could potentially be discarded without being recorded. Corrected Text -------------- For Accounting-Request packets, the default values for MRC, MRD, and MRT SHOULD be zero. These settings will enable a RADIUS client to continue sending accounting requests to a RADIUS server until the request is acknowledged. If any of MRC, MRD, or MRT are non-zero, then the accounting information could potentially be discarded without being recorded. This retransmission behavior can be modified for Accounting-Request packets containing Acct-Status-Type of Interim-Update. A "retransmission" MAY include updated statistics, but will otherwise be treated as a retransmission of the original packet, with timers as described above. Such an updated packet MUST set Acct-Delay-Time (if present) to zero, and Event-Timestamp (if present) to the current time. These changes indicate that the statistics contained in the packet are new, and were not previously sent. When the NAS sends periodic Accounting-Request packets containing Acct-Status-Type of Interim-Update, the NAS SHOULD NOT continue to retransmit an old Accounting-Request packet when it is time to send a new one. The old packet SHOULD be discarded, and the new one sent in its place. The alternative is for a NAS to send a new Accounting-Request packet while it still is trying to send an old one. This situation could lead to the NAS sending multiple Accounting-Request packets simultaneously for the same session, leading to congestive collapse of the network. Notes ----- - if we're retransmitting an Accounting-Request packet, it should be acceptable to update the statistics in it. - i.e. there should not be a requirement that the content remain the same. The Acct-Delay-Time attribute is changing, so why not other things, too? - And MRT of zero for Accounting-Request packet SHOULD NOT mean that the NAS starts a new retransmission timer every 5 minutes. - e.g. if the server is down for 20 minutes, the NAS should have *one* Accounting-Status packet in it's retransmit queue. Not 4. -------------------------------------- RFC5080 (draft-ietf-radext-fixes-08) -------------------------------------- Title : Common Remote Authentication Dial In User Service (RADIUS) Implementation Issues and Suggested Fixes Publication Date : December 2007 Author(s) : D. Nelson, A. DeKok Category : PROPOSED STANDARD Source : RADIUS EXTensions Area : Operations and Management Stream : IETF Verifying Party : IESG From nobody Mon May 23 08:36:45 2016 Return-Path: X-Original-To: radext@ietf.org Delivered-To: radext@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 1015712D1AD; Mon, 23 May 2016 08:36:41 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: "IETF-Announce" X-Test-IDTracker: no X-IETF-IDTracker: 6.21.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160523153641.10708.29048.idtracker@ietfa.amsl.com> Date: Mon, 23 May 2016 08:36:41 -0700 Archived-At: Cc: radext@ietf.org, stefan.winter@restena.lu, jouni.nospam@gmail.com, draft-ietf-radext-bigger-packets@ietf.org, The IESG , stephen.farrell@cs.tcd.ie, radext-chairs@ietf.org, rfc-editor@rfc-editor.org Subject: [radext] Document Action: 'Larger Packets for RADIUS over TCP' to Experimental RFC (draft-ietf-radext-bigger-packets-07.txt) X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.17 List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 May 2016 15:36:41 -0000 The IESG has approved the following document: - 'Larger Packets for RADIUS over TCP' (draft-ietf-radext-bigger-packets-07.txt) as Experimental RFC This document is the product of the RADIUS EXTensions Working Group. The IESG contact persons are Stephen Farrell, Benoit Claise and Joel Jaeggli. A URL of this Internet Draft is: https://datatracker.ietf.org/doc/draft-ietf-radext-bigger-packets/ Technical Summary: The Remote Authentication Dial-In User Service (RADIUS) protocol is limited to a total packet size of 4096 octets. The RADIUS over TLS experiment described in RFC 6614 has opened RADIUS to new use cases where the 4096-octet maximum size limit of RADIUS packets proves problematic. This specification extends the RADIUS over TCP experiment (RFC 6613) to permit larger RADIUS packets. This specification compliments other ongoing work to permit fragmentation of RADIUS authorization information. This document registers a new RADIUS code, an action which requires IESG approval. Working Group Summary: The document advanced through the working group stage smoothly. The amount of review it got was not overwhelming, but enough people participated to make it a solid and credible review and consensus overall. Document Quality: The document was reviewed by key contributors of the radext working group. It has not undergone an external review yet. There should be a review of the new Protocol-Error packet type during the IETF Last Call and IESG evaluation, since the allocation of a new packet type requires IESG approval. At least one vendor (FreeRADIUS) has indicated an interest to implement this specification. Personnel: The Document Shepherd is Stefan Winter . The responsible Area Director is Kathleen Moriarty (kathleen.moriarty.ietf@gmail.com); currently Stephen Farrell (stephen.farrell@cs.tcd.ie). From nobody Fri May 27 03:59:02 2016 Return-Path: X-Original-To: radext@ietf.org Delivered-To: radext@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id E1D1D12D98D; Fri, 27 May 2016 03:58:59 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "\"IETF Meeting Session Request Tool\"" To: X-Test-IDTracker: no X-IETF-IDTracker: 6.21.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160527105859.3020.43465.idtracker@ietfa.amsl.com> Date: Fri, 27 May 2016 03:58:59 -0700 Archived-At: Cc: radext@ietf.org, Kathleen.Moriarty.ietf@gmail.com, radext-chairs@ietf.org, stefan.winter@restena.lu Subject: [radext] radext - New Meeting Session Request for IETF 96 X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.17 List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 May 2016 10:59:00 -0000 A new meeting session request has just been submitted by Stefan Winter, a Chair of the radext working group. --------------------------------------------------------- Working Group Name: RADIUS EXTensions Area Name: Operations and Management Area Session Requester: Stefan Winter Number of Sessions: 1 Length of Session(s): 1 Hour Number of Attendees: 15 Conflicts to Avoid: First Priority: dime 6man v6ops dmm abfab oauth saag Second Priority: spring sfc rtcweb 6lo ace httpauth mile ipsecme Special Requests: We were on the "graveyard shift" last time - very last slot Friday afternoon. This led to extremely low attendance. Can someone else get that slot this time? Thanks! --------------------------------------------------------- From nobody Mon May 30 14:41:40 2016 Return-Path: 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 85B8D12D666 for ; Mon, 30 May 2016 14:41:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.647 X-Spam-Level: X-Spam-Status: No, score=-5.647 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.426, SPF_PASS=-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 P1yX3_G4FCnc for ; Mon, 30 May 2016 14:41:36 -0700 (PDT) Received: from xenon22.um.es (xenon22.um.es [155.54.212.162]) by ietfa.amsl.com (Postfix) with ESMTP id 7D9B912D677 for ; Mon, 30 May 2016 14:41:36 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by xenon22.um.es (Postfix) with ESMTP id 5E9132307; Mon, 30 May 2016 23:41:35 +0200 (CEST) X-Virus-Scanned: by antispam in UMU at xenon22.um.es Received: from xenon22.um.es ([127.0.0.1]) by localhost (xenon22.um.es [127.0.0.1]) (amavisd-new, port 10024) with LMTP id mDvAOOVEfm9x; Mon, 30 May 2016 23:41:35 +0200 (CEST) Received: from [192.168.1.200] (unknown [89.33.188.231]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: dan.garcia@um.es) by xenon22.um.es (Postfix) with ESMTPSA id B793422EE; Mon, 30 May 2016 23:41:34 +0200 (CEST) From: =?utf-8?Q?Dan_Garc=C3=ADa_Carrillo?= Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Mon, 30 May 2016 23:41:33 +0200 Message-Id: <6A6126F7-B1A9-4182-B9B7-21130699D935@um.es> To: radext@ietf.org Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) X-Mailer: Apple Mail (2.3124) Archived-At: Cc: =?utf-8?Q?Dan_Garc=C3=ADa_Carrillo?= Subject: [radext] LoRaWAN Authentication in RADIUS X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 May 2016 21:41:38 -0000 Dear all, We have uploaded a draft to show an initiative towards the integration = of AAA infrastructures into LP-WAN. This document show an example of how = the LoRaWAN join procedure can be used with RADIUS. Comments are welcome.=20 https://datatracker.ietf.org/doc/draft-garcia-radext-radius-lorawan/ Best Regards, Dan.= From nobody Tue May 31 06:45:09 2016 Return-Path: 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 5B8E912D1DC for ; Tue, 31 May 2016 06:45:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 UyNY4mayx7jN for ; Tue, 31 May 2016 06:45:06 -0700 (PDT) Received: from mail.networkradius.com (mail.networkradius.com [62.210.147.122]) by ietfa.amsl.com (Postfix) with ESMTP id C9AE512D508 for ; Tue, 31 May 2016 06:45:05 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.networkradius.com (Postfix) with ESMTP id 097C818E4; Tue, 31 May 2016 13:45:05 +0000 (UTC) Received: from mail.networkradius.com ([127.0.0.1]) by localhost (mail-server.vmhost2.networkradius.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lG5lKvt0uGJb; Tue, 31 May 2016 13:45:04 +0000 (UTC) Received: from [192.168.120.42] (unknown [23.233.24.114]) by mail.networkradius.com (Postfix) with ESMTPSA id C7982C7F; Tue, 31 May 2016 13:45:03 +0000 (UTC) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) From: Alan DeKok In-Reply-To: <6A6126F7-B1A9-4182-B9B7-21130699D935@um.es> Date: Tue, 31 May 2016 09:45:00 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <3DBD5F51-BBED-46B1-86CF-433825208E12@deployingradius.com> References: <6A6126F7-B1A9-4182-B9B7-21130699D935@um.es> To: =?utf-8?Q?Dan_Garc=C3=ADa_Carrillo?= X-Mailer: Apple Mail (2.3112) Archived-At: Cc: radext@ietf.org Subject: Re: [radext] LoRaWAN Authentication in RADIUS X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 May 2016 13:45:08 -0000 On May 30, 2016, at 5:41 PM, Dan Garc=C3=ADa Carrillo = wrote: > We have uploaded a draft to show an initiative towards the integration = of AAA infrastructures into LP-WAN. This document show an example of how = the LoRaWAN join procedure can be used with RADIUS. >=20 > Comments are welcome.=20 >=20 > https://datatracker.ietf.org/doc/draft-garcia-radext-radius-lorawan/ My $0.02: - Section 5 can probably be deleted. We've worked through RADIUS to = Diameter issues Diameter just transports RADIUS attributes as-is - Section 7 could talk about the security implications of sending keys = over RADIUS - Section 8 is wrong. The document needs two RADIUS attributes, which = means that there are actions for IANA. - section 4 contains zero information about the contents of the = attributes. I would suggest describing the contents in detail, and referencing the = "data types" document for any format. i.e. don't put in ASCII art. - the reference to LoRaWAN is the URL of a marketing page. This is not = useful. The reference should be to a technical specification. In short, the document describes an idea. It doesn't contain any real = technical content. Alan DeKok. From nobody Tue May 31 09:20:03 2016 Return-Path: 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 760E112D617 for ; Tue, 31 May 2016 09:20:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.647 X-Spam-Level: X-Spam-Status: No, score=-5.647 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.426, SPF_PASS=-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 RJ9mpcnHnvBJ for ; Tue, 31 May 2016 09:19:58 -0700 (PDT) Received: from xenon23.um.es (xenon23.um.es [155.54.212.163]) by ietfa.amsl.com (Postfix) with ESMTP id 7EB3512D61E for ; Tue, 31 May 2016 09:19:58 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by xenon23.um.es (Postfix) with ESMTP id 40AA044BA; Tue, 31 May 2016 18:19:55 +0200 (CEST) X-Virus-Scanned: by antispam in UMU at xenon23.um.es Received: from xenon23.um.es ([127.0.0.1]) by localhost (xenon23.um.es [127.0.0.1]) (amavisd-new, port 10024) with LMTP id M6AHOkYml0RT; Tue, 31 May 2016 18:19:55 +0200 (CEST) Received: from inf-205-239.inf.um.es (inf-205-239.inf.um.es [155.54.205.239]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: dan.garcia@um.es) by xenon23.um.es (Postfix) with ESMTPSA id DAF764812; Tue, 31 May 2016 18:19:53 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: =?utf-8?Q?Dan_Garc=C3=ADa_Carrillo?= In-Reply-To: <3DBD5F51-BBED-46B1-86CF-433825208E12@deployingradius.com> Date: Tue, 31 May 2016 18:19:53 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <42917D59-5710-4A2D-8AFD-F193223DA8A5@um.es> References: <6A6126F7-B1A9-4182-B9B7-21130699D935@um.es> <3DBD5F51-BBED-46B1-86CF-433825208E12@deployingradius.com> To: Alan DeKok X-Mailer: Apple Mail (2.3124) Archived-At: Cc: radext@ietf.org, =?utf-8?Q?Dan_Garc=C3=ADa_Carrillo?= Subject: Re: [radext] LoRaWAN Authentication in RADIUS X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 May 2016 16:20:01 -0000 > El 31 may 2016, a las 15:45, Alan DeKok = escribi=C3=B3: >=20 > On May 30, 2016, at 5:41 PM, Dan Garc=C3=ADa Carrillo = wrote: >> We have uploaded a draft to show an initiative towards the = integration of AAA infrastructures into LP-WAN. This document show an = example of how the LoRaWAN join procedure can be used with RADIUS. >>=20 >> Comments are welcome.=20 >>=20 >> https://datatracker.ietf.org/doc/draft-garcia-radext-radius-lorawan/ >=20 Dear Alan,=20 Thank you for taking the time to review the I-D, your comments are very = valuable indeed and we will provide a more precise version based on your = comments. Please see comments inline.=20 > My $0.02: >=20 > - Section 5 can probably be deleted. We've worked through RADIUS to = Diameter issues Diameter just transports RADIUS attributes as-is This is good to know, thank you. > - Section 7 could talk about the security implications of sending keys = over RADIUS >=20 For sure, a consideration of how the key distribution is managed would = be indeed both interesting and necessary.=20 > - Section 8 is wrong. The document needs two RADIUS attributes, which = means that there are actions for IANA. >=20 You are right, that is a mistake.=20 > - section 4 contains zero information about the contents of the = attributes. >=20 > I would suggest describing the contents in detail, and referencing = the "data types" document for any format. i.e. don't put in ASCII art. >=20 As you well say, a better introduction about the parameters and the = details of the exchange is needed.=20 > - the reference to LoRaWAN is the URL of a marketing page. This is = not useful. The reference should be to a technical specification. >=20 Thank you for pointing that out. > In short, the document describes an idea. It doesn't contain any = real technical content. >=20 > Alan DeKok. >=20 Best Regards, Dan. > _______________________________________________ > radext mailing list > radext@ietf.org > https://www.ietf.org/mailman/listinfo/radext