From nobody Wed Jan 4 07:00:59 2017 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 D33571293D9 for ; Wed, 4 Jan 2017 07:00:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.999 X-Spam-Level: X-Spam-Status: No, score=-4.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-3.1, 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 I1AQk-6HcFgi for ; Wed, 4 Jan 2017 07:00:56 -0800 (PST) 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 7916C128B37 for ; Wed, 4 Jan 2017 07:00:56 -0800 (PST) Received: from aragorn.restena.lu (aragorn.restena.lu [IPv6:2001:a18:1:8::155]) by smtprelay.restena.lu (Postfix) with ESMTPS id 50BB843976 for ; Wed, 4 Jan 2017 16:00:54 +0100 (CET) To: "radext@ietf.org" From: Stefan Winter Openpgp: id=AD3091F3AB24E05F4F722C03C0DE6A358A39DC66; url=http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xC0DE6A358A39DC66 Message-ID: <2b60a0e4-8d07-4048-785f-8effbe8a4c5d@restena.lu> Date: Wed, 4 Jan 2017 16:00:54 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.5.1 MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="gHdu4ugBLi7VvWE3HAFCsQh3g5G70a79a" Archived-At: Subject: [radext] not meeting in Chicago 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, 04 Jan 2017 15:00:58 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --gHdu4ugBLi7VvWE3HAFCsQh3g5G70a79a Content-Type: multipart/mixed; boundary="UUvK9TJqb7Upsgbau10jJdMgnNhLD8dRQ"; protected-headers="v1" From: Stefan Winter To: "radext@ietf.org" Message-ID: <2b60a0e4-8d07-4048-785f-8effbe8a4c5d@restena.lu> Subject: not meeting in Chicago --UUvK9TJqb7Upsgbau10jJdMgnNhLD8dRQ Content-Type: multipart/mixed; boundary="------------D7AAC487EAE19B361209AD4C" This is a multi-part message in MIME format. --------------D7AAC487EAE19B361209AD4C Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hello, and a Happy New Year to RADEXT! As an early warning: We have determined that there is a significant chance that none of the two working group chairs will be present in Chicago, so we are not planning a meeting for IETF98. Greetings, The Chairs --=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 --------------D7AAC487EAE19B361209AD4C 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----- --------------D7AAC487EAE19B361209AD4C-- --UUvK9TJqb7Upsgbau10jJdMgnNhLD8dRQ-- --gHdu4ugBLi7VvWE3HAFCsQh3g5G70a79a 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 iQIcBAEBCgAGBQJYbQ4mAAoJEMDeajWKOdxmPb0P/3uhlANzVxaXp9J5oe+cxp8F +QQcA2zjvaZ0ao3IUnx2PN9zA/+CMjuVG89jdnTN8xUQaDxxbrLt3sS2zmfDUGwv otZDBYu0m2JaRv1pK+t1olrbaj79kr1vUX/drudhhS9v5mBAgNkfnan5TAeMhI6+ oeIxqFOtMskyzM05xagY0T7y8alkpIExw32KQ7FkYyAv5QcLja4CsUYFbS4DJiYI 63lHsw35+/RTNPKoMxmK5g5o/exXC3/AqsfkfWWJ+U9T0BlCINZkQItQ2liKbM3k DJKHfntePyqDqdBQpoDc964aBKiTWNkTr60j4ZqQJZ1Qx82FEJWi3RxcMCIfLgfT g9MKZGm/I9kL+b7RUHb1E1/oJO1rS2yZh2c9iufqu3lZ73etr9sN+KSJSMHs9IWU yhC9AphNJhFlFfM7qGEBtf7YJ78Bs+DJX3+3y6waszihKVpE/V6JPV4k2l4LstLs BGAw2Q/i45SaAfuD/AALpgvGBUPRLSStKQ0mme4jMyO3QWBNLH0ufYKe0PjW7GaB HAZ4aw3AhJUcdIoVnY4BZMvl3qbF0vdpykgvbMS0fQy2fwM0M3GXEoxMADcGoVeX kE6gjJpqLhNAvBevFKc6H+CZAOf90BhA4HNKAoEFkFTG7yOixNiwMYqFGzVK1MEU T3fyWqAPaA9tkWHaStu0 =mK7n -----END PGP SIGNATURE----- --gHdu4ugBLi7VvWE3HAFCsQh3g5G70a79a-- From nobody Wed Jan 11 08:43:11 2017 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 6F8B3129F11; Wed, 11 Jan 2017 08:43:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 sAazaDa1M4Kt; Wed, 11 Jan 2017 08:43:09 -0800 (PST) Received: from mail-qk0-x232.google.com (mail-qk0-x232.google.com [IPv6:2607:f8b0:400d:c09::232]) (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 DA19B129F08; Wed, 11 Jan 2017 08:43:08 -0800 (PST) Received: by mail-qk0-x232.google.com with SMTP id 11so115876566qkl.3; Wed, 11 Jan 2017 08:43:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=gD4lZC+RT6wnV6LqSXbmERQUGi+rLhms+7llCXqHOVQ=; b=LcDpvEzBgq8ghlJ0p1wCnL/DKm3+Zn3EiTcC64ZPd/NURqw4YdQ5lZLlBpZPm20yir dSZqm0OfYkZT3nB+H60/EFG3oWg/ainfFYJe3X8JETqxj9JaV7N6+kUwsvWGTwO0gl2d 5mwkzjktVfptnmlkrnSt1fin31omONIQhtZs1mXSkCG0mnrBxPIWucA9Sa6SKVT1SHMp z8g4BbQSaxCM3vzHJkcVkJsBbrc1JPitGvGoAFg6C38iwP44SS7zw46CK7qer8dHDQMk LjgVa3CqkyqkBN6CXw7OdEalb0c9Nkt4JKIzt3+TLxUhV226hU2ZobWXHXMVPxtK6k53 JjTA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=gD4lZC+RT6wnV6LqSXbmERQUGi+rLhms+7llCXqHOVQ=; b=dtHjtH2LLqemlb/LkgO7NHUBcdQQnZ/dkDobBRx2LqXC18bQsvrqUePWTH4jpYP37P gKCxZtdYie7TVIc02Y6bKeDJjG6J9otLy4iaul0f0mELa0LlMw0Xr32DaamcTYnj/ocl GpILf5b0x0Gdm9YNcSaujQAbeRSax5DSJhKVeYW8YNypMOBUHJaYBx8sljosFz41h0Gk DnPqdA0GNP520uQZe2D4LlRxHGxLxk+IHsz3ZZvQqmCQjGQVcfPYsqMpUrT0O/UThn5S uwoJuwhCCfBGBm2cUgUGj7Lsv3uHpX9HdL9mHSmPPRVmCyf3C4brN9ahG2aQ+Psu1AqP CoxQ== X-Gm-Message-State: AIkVDXJpSDVfM1kjgN6YIfzCfbTwwJecdJZGDnGmOkjjH0mKxy5lWoCHV+EIdbYNaukqjSc4nYipbRbrDH0LXA== X-Received: by 10.55.162.65 with SMTP id l62mr8831071qke.17.1484152988041; Wed, 11 Jan 2017 08:43:08 -0800 (PST) MIME-Version: 1.0 Received: by 10.12.161.101 with HTTP; Wed, 11 Jan 2017 08:43:07 -0800 (PST) In-Reply-To: References: <20170109233022.14EE5B81304@rfc-editor.org> From: Kathleen Moriarty Date: Wed, 11 Jan 2017 11:43:07 -0500 Message-ID: To: Alan DeKok , "iesg@ietf.org" Content-Type: multipart/alternative; boundary=001a114d83cea505ee0545d44b05 Archived-At: Cc: Winter Stefan , "radext@ietf.org" , radext-chairs@ietf.org, radext-ads@ietf.org, RFC Editor Subject: Re: [radext] [AD] AUTH48 [LB]: RFC 8044 NOW AVAILABLE 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, 11 Jan 2017 16:43:10 -0000 --001a114d83cea505ee0545d44b05 Content-Type: text/plain; charset=UTF-8 Adding the IESG and the working group to see if there are any concerns with the following approach... inline On Wed, Jan 11, 2017 at 10:40 AM, Alan DeKok wrote: > > > > > a) RFCs 4072 and 7268 are not cited anywhere in this document. > > > > Please let us know where they should be cited; otherwise, the > > > > listings will be removed. > > > > > > The RFCs are referenced simply because this document is updating > > > attributes that they define. > > > > Can you please list the specific updates from the 2 mentioned RFCs here > and then I'll figure out if this needs to go back through the WG and last > calls or not. > > http://www.iana.org/assignments/radius-types/radius-types.xhtml#radius- > types-2 > > RFC 4072 defines EAP-Key-Name. It's in the RADIUS space, but t's > defined to have a Diameter data type "OctetString". We can't use > "OctetString" for a RADIUS data types, so the "data types" document defines > it as the RADIUS data type "string". Which ends up being the same for all > intents and purposes. > > RFC 7268 defines a bunch of attributes. Most are of 32-bit integers, > which maps well to the data types doc. The only real "new" thing is > EAPoL-Announcement. It's defined manually in RFC 7268 as "concatenate the > fragments together before looking at it". The data types doc calls this > out as a special data type "concat", along with EAP-Message, and a few > others. > > I think everyone is in agreement as to what the data types should be. > The "updates RFC 4072 / 7268" note is really saying "RFC 4072 / 7268 talks > about this attribute, but doesn't really give an adequate definition for > it. So the data types document picks something, which is compatible with > the original definition, but uses a now-standard data type" > > i.e. the original spec isn't so much wrong, as unclear and incomplete. > This seems like a small enough 'updates' that I think it should be fine to progress just adding the note that RFC4072 and RFC7268 are updated. Any objections? The alternative would be to put this back through the last call process, but I think this looks small enough to avoid that. It would really just be for process sake IMO. > Alan DeKok. > > -- Best regards, Kathleen --001a114d83cea505ee0545d44b05 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Adding the IESG and the working group to see if there are = any concerns with the following approach... inline

On Wed, Jan 11, 2017 at 10:40 AM, Alan DeK= ok <aland@freeradius.org> wrote:

> > > a) RFCs 4072 and 7268 are not cited anywhere in this documen= t.
> > > Please let us know where they should be cited; otherwise, th= e
> > > listings will be removed.
> >
> > The RFCs are referenced simply because this document is updating<= br> > > attributes that they define.
>
> Can you please list the specific updates from the 2 mentioned RFCs her= e and then I'll figure out if this needs to go back through the WG and = last calls or not.

http://www.iana= .org/assignments/radius-types/radius-types.xhtml#radius-type= s-2

=C2=A0 RFC 4072 defines EAP-Key-Name.=C2=A0 It's in the RADIUS space, b= ut t's defined to have a Diameter data type "OctetString".=C2= =A0 =C2=A0We can't use "OctetString" for a RADIUS data types,= so the "data types" document defines it as the RADIUS data type = "string". Which ends up being the same for all intents and purpos= es.

=C2=A0 RFC 7268 defines a bunch of attributes.=C2=A0 Most are of 32-bit int= egers, which maps well to the data types doc.=C2=A0 The only real "new= " thing is EAPoL-Announcement.=C2=A0 It's defined manually in RFC = 7268 as "concatenate the fragments together before looking at it"= .=C2=A0 The data types doc calls this out as a special data type "conc= at", along with EAP-Message, and a few others.

=C2=A0 I think everyone is in agreement as to what the data types should be= .=C2=A0 The "updates RFC 4072 / 7268" note is really saying "= ;RFC 4072 / 7268 talks about this attribute, but doesn't really give an= adequate definition for it.=C2=A0 So the data types document picks somethi= ng, which is compatible with the original definition, but uses a now-standa= rd data type"

=C2=A0 i.e. the original spec isn't so much wrong, as unclear and incom= plete.

This seems like a small enough &= #39;updates' that I think it should be fine to progress just adding the= note that RFC4072 and RFC7268 are updated.

Any ob= jections?=C2=A0 The alternative would be to put this back through the last = call process, but I think this looks small enough to avoid that.=C2=A0 It w= ould really just be for process sake IMO.


=C2=A0 Alan DeKok.




--

Best regards,
Kathleen
--001a114d83cea505ee0545d44b05-- From nobody Wed Jan 11 12:28:37 2017 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 87F481297E1; Wed, 11 Jan 2017 12:28:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.698 X-Spam-Level: X-Spam-Status: No, score=-2.698 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 RZB-FqbLGmrj; Wed, 11 Jan 2017 12:28:29 -0800 (PST) Received: from mail-pf0-x242.google.com (mail-pf0-x242.google.com [IPv6:2607:f8b0:400e:c00::242]) (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 36AEE12956F; Wed, 11 Jan 2017 12:28:29 -0800 (PST) Received: by mail-pf0-x242.google.com with SMTP id f144so14582305pfa.2; Wed, 11 Jan 2017 12:28:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=rGgCdnQcD7aUy5yJ91lgK1BUIeL3UtPQ4vrVUaXVAzw=; b=DBL7axSSPiDdXMk9ifKLGFDb7t6+oW8tusjDDk0aKYS8902W6kG1oTPf3BfldbI5By 4shErLyg/wA6sOZuUmHmMdSRs+xfL1UNS5kgjIHCxSGfTridG5qa1W9URTQnD3+RxLon OFAnSlPkbL9sEVRMbL+AdqYb+JlWmjBZ+IT+8aMwVlBdTCeXmHgFsxqCZHbkBsVAjda2 LiUaPn9AsetyQWPH+OMKOOD1zRpnzptSvDMClBREJ7LdqB7LstnvozOmEMwym5CN6fpd dd8X7PZsmSk4LelprdJkK8yPco9ml8DRwnCZVyoYF9gGutqK1S7xIMQ8Njbii3dXnCHO TAkQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=rGgCdnQcD7aUy5yJ91lgK1BUIeL3UtPQ4vrVUaXVAzw=; b=kTfORlGsu+XTJOUodWUkcgmsD7h0CLpRM1Ob+s9ofgV1wo03uNxd9iS4YqsjpUG/Yd mt7/InQG5ue8/OaYnJ3J/H41UdklN/ld19G0jZETxGatSohN/IVmyhKIOyQX4nP3Dtzl 9DOmzJTwlWw3lXNeFF3mdmSHHSx9rRSMOPaZsbme34MfCDGYs29yhZ0Bo4MAwvSwzfEV oz57wKP7SwD/q+4OSEvRzVhzuiZ2m/Wvjuy2bmy/9v51g3ZQrWy67GfnMMF9VjTkJMwB kE5ELnlHE+kEbhTyOCHX0zi+AgXVAZh8ADuEQeIBkHQ5BtgJ/LhUf4qi1E3VY7HKWXbC ZMqw== X-Gm-Message-State: AIkVDXJHZ1S7hV9ZrnQMTyFGxk2hnY1mAn3O/TJmhyUBcXX+m3cBofK6QLelh0u9P/dMqA== X-Received: by 10.84.218.132 with SMTP id r4mr15994471pli.23.1484166508740; Wed, 11 Jan 2017 12:28:28 -0800 (PST) Received: from [10.77.140.39] (mobile-166-176-184-137.mycingular.net. [166.176.184.137]) by smtp.gmail.com with ESMTPSA id h4sm1391439pfk.96.2017.01.11.12.28.27 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 11 Jan 2017 12:28:27 -0800 (PST) Content-Type: multipart/alternative; boundary=Apple-Mail-C5F61CF7-890C-43A0-8F56-4CC6F6E00823 Mime-Version: 1.0 (1.0) From: Bernard Aboba X-Mailer: iPhone Mail (14C92) In-Reply-To: Date: Wed, 11 Jan 2017 12:28:26 -0800 Content-Transfer-Encoding: 7bit Message-Id: References: <20170109233022.14EE5B81304@rfc-editor.org> To: Kathleen Moriarty Archived-At: Cc: "radext@ietf.org" , radext-ads@ietf.org, Winter Stefan , "iesg@ietf.org" , Alan DeKok , radext-chairs@ietf.org, RFC Editor Subject: Re: [radext] [AD] AUTH48 [LB]: RFC 8044 NOW AVAILABLE 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, 11 Jan 2017 20:28:31 -0000 --Apple-Mail-C5F61CF7-890C-43A0-8F56-4CC6F6E00823 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Data types do not affect what is actually sent on the wire, they just make i= t easier for a RADIUS server to add support for an attribute without custom c= ode. So the datatypes draft does not create a deployment blocker or backward= compatibility issue, it actually may make implementation easier.=20 > On Jan 11, 2017, at 8:43 AM, Kathleen Moriarty wrote: >=20 > Adding the IESG and the working group to see if there are any concerns wit= h the following approach... inline >=20 >> On Wed, Jan 11, 2017 at 10:40 AM, Alan DeKok wrote= : >>=20 >> > > > a) RFCs 4072 and 7268 are not cited anywhere in this document. >> > > > Please let us know where they should be cited; otherwise, the >> > > > listings will be removed. >> > > >> > > The RFCs are referenced simply because this document is updating >> > > attributes that they define. >> > >> > Can you please list the specific updates from the 2 mentioned RFCs here= and then I'll figure out if this needs to go back through the WG and last c= alls or not. >>=20 >> http://www.iana.org/assignments/radius-types/radius-types.xhtml#radius-ty= pes-2 >>=20 >> RFC 4072 defines EAP-Key-Name. It's in the RADIUS space, but t's defin= ed to have a Diameter data type "OctetString". We can't use "OctetString" f= or a RADIUS data types, so the "data types" document defines it as the RADIU= S data type "string". Which ends up being the same for all intents and purpo= ses. >>=20 >> RFC 7268 defines a bunch of attributes. Most are of 32-bit integers, w= hich maps well to the data types doc. The only real "new" thing is EAPoL-An= nouncement. It's defined manually in RFC 7268 as "concatenate the fragments= together before looking at it". The data types doc calls this out as a spe= cial data type "concat", along with EAP-Message, and a few others. >>=20 >> I think everyone is in agreement as to what the data types should be. T= he "updates RFC 4072 / 7268" note is really saying "RFC 4072 / 7268 talks ab= out this attribute, but doesn't really give an adequate definition for it. S= o the data types document picks something, which is compatible with the orig= inal definition, but uses a now-standard data type" >>=20 >> i.e. the original spec isn't so much wrong, as unclear and incomplete. >=20 > This seems like a small enough 'updates' that I think it should be fine to= progress just adding the note that RFC4072 and RFC7268 are updated. >=20 > Any objections? The alternative would be to put this back through the las= t call process, but I think this looks small enough to avoid that. It would= really just be for process sake IMO. >=20 >>=20 >> Alan DeKok. >>=20 >=20 >=20 >=20 > --=20 >=20 > Best regards, > Kathleen > _______________________________________________ > radext mailing list > radext@ietf.org > https://www.ietf.org/mailman/listinfo/radext --Apple-Mail-C5F61CF7-890C-43A0-8F56-4CC6F6E00823 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
Data types do not affect wh= at is actually sent on the wire, they just make it easier for a RADIUS serve= r to add support for an attribute without custom code. So the datatypes draf= t does not create a deployment blocker or backward compatibility issue, it a= ctually may make implementation easier. 

