From nobody Sun Nov 9 16:19:27 2014 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 386301A87CE for ; Sun, 9 Nov 2014 16:19:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.494 X-Spam-Level: X-Spam-Status: No, score=-2.494 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.594] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pdX2OAnwemoD for ; Sun, 9 Nov 2014 16:19:19 -0800 (PST) Received: from smtp.restena.lu (legolas.restena.lu [158.64.1.34]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 635331A87CD for ; Sun, 9 Nov 2014 16:19:19 -0800 (PST) Received: from viper.local (unknown [158.64.15.196]) by smtp.restena.lu (Postfix) with ESMTPSA id 5EA0880E05 for ; Mon, 10 Nov 2014 01:19:17 +0100 (CET) Message-ID: <54600481.2000309@restena.lu> Date: Mon, 10 Nov 2014 01:19:13 +0100 From: Stefan Winter User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: "radext@ietf.org" OpenPGP: id=8A39DC66 Content-Type: multipart/mixed; boundary="------------050901010102070300020103" Archived-At: http://mailarchive.ietf.org/arch/msg/radext/nSzaZ7_epZnf4VK0YQ__tCDsCgs Subject: [radext] Slides X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.15 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, 10 Nov 2014 00:19:24 -0000 This is a multi-part message in MIME format. --------------050901010102070300020103 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hello, if you are going to present during our radext session at IETF91, please remember to send your slides to the chairs as early as possible. You can always update slide decks closer to the meeting. The earlier we have something online, the better it is for the audience -everyone is better prepared then and we can have more informed discussions! Greetings, Stefan Winter --------------050901010102070300020103 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/MacGPG2 v2.0.19 (Darwin) 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----- --------------050901010102070300020103-- From nobody Fri Nov 14 06:17:15 2014 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 045781A0143; Fri, 14 Nov 2014 06:17:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham 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 QmpJ8UAE96R0; Fri, 14 Nov 2014 06:17:11 -0800 (PST) Received: from power.freeradius.org (power.freeradius.org [195.154.231.44]) by ietfa.amsl.com (Postfix) with ESMTP id 7ABCD1A0127; Fri, 14 Nov 2014 06:17:11 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by power.freeradius.org (Postfix) with ESMTP id E775F22402AF; Fri, 14 Nov 2014 15:17:10 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at power.freeradius.org Received: from power.freeradius.org ([127.0.0.1]) by localhost (power.freeradius.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jQuS26huzq_7; Fri, 14 Nov 2014 15:17:10 +0100 (CET) Received: from Thor.local (69-196-165-104.dsl.teksavvy.com [69.196.165.104]) by power.freeradius.org (Postfix) with ESMTPSA id 00B63224013A; Fri, 14 Nov 2014 15:17:09 +0100 (CET) Message-ID: <54660EE5.50503@deployingradius.com> Date: Fri, 14 Nov 2014 09:17:09 -0500 From: Alan DeKok User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: precis@ietf.org, "radext@ietf.org" X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/radext/2AgfvYcEvilLHcf615a3VzEfnio Subject: [radext] saslprepbis and NAI X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.15 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, 14 Nov 2014 14:17:13 -0000 The RADEXT WG is in the last stages of publishing the updated NAI document: https://tools.ietf.org/html/draft-ietf-radext-nai-10 This defines a standard for "username@realm" handling, where "realm" is a fully qualified hostname. It would be useful to reference that from the saslprepbis document. The NAI is used for EAP (802.1X), AAA, 3GPP, and international roaming. The NAI is a subset of the "userpart" defined in Section 3.1 of the saslprepbis document, in that it *requires* "username@realm", and the "realm" part is a fully qualified domain name. Hmm... I've just noticed that the ABNF in the NAI allows for IP addresses in the "realm" portion. That's not the intent. I'll have to go fix that. I'd like to be sure that the NAI document is compatible with (or at least not in violent disagreement with) the precis work. Alan DeKok. From nobody Fri Nov 14 17:51:54 2014 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D0EF11A014F for ; Fri, 14 Nov 2014 06:36:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=unavailable 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 dSHZ1z2-W633 for ; Fri, 14 Nov 2014 06:36:49 -0800 (PST) Received: from mail-ie0-f176.google.com (mail-ie0-f176.google.com [209.85.223.176]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DA3491A1A30 for ; Fri, 14 Nov 2014 06:36:48 -0800 (PST) Received: by mail-ie0-f176.google.com with SMTP id rd18so17348247iec.7 for ; Fri, 14 Nov 2014 06:36:47 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=Na3sWO81lITsfz8ErRDS0e+ypKMLCaQyVv5PHPE+LdY=; b=aryaQmYCigiZ2jRMOsolPWnSfHZzKAyl8Hp1ktcdZr9TIjE3u82kVgVaF4ItrTbs7I bWrBOvF+gHfCSODf4jScvHPSv6ibpWBhciN2y3ba/1ZsNSnqeQ2FPg5EEx7+q+WGkzqE hc4LsiS7jfgptm6Pbdf6VL5aaPtzOEJed+R6qzRQ7AcQQJLliHbp9xw0IV7RIaMFmYhL sZCh9+pIP47iZaKRghMowp4XDK/LbKw+B7NS8w29uIcHVv+Hb5oGgBsJYpYxQSjn17vD 8Lq4Uu2usfQqguVUrs3ZtGrhOQEiRi1MiVC8i40gZIirdTzH9eMXr+JNTWO3LIBsIU/+ f4Nw== X-Gm-Message-State: ALoCoQm3LOwT2kORw40qOcWt6dvYWSCQiMauZFY8GuHpiBFQv+AU+kJP6z/vk0sfWtjov8QH05kT X-Received: by 10.50.138.76 with SMTP id qo12mr6288549igb.43.1415975807316; Fri, 14 Nov 2014 06:36:47 -0800 (PST) Received: from aither.local (c-73-34-202-214.hsd1.co.comcast.net. [73.34.202.214]) by mx.google.com with ESMTPSA id w6sm1431109igp.15.2014.11.14.06.36.46 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 14 Nov 2014 06:36:46 -0800 (PST) Message-ID: <5466137D.7070406@andyet.net> Date: Fri, 14 Nov 2014 07:36:45 -0700 From: Peter Saint-Andre - &yet User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Alan DeKok , precis@ietf.org, "radext@ietf.org" References: <54660EE5.50503@deployingradius.com> In-Reply-To: <54660EE5.50503@deployingradius.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/radext/8pYjDyv7ssMAxToUzXfpjPR_PU0 X-Mailman-Approved-At: Fri, 14 Nov 2014 17:51:53 -0800 Subject: Re: [radext] [precis] saslprepbis and NAI X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.15 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, 14 Nov 2014 14:36:50 -0000 On 11/14/14, 7:17 AM, Alan DeKok wrote: > The RADEXT WG is in the last stages of publishing the updated NAI > document: > > https://tools.ietf.org/html/draft-ietf-radext-nai-10 > > This defines a standard for "username@realm" handling, where "realm" > is a fully qualified hostname. It would be useful to reference that > from the saslprepbis document. > > The NAI is used for EAP (802.1X), AAA, 3GPP, and international roaming. > > The NAI is a subset of the "userpart" defined in Section 3.1 of the > saslprepbis document, in that it *requires* "username@realm", and the > "realm" part is a fully qualified domain name. > > Hmm... I've just noticed that the ABNF in the NAI allows for IP > addresses in the "realm" portion. That's not the intent. I'll have to > go fix that. > > I'd like to be sure that the NAI document is compatible with (or at > least not in violent disagreement with) the precis work. Hi Alan, thanks for the heads-up! I am hoping that we are in violent agreement. I'll make sure to cross-check draft-ietf-radext-nai and draft-ietf-precis-saslprepbis carefully here soon. Peter -- Peter Saint-Andre https://andyet.com/ From nobody Mon Nov 24 18:53:35 2014 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 78B701A1B8D for ; Mon, 24 Nov 2014 18:53:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=unavailable 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 7jiJBOMczYKc for ; Mon, 24 Nov 2014 18:53:32 -0800 (PST) Received: from mail-ig0-f178.google.com (mail-ig0-f178.google.com [209.85.213.178]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C1EC21A1B7E for ; Mon, 24 Nov 2014 18:53:32 -0800 (PST) Received: by mail-ig0-f178.google.com with SMTP id hl2so4318602igb.5 for ; Mon, 24 Nov 2014 18:53:32 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=JvFoKwi4fsEYXnLv7pYAIsi26xBOlT/Enh+BHKuJV/U=; b=XthjvoszjOgCBoK5d4QbMyhx5jT5OMZtYTT6zwiHY5ovX0uoHkbOrErZrvFCrjVvtJ n0yc3dCY7djwE37ubBENCMdaUbjb3JMSnYEIT5uxoOhAYxxiv7+uPrWEtPEDCz7goEDQ ZmOvTIRorRsHoffkpsFHkjsgJQ2azD1xg7KANMcfjz5jXwKQpL4aSxzfPagH3GGyc37N GF6rw5wccZ2DUCK0JkbSrrvGFJQGtIngTfYO/BnRfG63SiOCAp+wivi5YOq8shKQoSua gYgwHEusodH1l2GRcwVmElhIizG0EhiORy8fXJcUktdBZ+50gNY/AveG6fwKjpR5eqi9 Dn/A== X-Gm-Message-State: ALoCoQndF5D7fxmAxzAyeeC1RpwqhbhgDOPeVQAAjHpGaOqDHDxrMBrG86KjzCmVJYfvWw+BF0Ru X-Received: by 10.50.143.73 with SMTP id sc9mr15466115igb.27.1416884012164; Mon, 24 Nov 2014 18:53:32 -0800 (PST) Received: from aither.local (c-73-34-202-214.hsd1.co.comcast.net. [73.34.202.214]) by mx.google.com with ESMTPSA id p198sm8485522iop.36.2014.11.24.18.53.31 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 24 Nov 2014 18:53:31 -0800 (PST) Message-ID: <5473EF2A.90808@andyet.net> Date: Mon, 24 Nov 2014 19:53:30 -0700 From: Peter Saint-Andre - &yet User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Alan DeKok , precis@ietf.org, "radext@ietf.org" References: <54660EE5.50503@deployingradius.com> In-Reply-To: <54660EE5.50503@deployingradius.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/radext/_jxhVzYrujp_fbdM8J4DkhYMwLg Subject: Re: [radext] [precis] saslprepbis and NAI X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Nov 2014 02:53:34 -0000 On 11/14/14, 7:17 AM, Alan DeKok wrote: > The RADEXT WG is in the last stages of publishing the updated NAI > document: > > https://tools.ietf.org/html/draft-ietf-radext-nai-10 > > This defines a standard for "username@realm" handling, where "realm" > is a fully qualified hostname. It would be useful to reference that > from the saslprepbis document. What kind of reference do you have in mind? Perhaps a pointer from Section 3.4 ("Application-Layer Constructs")? > The NAI is used for EAP (802.1X), AAA, 3GPP, and international roaming. > > The NAI is a subset of the "userpart" defined in Section 3.1 of the > saslprepbis document, in that it *requires* "username@realm", and the > "realm" part is a fully qualified domain name. > > Hmm... I've just noticed that the ABNF in the NAI allows for IP > addresses in the "realm" portion. That's not the intent. I'll have to > go fix that. > > I'd like to be sure that the NAI document is compatible with (or at > least not in violent disagreement with) the precis work. I've just reviewed the NAI specification. Although it does directly not address issues such as width mapping, case mapping, and Unicode normalization (seemingly inheriting its handling of those issues from RFC 5335 for the username portion and from IDNA2008 for the realm portion), as far as I can see it is compatible with saslprepbis. Peter -- Peter Saint-Andre https://andyet.com/ From nobody Tue Nov 25 07:50:43 2014 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 146F81A9125; Tue, 25 Nov 2014 07:50:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AlPaP8wDS80B; Tue, 25 Nov 2014 07:50:29 -0800 (PST) Received: from mail.painless-security.com (mail.painless-security.com [23.30.188.241]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D745B1A9129; Tue, 25 Nov 2014 07:50:28 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail.painless-security.com (Postfix) with ESMTP id 18C70204A2; Tue, 25 Nov 2014 10:47:41 -0500 (EST) Received: from mail.painless-security.com ([127.0.0.1]) by localhost (mail.suchdamage.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id naObQBUtmK1Q; Tue, 25 Nov 2014 10:47:40 -0500 (EST) Received: from carter-zimmerman.suchdamage.org (unknown [10.1.10.111]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.painless-security.com (Postfix) with ESMTPS; Tue, 25 Nov 2014 10:47:40 -0500 (EST) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 0186780FA6; Tue, 25 Nov 2014 10:50:26 -0500 (EST) From: Sam Hartman To: Peter Saint-Andre - &yet References: <54660EE5.50503@deployingradius.com> <5473EF2A.90808@andyet.net> Date: Tue, 25 Nov 2014 10:50:26 -0500 In-Reply-To: <5473EF2A.90808@andyet.net> (Peter Saint-Andre's message of "Mon, 24 Nov 2014 19:53:30 -0700") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain Archived-At: http://mailarchive.ietf.org/arch/msg/radext/-J505usx6sMiwbfYFA3JBH-BO8Y Cc: "radext@ietf.org" , precis@ietf.org, Alan DeKok Subject: Re: [radext] [precis] saslprepbis and NAI X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Nov 2014 15:50:32 -0000 >>>>> "Peter" == Peter Saint-Andre <- &yet > writes: Peter> I've just reviewed the NAI specification. Although it does Peter> directly not address issues such as width mapping, case Peter> mapping, and Unicode normalization (seemingly inheriting its Peter> handling of those issues from RFC 5335 for the username Peter> portion and from IDNA2008 for the realm portion), as far as I Peter> can see it is compatible with saslprepbis. So, is it our plan to address these issues in the EAP identity document? I can see the argument for not addressing them in NAI, but they need to be called out somewhere. --Sam From nobody Tue Nov 25 07:55:29 2014 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C9E441A9134; Tue, 25 Nov 2014 07:55:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham 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 nrEPfUx7Msl4; Tue, 25 Nov 2014 07:55:04 -0800 (PST) Received: from power.freeradius.org (power.freeradius.org [195.154.231.44]) by ietfa.amsl.com (Postfix) with ESMTP id EA35B1A9172; Tue, 25 Nov 2014 07:54:58 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by power.freeradius.org (Postfix) with ESMTP id CCBB0224044E; Tue, 25 Nov 2014 16:54:27 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at power.freeradius.org Received: from power.freeradius.org ([127.0.0.1]) by localhost (power.freeradius.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZY6W-aLKOa14; Tue, 25 Nov 2014 16:54:27 +0100 (CET) Received: from Thor.local (69-196-165-104.dsl.teksavvy.com [69.196.165.104]) by power.freeradius.org (Postfix) with ESMTPSA id C8C082240134; Tue, 25 Nov 2014 16:54:26 +0100 (CET) Message-ID: <5474A631.7060506@deployingradius.com> Date: Tue, 25 Nov 2014 10:54:25 -0500 From: Alan DeKok User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: Peter Saint-Andre - &yet References: <54660EE5.50503@deployingradius.com> <5473EF2A.90808@andyet.net> In-Reply-To: <5473EF2A.90808@andyet.net> X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/radext/yyFBcjd-7cr9mpkCER3IXbhc8MM Cc: "radext@ietf.org" , precis@ietf.org Subject: Re: [radext] [precis] saslprepbis and NAI X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Nov 2014 15:55:14 -0000 Peter Saint-Andre - &yet wrote: > On 11/14/14, 7:17 AM, Alan DeKok wrote: >> The RADEXT WG is in the last stages of publishing the updated NAI >> document: >> >> https://tools.ietf.org/html/draft-ietf-radext-nai-10 >> >> This defines a standard for "username@realm" handling, where "realm" >> is a fully qualified hostname. It would be useful to reference that >> from the saslprepbis document. > > What kind of reference do you have in mind? Perhaps a pointer from > Section 3.4 ("Application-Layer Constructs")? Yes. Just another indication that there are applications using the constructs. > I've just reviewed the NAI specification. Although it does directly not > address issues such as width mapping, case mapping, and Unicode > normalization (seemingly inheriting its handling of those issues from > RFC 5335 for the username portion and from IDNA2008 for the realm > portion), as far as I can see it is compatible with saslprepbis. Thanks. RFC 4282 did address many of those issues, and the conclusion was it's recommendations were wrong. This document addresses the issues by pointing to other documents. Alan DeKok. From nobody Tue Nov 25 07:55:56 2014 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 52E371A9308; Tue, 25 Nov 2014 07:55:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham 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 49toL1b-Dxs3; Tue, 25 Nov 2014 07:55:46 -0800 (PST) Received: from power.freeradius.org (power.freeradius.org [195.154.231.44]) by ietfa.amsl.com (Postfix) with ESMTP id 337971A6FCA; Tue, 25 Nov 2014 07:55:35 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by power.freeradius.org (Postfix) with ESMTP id 9E7C0224044E; Tue, 25 Nov 2014 16:55:04 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at power.freeradius.org Received: from power.freeradius.org ([127.0.0.1]) by localhost (power.freeradius.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Kr3d4O9OJqPn; Tue, 25 Nov 2014 16:55:04 +0100 (CET) Received: from Thor.local (69-196-165-104.dsl.teksavvy.com [69.196.165.104]) by power.freeradius.org (Postfix) with ESMTPSA id C1FB32240134; Tue, 25 Nov 2014 16:55:03 +0100 (CET) Message-ID: <5474A656.2080203@deployingradius.com> Date: Tue, 25 Nov 2014 10:55:02 -0500 From: Alan DeKok User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: Sam Hartman References: <54660EE5.50503@deployingradius.com> <5473EF2A.90808@andyet.net> In-Reply-To: X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/radext/KELsVJxbAj_bEHoKAvmEEQKVtFA Cc: "radext@ietf.org" , precis@ietf.org, Peter Saint-Andre - &yet Subject: Re: [radext] [precis] saslprepbis and NAI X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Nov 2014 15:55:49 -0000 Sam Hartman wrote: > So, is it our plan to address these issues in the EAP identity document? I think so, yes. Alan DeKok. From nobody Tue Nov 25 08:03:03 2014 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5A7421AC39D for ; Tue, 25 Nov 2014 08:02:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=unavailable 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 KMpEj32iCiwI for ; Tue, 25 Nov 2014 08:02:41 -0800 (PST) Received: from mail-ie0-f173.google.com (mail-ie0-f173.google.com [209.85.223.173]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DE8491AC3AD for ; Tue, 25 Nov 2014 08:01:19 -0800 (PST) Received: by mail-ie0-f173.google.com with SMTP id y20so798593ier.4 for ; Tue, 25 Nov 2014 08:01:19 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=E1tv0a4O04mOqxzSmK6BFJ5TzwxSv9ScTc134uM+l98=; b=foqBvhEi/wPmXift+fdgoE4BPJfK5KrquOGmHxfQX+5UkM2lXCvq+W6Y9TngO3u2GV U9mDoYhO9m0rgURGp+cW+Lvb5aHL0An9NJbwthZG5J3K1Fd4I7EBBK6dcsA1+6kqeCd3 tFTVEanKJMX35sgtt0eKDzvVVhw3jK8v1gV+oWJQyYW/E0quorX0r5PQyJMKxKsBgvKS u4xMM4mnHvLP/DfQIMZMmfMdfqukhqkDRKLsfI/sy6mmAdfhbqXMr582V/gb9cTVMaFD tJLw8msweJ4A9B06pBcuFJIkeDHyFXseyOfEA01pRpEeBAAbs6bOBeUUVNKeRRppxJfV rJaw== X-Gm-Message-State: ALoCoQl8EAKGEu8iNVipi+I9dtIj3HBy3mmRxRuJuBwmNUR9RwVe2F9lmZCatL8DjnEGC32BaLSD X-Received: by 10.42.130.7 with SMTP id t7mr12774894ics.25.1416931279143; Tue, 25 Nov 2014 08:01:19 -0800 (PST) Received: from aither.local (c-73-34-202-214.hsd1.co.comcast.net. [73.34.202.214]) by mx.google.com with ESMTPSA id g5sm745984iod.25.2014.11.25.08.01.18 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 25 Nov 2014 08:01:18 -0800 (PST) Message-ID: <5474A7CD.6070004@andyet.net> Date: Tue, 25 Nov 2014 09:01:17 -0700 From: Peter Saint-Andre - &yet User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Alan DeKok References: <54660EE5.50503@deployingradius.com> <5473EF2A.90808@andyet.net> <5474A631.7060506@deployingradius.com> In-Reply-To: <5474A631.7060506@deployingradius.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/radext/9Uln7i3yXrqvNXC00D9XttbWvp4 Cc: "radext@ietf.org" , precis@ietf.org Subject: Re: [radext] [precis] saslprepbis and NAI X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Nov 2014 16:02:43 -0000 On 11/25/14, 8:54 AM, Alan DeKok wrote: > Peter Saint-Andre - &yet wrote: >> On 11/14/14, 7:17 AM, Alan DeKok wrote: >>> The RADEXT WG is in the last stages of publishing the updated NAI >>> document: >>> >>> https://tools.ietf.org/html/draft-ietf-radext-nai-10 >>> >>> This defines a standard for "username@realm" handling, where "realm" >>> is a fully qualified hostname. It would be useful to reference that >>> from the saslprepbis document. >> >> What kind of reference do you have in mind? Perhaps a pointer from >> Section 3.4 ("Application-Layer Constructs")? > > Yes. Just another indication that there are applications using the > constructs. OK. I thought of some good text for this in the middle of the night but I neglected to write it down. :( I'll work to add something in the next version. >> I've just reviewed the NAI specification. Although it does directly not >> address issues such as width mapping, case mapping, and Unicode >> normalization (seemingly inheriting its handling of those issues from >> RFC 5335 for the username portion and from IDNA2008 for the realm >> portion), as far as I can see it is compatible with saslprepbis. > > Thanks. RFC 4282 did address many of those issues, and the conclusion > was it's recommendations were wrong. This document addresses the issues > by pointing to other documents. An eminently sensible approach, I think. Peter -- Peter Saint-Andre https://andyet.com/ From nobody Wed Nov 26 08:02:30 2014 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 53A101A0248; Wed, 26 Nov 2014 08:02:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham 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 NCOZeLftXiv3; Wed, 26 Nov 2014 08:02:26 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 0E9A91A0210; Wed, 26 Nov 2014 08:02:26 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.7.4 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20141126160226.19458.96007.idtracker@ietfa.amsl.com> Date: Wed, 26 Nov 2014 08:02:26 -0800 Archived-At: http://mailarchive.ietf.org/arch/msg/radext/JjXAROhIXBXPtq_ZI08UNwkrsbI Cc: radext@ietf.org Subject: [radext] I-D Action: draft-ietf-radext-nai-11.txt X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.15 List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Nov 2014 16:02:27 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the RADIUS EXTensions Working Group of the IETF. Title : The Network Access Identifier Author : Alan DeKok Filename : draft-ietf-radext-nai-11.txt Pages : 26 Date : 2014-11-26 Abstract: In order to provide inter-domain authentication services, it is necessary to have a standardized method that domains can use to identify each other's users. This document defines the syntax for the Network Access Identifier (NAI), the user identity submitted by the client prior to accessing resources. This document is a revised version of RFC 4282, which addresses issues with international character sets, as well as a number of other corrections to the previous document. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-radext-nai/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-radext-nai-11 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-radext-nai-11 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Thu Nov 27 00:21:04 2014 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0E4DB1A036E for ; Thu, 27 Nov 2014 00:21:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.011 X-Spam-Level: X-Spam-Status: No, score=-0.011 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MGTOagETdgPq for ; Thu, 27 Nov 2014 00:21:01 -0800 (PST) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:123a::1:2a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AD7481A0166 for ; Thu, 27 Nov 2014 00:21:01 -0800 (PST) Received: from localhost ([::1]:44964 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1XtuJv-0004p2-Do; Thu, 27 Nov 2014 00:20:59 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "radext issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: jouni.nospam@gmail.com, stefan.winter@restena.lu X-Trac-Project: radext Date: Thu, 27 Nov 2014 08:20:59 -0000 X-URL: http://tools.ietf.org/radext/ X-Trac-Ticket-URL: http://tools.ietf.org/wg/radext/trac/ticket/187#comment:2 Message-ID: <078.dc2b9c9d5d219f1a3492769b1501ddaf@trac.tools.ietf.org> References: <063.ba2b4bddc24d4cb1355d2b261657b2ec@trac.tools.ietf.org> X-Trac-Ticket-ID: 187 In-Reply-To: <063.ba2b4bddc24d4cb1355d2b261657b2ec@trac.tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: jouni.nospam@gmail.com, stefan.winter@restena.lu, radext@ietf.org X-SA-Exim-Mail-From: trac+radext@trac.tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Archived-At: http://mailarchive.ietf.org/arch/msg/radext/Abv_6e9AHZZK5kalZ4lrKXwMtPo Cc: radext@ietf.org Subject: Re: [radext] #187 (dynamic-discovery): Timeouts.. X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.15 Reply-To: radext@ietf.org List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Nov 2014 08:21:03 -0000 #187: Timeouts.. Changes (by jouni.nospam@gmail.com): * status: new => closed * resolution: => fixed Comment: Based on the discussion in the IETF91 RADEXT WG meeting, I am happy with the current text in -12. -- ------------------------------------+------------------------------------- Reporter: jouni.nospam@gmail.com | Owner: jouni.nospam@gmail.com Type: defect | Status: closed Priority: major | Milestone: Component: dynamic-discovery | Version: Severity: - | Resolution: fixed Keywords: | ------------------------------------+------------------------------------- Ticket URL: radext From nobody Thu Nov 27 00:23:07 2014 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 204AF1A0166 for ; Thu, 27 Nov 2014 00:23:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FeeRiAITOLI6 for ; Thu, 27 Nov 2014 00:23:03 -0800 (PST) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:123a::1:2a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E68321A036E for ; Thu, 27 Nov 2014 00:23:03 -0800 (PST) Received: from localhost ([::1]:45070 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1XtuLu-00040w-58; Thu, 27 Nov 2014 00:23:02 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "radext issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: jouni.nospam@gmail.com, stefan.winter@restena.lu X-Trac-Project: radext Date: Thu, 27 Nov 2014 08:23:02 -0000 X-URL: http://tools.ietf.org/radext/ X-Trac-Ticket-URL: http://tools.ietf.org/wg/radext/trac/ticket/189#comment:3 Message-ID: <078.b79611156bdb4bb14758884312a5da3b@trac.tools.ietf.org> References: <063.4785bcc57d94228bd8e3b91295e03e3c@trac.tools.ietf.org> X-Trac-Ticket-ID: 189 In-Reply-To: <063.4785bcc57d94228bd8e3b91295e03e3c@trac.tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: jouni.nospam@gmail.com, stefan.winter@restena.lu, radext@ietf.org X-SA-Exim-Mail-From: trac+radext@trac.tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Archived-At: http://mailarchive.ietf.org/arch/msg/radext/rIC93x_3gKWrtKlCj1Hzb2Q7R68 Cc: radext@ietf.org Subject: Re: [radext] #189 (dynamic-discovery): SRV protocol registry X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.15 Reply-To: radext@ietf.org List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Nov 2014 08:23:05 -0000 #189: SRV protocol registry Changes (by jouni.nospam@gmail.com): * status: new => closed * resolution: => fixed Comment: I am OK with the proposed solution in -12. -- ------------------------------------+------------------------------------- Reporter: jouni.nospam@gmail.com | Owner: jouni.nospam@gmail.com Type: task | Status: closed Priority: minor | Milestone: Component: dynamic-discovery | Version: Severity: - | Resolution: fixed Keywords: | ------------------------------------+------------------------------------- Ticket URL: radext From nobody Thu Nov 27 13:31:39 2014 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B98A21A00D8 for ; Thu, 27 Nov 2014 13:31:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.51 X-Spam-Level: X-Spam-Status: No, score=-14.51 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_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XK4qa149nDnU for ; Thu, 27 Nov 2014 13:31:36 -0800 (PST) Received: from aer-iport-1.cisco.com (aer-iport-1.cisco.com [173.38.203.51]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 53E2F1A0049 for ; Thu, 27 Nov 2014 13:31:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=11227; q=dns/txt; s=iport; t=1417123895; x=1418333495; h=message-id:date:from:mime-version:to:subject; bh=p7aUaySLkzVSP+dEle7HeET9LtDxB8mqUUBYhbYUd/M=; b=JeajdOiOXT7X12fd0shi56j9Gyk6U7K2qcl4NPX+eYnF/FIsVmlWFcCX UpBvP6kfzUshKzbh7MNKVSehfG5GcsCM/EtFl23kF6fAWjsya5F2ZDRJh DFs3Z9eZHo2BCAOhf9uyA8j8EyoctJ1O7TSB/V07MYOvR57dLqynt32n1 c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: At8EAC+Xd1StJssW/2dsb2JhbABbg1fGM4Fuh2sBAQEBAX2FAT0WGAMCAQIBSwEMCAEBiDwN0hgBAQEBBgEBAQEBARyQJIUrBYcCkEqHNYE1P4Magn6HSoM8hAqDfT4wAQEBgQMBBQEZA4EhAQEB X-IronPort-AV: E=Sophos;i="5.07,471,1413244800"; d="scan'208,217";a="252557933" Received: from aer-iport-nat.cisco.com (HELO aer-core-3.cisco.com) ([173.38.203.22]) by aer-iport-1.cisco.com with ESMTP; 27 Nov 2014 21:31:33 +0000 Received: from [10.60.67.84] (ams-bclaise-8913.cisco.com [10.60.67.84]) by aer-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id sARLVWOR001287; Thu, 27 Nov 2014 21:31:32 GMT Message-ID: <54779834.9030205@cisco.com> Date: Thu, 27 Nov 2014 22:31:32 +0100 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.7.0 MIME-Version: 1.0 To: "radext@ietf.org" , draft-ietf-radext-radius-fragmentation@tools.ietf.org Content-Type: multipart/alternative; boundary="------------010400020109050708040403" Archived-At: http://mailarchive.ietf.org/arch/msg/radext/SMRRkNKolWxaSR0l628yqoEzXwI Subject: [radext] AD review: draft-ietf-radext-radius-fragmentation X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.15 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, 27 Nov 2014 21:31:39 -0000 This is a multi-part message in MIME format. --------------010400020109050708040403 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Dear all, Here is the AD review. Note that I initiated a discussion with the IESG on the topic of an experimental doc updating a Standard Track doc. More on this pretty soon (hopefully). 1. Since this is an experimental future RFC, the experiment should be better explained. And if/when the experiment is successful, what's the next step. As an example, http://tools.ietf.org/html/draft-ietf-radext-dtls-13#section-1.3 was appreciated by the IESG. Coming back to this draft, if the experiment is success, the Standard Track version will update RFC 2865? 2. Open question: Does this draft update RFC 6158? The Length field in the RADIUS packet header is defined in[RFC2865] Section 3 . It is noted there that the maximum length of a RADIUS packet is 4096 octets. As a result, attribute designers SHOULD NOT assume that a RADIUS implementation can successfully process RADIUS packets larger than 4096 octets. Or maybe this is taken care of by: No such exchange is possible for accounting or authorization data.[RFC6158] Section 3.1 suggests that exchanging large amounts authorization data is unnecessary in RADIUS. Or, maybe, if this experiment is successful, then the Standard Track version will update RFC 6158? _Editorial:_ - Your first sentence in the introduction speaks about "Authentication Server (AS)", but some other parts of the document speak about "server" Example: In some cases, however, the authorization data sent by the server is large and highly dynamic. In other cases, the NAS needs to send large amounts of authorization data to the server. Btw, RFC 6158 speaks of RADIUS Server, which I believe is the right term. Please be consistent regarding terminology: server, AS, RADIUS server Same remark for client, RADIUS client. - OLD [RFC6158] recommends three approaches for the transmission of large amount of data within RADIUS. However, they are not applicable to the problem statement of this document for the following reasons: NEW: [RFC6158] section 3.1 recommends three approaches for the transmission of large amount of data within RADIUS. However, they are not applicable to the problem statement of this document for the following reasons: - OLD o The first approach does not talk about large ... o The second approach is not usable either, ... o PMTU discovery does not solve the problem, as it does not allow to send data larger than the minimum of (PMTU or 4096) octets. NEW: o The first approach (Utilization of a sequence of packets) does not talk about large ... o The second approach (Utilization of names rather than values) is not usable either, ... o PMTU discovery does not solve the problem, as it does not allow to send data larger than the minimum of (PMTU or 4096) octets. - Similarly, there is no need to fragment CoA packets. A reference, or at least expanding the acronym would help - This limit is the minimum of 4096 octets, and the current PMTU. I guess you want to say This limit is the minimum of 4096 octets and the current PMTU. - It is strongly RECOMMENDED that servers include a State attribute So strongly RECOMMENDED is between RECOMMENDED and MUST? :-) Let's not invent new RFC 2119 semantics. NEW: It is RECOMMENDED that servers include a State attribute - Section 4.2 OLD: Compliant clients receiving this packet will see the Frag-Status attribute, wand suspend all authorization and authentication handling until all of the chunks have been received. NEW: Compliant clients receiving this packet will see the Frag-Status attribute,_and_suspend all authorization and authentication handling until all of the chunks have been received. Regarding this sentence, we are in the "post-authorization section". So shouldn't be: NEW: Compliant clients receiving this packet will see the Frag-Status attribute,_and_suspend all authorization handling until all of the chunks have been received. - Section 11.2 The authors acknowledge that this specification violates the "MUST" requirement of[RFC2865] Section 4.1 . Be specific on which MUST requirements in [RFC2865] Section 4.1 . you refer to While you revise the document, you might want to take care of http://tools.ietf.org/idnits?url=https://tools.ietf.org/id/draft-ietf-radext-radius-fragmentation-08.txt Regards, Benoit --------------010400020109050708040403 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Dear all,

Here is the AD review.
Note that I initiated a discussion with the IESG on the topic of an experimental doc updating a Standard Track doc. More on this pretty soon (hopefully).

 

1.
Since this is an experimental future RFC, the experiment should be better explained. And if/when the experiment is successful, what's the next step.
As an example, http://tools.ietf.org/html/draft-ietf-radext-dtls-13#section-1.3 was appreciated by the IESG.
Coming back to this draft, if the experiment is success, the Standard Track version will update RFC 2865?

2.
Open question: Does this draft update RFC 6158?
   The Length field in the RADIUS packet header is defined in [RFC2865]
   Section 3.  It is noted there that the maximum length of a RADIUS
   packet is 4096 octets.  As a result, attribute designers SHOULD NOT
   assume that a RADIUS implementation can successfully process RADIUS
   packets larger than 4096 octets.
Or maybe this is taken care of by:
   No such
   exchange is possible for accounting or authorization data.  [RFC6158]
   Section 3.1 suggests that exchanging large amounts authorization data
   is unnecessary in RADIUS.
Or, maybe, if this experiment is successful, then the Standard Track version will update RFC 6158?


Editorial:
-
Your first sentence in the introduction speaks about "Authentication Server (AS)", but some other parts of the document speak about "server"
Example:
   In some cases, however, the
   authorization data sent by the server is large and highly dynamic.
   In other cases, the NAS needs to send large amounts of authorization
   data to the server.
Btw, RFC 6158 speaks of RADIUS Server, which I believe is the right term.
Please be consistent regarding terminology: server, AS, RADIUS server
Same remark for client, RADIUS client.

- 
OLD
 [RFC6158] recommends three approaches for the transmission of large
   amount of data within RADIUS.  However, they are not applicable to
   the problem statement of this document for the following reasons:

NEW:
 [RFC6158] section 3.1 recommends three approaches for the transmission of large
   amount of data within RADIUS.  However, they are not applicable to
   the problem statement of this document for the following reasons:

-
OLD
   o  The first approach does not talk about large ...

   o  The second approach is not usable either, ...

   o  PMTU discovery does not solve the problem, as it does not allow to
      send data larger than the minimum of (PMTU or 4096) octets.

NEW:
   o  The first approach (Utilization of a sequence of packets) does not talk about large ...

   o  The second approach (Utilization of names rather than values) is not usable either, ...

   o  PMTU discovery does not solve the problem, as it does not allow to
      send data larger than the minimum of (PMTU or 4096) octets.

- 
Similarly, there is no need to fragment CoA packets. 

A reference, or at least expanding the acronym would help

-
This limit is the minimum of 4096 octets, and the current PMTU.
I guess you want to say
This limit is the minimum of 4096 octets and the current PMTU.

- 
It is strongly RECOMMENDED that servers include a State attribute

So strongly RECOMMENDED is between RECOMMENDED and MUST? :-)
Let's not invent new RFC 2119 semantics.
NEW: It is RECOMMENDED that servers include a State attribute