On Jan 11, 2017,= at 8:43 AM, Kathleen Moriarty <kathleen.moriarty.ietf@gmail.com> wrote:

Adding the IESG and the working g= roup to see if there are any concerns with the following approach... inline<= div class=3D"gmail_extra">
On Wed, Jan 11, 201= 7 at 10:40 AM, Alan DeKok <aland@freeradius.org> wrote:
=

> > > a) RFCs 4072 and 7268 are not cited anywhere in this document= .
> > > Please let us know where they should be cited; otherwise, the=
> > > listings will be removed.
> >
> > The RFCs are referenced simply because this document is updating > > attributes that they define.
>
> Can you please list the specific updates from the 2 mentioned RFCs here= and then I'll figure out if this needs to go back through the WG and last c= alls or not.

http://www.iana.o= rg/assignments/radius-types/radius-types.xhtml#radius-types-2=

  RFC 4072 defines EAP-Key-Name.  It's in the RADIUS space, but t'= s defined to have a Diameter data type "OctetString".   We can't u= se "OctetString" for a RADIUS data types, so the "data types" document defin= es it as the RADIUS data type "string". Which ends up being the same for all= intents and purposes.

  RFC 7268 defines a bunch of attributes.  Most are of 32-bit inte= gers, which maps well to the data types doc.  The only real "new" thing= is EAPoL-Announcement.  It's defined manually in RFC 7268 as "concaten= ate the fragments together before looking at it".  The data types doc c= alls this out as a special data type "concat", along with EAP-Message, and a= few others.

  I think everyone is in agreement as to what the data types should be.=   The "updates RFC 4072 / 7268" note is really saying "RFC 4072 / 7268 t= alks about this attribute, but doesn't really give an adequate definition fo= r it.  So the data types document picks something, which is compatible w= ith the original definition, but uses a now-standard data type"

  i.e. the original spec isn't so much wrong, as unclear and incomplete= .

This seems like a small enough 'update= s' that I think it should be fine to progress just adding the note that RFC4= 072 and RFC7268 are updated.

Any objections?  T= he alternative would be to put this back through the last call process, but I= think this looks small enough to avoid that.  It would really just be f= or process sake IMO.


  Alan DeKok.




--

Best regards,
Kathleen
____________________= ___________________________
radext mailing list
radext@ietf.org
<= a href=3D"https://www.ietf.org/mailman/listinfo/radext">https://www.ietf.org= /mailman/listinfo/radext
= --Apple-Mail-C5F61CF7-890C-43A0-8F56-4CC6F6E00823-- From nobody Fri Jan 13 07:36:10 2017 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 D6F7B1296B4; Fri, 13 Jan 2017 07:36:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 lPlESYMBRLEB; Fri, 13 Jan 2017 07:36:02 -0800 (PST) Received: from mail-qt0-x242.google.com (mail-qt0-x242.google.com [IPv6:2607:f8b0:400d:c0d::242]) (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 668EB12948E; Fri, 13 Jan 2017 07:36:02 -0800 (PST) Received: by mail-qt0-x242.google.com with SMTP id n13so6618300qtc.0; Fri, 13 Jan 2017 07:36:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=wVOq9YlOQsvwcvYPYpf2Mtt6fBEUW2njqK+1T7Qlxys=; b=K2jutjdbz+pXzkMMfAEU+BeEDAJp0s2YELqOFzqE6N+Wk5B2bfF49G5y3kw0WM5fMG my7Hvx2x6wLYGOEuBXUj2hv5dYfeICNITH8vwtC/7/C8X355vHcItwDtM0/lLKbYQrfJ QCOw4iG2L8Mi7gcM5Jr653NyLw5nyd3pgZpkJTMci65ApJHuNN4e1rtPw1Lkah+jzkda qRws1X1IVTA+IeBXKUcS9l7IVeEbQWjlqUIUU0vzhAvSjq3BwUFlFlMeS8E2zIVFP3lz Jv/UFhPEBC0qXT662qoZkng4W+DLkrpmZSfqIn3KKviDuf8wI4qWt5VrLw51jOl+LZnX ALPA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=wVOq9YlOQsvwcvYPYpf2Mtt6fBEUW2njqK+1T7Qlxys=; b=EPE25Aw4e9RAjpbHty4FU0giJzU8rZEajxJlKF2x9SQyRiM59Y8rDZpSq+n0taV2zm AIqTY6fsJMFxl/cPu2nPooqKRWUNvwk/h0lxTuO3FlVe8QcCHEJWxxlE1iOX40Xeb+RN XySKxio+m6Qd1DGtqT6i0W0mxQsfZ/PCHnxyoEyDQqfnQteg/W7vXQ/RvQo7UY7HNoZH HOOHLZ97Af4eeMNSH6rr2HXsp2sNJlSjn7vU+F3gYiqZW+LX9Ia2cM59NTR5P7StABxO PZHmtKCQYCZ5HnX5X4gsyYHI13ltPwD7nC9YxDBmJjKb5O2RZSaQdoi0wGhwQr6g0vZa bHMQ== X-Gm-Message-State: AIkVDXJyaeOgig27jY8Kd5CiyOIBwLMjqerHkYUQ88UNaKrYmgpU8zNOc5ItS3QXUH2hpcSYNOH8wh5Oc7EffA== X-Received: by 10.237.45.7 with SMTP id h7mr17588983qtd.280.1484321761486; Fri, 13 Jan 2017 07:36:01 -0800 (PST) MIME-Version: 1.0 Received: by 10.12.161.101 with HTTP; Fri, 13 Jan 2017 07:36:01 -0800 (PST) In-Reply-To: References: <20170109233022.14EE5B81304@rfc-editor.org> From: Kathleen Moriarty Date: Fri, 13 Jan 2017 10:36:01 -0500 Message-ID: To: Bernard Aboba Content-Type: multipart/alternative; boundary=94eb2c124a405375320545fb9707 Archived-At: Cc: "radext@ietf.org" , radext-ads@ietf.org, Winter Stefan , "iesg@ietf.org" , Alan DeKok , radext-chairs@ietf.org, RFC Editor Subject: Re: [radext] [AD] AUTH48 [LB]: RFC 8044 NOW AVAILABLE 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: Fri, 13 Jan 2017 15:36:05 -0000 --94eb2c124a405375320545fb9707 Content-Type: text/plain; charset=UTF-8 Hello, I think we have agreement to continue moving forward, just noting the 'updates' since it is not a significant update. Thank you, Kathleen On Wed, Jan 11, 2017 at 3:28 PM, Bernard Aboba wrote: > Data types do not affect what is actually sent on the wire, they just make > it easier for a RADIUS server to add support for an attribute without > custom code. So the datatypes draft does not create a deployment blocker or > backward compatibility issue, it actually may make implementation easier. > > On Jan 11, 2017, at 8:43 AM, Kathleen Moriarty < > kathleen.moriarty.ietf@gmail.com> wrote: > > Adding the IESG and the working group to see if there are any concerns > with the following approach... inline > > On Wed, Jan 11, 2017 at 10:40 AM, Alan DeKok wrote: > >> >> > > > a) RFCs 4072 and 7268 are not cited anywhere in this document. >> > > > Please let us know where they should be cited; otherwise, the >> > > > listings will be removed. >> > > >> > > The RFCs are referenced simply because this document is updating >> > > attributes that they define. >> > >> > Can you please list the specific updates from the 2 mentioned RFCs here >> and then I'll figure out if this needs to go back through the WG and last >> calls or not. >> >> http://www.iana.org/assignments/radius-types/radius-types. >> xhtml#radius-types-2 >> >> RFC 4072 defines EAP-Key-Name. It's in the RADIUS space, but t's >> defined to have a Diameter data type "OctetString". We can't use >> "OctetString" for a RADIUS data types, so the "data types" document defines >> it as the RADIUS data type "string". Which ends up being the same for all >> intents and purposes. >> >> RFC 7268 defines a bunch of attributes. Most are of 32-bit integers, >> which maps well to the data types doc. The only real "new" thing is >> EAPoL-Announcement. It's defined manually in RFC 7268 as "concatenate the >> fragments together before looking at it". The data types doc calls this >> out as a special data type "concat", along with EAP-Message, and a few >> others. >> >> I think everyone is in agreement as to what the data types should be. >> The "updates RFC 4072 / 7268" note is really saying "RFC 4072 / 7268 talks >> about this attribute, but doesn't really give an adequate definition for >> it. So the data types document picks something, which is compatible with >> the original definition, but uses a now-standard data type" >> >> i.e. the original spec isn't so much wrong, as unclear and incomplete. >> > > This seems like a small enough 'updates' that I think it should be fine to > progress just adding the note that RFC4072 and RFC7268 are updated. > > Any objections? The alternative would be to put this back through the > last call process, but I think this looks small enough to avoid that. It > would really just be for process sake IMO. > > >> Alan DeKok. >> >> > > > -- > > Best regards, > Kathleen > > _______________________________________________ > radext mailing list > radext@ietf.org > https://www.ietf.org/mailman/listinfo/radext > > -- Best regards, Kathleen --94eb2c124a405375320545fb9707 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hello,

I think we have agreement to con= tinue moving forward, just noting the 'updates' since it is not a s= ignificant update.

Thank you,
Kathleen

On Wed,= Jan 11, 2017 at 3:28 PM, Bernard Aboba <bernard.aboba@gmail.com= > wrote:
Data types do not affect what is actually sent on the wire, the= y just make it easier for a RADIUS server to add support for an attribute w= ithout custom code. So the datatypes draft does not create a deployment blo= cker or backward compatibility issue, it actually may make implementation e= asier.=C2=A0

On Jan 11, 2017, at 8:43 = AM, Kathleen Moriarty <kathleen.moriarty.ietf@gmail.com> wrote:
Adding the IESG= and the working group to see if there are any concerns with the following = approach... inline

On Wed, Jan 11, 2017 at 10:40 AM, Alan DeKok <aland@freeradius.org= > wrote:

> > > a) RFCs 4072 and 7268 are not cited anywhere in this documen= t.
> > > Please let us know where they should be cited; otherwise, th= e
> > > listings will be removed.
> >
> > The RFCs are referenced simply because this document is updating<= br> > > attributes that they define.
>
> Can you please list the specific updates from the 2 mentioned RFCs her= e and then I'll figure out if this needs to go back through the WG and = last calls or not.

http://www.iana= .org/assignments/radius-types/radius-types.xhtml#radius-types-2

=C2=A0 RFC 4072 defines EAP-Key-Name.=C2=A0 It's in the RADIUS space, b= ut t's defined to have a Diameter data type "OctetString".=C2= =A0 =C2=A0We can't use "OctetString" for a RADIUS data types,= so the "data types" document defines it as the RADIUS data type = "string". Which ends up being the same for all intents and purpos= es.

=C2=A0 RFC 7268 defines a bunch of attributes.=C2=A0 Most are of 32-bit int= egers, which maps well to the data types doc.=C2=A0 The only real "new= " thing is EAPoL-Announcement.=C2=A0 It's defined manually in RFC = 7268 as "concatenate the fragments together before looking at it"= .=C2=A0 The data types doc calls this out as a special data type "conc= at", along with EAP-Message, and a few others.

=C2=A0 I think everyone is in agreement as to what the data types should be= .=C2=A0 The "updates RFC 4072 / 7268" note is really saying "= ;RFC 4072 / 7268 talks about this attribute, but doesn't really give an= adequate definition for it.=C2=A0 So the data types document picks somethi= ng, which is compatible with the original definition, but uses a now-standa= rd data type"

=C2=A0 i.e. the original spec isn't so much wrong, as unclear and incom= plete.




=C2=A0 Alan DeKok.




--

Best regards,
Kathleen

<= br clear=3D"all">

--

Best regards,
=
Kathleen
--94eb2c124a405375320545fb9707-- From nobody Fri Jan 13 10:11:42 2017 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 454221294F5; Fri, 13 Jan 2017 10:11:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.399 X-Spam-Level: X-Spam-Status: No, score=-7.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-3.199, 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 rJWB4xF4It8U; Fri, 13 Jan 2017 10:11:39 -0800 (PST) Received: from mail.amsl.com (c8a.amsl.com [4.31.198.40]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1953A1293FC; Fri, 13 Jan 2017 10:11:39 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by c8a.amsl.com (Postfix) with ESMTP id C69B41E5663; Fri, 13 Jan 2017 10:11:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from c8a.amsl.com ([127.0.0.1]) by localhost (c8a.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GTw-q2xniP7s; Fri, 13 Jan 2017 10:11:16 -0800 (PST) Received: from [10.0.0.12] (c-67-188-82-176.hsd1.ca.comcast.net [67.188.82.176]) by c8a.amsl.com (Postfix) with ESMTPSA id EFAB71E5661; Fri, 13 Jan 2017 10:11:15 -0800 (PST) Content-Type: multipart/alternative; boundary="Apple-Mail=_2A1A1379-8F1B-4FCF-A8F3-04EFF3DDC36B" Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Lynne Bartholomew In-Reply-To: Date: Fri, 13 Jan 2017 10:11:38 -0800 Message-Id: <438C29BB-EB6E-4D10-A538-B0C0F9DACC68@amsl.com> References: <20170109233022.14EE5B81304@rfc-editor.org> To: Kathleen Moriarty X-Mailer: Apple Mail (2.1878.6) Archived-At: Cc: "radext@ietf.org" , radext-ads@ietf.org, Winter Stefan , "iesg@ietf.org" , Alan DeKok , RFC Editor , radext-chairs@ietf.org, Bernard Aboba Subject: Re: [radext] [AD] AUTH48 [LB]: RFC 8044 NOW AVAILABLE 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: Fri, 13 Jan 2017 18:11:41 -0000 --Apple-Mail=_2A1A1379-8F1B-4FCF-A8F3-04EFF3DDC36B Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Dear Kathleen, Thank you for the email. It is not clear to us how best to update this document. Would the = following be correct? OLD: Updates: 2865, 3162, 6158, 6572 NEW: Updates: 2865, 3162, 4072, 6158, 6572, 7268 OLD: This document updates RFCs 2865, 3162, 6158, and 6572. NEW: This document updates RFCs 2865, 3162, 4072, 6158, 6572, and 7268. Thank you. RFC Editor/lb On Jan 13, 2017, at 7:36 AM, Kathleen Moriarty = wrote: > Hello, >=20 > I think we have agreement to continue moving forward, just noting the = 'updates' since it is not a significant update. >=20 > Thank you, > Kathleen >=20 > On Wed, Jan 11, 2017 at 3:28 PM, Bernard Aboba = wrote: > Data types do not affect what is actually sent on the wire, they just = make it easier for a RADIUS server to add support for an attribute = without custom code. So the datatypes draft does not create a deployment = blocker or backward compatibility issue, it actually may make = implementation easier.=20 >=20 > On Jan 11, 2017, at 8:43 AM, Kathleen Moriarty = wrote: >=20 >> Adding the IESG and the working group to see if there are any = concerns with the following approach... inline >>=20 >> On Wed, Jan 11, 2017 at 10:40 AM, Alan DeKok = wrote: >>=20 >> > > > a) RFCs 4072 and 7268 are not cited anywhere in this document. >> > > > Please let us know where they should be cited; otherwise, the >> > > > listings will be removed. >> > > >> > > The RFCs are referenced simply because this document is updating >> > > attributes that they define. >> > >> > Can you please list the specific updates from the 2 mentioned RFCs = here and then I'll figure out if this needs to go back through the WG = and last calls or not. >>=20 >> = http://www.iana.org/assignments/radius-types/radius-types.xhtml#radius-typ= es-2 >>=20 >> RFC 4072 defines EAP-Key-Name. It's in the RADIUS space, but t's = defined to have a Diameter data type "OctetString". We can't use = "OctetString" for a RADIUS data types, so the "data types" document = defines it as the RADIUS data type "string". Which ends up being the = same for all intents and purposes. >>=20 >> RFC 7268 defines a bunch of attributes. Most are of 32-bit = integers, which maps well to the data types doc. The only real "new" = thing is EAPoL-Announcement. It's defined manually in RFC 7268 as = "concatenate the fragments together before looking at it". The data = types doc calls this out as a special data type "concat", along with = EAP-Message, and a few others. >>=20 >> I think everyone is in agreement as to what the data types should = be. The "updates RFC 4072 / 7268" note is really saying "RFC 4072 / = 7268 talks about this attribute, but doesn't really give an adequate = definition for it. So the data types document picks something, which is = compatible with the original definition, but uses a now-standard data = type" >>=20 >> i.e. the original spec isn't so much wrong, as unclear and = incomplete. >>=20 >> This seems like a small enough 'updates' that I think it should be = fine to progress just adding the note that RFC4072 and RFC7268 are = updated. >>=20 >> Any objections? The alternative would be to put this back through = the last call process, but I think this looks small enough to avoid = that. It would really just be for process sake IMO. >>=20 >>=20 >> Alan DeKok. >>=20 >>=20 >>=20 >>=20 >> --=20 >>=20 >> Best regards, >> Kathleen >> _______________________________________________ >> radext mailing list >> radext@ietf.org >> https://www.ietf.org/mailman/listinfo/radext >=20 >=20 >=20 > --=20 >=20 > Best regards, > Kathleen --Apple-Mail=_2A1A1379-8F1B-4FCF-A8F3-04EFF3DDC36B Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Dear Kathleen,

Thank you for = the email.

It is not clear to us how best to = update this document.  Would the following be = correct?

OLD:
Updates: 2865, 3162, = 6158, 6572

NEW:
Updates: 2865, 3162, = 4072, 6158, 6572, = 7268


OLD:
This = document updates RFCs 2865, 3162, 6158, and = 6572.

NEW:
This document updates RFCs = 2865, 3162, 4072, 6158, 6572, and = 7268.


Thank = you.

RFC Editor/lb


On Jan 13, 2017, at 7:36 AM, Kathleen Moriarty <kathleen.moriarty.ietf@gm= ail.com> wrote:

Hello,

I think we have agreement to = continue moving forward, just noting the 'updates' since it is not a = significant update.

Thank = you,
Kathleen

On Wed, Jan 11, 2017 at 3:28 PM, Bernard Aboba = <bernard.aboba@gmail.com> = wrote:
Data types do not affect what is actually = sent on the wire, they just make it easier for a RADIUS server to add = support for an attribute without custom code. So the datatypes draft = does not create a deployment blocker or backward compatibility issue, it = actually may make implementation easier. 

On Jan 11, 2017, at 8:43 AM, Kathleen Moriarty = <kathleen.moriarty.ietf@gmail.com> = wrote:

Adding = the IESG and the working group to see if there are any concerns with the = following approach... inline

On Wed, Jan 11, 2017 at 10:40 AM, Alan DeKok <aland@freeradius.org> = wrote:

> > > a) RFCs 4072 and 7268 are not cited anywhere in this = document.
> > > Please let us know where they should be cited; otherwise, = the
> > > listings will be removed.
> >
> > The RFCs are referenced simply because this document is = updating
> > attributes that they define.
>
> Can you please list the specific updates from the 2 mentioned RFCs = here and then I'll figure out if this needs to go back through the WG = and last calls or not.

http://www.iana.org/assignments/radius-types/radius= -types.xhtml#radius-types-2

  RFC 4072 defines EAP-Key-Name.  It's in the RADIUS space, = but t's defined to have a Diameter data type "OctetString".  =  We can't use "OctetString" for a RADIUS data types, so the "data = types" document defines it as the RADIUS data type "string". Which ends = up being the same for all intents and purposes.

  RFC 7268 defines a bunch of attributes.  Most are of 32-bit = integers, which maps well to the data types doc.  The only real = "new" thing is EAPoL-Announcement.  It's defined manually in RFC = 7268 as "concatenate the fragments together before looking at it".  = The data types doc calls this out as a special data type "concat", along = with EAP-Message, and a few others.

  I think everyone is in agreement as to what the data types should = be.  The "updates RFC 4072 / 7268" note is really saying "RFC 4072 = / 7268 talks about this attribute, but doesn't really give an adequate = definition for it.  So the data types document picks something, = which is compatible with the original definition, but uses a = now-standard data type"

  i.e. the original spec isn't so much wrong, as unclear and = incomplete.

This seems like a small = enough 'updates' that I think it should be fine to progress just adding = the note that RFC4072 and RFC7268 are = updated.

Any objections?  The alternative = would be to put this back through the last call process, but I think = this looks small enough to avoid that.  It would really just be for = process sake IMO.


  Alan DeKok.




-- =

Best = regards,
Kathleen
_______________________________________________
radext mailing list
radext@ietf.org
https://www.ietf.org/mailman/listinfo/radext



--

Best = regards,
Kathleen

= --Apple-Mail=_2A1A1379-8F1B-4FCF-A8F3-04EFF3DDC36B-- From nobody Fri Jan 20 12:46:51 2017 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 E901212944D; Fri, 20 Jan 2017 12:46:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.399 X-Spam-Level: X-Spam-Status: No, score=-7.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-3.199, 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 UOuylrfl-VCj; Fri, 20 Jan 2017 12:46:45 -0800 (PST) Received: from mail.amsl.com (c8a.amsl.com [4.31.198.40]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 166F812944A; Fri, 20 Jan 2017 12:46:45 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by c8a.amsl.com (Postfix) with ESMTP id 1876F1E565F; Fri, 20 Jan 2017 12:46:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from c8a.amsl.com ([127.0.0.1]) by localhost (c8a.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dHJp-Qm4GJhj; Fri, 20 Jan 2017 12:46:21 -0800 (PST) Received: from [IPv6:2601:646:8f00:be20:8c34:2c21:f31:d958] (unknown [IPv6:2601:646:8f00:be20:8c34:2c21:f31:d958]) by c8a.amsl.com (Postfix) with ESMTPSA id 34CDB1E565E; Fri, 20 Jan 2017 12:46:21 -0800 (PST) Content-Type: multipart/alternative; boundary="Apple-Mail=_3E574CA2-88B4-4C29-BFD0-77F8CA6EBCE5" Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Lynne Bartholomew In-Reply-To: <438C29BB-EB6E-4D10-A538-B0C0F9DACC68@amsl.com> Date: Fri, 20 Jan 2017 12:46:42 -0800 Message-Id: <6A026C96-7C9B-4217-BEE1-E78FCB13487E@amsl.com> References: <20170109233022.14EE5B81304@rfc-editor.org> <438C29BB-EB6E-4D10-A538-B0C0F9DACC68@amsl.com> To: Kathleen Moriarty X-Mailer: Apple Mail (2.1878.6) Archived-At: Cc: "radext@ietf.org" , radext-ads@ietf.org, Winter Stefan , "iesg@ietf.org" , Alan DeKok , RFC Editor , radext-chairs@ietf.org, Bernard Aboba Subject: [radext] *[AD] Re: AUTH48 [LB]: RFC 8044 NOW AVAILABLE 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: Fri, 20 Jan 2017 20:46:47 -0000 --Apple-Mail=_3E574CA2-88B4-4C29-BFD0-77F8CA6EBCE5 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Dear *Kathleen, We do not believe that we have heard from you regarding our question = below. Please review, and let us know how this document should be = updated. Thank you. RFC Editor/lb On Jan 13, 2017, at 10:11 AM, Lynne Bartholomew = wrote: > Dear Kathleen, >=20 > Thank you for the email. >=20 > It is not clear to us how best to update this document. Would the = following be correct? >=20 > OLD: > Updates: 2865, 3162, 6158, 6572 >=20 > NEW: > Updates: 2865, 3162, 4072, 6158, 6572, 7268 >=20 >=20 > OLD: > This document updates RFCs 2865, 3162, 6158, and 6572. >=20 > NEW: > This document updates RFCs 2865, 3162, 4072, 6158, 6572, and 7268. >=20 >=20 > Thank you. >=20 > RFC Editor/lb >=20 >=20 > On Jan 13, 2017, at 7:36 AM, Kathleen Moriarty = wrote: >=20 >> Hello, >>=20 >> I think we have agreement to continue moving forward, just noting the = 'updates' since it is not a significant update. >>=20 >> Thank you, >> Kathleen >>=20 >> On Wed, Jan 11, 2017 at 3:28 PM, Bernard Aboba = wrote: >> Data types do not affect what is actually sent on the wire, they just = make it easier for a RADIUS server to add support for an attribute = without custom code. So the datatypes draft does not create a deployment = blocker or backward compatibility issue, it actually may make = implementation easier.=20 >>=20 >> On Jan 11, 2017, at 8:43 AM, Kathleen Moriarty = wrote: >>=20 >>> Adding the IESG and the working group to see if there are any = concerns with the following approach... inline >>>=20 >>> On Wed, Jan 11, 2017 at 10:40 AM, Alan DeKok = wrote: >>>=20 >>> > > > a) RFCs 4072 and 7268 are not cited anywhere in this document. >>> > > > Please let us know where they should be cited; otherwise, the >>> > > > listings will be removed. >>> > > >>> > > The RFCs are referenced simply because this document is updating >>> > > attributes that they define. >>> > >>> > Can you please list the specific updates from the 2 mentioned RFCs = here and then I'll figure out if this needs to go back through the WG = and last calls or not. >>>=20 >>> = http://www.iana.org/assignments/radius-types/radius-types.xhtml#radius-typ= es-2 >>>=20 >>> RFC 4072 defines EAP-Key-Name. It's in the RADIUS space, but t's = defined to have a Diameter data type "OctetString". We can't use = "OctetString" for a RADIUS data types, so the "data types" document = defines it as the RADIUS data type "string". Which ends up being the = same for all intents and purposes. >>>=20 >>> RFC 7268 defines a bunch of attributes. Most are of 32-bit = integers, which maps well to the data types doc. The only real "new" = thing is EAPoL-Announcement. It's defined manually in RFC 7268 as = "concatenate the fragments together before looking at it". The data = types doc calls this out as a special data type "concat", along with = EAP-Message, and a few others. >>>=20 >>> I think everyone is in agreement as to what the data types should = be. The "updates RFC 4072 / 7268" note is really saying "RFC 4072 / = 7268 talks about this attribute, but doesn't really give an adequate = definition for it. So the data types document picks something, which is = compatible with the original definition, but uses a now-standard data = type" >>>=20 >>> i.e. the original spec isn't so much wrong, as unclear and = incomplete. >>>=20 >>> This seems like a small enough 'updates' that I think it should be = fine to progress just adding the note that RFC4072 and RFC7268 are = updated. >>>=20 >>> Any objections? The alternative would be to put this back through = the last call process, but I think this looks small enough to avoid = that. It would really just be for process sake IMO. >>>=20 >>>=20 >>> Alan DeKok. >>>=20 >>>=20 >>>=20 >>>=20 >>> --=20 >>>=20 >>> Best regards, >>> Kathleen >>> _______________________________________________ >>> radext mailing list >>> radext@ietf.org >>> https://www.ietf.org/mailman/listinfo/radext >>=20 >>=20 >>=20 >> --=20 >>=20 >> Best regards, >> Kathleen >=20 --Apple-Mail=_3E574CA2-88B4-4C29-BFD0-77F8CA6EBCE5 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Dear = *Kathleen,

We do not believe that we have heard from = you regarding our question below.  Please review, and let us know = how this document should be updated.

Thank = you.

RFC Editor/lb


On Jan 13, 2017, at 10:11 AM, Lynne Bartholomew <lbartholomew@amsl.com> = wrote:

Dear Kathleen,

Thank you for = the email.

It is not clear to us how best to = update this document.  Would the following be = correct?

OLD:
Updates: 2865, 3162, = 6158, 6572

NEW:
Updates: 2865, 3162, = 4072, 6158, 6572, = 7268


OLD:
This = document updates RFCs 2865, 3162, 6158, and = 6572.

NEW:
This document updates RFCs = 2865, 3162, 4072, 6158, 6572, and = 7268.


Thank = you.

RFC Editor/lb


On Jan 13, 2017, at 7:36 AM, Kathleen Moriarty <kathleen.moriarty.ietf@gm= ail.com> wrote:

Hello,

I think we have agreement to = continue moving forward, just noting the 'updates' since it is not a = significant update.

Thank = you,
Kathleen

On Wed, Jan 11, 2017 at 3:28 PM, Bernard Aboba = <bernard.aboba@gmail.com> = wrote:
Data types do not affect what is actually = sent on the wire, they just make it easier for a RADIUS server to add = support for an attribute without custom code. So the datatypes draft = does not create a deployment blocker or backward compatibility issue, it = actually may make implementation easier. 

On Jan 11, 2017, at 8:43 AM, Kathleen Moriarty = <kathleen.moriarty.ietf@gmail.com> = wrote:

Adding = the IESG and the working group to see if there are any concerns with the = following approach... inline

On Wed, Jan 11, 2017 at 10:40 AM, Alan DeKok <aland@freeradius.org> = wrote:

> > > a) RFCs 4072 and 7268 are not cited anywhere in this = document.
> > > Please let us know where they should be cited; otherwise, = the
> > > listings will be removed.
> >
> > The RFCs are referenced simply because this document is = updating
> > attributes that they define.
>
> Can you please list the specific updates from the 2 mentioned RFCs = here and then I'll figure out if this needs to go back through the WG = and last calls or not.

http://www.iana.org/assignments/radius-types/radius= -types.xhtml#radius-types-2

  RFC 4072 defines EAP-Key-Name.  It's in the RADIUS space, = but t's defined to have a Diameter data type "OctetString".  =  We can't use "OctetString" for a RADIUS data types, so the "data = types" document defines it as the RADIUS data type "string". Which ends = up being the same for all intents and purposes.

  RFC 7268 defines a bunch of attributes.  Most are of 32-bit = integers, which maps well to the data types doc.  The only real = "new" thing is EAPoL-Announcement.  It's defined manually in RFC = 7268 as "concatenate the fragments together before looking at it".  = The data types doc calls this out as a special data type "concat", along = with EAP-Message, and a few others.

  I think everyone is in agreement as to what the data types should = be.  The "updates RFC 4072 / 7268" note is really saying "RFC 4072 = / 7268 talks about this attribute, but doesn't really give an adequate = definition for it.  So the data types document picks something, = which is compatible with the original definition, but uses a = now-standard data type"

  i.e. the original spec isn't so much wrong, as unclear and = incomplete.

This seems like a small = enough 'updates' that I think it should be fine to progress just adding = the note that RFC4072 and RFC7268 are = updated.

Any objections?  The alternative = would be to put this back through the last call process, but I think = this looks small enough to avoid that.  It would really just be for = process sake IMO.


  Alan DeKok.




-- =

Best = regards,
Kathleen
_______________________________________________
radext mailing list
radext@ietf.org
https://www.ietf.org/mailman/listinfo/radext



--

Best = regards,
Kathleen
=


= --Apple-Mail=_3E574CA2-88B4-4C29-BFD0-77F8CA6EBCE5-- From nobody Tue Jan 24 01:27:53 2017 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 A12E512950A; Fri, 20 Jan 2017 14:47:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.399 X-Spam-Level: X-Spam-Status: No, score=-7.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-3.199, 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 QZmR4R_Vvtmk; Fri, 20 Jan 2017 14:47:34 -0800 (PST) Received: from mail.amsl.com (c8a.amsl.com [4.31.198.40]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4934C1294F1; Fri, 20 Jan 2017 14:47:34 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by c8a.amsl.com (Postfix) with ESMTP id E00171E565F; Fri, 20 Jan 2017 14:47:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from c8a.amsl.com ([127.0.0.1]) by localhost (c8a.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7maXZ_oOOwLO; Fri, 20 Jan 2017 14:47:10 -0800 (PST) Received: from [IPv6:2601:646:8f00:be20:8c34:2c21:f31:d958] (unknown [IPv6:2601:646:8f00:be20:8c34:2c21:f31:d958]) by c8a.amsl.com (Postfix) with ESMTPSA id 1B0081E565E; Fri, 20 Jan 2017 14:47:10 -0800 (PST) Content-Type: multipart/alternative; boundary="Apple-Mail=_0DF96D75-637C-4798-84F3-C6E5E5D29C57" Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Lynne Bartholomew In-Reply-To: <6A026C96-7C9B-4217-BEE1-E78FCB13487E@amsl.com> Date: Fri, 20 Jan 2017 14:47:04 -0800 Message-Id: <967AA9E0-EC69-475E-8F61-CFF4837A3CD6@amsl.com> References: <20170109233022.14EE5B81304@rfc-editor.org> <438C29BB-EB6E-4D10-A538-B0C0F9DACC68@amsl.com> <6A026C96-7C9B-4217-BEE1-E78FCB13487E@amsl.com> To: Kathleen.Moriarty@dell.com X-Mailer: Apple Mail (2.1878.6) Archived-At: X-Mailman-Approved-At: Tue, 24 Jan 2017 01:27:48 -0800 Cc: "radext@ietf.org" , radext-ads@ietf.org, Winter Stefan , Kathleen Moriarty , "iesg@ietf.org" , Alan DeKok , RFC Editor , radext-chairs@ietf.org, Bernard Aboba Subject: Re: [radext] *[AD] Re: AUTH48 [LB]: RFC 8044 NOW AVAILABLE 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: Fri, 20 Jan 2017 22:47:35 -0000 --Apple-Mail=_0DF96D75-637C-4798-84F3-C6E5E5D29C57 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Dear Kathleen, Sending this email to your Dell address, in case the Gmail address is no = longer correct. RFC Editor/lb On Jan 20, 2017, at 12:46 PM, Lynne Bartholomew = wrote: > Dear *Kathleen, >=20 > We do not believe that we have heard from you regarding our question = below. Please review, and let us know how this document should be = updated. >=20 > Thank you. >=20 > RFC Editor/lb >=20 >=20 > On Jan 13, 2017, at 10:11 AM, Lynne Bartholomew = wrote: >=20 >> Dear Kathleen, >>=20 >> Thank you for the email. >>=20 >> It is not clear to us how best to update this document. Would the = following be correct? >>=20 >> OLD: >> Updates: 2865, 3162, 6158, 6572 >>=20 >> NEW: >> Updates: 2865, 3162, 4072, 6158, 6572, 7268 >>=20 >>=20 >> OLD: >> This document updates RFCs 2865, 3162, 6158, and 6572. >>=20 >> NEW: >> This document updates RFCs 2865, 3162, 4072, 6158, 6572, and 7268. >>=20 >>=20 >> Thank you. >>=20 >> RFC Editor/lb >>=20 >>=20 >> On Jan 13, 2017, at 7:36 AM, Kathleen Moriarty = wrote: >>=20 >>> Hello, >>>=20 >>> I think we have agreement to continue moving forward, just noting = the 'updates' since it is not a significant update. >>>=20 >>> Thank you, >>> Kathleen >>>=20 >>> On Wed, Jan 11, 2017 at 3:28 PM, Bernard Aboba = wrote: >>> Data types do not affect what is actually sent on the wire, they = just make it easier for a RADIUS server to add support for an attribute = without custom code. So the datatypes draft does not create a deployment = blocker or backward compatibility issue, it actually may make = implementation easier.=20 >>>=20 >>> On Jan 11, 2017, at 8:43 AM, Kathleen Moriarty = wrote: >>>=20 >>>> Adding the IESG and the working group to see if there are any = concerns with the following approach... inline >>>>=20 >>>> On Wed, Jan 11, 2017 at 10:40 AM, Alan DeKok = wrote: >>>>=20 >>>> > > > a) RFCs 4072 and 7268 are not cited anywhere in this = document. >>>> > > > Please let us know where they should be cited; otherwise, the >>>> > > > listings will be removed. >>>> > > >>>> > > The RFCs are referenced simply because this document is = updating >>>> > > attributes that they define. >>>> > >>>> > Can you please list the specific updates from the 2 mentioned = RFCs here and then I'll figure out if this needs to go back through the = WG and last calls or not. >>>>=20 >>>> = http://www.iana.org/assignments/radius-types/radius-types.xhtml#radius-typ= es-2 >>>>=20 >>>> RFC 4072 defines EAP-Key-Name. It's in the RADIUS space, but t's = defined to have a Diameter data type "OctetString". We can't use = "OctetString" for a RADIUS data types, so the "data types" document = defines it as the RADIUS data type "string". Which ends up being the = same for all intents and purposes. >>>>=20 >>>> RFC 7268 defines a bunch of attributes. Most are of 32-bit = integers, which maps well to the data types doc. The only real "new" = thing is EAPoL-Announcement. It's defined manually in RFC 7268 as = "concatenate the fragments together before looking at it". The data = types doc calls this out as a special data type "concat", along with = EAP-Message, and a few others. >>>>=20 >>>> I think everyone is in agreement as to what the data types should = be. The "updates RFC 4072 / 7268" note is really saying "RFC 4072 / = 7268 talks about this attribute, but doesn't really give an adequate = definition for it. So the data types document picks something, which is = compatible with the original definition, but uses a now-standard data = type" >>>>=20 >>>> i.e. the original spec isn't so much wrong, as unclear and = incomplete. >>>>=20 >>>> This seems like a small enough 'updates' that I think it should be = fine to progress just adding the note that RFC4072 and RFC7268 are = updated. >>>>=20 >>>> Any objections? The alternative would be to put this back through = the last call process, but I think this looks small enough to avoid = that. It would really just be for process sake IMO. >>>>=20 >>>>=20 >>>> Alan DeKok. >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>> --=20 >>>>=20 >>>> Best regards, >>>> Kathleen >>>> _______________________________________________ >>>> radext mailing list >>>> radext@ietf.org >>>> https://www.ietf.org/mailman/listinfo/radext >>>=20 >>>=20 >>>=20 >>> --=20 >>>=20 >>> Best regards, >>> Kathleen >>=20 >=20 --Apple-Mail=_0DF96D75-637C-4798-84F3-C6E5E5D29C57 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Dear Kathleen,

Sending this = email to your Dell address, in case the Gmail address is no longer = correct.

RFC Editor/lb

On Jan 20, 2017, at 12:46 PM, Lynne Bartholomew <lbartholomew@amsl.com> = wrote:

Dear = *Kathleen,

We do not believe that we have heard from = you regarding our question below.  Please review, and let us know = how this document should be updated.

Thank = you.

RFC Editor/lb


On Jan 13, 2017, at 10:11 AM, Lynne Bartholomew <lbartholomew@amsl.com> = wrote:

Dear Kathleen,

Thank you for = the email.

It is not clear to us how best to = update this document.  Would the following be = correct?

OLD:
Updates: 2865, 3162, = 6158, 6572

NEW:
Updates: 2865, 3162, = 4072, 6158, 6572, = 7268


OLD:
This = document updates RFCs 2865, 3162, 6158, and = 6572.

NEW:
This document updates RFCs = 2865, 3162, 4072, 6158, 6572, and = 7268.


Thank = you.

RFC Editor/lb


On Jan 13, 2017, at 7:36 AM, Kathleen Moriarty <kathleen.moriarty.ietf@gm= ail.com> wrote:

Hello,

I think we have agreement to = continue moving forward, just noting the 'updates' since it is not a = significant update.

Thank = you,
Kathleen

On Wed, Jan 11, 2017 at 3:28 PM, Bernard Aboba = <bernard.aboba@gmail.com> = wrote:
Data types do not affect what is actually = sent on the wire, they just make it easier for a RADIUS server to add = support for an attribute without custom code. So the datatypes draft = does not create a deployment blocker or backward compatibility issue, it = actually may make implementation easier. 

On Jan 11, 2017, at 8:43 AM, Kathleen Moriarty = <kathleen.moriarty.ietf@gmail.com> = wrote:

Adding = the IESG and the working group to see if there are any concerns with the = following approach... inline

On Wed, Jan 11, 2017 at 10:40 AM, Alan DeKok <aland@freeradius.org> = wrote:

> > > a) RFCs 4072 and 7268 are not cited anywhere in this = document.
> > > Please let us know where they should be cited; otherwise, = the
> > > listings will be removed.
> >
> > The RFCs are referenced simply because this document is = updating
> > attributes that they define.
>
> Can you please list the specific updates from the 2 mentioned RFCs = here and then I'll figure out if this needs to go back through the WG = and last calls or not.