- Section 4.2
OLD: Compliant clients receiving this packet will see the Frag-Status
   attribute, wand suspend all authorization and authentication handling
   until all of the chunks have been received. 

NEW: Compliant clients receiving this packet will see the Frag-Status
   attribute, and suspend all authorization and authentication handling
   until all of the chunks have been received.  

Regarding this sentence, we are in the "post-authorization section".
So shouldn't be: 

NEW: Compliant clients receiving this packet will see the Frag-Status
   attribute, and suspend all authorization handling
   until all of the chunks have been received. 

- Section 11.2

 The authors acknowledge that this specification violates the "MUST"
   requirement of [RFC2865] Section 4.1.
Be specific on which MUST requirements in [RFC2865] Section 4.1. you refer to

While you revise the document, you might want to take care of http://tools.ietf.org/idnits?url=https://tools.ietf.org/id/draft-ietf-radext-radius-fragmentation-08.txt

Regards, Benoit
--------------010400020109050708040403-- From nobody Fri Nov 28 02:15:00 2014 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0B8671A1AA3; Fri, 28 Nov 2014 02:14:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P-zrPKLnZElq; Fri, 28 Nov 2014 02:14:57 -0800 (PST) Received: from aer-iport-1.cisco.com (aer-iport-1.cisco.com [173.38.203.51]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 381BC1A1A99; Fri, 28 Nov 2014 02:14:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1191; q=dns/txt; s=iport; t=1417169698; x=1418379298; h=message-id:date:from:mime-version:to:subject:references: in-reply-to:content-transfer-encoding; bh=qCdnVabsGsYOzuNvcS3WJ8E11Pe9QielwcmjQ+WF0Dg=; b=Y7bc8aXaa5v9HhzbsJsCZHPR3qTuMejA8YQ5RfspKXTlmuXYdLIDH/eh A6NoWF3woi5lo5tRMqUeq5z2g9kHpGEEeqkWlxmS3C/ZFnU5fUJ+MipZ0 ESIHrg4gbdbGuSerW9nfo4X8MlwASWdkGJt41JMpIx8FLPnlDICXWwbgU A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqoEAANKeFStJssW/2dsb2JhbABbg1fIDQqFeFUCgSIBAQEBAX2EAwEBBAEBATU2BgQRCyEWDwkDAgECARUwBgEMBgIBAYg8DdIXAQEBAQEBAQEBAQEBAQEBAQEBFgSRAoRNAQSXTIc1gTWDWYJ+jxCDfT4wgkoBAQE X-IronPort-AV: E=Sophos;i="5.07,475,1413244800"; d="scan'208";a="253278822" Received: from aer-iport-nat.cisco.com (HELO aer-core-4.cisco.com) ([173.38.203.22]) by aer-iport-1.cisco.com with ESMTP; 28 Nov 2014 10:14:56 +0000 Received: from [10.60.67.84] (ams-bclaise-8913.cisco.com [10.60.67.84]) by aer-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id sASAEt0B005870; Fri, 28 Nov 2014 10:14:55 GMT Message-ID: <54784B1F.5090909@cisco.com> Date: Fri, 28 Nov 2014 11:14:55 +0100 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.7.0 MIME-Version: 1.0 To: Alan DeKok , precis@ietf.org, "radext@ietf.org" References: <54660EE5.50503@deployingradius.com> In-Reply-To: <54660EE5.50503@deployingradius.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/radext/p0lG6ZBrbIEmpxI7I5JIRGzNFPk Subject: Re: [radext] saslprepbis and NAI X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.15 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, 28 Nov 2014 10:14:59 -0000 Dear all, Please note that draft-ietf-radext-nai-11 is the IESG telechat next Thursday. Regards, Benoit > The RADEXT WG is in the last stages of publishing the updated NAI > document: > > https://tools.ietf.org/html/draft-ietf-radext-nai-10 > > This defines a standard for "username@realm" handling, where "realm" > is a fully qualified hostname. It would be useful to reference that > from the saslprepbis document. > > The NAI is used for EAP (802.1X), AAA, 3GPP, and international roaming. > > The NAI is a subset of the "userpart" defined in Section 3.1 of the > saslprepbis document, in that it *requires* "username@realm", and the > "realm" part is a fully qualified domain name. > > Hmm... I've just noticed that the ABNF in the NAI allows for IP > addresses in the "realm" portion. That's not the intent. I'll have to > go fix that. > > I'd like to be sure that the NAI document is compatible with (or at > least not in violent disagreement with) the precis work. > > Alan DeKok. > > _______________________________________________ > radext mailing list > radext@ietf.org > https://www.ietf.org/mailman/listinfo/radext > From nobody Fri Nov 28 02:19:56 2014 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B9541A1B0D for ; Fri, 28 Nov 2014 02:19:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.51 X-Spam-Level: X-Spam-Status: No, score=-14.51 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_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Wwgfr6w8R-yI for ; Fri, 28 Nov 2014 02:19:52 -0800 (PST) Received: from aer-iport-3.cisco.com (aer-iport-3.cisco.com [173.38.203.53]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9256A1A1B0B for ; Fri, 28 Nov 2014 02:19:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6273; q=dns/txt; s=iport; t=1417169991; x=1418379591; h=message-id:date:from:mime-version:to:subject:references: in-reply-to; bh=egq23Erdw+EvHp1diJrHvQCy6ThRSgDVKcLXgaseFss=; b=lTIjFEYTfAqb32o8KLfmUt2X54ML1lyc73dtrme9hSS0HJNqVs1gxAcS a22KABAIJi9nzEJqbAgq6VBAQ3O4Fn9yBkwqH9W0L9XW2sRztxo8PPt1K BV413a/78GAWHKuB6p80dYmylZVQ7Fr+N47Hs8hjQnsimTcL3of37UZxr Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqkEADBLeFStJssW/2dsb2JhbABbg1fIGYV2VQKBIgEBAQEBfYQCAQEBAwF4BgcEHAMBAgoWDwkDAgECATsCCAYBDAYCAQEFiC4JDdIcAQEBAQEBAQEBAQEBAQEBAQEBAQEYkBkQAgE+GAaERwWXTIc1gTU/hhiHSoM8hAqCN4FGPjABgkkBAQE X-IronPort-AV: E=Sophos;i="5.07,475,1413244800"; d="scan'208,217";a="248552263" Received: from aer-iport-nat.cisco.com (HELO aer-core-2.cisco.com) ([173.38.203.22]) by aer-iport-3.cisco.com with ESMTP; 28 Nov 2014 10:19:49 +0000 Received: from [10.60.67.84] (ams-bclaise-8913.cisco.com [10.60.67.84]) by aer-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id sASAJn50023635; Fri, 28 Nov 2014 10:19:49 GMT Message-ID: <54784C45.4010406@cisco.com> Date: Fri, 28 Nov 2014 11:19:49 +0100 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.7.0 MIME-Version: 1.0 To: "radext@ietf.org" , draft-ietf-radext-radius-fragmentation@tools.ietf.org, "'Barry Leiba'" References: In-Reply-To: X-Forwarded-Message-Id: Content-Type: multipart/alternative; boundary="------------030104060109080804050109" Archived-At: http://mailarchive.ietf.org/arch/msg/radext/Ul2su-hyHrrM8xdxDtv6ekxj-bo Subject: [radext] Fwd: Re: Experimental doc updating a Standard Track doc (draft-ietf-radext-radius-fragmentation) X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.15 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, 28 Nov 2014 10:19:54 -0000 This is a multi-part message in MIME format. --------------030104060109080804050109 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Dear all, Here is Barry's answer, supporting your "update". One more good suggestion at the end of his email. Regards, Benoit -------- Original Message -------- Subject: Re: Experimental doc updating a Standard Track doc Date: Thu, 27 Nov 2014 10:32:43 -0500 From: Barry Leiba To: Benoit Claise CC: IESG IESG , "radext-chairs@tools.ietf.org" > I'm currently busy with the AD review of > draft-ietf-radext-radius-fragmentation-08 > As mentioned in the writeup, this experimental document update a standard > track document > See the reasoning at > http://tools.ietf.org/html/draft-ietf-radext-radius-fragmentation-08#section-11.1 > > See also the RADEXT archive. > http://www.ietf.org/mail-archive/web/radext/current/msg08854.html > I pushed back initially, but the WG has some valid arguments. > > What do you think? > Have you faced this issue already? I think it absolutely makes sense (in the right circumstances) for an Experimental spec to "update" a Standards Track document: it's reasonable to consider something as an experimental update. In those cases, I think it's very important for the Experimental document to be very clear about what the update is, and that it's experimental. I think the same is true for Informational: Standards Track documents contain material that is informational, and it's reasonable for an Informational document to update that. We just need to use our judgment about what's right in a particular situation. For this "T" flag, I think it makes sense. I might add to Section 11.1 something about what happens to the "T" flag if this experiment flops and goes away. If this is reserving the "T" flag forevermore, regardless of whether the protocol defined herein sticks around, it would help for the document to be clear about that, so no one wonders someday, when this document becomes Historic, whether the "T" flag can be reused. Barry . --------------030104060109080804050109 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Dear all,

Here is Barry's answer, supporting your "update".
One more good suggestion at the end of his email.

Regards, Benoit


-------- Original Message --------
Subject: Re: Experimental doc updating a Standard Track doc
Date: Thu, 27 Nov 2014 10:32:43 -0500
From: Barry Leiba <barryleiba@computer.org>
To: Benoit Claise <bclaise@cisco.com>
CC: IESG IESG <iesg@ietf.org>, "radext-chairs@tools.ietf.org" <radext-chairs@tools.ietf.org> 


> I'm currently busy with the AD review of
> draft-ietf-radext-radius-fragmentation-08
> As mentioned in the writeup, this experimental document update a standard
> track document
> See the reasoning at
> http://tools.ietf.org/html/draft-ietf-radext-radius-fragmentation-08#section-11.1
>
> See also the RADEXT archive.
> http://www.ietf.org/mail-archive/web/radext/current/msg08854.html
> I pushed back initially, but the WG has some valid arguments.
>
> What do you think?
> Have you faced this issue already?

I think it absolutely makes sense (in the right circumstances) for an
Experimental spec to "update" a Standards Track document: it's
reasonable to consider something as an experimental update.  In those
cases, I think it's very important for the Experimental document to be
very clear about what the update is, and that it's experimental.

I think the same is true for Informational: Standards Track documents
contain material that is informational, and it's reasonable for an
Informational document to update that.

We just need to use our judgment about what's right in a particular
situation.  For this "T" flag, I think it makes sense.  I might add to
Section 11.1 something about what happens to the "T" flag if this
experiment flops and goes away.  If this is reserving the "T" flag
forevermore, regardless of whether the protocol defined herein sticks
around, it would help for the document to be clear about that, so no
one wonders someday, when this document becomes Historic, whether the
"T" flag can be reused.

Barry
.


--------------030104060109080804050109-- From nobody Sun Nov 30 23:10:39 2014 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B69E31A1A14 for ; Sun, 30 Nov 2014 23:10:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.51 X-Spam-Level: X-Spam-Status: No, score=-14.51 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_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nbdNa546gKne for ; Sun, 30 Nov 2014 23:10:29 -0800 (PST) Received: from alln-iport-1.cisco.com (alln-iport-1.cisco.com [173.37.142.88]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D607C1A03A2 for ; Sun, 30 Nov 2014 23:10:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1812; q=dns/txt; s=iport; t=1417417829; x=1418627429; h=from:to:subject:date:message-id:mime-version; bh=ZS7861vfDrsSB5yE4he0JkFwi1Zn4QI2R0c+Bq+qOmI=; b=jGZI6G18xLu756cx/vmaGRbqEi+1AbNJa1vBr1rzpameNDcDuKwCrqLD x3zj/WXamRhLEwysAiLR7dS3Uk19bPvTD7JbnVjoZHDlMzl3qMeuc377S ndpSVHkJaY5Fv1s+uKvtrrUjAwkzVpBJEmzyaX7+2xtWpFxoiMhrGvwgB I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhgFANgTfFStJV2Y/2dsb2JhbABbgkJEgS3EVYoJFgEBAQEBfYN5EIELAQsBdCcEiFOtAKUNAQoBAQEelUoFkQWLQpVDg3uCNYEBAQEB X-IronPort-AV: E=Sophos;i="5.07,491,1413244800"; d="scan'208,217";a="101359020" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by alln-iport-1.cisco.com with ESMTP; 01 Dec 2014 07:10:27 +0000 Received: from xhc-aln-x04.cisco.com (xhc-aln-x04.cisco.com [173.36.12.78]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id sB17ARWg026829 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Mon, 1 Dec 2014 07:10:27 GMT Received: from xmb-rcd-x14.cisco.com ([169.254.4.121]) by xhc-aln-x04.cisco.com ([173.36.12.78]) with mapi id 14.03.0195.001; Mon, 1 Dec 2014 01:10:27 -0600 From: "Satyanarayana Danda (sdanda)" To: "radext@ietf.org" Thread-Topic: Few gaps for IP Sessions from Radius Protocol Side Thread-Index: AQHQDTXhuGtO6TgFjUCucVlS5Gu4dw== Date: Mon, 1 Dec 2014 07:10:26 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.4.140807 x-originating-ip: [10.142.98.60] Content-Type: multipart/alternative; boundary="_000_D0A2123920754sdandaciscocom_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/radext/DdkUUpgkSvrKTTq9ngBhftH-2Uo Subject: [radext] Few gaps for IP Sessions from Radius Protocol Side X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.15 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, 01 Dec 2014 07:10:36 -0000 --_000_D0A2123920754sdandaciscocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Folks, With the IPoE evaluation, we seem to have a few gaps in terms of supported = values for a few IETF AVPs. The following are a few such instances 1. Framed-Protocol (7) has no values to specify for IPoE based sessions = (e.g either IPV4 or IPV6) 2. Acct-Terminate-Cause (49) has no pluses of the IP session disconnecti= on in a few cases (e.g Roaming scenarios) Would you like to know if any though process on this or any previous work d= one in this WG. Thanks Satya --_000_D0A2123920754sdandaciscocom_ Content-Type: text/html; charset="us-ascii" Content-ID: <8A4A5ACD8315164CA88E8993D7104A81@emea.cisco.com> Content-Transfer-Encoding: quoted-printable
Hi Folks,

With the IPoE evaluation, we seem to have a few gaps in terms of suppo= rted values for a few IETF AVPs.
The following are a few such instances
  1. Framed-Protocol (7) has no values to specify for IPoE based sessions (e= .g either IPV4 or IPV6)
  2. Acct-Terminate-Cause (49) has no pluses of = the IP session disconnection in a few cases (e.g Roaming scenarios)
    3. Would you like to know if any though process on this or any previous w= ork done in this WG.

    Thanks
    Satya

    --_000_D0A2123920754sdandaciscocom_--