http://www.iana.org/assignments/radius-types/radius= -types.xhtml#radius-types-2

  RFC 4072 defines EAP-Key-Name.  It's in the RADIUS space, = but t's defined to have a Diameter data type "OctetString".  =  We can't use "OctetString" for a RADIUS data types, so the "data = types" document defines it as the RADIUS data type "string". Which ends = up being the same for all intents and purposes.

  RFC 7268 defines a bunch of attributes.  Most are of 32-bit = integers, which maps well to the data types doc.  The only real = "new" thing is EAPoL-Announcement.  It's defined manually in RFC = 7268 as "concatenate the fragments together before looking at it".  = The data types doc calls this out as a special data type "concat", along = with EAP-Message, and a few others.

  I think everyone is in agreement as to what the data types should = be.  The "updates RFC 4072 / 7268" note is really saying "RFC 4072 = / 7268 talks about this attribute, but doesn't really give an adequate = definition for it.  So the data types document picks something, = which is compatible with the original definition, but uses a = now-standard data type"

  i.e. the original spec isn't so much wrong, as unclear and = incomplete.

This seems like a small = enough 'updates' that I think it should be fine to progress just adding = the note that RFC4072 and RFC7268 are = updated.

Any objections?  The alternative = would be to put this back through the last call process, but I think = this looks small enough to avoid that.  It would really just be for = process sake IMO.


  Alan DeKok.




-- =

Best = regards,
Kathleen
_______________________________________________
radext mailing list
radext@ietf.org
https://www.ietf.org/mailman/listinfo/radext



--

Best = regards,
Kathleen
=



= --Apple-Mail=_0DF96D75-637C-4798-84F3-C6E5E5D29C57-- From nobody Tue Jan 24 01:27:57 2017 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 36B0912952D; Fri, 20 Jan 2017 14:55:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.22 X-Spam-Level: X-Spam-Status: No, score=-2.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RCVD_IN_SORBS_SPAM=0.5, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); domainkeys=fail (1024-bit key) reason="fail (message has been altered)" header.from=Kathleen.Moriarty@dell.com header.d=dell.com; dkim=pass (1024-bit key) header.d=dell.com header.b=iuxINhdB; dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=emc.com header.b=i5NbCTeK 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 BFfqBkSdpPYn; Fri, 20 Jan 2017 14:55:06 -0800 (PST) Received: from esa8.dell-outbound.iphmx.com (esa8.dell-outbound.iphmx.com [68.232.149.218]) (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 C901512952F; Fri, 20 Jan 2017 14:55:06 -0800 (PST) DomainKey-Signature: s=smtpout; d=dell.com; c=simple; q=dns; h=Received:From:Received:Received:X-DKIM:DKIM-Signature: X-DKIM:Received:Received:Received:To:CC:Subject: Thread-Topic:Thread-Index:Date:Message-ID:References: In-Reply-To:Accept-Language:Content-Language: X-MS-Has-Attach:X-MS-TNEF-Correlator:Content-Type: MIME-Version:X-Sentrion-Hostname:X-RSA-Classifications; b=s+WgbGy3FclDWV9960HXzxncaROtN4qzviJMSGHttX4t+GVkU0UblOFq fnziKnlWt3pkKsTJj28OTMTs/ruSl9RGGTXWaFZ3LC62LktecDpL85oQ9 0ykAAr2XWY7DPJ738mHWEdqvmO3uMkA1UlHfhaUOj8Ds+ftZDoVhlqpeB I=; DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=dell.com; i=@dell.com; q=dns/txt; s=smtpout; t=1484952906; x=1516488906; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=7Imd30UNF1eK358CxkT2dSYxbuJcjcEG0qBR9L7vYZk=; b=iuxINhdB8jS7AKjfIGpEiJFhnJfHKyX1dKbvEOpursDwhRSWAYKvKPN7 gVAQ1At989vbOAFD5NYGva3+U2xL++ZlqC1j4rF77NIxUEjTtPp/3ra2z Jrr0X8oQ3jSYId+jZwm465FoUn3Bv8HTmozDVTSH3ZZjgfjjaQcveMeEq 8=; Received: from esa3.dell-outbound2.iphmx.com ([68.232.154.63]) by esa8.dell-outbound.iphmx.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 20 Jan 2017 16:55:06 -0600 From: "Moriarty, Kathleen" Received: from mailuogwdur.emc.com ([128.221.224.79]) by esa3.dell-outbound2.iphmx.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 21 Jan 2017 04:46:59 +0600 Received: from maildlpprd52.lss.emc.com (maildlpprd52.lss.emc.com [10.106.48.156]) by mailuogwprd54.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id v0KMt2AG018831 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Fri, 20 Jan 2017 17:55:03 -0500 X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd54.lss.emc.com v0KMt2AG018831 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=emc.com; s=jan2013; t=1484952904; bh=j65Nq+diZ3PrMe6i3KmGGPdKnJo=; h=From:To:CC:Subject:Date:Message-ID:References:In-Reply-To: Content-Type:MIME-Version; b=i5NbCTeKWjpVzF6yf+qA27G2alZO+6NQJzG8mMsnBTfePow2RPnuLnkbEab7ssJL+ /I4QnEMkWhkR7EQFa88u97B/4WNVFH1QoPonxq3WQd6cMBfVvdyuYQ4FE1xAABrMe4 E39WYlX1l1veo1XHF2kPWvFgj4CeU4Wie9+M/km8= X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd54.lss.emc.com v0KMt2AG018831 Received: from mailusrhubprd54.lss.emc.com (mailusrhubprd54.lss.emc.com [10.106.48.19]) by maildlpprd52.lss.emc.com (RSA Interceptor); Fri, 20 Jan 2017 17:53:46 -0500 Received: from MXHUB305.corp.emc.com (MXHUB305.corp.emc.com [10.146.3.31]) by mailusrhubprd54.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id v0KMsjNr013433 (version=TLSv1.2 cipher=AES128-SHA256 bits=128 verify=FAIL); Fri, 20 Jan 2017 17:54:45 -0500 Received: from MX307CL02.corp.emc.com ([fe80::64dd:bdd6:70f5:692a]) by MXHUB305.corp.emc.com ([10.146.3.31]) with mapi id 14.03.0266.001; Fri, 20 Jan 2017 17:54:44 -0500 To: Lynne Bartholomew Thread-Topic: *[AD] Re: [radext] AUTH48 [LB]: RFC 8044 NOW AVAILABLE Thread-Index: AQHSc28ztyCF+GkL0E2O9pYbN8xvgKFB+YP+ Date: Fri, 20 Jan 2017 22:54:44 +0000 Message-ID: <8DD90954-7366-41D9-A2F0-72BF5901B453@emc.com> References: <20170109233022.14EE5B81304@rfc-editor.org> <438C29BB-EB6E-4D10-A538-B0C0F9DACC68@amsl.com> <6A026C96-7C9B-4217-BEE1-E78FCB13487E@amsl.com>, <967AA9E0-EC69-475E-8F61-CFF4837A3CD6@amsl.com> In-Reply-To: <967AA9E0-EC69-475E-8F61-CFF4837A3CD6@amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_8DD90954736641D9A2F072BF5901B453emccom_" MIME-Version: 1.0 X-Sentrion-Hostname: mailusrhubprd54.lss.emc.com X-RSA-Classifications: public Archived-At: X-Mailman-Approved-At: Tue, 24 Jan 2017 01:27:48 -0800 Cc: "radext@ietf.org" , "radext-ads@ietf.org" , Winter Stefan , Kathleen Moriarty , "iesg@ietf.org" , Alan DeKok , RFC Editor , "radext-chairs@ietf.org" , Bernard Aboba Subject: Re: [radext] *[AD] Re: AUTH48 [LB]: RFC 8044 NOW AVAILABLE 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: Fri, 20 Jan 2017 22:55:09 -0000 --_000_8DD90954736641D9A2F072BF5901B453emccom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Lynne, Thank you, I'll look at this tonight. The gmail address is correct, but th= ese messages are consistently getting lost or filed wrong, so I need to fig= ure that out. Kathleen Please excuse typos, sent from handheld device On Jan 20, 2017, at 5:47 PM, Lynne Bartholomew > wrote: Dear Kathleen, Sending this email to your Dell address, in case the Gmail address is no lo= nger correct. RFC Editor/lb On Jan 20, 2017, at 12:46 PM, Lynne Bartholomew > wrote: Dear *Kathleen, We do not believe that we have heard from you regarding our question below.= Please review, and let us know how this document should be updated. Thank you. RFC Editor/lb On Jan 13, 2017, at 10:11 AM, Lynne Bartholomew > wrote: Dear Kathleen, Thank you for the email. It is not clear to us how best to update this document. Would the followin= g be correct? OLD: Updates: 2865, 3162, 6158, 6572 NEW: Updates: 2865, 3162, 4072, 6158, 6572, 7268 OLD: This document updates RFCs 2865, 3162, 6158, and 6572. NEW: This document updates RFCs 2865, 3162, 4072, 6158, 6572, and 7268. Thank you. RFC Editor/lb On Jan 13, 2017, at 7:36 AM, Kathleen Moriarty > wrote: Hello, I think we have agreement to continue moving forward, just noting the 'upda= tes' since it is not a significant update. Thank you, Kathleen On Wed, Jan 11, 2017 at 3:28 PM, Bernard Aboba > wrote: Data types do not affect what is actually sent on the wire, they just make = it easier for a RADIUS server to add support for an attribute without custo= m code. So the datatypes draft does not create a deployment blocker or back= ward compatibility issue, it actually may make implementation easier. On Jan 11, 2017, at 8:43 AM, Kathleen Moriarty > wrote: Adding the IESG and the working group to see if there are any concerns with= the following approach... inline On Wed, Jan 11, 2017 at 10:40 AM, Alan DeKok > wrote: > > > a) RFCs 4072 and 7268 are not cited anywhere in this document. > > > Please let us know where they should be cited; otherwise, the > > > listings will be removed. > > > > The RFCs are referenced simply because this document is updating > > attributes that they define. > > Can you please list the specific updates from the 2 mentioned RFCs here a= nd then I'll figure out if this needs to go back through the WG and last ca= lls or not. http://www.iana.org/assignments/radius-types/radius-types.xhtml#radius-type= s-2 RFC 4072 defines EAP-Key-Name. It's in the RADIUS space, but t's defined= to have a Diameter data type "OctetString". We can't use "OctetString" f= or a RADIUS data types, so the "data types" document defines it as the RADI= US data type "string". Which ends up being the same for all intents and pur= poses. RFC 7268 defines a bunch of attributes. Most are of 32-bit integers, whi= ch maps well to the data types doc. The only real "new" thing is EAPoL-Ann= ouncement. It's defined manually in RFC 7268 as "concatenate the fragments= together before looking at it". The data types doc calls this out as a sp= ecial data type "concat", along with EAP-Message, and a few others. I think everyone is in agreement as to what the data types should be. Th= e "updates RFC 4072 / 7268" note is really saying "RFC 4072 / 7268 talks ab= out this attribute, but doesn't really give an adequate definition for it. = So the data types document picks something, which is compatible with the o= riginal definition, but uses a now-standard data type" i.e. the original spec isn't so much wrong, as unclear and incomplete. This seems like a small enough 'updates' that I think it should be fine to = progress just adding the note that RFC4072 and RFC7268 are updated. Any objections? The alternative would be to put this back through the last= call process, but I think this looks small enough to avoid that. It would= really just be for process sake IMO. Alan DeKok. -- Best regards, Kathleen _______________________________________________ radext mailing list radext@ietf.org https://www.ietf.org/mailman/listinfo/radext -- Best regards, Kathleen --_000_8DD90954736641D9A2F072BF5901B453emccom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi Lynne,

Thank you, I'll look at this tonight.  = The gmail address is correct, but these messages are consistently getting l= ost or filed wrong, so I need to figure that out.

Kathleen 

Please excuse typos, sent from handheld device 

On Jan 20, 2017, at 5:47 PM, Lynne Bartholomew <lbartholomew@amsl.com> wrote:

Dear Kathleen,

Sending this email to your Dell address, in case the Gmail address is = no longer correct.

RFC Editor/lb

On Jan 20, 2017, at 12:46 PM, Lynne Bartholomew <lbartholomew@amsl.com> wrote:

Dear *Kathleen,

We do not believe that we have heard from you regarding our question b= elow.  Please review, and let us know how this document should be upda= ted.

Thank you.

RFC Editor/lb


On Jan 13, 2017, at 10:11 AM, Lynne Bartholomew <lbartholomew@amsl.com> wrote:

Dear Kathleen,

Thank you for the email.

It is not clear to us how best to update this document.  Would th= e following be correct?

OLD:
Updates: 2865, 3162, 6158, 6572

NEW:
Updates: 2865, 3162, 4072, 6158, 6572, 7268


OLD:
This document updates RFCs 2865, 3162, 6158, and 6572.

NEW:
This document updates RFCs 2865, 3162, 4072, 6158, 6572, and 7268.


Thank you.

RFC Editor/lb


On Jan 13, 2017, at 7:36 AM, Kathleen Moriarty <kathleen.moriarty.ietf@gmail.com> w= rote:

Hello,

I think we have agreement to continue moving forward, just noting the = 'updates' since it is not a significant update.

Thank you,
Kathleen

On Wed, Jan 11, 2017 at 3:28 PM, Bernard Aboba <= span dir=3D"ltr"> <bernard.ab= oba@gmail.com> wrote:
Data types do not affect what is actually sent on the wire, they just = make it easier for a RADIUS server to add support for an attribute without = custom code. So the datatypes draft does not create a deployment blocker or= backward compatibility issue, it actually may make implementation easier. 

On Jan 11, 2017, at 8:43 AM, Kathleen Moriarty <kathleen.moriarty.ietf@gmail.= com> wrote:

Adding the IESG and the working group to see if there are = any concerns with the following approach... inline

On Wed, Jan 11, 2017 at 10:40 AM, Alan DeKok <aland@freerad= ius.org> wrote:

> > > a) RFCs 4072 and 7268 are not cited anywhere in this documen= t.
> > > Please let us know where they should be cited; otherwise, th= e
> > > listings will be removed.
> >
> > The RFCs are referenced simply because this document is updating<= br> > > attributes that they define.
>
> Can you please list the specific updates from the 2 mentioned RFCs her= e and then I'll figure out if this needs to go back through the WG and last= calls or not.

http://www.iana= .org/assignments/radius-types/radius-types.xhtml#radius-types-2

  RFC 4072 defines EAP-Key-Name.  It's in the RADIUS space, but t= 's defined to have a Diameter data type "OctetString".  &nbs= p;We can't use "OctetString" for a RADIUS data types, so the &quo= t;data types" document defines it as the RADIUS data type "string= ". Which ends up being the same for all intents and purposes.

  RFC 7268 defines a bunch of attributes.  Most are of 32-bit int= egers, which maps well to the data types doc.  The only real "new= " thing is EAPoL-Announcement.  It's defined manually in RFC 7268= as "concatenate the fragments together before looking at it".&nb= sp; The data types doc calls this out as a special data type "concat"= ;, along with EAP-Message, and a few others.

  I think everyone is in agreement as to what the data types should be= .  The "updates RFC 4072 / 7268" note is really saying "= ;RFC 4072 / 7268 talks about this attribute, but doesn't really give an ade= quate definition for it.  So the data types document picks something, which is compatible with the original definition, but uses a no= w-standard data type"

  i.e. the original spec isn't so much wrong, as unclear and incomplet= e.

This seems like a small enough 'updates' that I think it should be fin= e to progress just adding the note that RFC4072 and RFC7268 are updated.

Any objections?  The alternative would be to put this back throug= h the last call process, but I think this looks small enough to avoid that.=   It would really just be for process sake IMO.


  Alan DeKok.




--

Best regards,
Kathleen
______________________________________= _________
radext mailing list
radext@ietf.org<= /a>
https://www.ietf.org/mailman/listinfo/radext



--

Best regards,
Kathleen



--_000_8DD90954736641D9A2F072BF5901B453emccom_-- From nobody Tue Jan 24 01:28:00 2017 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 874E312956C; Fri, 20 Jan 2017 15:12:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.399 X-Spam-Level: X-Spam-Status: No, score=-7.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-3.199, 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 VkOV9ZOjM-AY; Fri, 20 Jan 2017 15:12:30 -0800 (PST) Received: from mail.amsl.com (c8a.amsl.com [4.31.198.40]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0F68412956A; Fri, 20 Jan 2017 15:12:30 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by c8a.amsl.com (Postfix) with ESMTP id 97F911E565F; Fri, 20 Jan 2017 15:12:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from c8a.amsl.com ([127.0.0.1]) by localhost (c8a.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3OO5FqYeoUpa; Fri, 20 Jan 2017 15:12:06 -0800 (PST) Received: from [IPv6:2601:646:8f00:be20:8c34:2c21:f31:d958] (unknown [IPv6:2601:646:8f00:be20:8c34:2c21:f31:d958]) by c8a.amsl.com (Postfix) with ESMTPSA id C1A301E565E; Fri, 20 Jan 2017 15:12:05 -0800 (PST) Content-Type: multipart/alternative; boundary="Apple-Mail=_7BEEC42D-DAB6-4066-B40B-58E1C1944869" Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Lynne Bartholomew In-Reply-To: <8DD90954-7366-41D9-A2F0-72BF5901B453@emc.com> Date: Fri, 20 Jan 2017 15:12:27 -0800 Message-Id: <81E6CD72-5491-45F0-A4D0-6DAFE090163D@amsl.com> References: <20170109233022.14EE5B81304@rfc-editor.org> <438C29BB-EB6E-4D10-A538-B0C0F9DACC68@amsl.com> <6A026C96-7C9B-4217-BEE1-E78FCB13487E@amsl.com>, <967AA9E0-EC69-475E-8F61-CFF4837A3CD6@amsl.com> <8DD90954-7366-41D9-A2F0-72BF5901B453@emc.com> To: "Moriarty, Kathleen" X-Mailer: Apple Mail (2.1878.6) Archived-At: X-Mailman-Approved-At: Tue, 24 Jan 2017 01:27:48 -0800 Cc: "radext@ietf.org" , "radext-ads@ietf.org" , Winter Stefan , Kathleen Moriarty , "iesg@ietf.org" , Alan DeKok , RFC Editor , "radext-chairs@ietf.org" , Bernard Aboba Subject: Re: [radext] *[AD] Re: AUTH48 [LB]: RFC 8044 NOW AVAILABLE 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: Fri, 20 Jan 2017 23:12:31 -0000 --Apple-Mail=_7BEEC42D-DAB6-4066-B40B-58E1C1944869 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Dear Kathleen, Thank you very much for the prompt reply. No rush -- we just wanted to = make sure we were using the correct email address for you. Thanks again! RFC Editor/lb On Jan 20, 2017, at 2:54 PM, Moriarty, Kathleen = wrote: > Hi Lynne, >=20 > Thank you, I'll look at this tonight. The gmail address is correct, = but these messages are consistently getting lost or filed wrong, so I = need to figure that out. >=20 > Kathleen=20 >=20 > Please excuse typos, sent from handheld device=20 >=20 > On Jan 20, 2017, at 5:47 PM, Lynne Bartholomew = wrote: >=20 >> Dear Kathleen, >>=20 >> Sending this email to your Dell address, in case the Gmail address is = no longer correct. >>=20 >> RFC Editor/lb >>=20 >> On Jan 20, 2017, at 12:46 PM, Lynne Bartholomew = wrote: >>=20 >>> Dear *Kathleen, >>>=20 >>> We do not believe that we have heard from you regarding our question = below. Please review, and let us know how this document should be = updated. >>>=20 >>> Thank you. >>>=20 >>> RFC Editor/lb >>>=20 >>>=20 >>> On Jan 13, 2017, at 10:11 AM, Lynne Bartholomew = wrote: >>>=20 >>>> Dear Kathleen, >>>>=20 >>>> Thank you for the email. >>>>=20 >>>> It is not clear to us how best to update this document. Would the = following be correct? >>>>=20 >>>> OLD: >>>> Updates: 2865, 3162, 6158, 6572 >>>>=20 >>>> NEW: >>>> Updates: 2865, 3162, 4072, 6158, 6572, 7268 >>>>=20 >>>>=20 >>>> OLD: >>>> This document updates RFCs 2865, 3162, 6158, and 6572. >>>>=20 >>>> NEW: >>>> This document updates RFCs 2865, 3162, 4072, 6158, 6572, and 7268. >>>>=20 >>>>=20 >>>> Thank you. >>>>=20 >>>> RFC Editor/lb >>>>=20 >>>>=20 >>>> On Jan 13, 2017, at 7:36 AM, Kathleen Moriarty = wrote: >>>>=20 >>>>> Hello, >>>>>=20 >>>>> I think we have agreement to continue moving forward, just noting = the 'updates' since it is not a significant update. >>>>>=20 >>>>> Thank you, >>>>> Kathleen >>>>>=20 >>>>> On Wed, Jan 11, 2017 at 3:28 PM, Bernard Aboba = wrote: >>>>> Data types do not affect what is actually sent on the wire, they = just make it easier for a RADIUS server to add support for an attribute = without custom code. So the datatypes draft does not create a deployment = blocker or backward compatibility issue, it actually may make = implementation easier.=20 >>>>>=20 >>>>> On Jan 11, 2017, at 8:43 AM, Kathleen Moriarty = wrote: >>>>>=20 >>>>>> Adding the IESG and the working group to see if there are any = concerns with the following approach... inline >>>>>>=20 >>>>>> On Wed, Jan 11, 2017 at 10:40 AM, Alan DeKok = wrote: >>>>>>=20 >>>>>> > > > a) RFCs 4072 and 7268 are not cited anywhere in this = document. >>>>>> > > > Please let us know where they should be cited; otherwise, = the >>>>>> > > > listings will be removed. >>>>>> > > >>>>>> > > The RFCs are referenced simply because this document is = updating >>>>>> > > attributes that they define. >>>>>> > >>>>>> > Can you please list the specific updates from the 2 mentioned = RFCs here and then I'll figure out if this needs to go back through the = WG and last calls or not. >>>>>>=20 >>>>>> = http://www.iana.org/assignments/radius-types/radius-types.xhtml#radius-typ= es-2 >>>>>>=20 >>>>>> RFC 4072 defines EAP-Key-Name. It's in the RADIUS space, but = t's defined to have a Diameter data type "OctetString". We can't use = "OctetString" for a RADIUS data types, so the "data types" document = defines it as the RADIUS data type "string". Which ends up being the = same for all intents and purposes. >>>>>>=20 >>>>>> RFC 7268 defines a bunch of attributes. Most are of 32-bit = integers, which maps well to the data types doc. The only real "new" = thing is EAPoL-Announcement. It's defined manually in RFC 7268 as = "concatenate the fragments together before looking at it". The data = types doc calls this out as a special data type "concat", along with = EAP-Message, and a few others. >>>>>>=20 >>>>>> I think everyone is in agreement as to what the data types = should be. The "updates RFC 4072 / 7268" note is really saying "RFC = 4072 / 7268 talks about this attribute, but doesn't really give an = adequate definition for it. So the data types document picks something, = which is compatible with the original definition, but uses a = now-standard data type" >>>>>>=20 >>>>>> i.e. the original spec isn't so much wrong, as unclear and = incomplete. >>>>>>=20 >>>>>> This seems like a small enough 'updates' that I think it should = be fine to progress just adding the note that RFC4072 and RFC7268 are = updated. >>>>>>=20 >>>>>> Any objections? The alternative would be to put this back = through the last call process, but I think this looks small enough to = avoid that. It would really just be for process sake IMO. >>>>>>=20 >>>>>>=20 >>>>>> Alan DeKok. >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>> --=20 >>>>>>=20 >>>>>> Best regards, >>>>>> Kathleen >>>>>> _______________________________________________ >>>>>> radext mailing list >>>>>> radext@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/radext >>>>>=20 >>>>>=20 >>>>>=20 >>>>> --=20 >>>>>=20 >>>>> Best regards, >>>>> Kathleen >>>>=20 >>>=20 >>=20 --Apple-Mail=_7BEEC42D-DAB6-4066-B40B-58E1C1944869 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=us-ascii Dear Kathleen,

Thank you very much for the prompt reply.  No rush -- we just wanted to make sure we were using the correct email address for you.

Thanks again!

RFC Editor/lb


On Jan 20, 2017, at 2:54 PM, Moriarty, Kathleen <Kathleen.Moriarty@dell.com> wrote:

Hi Lynne,

Thank you, I'll look at this tonight.  The gmail address is correct, but these messages are consistently getting lost or filed wrong, so I need to figure that out.

Kathleen 

Please excuse typos, sent from handheld device 

On Jan 20, 2017, at 5:47 PM, Lynne Bartholomew <lbartholomew@amsl.com> wrote:

Dear Kathleen,

Sending this email to your Dell address, in case the Gmail address is no longer correct.

RFC Editor/lb

On Jan 20, 2017, at 12:46 PM, Lynne Bartholomew <lbartholomew@amsl.com> wrote:

Dear *Kathleen,

We do not believe that we have heard from you regarding our question below.  Please review, and let us know how this document should be updated.

Thank you.

RFC Editor/lb


On Jan 13, 2017, at 10:11 AM, Lynne Bartholomew <lbartholomew@amsl.com> wrote:

Dear Kathleen,

Thank you for the email.

It is not clear to us how best to update this document.  Would the following be correct?

OLD:
Updates: 2865, 3162, 6158, 6572

NEW:
Updates: 2865, 3162, 4072, 6158, 6572, 7268


OLD:
This document updates RFCs 2865, 3162, 6158, and 6572.

NEW:
This document updates RFCs 2865, 3162, 4072, 6158, 6572, and 7268.


Thank you.

RFC Editor/lb


On Jan 13, 2017, at 7:36 AM, Kathleen Moriarty <kathleen.moriarty.ietf@gmail.com> wrote:

Hello,

I think we have agreement to continue moving forward, just noting the 'updates' since it is not a significant update.

Thank you,
Kathleen

On Wed, Jan 11, 2017 at 3:28 PM, Bernard Aboba <bernard.aboba@gmail.com> wrote:
Data types do not affect what is actually sent on the wire, they just make it easier for a RADIUS server to add support for an attribute without custom code. So the datatypes draft does not create a deployment blocker or backward compatibility issue, it actually may make implementation easier. 

On Jan 11, 2017, at 8:43 AM, Kathleen Moriarty <kathleen.moriarty.ietf@gmail.com> wrote:

Adding the IESG and the working group to see if there are any concerns with the following approach... inline

On Wed, Jan 11, 2017 at 10:40 AM, Alan DeKok <aland@freeradius.org> wrote:

> > > a) RFCs 4072 and 7268 are not cited anywhere in this document.
> > > Please let us know where they should be cited; otherwise, the
> > > listings will be removed.
> >
> > The RFCs are referenced simply because this document is updating
> > attributes that they define.
>
> Can you please list the specific updates from the 2 mentioned RFCs here and then I'll figure out if this needs to go back through the WG and last calls or not.

http://www.iana.org/assignments/radius-types/radius-types.xhtml#radius-types-2

  RFC 4072 defines EAP-Key-Name.  It's in the RADIUS space, but t's defined to have a Diameter data type "OctetString".   We can't use "OctetString" for a RADIUS data types, so the "data types" document defines it as the RADIUS data type "string". Which ends up being the same for all intents and purposes.

  RFC 7268 defines a bunch of attributes.  Most are of 32-bit integers, which maps well to the data types doc.  The only real "new" thing is EAPoL-Announcement.  It's defined manually in RFC 7268 as "concatenate the fragments together before looking at it".  The data types doc calls this out as a special data type "concat", along with EAP-Message, and a few others.

  I think everyone is in agreement as to what the data types should be.  The "updates RFC 4072 / 7268" note is really saying "RFC 4072 / 7268 talks about this attribute, but doesn't really give an adequate definition for it.  So the data types document picks something, which is compatible with the original definition, but uses a now-standard data type"

  i.e. the original spec isn't so much wrong, as unclear and incomplete.

This seems like a small enough 'updates' that I think it should be fine to progress just adding the note that RFC4072 and RFC7268 are updated.

Any objections?  The alternative would be to put this back through the last call process, but I think this looks small enough to avoid that.  It would really just be for process sake IMO.


  Alan DeKok.




--

Best regards,
Kathleen
_______________________________________________
radext mailing list
radext@ietf.org
https://www.ietf.org/mailman/listinfo/radext



--

Best regards,
Kathleen




--Apple-Mail=_7BEEC42D-DAB6-4066-B40B-58E1C1944869-- From nobody Tue Jan 24 01:28:03 2017 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 E688B129B08; Sat, 21 Jan 2017 07:34:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.698 X-Spam-Level: X-Spam-Status: No, score=-2.698 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 kGsAi8vOAu1j; Sat, 21 Jan 2017 07:34:03 -0800 (PST) Received: from mail-io0-x241.google.com (mail-io0-x241.google.com [IPv6:2607:f8b0:4001:c06::241]) (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 ECA3B129B17; Sat, 21 Jan 2017 07:34:02 -0800 (PST) Received: by mail-io0-x241.google.com with SMTP id q20so10834411ioi.3; Sat, 21 Jan 2017 07:34:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=content-transfer-encoding:from:mime-version:subject:date:message-id :references:cc:in-reply-to:to; bh=cWAJJPU+NKnM6E/OkmiQp3GEYdDi9TtK0mhXyIubJI4=; b=LmYud1xuZeOsOQptDA6qOpRubpg/am6ncPgjji5CROyEBw8sfK1W+aHJTYz++iFx/0 rTw/0U4J9vWpa4xjap6ljqkkew+tw6KSNova85TK8qf9dfcso9T1wcU6LreZMzono0kB W7B/tiSkr1YehrhKqgraMlazEOVVD+cdVmwbRoR2n8cjgqAh8OzLNwfvLMGD8Qxvi+/W SUQL/tAdcREHOm4pYXB9P0NCfu05iFKmW+KmLKUrDC1d2VLBwS2lmNjTKbUYEekZgsRk nAHdX+Ipyt67DT1v5KcAl7Lu4lMbbTwvj8vJ+BaFGM/KfaYZMQHG1jtHuvsO3d/DH8FL Y3Ww== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:content-transfer-encoding:from:mime-version :subject:date:message-id:references:cc:in-reply-to:to; bh=cWAJJPU+NKnM6E/OkmiQp3GEYdDi9TtK0mhXyIubJI4=; b=YZsuOoawNNRQ+1cKjMT/t0wvQQSbb/p9aaODCAfuq7PZbuw2stc3Mrd+iki/VUB+I2 vKtRR4ZRav77AFucfwlQBVWHTTwJZ+xaT27jD8z1ZBBxmyZ8KaqlGZ+lPY7DXbRgqFkP VFNOHRftFUKpnZmVGj3jbL7NJ+USlvOSjKtnDKm7rswjDL8M6gGSn/CWCyqWimWr8PmM HJ4w2tDJfgiyYjBeNEXfy0tlBMsTsj0e7eEjX3jYCqoh9ObNPuAEvzZBPZBtD95CVoJU nW0zVAl87RRB5xAHnmdrpQhG9zRvlIRSW6yi77AMFEgxV50BU68Apc2shU1jb0GW0BMa Y5Iw== X-Gm-Message-State: AIkVDXIDBTDY+9teX0QoFuAQUua3kxVVBKSw5khQl1NiQe8FnFwKpH3J6P90P8Ou4xOvMA== X-Received: by 10.107.164.147 with SMTP id d19mr17958371ioj.79.1485012842344; Sat, 21 Jan 2017 07:34:02 -0800 (PST) Received: from [10.241.155.134] ([166.170.21.49]) by smtp.gmail.com with ESMTPSA id o1sm3246648itg.4.2017.01.21.07.34.01 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 21 Jan 2017 07:34:01 -0800 (PST) Content-Type: multipart/alternative; boundary=Apple-Mail-4ADB7164-6395-4B51-9463-A3C9EC208472 Content-Transfer-Encoding: 7bit From: kathleen.moriarty.ietf@gmail.com Mime-Version: 1.0 (1.0) Date: Sat, 21 Jan 2017 10:22:02 -0500 Message-Id: <3058D945-CC06-43FD-96FC-80542EA31C96@gmail.com> References: <20170109233022.14EE5B81304@rfc-editor.org> <438C29BB-EB6E-4D10-A538-B0C0F9DACC68@amsl.com> <6A026C96-7C9B-4217-BEE1-E78FCB13487E@amsl.com> <967AA9E0-EC69-475E-8F61-CFF4837A3CD6@amsl.com> In-Reply-To: <967AA9E0-EC69-475E-8F61-CFF4837A3CD6@amsl.com> To: Lynne Bartholomew X-Mailer: iPhone Mail (14C92) Archived-At: X-Mailman-Approved-At: Tue, 24 Jan 2017 01:27:48 -0800 Cc: Kathleen.Moriarty@dell.com, radext-ads@ietf.org, "radext@ietf.org" , Winter Stefan , "iesg@ietf.org" , Alan DeKok , RFC Editor , radext-chairs@ietf.org, Bernard Aboba Subject: Re: [radext] *[AD] Re: AUTH48 [LB]: RFC 8044 NOW AVAILABLE 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, 21 Jan 2017 15:34:06 -0000 --Apple-Mail-4ADB7164-6395-4B51-9463-A3C9EC208472 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Dear Lynne, Please excuse typos, sent from handheld device=20 > On Jan 20, 2017, at 5:47 PM, Lynne Bartholomew wro= te: >=20 > Dear Kathleen, >=20 > Sending this email to your Dell address, in case the Gmail address is no l= onger correct. >=20 > RFC Editor/lb >=20 >> On Jan 20, 2017, at 12:46 PM, Lynne Bartholomew w= rote: >>=20 >> Dear *Kathleen, >>=20 >> We do not believe that we have heard from you regarding our question belo= w. Please review, and let us know how this document should be updated. >>=20 >> Thank you. >>=20 >> RFC Editor/lb >>=20 >>=20 >>> On Jan 13, 2017, at 10:11 AM, Lynne Bartholomew w= rote: >>>=20 >>> Dear Kathleen, >>>=20 >>> Thank you for the email. >>>=20 >>> It is not clear to us how best to update this document. Would the follo= wing be correct? >>>=20 >>> OLD: >>> Updates: 2865, 3162, 6158, 6572 >>>=20 >>> NEW: >>> Updates: 2865, 3162, 4072, 6158, 6572, 7268 >>>=20 >>>=20 >>> OLD: >>> This document updates RFCs 2865, 3162, 6158, and 6572. >>>=20 >>> NEW: >>> This document updates RFCs 2865, 3162, 4072, 6158, 6572, and 7268. >>>=20 Yes, thank you. Kathleen=20 >>>=20 >>> Thank you. >>>=20 >>> RFC Editor/lb >>>=20 >>>=20 >>>> On Jan 13, 2017, at 7:36 AM, Kathleen Moriarty wrote: >>>>=20 >>>> Hello, >>>>=20 >>>> I think we have agreement to continue moving forward, just noting the '= updates' since it is not a significant update. >>>>=20 >>>> Thank you, >>>> Kathleen >>>>=20 >>>>> On Wed, Jan 11, 2017 at 3:28 PM, Bernard Aboba wrote: >>>>> Data types do not affect what is actually sent on the wire, they just m= ake it easier for a RADIUS server to add support for an attribute without cu= stom code. So the datatypes draft does not create a deployment blocker or ba= ckward compatibility issue, it actually may make implementation easier.=20 >>>>>=20 >>>>>> On Jan 11, 2017, at 8:43 AM, Kathleen Moriarty wrote: >>>>>>=20 >>>>>> Adding the IESG and the working group to see if there are any concern= s with the following approach... inline >>>>>>=20 >>>>>>> On Wed, Jan 11, 2017 at 10:40 AM, Alan DeKok w= rote: >>>>>>>=20 >>>>>>> > > > a) RFCs 4072 and 7268 are not cited anywhere in this document.= >>>>>>> > > > Please let us know where they should be cited; otherwise, the >>>>>>> > > > listings will be removed. >>>>>>> > > >>>>>>> > > The RFCs are referenced simply because this document is updating= >>>>>>> > > attributes that they define. >>>>>>> > >>>>>>> > Can you please list the specific updates from the 2 mentioned RFCs= here and then I'll figure out if this needs to go back through the WG and l= ast calls or not. >>>>>>>=20 >>>>>>> http://www.iana.org/assignments/radius-types/radius-types.xhtml#radi= us-types-2 >>>>>>>=20 >>>>>>> RFC 4072 defines EAP-Key-Name. It's in the RADIUS space, but t's d= efined to have a Diameter data type "OctetString". We can't use "OctetStri= ng" for a RADIUS data types, so the "data types" document defines it as the R= ADIUS data type "string". Which ends up being the same for all intents and p= urposes. >>>>>>>=20 >>>>>>> RFC 7268 defines a bunch of attributes. Most are of 32-bit intege= rs, which maps well to the data types doc. The only real "new" thing is EAP= oL-Announcement. It's defined manually in RFC 7268 as "concatenate the frag= ments together before looking at it". The data types doc calls this out as a= special data type "concat", along with EAP-Message, and a few others. >>>>>>>=20 >>>>>>> I think everyone is in agreement as to what the data types should b= e. The "updates RFC 4072 / 7268" note is really saying "RFC 4072 / 7268 tal= ks about this attribute, but doesn't really give an adequate definition for i= t. So the data types document picks something, which is compatible with the= original definition, but uses a now-standard data type" >>>>>>>=20 >>>>>>> i.e. the original spec isn't so much wrong, as unclear and incompl= ete. >>>>>>=20 >>>>>> This seems like a small enough 'updates' that I think it should be fi= ne to progress just adding the note that RFC4072 and RFC7268 are updated. >>>>>>=20 >>>>>> Any objections? The alternative would be to put this back through th= e last call process, but I think this looks small enough to avoid that. It w= ould really just be for process sake IMO. >>>>>>=20 >>>>>>>=20 >>>>>>> Alan DeKok. >>>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>> --=20 >>>>>>=20 >>>>>> Best regards, >>>>>> Kathleen >>>>>> _______________________________________________ >>>>>> radext mailing list >>>>>> radext@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/radext >>>>=20 >>>>=20 >>>>=20 >>>> --=20 >>>>=20 >>>> Best regards, >>>> Kathleen >>>=20 >>=20 >=20 --Apple-Mail-4ADB7164-6395-4B51-9463-A3C9EC208472 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
Dear Lynne,

Please excuse typos= , sent from handheld device 

On Jan 20, 2017, at 5:47 PM,= Lynne Bartholomew <lbartholomew= @amsl.com> wrote:

Dear&nbs= p;Kathleen,

Sending this email to your Dell address, in c= ase the Gmail address is no longer correct.

RFC Edi= tor/lb

On Jan 20, 2017, at 12:46 PM, Lynne Bartholomew <lbartholomew@amsl.com> wrote:
Dear *Kathleen,

We do not believe that we ha= ve heard from you regarding our question below.  Please review, and let= us know how this document should be updated.

Thank= you.

RFC Editor/lb


On Jan 13, 2017, at 10:11 AM, Lynne Bartholomew <lbartholomew@amsl.com> wrote:
Dear Kathleen,

Thank you for the email.=

It is not clear to us how best to update this docu= ment.  Would the following be correct?

OLD:
Updates: 2865, 3162, 6158, 6572

NEW:
<= div>Updates: 2865, 3162, 4072, 6158, 6572, 7268

OLD:
This document updates RFCs 2865, 3162, 6158, and 6= 572.

NEW:
This document updates RFCs 2865= , 3162, 4072, 6158, 6572, and 7268.

<= /div>

=
Yes, thank you.
Kathleen 
<= div>

Th= ank you.

RFC Editor/lb


On Jan 13, 2017, at 7:36 AM, Kathleen Moriarty <kathleen.moriarty.ietf@gmail.com> wrote:

Hello,

I think we have agreement t= o continue moving forward, just noting the 'updates' since it is not a signi= ficant update.

Thank you,
Kathleen
<= /div>

On Wed, Jan 1= 1, 2017 at 3:28 PM, Bernard Aboba <bernard.aboba@gmail.com> wrote:
Data types do not affect what is actually sent on the wire, they just make= it easier for a RADIUS server to add support for an attribute without custo= m code. So the datatypes draft does not create a deployment blocker or backw= ard compatibility issue, it actually may make implementation easier. 

On Jan 11, 2017, at 8:43 AM, Kathleen Mo= riarty <kathleen.moriarty.ietf@gmail.com> wrote:

Adding the IESG and the working group t= o see if there are any concerns with the following approach... inline

On Wed, Jan 11, 2017 at 1= 0:40 AM, Alan DeKok <aland@freeradius.org> wrote:

> > > a) RFCs 4072 and 7268 are not cited anywhere in this document= .
> > > Please let us know where they should be cited; otherwise, the=
> > > listings will be removed.
> >
> > The RFCs are referenced simply because this document is updating > > attributes that they define.
>
> Can you please list the specific updates from the 2 mentioned RFCs here= and then I'll figure out if this needs to go back through the WG and last c= alls or not.

http://www.iana.o= rg/assignments/radius-types/radius-types.xhtml#radius-types-2<= br>
  RFC 4072 defines EAP-Key-Name.  It's in the RADIUS space, but t'= s defined to have a Diameter data type "OctetString".   We can't u= se "OctetString" for a RADIUS data types, so the "data types" document defin= es it as the RADIUS data type "string". Which ends up being the same for all= intents and purposes.

  RFC 7268 defines a bunch of attributes.  Most are of 32-bit inte= gers, which maps well to the data types doc.  The only real "new" thing= is EAPoL-Announcement.  It's defined manually in RFC 7268 as "concaten= ate the fragments together before looking at it".  The data types doc c= alls this out as a special data type "concat", along with EAP-Message, and a= few others.

  I think everyone is in agreement as to what the data types should be.=   The "updates RFC 4072 / 7268" note is really saying "RFC 4072 / 7268 t= alks about this attribute, but doesn't really give an adequate definition fo= r it.  So the data types document picks something, which is compatible w= ith the original definition, but uses a now-standard data type"

  i.e. the original spec isn't so much wrong, as unclear and incomplete= .

This seems like a small enough 'update= s' that I think it should be fine to progress just adding the note that RFC4= 072 and RFC7268 are updated.

Any objections?  T= he alternative would be to put this back through the last call process, but I= think this looks small enough to avoid that.  It would really just be f= or process sake IMO.


  Alan DeKok.




--

Best regards,
Kathleen
___________________= ____________________________
radext mailing list=
radext@ietf.o= rg
https://www.ietf.org/mailman/listinfo/radext<= /span>


<= br>
--

Best regards,
Kathleen
=


=
= --Apple-Mail-4ADB7164-6395-4B51-9463-A3C9EC208472-- From nobody Tue Jan 24 01:28:07 2017 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 A1A2B1296C2; Mon, 23 Jan 2017 09:51:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.399 X-Spam-Level: X-Spam-Status: No, score=-7.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-3.199, 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 RgGYrnRJ1aed; Mon, 23 Jan 2017 09:51:32 -0800 (PST) Received: from mail.amsl.com (c8a.amsl.com [4.31.198.40]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B93B0129620; Mon, 23 Jan 2017 09:51:32 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by c8a.amsl.com (Postfix) with ESMTP id E4A2B1E565E; Mon, 23 Jan 2017 09:50:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from c8a.amsl.com ([127.0.0.1]) by localhost (c8a.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KocYJHhleMTR; Mon, 23 Jan 2017 09:50:56 -0800 (PST) Received: from [10.0.0.12] (c-67-188-82-176.hsd1.ca.comcast.net [67.188.82.176]) by c8a.amsl.com (Postfix) with ESMTPSA id 11DA81E5657; Mon, 23 Jan 2017 09:50:56 -0800 (PST) Content-Type: multipart/alternative; boundary="Apple-Mail=_C5CE084E-A03E-4A4B-A252-5A715206220C" Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Lynne Bartholomew In-Reply-To: <3058D945-CC06-43FD-96FC-80542EA31C96@gmail.com> Date: Mon, 23 Jan 2017 09:51:31 -0800 Message-Id: <70E0728C-DE5F-4ED2-BAD5-3FFB50D79ACA@amsl.com> References: <20170109233022.14EE5B81304@rfc-editor.org> <438C29BB-EB6E-4D10-A538-B0C0F9DACC68@amsl.com> <6A026C96-7C9B-4217-BEE1-E78FCB13487E@amsl.com> <967AA9E0-EC69-475E-8F61-CFF4837A3CD6@amsl.com> <3058D945-CC06-43FD-96FC-80542EA31C96@gmail.com> To: Kathleen.Moriarty@dell.com X-Mailer: Apple Mail (2.1878.6) Archived-At: X-Mailman-Approved-At: Tue, 24 Jan 2017 01:27:48 -0800 Cc: "radext@ietf.org" , radext-ads@ietf.org, Winter Stefan , kathleen.moriarty.ietf@gmail.com, "iesg@ietf.org" , Alan DeKok , RFC Editor , radext-chairs@ietf.org, Bernard Aboba Subject: Re: [radext] *[AD] Re: AUTH48 [LB]: RFC 8044 NOW AVAILABLE 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, 23 Jan 2017 17:51:34 -0000 --Apple-Mail=_C5CE084E-A03E-4A4B-A252-5A715206220C Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Dear Kathleen, We updated the first-page header and the Abstract per your note below. The updated files are here: http://www.rfc-editor.org/authors/rfc8044.txt http://www.rfc-editor.org/authors/rfc8044-diff.html This diff file shows these latest changes: http://www.rfc-editor.org/authors/rfc8044-lastdiff.html We have noted your approval on the AUTH48 status page: https://www.rfc-editor.org/auth48/rfc8044 We will prepare this document for publication shortly, along with its = companion document RFC 8045. Thank you! RFC Editor/lb On Jan 21, 2017, at 7:22 AM, kathleen.moriarty.ietf@gmail.com wrote: > Dear Lynne, >=20 > Please excuse typos, sent from handheld device=20 >=20 > On Jan 20, 2017, at 5:47 PM, Lynne Bartholomew = wrote: >=20 >> Dear Kathleen, >>=20 >> Sending this email to your Dell address, in case the Gmail address is = no longer correct. >>=20 >> RFC Editor/lb >>=20 >> On Jan 20, 2017, at 12:46 PM, Lynne Bartholomew = wrote: >>=20 >>> Dear *Kathleen, >>>=20 >>> We do not believe that we have heard from you regarding our question = below. Please review, and let us know how this document should be = updated. >>>=20 >>> Thank you. >>>=20 >>> RFC Editor/lb >>>=20 >>>=20 >>> On Jan 13, 2017, at 10:11 AM, Lynne Bartholomew = wrote: >>>=20 >>>> Dear Kathleen, >>>>=20 >>>> Thank you for the email. >>>>=20 >>>> It is not clear to us how best to update this document. Would the = following be correct? >>>>=20 >>>> OLD: >>>> Updates: 2865, 3162, 6158, 6572 >>>>=20 >>>> NEW: >>>> Updates: 2865, 3162, 4072, 6158, 6572, 7268 >>>>=20 >>>>=20 >>>> OLD: >>>> This document updates RFCs 2865, 3162, 6158, and 6572. >>>>=20 >>>> NEW: >>>> This document updates RFCs 2865, 3162, 4072, 6158, 6572, and 7268. >>>>=20 >=20 > Yes, thank you. > Kathleen=20 >>>>=20 >>>> Thank you. >>>>=20 >>>> RFC Editor/lb >>>>=20 >>>>=20 >>>> On Jan 13, 2017, at 7:36 AM, Kathleen Moriarty = wrote: >>>>=20 >>>>> Hello, >>>>>=20 >>>>> I think we have agreement to continue moving forward, just noting = the 'updates' since it is not a significant update. >>>>>=20 >>>>> Thank you, >>>>> Kathleen >>>>>=20 >>>>> On Wed, Jan 11, 2017 at 3:28 PM, Bernard Aboba = wrote: >>>>> Data types do not affect what is actually sent on the wire, they = just make it easier for a RADIUS server to add support for an attribute = without custom code. So the datatypes draft does not create a deployment = blocker or backward compatibility issue, it actually may make = implementation easier.=20 >>>>>=20 >>>>> On Jan 11, 2017, at 8:43 AM, Kathleen Moriarty = wrote: >>>>>=20 >>>>>> Adding the IESG and the working group to see if there are any = concerns with the following approach... inline >>>>>>=20 >>>>>> On Wed, Jan 11, 2017 at 10:40 AM, Alan DeKok = wrote: >>>>>>=20 >>>>>> > > > a) RFCs 4072 and 7268 are not cited anywhere in this = document. >>>>>> > > > Please let us know where they should be cited; otherwise, = the >>>>>> > > > listings will be removed. >>>>>> > > >>>>>> > > The RFCs are referenced simply because this document is = updating >>>>>> > > attributes that they define. >>>>>> > >>>>>> > Can you please list the specific updates from the 2 mentioned = RFCs here and then I'll figure out if this needs to go back through the = WG and last calls or not. >>>>>>=20 >>>>>> = http://www.iana.org/assignments/radius-types/radius-types.xhtml#radius-typ= es-2 >>>>>>=20 >>>>>> RFC 4072 defines EAP-Key-Name. It's in the RADIUS space, but = t's defined to have a Diameter data type "OctetString". We can't use = "OctetString" for a RADIUS data types, so the "data types" document = defines it as the RADIUS data type "string". Which ends up being the = same for all intents and purposes. >>>>>>=20 >>>>>> RFC 7268 defines a bunch of attributes. Most are of 32-bit = integers, which maps well to the data types doc. The only real "new" = thing is EAPoL-Announcement. It's defined manually in RFC 7268 as = "concatenate the fragments together before looking at it". The data = types doc calls this out as a special data type "concat", along with = EAP-Message, and a few others. >>>>>>=20 >>>>>> I think everyone is in agreement as to what the data types = should be. The "updates RFC 4072 / 7268" note is really saying "RFC = 4072 / 7268 talks about this attribute, but doesn't really give an = adequate definition for it. So the data types document picks something, = which is compatible with the original definition, but uses a = now-standard data type" >>>>>>=20 >>>>>> i.e. the original spec isn't so much wrong, as unclear and = incomplete. >>>>>>=20 >>>>>> This seems like a small enough 'updates' that I think it should = be fine to progress just adding the note that RFC4072 and RFC7268 are = updated. >>>>>>=20 >>>>>> Any objections? The alternative would be to put this back = through the last call process, but I think this looks small enough to = avoid that. It would really just be for process sake IMO. >>>>>>=20 >>>>>>=20 >>>>>> Alan DeKok. >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>> --=20 >>>>>>=20 >>>>>> Best regards, >>>>>> Kathleen >>>>>> _______________________________________________ >>>>>> radext mailing list >>>>>> radext@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/radext >>>>>=20 >>>>>=20 >>>>>=20 >>>>> --=20 >>>>>=20 >>>>> Best regards, >>>>> Kathleen >>>>=20 >>>=20 >>=20 --Apple-Mail=_C5CE084E-A03E-4A4B-A252-5A715206220C Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Dear = Kathleen,

We updated the first-page header and the = Abstract per your note below.

The updated files = are here:


=
This diff file shows these latest = changes:


We have noted your approval on the AUTH48 status = page:



We will = prepare this document for publication shortly, along with its companion = document RFC 8045.

Thank = you!

RFC Editor/lb


On Jan 21, 2017, at 7:22 AM, kathleen.moriarty.ietf@gm= ail.com wrote:

Dear Lynne,

Please excuse typos, sent from = handheld device 

On Jan 20, 2017, at 5:47 PM, Lynne = Bartholomew <lbartholomew@amsl.com> = wrote:

Dear Kathleen,

Sending this = email to your Dell address, in case the Gmail address is no longer = correct.

RFC Editor/lb

On Jan 20, 2017, at 12:46 PM, Lynne Bartholomew <lbartholomew@amsl.com> = wrote:

Dear = *Kathleen,

We do not believe that we have heard from = you regarding our question below.  Please review, and let us know = how this document should be updated.

Thank = you.

RFC Editor/lb


On Jan 13, 2017, at 10:11 AM, Lynne Bartholomew <lbartholomew@amsl.com> = wrote:

Dear Kathleen,

Thank you for = the email.

It is not clear to us how best to = update this document.  Would the following be = correct?

OLD:
Updates: 2865, 3162, = 6158, 6572

NEW:
Updates: 2865, 3162, = 4072, 6158, 6572, = 7268


OLD:
This = document updates RFCs 2865, 3162, 6158, and = 6572.

NEW:
This document updates RFCs = 2865, 3162, 4072, 6158, 6572, and = 7268.


Yes, thank = you.
Kathleen 

Thank = you.

RFC Editor/lb


On Jan 13, 2017, at 7:36 AM, Kathleen Moriarty <kathleen.moriarty.ietf@gm= ail.com> wrote:

Hello,

I think we have agreement to = continue moving forward, just noting the 'updates' since it is not a = significant update.

Thank = you,
Kathleen

On Wed, Jan 11, 2017 at 3:28 PM, Bernard Aboba = <bernard.aboba@gmail.com> = wrote:
Data types do not affect what is actually = sent on the wire, they just make it easier for a RADIUS server to add = support for an attribute without custom code. So the datatypes draft = does not create a deployment blocker or backward compatibility issue, it = actually may make implementation easier. 

On Jan 11, 2017, at 8:43 AM, Kathleen Moriarty = <kathleen.moriarty.ietf@gmail.com> = wrote:

Adding = the IESG and the working group to see if there are any concerns with the = following approach... inline

On Wed, Jan 11, 2017 at 10:40 AM, Alan DeKok <aland@freeradius.org> = wrote:

> > > a) RFCs 4072 and 7268 are not cited anywhere in this = document.
> > > Please let us know where they should be cited; otherwise, = the
> > > listings will be removed.
> >
> > The RFCs are referenced simply because this document is = updating
> > attributes that they define.
>
> Can you please list the specific updates from the 2 mentioned RFCs = here and then I'll figure out if this needs to go back through the WG = and last calls or not.

http://www.iana.org/assignments/radius-types/radius= -types.xhtml#radius-types-2

  RFC 4072 defines EAP-Key-Name.  It's in the RADIUS space, = but t's defined to have a Diameter data type "OctetString".  =  We can't use "OctetString" for a RADIUS data types, so the "data = types" document defines it as the RADIUS data type "string". Which ends = up being the same for all intents and purposes.

  RFC 7268 defines a bunch of attributes.  Most are of 32-bit = integers, which maps well to the data types doc.  The only real = "new" thing is EAPoL-Announcement.  It's defined manually in RFC = 7268 as "concatenate the fragments together before looking at it".  = The data types doc calls this out as a special data type "concat", along = with EAP-Message, and a few others.

  I think everyone is in agreement as to what the data types should = be.  The "updates RFC 4072 / 7268" note is really saying "RFC 4072 = / 7268 talks about this attribute, but doesn't really give an adequate = definition for it.  So the data types document picks something, = which is compatible with the original definition, but uses a = now-standard data type"

  i.e. the original spec isn't so much wrong, as unclear and = incomplete.

This seems like a small = enough 'updates' that I think it should be fine to progress just adding = the note that RFC4072 and RFC7268 are = updated.

Any objections?  The alternative = would be to put this back through the last call process, but I think = this looks small enough to avoid that.  It would really just be for = process sake IMO.


  Alan DeKok.




-- =

Best = regards,
Kathleen
_______________________________________________
radext mailing list
radext@ietf.org
https://www.ietf.org/mailman/listinfo/radext



--

Best = regards,
Kathleen
=




= = --Apple-Mail=_C5CE084E-A03E-4A4B-A252-5A715206220C-- From nobody Tue Jan 24 01:28:10 2017 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 2ED4E129785; Mon, 23 Jan 2017 10:44:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.399 X-Spam-Level: X-Spam-Status: No, score=-7.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-3.199, 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 v8D1csUwv9sC; Mon, 23 Jan 2017 10:44:24 -0800 (PST) Received: from mail.amsl.com (c8a.amsl.com [4.31.198.40]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C7CAE12979D; Mon, 23 Jan 2017 10:44:24 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by c8a.amsl.com (Postfix) with ESMTP id C083B1E5656; Mon, 23 Jan 2017 10:43:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from c8a.amsl.com ([127.0.0.1]) by localhost (c8a.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d6aq2BC4JriY; Mon, 23 Jan 2017 10:43:48 -0800 (PST) Received: from [10.0.0.12] (c-67-188-82-176.hsd1.ca.comcast.net [67.188.82.176]) by c8a.amsl.com (Postfix) with ESMTPSA id E6D7B1E55CC; Mon, 23 Jan 2017 10:43:47 -0800 (PST) Content-Type: multipart/alternative; boundary="Apple-Mail=_C8D1D635-9BD7-4A1B-8097-6F585C54C0B0" Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Lynne Bartholomew In-Reply-To: <70E0728C-DE5F-4ED2-BAD5-3FFB50D79ACA@amsl.com> Date: Mon, 23 Jan 2017 10:44:22 -0800 Message-Id: References: <20170109233022.14EE5B81304@rfc-editor.org> <438C29BB-EB6E-4D10-A538-B0C0F9DACC68@amsl.com> <6A026C96-7C9B-4217-BEE1-E78FCB13487E@amsl.com> <967AA9E0-EC69-475E-8F61-CFF4837A3CD6@amsl.com> <3058D945-CC06-43FD-96FC-80542EA31C96@gmail.com> <70E0728C-DE5F-4ED2-BAD5-3FFB50D79ACA@amsl.com> To: Alan DeKok , Kathleen.Moriarty@dell.com X-Mailer: Apple Mail (2.1878.6) Archived-At: X-Mailman-Approved-At: Tue, 24 Jan 2017 01:27:48 -0800 Cc: "radext@ietf.org" , radext-ads@ietf.org, Winter Stefan , kathleen.moriarty.ietf@gmail.com, "iesg@ietf.org" , RFC Editor , radext-chairs@ietf.org, Bernard Aboba Subject: [radext] *[AD] Re: AUTH48 [LB]: RFC 8044 NOW AVAILABLE 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, 23 Jan 2017 18:44:28 -0000 --Apple-Mail=_C8D1D635-9BD7-4A1B-8097-6F585C54C0B0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Dear Alan and *Kathleen, We are preparing this document for publication, and we found that our = question regarding the listing for RFC 4072 was not addressed. RFC 4072 is listed under Normative References, but it is not cited = anywhere in the text. Please let us know whether it should be cited = somewhere or removed from the references list. Note for *Kathleen: If = the choice is to remove the reference, we will need your approval, = because it is listed as Normative. Thank you. RFC Editor/lb On Jan 23, 2017, at 9:51 AM, Lynne Bartholomew = wrote: > Dear Kathleen, >=20 > We updated the first-page header and the Abstract per your note below. >=20 > The updated files are here: >=20 > http://www.rfc-editor.org/authors/rfc8044.txt > http://www.rfc-editor.org/authors/rfc8044-diff.html >=20 > This diff file shows these latest changes: >=20 > http://www.rfc-editor.org/authors/rfc8044-lastdiff.html >=20 > We have noted your approval on the AUTH48 status page: >=20 > https://www.rfc-editor.org/auth48/rfc8044 >=20 >=20 > We will prepare this document for publication shortly, along with its = companion document RFC 8045. >=20 > Thank you! >=20 > RFC Editor/lb >=20 >=20 > On Jan 21, 2017, at 7:22 AM, kathleen.moriarty.ietf@gmail.com wrote: >=20 >> Dear Lynne, >>=20 >> Please excuse typos, sent from handheld device=20 >>=20 >> On Jan 20, 2017, at 5:47 PM, Lynne Bartholomew = wrote: >>=20 >>> Dear Kathleen, >>>=20 >>> Sending this email to your Dell address, in case the Gmail address = is no longer correct. >>>=20 >>> RFC Editor/lb >>>=20 >>> On Jan 20, 2017, at 12:46 PM, Lynne Bartholomew = wrote: >>>=20 >>>> Dear *Kathleen, >>>>=20 >>>> We do not believe that we have heard from you regarding our = question below. Please review, and let us know how this document should = be updated. >>>>=20 >>>> Thank you. >>>>=20 >>>> RFC Editor/lb >>>>=20 >>>>=20 >>>> On Jan 13, 2017, at 10:11 AM, Lynne Bartholomew = wrote: >>>>=20 >>>>> Dear Kathleen, >>>>>=20 >>>>> Thank you for the email. >>>>>=20 >>>>> It is not clear to us how best to update this document. Would the = following be correct? >>>>>=20 >>>>> OLD: >>>>> Updates: 2865, 3162, 6158, 6572 >>>>>=20 >>>>> NEW: >>>>> Updates: 2865, 3162, 4072, 6158, 6572, 7268 >>>>>=20 >>>>>=20 >>>>> OLD: >>>>> This document updates RFCs 2865, 3162, 6158, and 6572. >>>>>=20 >>>>> NEW: >>>>> This document updates RFCs 2865, 3162, 4072, 6158, 6572, and 7268. >>>>>=20 >>=20 >> Yes, thank you. >> Kathleen=20 >>>>>=20 >>>>> Thank you. >>>>>=20 >>>>> RFC Editor/lb >>>>>=20 >>>>>=20 >>>>> On Jan 13, 2017, at 7:36 AM, Kathleen Moriarty = wrote: >>>>>=20 >>>>>> Hello, >>>>>>=20 >>>>>> I think we have agreement to continue moving forward, just noting = the 'updates' since it is not a significant update. >>>>>>=20 >>>>>> Thank you, >>>>>> Kathleen >>>>>>=20 >>>>>> On Wed, Jan 11, 2017 at 3:28 PM, Bernard Aboba = wrote: >>>>>> Data types do not affect what is actually sent on the wire, they = just make it easier for a RADIUS server to add support for an attribute = without custom code. So the datatypes draft does not create a deployment = blocker or backward compatibility issue, it actually may make = implementation easier.=20 >>>>>>=20 >>>>>> On Jan 11, 2017, at 8:43 AM, Kathleen Moriarty = wrote: >>>>>>=20 >>>>>>> Adding the IESG and the working group to see if there are any = concerns with the following approach... inline >>>>>>>=20 >>>>>>> On Wed, Jan 11, 2017 at 10:40 AM, Alan DeKok = wrote: >>>>>>>=20 >>>>>>> > > > a) RFCs 4072 and 7268 are not cited anywhere in this = document. >>>>>>> > > > Please let us know where they should be cited; otherwise, = the >>>>>>> > > > listings will be removed. >>>>>>> > > >>>>>>> > > The RFCs are referenced simply because this document is = updating >>>>>>> > > attributes that they define. >>>>>>> > >>>>>>> > Can you please list the specific updates from the 2 mentioned = RFCs here and then I'll figure out if this needs to go back through the = WG and last calls or not. >>>>>>>=20 >>>>>>> = http://www.iana.org/assignments/radius-types/radius-types.xhtml#radius-typ= es-2 >>>>>>>=20 >>>>>>> RFC 4072 defines EAP-Key-Name. It's in the RADIUS space, but = t's defined to have a Diameter data type "OctetString". We can't use = "OctetString" for a RADIUS data types, so the "data types" document = defines it as the RADIUS data type "string". Which ends up being the = same for all intents and purposes. >>>>>>>=20 >>>>>>> RFC 7268 defines a bunch of attributes. Most are of 32-bit = integers, which maps well to the data types doc. The only real "new" = thing is EAPoL-Announcement. It's defined manually in RFC 7268 as = "concatenate the fragments together before looking at it". The data = types doc calls this out as a special data type "concat", along with = EAP-Message, and a few others. >>>>>>>=20 >>>>>>> I think everyone is in agreement as to what the data types = should be. The "updates RFC 4072 / 7268" note is really saying "RFC = 4072 / 7268 talks about this attribute, but doesn't really give an = adequate definition for it. So the data types document picks something, = which is compatible with the original definition, but uses a = now-standard data type" >>>>>>>=20 >>>>>>> i.e. the original spec isn't so much wrong, as unclear and = incomplete. >>>>>>>=20 >>>>>>> This seems like a small enough 'updates' that I think it should = be fine to progress just adding the note that RFC4072 and RFC7268 are = updated. >>>>>>>=20 >>>>>>> Any objections? The alternative would be to put this back = through the last call process, but I think this looks small enough to = avoid that. It would really just be for process sake IMO. >>>>>>>=20 >>>>>>>=20 >>>>>>> Alan DeKok. >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>> --=20 >>>>>>>=20 >>>>>>> Best regards, >>>>>>> Kathleen >>>>>>> _______________________________________________ >>>>>>> radext mailing list >>>>>>> radext@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/radext >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>> --=20 >>>>>>=20 >>>>>> Best regards, >>>>>> Kathleen >>>>>=20 >>>>=20 >>>=20 >=20 --Apple-Mail=_C8D1D635-9BD7-4A1B-8097-6F585C54C0B0 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Dear = Alan and *Kathleen,

We are preparing this document = for publication, and we found that our question regarding the listing = for RFC 4072 was not addressed.

RFC 4072 is = listed under Normative References, but it is not cited anywhere in the = text.  Please let us know whether it should be cited somewhere or = removed from the references list.  Note for *Kathleen:  If the = choice is to remove the reference, we will need your approval, because = it is listed as Normative.

Thank = you.

RFC Editor/lb

On Jan 23, 2017, at 9:51 AM, Lynne Bartholomew <lbartholomew@amsl.com> = wrote:

Dear = Kathleen,

We updated the first-page header and the = Abstract per your note below.

The updated files = are here:


=
This diff file shows these latest = changes:


We have noted your approval on the AUTH48 status = page:



We will = prepare this document for publication shortly, along with its companion = document RFC 8045.

Thank = you!

RFC Editor/lb


On Jan 21, 2017, at 7:22 AM, kathleen.moriarty.ietf@gm= ail.com wrote:

Dear Lynne,

Please excuse typos, sent from = handheld device 

On Jan 20, 2017, at 5:47 PM, Lynne = Bartholomew <lbartholomew@amsl.com> = wrote:

Dear Kathleen,

Sending this = email to your Dell address, in case the Gmail address is no longer = correct.

RFC Editor/lb

On Jan 20, 2017, at 12:46 PM, Lynne Bartholomew <lbartholomew@amsl.com> = wrote:

Dear = *Kathleen,

We do not believe that we have heard from = you regarding our question below.  Please review, and let us know = how this document should be updated.

Thank = you.

RFC Editor/lb


On Jan 13, 2017, at 10:11 AM, Lynne Bartholomew <lbartholomew@amsl.com> = wrote:

Dear Kathleen,

Thank you for = the email.

It is not clear to us how best to = update this document.  Would the following be = correct?

OLD:
Updates: 2865, 3162, = 6158, 6572

NEW:
Updates: 2865, 3162, = 4072, 6158, 6572, = 7268


OLD:
This = document updates RFCs 2865, 3162, 6158, and = 6572.

NEW:
This document updates RFCs = 2865, 3162, 4072, 6158, 6572, and = 7268.


Yes, thank = you.
Kathleen 

Thank = you.

RFC Editor/lb


On Jan 13, 2017, at 7:36 AM, Kathleen Moriarty <kathleen.moriarty.ietf@gm= ail.com> wrote:

Hello,

I think we have agreement to = continue moving forward, just noting the 'updates' since it is not a = significant update.

Thank = you,
Kathleen

On Wed, Jan 11, 2017 at 3:28 PM, Bernard Aboba = <bernard.aboba@gmail.com> = wrote:
Data types do not affect what is actually = sent on the wire, they just make it easier for a RADIUS server to add = support for an attribute without custom code. So the datatypes draft = does not create a deployment blocker or backward compatibility issue, it = actually may make implementation easier. 

On Jan 11, 2017, at 8:43 AM, Kathleen Moriarty = <kathleen.moriarty.ietf@gmail.com> = wrote:

Adding = the IESG and the working group to see if there are any concerns with the = following approach... inline

On Wed, Jan 11, 2017 at 10:40 AM, Alan DeKok <aland@freeradius.org> = wrote:

> > > a) RFCs 4072 and 7268 are not cited anywhere in this = document.
> > > Please let us know where they should be cited; otherwise, = the
> > > listings will be removed.
> >
> > The RFCs are referenced simply because this document is = updating
> > attributes that they define.
>
> Can you please list the specific updates from the 2 mentioned RFCs = here and then I'll figure out if this needs to go back through the WG = and last calls or not.

http://www.iana.org/assignments/radius-types/radius= -types.xhtml#radius-types-2

  RFC 4072 defines EAP-Key-Name.  It's in the RADIUS space, = but t's defined to have a Diameter data type "OctetString".  =  We can't use "OctetString" for a RADIUS data types, so the "data = types" document defines it as the RADIUS data type "string". Which ends = up being the same for all intents and purposes.

  RFC 7268 defines a bunch of attributes.  Most are of 32-bit = integers, which maps well to the data types doc.  The only real = "new" thing is EAPoL-Announcement.  It's defined manually in RFC = 7268 as "concatenate the fragments together before looking at it".  = The data types doc calls this out as a special data type "concat", along = with EAP-Message, and a few others.

  I think everyone is in agreement as to what the data types should = be.  The "updates RFC 4072 / 7268" note is really saying "RFC 4072 = / 7268 talks about this attribute, but doesn't really give an adequate = definition for it.  So the data types document picks something, = which is compatible with the original definition, but uses a = now-standard data type"

  i.e. the original spec isn't so much wrong, as unclear and = incomplete.

This seems like a small = enough 'updates' that I think it should be fine to progress just adding = the note that RFC4072 and RFC7268 are = updated.

Any objections?  The alternative = would be to put this back through the last call process, but I think = this looks small enough to avoid that.  It would really just be for = process sake IMO.


  Alan DeKok.




-- =

Best = regards,
Kathleen
_______________________________________________
radext mailing list
radext@ietf.org
https://www.ietf.org/mailman/listinfo/radext



--

Best = regards,
Kathleen
=




<= /blockquote>

= --Apple-Mail=_C8D1D635-9BD7-4A1B-8097-6F585C54C0B0-- From nobody Tue Jan 24 01:28:12 2017 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 4BD591297A8; Mon, 23 Jan 2017 10:51:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 fC1YmuSHzaSg; Mon, 23 Jan 2017 10:51:37 -0800 (PST) Received: from mail.networkradius.com (mail.networkradius.com [62.210.147.122]) by ietfa.amsl.com (Postfix) with ESMTP id 19382129496; Mon, 23 Jan 2017 10:51:34 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail.networkradius.com (Postfix) with ESMTP id EB5102C0C; Mon, 23 Jan 2017 18:51:33 +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 OYsLxEplrCgm; Mon, 23 Jan 2017 18:51:33 +0000 (UTC) Received: from [192.168.20.15] (CPEf4cc552207f0-CM00fc8dce0fa0.cpe.net.cable.rogers.com [99.230.129.191]) by mail.networkradius.com (Postfix) with ESMTPSA id 5B2972C09; Mon, 23 Jan 2017 18:51:32 +0000 (UTC) Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Content-Type: multipart/signed; boundary="Apple-Mail=_78FE74A2-B59C-4F33-A4E8-1100C533A846"; protocol="application/pgp-signature"; micalg=pgp-sha256 X-Pgp-Agent: GPGMail From: Alan DeKok In-Reply-To: Date: Mon, 23 Jan 2017 13:51:29 -0500 Message-Id: <46889561-7CC5-42E3-8021-8568590C4D6D@freeradius.org> References: <20170109233022.14EE5B81304@rfc-editor.org> <438C29BB-EB6E-4D10-A538-B0C0F9DACC68@amsl.com> <6A026C96-7C9B-4217-BEE1-E78FCB13487E@amsl.com> <967AA9E0-EC69-475E-8F61-CFF4837A3CD6@amsl.com> <3058D945-CC06-43FD-96FC-80542EA31C96@gmail.com> <70E0728C-DE5F-4ED2-BAD5-3FFB50D79ACA@amsl.com> To: Lynne Bartholomew X-Mailer: Apple Mail (2.3124) Archived-At: X-Mailman-Approved-At: Tue, 24 Jan 2017 01:27:48 -0800 Cc: Kathleen.Moriarty@dell.com, radext-ads@ietf.org, "radext@ietf.org" , Winter Stefan , Kathleen Moriarty , "iesg@ietf.org" , RFC Editor , radext-chairs@ietf.org, Bernard Aboba Subject: Re: [radext] *[AD] Re: AUTH48 [LB]: RFC 8044 NOW AVAILABLE 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, 23 Jan 2017 18:51:39 -0000 --Apple-Mail=_78FE74A2-B59C-4F33-A4E8-1100C533A846 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii >=20 > On Jan 23, 2017, at 1:44 PM, Lynne Bartholomew = wrote: >=20 > Dear Alan and *Kathleen, >=20 > We are preparing this document for publication, and we found that our = question regarding the listing for RFC 4072 was not addressed. >=20 > RFC 4072 is listed under Normative References, but it is not cited = anywhere in the text. Please let us know whether it should be cited = somewhere or removed from the references list. Note for *Kathleen: If = the choice is to remove the reference, we will need your approval, = because it is listed as Normative. It's listed as Normative because of the "Updates" line which says that = this document updates RFC 4072. The only other reference to RFC 4072 was to via an attribute in the = table which was removed. I think that leaving RFC 4072 as normative is the correct decision. --Apple-Mail=_78FE74A2-B59C-4F33-A4E8-1100C533A846 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- iQEcBAEBCAAGBQJYhlCyAAoJEH0Oec13Yh7NG8QH/RMoIhhSHrbblmcHXMjus0F+ JZZgW+IDVvWbBxMgBIVF12liJE2Uj2Osc71mPahgETjDYM3gYG4wF9nTwwt35KD4 oReFMx3dnn7eII9BVD/nfpr4RmtmNieHMQwG9SPAQD1IW7b0YzClsfbjrASUgMvB KElNCMMI5xJkH6I/g5W2P4MhO9Z5lkuxB8cpkNg1Sug7pjxwUk4TsanfB9ufhR69 QDgDNAXdCA2LkAJZ6MWrm53uOAURr8/ZsAuvQLq3iBblekU3rTZeMvVfsLeHZZoV uXnWaxwh22ef43/3WewJK1QFUY5ga4y3H+/rUYM4R4IU/I+nrbRMEK/q8X3duQo= =M5/k -----END PGP SIGNATURE----- --Apple-Mail=_78FE74A2-B59C-4F33-A4E8-1100C533A846-- From nobody Tue Jan 24 01:28:14 2017 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 053091296D6; Mon, 23 Jan 2017 10:58:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.4 X-Spam-Level: X-Spam-Status: No, score=-7.4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-3.199, 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 tjbKWII6q0hs; Mon, 23 Jan 2017 10:58:41 -0800 (PST) Received: from mail.amsl.com (c8a.amsl.com [4.31.198.40]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E568E12967E; Mon, 23 Jan 2017 10:58:41 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by c8a.amsl.com (Postfix) with ESMTP id DA33C1E565A; Mon, 23 Jan 2017 10:58:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from c8a.amsl.com ([127.0.0.1]) by localhost (c8a.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w05us5jLyIsc; Mon, 23 Jan 2017 10:58:05 -0800 (PST) Received: from [10.0.0.12] (c-67-188-82-176.hsd1.ca.comcast.net [67.188.82.176]) by c8a.amsl.com (Postfix) with ESMTPSA id 1FDA61E5657; Mon, 23 Jan 2017 10:58:05 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Lynne Bartholomew In-Reply-To: <46889561-7CC5-42E3-8021-8568590C4D6D@freeradius.org> Date: Mon, 23 Jan 2017 10:58:40 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20170109233022.14EE5B81304@rfc-editor.org> <438C29BB-EB6E-4D10-A538-B0C0F9DACC68@amsl.com> <6A026C96-7C9B-4217-BEE1-E78FCB13487E@amsl.com> <967AA9E0-EC69-475E-8F61-CFF4837A3CD6@amsl.com> <3058D945-CC06-43FD-96FC-80542EA31C96@gmail.com> <70E0728C-DE5F-4ED2-BAD5-3FFB50D79ACA@amsl.com> <46889561-7CC5-42E3-8021-8568590C4D6D@freeradius.org> To: Alan DeKok X-Mailer: Apple Mail (2.1878.6) Archived-At: X-Mailman-Approved-At: Tue, 24 Jan 2017 01:27:48 -0800 Cc: Kathleen.Moriarty@dell.com, radext-ads@ietf.org, "radext@ietf.org" , Winter Stefan , Kathleen Moriarty , "iesg@ietf.org" , RFC Editor , radext-chairs@ietf.org, Bernard Aboba Subject: Re: [radext] *[AD] Re: AUTH48 [LB]: RFC 8044 NOW AVAILABLE 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, 23 Jan 2017 18:58:43 -0000 Apologies; RFC 4072 is now in the "updates" list and is listed in the = Abstract. RFC Editor/lb On Jan 23, 2017, at 10:51 AM, Alan DeKok wrote: >>=20 >> On Jan 23, 2017, at 1:44 PM, Lynne Bartholomew = wrote: >>=20 >> Dear Alan and *Kathleen, >>=20 >> We are preparing this document for publication, and we found that our = question regarding the listing for RFC 4072 was not addressed. >>=20 >> RFC 4072 is listed under Normative References, but it is not cited = anywhere in the text. Please let us know whether it should be cited = somewhere or removed from the references list. Note for *Kathleen: If = the choice is to remove the reference, we will need your approval, = because it is listed as Normative. >=20 > It's listed as Normative because of the "Updates" line which says = that this document updates RFC 4072. >=20 > The only other reference to RFC 4072 was to via an attribute in the = table which was removed. >=20 > I think that leaving RFC 4072 as normative is the correct decision. From nobody Tue Jan 24 01:28:16 2017 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 8DC5512967E; Mon, 23 Jan 2017 10:59:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 XAJrpFJaJTo7; Mon, 23 Jan 2017 10:59:06 -0800 (PST) Received: from mail-yw0-x242.google.com (mail-yw0-x242.google.com [IPv6:2607:f8b0:4002:c05::242]) (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 CF734129496; Mon, 23 Jan 2017 10:59:05 -0800 (PST) Received: by mail-yw0-x242.google.com with SMTP id q71so13339814ywg.3; Mon, 23 Jan 2017 10:59:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=CjADKgFs0XBa9R4ukOj0E5Wtgfbkz8Yo221YOu/Xhgg=; b=A0PwVtFV2MpbvRKHUzfLUKGmRcIk62Oh73hvOjh8Usd3Ks1u+L0VQJdkpn8tpw0lE9 SPgYBYuebVAvZoQX5yLvzNtNGoX09ScH3TPCfK3OVD3onbCpkHBngKoyavnVUn3Nmim6 rqPhFe0pDIurXHKoS2uRfzYe5b83r4BBuFLeOkxTj/SGsE08M0T8DgSwUE1COehGH5PP q8W4ca2iebnbUxb6ijbnW7b3JOHvAv9D5idNBtrrkT1NS36OTbh5XoQrByuhqkjyjycx jZfPsJagBpNdFxI43yvtIZvMDqZx7Ty12ZjRR42rH/PUqLqy5sIjkcWGxJ3l1uTTH/gw YQAA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=CjADKgFs0XBa9R4ukOj0E5Wtgfbkz8Yo221YOu/Xhgg=; b=aQ30cDGBGi8NhbPx5YrfI+cM970aHUcByc603UDjawyeKMe3zXuMyt/aNInEqt/DiW df88fVfWEzOUbmeHLepuyDbYprPJfypvlDfYe/DW26Y4Wbd6q8DlomV681QVuWcjFZ5i ysD7AXHXOhwfj6M2EAL1LIl0sBXV43VlvuiFcT15ZR6HpkVrtjQsau6ROFBEiOqOle1i UqwgqaOicy8dFHR2nxnG+vkXjpX3pc8kNHXBIEX1JgL4ff7XnGi5qd1nSQACmOWkajm9 v2Yw1x5PTcrRVAR/JZadUYvJc1HjArR+n6h4dcMbZB5uqu7sXLwNnV2Kim+SC6Q7HSke SpxA== X-Gm-Message-State: AIkVDXKxVKkVvVNsRLKLWCOvYbpF3bBVBPEsQ2lYQkq9lSjNYa7yD4lmCKzVxe6PsfMI7V84405d3k0kKdp6MQ== X-Received: by 10.55.198.149 with SMTP id s21mr27743283qkl.196.1485197945040; Mon, 23 Jan 2017 10:59:05 -0800 (PST) MIME-Version: 1.0 Received: by 10.12.170.30 with HTTP; Mon, 23 Jan 2017 10:59:04 -0800 (PST) In-Reply-To: References: <20170109233022.14EE5B81304@rfc-editor.org> <438C29BB-EB6E-4D10-A538-B0C0F9DACC68@amsl.com> <6A026C96-7C9B-4217-BEE1-E78FCB13487E@amsl.com> <967AA9E0-EC69-475E-8F61-CFF4837A3CD6@amsl.com> <3058D945-CC06-43FD-96FC-80542EA31C96@gmail.com> <70E0728C-DE5F-4ED2-BAD5-3FFB50D79ACA@amsl.com> <46889561-7CC5-42E3-8021-8568590C4D6D@freeradius.org> From: Kathleen Moriarty Date: Mon, 23 Jan 2017 13:59:04 -0500 Message-ID: To: Lynne Bartholomew Content-Type: multipart/alternative; boundary=001a11451488ef7dea0546c79784 Archived-At: X-Mailman-Approved-At: Tue, 24 Jan 2017 01:27:48 -0800 Cc: "Moriarty, Kathleen" , radext-ads@ietf.org, "radext@ietf.org" , Winter Stefan , "iesg@ietf.org" , Alan DeKok , RFC Editor , radext-chairs@ietf.org, Bernard Aboba Subject: Re: [radext] *[AD] Re: AUTH48 [LB]: RFC 8044 NOW AVAILABLE 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, 23 Jan 2017 18:59:07 -0000 --001a11451488ef7dea0546c79784 Content-Type: text/plain; charset=UTF-8 Thank you, all! On Mon, Jan 23, 2017 at 1:58 PM, Lynne Bartholomew wrote: > Apologies; RFC 4072 is now in the "updates" list and is listed in the > Abstract. > > RFC Editor/lb > > On Jan 23, 2017, at 10:51 AM, Alan DeKok wrote: > > >> > >> On Jan 23, 2017, at 1:44 PM, Lynne Bartholomew > wrote: > >> > >> Dear Alan and *Kathleen, > >> > >> We are preparing this document for publication, and we found that our > question regarding the listing for RFC 4072 was not addressed. > >> > >> RFC 4072 is listed under Normative References, but it is not cited > anywhere in the text. Please let us know whether it should be cited > somewhere or removed from the references list. Note for *Kathleen: If the > choice is to remove the reference, we will need your approval, because it > is listed as Normative. > > > > It's listed as Normative because of the "Updates" line which says that > this document updates RFC 4072. > > > > The only other reference to RFC 4072 was to via an attribute in the > table which was removed. > > > > I think that leaving RFC 4072 as normative is the correct decision. > > -- Best regards, Kathleen --001a11451488ef7dea0546c79784 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Thank you, all!

On Mon, Jan 23, 2017 at 1:58 PM, Lynne Bartholomew <lbartholomew@amsl.com> wrote:
Apologies; RFC 4072 is now in the "updates" list and is lis= ted in the Abstract.

RFC Editor/lb

On Jan 23, 2017, at 10:51 AM, Alan DeKok <aland@freeradius.org> wrote:

>>
>> On Jan 23, 2017, at 1:44 PM, Lynne Bartholomew <lbartholomew@amsl.com> wrote:
>>
>> Dear Alan and *Kathleen,
>>
>> We are preparing this document for publication, and we found that = our question regarding the listing for RFC 4072 was not addressed.
>>
>> RFC 4072 is listed under Normative References, but it is not cited= anywhere in the text.=C2=A0 Please let us know whether it should be cited = somewhere or removed from the references list.=C2=A0 Note for *Kathleen:=C2= =A0 If the choice is to remove the reference, we will need your approval, b= ecause it is listed as Normative.
>
>=C2=A0 It's listed as Normative because of the "Updates" = line which says that this document updates RFC 4072.
>
>=C2=A0 The only other reference to RFC 4072 was to via an attribute in = the table which was removed.
>
>=C2=A0 I think that leaving RFC 4072 as normative is the correct decisi= on.




--
=

Best regards,
Kathleen
--001a11451488ef7dea0546c79784-- From nobody Wed Jan 25 17:29:22 2017 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 15F4B12942F; Wed, 25 Jan 2017 17:29:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.401 X-Spam-Level: X-Spam-Status: No, score=-7.401 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-3.199, SPF_HELO_PASS=-0.001, 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 wnKGRT9gPiZN; Wed, 25 Jan 2017 17:29:16 -0800 (PST) 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 DA1B7126D74; Wed, 25 Jan 2017 17:29:16 -0800 (PST) Received: by rfc-editor.org (Postfix, from userid 30) id BFE39B80F6C; Wed, 25 Jan 2017 17:29:16 -0800 (PST) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org X-PHP-Originating-Script: 1005:ams_util_lib.php From: rfc-editor@rfc-editor.org Message-Id: <20170126012916.BFE39B80F6C@rfc-editor.org> Date: Wed, 25 Jan 2017 17:29:16 -0800 (PST) Archived-At: Cc: drafts-update-ref@iana.org, radext@ietf.org, rfc-editor@rfc-editor.org Subject: [radext] RFC 8044 on Data Types 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: Thu, 26 Jan 2017 01:29:18 -0000 A new Request for Comments is now available in online RFC libraries. RFC 8044 Title: Data Types in RADIUS Author: A. DeKok Status: Standards Track Stream: IETF Date: January 2017 Mailbox: aland@freeradius.org Pages: 35 Characters: 63324 Updates: RFC 2865, RFC 3162, RFC 6158, RFC 6572, RFC 7268 I-D Tag: draft-ietf-radext-datatypes-08.txt URL: https://www.rfc-editor.org/info/rfc8044 DOI: 10.17487/RFC8044 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 the publication of RFC 2865. We provide an IANA registry for the data types and update the "RADIUS Attribute Types" 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. This document updates RFCs 2865, 3162, 4072, 6158, 6572, and 7268. This document is a product of the RADIUS EXTensions Working Group of the IETF. This is now a Proposed Standard. STANDARDS TRACK: This document specifies an Internet Standards Track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the Official Internet Protocol Standards (https://www.rfc-editor.org/standards) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see https://www.ietf.org/mailman/listinfo/ietf-announce https://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see https://www.rfc-editor.org/search For downloading RFCs, see https://www.rfc-editor.org/retrieve/bulk Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC From nobody Wed Jan 25 17:29:50 2017 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 27AFC129445; Wed, 25 Jan 2017 17:29:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.401 X-Spam-Level: X-Spam-Status: No, score=-7.401 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-3.199, SPF_HELO_PASS=-0.001, 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 UGh1Iqki5rYZ; Wed, 25 Jan 2017 17:29:37 -0800 (PST) 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 22712129444; Wed, 25 Jan 2017 17:29:33 -0800 (PST) Received: by rfc-editor.org (Postfix, from userid 30) id 0D98BB80F76; Wed, 25 Jan 2017 17:29:33 -0800 (PST) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org X-PHP-Originating-Script: 1005:ams_util_lib.php From: rfc-editor@rfc-editor.org Message-Id: <20170126012933.0D98BB80F76@rfc-editor.org> Date: Wed, 25 Jan 2017 17:29:33 -0800 (PST) Archived-At: Cc: drafts-update-ref@iana.org, radext@ietf.org, rfc-editor@rfc-editor.org Subject: [radext] RFC 8045 on RADIUS Extensions for IP Port Configuration and Reporting 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: Thu, 26 Jan 2017 01:29:44 -0000 A new Request for Comments is now available in online RFC libraries. RFC 8045 Title: RADIUS Extensions for IP Port Configuration and Reporting Author: D. Cheng, J. Korhonen, M. Boucadair, S. Sivakumar Status: Standards Track Stream: IETF Date: January 2017 Mailbox: dean.cheng@huawei.com, jouni.nospam@gmail.com, mohamed.boucadair@orange.com, ssenthil@cisco.com Pages: 43 Characters: 84193 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-radext-ip-port-radius-ext-17.txt URL: https://www.rfc-editor.org/info/rfc8045 DOI: 10.17487/RFC8045 This document defines three new RADIUS attributes. For devices that implement IP port ranges, these attributes are used to communicate with a RADIUS server in order to configure and report IP transport ports as well as mapping behavior for specific hosts. This mechanism can be used in various deployment scenarios such as Carrier-Grade NAT, IPv4/IPv6 translators, Provider WLAN gateway, etc. This document defines a mapping between some RADIUS attributes and IP Flow Information Export (IPFIX) Information Element identifiers. This document is a product of the RADIUS EXTensions Working Group of the IETF. This is now a Proposed Standard. STANDARDS TRACK: This document specifies an Internet Standards Track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the Official Internet Protocol Standards (https://www.rfc-editor.org/standards) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see https://www.ietf.org/mailman/listinfo/ietf-announce https://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see https://www.rfc-editor.org/search For downloading RFCs, see https://www.rfc-editor.org/retrieve/bulk Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC