From jsalowey@cisco.com Tue Jul 3 10:21:56 2012 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 382E811E8175 for ; Tue, 3 Jul 2012 10:21:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rf74qwLxc7Ti for ; Tue, 3 Jul 2012 10:21:55 -0700 (PDT) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) by ietfa.amsl.com (Postfix) with ESMTP id D6A4611E80BB for ; Tue, 3 Jul 2012 10:21:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=jsalowey@cisco.com; l=725; q=dns/txt; s=iport; t=1341336123; x=1342545723; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=mPxaw3hIZZ5cO8s/MxYh3kclqUBFrmDappUG/KlMdow=; b=SNfd9cduN6siwpFW9IkQ2H7LoT2i29432fwTGLDszc4gLUDPguX0Njuh DLoiqKHNsc2MWeyk1Cx7HWpKakE++AJS3m+86HfGDj3MjKrFJp76Iaqt9 LphMrirmD0ZuhTX3Amn1XQl8Z/lQqskyAYFqJlUFAHI0LAaI/BZ36abI+ w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAC8p80+tJXG+/2dsb2JhbABEtweBB4IZAQEEEgFmEAIBCEYyJQIEDieHaZoYoEqLNxSFJmADiBeNHo4dgWaCX4FW X-IronPort-AV: E=Sophos;i="4.77,516,1336348800"; d="scan'208";a="98431108" Received: from rcdn-core2-3.cisco.com ([173.37.113.190]) by rcdn-iport-5.cisco.com with ESMTP; 03 Jul 2012 17:21:59 +0000 Received: from xhc-rcd-x14.cisco.com (xhc-rcd-x14.cisco.com [173.37.183.88]) by rcdn-core2-3.cisco.com (8.14.5/8.14.5) with ESMTP id q63HLxGV023273 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 3 Jul 2012 17:21:59 GMT Received: from xmb-rcd-x09.cisco.com ([169.254.9.234]) by xhc-rcd-x14.cisco.com ([173.37.183.88]) with mapi id 14.02.0298.004; Tue, 3 Jul 2012 12:21:57 -0500 From: "Joseph Salowey (jsalowey)" To: Bernard Aboba Thread-Topic: [radext] Proposed Resolution for Issue #109 Thread-Index: AQHNU+v9o0KC6JGcRkqPQUv9Nf8LopcYLK8A Date: Tue, 3 Jul 2012 17:21:56 +0000 Message-ID: <4730F52D-C88B-4B17-A635-BD017B02F799@cisco.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.33.249.195] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19014.005 x-tm-as-result: No--35.582200-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="iso-8859-1" Content-ID: <12F907D65BDF1F43AC5D61C8D05E65B2@cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "" Subject: Re: [radext] Proposed Resolution for Issue #109 X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Jul 2012 17:21:56 -0000 Hi Bernard, I haven't found anywhere where the Acct-Termiate-Cause is allowed in the Ac= cess-Reject. If we want to use this attribute in an Access-Reject then I= think we would have to explicitly allow that in this draft. Do you see a= ny problem with including that? =20 Also, most of the existing values are indicating conditions present on the = NAS whereas the presence of the attribute in the reject is indicating the r= eason for the reject policy decision from the AAA. Perhaps it would be bet= ter to use a separate attribute. The use of terminate-cause in 5196 is pr= etty limited and specific. =20 Thanks, Joe On Jun 26, 2012, at 3:35 PM, Bernard Aboba wrote: > From radext-bounces@ietf.org Tue Jul 3 10:21:59 2012 Return-Path: X-Original-To: radext-archive-IeZ9sae2@lists.ietf.org Delivered-To: ietfarch-radext-archive-IeZ9sae2@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1470011E80BB; Tue, 3 Jul 2012 10:21:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1341336119; bh=ATavNr/xHs436zZvjoit2wRDx4XunCwwGtmWB76JiaM=; h=From:To:Date:Message-ID:References:In-Reply-To:Content-ID: MIME-Version:Cc:Subject:List-Id:List-Unsubscribe:List-Archive: List-Post:List-Help:List-Subscribe:Content-Type: Content-Transfer-Encoding:Sender; b=ihAaBJZsaBRgHB2swRU2N1TXYEC6i3Khcj/GXqDLPb3gBqOJhtJ9TR15h2lOPafwv zvqORx7yHKCxbEjCjXLXPOkzE+uDWQCVsiyOX1N+TChDa3yuCaakDQ1PijX9H8CebV /Zu9xBnIMadmX5f/qLbdDZbniVYNvz8yQTZhGZzE= 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 382E811E8175 for ; Tue, 3 Jul 2012 10:21:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rf74qwLxc7Ti for ; Tue, 3 Jul 2012 10:21:55 -0700 (PDT) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) by ietfa.amsl.com (Postfix) with ESMTP id D6A4611E80BB for ; Tue, 3 Jul 2012 10:21:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=jsalowey@cisco.com; l=725; q=dns/txt; s=iport; t=1341336123; x=1342545723; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=mPxaw3hIZZ5cO8s/MxYh3kclqUBFrmDappUG/KlMdow=; b=SNfd9cduN6siwpFW9IkQ2H7LoT2i29432fwTGLDszc4gLUDPguX0Njuh DLoiqKHNsc2MWeyk1Cx7HWpKakE++AJS3m+86HfGDj3MjKrFJp76Iaqt9 LphMrirmD0ZuhTX3Amn1XQl8Z/lQqskyAYFqJlUFAHI0LAaI/BZ36abI+ w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAC8p80+tJXG+/2dsb2JhbABEtweBB4IZAQEEEgFmEAIBCEYyJQIEDieHaZoYoEqLNxSFJmADiBeNHo4dgWaCX4FW X-IronPort-AV: E=Sophos;i="4.77,516,1336348800"; d="scan'208";a="98431108" Received: from rcdn-core2-3.cisco.com ([173.37.113.190]) by rcdn-iport-5.cisco.com with ESMTP; 03 Jul 2012 17:21:59 +0000 Received: from xhc-rcd-x14.cisco.com (xhc-rcd-x14.cisco.com [173.37.183.88]) by rcdn-core2-3.cisco.com (8.14.5/8.14.5) with ESMTP id q63HLxGV023273 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 3 Jul 2012 17:21:59 GMT Received: from xmb-rcd-x09.cisco.com ([169.254.9.234]) by xhc-rcd-x14.cisco.com ([173.37.183.88]) with mapi id 14.02.0298.004; Tue, 3 Jul 2012 12:21:57 -0500 From: "Joseph Salowey (jsalowey)" To: Bernard Aboba Thread-Topic: [radext] Proposed Resolution for Issue #109 Thread-Index: AQHNU+v9o0KC6JGcRkqPQUv9Nf8LopcYLK8A Date: Tue, 3 Jul 2012 17:21:56 +0000 Message-ID: <4730F52D-C88B-4B17-A635-BD017B02F799@cisco.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.33.249.195] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19014.005 x-tm-as-result: No--35.582200-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-ID: <12F907D65BDF1F43AC5D61C8D05E65B2@cisco.com> MIME-Version: 1.0 Cc: "" Subject: Re: [radext] Proposed Resolution for Issue #109 X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: radext-bounces@ietf.org Errors-To: radext-bounces@ietf.org Hi Bernard, I haven't found anywhere where the Acct-Termiate-Cause is allowed in the Access-Reject. If we want to use this attribute in an Access-Reject then I think we would have to explicitly allow that in this draft. Do you see any problem with including that? Also, most of the existing values are indicating conditions present on the NAS whereas the presence of the attribute in the reject is indicating the reason for the reject policy decision from the AAA. Perhaps it would be better to use a separate attribute. The use of terminate-cause in 5196 is pretty limited and specific. Thanks, Joe On Jun 26, 2012, at 3:35 PM, Bernard Aboba wrote: > _______________________________________________ radext mailing list radext@ietf.org https://www.ietf.org/mailman/listinfo/radext From radext-bounces@ietf.org Wed Jul 4 09:29:06 2012 Return-Path: X-Original-To: radext-archive-IeZ9sae2@lists.ietf.org Delivered-To: ietfarch-radext-archive-IeZ9sae2@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7A87F21F8712; Wed, 4 Jul 2012 09:29:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1341419346; bh=9D3Ht9puB7DAkeF4Jo0nYxmx7+nRjRyA2lQ8+NDjeZ8=; h=Message-ID:From:To:Date:In-Reply-To:References:MIME-Version:Cc: Subject:List-Id:List-Unsubscribe:List-Archive:List-Post:List-Help: List-Subscribe:Content-Type:Sender; b=UN41IUNYwDApkvygyweMhHQKwho00IRGhbzbE+eyEkXtLD+JTnHVYHb1Da/idDuc/ msIEK5VJF3LPu3etPrkJQlxm8YEZf7V9MR48YCBxkx3CXsF690AVcOQ/nDtB73TxJ7 bz/Lht9kRH/byRINhgzheVND8vnm2sdl/bzFAE+U= 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 B5E8121F8712 for ; Wed, 4 Jul 2012 09:29:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.44 X-Spam-Level: X-Spam-Status: No, score=-102.44 tagged_above=-999 required=5 tests=[AWL=0.158, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2EmyYfnN5NXZ for ; Wed, 4 Jul 2012 09:29:04 -0700 (PDT) Received: from blu0-omc4-s6.blu0.hotmail.com (blu0-omc4-s6.blu0.hotmail.com [65.55.111.145]) by ietfa.amsl.com (Postfix) with ESMTP id AC68F21F8710 for ; Wed, 4 Jul 2012 09:29:04 -0700 (PDT) Received: from BLU169-W138 ([65.55.111.137]) by blu0-omc4-s6.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 4 Jul 2012 09:29:13 -0700 Message-ID: X-Originating-IP: [24.16.96.166] From: Bernard Aboba To: "Joseph Salowey (jsalowey)" Date: Wed, 4 Jul 2012 09:29:13 -0700 Importance: Normal In-Reply-To: <4730F52D-C88B-4B17-A635-BD017B02F799@cisco.com> References: , <4730F52D-C88B-4B17-A635-BD017B02F799@cisco.com> MIME-Version: 1.0 X-OriginalArrivalTime: 04 Jul 2012 16:29:13.0875 (UTC) FILETIME=[2611D630:01CD5A02] Cc: radext@ietf.org Subject: Re: [radext] Proposed Resolution for Issue #109 X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============7046153151122761757==" Sender: radext-bounces@ietf.org Errors-To: radext-bounces@ietf.org --===============7046153151122761757== Content-Type: multipart/alternative; boundary="_51359712-0f57-42f4-8a12-6f1b0efc9b70_" --_51359712-0f57-42f4-8a12-6f1b0efc9b70_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Existing values of Acct-Terminate-Cause relate to conditions on the host or= NAS that cause a session to be terminated=3B the attribute is used to info= rm the Accounting Server of what happened.=20 This sounded similar to the first part of the description in the text:=20 The Reason code field of a Disassociation or Deauthentication frame (see clause 8.3.3.4 and 8.3.3.12 respectively in [IEEE-802.11]) is transmitted by an Access Point to the station=20 If a Disassociation or Deauthentication frame is sent by the AP to the stat= ion that causes a session to be terminated=2C then sending an Acct-Terminat= e-Cause in an Accounting-Request could make sense.=20 However=2C there is also the rest of the sentence:=20 "when authorization is denied=2C where authentication may have been success= ful."=20 Some questions come to mind: 1. Is it the NAS which is initiating the termination (e.g.=2C reporting th= e Reason-Code to the RADIUS server ) or is it the RADIUS server (e.g.=2C te= lling the AP to send a particular Reason-Code to the station)?=20 2. Is the termination occurring after a session has been started (Disconne= ct-Request) or does it represent a denial of access (Access-Reject)?=20 One of the reason codes (code 27) seems to imply that the session was termi= nated by the SP after it was started (e.g.=2C Access-Accept was sent=2C the= n a Disconnect-Request). =20 In that situation=2C a reason for the disconnect might be included in the D= isconnect-Request=2C then echoed in an Accounting-Request. =20 Rather than using another attribute in the Accounting-Request to indicate t= he reason for the termination=2C it may make sense to use Acct-Terminate-Ca= use=3B however=2C if that is done then Acct-Terminate-Cause would also be = needed in the Disconnect-Request so the DAS would know what to include (e.g= .=2C why the session was terminated).=20 Other codes (such as 28=2C 29 or 30) seem to imply that the session never g= ot started=3B the implication is that an Access-Reject was sent.=20 In that situation=2C is the desire to cause the AP to send a particular Rea= son-Code to the Station? If a session was not started=2C then an Accounti= ng-Request would not be sent.=20 In that scenario=2C the use of Acct-Terminate-Cause may make less sense=2C = and instead it may make sense to include an Attribute expressing the Reason= -Code.=20 The "when authentication may have been successful" raises the question of w= hether an EAP-Success is being transmitted within an EAP-Message attribute = contained within an Access-Reject.=20 RFC 3579 Section 2.6.3 says: Access-Accept packets SHOULD have only one EAP-Message attribute in them=2C containing EAP Success=3B similarly=2C Access-Reject packets SHO= ULD have only one EAP-Message attribute in them=2C containing EAP Failure. Where the encapsulated EAP packet does not match the result implied by the RADIUS Packet Type=2C the combination is likely to cause confusion=2C because the NAS and peer will arrive at different conclusions as to the outcome of the authentication. > From: jsalowey@cisco.com > To: bernard_aboba@hotmail.com > Date: Tue=2C 3 Jul 2012 17:21:56 +0000 > CC: radext@ietf.org > Subject: Re: [radext] Proposed Resolution for Issue #109 >=20 > Hi Bernard=2C >=20 > I haven't found anywhere where the Acct-Terminate-Cause is allowed in the= Access-Reject. If we want to use this attribute in an Access-Reject the= n I think we would have to explicitly allow that in this draft. Do you se= e any problem with including that? =20 >=20 > Also=2C most of the existing values are indicating conditions present on = the NAS whereas the presence of the attribute in the reject is indicating t= he reason for the reject policy decision from the AAA. Perhaps it would be= better to use a separate attribute. The use of terminate-cause in 5196 i= s pretty limited and specific. =20 >=20 > Thanks=2C >=20 > Joe >=20 >=20 > On Jun 26=2C 2012=2C at 3:35 PM=2C Bernard Aboba wrote: >=20 > > >=20 > _______________________________________________ > radext mailing list > radext@ietf.org > https://www.ietf.org/mailman/listinfo/radext = --_51359712-0f57-42f4-8a12-6f1b0efc9b70_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Existing values of Acct-Terminate-Cause relate to conditions on the host or= NAS that cause a session to be terminated=3B the attribute is used to info= rm the Accounting Server of what happened.

This sounded similar to = the first part of the description in the text: 
 =
  The Reason code field of a Disassociation or Deauthentication frame
   (see clause 8.3.3.4 and 8.3.3.12 respectively in [IEEE-802.1=
1]) is
   transmitted by an Access Point to the station

If a Disassociat= ion or Deauthentication frame is sent by the AP to the station that causes = a session to be terminated=2C then sending an Acct-Terminate-Cause in an Ac= counting-Request could make sense.

However=2C there is also the res= t of the sentence:

"when authorization is denied=2C where authentic= ation may have been successful."

Some questions come to mind:
1. =3B Is it the NAS which is initiating the termination (e.g.=2C rep= orting the Reason-Code to the RADIUS server ) or is it the RADIUS server (e= .g.=2C telling the AP to send a particular Reason-Code to the station)? 2. =3B Is the termination occurring after a session has been started (= Disconnect-Request) or does it represent a denial of access (Access-Reject)= ?

One of the reason codes (code 27) seems to imply that the session= was terminated by the SP after it was started (e.g.=2C Access-Accept was s= ent=2C then a Disconnect-Request). =3B

In that situation=2C a r= eason for the disconnect might be included in the Disconnect-Request=2C the= n echoed in an Accounting-Request. =3B

Rather than using anothe= r attribute in the Accounting-Request to indicate the reason for the termin= ation=2C it may make sense to use Acct-Terminate-Cause=3B =3B however= =2C if that is done then Acct-Terminate-Cause would also be needed in the D= isconnect-Request so the DAS would know what to include (e.g.=2C why the se= ssion was terminated).

Other codes (such as 28=2C 29 or 30) seem to= imply that the session never got started=3B the implication is that an Acc= ess-Reject was sent.

In that situation=2C is the desire to cause th= e AP to send a particular Reason-Code to the Station?  =3B If a session= was not started=2C then an Accounting-Request would not be sent.

I= n that scenario=2C the use of Acct-Terminate-Cause may make less sense=2C a= nd instead it may make sense to include an Attribute expressing the Reason-= Code.

The "when authentication may have been successful" raises the= question of whether an EAP-Success is being transmitted within an EAP-Mess= age attribute contained within an Access-Reject.

RFC 3579 Section 2= .6.3 says:

   Access-Accept packets SHOULD have only one EAP-Me=
ssage attribute in
   them=2C containing EAP Success=3B similarly=2C Access-Reject packets SHO=
ULD
   have only one EAP-Message attribute in them=2C containing EAP Failure.

   Where the encapsulated EAP packet does not match the result implied
   by the RADIUS Packet Type=2C the combination is likely to cause
   confusion=2C because the NAS and peer will arrive at different
   conclusions as to the outcome of the authentication.





>=3B= From: jsalowey@cisco.com
>=3B To: bernard_aboba@hotmail.com
>=3B= Date: Tue=2C 3 Jul 2012 17:21:56 +0000
>=3B CC: radext@ietf.org
&g= t=3B Subject: Re: [radext] Proposed Resolution for Issue #109
>=3B >=3B Hi Bernard=2C
>=3B
>=3B I haven't found anywhere where t= he Acct-Terminate-Cause is allowed in the Access-Reject. If we want to u= se this attribute in an Access-Reject then I think we would have to explici= tly allow that in this draft. Do you see any problem with including that?=
>=3B
>=3B Also=2C most of the existing values are indicating = conditions present on the NAS whereas the presence of the attribute in the = reject is indicating the reason for the reject policy decision from the AAA= . Perhaps it would be better to use a separate attribute. The use of ter= minate-cause in 5196 is pretty limited and specific.
>=3B
>=3B= Thanks=2C
>=3B
>=3B Joe
>=3B
>=3B
>=3B On Jun = 26=2C 2012=2C at 3:35 PM=2C Bernard Aboba wrote:
>=3B
>=3B >= =3B <=3BRAD-WLAN.txt>=3B
>=3B
>=3B _________________________= ______________________
>=3B radext mailing list
>=3B radext@ietf.= org
>=3B https://www.ietf.org/mailman/listinfo/radext
=
= --_51359712-0f57-42f4-8a12-6f1b0efc9b70_-- --===============7046153151122761757== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ radext mailing list radext@ietf.org https://www.ietf.org/mailman/listinfo/radext --===============7046153151122761757==-- From bernard_aboba@hotmail.com Wed Jul 4 09:29:05 2012 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 B5E8121F8712 for ; Wed, 4 Jul 2012 09:29:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.44 X-Spam-Level: X-Spam-Status: No, score=-102.44 tagged_above=-999 required=5 tests=[AWL=0.158, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2EmyYfnN5NXZ for ; Wed, 4 Jul 2012 09:29:04 -0700 (PDT) Received: from blu0-omc4-s6.blu0.hotmail.com (blu0-omc4-s6.blu0.hotmail.com [65.55.111.145]) by ietfa.amsl.com (Postfix) with ESMTP id AC68F21F8710 for ; Wed, 4 Jul 2012 09:29:04 -0700 (PDT) Received: from BLU169-W138 ([65.55.111.137]) by blu0-omc4-s6.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 4 Jul 2012 09:29:13 -0700 Message-ID: Content-Type: multipart/alternative; boundary="_51359712-0f57-42f4-8a12-6f1b0efc9b70_" X-Originating-IP: [24.16.96.166] From: Bernard Aboba To: "Joseph Salowey (jsalowey)" Date: Wed, 4 Jul 2012 09:29:13 -0700 Importance: Normal In-Reply-To: <4730F52D-C88B-4B17-A635-BD017B02F799@cisco.com> References: , <4730F52D-C88B-4B17-A635-BD017B02F799@cisco.com> MIME-Version: 1.0 X-OriginalArrivalTime: 04 Jul 2012 16:29:13.0875 (UTC) FILETIME=[2611D630:01CD5A02] Cc: radext@ietf.org Subject: Re: [radext] Proposed Resolution for Issue #109 X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 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 Jul 2012 16:29:05 -0000 --_51359712-0f57-42f4-8a12-6f1b0efc9b70_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Existing values of Acct-Terminate-Cause relate to conditions on the host or= NAS that cause a session to be terminated=3B the attribute is used to info= rm the Accounting Server of what happened.=20 This sounded similar to the first part of the description in the text:=20 The Reason code field of a Disassociation or Deauthentication frame (see clause 8.3.3.4 and 8.3.3.12 respectively in [IEEE-802.11]) is transmitted by an Access Point to the station=20 If a Disassociation or Deauthentication frame is sent by the AP to the stat= ion that causes a session to be terminated=2C then sending an Acct-Terminat= e-Cause in an Accounting-Request could make sense.=20 However=2C there is also the rest of the sentence:=20 "when authorization is denied=2C where authentication may have been success= ful."=20 Some questions come to mind: 1. Is it the NAS which is initiating the termination (e.g.=2C reporting th= e Reason-Code to the RADIUS server ) or is it the RADIUS server (e.g.=2C te= lling the AP to send a particular Reason-Code to the station)?=20 2. Is the termination occurring after a session has been started (Disconne= ct-Request) or does it represent a denial of access (Access-Reject)?=20 One of the reason codes (code 27) seems to imply that the session was termi= nated by the SP after it was started (e.g.=2C Access-Accept was sent=2C the= n a Disconnect-Request). =20 In that situation=2C a reason for the disconnect might be included in the D= isconnect-Request=2C then echoed in an Accounting-Request. =20 Rather than using another attribute in the Accounting-Request to indicate t= he reason for the termination=2C it may make sense to use Acct-Terminate-Ca= use=3B however=2C if that is done then Acct-Terminate-Cause would also be = needed in the Disconnect-Request so the DAS would know what to include (e.g= .=2C why the session was terminated).=20 Other codes (such as 28=2C 29 or 30) seem to imply that the session never g= ot started=3B the implication is that an Access-Reject was sent.=20 In that situation=2C is the desire to cause the AP to send a particular Rea= son-Code to the Station? If a session was not started=2C then an Accounti= ng-Request would not be sent.=20 In that scenario=2C the use of Acct-Terminate-Cause may make less sense=2C = and instead it may make sense to include an Attribute expressing the Reason= -Code.=20 The "when authentication may have been successful" raises the question of w= hether an EAP-Success is being transmitted within an EAP-Message attribute = contained within an Access-Reject.=20 RFC 3579 Section 2.6.3 says: Access-Accept packets SHOULD have only one EAP-Message attribute in them=2C containing EAP Success=3B similarly=2C Access-Reject packets SHO= ULD have only one EAP-Message attribute in them=2C containing EAP Failure. Where the encapsulated EAP packet does not match the result implied by the RADIUS Packet Type=2C the combination is likely to cause confusion=2C because the NAS and peer will arrive at different conclusions as to the outcome of the authentication. > From: jsalowey@cisco.com > To: bernard_aboba@hotmail.com > Date: Tue=2C 3 Jul 2012 17:21:56 +0000 > CC: radext@ietf.org > Subject: Re: [radext] Proposed Resolution for Issue #109 >=20 > Hi Bernard=2C >=20 > I haven't found anywhere where the Acct-Terminate-Cause is allowed in the= Access-Reject. If we want to use this attribute in an Access-Reject the= n I think we would have to explicitly allow that in this draft. Do you se= e any problem with including that? =20 >=20 > Also=2C most of the existing values are indicating conditions present on = the NAS whereas the presence of the attribute in the reject is indicating t= he reason for the reject policy decision from the AAA. Perhaps it would be= better to use a separate attribute. The use of terminate-cause in 5196 i= s pretty limited and specific. =20 >=20 > Thanks=2C >=20 > Joe >=20 >=20 > On Jun 26=2C 2012=2C at 3:35 PM=2C Bernard Aboba wrote: >=20 > > >=20 > _______________________________________________ > radext mailing list > radext@ietf.org > https://www.ietf.org/mailman/listinfo/radext = --_51359712-0f57-42f4-8a12-6f1b0efc9b70_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Existing values of Acct-Terminate-Cause relate to conditions on the host or= NAS that cause a session to be terminated=3B the attribute is used to info= rm the Accounting Server of what happened.

This sounded similar to = the first part of the description in the text: 
 =
  The Reason code field of a Disassociation or Deauthentication frame
   (see clause 8.3.3.4 and 8.3.3.12 respectively in [IEEE-802.1=
1]) is
   transmitted by an Access Point to the station

If a Disassociat= ion or Deauthentication frame is sent by the AP to the station that causes = a session to be terminated=2C then sending an Acct-Terminate-Cause in an Ac= counting-Request could make sense.

However=2C there is also the res= t of the sentence:

"when authorization is denied=2C where authentic= ation may have been successful."

Some questions come to mind:
1. =3B Is it the NAS which is initiating the termination (e.g.=2C rep= orting the Reason-Code to the RADIUS server ) or is it the RADIUS server (e= .g.=2C telling the AP to send a particular Reason-Code to the station)? 2. =3B Is the termination occurring after a session has been started (= Disconnect-Request) or does it represent a denial of access (Access-Reject)= ?

One of the reason codes (code 27) seems to imply that the session= was terminated by the SP after it was started (e.g.=2C Access-Accept was s= ent=2C then a Disconnect-Request). =3B

In that situation=2C a r= eason for the disconnect might be included in the Disconnect-Request=2C the= n echoed in an Accounting-Request. =3B

Rather than using anothe= r attribute in the Accounting-Request to indicate the reason for the termin= ation=2C it may make sense to use Acct-Terminate-Cause=3B =3B however= =2C if that is done then Acct-Terminate-Cause would also be needed in the D= isconnect-Request so the DAS would know what to include (e.g.=2C why the se= ssion was terminated).

Other codes (such as 28=2C 29 or 30) seem to= imply that the session never got started=3B the implication is that an Acc= ess-Reject was sent.

In that situation=2C is the desire to cause th= e AP to send a particular Reason-Code to the Station?  =3B If a session= was not started=2C then an Accounting-Request would not be sent.

I= n that scenario=2C the use of Acct-Terminate-Cause may make less sense=2C a= nd instead it may make sense to include an Attribute expressing the Reason-= Code.

The "when authentication may have been successful" raises the= question of whether an EAP-Success is being transmitted within an EAP-Mess= age attribute contained within an Access-Reject.

RFC 3579 Section 2= .6.3 says:

   Access-Accept packets SHOULD have only one EAP-Me=
ssage attribute in
   them=2C containing EAP Success=3B similarly=2C Access-Reject packets SHO=
ULD
   have only one EAP-Message attribute in them=2C containing EAP Failure.

   Where the encapsulated EAP packet does not match the result implied
   by the RADIUS Packet Type=2C the combination is likely to cause
   confusion=2C because the NAS and peer will arrive at different
   conclusions as to the outcome of the authentication.





>=3B= From: jsalowey@cisco.com
>=3B To: bernard_aboba@hotmail.com
>=3B= Date: Tue=2C 3 Jul 2012 17:21:56 +0000
>=3B CC: radext@ietf.org
&g= t=3B Subject: Re: [radext] Proposed Resolution for Issue #109
>=3B >=3B Hi Bernard=2C
>=3B
>=3B I haven't found anywhere where t= he Acct-Terminate-Cause is allowed in the Access-Reject. If we want to u= se this attribute in an Access-Reject then I think we would have to explici= tly allow that in this draft. Do you see any problem with including that?=
>=3B
>=3B Also=2C most of the existing values are indicating = conditions present on the NAS whereas the presence of the attribute in the = reject is indicating the reason for the reject policy decision from the AAA= . Perhaps it would be better to use a separate attribute. The use of ter= minate-cause in 5196 is pretty limited and specific.
>=3B
>=3B= Thanks=2C
>=3B
>=3B Joe
>=3B
>=3B
>=3B On Jun = 26=2C 2012=2C at 3:35 PM=2C Bernard Aboba wrote:
>=3B
>=3B >= =3B <=3BRAD-WLAN.txt>=3B
>=3B
>=3B _________________________= ______________________
>=3B radext mailing list
>=3B radext@ietf.= org
>=3B https://www.ietf.org/mailman/listinfo/radext
=
= --_51359712-0f57-42f4-8a12-6f1b0efc9b70_-- From yoshigev@gmail.com Mon Jul 9 04:47:12 2012 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 56E3C21F86DF for ; Mon, 9 Jul 2012 04:47:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xOC5uashECcm for ; Mon, 9 Jul 2012 04:47:11 -0700 (PDT) Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id AF81B21F86D9 for ; Mon, 9 Jul 2012 04:47:08 -0700 (PDT) Received: by obbwc20 with SMTP id wc20so461082obb.31 for ; Mon, 09 Jul 2012 04:47:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=3peUo2cBpM7zUdO1wCYrv4+Vy86LJAsMtijGx7chlMo=; b=q1LSXn3GQB3SanHphko5wmGXG2+xKGQ0Fm4US5Rv8Staxrc0MO6izF0yqo0f2+7yrV AXlDEFjEo7zHI51KGI/fBXrr4ymz1CLPCe7tvJZNUvqbNQMYObRW6i4ehqKgHUYFVCDu 4mR34p03VFkQ9ng2pgDn9vK5jfFryLNWsGC1mP+hrLyH/DEf/29ekNaLFnYaAmtA/wMa TEWj3jCkhHLU7rOr4Ha2g5jNQXGRvh1bi4Yp27kGUkwPaskETGTcBX1Ki7tzxo518x/r Vcps3wdGge1biIDpQKNU1Er/W/MOKdZ6RkauT/+9wT5Hv+9xwFVtr0sz2o3fsl+05RnT 4xvQ== MIME-Version: 1.0 Received: by 10.182.228.6 with SMTP id se6mr35468249obc.29.1341834453111; Mon, 09 Jul 2012 04:47:33 -0700 (PDT) Received: by 10.60.120.74 with HTTP; Mon, 9 Jul 2012 04:47:33 -0700 (PDT) Date: Mon, 9 Jul 2012 14:47:33 +0300 Message-ID: From: Yehoshua Gev To: radext@ietf.org Content-Type: multipart/alternative; boundary=f46d04451709ecd39504c4642d8d Subject: [radext] RFC 5090 RADIUS client X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Jul 2012 11:47:12 -0000 --f46d04451709ecd39504c4642d8d Content-Type: text/plain; charset=UTF-8 Hello all, I hope that someone could answer some questions I have encountered with when designing a SIP server supporting RFC 5090. 1. Configuration of realm Section 2.1.1: The RADIUS client MUST choose the credential of the (Proxy-)Authorization header if the realm directive matches its ***locally configured*** realm. Section 2.1.5: The RADIUS client constructs a (Proxy-)Authenticate header using the ***received*** Digest-Nonce and Digest-Realm attributes to fill the nonce and realm directives. If the realm is determined by the RADIUS server, how would the RADIUS client know which Authorization header to choose? Should the RADIUS client remember the realms it had received on Access-Challenge responses? 2. Storing the nonce Section 2.1.2: If the RADIUS client recognizes the nonce, it takes the header directives and puts them into a RADIUS Access-Request packet. How should the RADIUS client recognize the nonce if it was not generated by it? Should the RADIUS client keep state and store the nonce it had received on the last Access-Challenge? 3. Statefulness The RFC does not state whether the RADIUS client (HTTP-style server) can work without keeping state. Especially that it must respond with the State attribute in subsequent Access-Request (section 5). If I understand the digest authentication scheme correctly, I believe that the opaque directive is used for state. Can opaque be used to store the State attribute? May the RADIUS client modify the opaque directive, to include the both Digest-Opaque and State attributes? Thank you very much, Yehoshua Gev --f46d04451709ecd39504c4642d8d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hello all,

I hope that someo= ne could answer some questions I have encountered with when designing a SIP= server supporting RFC 5090.


1. Con= figuration of realm
Section 2.1.1:
=C2=A0 =C2=A0The RADIUS
=C2=A0 =C2= =A0client MUST choose the credential of the (Proxy-)Authorization header
=C2=A0 =C2=A0if the realm directive matches its ***locally configur= ed*** realm.

Section 2.1.5:
=C2=A0 =C2=A0The RADIUS client construc= ts a (Proxy-)Authenticate header using the
=C2=A0 =C2=A0***receiv= ed*** Digest-Nonce and Digest-Realm attributes to fill the nonce
= =C2=A0 =C2=A0and realm directives.

If the realm is determined by the RADIUS server, how wo= uld the RADIUS client know which Authorization header to choose?
= Should the RADIUS client remember the realms it had received on Access-Chal= lenge responses?


2. Storing the nonce
Section 2= .1.2:
=C2=A0 =C2=A0If the RADIUS client recognizes the nonce, it = takes the header
=C2=A0 =C2=A0directives and puts them into a RAD= IUS Access-Request packet.

How should the RADIUS client recognize the nonce if it = was not generated by it?
Should the RADIUS client keep state and = store the nonce it had received on the last Access-Challenge?


3. Statefulness
The RFC does not st= ate whether the RADIUS client (HTTP-style server) can work without keeping = state.
Especially that it must respond with the State attribute i= n subsequent Access-Request (section 5).

If I understand the digest authentication scheme correc= tly, I believe that the opaque directive is used for state.
Can o= paque be used to store the State attribute?
May the RADIUS client= modify the opaque directive, to include the both Digest-Opaque and State a= ttributes?


Thank you very much,
Yehoshua = Gev

--f46d04451709ecd39504c4642d8d-- From radext-bounces@ietf.org Mon Jul 9 04:47:13 2012 Return-Path: X-Original-To: radext-archive-IeZ9sae2@lists.ietf.org Delivered-To: ietfarch-radext-archive-IeZ9sae2@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5A3C221F86D9; Mon, 9 Jul 2012 04:47:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1341834433; bh=X06FssGJ57r42cpq0CAmDnBPpbdhl+ZEkIrEylKePtI=; h=MIME-Version:Date:Message-ID:From:To:Subject:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: Content-Type:Sender; b=BiMDjYR6Zqyd4GYxOuPWmoPZ8nDbmmsagWRwYxirwR8L5Tycp81gMEMuGFx4ZNr66 z9Wc2ibWpltBc9ryME+5cyzOuKgusF23f41epugyxy4dpvJ71znD7ZfbhsJc5aorOO moccAI+deyCzLaQG64cQWWolWDod0OlMpsNljXv0= 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 56E3C21F86DF for ; Mon, 9 Jul 2012 04:47:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xOC5uashECcm for ; Mon, 9 Jul 2012 04:47:11 -0700 (PDT) Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id AF81B21F86D9 for ; Mon, 9 Jul 2012 04:47:08 -0700 (PDT) Received: by obbwc20 with SMTP id wc20so461082obb.31 for ; Mon, 09 Jul 2012 04:47:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=3peUo2cBpM7zUdO1wCYrv4+Vy86LJAsMtijGx7chlMo=; b=q1LSXn3GQB3SanHphko5wmGXG2+xKGQ0Fm4US5Rv8Staxrc0MO6izF0yqo0f2+7yrV AXlDEFjEo7zHI51KGI/fBXrr4ymz1CLPCe7tvJZNUvqbNQMYObRW6i4ehqKgHUYFVCDu 4mR34p03VFkQ9ng2pgDn9vK5jfFryLNWsGC1mP+hrLyH/DEf/29ekNaLFnYaAmtA/wMa TEWj3jCkhHLU7rOr4Ha2g5jNQXGRvh1bi4Yp27kGUkwPaskETGTcBX1Ki7tzxo518x/r Vcps3wdGge1biIDpQKNU1Er/W/MOKdZ6RkauT/+9wT5Hv+9xwFVtr0sz2o3fsl+05RnT 4xvQ== MIME-Version: 1.0 Received: by 10.182.228.6 with SMTP id se6mr35468249obc.29.1341834453111; Mon, 09 Jul 2012 04:47:33 -0700 (PDT) Received: by 10.60.120.74 with HTTP; Mon, 9 Jul 2012 04:47:33 -0700 (PDT) Date: Mon, 9 Jul 2012 14:47:33 +0300 Message-ID: From: Yehoshua Gev To: radext@ietf.org Subject: [radext] RFC 5090 RADIUS client X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0362906778790403760==" Sender: radext-bounces@ietf.org Errors-To: radext-bounces@ietf.org --===============0362906778790403760== Content-Type: multipart/alternative; boundary=f46d04451709ecd39504c4642d8d --f46d04451709ecd39504c4642d8d Content-Type: text/plain; charset=UTF-8 Hello all, I hope that someone could answer some questions I have encountered with when designing a SIP server supporting RFC 5090. 1. Configuration of realm Section 2.1.1: The RADIUS client MUST choose the credential of the (Proxy-)Authorization header if the realm directive matches its ***locally configured*** realm. Section 2.1.5: The RADIUS client constructs a (Proxy-)Authenticate header using the ***received*** Digest-Nonce and Digest-Realm attributes to fill the nonce and realm directives. If the realm is determined by the RADIUS server, how would the RADIUS client know which Authorization header to choose? Should the RADIUS client remember the realms it had received on Access-Challenge responses? 2. Storing the nonce Section 2.1.2: If the RADIUS client recognizes the nonce, it takes the header directives and puts them into a RADIUS Access-Request packet. How should the RADIUS client recognize the nonce if it was not generated by it? Should the RADIUS client keep state and store the nonce it had received on the last Access-Challenge? 3. Statefulness The RFC does not state whether the RADIUS client (HTTP-style server) can work without keeping state. Especially that it must respond with the State attribute in subsequent Access-Request (section 5). If I understand the digest authentication scheme correctly, I believe that the opaque directive is used for state. Can opaque be used to store the State attribute? May the RADIUS client modify the opaque directive, to include the both Digest-Opaque and State attributes? Thank you very much, Yehoshua Gev --f46d04451709ecd39504c4642d8d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hello all,

I hope that someo= ne could answer some questions I have encountered with when designing a SIP= server supporting RFC 5090.


1. Con= figuration of realm
Section 2.1.1:
=C2=A0 =C2=A0The RADIUS
=C2=A0 =C2= =A0client MUST choose the credential of the (Proxy-)Authorization header
=C2=A0 =C2=A0if the realm directive matches its ***locally configur= ed*** realm.

Section 2.1.5:
=C2=A0 =C2=A0The RADIUS client construc= ts a (Proxy-)Authenticate header using the
=C2=A0 =C2=A0***receiv= ed*** Digest-Nonce and Digest-Realm attributes to fill the nonce
= =C2=A0 =C2=A0and realm directives.

If the realm is determined by the RADIUS server, how wo= uld the RADIUS client know which Authorization header to choose?
= Should the RADIUS client remember the realms it had received on Access-Chal= lenge responses?


2. Storing the nonce
Section 2= .1.2:
=C2=A0 =C2=A0If the RADIUS client recognizes the nonce, it = takes the header
=C2=A0 =C2=A0directives and puts them into a RAD= IUS Access-Request packet.

How should the RADIUS client recognize the nonce if it = was not generated by it?
Should the RADIUS client keep state and = store the nonce it had received on the last Access-Challenge?


3. Statefulness
The RFC does not st= ate whether the RADIUS client (HTTP-style server) can work without keeping = state.
Especially that it must respond with the State attribute i= n subsequent Access-Request (section 5).

If I understand the digest authentication scheme correc= tly, I believe that the opaque directive is used for state.
Can o= paque be used to store the State attribute?
May the RADIUS client= modify the opaque directive, to include the both Digest-Opaque and State a= ttributes?


Thank you very much,
Yehoshua = Gev

--f46d04451709ecd39504c4642d8d-- --===============0362906778790403760== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ radext mailing list radext@ietf.org https://www.ietf.org/mailman/listinfo/radext --===============0362906778790403760==-- From jsalowey@cisco.com Tue Jul 10 21:40:14 2012 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 0CE6511E80CE for ; Tue, 10 Jul 2012 21:40:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BauP3SHpgBNa for ; Tue, 10 Jul 2012 21:40:13 -0700 (PDT) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id 8F37711E80BA for ; Tue, 10 Jul 2012 21:40:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=jsalowey@cisco.com; l=5219; q=dns/txt; s=iport; t=1341981641; x=1343191241; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=ZlwfaX9ltfqfcxTXENcFZiSh3v5BldZq6WzS6M7Q+Ck=; b=HPZN20ZqLTOLZa0jMWvwgAhHT3t94BBdQredWkxLcQuTx9/2jVQ2kmov 94G2cIeVPnK1gnV/c7Fe5cKZy8He63oqxjjHjGhEvAN5RLqI6S2lQrXAS 056EXFRfZFGTdLEzSkwyXsGjYrK9vpEFL855vod36cqrJh377kknRV0T8 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqsFACgD/U+tJXG8/2dsb2JhbABFpn2RAoEHgiABAQEDAQEBAQ8BWwsFCwIBCBEDAQIBLicLHQgCBA4FIodcAwYGC50goBYEilpmFIR6YAOIFo0giwSDG4Fmgl+BVg X-IronPort-AV: E=Sophos;i="4.77,564,1336348800"; d="scan'208";a="100697539" Received: from rcdn-core2-1.cisco.com ([173.37.113.188]) by rcdn-iport-4.cisco.com with ESMTP; 11 Jul 2012 04:40:37 +0000 Received: from xhc-aln-x12.cisco.com (xhc-aln-x12.cisco.com [173.36.12.86]) by rcdn-core2-1.cisco.com (8.14.5/8.14.5) with ESMTP id q6B4ebIR013826 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 11 Jul 2012 04:40:37 GMT Received: from xmb-rcd-x09.cisco.com ([169.254.9.118]) by xhc-aln-x12.cisco.com ([173.36.12.86]) with mapi id 14.02.0298.004; Tue, 10 Jul 2012 23:40:37 -0500 From: "Joseph Salowey (jsalowey)" To: Bernard Aboba Thread-Topic: [radext] Proposed Resolution for Issue #109 Thread-Index: AQHNU+v9o0KC6JGcRkqPQUv9Nf8LopcYLK8AgAGDlYCACjpVgA== Date: Wed, 11 Jul 2012 04:40:10 +0000 Message-ID: <66C7D1DF-9899-48C5-91BA-D530C8A82162@cisco.com> References: , <4730F52D-C88B-4B17-A635-BD017B02F799@cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.33.249.195] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19030.002 x-tm-as-result: No--60.721800-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="iso-8859-1" Content-ID: <7094A13D71AC44418E3867808D6990BA@cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "" Subject: Re: [radext] Proposed Resolution for Issue #109 X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 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 Jul 2012 04:40:14 -0000 On Jul 4, 2012, at 9:29 AM, Bernard Aboba wrote: > Existing values of Acct-Terminate-Cause relate to conditions on the host = or NAS that cause a session to be terminated; the attribute is used to info= rm the Accounting Server of what happened.=20 >=20 > This sounded similar to the first part of the description in the text:=20 > The Reason code field of a Disassociation or Deauthentication frame > (see clause 8.3.3.4 and 8.3.3.12 respectively in [ > IEEE-802.11 > ]) is > transmitted by an Access Point to the station=20 >=20 >=20 > If a Disassociation or Deauthentication frame is sent by the AP to the st= ation that causes a session to be terminated, then sending an Acct-Terminat= e-Cause in an Accounting-Request could make sense.=20 >=20 > However, there is also the rest of the sentence:=20 >=20 > "when authorization is denied, where authentication may have been success= ful."=20 >=20 > Some questions come to mind: >=20 > 1. Is it the NAS which is initiating the termination (e.g., reporting th= e Reason-Code to the RADIUS server ) or is it the RADIUS server (e.g., tell= ing the AP to send a particular Reason-Code to the station)?=20 [Joe] the use case that prompted this attribute was a denial of authorizati= on from the AAA to tell the AP to send a particular reason code. In other = cases I suppose there may be other triggers for the AP to terminate the ses= sion. > 2. Is the termination occurring after a session has been started (Discon= nect-Request) or does it represent a denial of access (Access-Reject)?=20 >=20 [Joe] the focus was on Access-Reject, but Disconnect-Request would probably= applicable too. =20 > One of the reason codes (code 27) seems to imply that the session was ter= minated by the SP after it was started (e.g., Access-Accept was sent, then = a Disconnect-Request). =20 >=20 > In that situation, a reason for the disconnect might be included in the D= isconnect-Request, then echoed in an Accounting-Request. =20 >=20 > Rather than using another attribute in the Accounting-Request to indicate= the reason for the termination, it may make sense to use Acct-Terminate-Ca= use; however, if that is done then Acct-Terminate-Cause would also be need= ed in the Disconnect-Request so the DAS would know what to include (e.g., w= hy the session was terminated).=20 >=20 > Other codes (such as 28, 29 or 30) seem to imply that the session never g= ot started; the implication is that an Access-Reject was sent.=20 >=20 > In that situation, is the desire to cause the AP to send a particular Rea= son-Code to the Station? If a session was not started, then an Accounting= -Request would not be sent.=20 >=20 [Joe] Yes.=20 > In that scenario, the use of Acct-Terminate-Cause may make less sense, an= d instead it may make sense to include an Attribute expressing the Reason-C= ode.=20 >=20 > The "when authentication may have been successful" raises the question of= whether an EAP-Success is being transmitted within an EAP-Message attribut= e contained within an Access-Reject.=20 >=20 [Joe] Good point, I think we would want to include a note to remind the r= eader of this recommendation. It might also be feasible to allow the attr= ibute in an Access-Accept to indicate failed authorization even if authenti= cation succeeds, however this seems like it may lead the confusing situati= on where an access-accept really means access-reject. =20 > RFC 3579 Section 2.6.3 says: >=20 > Access-Accept packets SHOULD have only one EAP-Message attribute in > them, containing EAP Success; similarly, Access-Reject packets SHOULD > have only one EAP-Message attribute in them, containing EAP Failure. >=20 > Where the encapsulated EAP packet does not match the result implied > by the RADIUS Packet Type, the combination is likely to cause > confusion, because the NAS and peer will arrive at different > conclusions as to the outcome of the authentication. >=20 >=20 >=20 >=20 >=20 >=20 > > From: jsalowey@cisco.com > > To: bernard_aboba@hotmail.com > > Date: Tue, 3 Jul 2012 17:21:56 +0000 > > CC: radext@ietf.org > > Subject: Re: [radext] Proposed Resolution for Issue #109 > >=20 > > Hi Bernard, > >=20 > > I haven't found anywhere where the Acct-Terminate-Cause is allowed in t= he Access-Reject. If we want to use this attribute in an Access-Reject then= I think we would have to explicitly allow that in this draft. Do you see a= ny problem with including that? > >=20 > > Also, most of the existing values are indicating conditions present on = the NAS whereas the presence of the attribute in the reject is indicating t= he reason for the reject policy decision from the AAA. Perhaps it would be = better to use a separate attribute. The use of terminate-cause in 5196 is p= retty limited and specific.=20 > >=20 > > Thanks, > >=20 > > Joe > >=20 > >=20 > > On Jun 26, 2012, at 3:35 PM, Bernard Aboba wrote: > >=20 > > > > >=20 > > _______________________________________________ > > radext mailing list > > radext@ietf.org > > https://www.ietf.org/mailman/listinfo/radext From radext-bounces@ietf.org Tue Jul 10 21:40:16 2012 Return-Path: X-Original-To: radext-archive-IeZ9sae2@lists.ietf.org Delivered-To: ietfarch-radext-archive-IeZ9sae2@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7395B11E80C5; Tue, 10 Jul 2012 21:40:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1341981616; bh=4LA6wbdeWCPho+QV7fCwZ7bwrTE0/lXW3rnnDrGi9ag=; h=From:To:Date:Message-ID:References:In-Reply-To:Content-ID: MIME-Version:Cc:Subject:List-Id:List-Unsubscribe:List-Archive: List-Post:List-Help:List-Subscribe:Content-Type: Content-Transfer-Encoding:Sender; b=JwxqMl+GoA1q6eH317Sza1P/AwOZacpMmoHuXOhP3W73+eR7gSAYIEp7drP/jwD4Q GaN2URgzMiwK3rnXiSlwfIapkIl2pfdyJXQGQjCJ7U/cLCGU3NPKHHOQtDwvwKB5Pz vmei+6J9Wdf8qAB9TLL6eNWfGSz+/V54IDq/D3NI= 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 0CE6511E80CE for ; Tue, 10 Jul 2012 21:40:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BauP3SHpgBNa for ; Tue, 10 Jul 2012 21:40:13 -0700 (PDT) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id 8F37711E80BA for ; Tue, 10 Jul 2012 21:40:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=jsalowey@cisco.com; l=5219; q=dns/txt; s=iport; t=1341981641; x=1343191241; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=ZlwfaX9ltfqfcxTXENcFZiSh3v5BldZq6WzS6M7Q+Ck=; b=HPZN20ZqLTOLZa0jMWvwgAhHT3t94BBdQredWkxLcQuTx9/2jVQ2kmov 94G2cIeVPnK1gnV/c7Fe5cKZy8He63oqxjjHjGhEvAN5RLqI6S2lQrXAS 056EXFRfZFGTdLEzSkwyXsGjYrK9vpEFL855vod36cqrJh377kknRV0T8 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqsFACgD/U+tJXG8/2dsb2JhbABFpn2RAoEHgiABAQEDAQEBAQ8BWwsFCwIBCBEDAQIBLicLHQgCBA4FIodcAwYGC50goBYEilpmFIR6YAOIFo0giwSDG4Fmgl+BVg X-IronPort-AV: E=Sophos;i="4.77,564,1336348800"; d="scan'208";a="100697539" Received: from rcdn-core2-1.cisco.com ([173.37.113.188]) by rcdn-iport-4.cisco.com with ESMTP; 11 Jul 2012 04:40:37 +0000 Received: from xhc-aln-x12.cisco.com (xhc-aln-x12.cisco.com [173.36.12.86]) by rcdn-core2-1.cisco.com (8.14.5/8.14.5) with ESMTP id q6B4ebIR013826 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 11 Jul 2012 04:40:37 GMT Received: from xmb-rcd-x09.cisco.com ([169.254.9.118]) by xhc-aln-x12.cisco.com ([173.36.12.86]) with mapi id 14.02.0298.004; Tue, 10 Jul 2012 23:40:37 -0500 From: "Joseph Salowey (jsalowey)" To: Bernard Aboba Thread-Topic: [radext] Proposed Resolution for Issue #109 Thread-Index: AQHNU+v9o0KC6JGcRkqPQUv9Nf8LopcYLK8AgAGDlYCACjpVgA== Date: Wed, 11 Jul 2012 04:40:10 +0000 Message-ID: <66C7D1DF-9899-48C5-91BA-D530C8A82162@cisco.com> References: , <4730F52D-C88B-4B17-A635-BD017B02F799@cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.33.249.195] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19030.002 x-tm-as-result: No--60.721800-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-ID: <7094A13D71AC44418E3867808D6990BA@cisco.com> MIME-Version: 1.0 Cc: "" Subject: Re: [radext] Proposed Resolution for Issue #109 X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: radext-bounces@ietf.org Errors-To: radext-bounces@ietf.org On Jul 4, 2012, at 9:29 AM, Bernard Aboba wrote: > Existing values of Acct-Terminate-Cause relate to conditions on the host or NAS that cause a session to be terminated; the attribute is used to inform the Accounting Server of what happened. > > This sounded similar to the first part of the description in the text: > The Reason code field of a Disassociation or Deauthentication frame > (see clause 8.3.3.4 and 8.3.3.12 respectively in [ > IEEE-802.11 > ]) is > transmitted by an Access Point to the station > > > If a Disassociation or Deauthentication frame is sent by the AP to the station that causes a session to be terminated, then sending an Acct-Terminate-Cause in an Accounting-Request could make sense. > > However, there is also the rest of the sentence: > > "when authorization is denied, where authentication may have been successful." > > Some questions come to mind: > > 1. Is it the NAS which is initiating the termination (e.g., reporting the Reason-Code to the RADIUS server ) or is it the RADIUS server (e.g., telling the AP to send a particular Reason-Code to the station)? [Joe] the use case that prompted this attribute was a denial of authorization from the AAA to tell the AP to send a particular reason code. In other cases I suppose there may be other triggers for the AP to terminate the session. > 2. Is the termination occurring after a session has been started (Disconnect-Request) or does it represent a denial of access (Access-Reject)? > [Joe] the focus was on Access-Reject, but Disconnect-Request would probably applicable too. > One of the reason codes (code 27) seems to imply that the session was terminated by the SP after it was started (e.g., Access-Accept was sent, then a Disconnect-Request). > > In that situation, a reason for the disconnect might be included in the Disconnect-Request, then echoed in an Accounting-Request. > > Rather than using another attribute in the Accounting-Request to indicate the reason for the termination, it may make sense to use Acct-Terminate-Cause; however, if that is done then Acct-Terminate-Cause would also be needed in the Disconnect-Request so the DAS would know what to include (e.g., why the session was terminated). > > Other codes (such as 28, 29 or 30) seem to imply that the session never got started; the implication is that an Access-Reject was sent. > > In that situation, is the desire to cause the AP to send a particular Reason-Code to the Station? If a session was not started, then an Accounting-Request would not be sent. > [Joe] Yes. > In that scenario, the use of Acct-Terminate-Cause may make less sense, and instead it may make sense to include an Attribute expressing the Reason-Code. > > The "when authentication may have been successful" raises the question of whether an EAP-Success is being transmitted within an EAP-Message attribute contained within an Access-Reject. > [Joe] Good point, I think we would want to include a note to remind the reader of this recommendation. It might also be feasible to allow the attribute in an Access-Accept to indicate failed authorization even if authentication succeeds, however this seems like it may lead the confusing situation where an access-accept really means access-reject. > RFC 3579 Section 2.6.3 says: > > Access-Accept packets SHOULD have only one EAP-Message attribute in > them, containing EAP Success; similarly, Access-Reject packets SHOULD > have only one EAP-Message attribute in them, containing EAP Failure. > > Where the encapsulated EAP packet does not match the result implied > by the RADIUS Packet Type, the combination is likely to cause > confusion, because the NAS and peer will arrive at different > conclusions as to the outcome of the authentication. > > > > > > > > From: jsalowey@cisco.com > > To: bernard_aboba@hotmail.com > > Date: Tue, 3 Jul 2012 17:21:56 +0000 > > CC: radext@ietf.org > > Subject: Re: [radext] Proposed Resolution for Issue #109 > > > > Hi Bernard, > > > > I haven't found anywhere where the Acct-Terminate-Cause is allowed in the Access-Reject. If we want to use this attribute in an Access-Reject then I think we would have to explicitly allow that in this draft. Do you see any problem with including that? > > > > Also, most of the existing values are indicating conditions present on the NAS whereas the presence of the attribute in the reject is indicating the reason for the reject policy decision from the AAA. Perhaps it would be better to use a separate attribute. The use of terminate-cause in 5196 is pretty limited and specific. > > > > Thanks, > > > > Joe > > > > > > On Jun 26, 2012, at 3:35 PM, Bernard Aboba wrote: > > > > > > > > > _______________________________________________ > > radext mailing list > > radext@ietf.org > > https://www.ietf.org/mailman/listinfo/radext _______________________________________________ radext mailing list radext@ietf.org https://www.ietf.org/mailman/listinfo/radext From radext-bounces@ietf.org Tue Jul 10 23:47:10 2012 Return-Path: X-Original-To: radext-archive-IeZ9sae2@lists.ietf.org Delivered-To: ietfarch-radext-archive-IeZ9sae2@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 93E5511E80F4; Tue, 10 Jul 2012 23:47:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1341989230; bh=J3sDhvLSZUq+duZke4q2tD+TaNwLjSBtNLK9z+qGgfE=; h=From:To:Date:Message-ID:References:In-Reply-To:MIME-Version: Subject:List-Id:List-Unsubscribe:List-Archive:List-Post:List-Help: List-Subscribe:Content-Type:Content-Transfer-Encoding:Sender; b=wdXQTAzPBXO61LortjCPj/3hL/CPIksvxTNybNtaLFQXcCRdjmcBTIclbo67LzKkV c0RT7baWSEf53+naAjLW+boXjFngO1BgGHC/RcrxN1mvovz3D47PUU0+JNa/slGkpP Sle6p1sU6ZXgPJfeZnQVtB7J0ksMrPRmr3J2MQkE= 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 8DE0011E80F4 for ; Tue, 10 Jul 2012 23:47:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.183 X-Spam-Level: X-Spam-Status: No, score=-6.183 tagged_above=-999 required=5 tests=[AWL=0.416, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Lqob3EgcpiAP for ; Tue, 10 Jul 2012 23:47:09 -0700 (PDT) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id E638211E80D1 for ; Tue, 10 Jul 2012 23:47:08 -0700 (PDT) Received: from 172.18.9.243 (EHLO dfweml202-edg.china.huawei.com) ([172.18.9.243]) by dfwrg02-dlp.huawei.com (MOS 4.2.3-GA FastPath) with ESMTP id AHQ65672; Wed, 11 Jul 2012 02:47:38 -0400 (EDT) Received: from DFWEML406-HUB.china.huawei.com (10.193.5.131) by dfweml202-edg.china.huawei.com (172.18.9.108) with Microsoft SMTP Server (TLS) id 14.1.323.3; Tue, 10 Jul 2012 23:45:00 -0700 Received: from SZXEML438-HUB.china.huawei.com (10.72.61.73) by dfweml406-hub.china.huawei.com (10.193.5.131) with Microsoft SMTP Server (TLS) id 14.1.323.3; Tue, 10 Jul 2012 23:44:59 -0700 Received: from SZXEML510-MBS.china.huawei.com ([169.254.8.103]) by szxeml438-hub.china.huawei.com ([10.72.61.73]) with mapi id 14.01.0323.003; Wed, 11 Jul 2012 14:44:52 +0800 From: Leaf yeh To: "" Thread-Topic: New Version Notification for draft-yeh-radext-ext-traffic-statistics-03.txt Thread-Index: AQHNXYhZSJKrwHy/rk2u8ErPQ+tz9pcjnWPw Date: Wed, 11 Jul 2012 06:44:51 +0000 Message-ID: References: <20120709040655.15521.56871.idtracker@ietfa.amsl.com> In-Reply-To: <20120709040655.15521.56871.idtracker@ietfa.amsl.com> Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.66.83.160] MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: Re: [radext] New Version Notification for draft-yeh-radext-ext-traffic-statistics-03.txt X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: radext-bounces@ietf.org Errors-To: radext-bounces@ietf.org Dear Radext Chairs & Folks: The newly updated draft on 'RADIUS Accounting Extensions for Traffic Statistics' are really derived from the long discussions even from IETF80. The relative presentations before can be referred as follows: http://www.ietf.org/proceedings/83/slides/slides-83-radext-1.pdf http://www.ietf.org/proceedings/82/slides/radext-2.pdf http://www.ietf.org/proceedings/80/slides/radext-5.pdf It is already in the tentative re-charter of Radext. (http://www.ietf.org/mail-archive/web/radext/current/msg07572.html ) RADIUS Accounting Extensions for Traffic Statistics. This work item will specify RADIUS accounting attributes for differentiated accounting policies and traffic recording. Nov 2012 Traffic Statistics Attribute I-D submitted as a Proposed Standard RFC I believe it is mature enough for the call for adoption now. Anyway, here is call for your review again. Your comments are more than welcome! Best Regards, Leaf -----Original Message----- From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] Sent: Monday, July 09, 2012 12:07 PM To: Leaf yeh Subject: New Version Notification for draft-yeh-radext-ext-traffic-statistics-03.txt A new version of I-D, draft-yeh-radext-ext-traffic-statistics-03.txt has been successfully submitted by Leaf Y. Yeh and posted to the IETF repository. Filename: draft-yeh-radext-ext-traffic-statistics Revision: 03 Title: RADIUS Accounting Extensions for Traffic Statistics Creation date: 2012-07-09 WG ID: Individual Submission Number of pages: 13 URL: http://www.ietf.org/internet-drafts/draft-yeh-radext-ext-traffic-statistics-03.txt Status: http://datatracker.ietf.org/doc/draft-yeh-radext-ext-traffic-statistics Htmlized: http://tools.ietf.org/html/draft-yeh-radext-ext-traffic-statistics-03 Diff: http://tools.ietf.org/rfcdiff?url2=draft-yeh-radext-ext-traffic-statistics-03 Abstract: This document specifies the RADIUS extensions of attributes for the traffic statistics with different type, which can be used to support the differentiated accounting policies and traffic recording on the AAA server. The IETF Secretariat _______________________________________________ radext mailing list radext@ietf.org https://www.ietf.org/mailman/listinfo/radext From leaf.y.yeh@huawei.com Tue Jul 10 23:47:09 2012 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 8DE0011E80F4 for ; Tue, 10 Jul 2012 23:47:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.183 X-Spam-Level: X-Spam-Status: No, score=-6.183 tagged_above=-999 required=5 tests=[AWL=0.416, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Lqob3EgcpiAP for ; Tue, 10 Jul 2012 23:47:09 -0700 (PDT) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id E638211E80D1 for ; Tue, 10 Jul 2012 23:47:08 -0700 (PDT) Received: from 172.18.9.243 (EHLO dfweml202-edg.china.huawei.com) ([172.18.9.243]) by dfwrg02-dlp.huawei.com (MOS 4.2.3-GA FastPath) with ESMTP id AHQ65672; Wed, 11 Jul 2012 02:47:38 -0400 (EDT) Received: from DFWEML406-HUB.china.huawei.com (10.193.5.131) by dfweml202-edg.china.huawei.com (172.18.9.108) with Microsoft SMTP Server (TLS) id 14.1.323.3; Tue, 10 Jul 2012 23:45:00 -0700 Received: from SZXEML438-HUB.china.huawei.com (10.72.61.73) by dfweml406-hub.china.huawei.com (10.193.5.131) with Microsoft SMTP Server (TLS) id 14.1.323.3; Tue, 10 Jul 2012 23:44:59 -0700 Received: from SZXEML510-MBS.china.huawei.com ([169.254.8.103]) by szxeml438-hub.china.huawei.com ([10.72.61.73]) with mapi id 14.01.0323.003; Wed, 11 Jul 2012 14:44:52 +0800 From: Leaf yeh To: "" Thread-Topic: New Version Notification for draft-yeh-radext-ext-traffic-statistics-03.txt Thread-Index: AQHNXYhZSJKrwHy/rk2u8ErPQ+tz9pcjnWPw Date: Wed, 11 Jul 2012 06:44:51 +0000 Message-ID: References: <20120709040655.15521.56871.idtracker@ietfa.amsl.com> In-Reply-To: <20120709040655.15521.56871.idtracker@ietfa.amsl.com> Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.66.83.160] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: Re: [radext] New Version Notification for draft-yeh-radext-ext-traffic-statistics-03.txt X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 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 Jul 2012 06:47:09 -0000 RGVhciBSYWRleHQgQ2hhaXJzICYgRm9sa3M6DQoNClRoZSBuZXdseSB1cGRhdGVkIGRyYWZ0IG9u ICdSQURJVVMgQWNjb3VudGluZyBFeHRlbnNpb25zIGZvciBUcmFmZmljIFN0YXRpc3RpY3MnIGFy ZSByZWFsbHkgZGVyaXZlZCBmcm9tIHRoZSBsb25nIGRpc2N1c3Npb25zIGV2ZW4gZnJvbSBJRVRG ODAuIFRoZSByZWxhdGl2ZSBwcmVzZW50YXRpb25zIGJlZm9yZSBjYW4gYmUgcmVmZXJyZWQgYXMg Zm9sbG93czoNCg0KaHR0cDovL3d3dy5pZXRmLm9yZy9wcm9jZWVkaW5ncy84My9zbGlkZXMvc2xp ZGVzLTgzLXJhZGV4dC0xLnBkZg0KaHR0cDovL3d3dy5pZXRmLm9yZy9wcm9jZWVkaW5ncy84Mi9z bGlkZXMvcmFkZXh0LTIucGRmIA0KaHR0cDovL3d3dy5pZXRmLm9yZy9wcm9jZWVkaW5ncy84MC9z bGlkZXMvcmFkZXh0LTUucGRmIA0KDQpJdCBpcyBhbHJlYWR5IGluIHRoZSB0ZW50YXRpdmUgcmUt Y2hhcnRlciBvZiBSYWRleHQuIChodHRwOi8vd3d3LmlldGYub3JnL21haWwtYXJjaGl2ZS93ZWIv cmFkZXh0L2N1cnJlbnQvbXNnMDc1NzIuaHRtbCApDQoNCjxxdW90ZT5SQURJVVMgQWNjb3VudGlu ZyBFeHRlbnNpb25zIGZvciBUcmFmZmljIFN0YXRpc3RpY3MuIFRoaXMgd29yayBpdGVtIHdpbGwg c3BlY2lmeSBSQURJVVMgYWNjb3VudGluZyBhdHRyaWJ1dGVzIGZvciBkaWZmZXJlbnRpYXRlZCBh Y2NvdW50aW5nIHBvbGljaWVzIGFuZCB0cmFmZmljIHJlY29yZGluZy4gPC9xdW90ZT4NCjxxdW90 ZT5Ob3YgMjAxMiAgICBUcmFmZmljIFN0YXRpc3RpY3MgQXR0cmlidXRlIEktRCBzdWJtaXR0ZWQg YXMgYSBQcm9wb3NlZCBTdGFuZGFyZCBSRkM8L3F1b3RlPg0KDQpJIGJlbGlldmUgaXQgaXMgbWF0 dXJlIGVub3VnaCBmb3IgdGhlIGNhbGwgZm9yIGFkb3B0aW9uIG5vdy4gDQoNCkFueXdheSwgaGVy ZSBpcyBjYWxsIGZvciB5b3VyIHJldmlldyBhZ2Fpbi4gWW91ciBjb21tZW50cyBhcmUgbW9yZSB0 aGFuIHdlbGNvbWUhDQoNCg0KQmVzdCBSZWdhcmRzLA0KTGVhZg0KDQoNCi0tLS0tT3JpZ2luYWwg TWVzc2FnZS0tLS0tDQpGcm9tOiBpbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmcgW21haWx0bzppbnRl cm5ldC1kcmFmdHNAaWV0Zi5vcmddIA0KU2VudDogTW9uZGF5LCBKdWx5IDA5LCAyMDEyIDEyOjA3 IFBNDQpUbzogTGVhZiB5ZWgNClN1YmplY3Q6IE5ldyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3Ig ZHJhZnQteWVoLXJhZGV4dC1leHQtdHJhZmZpYy1zdGF0aXN0aWNzLTAzLnR4dA0KDQoNCkEgbmV3 IHZlcnNpb24gb2YgSS1ELCBkcmFmdC15ZWgtcmFkZXh0LWV4dC10cmFmZmljLXN0YXRpc3RpY3Mt MDMudHh0DQpoYXMgYmVlbiBzdWNjZXNzZnVsbHkgc3VibWl0dGVkIGJ5IExlYWYgWS4gWWVoIGFu ZCBwb3N0ZWQgdG8gdGhlDQpJRVRGIHJlcG9zaXRvcnkuDQoNCkZpbGVuYW1lOgkgZHJhZnQteWVo LXJhZGV4dC1leHQtdHJhZmZpYy1zdGF0aXN0aWNzDQpSZXZpc2lvbjoJIDAzDQpUaXRsZToJCSBS QURJVVMgQWNjb3VudGluZyBFeHRlbnNpb25zIGZvciBUcmFmZmljIFN0YXRpc3RpY3MNCkNyZWF0 aW9uIGRhdGU6CSAyMDEyLTA3LTA5DQpXRyBJRDoJCSBJbmRpdmlkdWFsIFN1Ym1pc3Npb24NCk51 bWJlciBvZiBwYWdlczogMTMNClVSTDogICAgICAgICAgICAgaHR0cDovL3d3dy5pZXRmLm9yZy9p bnRlcm5ldC1kcmFmdHMvZHJhZnQteWVoLXJhZGV4dC1leHQtdHJhZmZpYy1zdGF0aXN0aWNzLTAz LnR4dA0KU3RhdHVzOiAgICAgICAgICBodHRwOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2Ry YWZ0LXllaC1yYWRleHQtZXh0LXRyYWZmaWMtc3RhdGlzdGljcw0KSHRtbGl6ZWQ6ICAgICAgICBo dHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC15ZWgtcmFkZXh0LWV4dC10cmFmZmljLXN0 YXRpc3RpY3MtMDMNCkRpZmY6ICAgICAgICAgICAgaHR0cDovL3Rvb2xzLmlldGYub3JnL3JmY2Rp ZmY/dXJsMj1kcmFmdC15ZWgtcmFkZXh0LWV4dC10cmFmZmljLXN0YXRpc3RpY3MtMDMNCg0KQWJz dHJhY3Q6DQogICBUaGlzIGRvY3VtZW50IHNwZWNpZmllcyB0aGUgUkFESVVTIGV4dGVuc2lvbnMg b2YgYXR0cmlidXRlcyBmb3IgdGhlDQogICB0cmFmZmljIHN0YXRpc3RpY3Mgd2l0aCBkaWZmZXJl bnQgdHlwZSwgd2hpY2ggY2FuIGJlIHVzZWQgdG8gc3VwcG9ydA0KICAgdGhlIGRpZmZlcmVudGlh dGVkIGFjY291bnRpbmcgcG9saWNpZXMgYW5kIHRyYWZmaWMgcmVjb3JkaW5nIG9uIHRoZQ0KICAg QUFBIHNlcnZlci4NCg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIA0KDQoNClRoZSBJRVRGIFNl Y3JldGFyaWF0DQo= From radext-bounces@ietf.org Tue Jul 10 23:52:18 2012 Return-Path: X-Original-To: radext-archive-IeZ9sae2@lists.ietf.org Delivered-To: ietfarch-radext-archive-IeZ9sae2@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EE15111E80BC; Tue, 10 Jul 2012 23:52:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1341989537; bh=5rs4dUCI89UV4AdaaXvQN+ENmcdx2TYw1g8BFrodBrY=; h=From:To:Date:Message-ID:MIME-Version:Subject:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: Content-Type:Content-Transfer-Encoding:Sender; b=uNQjIMAARwjISdrAHUJ3ZplheH5u3LeHyVqUWH2kyVT68ud49qsUf9eB34ThE/idg CSiJrJtPiGwdg5Qd3hbpIuj2FZZKiyDw40kurOETuQZGbEOOxYUiVMJ+0OSPXCao3W M5UVskGibH59TQzOvT0ONfb/hEVUdnVXBBOx6M8U= 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 6A11911E80BC for ; Tue, 10 Jul 2012 23:52:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.209 X-Spam-Level: X-Spam-Status: No, score=-6.209 tagged_above=-999 required=5 tests=[AWL=0.390, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ifu8fejNwW6h for ; Tue, 10 Jul 2012 23:52:16 -0700 (PDT) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id 9CBCA11E8086 for ; Tue, 10 Jul 2012 23:52:16 -0700 (PDT) Received: from 172.18.9.243 (EHLO dfweml202-edg.china.huawei.com) ([172.18.9.243]) by dfwrg01-dlp.huawei.com (MOS 4.2.3-GA FastPath) with ESMTP id AHX62955; Wed, 11 Jul 2012 02:52:46 -0400 (EDT) Received: from DFWEML404-HUB.china.huawei.com (10.193.5.203) by dfweml202-edg.china.huawei.com (172.18.9.108) with Microsoft SMTP Server (TLS) id 14.1.323.3; Tue, 10 Jul 2012 23:50:30 -0700 Received: from SZXEML420-HUB.china.huawei.com (10.82.67.159) by dfweml404-hub.china.huawei.com (10.193.5.203) with Microsoft SMTP Server (TLS) id 14.1.323.3; Tue, 10 Jul 2012 23:50:29 -0700 Received: from SZXEML510-MBS.china.huawei.com ([169.254.8.103]) by szxeml420-hub.china.huawei.com ([10.82.67.159]) with mapi id 14.01.0323.003; Wed, 11 Jul 2012 14:50:26 +0800 From: Leaf yeh To: "" Thread-Topic: New Version Notification for draft-yeh-radext-ext-dual-stack-access-00.txt Thread-Index: AQHNXa47PVjigqirBEGlEY/iXJwOt5cjpj+Q Date: Wed, 11 Jul 2012 06:50:24 +0000 Message-ID: Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.66.83.160] MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: [radext] FW: New Version Notification for draft-yeh-radext-ext-dual-stack-access-00.txt X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: radext-bounces@ietf.org Errors-To: radext-bounces@ietf.org Dear Radext Chairs & Folks: The newly submitted draft on 'RADIUS Extension for Dual Stack Access' is ready to call for your review. Your comments will be highly appreciated! Best Regards, Leaf -----Original Message----- From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] Sent: Monday, July 09, 2012 4:38 PM To: Leaf yeh Subject: New Version Notification for draft-yeh-radext-ext-dual-stack-access-00.txt A new version of I-D, draft-yeh-radext-ext-dual-stack-access-00.txt has been successfully submitted by Leaf Y. Yeh and posted to the IETF repository. Filename: draft-yeh-radext-ext-dual-stack-access Revision: 00 Title: RADIUS Extension for Dual Stack Access Creation date: 2012-07-09 WG ID: Individual Submission Number of pages: 10 URL: http://www.ietf.org/internet-drafts/draft-yeh-radext-ext-dual-stack-access-00.txt Status: http://datatracker.ietf.org/doc/draft-yeh-radext-ext-dual-stack-access Htmlized: http://tools.ietf.org/html/draft-yeh-radext-ext-dual-stack-access-00 Abstract: This document specifies the additional RADIUS attribute for IPv4 and IPv6 dual stack access, which are used in the AAA processes for NAS to employ the right mechanism and to allocate the proper configuration or resources for the users. The IETF Secretariat _______________________________________________ radext mailing list radext@ietf.org https://www.ietf.org/mailman/listinfo/radext From leaf.y.yeh@huawei.com Tue Jul 10 23:52:17 2012 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 6A11911E80BC for ; Tue, 10 Jul 2012 23:52:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.209 X-Spam-Level: X-Spam-Status: No, score=-6.209 tagged_above=-999 required=5 tests=[AWL=0.390, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ifu8fejNwW6h for ; Tue, 10 Jul 2012 23:52:16 -0700 (PDT) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id 9CBCA11E8086 for ; Tue, 10 Jul 2012 23:52:16 -0700 (PDT) Received: from 172.18.9.243 (EHLO dfweml202-edg.china.huawei.com) ([172.18.9.243]) by dfwrg01-dlp.huawei.com (MOS 4.2.3-GA FastPath) with ESMTP id AHX62955; Wed, 11 Jul 2012 02:52:46 -0400 (EDT) Received: from DFWEML404-HUB.china.huawei.com (10.193.5.203) by dfweml202-edg.china.huawei.com (172.18.9.108) with Microsoft SMTP Server (TLS) id 14.1.323.3; Tue, 10 Jul 2012 23:50:30 -0700 Received: from SZXEML420-HUB.china.huawei.com (10.82.67.159) by dfweml404-hub.china.huawei.com (10.193.5.203) with Microsoft SMTP Server (TLS) id 14.1.323.3; Tue, 10 Jul 2012 23:50:29 -0700 Received: from SZXEML510-MBS.china.huawei.com ([169.254.8.103]) by szxeml420-hub.china.huawei.com ([10.82.67.159]) with mapi id 14.01.0323.003; Wed, 11 Jul 2012 14:50:26 +0800 From: Leaf yeh To: "" Thread-Topic: New Version Notification for draft-yeh-radext-ext-dual-stack-access-00.txt Thread-Index: AQHNXa47PVjigqirBEGlEY/iXJwOt5cjpj+Q Date: Wed, 11 Jul 2012 06:50:24 +0000 Message-ID: Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.66.83.160] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: [radext] FW: New Version Notification for draft-yeh-radext-ext-dual-stack-access-00.txt X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 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 Jul 2012 06:52:17 -0000 RGVhciBSYWRleHQgQ2hhaXJzICYgRm9sa3M6DQoNClRoZSBuZXdseSBzdWJtaXR0ZWQgZHJhZnQg b24gJ1JBRElVUyBFeHRlbnNpb24gZm9yIER1YWwgU3RhY2sgQWNjZXNzJyBpcyByZWFkeSB0byBj YWxsIGZvciB5b3VyIHJldmlldy4gDQoNCllvdXIgY29tbWVudHMgd2lsbCBiZSBoaWdobHkgYXBw cmVjaWF0ZWQhDQoNCg0KQmVzdCBSZWdhcmRzLA0KTGVhZg0KDQoNCi0tLS0tT3JpZ2luYWwgTWVz c2FnZS0tLS0tDQpGcm9tOiBpbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmcgW21haWx0bzppbnRlcm5l dC1kcmFmdHNAaWV0Zi5vcmddIA0KU2VudDogTW9uZGF5LCBKdWx5IDA5LCAyMDEyIDQ6MzggUE0N ClRvOiBMZWFmIHllaA0KU3ViamVjdDogTmV3IFZlcnNpb24gTm90aWZpY2F0aW9uIGZvciBkcmFm dC15ZWgtcmFkZXh0LWV4dC1kdWFsLXN0YWNrLWFjY2Vzcy0wMC50eHQNCg0KDQpBIG5ldyB2ZXJz aW9uIG9mIEktRCwgZHJhZnQteWVoLXJhZGV4dC1leHQtZHVhbC1zdGFjay1hY2Nlc3MtMDAudHh0 DQpoYXMgYmVlbiBzdWNjZXNzZnVsbHkgc3VibWl0dGVkIGJ5IExlYWYgWS4gWWVoIGFuZCBwb3N0 ZWQgdG8gdGhlDQpJRVRGIHJlcG9zaXRvcnkuDQoNCkZpbGVuYW1lOgkgZHJhZnQteWVoLXJhZGV4 dC1leHQtZHVhbC1zdGFjay1hY2Nlc3MNClJldmlzaW9uOgkgMDANClRpdGxlOgkJIFJBRElVUyBF eHRlbnNpb24gZm9yIER1YWwgU3RhY2sgQWNjZXNzDQpDcmVhdGlvbiBkYXRlOgkgMjAxMi0wNy0w OQ0KV0cgSUQ6CQkgSW5kaXZpZHVhbCBTdWJtaXNzaW9uDQpOdW1iZXIgb2YgcGFnZXM6IDEwDQpV Ukw6ICAgICAgICAgICAgIGh0dHA6Ly93d3cuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzL2RyYWZ0 LXllaC1yYWRleHQtZXh0LWR1YWwtc3RhY2stYWNjZXNzLTAwLnR4dA0KU3RhdHVzOiAgICAgICAg ICBodHRwOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LXllaC1yYWRleHQtZXh0LWR1 YWwtc3RhY2stYWNjZXNzDQpIdG1saXplZDogICAgICAgIGh0dHA6Ly90b29scy5pZXRmLm9yZy9o dG1sL2RyYWZ0LXllaC1yYWRleHQtZXh0LWR1YWwtc3RhY2stYWNjZXNzLTAwDQoNCg0KQWJzdHJh Y3Q6DQogICBUaGlzIGRvY3VtZW50IHNwZWNpZmllcyB0aGUgYWRkaXRpb25hbCBSQURJVVMgYXR0 cmlidXRlIGZvciBJUHY0IGFuZA0KICAgSVB2NiBkdWFsIHN0YWNrIGFjY2Vzcywgd2hpY2ggYXJl IHVzZWQgaW4gdGhlIEFBQSBwcm9jZXNzZXMgZm9yIE5BUw0KICAgdG8gZW1wbG95IHRoZSByaWdo dCBtZWNoYW5pc20gYW5kIHRvIGFsbG9jYXRlIHRoZSBwcm9wZXINCiAgIGNvbmZpZ3VyYXRpb24g b3IgcmVzb3VyY2VzIGZvciB0aGUgdXNlcnMuDQoNCiAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAN Cg0KDQpUaGUgSUVURiBTZWNyZXRhcmlhdA0K From aland@deployingradius.com Wed Jul 11 09:16:24 2012 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 74F6211E8110 for ; Wed, 11 Jul 2012 09:16:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LGVAiPsO+C-4 for ; Wed, 11 Jul 2012 09:16:23 -0700 (PDT) Received: from liberty.deployingradius.com (liberty.deployingradius.com [88.191.76.128]) by ietfa.amsl.com (Postfix) with ESMTP id 770FB11E810B for ; Wed, 11 Jul 2012 09:16:23 -0700 (PDT) Message-ID: <4FFDA6DF.7040403@deployingradius.com> Date: Wed, 11 Jul 2012 12:16:31 -0400 From: Alan DeKok User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: Yehoshua Gev References: In-Reply-To: X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: radext@ietf.org Subject: Re: [radext] RFC 5090 RADIUS client X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 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 Jul 2012 16:16:24 -0000 Yehoshua Gev wrote: > I hope that someone could answer some questions I have encountered with > when designing a SIP server supporting RFC 5090. The implementation status of RFC 5090 is poor. i.e. most implementations still use the format define in doc/rfc/draft-sterman-aaa-sip-00.txt I would suggest surveying RADIUS servers for their support of RFC 5090, versus their support of that draft. > 3. Statefulness > The RFC does not state whether the RADIUS client (HTTP-style server) can > work without keeping state. > Especially that it must respond with the State attribute in subsequent > Access-Request (section 5). > > If I understand the digest authentication scheme correctly, I believe > that the opaque directive is used for state. > Can opaque be used to store the State attribute? No. The State attribute is separate, and must be treated as separate. > May the RADIUS client modify the opaque directive, to include the both > Digest-Opaque and State attributes? I would suggest "no". Alan DeKok. From radext-bounces@ietf.org Wed Jul 11 09:16:27 2012 Return-Path: X-Original-To: radext-archive-IeZ9sae2@lists.ietf.org Delivered-To: ietfarch-radext-archive-IeZ9sae2@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A6DE611E8112; Wed, 11 Jul 2012 09:16:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1342023386; bh=APiUhoxHql7qjp3wDSWA/WuGGo5zO3SHobp4C1aNbHk=; h=Message-ID:Date:From:MIME-Version:To:References:In-Reply-To:Cc: Subject:List-Id:List-Unsubscribe:List-Archive:List-Post:List-Help: List-Subscribe:Content-Type:Content-Transfer-Encoding:Sender; b=lXCfJCdXtriFndKuSaOyG19oCxsiEWAjysjQeDu4nv5eR4gij2gVZqQonZBpqr6wd 9HsDx/8fHMSaZwY7Y7j8rzBah2T4yiXVAOrWmCyZgTBF0A6i/kz0haXTuMrAuTQdOG 6naMvLaBde6+2S/NR9msRSXpY6Lg1Ln1F0HbJANM= 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 74F6211E8110 for ; Wed, 11 Jul 2012 09:16:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LGVAiPsO+C-4 for ; Wed, 11 Jul 2012 09:16:23 -0700 (PDT) Received: from liberty.deployingradius.com (liberty.deployingradius.com [88.191.76.128]) by ietfa.amsl.com (Postfix) with ESMTP id 770FB11E810B for ; Wed, 11 Jul 2012 09:16:23 -0700 (PDT) Message-ID: <4FFDA6DF.7040403@deployingradius.com> Date: Wed, 11 Jul 2012 12:16:31 -0400 From: Alan DeKok User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: Yehoshua Gev References: In-Reply-To: X-Enigmail-Version: 0.96.0 Cc: radext@ietf.org Subject: Re: [radext] RFC 5090 RADIUS client X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: radext-bounces@ietf.org Errors-To: radext-bounces@ietf.org Yehoshua Gev wrote: > I hope that someone could answer some questions I have encountered with > when designing a SIP server supporting RFC 5090. The implementation status of RFC 5090 is poor. i.e. most implementations still use the format define in doc/rfc/draft-sterman-aaa-sip-00.txt I would suggest surveying RADIUS servers for their support of RFC 5090, versus their support of that draft. > 3. Statefulness > The RFC does not state whether the RADIUS client (HTTP-style server) can > work without keeping state. > Especially that it must respond with the State attribute in subsequent > Access-Request (section 5). > > If I understand the digest authentication scheme correctly, I believe > that the opaque directive is used for state. > Can opaque be used to store the State attribute? No. The State attribute is separate, and must be treated as separate. > May the RADIUS client modify the opaque directive, to include the both > Digest-Opaque and State attributes? I would suggest "no". Alan DeKok. _______________________________________________ radext mailing list radext@ietf.org https://www.ietf.org/mailman/listinfo/radext From radext-bounces@ietf.org Wed Jul 11 09:43:11 2012 Return-Path: X-Original-To: radext-archive-IeZ9sae2@lists.ietf.org Delivered-To: ietfarch-radext-archive-IeZ9sae2@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2D94021F85F1; Wed, 11 Jul 2012 09:43:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1342024991; bh=lIwvBEMZPnxv0TofnjDuFViN/D5BmdGFN8/wOwEpJ6k=; h=Message-ID:Date:From:MIME-Version:To:References:In-Reply-To:Cc: Subject:List-Id:List-Unsubscribe:List-Archive:List-Post:List-Help: List-Subscribe:Content-Type:Content-Transfer-Encoding:Sender; b=k6U1GMZAFKRWEfCBE2JvNMh+ugDX8QYUbKyOXiJuPlfXLlrgCBtHy9rZGo7icSIlq if+bQMI5qT4msC7shbyB+uLjqAfFf8NlECUF2Ue/hWXO3hYDbSsHZuChCbJ5a3w5uT x4ZUQiEIa7m4ESySN27hegOjJl+nDq+U6xLZqXak= 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 D729321F85F0 for ; Wed, 11 Jul 2012 09:43:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SWy99ywWh2Z9 for ; Wed, 11 Jul 2012 09:43:09 -0700 (PDT) Received: from liberty.deployingradius.com (liberty.deployingradius.com [88.191.76.128]) by ietfa.amsl.com (Postfix) with ESMTP id 0584E21F85EF for ; Wed, 11 Jul 2012 09:43:09 -0700 (PDT) Message-ID: <4FFDAD25.2020208@deployingradius.com> Date: Wed, 11 Jul 2012 12:43:17 -0400 From: Alan DeKok User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: Leaf yeh References: <20120709040655.15521.56871.idtracker@ietfa.amsl.com> In-Reply-To: X-Enigmail-Version: 0.96.0 Cc: "" Subject: Re: [radext] New Version Notification for draft-yeh-radext-ext-traffic-statistics-03.txt X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: radext-bounces@ietf.org Errors-To: radext-bounces@ietf.org Leaf yeh wrote: > I believe it is mature enough for the call for adoption now. I don't support this document. > Anyway, here is call for your review again. Your comments are more than welcome! My comments are already on record. Alan DeKok. _______________________________________________ radext mailing list radext@ietf.org https://www.ietf.org/mailman/listinfo/radext From aland@deployingradius.com Wed Jul 11 09:43:09 2012 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 D729321F85F0 for ; Wed, 11 Jul 2012 09:43:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SWy99ywWh2Z9 for ; Wed, 11 Jul 2012 09:43:09 -0700 (PDT) Received: from liberty.deployingradius.com (liberty.deployingradius.com [88.191.76.128]) by ietfa.amsl.com (Postfix) with ESMTP id 0584E21F85EF for ; Wed, 11 Jul 2012 09:43:09 -0700 (PDT) Message-ID: <4FFDAD25.2020208@deployingradius.com> Date: Wed, 11 Jul 2012 12:43:17 -0400 From: Alan DeKok User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: Leaf yeh References: <20120709040655.15521.56871.idtracker@ietfa.amsl.com> In-Reply-To: X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "" Subject: Re: [radext] New Version Notification for draft-yeh-radext-ext-traffic-statistics-03.txt X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 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 Jul 2012 16:43:10 -0000 Leaf yeh wrote: > I believe it is mature enough for the call for adoption now. I don't support this document. > Anyway, here is call for your review again. Your comments are more than welcome! My comments are already on record. Alan DeKok. From leaf.y.yeh@huawei.com Wed Jul 11 19:26:43 2012 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 E331211E810F for ; Wed, 11 Jul 2012 19:26:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.232 X-Spam-Level: X-Spam-Status: No, score=-6.232 tagged_above=-999 required=5 tests=[AWL=0.367, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V2crIMdVdMFv for ; Wed, 11 Jul 2012 19:26:43 -0700 (PDT) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id 3D55B11E809A for ; Wed, 11 Jul 2012 19:26:43 -0700 (PDT) Received: from 172.18.9.243 (EHLO dfweml201-edg.china.huawei.com) ([172.18.9.243]) by dfwrg01-dlp.huawei.com (MOS 4.2.3-GA FastPath) with ESMTP id AHY30401; Wed, 11 Jul 2012 22:27:15 -0400 (EDT) Received: from DFWEML406-HUB.china.huawei.com (10.193.5.131) by dfweml201-edg.china.huawei.com (172.18.9.107) with Microsoft SMTP Server (TLS) id 14.1.323.3; Wed, 11 Jul 2012 19:23:58 -0700 Received: from SZXEML421-HUB.china.huawei.com (10.82.67.160) by dfweml406-hub.china.huawei.com (10.193.5.131) with Microsoft SMTP Server (TLS) id 14.1.323.3; Wed, 11 Jul 2012 19:24:03 -0700 Received: from SZXEML510-MBS.china.huawei.com ([169.254.8.103]) by szxeml421-hub.china.huawei.com ([10.82.67.160]) with mapi id 14.01.0323.003; Thu, 12 Jul 2012 10:23:59 +0800 From: Leaf yeh To: Alan DeKok Thread-Topic: [radext] New Version Notification for draft-yeh-radext-ext-traffic-statistics-03.txt Thread-Index: AQHNX4RJjQEmKvvN+0aebbZV0Efdcpck6uuA Date: Thu, 12 Jul 2012 02:23:59 +0000 Message-ID: References: <20120709040655.15521.56871.idtracker@ietfa.amsl.com> <4FFDAD25.2020208@deployingradius.com> In-Reply-To: <4FFDAD25.2020208@deployingradius.com> Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.66.83.160] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "" Subject: Re: [radext] New Version Notification for draft-yeh-radext-ext-traffic-statistics-03.txt X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 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, 12 Jul 2012 02:26:44 -0000 Alan - My comments are already on record. It is apparent I've missed your records on the List Archive.=20 Could you explicitly express your concerns or comments here again? Best Regards, Leaf -----Original Message----- From: Alan DeKok [mailto:aland@deployingradius.com]=20 Sent: Thursday, July 12, 2012 12:43 AM To: Leaf yeh Cc: Subject: Re: [radext] New Version Notification for draft-yeh-radext-ext-tra= ffic-statistics-03.txt Leaf yeh wrote: > I believe it is mature enough for the call for adoption now.=20 I don't support this document. > Anyway, here is call for your review again. Your comments are more than w= elcome! My comments are already on record. Alan DeKok. From radext-bounces@ietf.org Wed Jul 11 19:26:44 2012 Return-Path: X-Original-To: radext-archive-IeZ9sae2@lists.ietf.org Delivered-To: ietfarch-radext-archive-IeZ9sae2@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B9D7011E810F; Wed, 11 Jul 2012 19:26:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1342060004; bh=+vaHAs5UlS1wAUet2LVsPp6pL5w15YxgC1V0/3JNpBo=; h=From:To:Date:Message-ID:References:In-Reply-To:MIME-Version:Cc: Subject:List-Id:List-Unsubscribe:List-Archive:List-Post:List-Help: List-Subscribe:Content-Type:Content-Transfer-Encoding:Sender; b=Mp/0X6IG4l0K+RDS2gGw/Ji6oqjdaeOJcsa+oqfe7YHNIuGduX7VTj6tyOc83LDB/ dPtEpxKeiEE9P57Z9JYZFn2/Vl1kPh0tz3ZR5OLl/jDRSprzRRSWmAfWnAYpI+gCdH aGnRjfG9vnbp1W3pyHrEWDvRJnEViPGBxI3k5J28= 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 E331211E810F for ; Wed, 11 Jul 2012 19:26:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.232 X-Spam-Level: X-Spam-Status: No, score=-6.232 tagged_above=-999 required=5 tests=[AWL=0.367, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V2crIMdVdMFv for ; Wed, 11 Jul 2012 19:26:43 -0700 (PDT) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id 3D55B11E809A for ; Wed, 11 Jul 2012 19:26:43 -0700 (PDT) Received: from 172.18.9.243 (EHLO dfweml201-edg.china.huawei.com) ([172.18.9.243]) by dfwrg01-dlp.huawei.com (MOS 4.2.3-GA FastPath) with ESMTP id AHY30401; Wed, 11 Jul 2012 22:27:15 -0400 (EDT) Received: from DFWEML406-HUB.china.huawei.com (10.193.5.131) by dfweml201-edg.china.huawei.com (172.18.9.107) with Microsoft SMTP Server (TLS) id 14.1.323.3; Wed, 11 Jul 2012 19:23:58 -0700 Received: from SZXEML421-HUB.china.huawei.com (10.82.67.160) by dfweml406-hub.china.huawei.com (10.193.5.131) with Microsoft SMTP Server (TLS) id 14.1.323.3; Wed, 11 Jul 2012 19:24:03 -0700 Received: from SZXEML510-MBS.china.huawei.com ([169.254.8.103]) by szxeml421-hub.china.huawei.com ([10.82.67.160]) with mapi id 14.01.0323.003; Thu, 12 Jul 2012 10:23:59 +0800 From: Leaf yeh To: Alan DeKok Thread-Topic: [radext] New Version Notification for draft-yeh-radext-ext-traffic-statistics-03.txt Thread-Index: AQHNX4RJjQEmKvvN+0aebbZV0Efdcpck6uuA Date: Thu, 12 Jul 2012 02:23:59 +0000 Message-ID: References: <20120709040655.15521.56871.idtracker@ietfa.amsl.com> <4FFDAD25.2020208@deployingradius.com> In-Reply-To: <4FFDAD25.2020208@deployingradius.com> Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.66.83.160] MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "" Subject: Re: [radext] New Version Notification for draft-yeh-radext-ext-traffic-statistics-03.txt X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: radext-bounces@ietf.org Errors-To: radext-bounces@ietf.org Alan - My comments are already on record. It is apparent I've missed your records on the List Archive. Could you explicitly express your concerns or comments here again? Best Regards, Leaf -----Original Message----- From: Alan DeKok [mailto:aland@deployingradius.com] Sent: Thursday, July 12, 2012 12:43 AM To: Leaf yeh Cc: Subject: Re: [radext] New Version Notification for draft-yeh-radext-ext-traffic-statistics-03.txt Leaf yeh wrote: > I believe it is mature enough for the call for adoption now. I don't support this document. > Anyway, here is call for your review again. Your comments are more than welcome! My comments are already on record. Alan DeKok. _______________________________________________ radext mailing list radext@ietf.org https://www.ietf.org/mailman/listinfo/radext From stefan.winter@restena.lu Thu Jul 12 01:19:06 2012 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 2E8DB21F8691 for ; Thu, 12 Jul 2012 01:19:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0UJfNKf-Ng12 for ; Thu, 12 Jul 2012 01:19:05 -0700 (PDT) Received: from smtprelay.restena.lu (smtprelay.restena.lu [IPv6:2001:a18:1::62]) by ietfa.amsl.com (Postfix) with ESMTP id 2F15521F8598 for ; Thu, 12 Jul 2012 01:19:05 -0700 (PDT) Received: from smtprelay.restena.lu (localhost [127.0.0.1]) by smtprelay.restena.lu (Postfix) with ESMTP id A233810580 for ; Thu, 12 Jul 2012 10:19:36 +0200 (CEST) Received: from [IPv6:2001:a18:1:8:d9ce:77b1:6b7b:7788] (unknown [IPv6:2001:a18:1:8:d9ce:77b1:6b7b:7788]) by smtprelay.restena.lu (Postfix) with ESMTPS id 5A2451057E for ; Thu, 12 Jul 2012 10:19:36 +0200 (CEST) Message-ID: <4FFE8893.30402@restena.lu> Date: Thu, 12 Jul 2012 10:19:31 +0200 From: Stefan Winter User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:13.0) Gecko/20120601 Thunderbird/13.0 MIME-Version: 1.0 To: "radext@ietf.org" References: <20120712081654.17566.87131.idtracker@ietfa.amsl.com> In-Reply-To: <20120712081654.17566.87131.idtracker@ietfa.amsl.com> X-Enigmail-Version: 1.4.2 X-Forwarded-Message-Id: <20120712081654.17566.87131.idtracker@ietfa.amsl.com> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig7E91DD27E9C39A3362229A55" X-Virus-Scanned: ClamAV Subject: [radext] Fwd: New Version Notification for draft-winter-radext-fancyaccounting-01.txt X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 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, 12 Jul 2012 08:19:06 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig7E91DD27E9C39A3362229A55 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hello, since the interest on the topic of RADIUS Accounting for subsets of the total traffic has risen again, I have revived my old, expired -00 version of "fancyaccounting". The major change to -00 is that I drop the enumerated integer as a means to express which traffic is counted, and use only the string type instead. Realising that a known vocabulary of traffic classes is useful for inter-op between ISPs, I introduced an - optional - fixed syntax for specific accounting traffic classes by using URNs. Among those is, of course, IPv6, as this was the original trigger for the accounting traffic class discussion. The advantage of the URN/freetext model is that it can be expanded arbitrarily and yet have a defined meaning; while still allowing a local admin to count "whatever" by choosing not to use a URN. I would like to thank Klaas Wierenga for his inspiration in that regard! The other changes are cleanups (move of Integer64 to radius-extensions) and tighter semenatic requirements of when to send what; including a way to express which bytes exactly to count - a suggestion I got some 2 years ago when discussing -00. This is an individual submission which is in sort of a competition with draft-yeh-radext-ext-traffic-statistics. This is the consequence of Leaf's decision to first suggest numerous other, inferior, approaches, and then, when these were repelled, copying the approach from my -00 with slightly different wording with his name as the author; unsurprisingly, the two drafts are now very close to each other. I believe my draft is more thorough and thought-out in many aspects. The only difference is that his draft has an integer enumerator for traffic classes, while my draft uses a string. The string can do the same well-defined enumeration of known traffic classes that the integer can also do, and more. If the re-charter with an explicit mention of "RADIUS Accounting Extensions for Traffic Statistics" gets adopted, I would like to suggest adopting my draft for that topic. Greetings, Stefan Winter -------- Original Message -------- Subject: New Version Notification for draft-winter-radext-fancyaccounting-01.txt Date: Thu, 12 Jul 2012 01:16:54 -0700 From: internet-drafts@ietf.org To: stefan.winter@restena.lu A new version of I-D, draft-winter-radext-fancyaccounting-01.txt has been successfully submitted by Stefan Winter and posted to the IETF repository. Filename: draft-winter-radext-fancyaccounting Revision: 01 Title: RADIUS Accounting for traffic classes Creation date: 2012-07-12 WG ID: Individual Submission Number of pages: 9 URL: http://www.ietf.org/internet-drafts/draft-winter-radext-fancyaccounting-0= 1.txt Status: http://datatracker.ietf.org/doc/draft-winter-radext-fancyaccounting Htmlized: http://tools.ietf.org/html/draft-winter-radext-fancyaccounting-01 Diff: http://tools.ietf.org/rfcdiff?url2=3Ddraft-winter-radext-fancyaccounting-= 01 Abstract: This document specifies new attributes for RADIUS Accounting to enable NAS reporting of subsets of the total traffic in a user session. The IETF Secretariat --------------enig7E91DD27E9C39A3362229A55 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.0.18 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk/+iJcACgkQ+jm90f8eFWbZTACgh5zI9c1NM/ZLOvBmBTlsMN5y voUAn1lFS/sZjFrbfrL8Q6Ux6dp5BVyA =tQc0 -----END PGP SIGNATURE----- --------------enig7E91DD27E9C39A3362229A55-- From radext-bounces@ietf.org Thu Jul 12 01:19:07 2012 Return-Path: X-Original-To: radext-archive-IeZ9sae2@lists.ietf.org Delivered-To: ietfarch-radext-archive-IeZ9sae2@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 434E421F8691; Thu, 12 Jul 2012 01:19:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1342081147; bh=0B0ERyEoFKFEnu2/O5IdB2VnBYGhKgV0cUenwZniIl4=; h=Message-ID:Date:From:MIME-Version:To:References:In-Reply-To: Subject:List-Id:List-Unsubscribe:List-Archive:List-Post:List-Help: List-Subscribe:Content-Type:Sender; b=u/WSPFH6hIgtaYt/4hVX7lBpmkZWPETgtX3Xs4VXny3JjBwRtKxzZ/gX/4dADthNz oioZ/E9rw1RSaL4wN/ePKmHhtZBWqc8s4Y3gxTBAiHZdNCPf96RDG8dn+GPKRMnxO7 v7G6wcWT7w++E8D462IvM1/wRsiuoi5XyXI5yqfU= 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 2E8DB21F8691 for ; Thu, 12 Jul 2012 01:19:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0UJfNKf-Ng12 for ; Thu, 12 Jul 2012 01:19:05 -0700 (PDT) Received: from smtprelay.restena.lu (smtprelay.restena.lu [IPv6:2001:a18:1::62]) by ietfa.amsl.com (Postfix) with ESMTP id 2F15521F8598 for ; Thu, 12 Jul 2012 01:19:05 -0700 (PDT) Received: from smtprelay.restena.lu (localhost [127.0.0.1]) by smtprelay.restena.lu (Postfix) with ESMTP id A233810580 for ; Thu, 12 Jul 2012 10:19:36 +0200 (CEST) Received: from [IPv6:2001:a18:1:8:d9ce:77b1:6b7b:7788] (unknown [IPv6:2001:a18:1:8:d9ce:77b1:6b7b:7788]) by smtprelay.restena.lu (Postfix) with ESMTPS id 5A2451057E for ; Thu, 12 Jul 2012 10:19:36 +0200 (CEST) Message-ID: <4FFE8893.30402@restena.lu> Date: Thu, 12 Jul 2012 10:19:31 +0200 From: Stefan Winter User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:13.0) Gecko/20120601 Thunderbird/13.0 MIME-Version: 1.0 To: "radext@ietf.org" References: <20120712081654.17566.87131.idtracker@ietfa.amsl.com> In-Reply-To: <20120712081654.17566.87131.idtracker@ietfa.amsl.com> X-Enigmail-Version: 1.4.2 X-Forwarded-Message-Id: <20120712081654.17566.87131.idtracker@ietfa.amsl.com> X-Virus-Scanned: ClamAV Subject: [radext] Fwd: New Version Notification for draft-winter-radext-fancyaccounting-01.txt X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============3833743313978928594==" Sender: radext-bounces@ietf.org Errors-To: radext-bounces@ietf.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --===============3833743313978928594== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig7E91DD27E9C39A3362229A55" This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig7E91DD27E9C39A3362229A55 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hello, since the interest on the topic of RADIUS Accounting for subsets of the total traffic has risen again, I have revived my old, expired -00 version of "fancyaccounting". The major change to -00 is that I drop the enumerated integer as a means to express which traffic is counted, and use only the string type instead. Realising that a known vocabulary of traffic classes is useful for inter-op between ISPs, I introduced an - optional - fixed syntax for specific accounting traffic classes by using URNs. Among those is, of course, IPv6, as this was the original trigger for the accounting traffic class discussion. The advantage of the URN/freetext model is that it can be expanded arbitrarily and yet have a defined meaning; while still allowing a local admin to count "whatever" by choosing not to use a URN. I would like to thank Klaas Wierenga for his inspiration in that regard! The other changes are cleanups (move of Integer64 to radius-extensions) and tighter semenatic requirements of when to send what; including a way to express which bytes exactly to count - a suggestion I got some 2 years ago when discussing -00. This is an individual submission which is in sort of a competition with draft-yeh-radext-ext-traffic-statistics. This is the consequence of Leaf's decision to first suggest numerous other, inferior, approaches, and then, when these were repelled, copying the approach from my -00 with slightly different wording with his name as the author; unsurprisingly, the two drafts are now very close to each other. I believe my draft is more thorough and thought-out in many aspects. The only difference is that his draft has an integer enumerator for traffic classes, while my draft uses a string. The string can do the same well-defined enumeration of known traffic classes that the integer can also do, and more. If the re-charter with an explicit mention of "RADIUS Accounting Extensions for Traffic Statistics" gets adopted, I would like to suggest adopting my draft for that topic. Greetings, Stefan Winter -------- Original Message -------- Subject: New Version Notification for draft-winter-radext-fancyaccounting-01.txt Date: Thu, 12 Jul 2012 01:16:54 -0700 From: internet-drafts@ietf.org To: stefan.winter@restena.lu A new version of I-D, draft-winter-radext-fancyaccounting-01.txt has been successfully submitted by Stefan Winter and posted to the IETF repository. Filename: draft-winter-radext-fancyaccounting Revision: 01 Title: RADIUS Accounting for traffic classes Creation date: 2012-07-12 WG ID: Individual Submission Number of pages: 9 URL: http://www.ietf.org/internet-drafts/draft-winter-radext-fancyaccounting-0= 1.txt Status: http://datatracker.ietf.org/doc/draft-winter-radext-fancyaccounting Htmlized: http://tools.ietf.org/html/draft-winter-radext-fancyaccounting-01 Diff: http://tools.ietf.org/rfcdiff?url2=3Ddraft-winter-radext-fancyaccounting-= 01 Abstract: This document specifies new attributes for RADIUS Accounting to enable NAS reporting of subsets of the total traffic in a user session. The IETF Secretariat --------------enig7E91DD27E9C39A3362229A55 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.0.18 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk/+iJcACgkQ+jm90f8eFWbZTACgh5zI9c1NM/ZLOvBmBTlsMN5y voUAn1lFS/sZjFrbfrL8Q6Ux6dp5BVyA =tQc0 -----END PGP SIGNATURE----- --------------enig7E91DD27E9C39A3362229A55-- --===============3833743313978928594== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ radext mailing list radext@ietf.org https://www.ietf.org/mailman/listinfo/radext --===============3833743313978928594==-- From radext-bounces@ietf.org Thu Jul 12 02:38:24 2012 Return-Path: X-Original-To: radext-archive-IeZ9sae2@lists.ietf.org Delivered-To: ietfarch-radext-archive-IeZ9sae2@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7CECB21F8484; Thu, 12 Jul 2012 02:38:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1342085904; bh=TZ/kV8mBA9wuzK3Q9dFx/pxWusdOtWdDgcYgqput9iY=; h=Date:From:To:In-Reply-To:Message-ID:References:MIME-Version:Cc: Subject:List-Id:List-Unsubscribe:List-Archive:List-Post:List-Help: List-Subscribe:Content-Transfer-Encoding:Content-Type:Sender; b=PGHz/sesJlMajExY+GcnH0+xbe8shL0Ie9LZfwAPg5lXj3J2jMKyrcjc8xPD4QQX6 WX6h1QfsjcHEBfT8StDSIQoklRipRcoJ38dGl9U8XhdpdikKuZ4Xv9lM5LJDlxMwJx 0j9XWaTdEZ+dVSNYzgZgtxdlh83Gz6W5qGF68WYA= 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 9CEBD21F8484 for ; Thu, 12 Jul 2012 02:38:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CM4k79+UoK+o for ; Thu, 12 Jul 2012 02:38:22 -0700 (PDT) Received: from aspen.internal.iea-software.com (remote.iea-software.com [70.89.142.196]) by ietfa.amsl.com (Postfix) with ESMTP id 8F27F21F847E for ; Thu, 12 Jul 2012 02:38:22 -0700 (PDT) Received: from SMURF (unverified [10.0.3.195]) by aspen.internal.iea-software.com (Rockliffe SMTPRA 7.0.6) with ESMTP id ; Thu, 12 Jul 2012 02:38:22 -0700 Date: Thu, 12 Jul 2012 02:38:53 -0700 (Pacific Daylight Time) From: Peter Deacon To: Stefan Winter In-Reply-To: <4FFE8893.30402@restena.lu> Message-ID: References: <20120712081654.17566.87131.idtracker@ietfa.amsl.com> <4FFE8893.30402@restena.lu> User-Agent: Alpine 2.00 (WNT 1167 2008-08-23) MIME-Version: 1.0 Cc: "radext@ietf.org" Subject: Re: [radext] Fwd: New Version Notification for draft-winter-radext-fancyaccounting-01.txt X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: radext-bounces@ietf.org Errors-To: radext-bounces@ietf.org On Thu, 12 Jul 2012, Stefan Winter wrote: > Hello, > since the interest on the topic of RADIUS Accounting for subsets of the > total traffic has risen again, I have revived my old, expired -00 > version of "fancyaccounting". The major change to -00 is that I drop the > enumerated integer as a means to express which traffic is counted, and > use only the string type instead. > Realising that a known vocabulary of traffic classes is useful for > inter-op between ISPs, I introduced an - optional - fixed syntax for > specific accounting traffic classes by using URNs. Among those is, of > course, IPv6, as this was the original trigger for the accounting > traffic class discussion. I like the new accounting draft -- simple and flexible. Some thoughts.. There might be cases where not all Packet and Octet information is known or provided. For example counting bytes over a serial line or higher layer where packet counts may no longer be known, applicable or accessible. Suggest changing 'exactly once' to zero or one for Packets and Octets fields. -- If you can count it people are going to want to enforce it. Using interim accounting and dynamic auth is a practical option however leakage is unavoidable. Perhaps a separate container group to signal limits via Access-Accept enforced by NAS: Limit-Traffic-Class Limit-Traffic-Class-Name Limit-Traffic-Class-Input-Octets Limit-Traffic-Class-Output-Octets 'd volunteer text if theres interest and this is not too much scope creep. regards, Peter _______________________________________________ radext mailing list radext@ietf.org https://www.ietf.org/mailman/listinfo/radext From peterd@iea-software.com Thu Jul 12 02:38:23 2012 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 9CEBD21F8484 for ; Thu, 12 Jul 2012 02:38:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CM4k79+UoK+o for ; Thu, 12 Jul 2012 02:38:22 -0700 (PDT) Received: from aspen.internal.iea-software.com (remote.iea-software.com [70.89.142.196]) by ietfa.amsl.com (Postfix) with ESMTP id 8F27F21F847E for ; Thu, 12 Jul 2012 02:38:22 -0700 (PDT) Received: from SMURF (unverified [10.0.3.195]) by aspen.internal.iea-software.com (Rockliffe SMTPRA 7.0.6) with ESMTP id ; Thu, 12 Jul 2012 02:38:22 -0700 Date: Thu, 12 Jul 2012 02:38:53 -0700 (Pacific Daylight Time) From: Peter Deacon To: Stefan Winter In-Reply-To: <4FFE8893.30402@restena.lu> Message-ID: References: <20120712081654.17566.87131.idtracker@ietfa.amsl.com> <4FFE8893.30402@restena.lu> User-Agent: Alpine 2.00 (WNT 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: "radext@ietf.org" Subject: Re: [radext] Fwd: New Version Notification for draft-winter-radext-fancyaccounting-01.txt X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 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, 12 Jul 2012 09:38:23 -0000 On Thu, 12 Jul 2012, Stefan Winter wrote: > Hello, > since the interest on the topic of RADIUS Accounting for subsets of the > total traffic has risen again, I have revived my old, expired -00 > version of "fancyaccounting". The major change to -00 is that I drop the > enumerated integer as a means to express which traffic is counted, and > use only the string type instead. > Realising that a known vocabulary of traffic classes is useful for > inter-op between ISPs, I introduced an - optional - fixed syntax for > specific accounting traffic classes by using URNs. Among those is, of > course, IPv6, as this was the original trigger for the accounting > traffic class discussion. I like the new accounting draft -- simple and flexible. Some thoughts.. There might be cases where not all Packet and Octet information is known or provided. For example counting bytes over a serial line or higher layer where packet counts may no longer be known, applicable or accessible. Suggest changing 'exactly once' to zero or one for Packets and Octets fields. -- If you can count it people are going to want to enforce it. Using interim accounting and dynamic auth is a practical option however leakage is unavoidable. Perhaps a separate container group to signal limits via Access-Accept enforced by NAS: Limit-Traffic-Class Limit-Traffic-Class-Name Limit-Traffic-Class-Input-Octets Limit-Traffic-Class-Output-Octets 'd volunteer text if theres interest and this is not too much scope creep. regards, Peter From radext-bounces@ietf.org Thu Jul 12 02:44:02 2012 Return-Path: X-Original-To: radext-archive-IeZ9sae2@lists.ietf.org Delivered-To: ietfarch-radext-archive-IeZ9sae2@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1122C21F876C; Thu, 12 Jul 2012 02:44:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1342086242; bh=M8YjZ4Pza4PCh8FmXxosVUCW6MK27Yzh2ebzSxKXsz4=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:From:To:Cc: Subject:List-Id:List-Unsubscribe:List-Archive:List-Post:List-Help: List-Subscribe:Content-Type:Content-Transfer-Encoding:Sender; b=o92jFFVrKoPSteyHgJwTsDinDBXAwt5V45laYQqqrRnTEEH1DpxUh3FafvZdg8L3Y YuWXEPEEssHYQy/vMwiDjSEZ6O+9aqZ+ILTtycOQ3YjQe+9KCUkzVlFnMscPY9FGY/ DzsiDITo6U4oS+UkUUBDl+Qxfqc3NgNaO2oVRRbg= 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 3364621F876C for ; Thu, 12 Jul 2012 02:44:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[AWL=0.001, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Nd7kfjYUj6Q8 for ; Thu, 12 Jul 2012 02:44:00 -0700 (PDT) Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id 8F82221F8766 for ; Thu, 12 Jul 2012 02:44:00 -0700 (PDT) Received: by obbwc20 with SMTP id wc20so3239669obb.31 for ; Thu, 12 Jul 2012 02:44:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=6LgUZ8QdJjS4eMMqumW9ZIHCUTPY+8bHVyoPd3m7sqQ=; b=BIZdOxeqJcEkYibiS00u5qGRMYr5auNZ4UOnJG+M4A1w3i/rgqdB7NfgF3FAoMCfd7 DwQilN089ltO25ZxakI07w8zd2jpwLt2DrxBQVXHKda4edgp+l9MebntTHGS4DJc10lZ mCEx9etw11VNFUQnXlIVRoeU1YcbZDYl7DrA4sjVjqJX+bUiuWjnMEpHTHWM2J+8sZlP uwBT+uE6R7M7mXZxzjmSwXUwXsdp0omek6ux+gs+TdnOL90Y5u+Zeoorcfv0rdvzBOPP bAS43f4tJdxwOqVPJNRJmZzm6l7bFlzJsxuAcczYhdQ3dgIVFalPnjfUwYpf+fNt4IT3 UP2g== MIME-Version: 1.0 Received: by 10.60.25.6 with SMTP id y6mr54724825oef.42.1342086273108; Thu, 12 Jul 2012 02:44:33 -0700 (PDT) Received: by 10.60.120.74 with HTTP; Thu, 12 Jul 2012 02:44:32 -0700 (PDT) In-Reply-To: <4FFDA6DF.7040403@deployingradius.com> References: <4FFDA6DF.7040403@deployingradius.com> Date: Thu, 12 Jul 2012 12:44:32 +0300 Message-ID: From: Yehoshua Gev To: Alan DeKok Cc: radext@ietf.org Subject: Re: [radext] RFC 5090 RADIUS client X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: radext-bounces@ietf.org Errors-To: radext-bounces@ietf.org Thanks. So the client would have to store the State attribute value until receiving the new INVITE? Yehoshua On Wed, Jul 11, 2012 at 7:16 PM, Alan DeKok wrote: > > Yehoshua Gev wrote: > > I hope that someone could answer some questions I have encountered with > > when designing a SIP server supporting RFC 5090. > > The implementation status of RFC 5090 is poor. i.e. most > implementations still use the format define in > > doc/rfc/draft-sterman-aaa-sip-00.txt > > I would suggest surveying RADIUS servers for their support of RFC > 5090, versus their support of that draft. > > > 3. Statefulness > > The RFC does not state whether the RADIUS client (HTTP-style server) can > > work without keeping state. > > Especially that it must respond with the State attribute in subsequent > > Access-Request (section 5). > > > > If I understand the digest authentication scheme correctly, I believe > > that the opaque directive is used for state. > > Can opaque be used to store the State attribute? > > No. The State attribute is separate, and must be treated as separate. > > > May the RADIUS client modify the opaque directive, to include the both > > Digest-Opaque and State attributes? > > I would suggest "no". > > Alan DeKok. _______________________________________________ radext mailing list radext@ietf.org https://www.ietf.org/mailman/listinfo/radext From yoshigev@gmail.com Thu Jul 12 02:44:01 2012 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 3364621F876C for ; Thu, 12 Jul 2012 02:44:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[AWL=0.001, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Nd7kfjYUj6Q8 for ; Thu, 12 Jul 2012 02:44:00 -0700 (PDT) Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id 8F82221F8766 for ; Thu, 12 Jul 2012 02:44:00 -0700 (PDT) Received: by obbwc20 with SMTP id wc20so3239669obb.31 for ; Thu, 12 Jul 2012 02:44:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=6LgUZ8QdJjS4eMMqumW9ZIHCUTPY+8bHVyoPd3m7sqQ=; b=BIZdOxeqJcEkYibiS00u5qGRMYr5auNZ4UOnJG+M4A1w3i/rgqdB7NfgF3FAoMCfd7 DwQilN089ltO25ZxakI07w8zd2jpwLt2DrxBQVXHKda4edgp+l9MebntTHGS4DJc10lZ mCEx9etw11VNFUQnXlIVRoeU1YcbZDYl7DrA4sjVjqJX+bUiuWjnMEpHTHWM2J+8sZlP uwBT+uE6R7M7mXZxzjmSwXUwXsdp0omek6ux+gs+TdnOL90Y5u+Zeoorcfv0rdvzBOPP bAS43f4tJdxwOqVPJNRJmZzm6l7bFlzJsxuAcczYhdQ3dgIVFalPnjfUwYpf+fNt4IT3 UP2g== MIME-Version: 1.0 Received: by 10.60.25.6 with SMTP id y6mr54724825oef.42.1342086273108; Thu, 12 Jul 2012 02:44:33 -0700 (PDT) Received: by 10.60.120.74 with HTTP; Thu, 12 Jul 2012 02:44:32 -0700 (PDT) In-Reply-To: <4FFDA6DF.7040403@deployingradius.com> References: <4FFDA6DF.7040403@deployingradius.com> Date: Thu, 12 Jul 2012 12:44:32 +0300 Message-ID: From: Yehoshua Gev To: Alan DeKok Content-Type: text/plain; charset=UTF-8 Cc: radext@ietf.org Subject: Re: [radext] RFC 5090 RADIUS client X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 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, 12 Jul 2012 09:44:01 -0000 Thanks. So the client would have to store the State attribute value until receiving the new INVITE? Yehoshua On Wed, Jul 11, 2012 at 7:16 PM, Alan DeKok wrote: > > Yehoshua Gev wrote: > > I hope that someone could answer some questions I have encountered with > > when designing a SIP server supporting RFC 5090. > > The implementation status of RFC 5090 is poor. i.e. most > implementations still use the format define in > > doc/rfc/draft-sterman-aaa-sip-00.txt > > I would suggest surveying RADIUS servers for their support of RFC > 5090, versus their support of that draft. > > > 3. Statefulness > > The RFC does not state whether the RADIUS client (HTTP-style server) can > > work without keeping state. > > Especially that it must respond with the State attribute in subsequent > > Access-Request (section 5). > > > > If I understand the digest authentication scheme correctly, I believe > > that the opaque directive is used for state. > > Can opaque be used to store the State attribute? > > No. The State attribute is separate, and must be treated as separate. > > > May the RADIUS client modify the opaque directive, to include the both > > Digest-Opaque and State attributes? > > I would suggest "no". > > Alan DeKok. From leaf.y.yeh@huawei.com Thu Jul 12 04:45:09 2012 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 904DD21F8811 for ; Thu, 12 Jul 2012 04:45:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.252 X-Spam-Level: X-Spam-Status: No, score=-6.252 tagged_above=-999 required=5 tests=[AWL=0.347, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dDjUbTedUCc4 for ; Thu, 12 Jul 2012 04:45:08 -0700 (PDT) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id A63BE21F8615 for ; Thu, 12 Jul 2012 04:45:08 -0700 (PDT) Received: from 172.18.9.243 (EHLO dfweml202-edg.china.huawei.com) ([172.18.9.243]) by dfwrg02-dlp.huawei.com (MOS 4.2.3-GA FastPath) with ESMTP id AHR66810; Thu, 12 Jul 2012 07:45:41 -0400 (EDT) Received: from DFWEML404-HUB.china.huawei.com (10.193.5.203) by dfweml202-edg.china.huawei.com (172.18.9.108) with Microsoft SMTP Server (TLS) id 14.1.323.3; Thu, 12 Jul 2012 04:43:04 -0700 Received: from SZXEML440-HUB.china.huawei.com (10.72.61.75) by dfweml404-hub.china.huawei.com (10.193.5.203) with Microsoft SMTP Server (TLS) id 14.1.323.3; Thu, 12 Jul 2012 04:43:03 -0700 Received: from SZXEML510-MBS.china.huawei.com ([169.254.8.103]) by SZXEML440-HUB.china.huawei.com ([10.72.61.75]) with mapi id 14.01.0323.003; Thu, 12 Jul 2012 19:42:58 +0800 From: Leaf yeh To: "radext@ietf.org" Thread-Topic: [radext] Fwd: New Version Notification for draft-winter-radext-fancyaccounting-01.txt Thread-Index: AQHNYAcbajsyHVA0AESdZldyuv+snJclcgFg Date: Thu, 12 Jul 2012 11:42:56 +0000 Message-ID: References: <20120712081654.17566.87131.idtracker@ietfa.amsl.com> <4FFE8893.30402@restena.lu> In-Reply-To: <4FFE8893.30402@restena.lu> Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.66.83.160] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: Re: [radext] Fwd: New Version Notification for draft-winter-radext-fancyaccounting-01.txt X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 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, 12 Jul 2012 11:45:09 -0000 U3RlZmFuIC0gVGhpcyBpcyBhbiBpbmRpdmlkdWFsIHN1Ym1pc3Npb24gd2hpY2ggaXMgaW4gc29y dCBvZiBhIGNvbXBldGl0aW9uIHdpdGggZHJhZnQteWVoLXJhZGV4dC1leHQtdHJhZmZpYy1zdGF0 aXN0aWNzLiANCg0KV2VsY29tZSBkZWJhdGUgb3IgY29tcGV0aXRpb24gb24gdGhlIHNhbWUgdG9w aWM6IFJBRElVUyBBY2NvdW50aW5nIEV4dGVuc2lvbnMgZm9yIFRyYWZmaWMgU3RhdGlzdGljcy4g SG9wZSB0aGUgV0cgY291bGQgZmlndXJlIG91dCB0aGUgc29sdXRpb24gb24gdGhpcyB0b3BpYyBz b29uLiBUaGUgcHJvYmxlbSBsb29rcyBub3Qgc28gZGlmZmljdWx0Lg0KDQpTdGVmYW4gLSBUaGlz IGlzIHRoZSBjb25zZXF1ZW5jZSBvZiBMZWFmJ3MgZGVjaXNpb24gdG8gZmlyc3Qgc3VnZ2VzdCBu dW1lcm91cyBvdGhlciwgaW5mZXJpb3IsIGFwcHJvYWNoZXMsIGFuZCB0aGVuLCB3aGVuIHRoZXNl IHdlcmUgcmVwZWxsZWQsIGNvcHlpbmcgdGhlIGFwcHJvYWNoIGZyb20gbXkgLTAwIHdpdGggc2xp Z2h0bHkgZGlmZmVyZW50IHdvcmRpbmcgd2l0aCBoaXMgbmFtZSBhcyB0aGUgYXV0aG9yOyB1bnN1 cnByaXNpbmdseSwgdGhlIHR3byBkcmFmdHMgYXJlIG5vdyB2ZXJ5IGNsb3NlIHRvIGVhY2ggb3Ro ZXIuIA0KDQpIaXN0b3J5IG9uIHRoaXMgdG9waWMgaW4gbXkgbWVtb3J5IGZvciB5b3VyIGNvcnJl Y3Rpb246DQoxLiAgZHJhZnQteWVoLXJhZGV4dC1kdWFsLXN0YWNrLWFjY2Vzcy0wMCAoMjAxMS0z LTcpIHB1dCBmb3J3YXJkIHRoZSB0b3BpYyAmIDFzdCBzb2x1dGlvbiBvZiBSQURJVVMgQWNjb3Vu dGluZyBFeHRlbnNpb25zIGZvciBUcmFmZmljIFN0YXRpc3RpY3MgZm9yIGR1YWwgc3RhY2ssIGFu ZCBwcmVzZW50ZWQgaW4gSUVURjgwOw0KMi4gIEFmdGVyIElFVEY4MCBSYWRleHQgc2Vzc2lvbiwg ZHJhZnQtd2ludGVyLXJhZGV4dC1mYW5jeWFjY291bnRpbmctMDAgKDIwMTEtMy0zMSkgcHV0IGZv cndhcmQgdGhlIDJuZCBzb2x1dGlvbiBvZiBUTFYgd2l0aCBleHRlbmRlZC10eXBlIHNwYWNlOw0K My4gIGRyYWZ0LXllaC1yYWRleHQtZHVhbC1zdGFjay1hY2Nlc3MtMDIgZXhwaXJlZCBpbiAyMDEx LTA5LTMwDQo0LiAgZHJhZnQtd2ludGVyLXJhZGV4dC1mYW5jeWFjY291bnRpbmctMDAgZXhwaXJl ZCBpbiAyMDExLTEwLTAyDQo1LiAgVGhlIElFVEY4MiBwcmVzZW50YXRpb24gKGh0dHA6Ly93d3cu aWV0Zi5vcmcvcHJvY2VlZGluZ3MvODIvc2xpZGVzL3JhZGV4dC0yLnBkZiApIHdpdGggZHJhZnQt eWVoLXJhZGV4dC1leHQtdHJhZmZpYy1zdGF0aXN0aWNzLTAxIHJlLXRyaWdnZXJlZCB0aGUgZGlz Y3Vzc2lvbiBvbiB0aGUgYXR0cmlidXRlIGRlc2lnbiBvZiBBY2N0LVRyYWZmaWMtU3RhdGlzdGlj czsNCjYuICBBZnRlciBnb3QgdGhlIGhpbnQgaW4gdGhlIG1lZXRpbmcgbWludXRlcyBvZiBSYWRl eHQgSUVURjgyIChodHRwOi8vd3d3LmlldGYub3JnL21haWwtYXJjaGl2ZS93ZWIvcmFkZXh0L2N1 cnJlbnQvbXNnMDc0ODkuaHRtbCApLCBJIGFza2VkIGZvciB0aGUgY29vcGVyYXRpb24gd2l0aCBT dGVmYW4gb24gdGhpcyB0b3BpYyBzZXZlcmFsIHRpbWVzLCBidXQgaXQgbG9va3MgdG8gYnVtcDsN CjcuICBBZnRlciB0aGUgZGlzY3Vzc2lvbiBvbiB0aGUgbWFpbGluZyBsaXN0IG9mIFJhZGV4dCwg ZHJhZnQteWVoLXJhZGV4dC1leHQtdHJhZmZpYy1zdGF0aXN0aWNzLTAyIGFkb3B0ZWQgdGhlIGRh dGUgdHlwZSBvZiBuZXN0aW5nLVRMVjsNCjguICBBcm91bmQgbW9yZSB0aGFuIDEgd2VlayBiZWZv cmUgSSBzdWJtaXR0ZWQgZHJhZnQteWVoLXJhZGV4dC1leHQtdHJhZmZpYy1zdGF0aXN0aWNzLTAz LCBJIGFza2VkIFN0ZWZhbiBmb3IgaGlzIHJldmlzaW9uIGFuZCBjb29wZXJhdGlvbiBvbiBteSBk cmFmdCBhZ2FpbiwgYnV0IGZhaWxlZC4NCg0KDQpTdGVmYW4gLSBJIGJlbGlldmUgbXkgZHJhZnQg aXMgbW9yZSB0aG9yb3VnaCBhbmQgdGhvdWdodC1vdXQgaW4gbWFueSBhc3BlY3RzLiBUaGUgb25s eSBkaWZmZXJlbmNlIGlzIHRoYXQgaGlzIGRyYWZ0IGhhcyBhbiBpbnRlZ2VyIGVudW1lcmF0b3Ig Zm9yIHRyYWZmaWMgY2xhc3Nlcywgd2hpbGUgbXkgZHJhZnQgdXNlcyBhIHN0cmluZy4gDQoNClRo ZSBhYm92ZSAyIHN0YXRlbWVudHMgc291bmRzIGNvbnRyYWRpY3RvcnkuDQoNClN0ZWZhbiAtIFRo ZSBzdHJpbmcgY2FuIGRvIHRoZSBzYW1lIHdlbGwtZGVmaW5lZCBlbnVtZXJhdGlvbiBvZiBrbm93 biB0cmFmZmljIGNsYXNzZXMgdGhhdCB0aGUgaW50ZWdlciBjYW4gYWxzbyBkbywgYW5kIG1vcmUu DQoNClRoaXMgc291bmRzIHNvbWV0aGluZyByZWFsIG9uIHRoZSBhc3BlY3Qgb2YgdGVjaG5vbG9n eSBvciBSYWRpdXMgYXR0cmlidXRlIGRlc2lnbiwgd2hpY2ggYXNrcyBmb3IgdGhlIGRpc2N1c3Np b24gd2l0aGluIHRoZSBXRy4NCg0KDQpCZXN0IFJlZ2FyZHMsDQpMZWFmDQoNCg0KLS0tLS1Pcmln aW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IHJhZGV4dC1ib3VuY2VzQGlldGYub3JnIFttYWlsdG86 cmFkZXh0LWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBTdGVmYW4gV2ludGVyDQpTZW50 OiBUaHVyc2RheSwgSnVseSAxMiwgMjAxMiA0OjIwIFBNDQpUbzogcmFkZXh0QGlldGYub3JnDQpT dWJqZWN0OiBbcmFkZXh0XSBGd2Q6IE5ldyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3IgZHJhZnQt d2ludGVyLXJhZGV4dC1mYW5jeWFjY291bnRpbmctMDEudHh0DQoNCkhlbGxvLA0KDQpzaW5jZSB0 aGUgaW50ZXJlc3Qgb24gdGhlIHRvcGljIG9mIFJBRElVUyBBY2NvdW50aW5nIGZvciBzdWJzZXRz IG9mIHRoZSB0b3RhbCB0cmFmZmljIGhhcyByaXNlbiBhZ2FpbiwgSSBoYXZlIHJldml2ZWQgbXkg b2xkLCBleHBpcmVkIC0wMCB2ZXJzaW9uIG9mICJmYW5jeWFjY291bnRpbmciLiBUaGUgbWFqb3Ig Y2hhbmdlIHRvIC0wMCBpcyB0aGF0IEkgZHJvcCB0aGUgZW51bWVyYXRlZCBpbnRlZ2VyIGFzIGEg bWVhbnMgdG8gZXhwcmVzcyB3aGljaCB0cmFmZmljIGlzIGNvdW50ZWQsIGFuZCB1c2Ugb25seSB0 aGUgc3RyaW5nIHR5cGUgaW5zdGVhZC4NCg0KUmVhbGlzaW5nIHRoYXQgYSBrbm93biB2b2NhYnVs YXJ5IG9mIHRyYWZmaWMgY2xhc3NlcyBpcyB1c2VmdWwgZm9yIGludGVyLW9wIGJldHdlZW4gSVNQ cywgSSBpbnRyb2R1Y2VkIGFuIC0gb3B0aW9uYWwgLSBmaXhlZCBzeW50YXggZm9yIHNwZWNpZmlj IGFjY291bnRpbmcgdHJhZmZpYyBjbGFzc2VzIGJ5IHVzaW5nIFVSTnMuIEFtb25nIHRob3NlIGlz LCBvZiBjb3Vyc2UsIElQdjYsIGFzIHRoaXMgd2FzIHRoZSBvcmlnaW5hbCB0cmlnZ2VyIGZvciB0 aGUgYWNjb3VudGluZyB0cmFmZmljIGNsYXNzIGRpc2N1c3Npb24uDQoNClRoZSBhZHZhbnRhZ2Ug b2YgdGhlIFVSTi9mcmVldGV4dCBtb2RlbCBpcyB0aGF0IGl0IGNhbiBiZSBleHBhbmRlZCBhcmJp dHJhcmlseSBhbmQgeWV0IGhhdmUgYSBkZWZpbmVkIG1lYW5pbmc7IHdoaWxlIHN0aWxsIGFsbG93 aW5nIGEgbG9jYWwgYWRtaW4gdG8gY291bnQgIndoYXRldmVyIiBieSBjaG9vc2luZyBub3QgdG8g dXNlIGEgVVJOLiBJIHdvdWxkIGxpa2UgdG8gdGhhbmsgS2xhYXMgV2llcmVuZ2EgZm9yIGhpcyBp bnNwaXJhdGlvbiBpbiB0aGF0IHJlZ2FyZCENCg0KVGhlIG90aGVyIGNoYW5nZXMgYXJlIGNsZWFu dXBzIChtb3ZlIG9mIEludGVnZXI2NCB0byByYWRpdXMtZXh0ZW5zaW9ucykgYW5kIHRpZ2h0ZXIg c2VtZW5hdGljIHJlcXVpcmVtZW50cyBvZiB3aGVuIHRvIHNlbmQgd2hhdDsgaW5jbHVkaW5nIGEg d2F5IHRvIGV4cHJlc3Mgd2hpY2ggYnl0ZXMgZXhhY3RseSB0byBjb3VudCAtIGEgc3VnZ2VzdGlv biBJIGdvdCBzb21lIDIgeWVhcnMgYWdvIHdoZW4gZGlzY3Vzc2luZyAtMDAuDQoNClRoaXMgaXMg YW4gaW5kaXZpZHVhbCBzdWJtaXNzaW9uIHdoaWNoIGlzIGluIHNvcnQgb2YgYSBjb21wZXRpdGlv biB3aXRoIGRyYWZ0LXllaC1yYWRleHQtZXh0LXRyYWZmaWMtc3RhdGlzdGljcy4gVGhpcyBpcyB0 aGUgY29uc2VxdWVuY2Ugb2YgTGVhZidzIGRlY2lzaW9uIHRvIGZpcnN0IHN1Z2dlc3QgbnVtZXJv dXMgb3RoZXIsIGluZmVyaW9yLCBhcHByb2FjaGVzLCBhbmQgdGhlbiwgd2hlbiB0aGVzZSB3ZXJl IHJlcGVsbGVkLCBjb3B5aW5nIHRoZSBhcHByb2FjaCBmcm9tIG15IC0wMCB3aXRoIHNsaWdodGx5 IGRpZmZlcmVudCB3b3JkaW5nIHdpdGggaGlzIG5hbWUgYXMgdGhlIGF1dGhvcjsgdW5zdXJwcmlz aW5nbHksIHRoZSB0d28gZHJhZnRzIGFyZSBub3cgdmVyeSBjbG9zZSB0byBlYWNoIG90aGVyLiBJ IGJlbGlldmUgbXkgZHJhZnQgaXMgbW9yZSB0aG9yb3VnaCBhbmQgdGhvdWdodC1vdXQgaW4gbWFu eSBhc3BlY3RzLiBUaGUgb25seSBkaWZmZXJlbmNlIGlzIHRoYXQgaGlzIGRyYWZ0IGhhcyBhbiBp bnRlZ2VyIGVudW1lcmF0b3IgZm9yIHRyYWZmaWMgY2xhc3Nlcywgd2hpbGUgbXkgZHJhZnQgdXNl cyBhIHN0cmluZy4gVGhlIHN0cmluZyBjYW4gZG8gdGhlIHNhbWUgd2VsbC1kZWZpbmVkIGVudW1l cmF0aW9uIG9mIGtub3duIHRyYWZmaWMgY2xhc3NlcyB0aGF0IHRoZSBpbnRlZ2VyIGNhbiBhbHNv IGRvLCBhbmQgbW9yZS4NCg0KSWYgdGhlIHJlLWNoYXJ0ZXIgd2l0aCBhbiBleHBsaWNpdCBtZW50 aW9uIG9mICJSQURJVVMgQWNjb3VudGluZyBFeHRlbnNpb25zIGZvciBUcmFmZmljIFN0YXRpc3Rp Y3MiIGdldHMgYWRvcHRlZCwgSSB3b3VsZCBsaWtlIHRvIHN1Z2dlc3QgYWRvcHRpbmcgbXkgZHJh ZnQgZm9yIHRoYXQgdG9waWMuDQoNCkdyZWV0aW5ncywNCg0KU3RlZmFuIFdpbnRlcg0KDQoNCi0t LS0tLS0tIE9yaWdpbmFsIE1lc3NhZ2UgLS0tLS0tLS0NClN1YmplY3Q6IE5ldyBWZXJzaW9uIE5v dGlmaWNhdGlvbiBmb3INCmRyYWZ0LXdpbnRlci1yYWRleHQtZmFuY3lhY2NvdW50aW5nLTAxLnR4 dA0KRGF0ZTogVGh1LCAxMiBKdWwgMjAxMiAwMToxNjo1NCAtMDcwMA0KRnJvbTogaW50ZXJuZXQt ZHJhZnRzQGlldGYub3JnDQpUbzogc3RlZmFuLndpbnRlckByZXN0ZW5hLmx1DQoNCg0KQSBuZXcg dmVyc2lvbiBvZiBJLUQsIGRyYWZ0LXdpbnRlci1yYWRleHQtZmFuY3lhY2NvdW50aW5nLTAxLnR4 dA0KaGFzIGJlZW4gc3VjY2Vzc2Z1bGx5IHN1Ym1pdHRlZCBieSBTdGVmYW4gV2ludGVyIGFuZCBw b3N0ZWQgdG8gdGhlIElFVEYgcmVwb3NpdG9yeS4NCg0KRmlsZW5hbWU6CSBkcmFmdC13aW50ZXIt cmFkZXh0LWZhbmN5YWNjb3VudGluZw0KUmV2aXNpb246CSAwMQ0KVGl0bGU6CQkgUkFESVVTIEFj Y291bnRpbmcgZm9yIHRyYWZmaWMgY2xhc3Nlcw0KQ3JlYXRpb24gZGF0ZToJIDIwMTItMDctMTIN CldHIElEOgkJIEluZGl2aWR1YWwgU3VibWlzc2lvbg0KTnVtYmVyIG9mIHBhZ2VzOiA5DQpVUkw6 DQpodHRwOi8vd3d3LmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy9kcmFmdC13aW50ZXItcmFkZXh0 LWZhbmN5YWNjb3VudGluZy0wMS50eHQNClN0YXR1czoNCmh0dHA6Ly9kYXRhdHJhY2tlci5pZXRm Lm9yZy9kb2MvZHJhZnQtd2ludGVyLXJhZGV4dC1mYW5jeWFjY291bnRpbmcNCkh0bWxpemVkOg0K aHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtd2ludGVyLXJhZGV4dC1mYW5jeWFjY291 bnRpbmctMDENCkRpZmY6DQpodHRwOi8vdG9vbHMuaWV0Zi5vcmcvcmZjZGlmZj91cmwyPWRyYWZ0 LXdpbnRlci1yYWRleHQtZmFuY3lhY2NvdW50aW5nLTAxDQoNCkFic3RyYWN0Og0KICAgVGhpcyBk b2N1bWVudCBzcGVjaWZpZXMgbmV3IGF0dHJpYnV0ZXMgZm9yIFJBRElVUyBBY2NvdW50aW5nIHRv DQogICBlbmFibGUgTkFTIHJlcG9ydGluZyBvZiBzdWJzZXRzIG9mIHRoZSB0b3RhbCB0cmFmZmlj IGluIGEgdXNlcg0KICAgc2Vzc2lvbi4NCg0KDQoNCg0KDQpUaGUgSUVURiBTZWNyZXRhcmlhdA0K DQoNCg0K From radext-bounces@ietf.org Thu Jul 12 04:45:11 2012 Return-Path: X-Original-To: radext-archive-IeZ9sae2@lists.ietf.org Delivered-To: ietfarch-radext-archive-IeZ9sae2@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1F0C921F8811; Thu, 12 Jul 2012 04:45:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1342093511; bh=VoNY7wjXvA+nBhc1QVgWlezVJRs1FmYp7Zzbm5/o7ck=; h=From:To:Date:Message-ID:References:In-Reply-To:MIME-Version: Subject:List-Id:List-Unsubscribe:List-Archive:List-Post:List-Help: List-Subscribe:Content-Type:Content-Transfer-Encoding:Sender; b=HqekQut7qZ/fbCI9BZlBVza6S/QO74/ktILA+ZSPI0r9wx2/Ih5L+bc2y258z9Mzk VeOBPUSMedOXhA5SmkGZo6XpmOVK36NRmKhfnZV7c71gjT8k2aiLgBIkRG7yj01txz EqNdfNaqVl8lP1FZ76TITywnY6PhjlAnE96RAkEU= 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 904DD21F8811 for ; Thu, 12 Jul 2012 04:45:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.252 X-Spam-Level: X-Spam-Status: No, score=-6.252 tagged_above=-999 required=5 tests=[AWL=0.347, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dDjUbTedUCc4 for ; Thu, 12 Jul 2012 04:45:08 -0700 (PDT) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id A63BE21F8615 for ; Thu, 12 Jul 2012 04:45:08 -0700 (PDT) Received: from 172.18.9.243 (EHLO dfweml202-edg.china.huawei.com) ([172.18.9.243]) by dfwrg02-dlp.huawei.com (MOS 4.2.3-GA FastPath) with ESMTP id AHR66810; Thu, 12 Jul 2012 07:45:41 -0400 (EDT) Received: from DFWEML404-HUB.china.huawei.com (10.193.5.203) by dfweml202-edg.china.huawei.com (172.18.9.108) with Microsoft SMTP Server (TLS) id 14.1.323.3; Thu, 12 Jul 2012 04:43:04 -0700 Received: from SZXEML440-HUB.china.huawei.com (10.72.61.75) by dfweml404-hub.china.huawei.com (10.193.5.203) with Microsoft SMTP Server (TLS) id 14.1.323.3; Thu, 12 Jul 2012 04:43:03 -0700 Received: from SZXEML510-MBS.china.huawei.com ([169.254.8.103]) by SZXEML440-HUB.china.huawei.com ([10.72.61.75]) with mapi id 14.01.0323.003; Thu, 12 Jul 2012 19:42:58 +0800 From: Leaf yeh To: "radext@ietf.org" Thread-Topic: [radext] Fwd: New Version Notification for draft-winter-radext-fancyaccounting-01.txt Thread-Index: AQHNYAcbajsyHVA0AESdZldyuv+snJclcgFg Date: Thu, 12 Jul 2012 11:42:56 +0000 Message-ID: References: <20120712081654.17566.87131.idtracker@ietfa.amsl.com> <4FFE8893.30402@restena.lu> In-Reply-To: <4FFE8893.30402@restena.lu> Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.66.83.160] MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: Re: [radext] Fwd: New Version Notification for draft-winter-radext-fancyaccounting-01.txt X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: radext-bounces@ietf.org Errors-To: radext-bounces@ietf.org Stefan - This is an individual submission which is in sort of a competition with draft-yeh-radext-ext-traffic-statistics. Welcome debate or competition on the same topic: RADIUS Accounting Extensions for Traffic Statistics. Hope the WG could figure out the solution on this topic soon. The problem looks not so difficult. Stefan - This is the consequence of Leaf's decision to first suggest numerous other, inferior, approaches, and then, when these were repelled, copying the approach from my -00 with slightly different wording with his name as the author; unsurprisingly, the two drafts are now very close to each other. History on this topic in my memory for your correction: 1. draft-yeh-radext-dual-stack-access-00 (2011-3-7) put forward the topic & 1st solution of RADIUS Accounting Extensions for Traffic Statistics for dual stack, and presented in IETF80; 2. After IETF80 Radext session, draft-winter-radext-fancyaccounting-00 (2011-3-31) put forward the 2nd solution of TLV with extended-type space; 3. draft-yeh-radext-dual-stack-access-02 expired in 2011-09-30 4. draft-winter-radext-fancyaccounting-00 expired in 2011-10-02 5. The IETF82 presentation (http://www.ietf.org/proceedings/82/slides/radext-2.pdf ) with draft-yeh-radext-ext-traffic-statistics-01 re-triggered the discussion on the attribute design of Acct-Traffic-Statistics; 6. After got the hint in the meeting minutes of Radext IETF82 (http://www.ietf.org/mail-archive/web/radext/current/msg07489.html ), I asked for the cooperation with Stefan on this topic several times, but it looks to bump; 7. After the discussion on the mailing list of Radext, draft-yeh-radext-ext-traffic-statistics-02 adopted the date type of nesting-TLV; 8. Around more than 1 week before I submitted draft-yeh-radext-ext-traffic-statistics-03, I asked Stefan for his revision and cooperation on my draft again, but failed. Stefan - I believe my draft is more thorough and thought-out in many aspects. The only difference is that his draft has an integer enumerator for traffic classes, while my draft uses a string. The above 2 statements sounds contradictory. Stefan - The string can do the same well-defined enumeration of known traffic classes that the integer can also do, and more. This sounds something real on the aspect of technology or Radius attribute design, which asks for the discussion within the WG. Best Regards, Leaf -----Original Message----- From: radext-bounces@ietf.org [mailto:radext-bounces@ietf.org] On Behalf Of Stefan Winter Sent: Thursday, July 12, 2012 4:20 PM To: radext@ietf.org Subject: [radext] Fwd: New Version Notification for draft-winter-radext-fancyaccounting-01.txt Hello, since the interest on the topic of RADIUS Accounting for subsets of the total traffic has risen again, I have revived my old, expired -00 version of "fancyaccounting". The major change to -00 is that I drop the enumerated integer as a means to express which traffic is counted, and use only the string type instead. Realising that a known vocabulary of traffic classes is useful for inter-op between ISPs, I introduced an - optional - fixed syntax for specific accounting traffic classes by using URNs. Among those is, of course, IPv6, as this was the original trigger for the accounting traffic class discussion. The advantage of the URN/freetext model is that it can be expanded arbitrarily and yet have a defined meaning; while still allowing a local admin to count "whatever" by choosing not to use a URN. I would like to thank Klaas Wierenga for his inspiration in that regard! The other changes are cleanups (move of Integer64 to radius-extensions) and tighter semenatic requirements of when to send what; including a way to express which bytes exactly to count - a suggestion I got some 2 years ago when discussing -00. This is an individual submission which is in sort of a competition with draft-yeh-radext-ext-traffic-statistics. This is the consequence of Leaf's decision to first suggest numerous other, inferior, approaches, and then, when these were repelled, copying the approach from my -00 with slightly different wording with his name as the author; unsurprisingly, the two drafts are now very close to each other. I believe my draft is more thorough and thought-out in many aspects. The only difference is that his draft has an integer enumerator for traffic classes, while my draft uses a string. The string can do the same well-defined enumeration of known traffic classes that the integer can also do, and more. If the re-charter with an explicit mention of "RADIUS Accounting Extensions for Traffic Statistics" gets adopted, I would like to suggest adopting my draft for that topic. Greetings, Stefan Winter -------- Original Message -------- Subject: New Version Notification for draft-winter-radext-fancyaccounting-01.txt Date: Thu, 12 Jul 2012 01:16:54 -0700 From: internet-drafts@ietf.org To: stefan.winter@restena.lu A new version of I-D, draft-winter-radext-fancyaccounting-01.txt has been successfully submitted by Stefan Winter and posted to the IETF repository. Filename: draft-winter-radext-fancyaccounting Revision: 01 Title: RADIUS Accounting for traffic classes Creation date: 2012-07-12 WG ID: Individual Submission Number of pages: 9 URL: http://www.ietf.org/internet-drafts/draft-winter-radext-fancyaccounting-01.txt Status: http://datatracker.ietf.org/doc/draft-winter-radext-fancyaccounting Htmlized: http://tools.ietf.org/html/draft-winter-radext-fancyaccounting-01 Diff: http://tools.ietf.org/rfcdiff?url2=draft-winter-radext-fancyaccounting-01 Abstract: This document specifies new attributes for RADIUS Accounting to enable NAS reporting of subsets of the total traffic in a user session. The IETF Secretariat _______________________________________________ radext mailing list radext@ietf.org https://www.ietf.org/mailman/listinfo/radext From radext-bounces@ietf.org Thu Jul 12 06:31:34 2012 Return-Path: X-Original-To: radext-archive-IeZ9sae2@lists.ietf.org Delivered-To: ietfarch-radext-archive-IeZ9sae2@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7B04C21F885E; Thu, 12 Jul 2012 06:31:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1342099894; bh=nqIxUzZwa3sVypfFZsovrge7yBq23hR4aJiUDqbiEto=; h=Message-ID:Date:From:MIME-Version:To:References:In-Reply-To: Subject:List-Id:List-Unsubscribe:List-Archive:List-Post:List-Help: List-Subscribe:Content-Type:Sender; b=ZuZxwbihVFy1s+wcV2FytwbmAgWLBMqdnuv86/8GZh7LKiVDdVfz8vZ9iqakogVPI RbayS5aGyCHIObFaLzPBYjxuWPbmnCfZXg95LnlkIkDOL66tBo2MrkI+Bz+5Yr1Aid Z/VXMma8WCR6l8vUEHb0RH/dMuFeQhO9SZIgNY1k= 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 122E821F885E for ; Thu, 12 Jul 2012 06:31:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RRwLGX2M84M4 for ; Thu, 12 Jul 2012 06:31:32 -0700 (PDT) Received: from smtprelay.restena.lu (smtprelay.restena.lu [IPv6:2001:a18:1::62]) by ietfa.amsl.com (Postfix) with ESMTP id C873221F884D for ; Thu, 12 Jul 2012 06:31:31 -0700 (PDT) Received: from smtprelay.restena.lu (localhost [127.0.0.1]) by smtprelay.restena.lu (Postfix) with ESMTP id 8EAAB10580 for ; Thu, 12 Jul 2012 15:32:04 +0200 (CEST) Received: from [IPv6:2001:a18:1:8:200e:4936:916a:e474] (unknown [IPv6:2001:a18:1:8:200e:4936:916a:e474]) by smtprelay.restena.lu (Postfix) with ESMTPS id 764FE1057E for ; Thu, 12 Jul 2012 15:32:04 +0200 (CEST) Message-ID: <4FFED1D3.7060706@restena.lu> Date: Thu, 12 Jul 2012 15:32:03 +0200 From: Stefan Winter User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:13.0) Gecko/20120601 Thunderbird/13.0 MIME-Version: 1.0 To: radext@ietf.org References: <20120712081654.17566.87131.idtracker@ietfa.amsl.com> <4FFE8893.30402@restena.lu> In-Reply-To: X-Enigmail-Version: 1.4.2 X-Virus-Scanned: ClamAV Subject: Re: [radext] Fwd: New Version Notification for draft-winter-radext-fancyaccounting-01.txt X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============4090034839495912487==" Sender: radext-bounces@ietf.org Errors-To: radext-bounces@ietf.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --===============4090034839495912487== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigFDB8AB4B508779E09BC775B0" This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigFDB8AB4B508779E09BC775B0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable > Welcome debate or competition on the same topic: RADIUS Accounting Exte= nsions for Traffic Statistics. Hope the WG could figure out the solution = on this topic soon. The problem looks not so difficult. Indeed. The main question seems to be: should the format be extensible to support arbitrary accounting needs? Or should it be limited to a few fixed values, centrally managed by the IETF? I argue for the first, you for the second. > Stefan - This is the consequence of Leaf's decision to first suggest nu= merous other, inferior, approaches, and then, when these were repelled, c= opying the approach from my -00 with slightly different wording with his = name as the author; unsurprisingly, the two drafts are now very close to = each other.=20 >=20 > History on this topic in my memory for your correction: > 1. draft-yeh-radext-dual-stack-access-00 (2011-3-7) put forward the to= pic & 1st solution of RADIUS Accounting Extensions for Traffic Statistics= for dual stack, and presented in IETF80; > 2. After IETF80 Radext session, draft-winter-radext-fancyaccounting-00= (2011-3-31) put forward the 2nd solution of TLV with extended-type space= ; > 3. draft-yeh-radext-dual-stack-access-02 expired in 2011-09-30 > 4. draft-winter-radext-fancyaccounting-00 expired in 2011-10-02 > 5. The IETF82 presentation (http://www.ietf.org/proceedings/82/slides/= radext-2.pdf ) with draft-yeh-radext-ext-traffic-statistics-01 re-trigger= ed the discussion on the attribute design of Acct-Traffic-Statistics; > 6. After got the hint in the meeting minutes of Radext IETF82 (http://= www.ietf.org/mail-archive/web/radext/current/msg07489.html ), I asked for= the cooperation with Stefan on this topic several times, but it looks to= bump; > 7. After the discussion on the mailing list of Radext, draft-yeh-radex= t-ext-traffic-statistics-02 adopted the date type of nesting-TLV; > 8. Around more than 1 week before I submitted draft-yeh-radext-ext-tra= ffic-statistics-03, I asked Stefan for his revision and cooperation on my= draft again, but failed. Thanks for this timeline - it perfectly proves my point. The TLV structure was first introduced in your point 2 by me. It reappeared in point 7. - This time, the author was you, while the concept was the same.= The fact that you repeatedly put up slides in the time between 2 and 7 which were calling the TLV approach "design 3" does not mean it was your idea and design. The draft, idea and structure were there long before you did that. In that light, isn't it understandable that I don't fancy becoming a co-author of "your" draft with you as an editor? If that's not a sufficient justification for me being upset, here's another one: following IETF80, I created fancyaccounting-00 because I was trying to *help* you - you presented a good problem statement, and I had an easy solution in my mind. And yet, when I uploaded it *and* got positive feedback from the WG, you indicated that you are not interested in the topic in a subsequent meeting, making it all stall. That is not ni= ce. That's my only reply on that topic. Spending time uselessly arguing on off-topic aspects doesn't contribute to a solution. > Stefan - I believe my draft is more thorough and thought-out in many as= pects. The only difference is that his draft has an integer enumerator fo= r traffic classes, while my draft uses a string.=20 >=20 > The above 2 statements sounds contradictory. Not at all. My previous mail contained reasons and argument why I did it, and it enumerated why it is a good idea. Your reply conveniently cuts out these, and doesn't present counter-arguments against them. You just state you don't like it. Too bad= =2E > Stefan - The string can do the same well-defined enumeration of known t= raffic classes that the integer can also do, and more. >=20 > This sounds something real on the aspect of technology or Radius attrib= ute design, which asks for the discussion within the WG. Indeed. Stefan Winter >=20 >=20 > Best Regards, > Leaf >=20 >=20 > -----Original Message----- > From: radext-bounces@ietf.org [mailto:radext-bounces@ietf.org] On Behal= f Of Stefan Winter > Sent: Thursday, July 12, 2012 4:20 PM > To: radext@ietf.org > Subject: [radext] Fwd: New Version Notification for draft-winter-radext= -fancyaccounting-01.txt >=20 > Hello, >=20 > since the interest on the topic of RADIUS Accounting for subsets of the= total traffic has risen again, I have revived my old, expired -00 versio= n of "fancyaccounting". The major change to -00 is that I drop the enumer= ated integer as a means to express which traffic is counted, and use only= the string type instead. >=20 > Realising that a known vocabulary of traffic classes is useful for inte= r-op between ISPs, I introduced an - optional - fixed syntax for specific= accounting traffic classes by using URNs. Among those is, of course, IPv= 6, as this was the original trigger for the accounting traffic class disc= ussion. >=20 > The advantage of the URN/freetext model is that it can be expanded arbi= trarily and yet have a defined meaning; while still allowing a local admi= n to count "whatever" by choosing not to use a URN. I would like to thank= Klaas Wierenga for his inspiration in that regard! >=20 > The other changes are cleanups (move of Integer64 to radius-extensions)= and tighter semenatic requirements of when to send what; including a way= to express which bytes exactly to count - a suggestion I got some 2 year= s ago when discussing -00. >=20 > This is an individual submission which is in sort of a competition with= draft-yeh-radext-ext-traffic-statistics. This is the consequence of Leaf= 's decision to first suggest numerous other, inferior, approaches, and th= en, when these were repelled, copying the approach from my -00 with sligh= tly different wording with his name as the author; unsurprisingly, the tw= o drafts are now very close to each other. I believe my draft is more tho= rough and thought-out in many aspects. The only difference is that his dr= aft has an integer enumerator for traffic classes, while my draft uses a = string. The string can do the same well-defined enumeration of known traf= fic classes that the integer can also do, and more. >=20 > If the re-charter with an explicit mention of "RADIUS Accounting Extens= ions for Traffic Statistics" gets adopted, I would like to suggest adopti= ng my draft for that topic. >=20 > Greetings, >=20 > Stefan Winter >=20 >=20 > -------- Original Message -------- > Subject: New Version Notification for > draft-winter-radext-fancyaccounting-01.txt > Date: Thu, 12 Jul 2012 01:16:54 -0700 > From: internet-drafts@ietf.org > To: stefan.winter@restena.lu >=20 >=20 > A new version of I-D, draft-winter-radext-fancyaccounting-01.txt > has been successfully submitted by Stefan Winter and posted to the IETF= repository. >=20 > Filename: draft-winter-radext-fancyaccounting > Revision: 01 > Title: RADIUS Accounting for traffic classes > Creation date: 2012-07-12 > WG ID: Individual Submission > Number of pages: 9 > URL: > http://www.ietf.org/internet-drafts/draft-winter-radext-fancyaccounting= -01.txt > Status: > http://datatracker.ietf.org/doc/draft-winter-radext-fancyaccounting > Htmlized: > http://tools.ietf.org/html/draft-winter-radext-fancyaccounting-01 > Diff: > http://tools.ietf.org/rfcdiff?url2=3Ddraft-winter-radext-fancyaccountin= g-01 >=20 > Abstract: > This document specifies new attributes for RADIUS Accounting to > enable NAS reporting of subsets of the total traffic in a user > session. >=20 >=20 >=20 >=20 >=20 > The IETF Secretariat >=20 >=20 >=20 > _______________________________________________ > radext mailing list > radext@ietf.org > https://www.ietf.org/mailman/listinfo/radext >=20 --=20 Stefan WINTER Ingenieur de Recherche Fondation RESTENA - R=E9seau T=E9l=E9informatique de l'Education National= e et de la Recherche 6, rue Richard Coudenhove-Kalergi L-1359 Luxembourg Tel: +352 424409 1 Fax: +352 422473 --------------enigFDB8AB4B508779E09BC775B0 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.0.18 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk/+0dQACgkQ+jm90f8eFWbC7gCfRPE/pesoZZRSXrVMChx4Cv+R ER0An2n4hMyVJIT/u3tiDBYeTWfdvsGX =Cs2k -----END PGP SIGNATURE----- --------------enigFDB8AB4B508779E09BC775B0-- --===============4090034839495912487== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ radext mailing list radext@ietf.org https://www.ietf.org/mailman/listinfo/radext --===============4090034839495912487==-- From stefan.winter@restena.lu Thu Jul 12 06:31:33 2012 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 122E821F885E for ; Thu, 12 Jul 2012 06:31:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RRwLGX2M84M4 for ; Thu, 12 Jul 2012 06:31:32 -0700 (PDT) Received: from smtprelay.restena.lu (smtprelay.restena.lu [IPv6:2001:a18:1::62]) by ietfa.amsl.com (Postfix) with ESMTP id C873221F884D for ; Thu, 12 Jul 2012 06:31:31 -0700 (PDT) Received: from smtprelay.restena.lu (localhost [127.0.0.1]) by smtprelay.restena.lu (Postfix) with ESMTP id 8EAAB10580 for ; Thu, 12 Jul 2012 15:32:04 +0200 (CEST) Received: from [IPv6:2001:a18:1:8:200e:4936:916a:e474] (unknown [IPv6:2001:a18:1:8:200e:4936:916a:e474]) by smtprelay.restena.lu (Postfix) with ESMTPS id 764FE1057E for ; Thu, 12 Jul 2012 15:32:04 +0200 (CEST) Message-ID: <4FFED1D3.7060706@restena.lu> Date: Thu, 12 Jul 2012 15:32:03 +0200 From: Stefan Winter User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:13.0) Gecko/20120601 Thunderbird/13.0 MIME-Version: 1.0 To: radext@ietf.org References: <20120712081654.17566.87131.idtracker@ietfa.amsl.com> <4FFE8893.30402@restena.lu> In-Reply-To: X-Enigmail-Version: 1.4.2 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigFDB8AB4B508779E09BC775B0" X-Virus-Scanned: ClamAV Subject: Re: [radext] Fwd: New Version Notification for draft-winter-radext-fancyaccounting-01.txt X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 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, 12 Jul 2012 13:31:33 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigFDB8AB4B508779E09BC775B0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable > Welcome debate or competition on the same topic: RADIUS Accounting Exte= nsions for Traffic Statistics. Hope the WG could figure out the solution = on this topic soon. The problem looks not so difficult. Indeed. The main question seems to be: should the format be extensible to support arbitrary accounting needs? Or should it be limited to a few fixed values, centrally managed by the IETF? I argue for the first, you for the second. > Stefan - This is the consequence of Leaf's decision to first suggest nu= merous other, inferior, approaches, and then, when these were repelled, c= opying the approach from my -00 with slightly different wording with his = name as the author; unsurprisingly, the two drafts are now very close to = each other.=20 >=20 > History on this topic in my memory for your correction: > 1. draft-yeh-radext-dual-stack-access-00 (2011-3-7) put forward the to= pic & 1st solution of RADIUS Accounting Extensions for Traffic Statistics= for dual stack, and presented in IETF80; > 2. After IETF80 Radext session, draft-winter-radext-fancyaccounting-00= (2011-3-31) put forward the 2nd solution of TLV with extended-type space= ; > 3. draft-yeh-radext-dual-stack-access-02 expired in 2011-09-30 > 4. draft-winter-radext-fancyaccounting-00 expired in 2011-10-02 > 5. The IETF82 presentation (http://www.ietf.org/proceedings/82/slides/= radext-2.pdf ) with draft-yeh-radext-ext-traffic-statistics-01 re-trigger= ed the discussion on the attribute design of Acct-Traffic-Statistics; > 6. After got the hint in the meeting minutes of Radext IETF82 (http://= www.ietf.org/mail-archive/web/radext/current/msg07489.html ), I asked for= the cooperation with Stefan on this topic several times, but it looks to= bump; > 7. After the discussion on the mailing list of Radext, draft-yeh-radex= t-ext-traffic-statistics-02 adopted the date type of nesting-TLV; > 8. Around more than 1 week before I submitted draft-yeh-radext-ext-tra= ffic-statistics-03, I asked Stefan for his revision and cooperation on my= draft again, but failed. Thanks for this timeline - it perfectly proves my point. The TLV structure was first introduced in your point 2 by me. It reappeared in point 7. - This time, the author was you, while the concept was the same.= The fact that you repeatedly put up slides in the time between 2 and 7 which were calling the TLV approach "design 3" does not mean it was your idea and design. The draft, idea and structure were there long before you did that. In that light, isn't it understandable that I don't fancy becoming a co-author of "your" draft with you as an editor? If that's not a sufficient justification for me being upset, here's another one: following IETF80, I created fancyaccounting-00 because I was trying to *help* you - you presented a good problem statement, and I had an easy solution in my mind. And yet, when I uploaded it *and* got positive feedback from the WG, you indicated that you are not interested in the topic in a subsequent meeting, making it all stall. That is not ni= ce. That's my only reply on that topic. Spending time uselessly arguing on off-topic aspects doesn't contribute to a solution. > Stefan - I believe my draft is more thorough and thought-out in many as= pects. The only difference is that his draft has an integer enumerator fo= r traffic classes, while my draft uses a string.=20 >=20 > The above 2 statements sounds contradictory. Not at all. My previous mail contained reasons and argument why I did it, and it enumerated why it is a good idea. Your reply conveniently cuts out these, and doesn't present counter-arguments against them. You just state you don't like it. Too bad= =2E > Stefan - The string can do the same well-defined enumeration of known t= raffic classes that the integer can also do, and more. >=20 > This sounds something real on the aspect of technology or Radius attrib= ute design, which asks for the discussion within the WG. Indeed. Stefan Winter >=20 >=20 > Best Regards, > Leaf >=20 >=20 > -----Original Message----- > From: radext-bounces@ietf.org [mailto:radext-bounces@ietf.org] On Behal= f Of Stefan Winter > Sent: Thursday, July 12, 2012 4:20 PM > To: radext@ietf.org > Subject: [radext] Fwd: New Version Notification for draft-winter-radext= -fancyaccounting-01.txt >=20 > Hello, >=20 > since the interest on the topic of RADIUS Accounting for subsets of the= total traffic has risen again, I have revived my old, expired -00 versio= n of "fancyaccounting". The major change to -00 is that I drop the enumer= ated integer as a means to express which traffic is counted, and use only= the string type instead. >=20 > Realising that a known vocabulary of traffic classes is useful for inte= r-op between ISPs, I introduced an - optional - fixed syntax for specific= accounting traffic classes by using URNs. Among those is, of course, IPv= 6, as this was the original trigger for the accounting traffic class disc= ussion. >=20 > The advantage of the URN/freetext model is that it can be expanded arbi= trarily and yet have a defined meaning; while still allowing a local admi= n to count "whatever" by choosing not to use a URN. I would like to thank= Klaas Wierenga for his inspiration in that regard! >=20 > The other changes are cleanups (move of Integer64 to radius-extensions)= and tighter semenatic requirements of when to send what; including a way= to express which bytes exactly to count - a suggestion I got some 2 year= s ago when discussing -00. >=20 > This is an individual submission which is in sort of a competition with= draft-yeh-radext-ext-traffic-statistics. This is the consequence of Leaf= 's decision to first suggest numerous other, inferior, approaches, and th= en, when these were repelled, copying the approach from my -00 with sligh= tly different wording with his name as the author; unsurprisingly, the tw= o drafts are now very close to each other. I believe my draft is more tho= rough and thought-out in many aspects. The only difference is that his dr= aft has an integer enumerator for traffic classes, while my draft uses a = string. The string can do the same well-defined enumeration of known traf= fic classes that the integer can also do, and more. >=20 > If the re-charter with an explicit mention of "RADIUS Accounting Extens= ions for Traffic Statistics" gets adopted, I would like to suggest adopti= ng my draft for that topic. >=20 > Greetings, >=20 > Stefan Winter >=20 >=20 > -------- Original Message -------- > Subject: New Version Notification for > draft-winter-radext-fancyaccounting-01.txt > Date: Thu, 12 Jul 2012 01:16:54 -0700 > From: internet-drafts@ietf.org > To: stefan.winter@restena.lu >=20 >=20 > A new version of I-D, draft-winter-radext-fancyaccounting-01.txt > has been successfully submitted by Stefan Winter and posted to the IETF= repository. >=20 > Filename: draft-winter-radext-fancyaccounting > Revision: 01 > Title: RADIUS Accounting for traffic classes > Creation date: 2012-07-12 > WG ID: Individual Submission > Number of pages: 9 > URL: > http://www.ietf.org/internet-drafts/draft-winter-radext-fancyaccounting= -01.txt > Status: > http://datatracker.ietf.org/doc/draft-winter-radext-fancyaccounting > Htmlized: > http://tools.ietf.org/html/draft-winter-radext-fancyaccounting-01 > Diff: > http://tools.ietf.org/rfcdiff?url2=3Ddraft-winter-radext-fancyaccountin= g-01 >=20 > Abstract: > This document specifies new attributes for RADIUS Accounting to > enable NAS reporting of subsets of the total traffic in a user > session. >=20 >=20 >=20 >=20 >=20 > The IETF Secretariat >=20 >=20 >=20 > _______________________________________________ > radext mailing list > radext@ietf.org > https://www.ietf.org/mailman/listinfo/radext >=20 --=20 Stefan WINTER Ingenieur de Recherche Fondation RESTENA - R=E9seau T=E9l=E9informatique de l'Education National= e et de la Recherche 6, rue Richard Coudenhove-Kalergi L-1359 Luxembourg Tel: +352 424409 1 Fax: +352 422473 --------------enigFDB8AB4B508779E09BC775B0 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.0.18 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk/+0dQACgkQ+jm90f8eFWbC7gCfRPE/pesoZZRSXrVMChx4Cv+R ER0An2n4hMyVJIT/u3tiDBYeTWfdvsGX =Cs2k -----END PGP SIGNATURE----- --------------enigFDB8AB4B508779E09BC775B0-- From stefan.winter@restena.lu Thu Jul 12 06:49:24 2012 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 8152A21F86F0 for ; Thu, 12 Jul 2012 06:49:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4oCYSC1ZHCQ2 for ; Thu, 12 Jul 2012 06:49:24 -0700 (PDT) Received: from smtprelay.restena.lu (smtprelay.restena.lu [IPv6:2001:a18:1::62]) by ietfa.amsl.com (Postfix) with ESMTP id A54A321F86BD for ; Thu, 12 Jul 2012 06:49:23 -0700 (PDT) Received: from smtprelay.restena.lu (localhost [127.0.0.1]) by smtprelay.restena.lu (Postfix) with ESMTP id 9AE5410580; Thu, 12 Jul 2012 15:49:56 +0200 (CEST) Received: from [IPv6:2001:a18:1:8:200e:4936:916a:e474] (unknown [IPv6:2001:a18:1:8:200e:4936:916a:e474]) by smtprelay.restena.lu (Postfix) with ESMTPS id 3D7001057E; Thu, 12 Jul 2012 15:49:56 +0200 (CEST) Message-ID: <4FFED600.3000109@restena.lu> Date: Thu, 12 Jul 2012 15:49:52 +0200 From: Stefan Winter User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:13.0) Gecko/20120601 Thunderbird/13.0 MIME-Version: 1.0 To: Peter Deacon References: <20120712081654.17566.87131.idtracker@ietfa.amsl.com> <4FFE8893.30402@restena.lu> In-Reply-To: X-Enigmail-Version: 1.4.2 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigA75173B56D292791606E79AE" X-Virus-Scanned: ClamAV Cc: "radext@ietf.org" Subject: Re: [radext] Fwd: New Version Notification for draft-winter-radext-fancyaccounting-01.txt X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 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, 12 Jul 2012 13:49:24 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigA75173B56D292791606E79AE Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi, > I like the new accounting draft -- simple and flexible. Thanks :-) > Some thoughts.. >=20 > There might be cases where not all Packet and Octet information is know= n > or provided. For example counting bytes over a serial line or higher > layer where packet counts may no longer be known, applicable or accessi= ble. >=20 > Suggest changing 'exactly once' to zero or one for Packets and Octets > fields. That's a good point. I'll change the text accordingly. One Q about "no longer be known" - I don't know any usage patterns that would lead to a value getting "lost" during a session. A concern of mine was that a NAS might send a value in an Interim-Update, but then not report the same type of data in the Stop packet. I considered that a very bad thing, as it leaves the RADIUS server with the open question on what happened to this type of traffic since the last update. That's why I added text in the occurence table that requires once-sent values to be sent in the final Stop ticket, too. If values stop being known mid-session, is that then an unreasonable requirement? > If you can count it people are going to want to enforce it. Using > interim accounting and dynamic auth is a practical option however > leakage is unavoidable. >=20 > Perhaps a separate container group to signal limits via Access-Accept > enforced by NAS: >=20 > Limit-Traffic-Class > Limit-Traffic-Class-Name > Limit-Traffic-Class-Input-Octets > Limit-Traffic-Class-Output-Octets >=20 > 'd volunteer text if theres interest and this is not too much scope cre= ep. This part I'm not so comfortable with - at least in the scope of the current draft. I see Accounting as a one-way flow from the NAS to the RADIUS server to report about the current reality of a user session. Undoubtedly, being able to send Time or Data limits from the RADIUS server to the NAS is also useful, but it's a different topic IMHO, worth its own draft. However, if the WG thinks that this should be in the scope of this document, I'll be happy to add your text. Greetings, Stefan Winter >=20 > regards, > Peter --=20 Stefan WINTER Ingenieur de Recherche Fondation RESTENA - R=E9seau T=E9l=E9informatique de l'Education National= e et de la Recherche 6, rue Richard Coudenhove-Kalergi L-1359 Luxembourg Tel: +352 424409 1 Fax: +352 422473 --------------enigA75173B56D292791606E79AE 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.0.18 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk/+1gMACgkQ+jm90f8eFWarjgCeO6Yv9Yv26MWUA3u+N8GYuUBw W30An2hhyyiWh1zmxXxco8CbRNDTJvFX =K598 -----END PGP SIGNATURE----- --------------enigA75173B56D292791606E79AE-- From radext-bounces@ietf.org Thu Jul 12 06:49:25 2012 Return-Path: X-Original-To: radext-archive-IeZ9sae2@lists.ietf.org Delivered-To: ietfarch-radext-archive-IeZ9sae2@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D5BCA21F86EA; Thu, 12 Jul 2012 06:49:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1342100965; bh=QxMzCjztxxqqqklpSOg9reYwP/uTva9jbvOjqXvoB1I=; h=Message-ID:Date:From:MIME-Version:To:References:In-Reply-To:Cc: Subject:List-Id:List-Unsubscribe:List-Archive:List-Post:List-Help: List-Subscribe:Content-Type:Sender; b=jzxvlKt40uEyof1+8k9D/0iorFr1ykoC1T5THNj0p8IkqDpDtmNJRO9IwQFIqekaS aHCKwaHnrbN6pYz271Hx6Qv9Zv4TOL/1vhBVAesE9TaFcBvXlDh9HXPUlmMly3tiLi ow3DfwKoTh4rPASgGcGh7i2ucWF8Cx0mD4co2IIg= 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 8152A21F86F0 for ; Thu, 12 Jul 2012 06:49:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4oCYSC1ZHCQ2 for ; Thu, 12 Jul 2012 06:49:24 -0700 (PDT) Received: from smtprelay.restena.lu (smtprelay.restena.lu [IPv6:2001:a18:1::62]) by ietfa.amsl.com (Postfix) with ESMTP id A54A321F86BD for ; Thu, 12 Jul 2012 06:49:23 -0700 (PDT) Received: from smtprelay.restena.lu (localhost [127.0.0.1]) by smtprelay.restena.lu (Postfix) with ESMTP id 9AE5410580; Thu, 12 Jul 2012 15:49:56 +0200 (CEST) Received: from [IPv6:2001:a18:1:8:200e:4936:916a:e474] (unknown [IPv6:2001:a18:1:8:200e:4936:916a:e474]) by smtprelay.restena.lu (Postfix) with ESMTPS id 3D7001057E; Thu, 12 Jul 2012 15:49:56 +0200 (CEST) Message-ID: <4FFED600.3000109@restena.lu> Date: Thu, 12 Jul 2012 15:49:52 +0200 From: Stefan Winter User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:13.0) Gecko/20120601 Thunderbird/13.0 MIME-Version: 1.0 To: Peter Deacon References: <20120712081654.17566.87131.idtracker@ietfa.amsl.com> <4FFE8893.30402@restena.lu> In-Reply-To: X-Enigmail-Version: 1.4.2 X-Virus-Scanned: ClamAV Cc: "radext@ietf.org" Subject: Re: [radext] Fwd: New Version Notification for draft-winter-radext-fancyaccounting-01.txt X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1991528714777937215==" Sender: radext-bounces@ietf.org Errors-To: radext-bounces@ietf.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --===============1991528714777937215== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigA75173B56D292791606E79AE" This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigA75173B56D292791606E79AE Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi, > I like the new accounting draft -- simple and flexible. Thanks :-) > Some thoughts.. >=20 > There might be cases where not all Packet and Octet information is know= n > or provided. For example counting bytes over a serial line or higher > layer where packet counts may no longer be known, applicable or accessi= ble. >=20 > Suggest changing 'exactly once' to zero or one for Packets and Octets > fields. That's a good point. I'll change the text accordingly. One Q about "no longer be known" - I don't know any usage patterns that would lead to a value getting "lost" during a session. A concern of mine was that a NAS might send a value in an Interim-Update, but then not report the same type of data in the Stop packet. I considered that a very bad thing, as it leaves the RADIUS server with the open question on what happened to this type of traffic since the last update. That's why I added text in the occurence table that requires once-sent values to be sent in the final Stop ticket, too. If values stop being known mid-session, is that then an unreasonable requirement? > If you can count it people are going to want to enforce it. Using > interim accounting and dynamic auth is a practical option however > leakage is unavoidable. >=20 > Perhaps a separate container group to signal limits via Access-Accept > enforced by NAS: >=20 > Limit-Traffic-Class > Limit-Traffic-Class-Name > Limit-Traffic-Class-Input-Octets > Limit-Traffic-Class-Output-Octets >=20 > 'd volunteer text if theres interest and this is not too much scope cre= ep. This part I'm not so comfortable with - at least in the scope of the current draft. I see Accounting as a one-way flow from the NAS to the RADIUS server to report about the current reality of a user session. Undoubtedly, being able to send Time or Data limits from the RADIUS server to the NAS is also useful, but it's a different topic IMHO, worth its own draft. However, if the WG thinks that this should be in the scope of this document, I'll be happy to add your text. Greetings, Stefan Winter >=20 > regards, > Peter --=20 Stefan WINTER Ingenieur de Recherche Fondation RESTENA - R=E9seau T=E9l=E9informatique de l'Education National= e et de la Recherche 6, rue Richard Coudenhove-Kalergi L-1359 Luxembourg Tel: +352 424409 1 Fax: +352 422473 --------------enigA75173B56D292791606E79AE 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.0.18 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk/+1gMACgkQ+jm90f8eFWarjgCeO6Yv9Yv26MWUA3u+N8GYuUBw W30An2hhyyiWh1zmxXxco8CbRNDTJvFX =K598 -----END PGP SIGNATURE----- --------------enigA75173B56D292791606E79AE-- --===============1991528714777937215== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ radext mailing list radext@ietf.org https://www.ietf.org/mailman/listinfo/radext --===============1991528714777937215==-- From peterd@iea-software.com Thu Jul 12 10:35:12 2012 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 E455511E8098 for ; Thu, 12 Jul 2012 10:35:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TVP3mdGu3HNs for ; Thu, 12 Jul 2012 10:35:12 -0700 (PDT) Received: from aspen.internal.iea-software.com (remote.iea-software.com [70.89.142.196]) by ietfa.amsl.com (Postfix) with ESMTP id 4DD9F11E8083 for ; Thu, 12 Jul 2012 10:35:11 -0700 (PDT) Received: from SMURF (unverified [10.0.3.195]) by aspen.internal.iea-software.com (Rockliffe SMTPRA 7.0.6) with ESMTP id ; Thu, 12 Jul 2012 10:34:32 -0700 Date: Thu, 12 Jul 2012 10:35:44 -0700 (Pacific Daylight Time) From: Peter Deacon To: Stefan Winter In-Reply-To: <4FFED600.3000109@restena.lu> Message-ID: References: <20120712081654.17566.87131.idtracker@ietfa.amsl.com> <4FFE8893.30402@restena.lu> <4FFED600.3000109@restena.lu> User-Agent: Alpine 2.00 (WNT 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: "radext@ietf.org" Subject: Re: [radext] Fwd: New Version Notification for draft-winter-radext-fancyaccounting-01.txt X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 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, 12 Jul 2012 17:35:13 -0000 On Thu, 12 Jul 2012, Stefan Winter wrote: > One Q about "no longer be known" - I don't know any usage patterns that > would lead to a value getting "lost" during a session. > A concern of mine was that a NAS might send a value in an > Interim-Update, but then not report the same type of data in the Stop > packet. > I considered that a very bad thing, as it leaves the RADIUS server with > the open question on what happened to this type of traffic since the > last update. That's why I added text in the occurence table that > requires once-sent values to be sent in the final Stop ticket, too. > If values stop being known mid-session, is that then an unreasonable > requirement? Agree. I think at point where a class or any sub-attribute of the class appears in an interim it should be required to be sent in all subsequent interims and stop record. Forgetting should not be an option. Allowing any counter data to disappear or reset is ambiguous as to how the lack of information is interpreted. Especially difficult for backend systems providing near realtime costing of usage. > However, if the WG thinks that this should be in the scope of this > document, I'll be happy to add your text. Pretty please WG :) regards, Peter From radext-bounces@ietf.org Thu Jul 12 10:35:14 2012 Return-Path: X-Original-To: radext-archive-IeZ9sae2@lists.ietf.org Delivered-To: ietfarch-radext-archive-IeZ9sae2@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6352711E8098; Thu, 12 Jul 2012 10:35:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1342114514; bh=fC0dJwFZg6pIK+IHIhiFVfmFh/cPAixlBwz40evLofw=; h=Date:From:To:In-Reply-To:Message-ID:References:MIME-Version:Cc: Subject:List-Id:List-Unsubscribe:List-Archive:List-Post:List-Help: List-Subscribe:Content-Transfer-Encoding:Content-Type:Sender; b=yAz3e9GmCELz4H/5cI3/h/Y5wyZcRmYfhIivy5bjKV965tvZ79/9GaQSaSthUJ/9z aMDF6A1MtPUIZXCSn9L1zva/uViTvNLWr9ee4wQ1bxHZKB3IgP5s6V4y248hPcpYd6 J5Bk4Xc2EZI52BL/fU/6/+FwUpWv9DVJ0he8Vp0Q= 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 E455511E8098 for ; Thu, 12 Jul 2012 10:35:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TVP3mdGu3HNs for ; Thu, 12 Jul 2012 10:35:12 -0700 (PDT) Received: from aspen.internal.iea-software.com (remote.iea-software.com [70.89.142.196]) by ietfa.amsl.com (Postfix) with ESMTP id 4DD9F11E8083 for ; Thu, 12 Jul 2012 10:35:11 -0700 (PDT) Received: from SMURF (unverified [10.0.3.195]) by aspen.internal.iea-software.com (Rockliffe SMTPRA 7.0.6) with ESMTP id ; Thu, 12 Jul 2012 10:34:32 -0700 Date: Thu, 12 Jul 2012 10:35:44 -0700 (Pacific Daylight Time) From: Peter Deacon To: Stefan Winter In-Reply-To: <4FFED600.3000109@restena.lu> Message-ID: References: <20120712081654.17566.87131.idtracker@ietfa.amsl.com> <4FFE8893.30402@restena.lu> <4FFED600.3000109@restena.lu> User-Agent: Alpine 2.00 (WNT 1167 2008-08-23) MIME-Version: 1.0 Cc: "radext@ietf.org" Subject: Re: [radext] Fwd: New Version Notification for draft-winter-radext-fancyaccounting-01.txt X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: radext-bounces@ietf.org Errors-To: radext-bounces@ietf.org On Thu, 12 Jul 2012, Stefan Winter wrote: > One Q about "no longer be known" - I don't know any usage patterns that > would lead to a value getting "lost" during a session. > A concern of mine was that a NAS might send a value in an > Interim-Update, but then not report the same type of data in the Stop > packet. > I considered that a very bad thing, as it leaves the RADIUS server with > the open question on what happened to this type of traffic since the > last update. That's why I added text in the occurence table that > requires once-sent values to be sent in the final Stop ticket, too. > If values stop being known mid-session, is that then an unreasonable > requirement? Agree. I think at point where a class or any sub-attribute of the class appears in an interim it should be required to be sent in all subsequent interims and stop record. Forgetting should not be an option. Allowing any counter data to disappear or reset is ambiguous as to how the lack of information is interpreted. Especially difficult for backend systems providing near realtime costing of usage. > However, if the WG thinks that this should be in the scope of this > document, I'll be happy to add your text. Pretty please WG :) regards, Peter _______________________________________________ radext mailing list radext@ietf.org https://www.ietf.org/mailman/listinfo/radext From leaf.y.yeh@huawei.com Thu Jul 12 21:20:09 2012 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 0B3C511E8117 for ; Thu, 12 Jul 2012 21:20:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.271 X-Spam-Level: X-Spam-Status: No, score=-6.271 tagged_above=-999 required=5 tests=[AWL=0.328, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WaW27ljfGZmu for ; Thu, 12 Jul 2012 21:20:07 -0700 (PDT) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id A220411E8114 for ; Thu, 12 Jul 2012 21:20:07 -0700 (PDT) Received: from 172.18.9.243 (EHLO dfweml202-edg.china.huawei.com) ([172.18.9.243]) by dfwrg02-dlp.huawei.com (MOS 4.2.3-GA FastPath) with ESMTP id AHS23324; Fri, 13 Jul 2012 00:20:42 -0400 (EDT) Received: from DFWEML407-HUB.china.huawei.com (10.193.5.132) by dfweml202-edg.china.huawei.com (172.18.9.108) with Microsoft SMTP Server (TLS) id 14.1.323.3; Thu, 12 Jul 2012 21:18:00 -0700 Received: from SZXEML421-HUB.china.huawei.com (10.82.67.160) by dfweml407-hub.china.huawei.com (10.193.5.132) with Microsoft SMTP Server (TLS) id 14.1.323.3; Thu, 12 Jul 2012 21:17:58 -0700 Received: from SZXEML510-MBS.china.huawei.com ([169.254.8.103]) by szxeml421-hub.china.huawei.com ([10.82.67.160]) with mapi id 14.01.0323.003; Fri, 13 Jul 2012 12:17:54 +0800 From: Leaf yeh To: Stefan Winter , "radext@ietf.org" Thread-Topic: [radext] Fwd: New Version Notification for draft-winter-radext-fancyaccounting-01.txt Thread-Index: AQHNYDLCgRpgY5mqQE25TOLToIHWB5clyhLR Date: Fri, 13 Jul 2012 04:17:53 +0000 Message-ID: References: <20120712081654.17566.87131.idtracker@ietfa.amsl.com> <4FFE8893.30402@restena.lu> , <4FFED1D3.7060706@restena.lu> In-Reply-To: <4FFED1D3.7060706@restena.lu> Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.66.83.160] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <1A951290D26A844C848BD2E0B5FD9E2D@huawei.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: Re: [radext] Fwd: New Version Notification for draft-winter-radext-fancyaccounting-01.txt X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 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 Jul 2012 04:20:09 -0000 > Stefan - The string can do the same well-defined enumeration of known tra= ffic classes that the integer can also do, and more. Section 2.1.1 - Option 1: Acct-Traffic-Class-Name string starting wi= th the substring "urn:". Usage of this option implies that the traffic name is in the form of a URN and requires that a public specification of this URN exists. That specification must include the type of traffic being counted with this traffic class, and the exact definition of where in the network packets the byte-count starts and ends. The sub-attribute, Acct-Traffic-Class-Name, here sounds create a new data t= ype of string with additional specification. And the method of 'URN' does n= ot really get advantages over the enumeration codes defined in sub-attribu= tes of the draft-yeh-radext-ext-traffic-statistics-03. I mean the enumerati= on problem of traffic type is still there, but introduced a more new type o= f string parser for this specified data type. Then the question will be why= we need this kind of complexity to solve the same problem. Option 2: Acct-Traffic-Class-Name string not starting with "urn:". This option is for local use of special-purpose accounting as defined by the NAS administrator, where no defined URN matches the meaning of the traffic to be counted. The meaning of the content needs to be communicated out-of-band between the NAS and RADIUS Server operator. Example: Acct-Traffic-Class-Name =3D "UDP traffic to AS2606". The 'non-urn' string sounds opaque or un-readable to the machine as the usu= al string. Right? What kind of the out-of-band means will be needed for the data interpretati= on in the string? This also sounds new complexities. Stefan - The main question seems to be: should the format be extensible to support arbitrary accounting needs? Or should it be limited to a few fixed values, centrally managed by the IETF? a. Nesting-TVL with its sub-attributes does not mean that it can't be exten= sible in the future to define=A0new sub-attribute for the necessary provisi= oning=A0scenario.=20 b. Fixed and extensible. To make a proposed standard managed by IETF is why= we come here. Right? Stefan - Spending time uselessly arguing on off-topic aspects doesn't contribute to a solution. Agreed. I suggest to ask the chairs to solve the argument between us. OK? Best Regards, Leaf =A0 =A0 =A0 ________________________________________ From: radext-bounces@ietf.org [radext-bounces@ietf.org] on behalf of Stefan= Winter [stefan.winter@restena.lu] Sent: Thursday, July 12, 2012 21:32 To: radext@ietf.org Subject: Re: [radext] Fwd: New Version Notification for draft-winter-radext= -fancyaccounting-01.txt > Welcome debate or competition on the same topic: RADIUS Accounting Extens= ions for Traffic Statistics. Hope the WG could figure out the solution on t= his topic soon. The problem looks not so difficult. Indeed. The main question seems to be: should the format be extensible to support arbitrary accounting needs? Or should it be limited to a few fixed values, centrally managed by the IETF? I argue for the first, you for the second. > Stefan - This is the consequence of Leaf's decision to first suggest nume= rous other, inferior, approaches, and then, when these were repelled, copyi= ng the approach from my -00 with slightly different wording with his name a= s the author; unsurprisingly, the two drafts are now very close to each oth= er.=20 >=20 > History on this topic in my memory for your correction: > 1.=A0 draft-yeh-radext-dual-stack-access-00 (2011-3-7) put forward the to= pic & 1st solution of RADIUS Accounting Extensions for Traffic Statistics f= or dual stack, and presented in IETF80; > 2.=A0 After IETF80 Radext session, draft-winter-radext-fancyaccounting-00= (2011-3-31) put forward the 2nd solution of TLV with extended-type space; > 3.=A0 draft-yeh-radext-dual-stack-access-02 expired in 2011-09-30 > 4.=A0 draft-winter-radext-fancyaccounting-00 expired in 2011-10-02 > 5.=A0 The IETF82 presentation (http://www.ietf.org/proceedings/82/slides/= radext-2.pdf ) with draft-yeh-radext-ext-traffic-statistics-01 re-triggered= the discussion on the attribute design of Acct-Traffic-Statistics; > 6.=A0 After got the hint in the meeting minutes of Radext IETF82 (http://= www.ietf.org/mail-archive/web/radext/current/msg07489.html ), I asked for t= he cooperation with Stefan on this topic several times, but it looks to bum= p; > 7.=A0 After the discussion on the mailing list of Radext, draft-yeh-radex= t-ext-traffic-statistics-02 adopted the date type of nesting-TLV; > 8.=A0 Around more than 1 week before I submitted draft-yeh-radext-ext-tra= ffic-statistics-03, I asked Stefan for his revision and cooperation on my d= raft again, but failed. Thanks for this timeline - it perfectly proves my point. The TLV structure was first introduced in your point 2 by me. It reappeared in point 7. - This time, the author was you, while the concept was the same. The fact that you repeatedly put up slides in the time between 2 and 7 which were calling the TLV approach "design 3" does not mean it was your idea and design. The draft, idea and structure were there long before you did that. In that light, isn't it understandable that I don't fancy becoming a co-author of "your" draft with you as an editor? If that's not a sufficient justification for me being upset, here's another one: following IETF80, I created fancyaccounting-00 because I was trying to *help* you - you presented a good problem statement, and I had an easy solution in my mind. And yet, when I uploaded it *and* got positive feedback from the WG, you indicated that you are not interested in the topic in a subsequent meeting, making it all stall. That is not nice= . That's my only reply on that topic. Spending time uselessly arguing on off-topic aspects doesn't contribute to a solution. > Stefan - I believe my draft is more thorough and thought-out in many aspe= cts. The only difference is that his draft has an integer enumerator for tr= affic classes, while my draft uses a string.=20 >=20 > The above 2 statements sounds contradictory. Not at all. My previous mail contained reasons and argument why I did it, and it enumerated why it is a good idea. Your reply conveniently cuts out these, and doesn't present counter-arguments against them. You just state you don't like it. Too bad. > Stefan - The string can do the same well-defined enumeration of known tra= ffic classes that the integer can also do, and more. >=20 > This sounds something real on the aspect of technology or Radius attribut= e design, which asks for the discussion within the WG. Indeed. Stefan Winter >=20 >=20 > Best Regards, > Leaf >=20 >=20 > -----Original Message----- > From: radext-bounces@ietf.org [mailto:radext-bounces@ietf.org] On Behalf = Of Stefan Winter > Sent: Thursday, July 12, 2012 4:20 PM > To: radext@ietf.org > Subject: [radext] Fwd: New Version Notification for draft-winter-radext-f= ancyaccounting-01.txt >=20 > Hello, >=20 > since the interest on the topic of RADIUS Accounting for subsets of the t= otal traffic has risen again, I have revived my old, expired -00 version of= "fancyaccounting". The major change to -00 is that I drop the enumerated i= nteger as a means to express which traffic is counted, and use only the str= ing type instead. >=20 > Realising that a known vocabulary of traffic classes is useful for inter-= op between ISPs, I introduced an - optional - fixed syntax for specific acc= ounting traffic classes by using URNs. Among those is, of course, IPv6, as = this was the original trigger for the accounting traffic class discussion. >=20 > The advantage of the URN/freetext model is that it can be expanded arbitr= arily and yet have a defined meaning; while still allowing a local admin to= count "whatever" by choosing not to use a URN. I would like to thank Klaas= Wierenga for his inspiration in that regard! >=20 > The other changes are cleanups (move of Integer64 to radius-extensions) a= nd tighter semenatic requirements of when to send what; including a way to = express which bytes exactly to count - a suggestion I got some 2 years ago = when discussing -00. >=20 > This is an individual submission which is in sort of a competition with d= raft-yeh-radext-ext-traffic-statistics. This is the consequence of Leaf's d= ecision to first suggest numerous other, inferior, approaches, and then, wh= en these were repelled, copying the approach from my -00 with slightly diff= erent wording with his name as the author; unsurprisingly, the two drafts a= re now very close to each other. I believe my draft is more thorough and th= ought-out in many aspects. The only difference is that his draft has an int= eger enumerator for traffic classes, while my draft uses a string. The stri= ng can do the same well-defined enumeration of known traffic classes that t= he integer can also do, and more. >=20 > If the re-charter with an explicit mention of "RADIUS Accounting Extensio= ns for Traffic Statistics" gets adopted, I would like to suggest adopting m= y draft for that topic. >=20 > Greetings, >=20 > Stefan Winter >=20 >=20 > -------- Original Message -------- > Subject: New Version Notification for > draft-winter-radext-fancyaccounting-01.txt > Date: Thu, 12 Jul 2012 01:16:54 -0700 > From: internet-drafts@ietf.org > To: stefan.winter@restena.lu >=20 >=20 > A new version of I-D, draft-winter-radext-fancyaccounting-01.txt > has been successfully submitted by Stefan Winter and posted to the IETF r= epository. >=20 > Filename:=A0=A0=A0=A0=A0 draft-winter-radext-fancyaccounting > Revision:=A0=A0=A0=A0=A0 01 > Title:=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 RADIUS Accounting = for traffic classes > Creation date:=A0=A0=A0=A0=A0=A0=A0=A0 2012-07-12 > WG ID:=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 Individual Submiss= ion > Number of pages: 9 > URL: > http://www.ietf.org/internet-drafts/draft-winter-radext-fancyaccounting-0= 1.txt > Status: > http://datatracker.ietf.org/doc/draft-winter-radext-fancyaccounting > Htmlized: > http://tools.ietf.org/html/draft-winter-radext-fancyaccounting-01 > Diff: > http://tools.ietf.org/rfcdiff?url2=3Ddraft-winter-radext-fancyaccounting-= 01 >=20 > Abstract: >=A0=A0=A0 This document specifies new attributes for RADIUS Accounting to >=A0=A0=A0 enable NAS reporting of subsets of the total traffic in a user >=A0=A0=A0 session. >=20 >=20 >=20 >=20 >=20 > The IETF Secretariat >=20 >=20 >=20 > _______________________________________________ > radext mailing list > radext@ietf.org > https://www.ietf.org/mailman/listinfo/radext >=20 --=20 Stefan WINTER Ingenieur de Recherche Fondation RESTENA - R=E9seau T=E9l=E9informatique de l'Education Nationale = et de la Recherche 6, rue Richard Coudenhove-Kalergi L-1359 Luxembourg Tel: +352 424409 1 Fax: +352 422473 From radext-bounces@ietf.org Thu Jul 12 21:20:11 2012 Return-Path: X-Original-To: radext-archive-IeZ9sae2@lists.ietf.org Delivered-To: ietfarch-radext-archive-IeZ9sae2@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4A76911E8114; Thu, 12 Jul 2012 21:20:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1342153211; bh=brE4TtkMk++mf/xidqtxEYT1JPyt8VhPnYHInLWChEo=; h=From:To:Date:Message-ID:References:In-Reply-To:Content-ID: MIME-Version:Subject:List-Id:List-Unsubscribe:List-Archive: List-Post:List-Help:List-Subscribe:Content-Type: Content-Transfer-Encoding:Sender; b=SvIAIgBqCiyj7X+z2rktW3V29b+GZSlIIXT32BXs8gwLpmNw2vdovURCW+PE4lADM zmEebIDUJK/jVnKKqntHnhv3Y+S11X7j34c/2Mbfl8q+0hVLgX2JrnB9RHAvQIazOP uL1/UEJ22gu+2ySSDCTA1THLcZBHLQ8zWVMmY01s= 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 0B3C511E8117 for ; Thu, 12 Jul 2012 21:20:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.271 X-Spam-Level: X-Spam-Status: No, score=-6.271 tagged_above=-999 required=5 tests=[AWL=0.328, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WaW27ljfGZmu for ; Thu, 12 Jul 2012 21:20:07 -0700 (PDT) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id A220411E8114 for ; Thu, 12 Jul 2012 21:20:07 -0700 (PDT) Received: from 172.18.9.243 (EHLO dfweml202-edg.china.huawei.com) ([172.18.9.243]) by dfwrg02-dlp.huawei.com (MOS 4.2.3-GA FastPath) with ESMTP id AHS23324; Fri, 13 Jul 2012 00:20:42 -0400 (EDT) Received: from DFWEML407-HUB.china.huawei.com (10.193.5.132) by dfweml202-edg.china.huawei.com (172.18.9.108) with Microsoft SMTP Server (TLS) id 14.1.323.3; Thu, 12 Jul 2012 21:18:00 -0700 Received: from SZXEML421-HUB.china.huawei.com (10.82.67.160) by dfweml407-hub.china.huawei.com (10.193.5.132) with Microsoft SMTP Server (TLS) id 14.1.323.3; Thu, 12 Jul 2012 21:17:58 -0700 Received: from SZXEML510-MBS.china.huawei.com ([169.254.8.103]) by szxeml421-hub.china.huawei.com ([10.82.67.160]) with mapi id 14.01.0323.003; Fri, 13 Jul 2012 12:17:54 +0800 From: Leaf yeh To: Stefan Winter , "radext@ietf.org" Thread-Topic: [radext] Fwd: New Version Notification for draft-winter-radext-fancyaccounting-01.txt Thread-Index: AQHNYDLCgRpgY5mqQE25TOLToIHWB5clyhLR Date: Fri, 13 Jul 2012 04:17:53 +0000 Message-ID: References: <20120712081654.17566.87131.idtracker@ietfa.amsl.com> <4FFE8893.30402@restena.lu> , <4FFED1D3.7060706@restena.lu> In-Reply-To: <4FFED1D3.7060706@restena.lu> Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.66.83.160] Content-ID: <1A951290D26A844C848BD2E0B5FD9E2D@huawei.com> MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: Re: [radext] Fwd: New Version Notification for draft-winter-radext-fancyaccounting-01.txt X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: radext-bounces@ietf.org Errors-To: radext-bounces@ietf.org > Stefan - The string can do the same well-defined enumeration of known tra= ffic classes that the integer can also do, and more. Section 2.1.1 - Option 1: Acct-Traffic-Class-Name string starting wi= th the substring "urn:". Usage of this option implies that the traffic name is in the form of a URN and requires that a public specification of this URN exists. That specification must include the type of traffic being counted with this traffic class, and the exact definition of where in the network packets the byte-count starts and ends. The sub-attribute, Acct-Traffic-Class-Name, here sounds create a new data t= ype of string with additional specification. And the method of 'URN' does n= ot really get advantages over the enumeration codes defined in sub-attribu= tes of the draft-yeh-radext-ext-traffic-statistics-03. I mean the enumerati= on problem of traffic type is still there, but introduced a more new type o= f string parser for this specified data type. Then the question will be why= we need this kind of complexity to solve the same problem. Option 2: Acct-Traffic-Class-Name string not starting with "urn:". This option is for local use of special-purpose accounting as defined by the NAS administrator, where no defined URN matches the meaning of the traffic to be counted. The meaning of the content needs to be communicated out-of-band between the NAS and RADIUS Server operator. Example: Acct-Traffic-Class-Name =3D "UDP traffic to AS2606". The 'non-urn' string sounds opaque or un-readable to the machine as the usu= al string. Right? What kind of the out-of-band means will be needed for the data interpretati= on in the string? This also sounds new complexities. Stefan - The main question seems to be: should the format be extensible to support arbitrary accounting needs? Or should it be limited to a few fixed values, centrally managed by the IETF? a. Nesting-TVL with its sub-attributes does not mean that it can't be exten= sible in the future to define=A0new sub-attribute for the necessary provisi= oning=A0scenario. = b. Fixed and extensible. To make a proposed standard managed by IETF is why= we come here. Right? Stefan - Spending time uselessly arguing on off-topic aspects doesn't contribute to a solution. Agreed. I suggest to ask the chairs to solve the argument between us. OK? Best Regards, Leaf =A0 =A0 =A0 ________________________________________ From: radext-bounces@ietf.org [radext-bounces@ietf.org] on behalf of Stefan= Winter [stefan.winter@restena.lu] Sent: Thursday, July 12, 2012 21:32 To: radext@ietf.org Subject: Re: [radext] Fwd: New Version Notification for draft-winter-radext= -fancyaccounting-01.txt > Welcome debate or competition on the same topic: RADIUS Accounting Extens= ions for Traffic Statistics. Hope the WG could figure out the solution on t= his topic soon. The problem looks not so difficult. Indeed. The main question seems to be: should the format be extensible to support arbitrary accounting needs? Or should it be limited to a few fixed values, centrally managed by the IETF? I argue for the first, you for the second. > Stefan - This is the consequence of Leaf's decision to first suggest nume= rous other, inferior, approaches, and then, when these were repelled, copyi= ng the approach from my -00 with slightly different wording with his name a= s the author; unsurprisingly, the two drafts are now very close to each oth= er. = > = > History on this topic in my memory for your correction: > 1.=A0 draft-yeh-radext-dual-stack-access-00 (2011-3-7) put forward the to= pic & 1st solution of RADIUS Accounting Extensions for Traffic Statistics f= or dual stack, and presented in IETF80; > 2.=A0 After IETF80 Radext session, draft-winter-radext-fancyaccounting-00= (2011-3-31) put forward the 2nd solution of TLV with extended-type space; > 3.=A0 draft-yeh-radext-dual-stack-access-02 expired in 2011-09-30 > 4.=A0 draft-winter-radext-fancyaccounting-00 expired in 2011-10-02 > 5.=A0 The IETF82 presentation (http://www.ietf.org/proceedings/82/slides/= radext-2.pdf ) with draft-yeh-radext-ext-traffic-statistics-01 re-triggered= the discussion on the attribute design of Acct-Traffic-Statistics; > 6.=A0 After got the hint in the meeting minutes of Radext IETF82 (http://= www.ietf.org/mail-archive/web/radext/current/msg07489.html ), I asked for t= he cooperation with Stefan on this topic several times, but it looks to bum= p; > 7.=A0 After the discussion on the mailing list of Radext, draft-yeh-radex= t-ext-traffic-statistics-02 adopted the date type of nesting-TLV; > 8.=A0 Around more than 1 week before I submitted draft-yeh-radext-ext-tra= ffic-statistics-03, I asked Stefan for his revision and cooperation on my d= raft again, but failed. Thanks for this timeline - it perfectly proves my point. The TLV structure was first introduced in your point 2 by me. It reappeared in point 7. - This time, the author was you, while the concept was the same. The fact that you repeatedly put up slides in the time between 2 and 7 which were calling the TLV approach "design 3" does not mean it was your idea and design. The draft, idea and structure were there long before you did that. In that light, isn't it understandable that I don't fancy becoming a co-author of "your" draft with you as an editor? If that's not a sufficient justification for me being upset, here's another one: following IETF80, I created fancyaccounting-00 because I was trying to *help* you - you presented a good problem statement, and I had an easy solution in my mind. And yet, when I uploaded it *and* got positive feedback from the WG, you indicated that you are not interested in the topic in a subsequent meeting, making it all stall. That is not nice. That's my only reply on that topic. Spending time uselessly arguing on off-topic aspects doesn't contribute to a solution. > Stefan - I believe my draft is more thorough and thought-out in many aspe= cts. The only difference is that his draft has an integer enumerator for tr= affic classes, while my draft uses a string. = > = > The above 2 statements sounds contradictory. Not at all. My previous mail contained reasons and argument why I did it, and it enumerated why it is a good idea. Your reply conveniently cuts out these, and doesn't present counter-arguments against them. You just state you don't like it. Too bad. > Stefan - The string can do the same well-defined enumeration of known tra= ffic classes that the integer can also do, and more. > = > This sounds something real on the aspect of technology or Radius attribut= e design, which asks for the discussion within the WG. Indeed. Stefan Winter > = > = > Best Regards, > Leaf > = > = > -----Original Message----- > From: radext-bounces@ietf.org [mailto:radext-bounces@ietf.org] On Behalf = Of Stefan Winter > Sent: Thursday, July 12, 2012 4:20 PM > To: radext@ietf.org > Subject: [radext] Fwd: New Version Notification for draft-winter-radext-f= ancyaccounting-01.txt > = > Hello, > = > since the interest on the topic of RADIUS Accounting for subsets of the t= otal traffic has risen again, I have revived my old, expired -00 version of= "fancyaccounting". The major change to -00 is that I drop the enumerated i= nteger as a means to express which traffic is counted, and use only the str= ing type instead. > = > Realising that a known vocabulary of traffic classes is useful for inter-= op between ISPs, I introduced an - optional - fixed syntax for specific acc= ounting traffic classes by using URNs. Among those is, of course, IPv6, as = this was the original trigger for the accounting traffic class discussion. > = > The advantage of the URN/freetext model is that it can be expanded arbitr= arily and yet have a defined meaning; while still allowing a local admin to= count "whatever" by choosing not to use a URN. I would like to thank Klaas= Wierenga for his inspiration in that regard! > = > The other changes are cleanups (move of Integer64 to radius-extensions) a= nd tighter semenatic requirements of when to send what; including a way to = express which bytes exactly to count - a suggestion I got some 2 years ago = when discussing -00. > = > This is an individual submission which is in sort of a competition with d= raft-yeh-radext-ext-traffic-statistics. This is the consequence of Leaf's d= ecision to first suggest numerous other, inferior, approaches, and then, wh= en these were repelled, copying the approach from my -00 with slightly diff= erent wording with his name as the author; unsurprisingly, the two drafts a= re now very close to each other. I believe my draft is more thorough and th= ought-out in many aspects. The only difference is that his draft has an int= eger enumerator for traffic classes, while my draft uses a string. The stri= ng can do the same well-defined enumeration of known traffic classes that t= he integer can also do, and more. > = > If the re-charter with an explicit mention of "RADIUS Accounting Extensio= ns for Traffic Statistics" gets adopted, I would like to suggest adopting m= y draft for that topic. > = > Greetings, > = > Stefan Winter > = > = > -------- Original Message -------- > Subject: New Version Notification for > draft-winter-radext-fancyaccounting-01.txt > Date: Thu, 12 Jul 2012 01:16:54 -0700 > From: internet-drafts@ietf.org > To: stefan.winter@restena.lu > = > = > A new version of I-D, draft-winter-radext-fancyaccounting-01.txt > has been successfully submitted by Stefan Winter and posted to the IETF r= epository. > = > Filename:=A0=A0=A0=A0=A0 draft-winter-radext-fancyaccounting > Revision:=A0=A0=A0=A0=A0 01 > Title:=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 RADIUS Accounting = for traffic classes > Creation date:=A0=A0=A0=A0=A0=A0=A0=A0 2012-07-12 > WG ID:=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 Individual Submiss= ion > Number of pages: 9 > URL: > http://www.ietf.org/internet-drafts/draft-winter-radext-fancyaccounting-0= 1.txt > Status: > http://datatracker.ietf.org/doc/draft-winter-radext-fancyaccounting > Htmlized: > http://tools.ietf.org/html/draft-winter-radext-fancyaccounting-01 > Diff: > http://tools.ietf.org/rfcdiff?url2=3Ddraft-winter-radext-fancyaccounting-= 01 > = > Abstract: >=A0=A0=A0 This document specifies new attributes for RADIUS Accounting to >=A0=A0=A0 enable NAS reporting of subsets of the total traffic in a user >=A0=A0=A0 session. > = > = > = > = > = > The IETF Secretariat > = > = > = > _______________________________________________ > radext mailing list > radext@ietf.org > https://www.ietf.org/mailman/listinfo/radext > = -- = Stefan WINTER Ingenieur de Recherche Fondation RESTENA - R=E9seau T=E9l=E9informatique de l'Education Nationale = et de la Recherche 6, rue Richard Coudenhove-Kalergi L-1359 Luxembourg Tel: +352 424409 1 Fax: +352 422473 _______________________________________________ radext mailing list radext@ietf.org https://www.ietf.org/mailman/listinfo/radext From stefan.winter@restena.lu Fri Jul 13 09:09:08 2012 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 29C6111E80CD for ; Fri, 13 Jul 2012 09:09:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hG4AMJrxlylF for ; Fri, 13 Jul 2012 09:09:06 -0700 (PDT) Received: from smtprelay.restena.lu (smtprelay.restena.lu [IPv6:2001:a18:1::62]) by ietfa.amsl.com (Postfix) with ESMTP id 0C4BA11E80C9 for ; Fri, 13 Jul 2012 09:09:05 -0700 (PDT) Received: from smtprelay.restena.lu (localhost [127.0.0.1]) by smtprelay.restena.lu (Postfix) with ESMTP id 1BF1410584 for ; Fri, 13 Jul 2012 18:09:40 +0200 (CEST) Received: from [IPv6:2001:a18:1:8:34d2:595a:a600:bbea] (unknown [IPv6:2001:a18:1:8:34d2:595a:a600:bbea]) by smtprelay.restena.lu (Postfix) with ESMTPS id B53311057F for ; Fri, 13 Jul 2012 18:09:39 +0200 (CEST) Message-ID: <5000483E.5030800@restena.lu> Date: Fri, 13 Jul 2012 18:09:34 +0200 From: Stefan Winter User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:13.0) Gecko/20120601 Thunderbird/13.0 MIME-Version: 1.0 To: radext@ietf.org References: <20120712081654.17566.87131.idtracker@ietfa.amsl.com> <4FFE8893.30402@restena.lu> , <4FFED1D3.7060706@restena.lu> In-Reply-To: X-Enigmail-Version: 1.4.2 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigCEF8043BD5FBC64D9E67C416" X-Virus-Scanned: ClamAV Subject: Re: [radext] Fwd: New Version Notification for draft-winter-radext-fancyaccounting-01.txt X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 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 Jul 2012 16:09:08 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigCEF8043BD5FBC64D9E67C416 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi, > The sub-attribute, Acct-Traffic-Class-Name, here sounds create a new da= ta type of string with additional specification. And the method of 'URN' = does not really get advantages over the enumeration codes defined in sub= -attributes of the draft-yeh-radext-ext-traffic-statistics-03. It's very obvious advantage is flexibility. Your integer is limited to IETF actions if new values are to be assigned. That is at least my guess, your draft does not say anything about how new values in this enum are assigned. I.e. your draft is underspecified in that aspect. Even in your own draft, the shortcomings of that approach are obvious: for DSCP, you created a whole new attribute! With the string, there is indeed one space of controlled vocabulary, it's the "urn:ietf:radius-accounting:" prefix. But: if vendors have their own NASes with more fine-grained reporting abilities than just "IP version" or "DSCP value", they can define these in their own URN tree and merrily use them - without any intervention of the IETF required. This is the exact same approach that is used for RADIUS attributes in general: there are IETF attributes, and there are Vendor-Specific ones. The analogy should be pretty obvious to see. I hope you are not going to argue about the usefulness of VSAs; they have done a lot of good in the last decades. Following that path sounds rather logical to me. > I mean the enumeration problem of traffic type is still there, but intr= oduced a more new type of string parser for this specified data type. The= n the question will be why we need this kind of complexity to solve the s= ame problem. What extra parser are you talking about? It's a string, and it has a value. A NAS can act very simply with that: if it is supposed to report on IPv6 volumes, it puts the literal string "urn:ietf:radius-accounting:ip:6" into the attribute. A RADIUS server which is curious whether it got any IPv6 volume statistics makes a simple equality check on incoming Acct-Traffic-Class-Name attributes: if ( Acct-Traffic-Class-Name =3D=3D "urn:ietf:radius-accounting:ip:6" ) {= do fancy stuff with IPv6 data; } An equality check is just about the simplest parser I can imagine. You draft would need to compare integers, too. > Option 2: Acct-Traffic-Class-Name string not starting with "urn:= ". > This option is for local use of special-purpose accounting as defined > by the NAS administrator, where no defined URN matches the meaning of > the traffic to be counted. The meaning of the content needs to be > communicated out-of-band between the NAS and RADIUS Server operator. > Example: Acct-Traffic-Class-Name =3D "UDP traffic to AS2606". >=20 > The 'non-urn' string sounds opaque or un-readable to the machine as the= usual string. Right? That's right. A RADIUS server can still be configured by the admin to log them in a defined way if he so wants, using the same equality checks as above. > What kind of the out-of-band means will be needed for the data interpre= tation in the string? This also sounds new complexities. In small environments, the NAS admin is also the RADIUS Server admin. There is no complexity. In larger environments, human communication between NAS admin and RADIUS admin by a communication means of your choice needs to take place. For example an e-mail " From: NAS Admin To: RAIDUS Server admin Subject: traffic counter installed! Dear RADIUS Server admin, you asked me to configure our NASes to report on the amount of UDP traffic sent to AS2602, to find out who the guy is who swamps our backbone with source-address-faked UDP packets. Just to let you know, I configured that 5 minutes ago; the NASes will use the Acct-Traffic-Class-Name label "UDP->AS2602" in their accounting records. Hope you'll catch him! Best regards, Your NAS Admin" Or Jabber. Or POTS. Or whatever you like. Of course this does not scale; it's not very useful beyond enterprise borders. For these, a proper definition and - guess what - a URN value would be used to formalise things. If that approach is seen as too liberal (I can sort of understand that), the draft can be changed to limit itself to option 1 only (urn: prefix MUST be used). That would still allow non-IETF groups to define their own filters. What I don't like about it is that some people *will* ignore the requirement and send arbitrary strings anyway - so why not spell out that possibility explicitly. It is certainly the most painless way for little enterprises which couldn't be bothered to make their own URN registry. > Stefan - The main question seems to be: should the format be extensible= > to support arbitrary accounting needs? Or should it be limited to a few= > fixed values, centrally managed by the IETF? >=20 > a. Nesting-TVL with its sub-attributes does not mean that it can't be e= xtensible in the future to define new sub-attribute for the necessary pro= visioning scenario.=20 > b. Fixed and extensible. To make a proposed standard managed by IETF is= why we come here. Right? Again, you prove my point with your own draft. As per your draft, "extensible" means that a new RFC needs to be written, a new attribute defined, new ENUM values specified. For *everything*. One example is DSCP. Funny thing is, I don't care much about DSCP. I only used it as an example of something people *might want*. Your reaction is that the draft needs a new attribute to carry the DSCP values. Whereas as per my draft, "extensible" means that if an organisation or individual has its own idea about what it wants to get stats about, it can just carry on and do it. And if that thing to report about proves to be interesting enough for the IETF to care, *then* can it be blessed by putting it into the IETF URN tree. Again, very similar to VSAs. Greetings, Stefan Winter >=20 >=20 > Stefan - Spending time uselessly arguing on > off-topic aspects doesn't contribute to a solution. >=20 > Agreed. I suggest to ask the chairs to solve the argument between us. O= K? >=20 >=20 > Best Regards, > Leaf > =20 > =20 > =20 > ________________________________________ > From: radext-bounces@ietf.org [radext-bounces@ietf.org] on behalf of St= efan Winter [stefan.winter@restena.lu] > Sent: Thursday, July 12, 2012 21:32 > To: radext@ietf.org > Subject: Re: [radext] Fwd: New Version Notification for draft-winter-ra= dext-fancyaccounting-01.txt >=20 >=20 >> Welcome debate or competition on the same topic: RADIUS Accounting Ext= ensions for Traffic Statistics. Hope the WG could figure out the solution= on this topic soon. The problem looks not so difficult. >=20 > Indeed. The main question seems to be: should the format be extensible > to support arbitrary accounting needs? Or should it be limited to a few= > fixed values, centrally managed by the IETF? >=20 > I argue for the first, you for the second. >=20 >> Stefan - This is the consequence of Leaf's decision to first suggest n= umerous other, inferior, approaches, and then, when these were repelled, = copying the approach from my -00 with slightly different wording with his= name as the author; unsurprisingly, the two drafts are now very close to= each other.=20 >> >> History on this topic in my memory for your correction: >> 1. draft-yeh-radext-dual-stack-access-00 (2011-3-7) put forward the t= opic & 1st solution of RADIUS Accounting Extensions for Traffic Statistic= s for dual stack, and presented in IETF80; >> 2. After IETF80 Radext session, draft-winter-radext-fancyaccounting-0= 0 (2011-3-31) put forward the 2nd solution of TLV with extended-type spac= e; >> 3. draft-yeh-radext-dual-stack-access-02 expired in 2011-09-30 >> 4. draft-winter-radext-fancyaccounting-00 expired in 2011-10-02 >> 5. The IETF82 presentation (http://www.ietf.org/proceedings/82/slides= /radext-2.pdf ) with draft-yeh-radext-ext-traffic-statistics-01 re-trigge= red the discussion on the attribute design of Acct-Traffic-Statistics; >> 6. After got the hint in the meeting minutes of Radext IETF82 (http:/= /www.ietf.org/mail-archive/web/radext/current/msg07489.html ), I asked fo= r the cooperation with Stefan on this topic several times, but it looks t= o bump; >> 7. After the discussion on the mailing list of Radext, draft-yeh-rade= xt-ext-traffic-statistics-02 adopted the date type of nesting-TLV; >> 8. Around more than 1 week before I submitted draft-yeh-radext-ext-tr= affic-statistics-03, I asked Stefan for his revision and cooperation on m= y draft again, but failed. >=20 > Thanks for this timeline - it perfectly proves my point. The TLV > structure was first introduced in your point 2 by me. It reappeared in > point 7. - This time, the author was you, while the concept was the sam= e. >=20 > The fact that you repeatedly put up slides in the time between 2 and 7 > which were calling the TLV approach "design 3" does not mean it was you= r > idea and design. The draft, idea and structure were there long before > you did that. >=20 > In that light, isn't it understandable that I don't fancy becoming a > co-author of "your" draft with you as an editor? >=20 > If that's not a sufficient justification for me being upset, here's > another one: following IETF80, I created fancyaccounting-00 because I > was trying to *help* you - you presented a good problem statement, and = I > had an easy solution in my mind. And yet, when I uploaded it *and* got > positive feedback from the WG, you indicated that you are not intereste= d > in the topic in a subsequent meeting, making it all stall. That is not = nice. >=20 > That's my only reply on that topic. Spending time uselessly arguing on > off-topic aspects doesn't contribute to a solution. >=20 >> Stefan - I believe my draft is more thorough and thought-out in many a= spects. The only difference is that his draft has an integer enumerator f= or traffic classes, while my draft uses a string.=20 >> >> The above 2 statements sounds contradictory. >=20 > Not at all. My previous mail contained reasons and argument why I did > it, and it enumerated why it is a good idea. >=20 > Your reply conveniently cuts out these, and doesn't present > counter-arguments against them. You just state you don't like it. Too b= ad. >=20 >> Stefan - The string can do the same well-defined enumeration of known = traffic classes that the integer can also do, and more. >> >> This sounds something real on the aspect of technology or Radius attri= bute design, which asks for the discussion within the WG. >=20 > Indeed. >=20 > Stefan Winter >=20 >> >> >> Best Regards, >> Leaf >> >> >> -----Original Message----- >> From: radext-bounces@ietf.org [mailto:radext-bounces@ietf.org] On Beha= lf Of Stefan Winter >> Sent: Thursday, July 12, 2012 4:20 PM >> To: radext@ietf.org >> Subject: [radext] Fwd: New Version Notification for draft-winter-radex= t-fancyaccounting-01.txt >> >> Hello, >> >> since the interest on the topic of RADIUS Accounting for subsets of th= e total traffic has risen again, I have revived my old, expired -00 versi= on of "fancyaccounting". The major change to -00 is that I drop the enume= rated integer as a means to express which traffic is counted, and use onl= y the string type instead. >> >> Realising that a known vocabulary of traffic classes is useful for int= er-op between ISPs, I introduced an - optional - fixed syntax for specifi= c accounting traffic classes by using URNs. Among those is, of course, IP= v6, as this was the original trigger for the accounting traffic class dis= cussion. >> >> The advantage of the URN/freetext model is that it can be expanded arb= itrarily and yet have a defined meaning; while still allowing a local adm= in to count "whatever" by choosing not to use a URN. I would like to than= k Klaas Wierenga for his inspiration in that regard! >> >> The other changes are cleanups (move of Integer64 to radius-extensions= ) and tighter semenatic requirements of when to send what; including a wa= y to express which bytes exactly to count - a suggestion I got some 2 yea= rs ago when discussing -00. >> >> This is an individual submission which is in sort of a competition wit= h draft-yeh-radext-ext-traffic-statistics. This is the consequence of Lea= f's decision to first suggest numerous other, inferior, approaches, and t= hen, when these were repelled, copying the approach from my -00 with slig= htly different wording with his name as the author; unsurprisingly, the t= wo drafts are now very close to each other. I believe my draft is more th= orough and thought-out in many aspects. The only difference is that his d= raft has an integer enumerator for traffic classes, while my draft uses a= string. The string can do the same well-defined enumeration of known tra= ffic classes that the integer can also do, and more. >> >> If the re-charter with an explicit mention of "RADIUS Accounting Exten= sions for Traffic Statistics" gets adopted, I would like to suggest adopt= ing my draft for that topic. >> >> Greetings, >> >> Stefan Winter >> >> >> -------- Original Message -------- >> Subject: New Version Notification for >> draft-winter-radext-fancyaccounting-01.txt >> Date: Thu, 12 Jul 2012 01:16:54 -0700 >> From: internet-drafts@ietf.org >> To: stefan.winter@restena.lu >> >> >> A new version of I-D, draft-winter-radext-fancyaccounting-01.txt >> has been successfully submitted by Stefan Winter and posted to the IET= F repository. >> >> Filename: draft-winter-radext-fancyaccounting >> Revision: 01 >> Title: RADIUS Accounting for traffic classes >> Creation date: 2012-07-12 >> WG ID: Individual Submission >> Number of pages: 9 >> URL: >> http://www.ietf.org/internet-drafts/draft-winter-radext-fancyaccountin= g-01.txt >> Status: >> http://datatracker.ietf.org/doc/draft-winter-radext-fancyaccounting >> Htmlized: >> http://tools.ietf.org/html/draft-winter-radext-fancyaccounting-01 >> Diff: >> http://tools.ietf.org/rfcdiff?url2=3Ddraft-winter-radext-fancyaccounti= ng-01 >> >> Abstract: >> This document specifies new attributes for RADIUS Accounting to >> enable NAS reporting of subsets of the total traffic in a user >> session. >> >> >> >> >> >> The IETF Secretariat >> >> >> >> _______________________________________________ >> radext mailing list >> radext@ietf.org >> https://www.ietf.org/mailman/listinfo/radext >> >=20 >=20 --=20 Stefan WINTER Ingenieur de Recherche Fondation RESTENA - R=E9seau T=E9l=E9informatique de l'Education National= e et de la Recherche 6, rue Richard Coudenhove-Kalergi L-1359 Luxembourg Tel: +352 424409 1 Fax: +352 422473 --------------enigCEF8043BD5FBC64D9E67C416 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.0.18 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAlAASEMACgkQ+jm90f8eFWZIKACghKf8kC24Fp/wSkR91MVZ7YU2 CrgAnRaxE09eP+5Av7MrfKfMcBCCqMuF =vQqA -----END PGP SIGNATURE----- --------------enigCEF8043BD5FBC64D9E67C416-- From radext-bounces@ietf.org Fri Jul 13 09:09:10 2012 Return-Path: X-Original-To: radext-archive-IeZ9sae2@lists.ietf.org Delivered-To: ietfarch-radext-archive-IeZ9sae2@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0404F11E80E0; Fri, 13 Jul 2012 09:09:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1342195750; bh=2mmHK6yaxpBm6UkhMkIVIjZyrG8/uG9+6E7NEJmn6Y8=; h=Message-ID:Date:From:MIME-Version:To:References:In-Reply-To: Subject:List-Id:List-Unsubscribe:List-Archive:List-Post:List-Help: List-Subscribe:Content-Type:Sender; b=Mz20RTUVXZja4t11FzwcknZqnx/CT6D7cpef/3t4KGTdkaF+BN/fDIe0PoKiPFKzc yXx03B/fEndJoRxTRktICheVL6qVLkWV49tKPeK16Z2ntfJprheDCa2GY9gAi0UiGG 9/PCUiftoiXfuisiorqi+leDawmXYw5KjL1ecTrg= 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 29C6111E80CD for ; Fri, 13 Jul 2012 09:09:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hG4AMJrxlylF for ; Fri, 13 Jul 2012 09:09:06 -0700 (PDT) Received: from smtprelay.restena.lu (smtprelay.restena.lu [IPv6:2001:a18:1::62]) by ietfa.amsl.com (Postfix) with ESMTP id 0C4BA11E80C9 for ; Fri, 13 Jul 2012 09:09:05 -0700 (PDT) Received: from smtprelay.restena.lu (localhost [127.0.0.1]) by smtprelay.restena.lu (Postfix) with ESMTP id 1BF1410584 for ; Fri, 13 Jul 2012 18:09:40 +0200 (CEST) Received: from [IPv6:2001:a18:1:8:34d2:595a:a600:bbea] (unknown [IPv6:2001:a18:1:8:34d2:595a:a600:bbea]) by smtprelay.restena.lu (Postfix) with ESMTPS id B53311057F for ; Fri, 13 Jul 2012 18:09:39 +0200 (CEST) Message-ID: <5000483E.5030800@restena.lu> Date: Fri, 13 Jul 2012 18:09:34 +0200 From: Stefan Winter User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:13.0) Gecko/20120601 Thunderbird/13.0 MIME-Version: 1.0 To: radext@ietf.org References: <20120712081654.17566.87131.idtracker@ietfa.amsl.com> <4FFE8893.30402@restena.lu> , <4FFED1D3.7060706@restena.lu> In-Reply-To: X-Enigmail-Version: 1.4.2 X-Virus-Scanned: ClamAV Subject: Re: [radext] Fwd: New Version Notification for draft-winter-radext-fancyaccounting-01.txt X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============7890619196668101927==" Sender: radext-bounces@ietf.org Errors-To: radext-bounces@ietf.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --===============7890619196668101927== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigCEF8043BD5FBC64D9E67C416" This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigCEF8043BD5FBC64D9E67C416 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi, > The sub-attribute, Acct-Traffic-Class-Name, here sounds create a new da= ta type of string with additional specification. And the method of 'URN' = does not really get advantages over the enumeration codes defined in sub= -attributes of the draft-yeh-radext-ext-traffic-statistics-03. It's very obvious advantage is flexibility. Your integer is limited to IETF actions if new values are to be assigned. That is at least my guess, your draft does not say anything about how new values in this enum are assigned. I.e. your draft is underspecified in that aspect. Even in your own draft, the shortcomings of that approach are obvious: for DSCP, you created a whole new attribute! With the string, there is indeed one space of controlled vocabulary, it's the "urn:ietf:radius-accounting:" prefix. But: if vendors have their own NASes with more fine-grained reporting abilities than just "IP version" or "DSCP value", they can define these in their own URN tree and merrily use them - without any intervention of the IETF required. This is the exact same approach that is used for RADIUS attributes in general: there are IETF attributes, and there are Vendor-Specific ones. The analogy should be pretty obvious to see. I hope you are not going to argue about the usefulness of VSAs; they have done a lot of good in the last decades. Following that path sounds rather logical to me. > I mean the enumeration problem of traffic type is still there, but intr= oduced a more new type of string parser for this specified data type. The= n the question will be why we need this kind of complexity to solve the s= ame problem. What extra parser are you talking about? It's a string, and it has a value. A NAS can act very simply with that: if it is supposed to report on IPv6 volumes, it puts the literal string "urn:ietf:radius-accounting:ip:6" into the attribute. A RADIUS server which is curious whether it got any IPv6 volume statistics makes a simple equality check on incoming Acct-Traffic-Class-Name attributes: if ( Acct-Traffic-Class-Name =3D=3D "urn:ietf:radius-accounting:ip:6" ) {= do fancy stuff with IPv6 data; } An equality check is just about the simplest parser I can imagine. You draft would need to compare integers, too. > Option 2: Acct-Traffic-Class-Name string not starting with "urn:= ". > This option is for local use of special-purpose accounting as defined > by the NAS administrator, where no defined URN matches the meaning of > the traffic to be counted. The meaning of the content needs to be > communicated out-of-band between the NAS and RADIUS Server operator. > Example: Acct-Traffic-Class-Name =3D "UDP traffic to AS2606". >=20 > The 'non-urn' string sounds opaque or un-readable to the machine as the= usual string. Right? That's right. A RADIUS server can still be configured by the admin to log them in a defined way if he so wants, using the same equality checks as above. > What kind of the out-of-band means will be needed for the data interpre= tation in the string? This also sounds new complexities. In small environments, the NAS admin is also the RADIUS Server admin. There is no complexity. In larger environments, human communication between NAS admin and RADIUS admin by a communication means of your choice needs to take place. For example an e-mail " From: NAS Admin To: RAIDUS Server admin Subject: traffic counter installed! Dear RADIUS Server admin, you asked me to configure our NASes to report on the amount of UDP traffic sent to AS2602, to find out who the guy is who swamps our backbone with source-address-faked UDP packets. Just to let you know, I configured that 5 minutes ago; the NASes will use the Acct-Traffic-Class-Name label "UDP->AS2602" in their accounting records. Hope you'll catch him! Best regards, Your NAS Admin" Or Jabber. Or POTS. Or whatever you like. Of course this does not scale; it's not very useful beyond enterprise borders. For these, a proper definition and - guess what - a URN value would be used to formalise things. If that approach is seen as too liberal (I can sort of understand that), the draft can be changed to limit itself to option 1 only (urn: prefix MUST be used). That would still allow non-IETF groups to define their own filters. What I don't like about it is that some people *will* ignore the requirement and send arbitrary strings anyway - so why not spell out that possibility explicitly. It is certainly the most painless way for little enterprises which couldn't be bothered to make their own URN registry. > Stefan - The main question seems to be: should the format be extensible= > to support arbitrary accounting needs? Or should it be limited to a few= > fixed values, centrally managed by the IETF? >=20 > a. Nesting-TVL with its sub-attributes does not mean that it can't be e= xtensible in the future to define new sub-attribute for the necessary pro= visioning scenario.=20 > b. Fixed and extensible. To make a proposed standard managed by IETF is= why we come here. Right? Again, you prove my point with your own draft. As per your draft, "extensible" means that a new RFC needs to be written, a new attribute defined, new ENUM values specified. For *everything*. One example is DSCP. Funny thing is, I don't care much about DSCP. I only used it as an example of something people *might want*. Your reaction is that the draft needs a new attribute to carry the DSCP values. Whereas as per my draft, "extensible" means that if an organisation or individual has its own idea about what it wants to get stats about, it can just carry on and do it. And if that thing to report about proves to be interesting enough for the IETF to care, *then* can it be blessed by putting it into the IETF URN tree. Again, very similar to VSAs. Greetings, Stefan Winter >=20 >=20 > Stefan - Spending time uselessly arguing on > off-topic aspects doesn't contribute to a solution. >=20 > Agreed. I suggest to ask the chairs to solve the argument between us. O= K? >=20 >=20 > Best Regards, > Leaf > =20 > =20 > =20 > ________________________________________ > From: radext-bounces@ietf.org [radext-bounces@ietf.org] on behalf of St= efan Winter [stefan.winter@restena.lu] > Sent: Thursday, July 12, 2012 21:32 > To: radext@ietf.org > Subject: Re: [radext] Fwd: New Version Notification for draft-winter-ra= dext-fancyaccounting-01.txt >=20 >=20 >> Welcome debate or competition on the same topic: RADIUS Accounting Ext= ensions for Traffic Statistics. Hope the WG could figure out the solution= on this topic soon. The problem looks not so difficult. >=20 > Indeed. The main question seems to be: should the format be extensible > to support arbitrary accounting needs? Or should it be limited to a few= > fixed values, centrally managed by the IETF? >=20 > I argue for the first, you for the second. >=20 >> Stefan - This is the consequence of Leaf's decision to first suggest n= umerous other, inferior, approaches, and then, when these were repelled, = copying the approach from my -00 with slightly different wording with his= name as the author; unsurprisingly, the two drafts are now very close to= each other.=20 >> >> History on this topic in my memory for your correction: >> 1. draft-yeh-radext-dual-stack-access-00 (2011-3-7) put forward the t= opic & 1st solution of RADIUS Accounting Extensions for Traffic Statistic= s for dual stack, and presented in IETF80; >> 2. After IETF80 Radext session, draft-winter-radext-fancyaccounting-0= 0 (2011-3-31) put forward the 2nd solution of TLV with extended-type spac= e; >> 3. draft-yeh-radext-dual-stack-access-02 expired in 2011-09-30 >> 4. draft-winter-radext-fancyaccounting-00 expired in 2011-10-02 >> 5. The IETF82 presentation (http://www.ietf.org/proceedings/82/slides= /radext-2.pdf ) with draft-yeh-radext-ext-traffic-statistics-01 re-trigge= red the discussion on the attribute design of Acct-Traffic-Statistics; >> 6. After got the hint in the meeting minutes of Radext IETF82 (http:/= /www.ietf.org/mail-archive/web/radext/current/msg07489.html ), I asked fo= r the cooperation with Stefan on this topic several times, but it looks t= o bump; >> 7. After the discussion on the mailing list of Radext, draft-yeh-rade= xt-ext-traffic-statistics-02 adopted the date type of nesting-TLV; >> 8. Around more than 1 week before I submitted draft-yeh-radext-ext-tr= affic-statistics-03, I asked Stefan for his revision and cooperation on m= y draft again, but failed. >=20 > Thanks for this timeline - it perfectly proves my point. The TLV > structure was first introduced in your point 2 by me. It reappeared in > point 7. - This time, the author was you, while the concept was the sam= e. >=20 > The fact that you repeatedly put up slides in the time between 2 and 7 > which were calling the TLV approach "design 3" does not mean it was you= r > idea and design. The draft, idea and structure were there long before > you did that. >=20 > In that light, isn't it understandable that I don't fancy becoming a > co-author of "your" draft with you as an editor? >=20 > If that's not a sufficient justification for me being upset, here's > another one: following IETF80, I created fancyaccounting-00 because I > was trying to *help* you - you presented a good problem statement, and = I > had an easy solution in my mind. And yet, when I uploaded it *and* got > positive feedback from the WG, you indicated that you are not intereste= d > in the topic in a subsequent meeting, making it all stall. That is not = nice. >=20 > That's my only reply on that topic. Spending time uselessly arguing on > off-topic aspects doesn't contribute to a solution. >=20 >> Stefan - I believe my draft is more thorough and thought-out in many a= spects. The only difference is that his draft has an integer enumerator f= or traffic classes, while my draft uses a string.=20 >> >> The above 2 statements sounds contradictory. >=20 > Not at all. My previous mail contained reasons and argument why I did > it, and it enumerated why it is a good idea. >=20 > Your reply conveniently cuts out these, and doesn't present > counter-arguments against them. You just state you don't like it. Too b= ad. >=20 >> Stefan - The string can do the same well-defined enumeration of known = traffic classes that the integer can also do, and more. >> >> This sounds something real on the aspect of technology or Radius attri= bute design, which asks for the discussion within the WG. >=20 > Indeed. >=20 > Stefan Winter >=20 >> >> >> Best Regards, >> Leaf >> >> >> -----Original Message----- >> From: radext-bounces@ietf.org [mailto:radext-bounces@ietf.org] On Beha= lf Of Stefan Winter >> Sent: Thursday, July 12, 2012 4:20 PM >> To: radext@ietf.org >> Subject: [radext] Fwd: New Version Notification for draft-winter-radex= t-fancyaccounting-01.txt >> >> Hello, >> >> since the interest on the topic of RADIUS Accounting for subsets of th= e total traffic has risen again, I have revived my old, expired -00 versi= on of "fancyaccounting". The major change to -00 is that I drop the enume= rated integer as a means to express which traffic is counted, and use onl= y the string type instead. >> >> Realising that a known vocabulary of traffic classes is useful for int= er-op between ISPs, I introduced an - optional - fixed syntax for specifi= c accounting traffic classes by using URNs. Among those is, of course, IP= v6, as this was the original trigger for the accounting traffic class dis= cussion. >> >> The advantage of the URN/freetext model is that it can be expanded arb= itrarily and yet have a defined meaning; while still allowing a local adm= in to count "whatever" by choosing not to use a URN. I would like to than= k Klaas Wierenga for his inspiration in that regard! >> >> The other changes are cleanups (move of Integer64 to radius-extensions= ) and tighter semenatic requirements of when to send what; including a wa= y to express which bytes exactly to count - a suggestion I got some 2 yea= rs ago when discussing -00. >> >> This is an individual submission which is in sort of a competition wit= h draft-yeh-radext-ext-traffic-statistics. This is the consequence of Lea= f's decision to first suggest numerous other, inferior, approaches, and t= hen, when these were repelled, copying the approach from my -00 with slig= htly different wording with his name as the author; unsurprisingly, the t= wo drafts are now very close to each other. I believe my draft is more th= orough and thought-out in many aspects. The only difference is that his d= raft has an integer enumerator for traffic classes, while my draft uses a= string. The string can do the same well-defined enumeration of known tra= ffic classes that the integer can also do, and more. >> >> If the re-charter with an explicit mention of "RADIUS Accounting Exten= sions for Traffic Statistics" gets adopted, I would like to suggest adopt= ing my draft for that topic. >> >> Greetings, >> >> Stefan Winter >> >> >> -------- Original Message -------- >> Subject: New Version Notification for >> draft-winter-radext-fancyaccounting-01.txt >> Date: Thu, 12 Jul 2012 01:16:54 -0700 >> From: internet-drafts@ietf.org >> To: stefan.winter@restena.lu >> >> >> A new version of I-D, draft-winter-radext-fancyaccounting-01.txt >> has been successfully submitted by Stefan Winter and posted to the IET= F repository. >> >> Filename: draft-winter-radext-fancyaccounting >> Revision: 01 >> Title: RADIUS Accounting for traffic classes >> Creation date: 2012-07-12 >> WG ID: Individual Submission >> Number of pages: 9 >> URL: >> http://www.ietf.org/internet-drafts/draft-winter-radext-fancyaccountin= g-01.txt >> Status: >> http://datatracker.ietf.org/doc/draft-winter-radext-fancyaccounting >> Htmlized: >> http://tools.ietf.org/html/draft-winter-radext-fancyaccounting-01 >> Diff: >> http://tools.ietf.org/rfcdiff?url2=3Ddraft-winter-radext-fancyaccounti= ng-01 >> >> Abstract: >> This document specifies new attributes for RADIUS Accounting to >> enable NAS reporting of subsets of the total traffic in a user >> session. >> >> >> >> >> >> The IETF Secretariat >> >> >> >> _______________________________________________ >> radext mailing list >> radext@ietf.org >> https://www.ietf.org/mailman/listinfo/radext >> >=20 >=20 --=20 Stefan WINTER Ingenieur de Recherche Fondation RESTENA - R=E9seau T=E9l=E9informatique de l'Education National= e et de la Recherche 6, rue Richard Coudenhove-Kalergi L-1359 Luxembourg Tel: +352 424409 1 Fax: +352 422473 --------------enigCEF8043BD5FBC64D9E67C416 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.0.18 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAlAASEMACgkQ+jm90f8eFWZIKACghKf8kC24Fp/wSkR91MVZ7YU2 CrgAnRaxE09eP+5Av7MrfKfMcBCCqMuF =vQqA -----END PGP SIGNATURE----- --------------enigCEF8043BD5FBC64D9E67C416-- --===============7890619196668101927== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ radext mailing list radext@ietf.org https://www.ietf.org/mailman/listinfo/radext --===============7890619196668101927==-- From dnelson@elbrys.com Fri Jul 13 12:04:48 2012 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 4474121F86D0 for ; Fri, 13 Jul 2012 12:04:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.976 X-Spam-Level: X-Spam-Status: No, score=-2.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YGX6MgHQp-PS for ; Fri, 13 Jul 2012 12:04:47 -0700 (PDT) Received: from mail-vc0-f172.google.com (mail-vc0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 1541921F86EA for ; Fri, 13 Jul 2012 12:04:46 -0700 (PDT) Received: by vcbfo14 with SMTP id fo14so905416vcb.31 for ; Fri, 13 Jul 2012 12:05:23 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=/yYMkYXTKVviA8tA2ATDeNH+shkywCurgNd0nF5rURA=; b=YmI6t17N1hSRYXbutDGtPp/2FVJOaOWUUg3Ie7AMqskgMVZC5dlLETme+kt+i5s0d2 37rXIddUTj6rp7cYJrOEQvXNKUJrPUeHvVVSYBUWqQrV0whbt3GWQpc31nCByuRnzqxe R6Ix+uu2rjjWIWuXLvTFlIttK6PJsbF3NiPKpB6qiwItK87hgw7BeUnZiNhTjTCz7zC+ K7lfGWjGWnhV+JcM2YMrPLy983S/VO9S76WACRnokA5ZKROpqhiq055N1KZWOzdeR95u SA0I8pmI3vdySY8HeuXzryzAl3gEIJH5TAZ7QKoS+erZa4YrANg9l2INnedw7/WnXFIA 0ztw== MIME-Version: 1.0 Received: by 10.220.239.196 with SMTP id kx4mr1131170vcb.25.1342206323039; Fri, 13 Jul 2012 12:05:23 -0700 (PDT) Received: by 10.52.183.137 with HTTP; Fri, 13 Jul 2012 12:05:23 -0700 (PDT) In-Reply-To: <5000483E.5030800@restena.lu> References: <20120712081654.17566.87131.idtracker@ietfa.amsl.com> <4FFE8893.30402@restena.lu> <4FFED1D3.7060706@restena.lu> <5000483E.5030800@restena.lu> Date: Fri, 13 Jul 2012 15:05:23 -0400 Message-ID: From: Dave Nelson To: Stefan Winter Content-Type: multipart/alternative; boundary=14dae9cdbf03199f5c04c4bac388 X-Gm-Message-State: ALoCoQnvhDxXAFHVJqjOc9fFEqHaVFFhhx2t3vZDKoK/zmUAtzQ5RDNqUFIo7wa3ThkNmXDxBrdR Cc: radext@ietf.org Subject: Re: [radext] Fwd: New Version Notification for draft-winter-radext-fancyaccounting-01.txt X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 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 Jul 2012 19:04:48 -0000 --14dae9cdbf03199f5c04c4bac388 Content-Type: text/plain; charset=ISO-8859-1 I haven't read the (competing?) drafts in a while, but one issue in your most recent mail caught my attention. What's the fundamental difference between a string type encoding using an (unregistered) user-private URN namespace and a Vendor Specific Enumeration for an integer type? The latter is an officially discouraged technique, in the RADIUS Design Guidelines, as I recall. Flexibility for small users, who can't be bothered with managed namespaces and codepoints is all well and good, but it seems to me that the purpose of doing work in the IETF is to guarantee a high level multi-vendor interoperability by formally defining such things. No? Regards, Dave David B. Nelson Director of Technology Elbrys Networks, Inc. www.elbrys.com +1.603.570.2636 --14dae9cdbf03199f5c04c4bac388 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I haven't read=A0the=A0(competing?) drafts in a while, but one issue in= your most recent mail=A0caught=A0my attention.

What'= ;s the fundamental difference between a string type encoding using an (unre= gistered) user-private URN namespace and a Vendor Specific=A0Enumeration fo= r an=A0integer=A0type?=A0 The=A0latter=A0is an=A0officially=A0discouraged t= echnique, in the RADIUS Design=A0Guidelines, as I recall.

Flexibility for small users, who can't be bothered = with managed namespaces and codepoints is all well and good, but it seems t= o me that the purpose of doing work in=A0the=A0IETF is to=A0guarantee=A0a h= igh level multi-vendor=A0interoperability=A0by formally defining such thing= s. =A0No?

Regards,

Dave

David= B. Nelson
Director of Technology
Elbrys Networks, Inc.
www.elbrys.com
+1.603.570.= 2636
--14dae9cdbf03199f5c04c4bac388-- From radext-bounces@ietf.org Fri Jul 13 12:04:50 2012 Return-Path: X-Original-To: radext-archive-IeZ9sae2@lists.ietf.org Delivered-To: ietfarch-radext-archive-IeZ9sae2@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 30B3121F86F2; Fri, 13 Jul 2012 12:04:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1342206290; bh=KEyiSamTCf+6iJ58frfjsuXRBbaWSRqWgSzR7auyDjk=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:From:To:Cc: Subject:List-Id:List-Unsubscribe:List-Archive:List-Post:List-Help: List-Subscribe:Content-Type:Sender; b=WMYG9YHwD41ymrc/0+PktM1L+c7CAurGlc4OcAGj2EDy49sIJTRUi75o8KGVjV1DV /Oj8VioLfo3EwfY7rWRP3G5VgI8QOFt76isjRud6dPDxtsuEX6BfxDgsTrnvxM9CUr wZOqmIZGz6VOav3B404yj9S5xr/+yB+jZfKES9QA= 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 4474121F86D0 for ; Fri, 13 Jul 2012 12:04:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.976 X-Spam-Level: X-Spam-Status: No, score=-2.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YGX6MgHQp-PS for ; Fri, 13 Jul 2012 12:04:47 -0700 (PDT) Received: from mail-vc0-f172.google.com (mail-vc0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 1541921F86EA for ; Fri, 13 Jul 2012 12:04:46 -0700 (PDT) Received: by vcbfo14 with SMTP id fo14so905416vcb.31 for ; Fri, 13 Jul 2012 12:05:23 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=/yYMkYXTKVviA8tA2ATDeNH+shkywCurgNd0nF5rURA=; b=YmI6t17N1hSRYXbutDGtPp/2FVJOaOWUUg3Ie7AMqskgMVZC5dlLETme+kt+i5s0d2 37rXIddUTj6rp7cYJrOEQvXNKUJrPUeHvVVSYBUWqQrV0whbt3GWQpc31nCByuRnzqxe R6Ix+uu2rjjWIWuXLvTFlIttK6PJsbF3NiPKpB6qiwItK87hgw7BeUnZiNhTjTCz7zC+ K7lfGWjGWnhV+JcM2YMrPLy983S/VO9S76WACRnokA5ZKROpqhiq055N1KZWOzdeR95u SA0I8pmI3vdySY8HeuXzryzAl3gEIJH5TAZ7QKoS+erZa4YrANg9l2INnedw7/WnXFIA 0ztw== MIME-Version: 1.0 Received: by 10.220.239.196 with SMTP id kx4mr1131170vcb.25.1342206323039; Fri, 13 Jul 2012 12:05:23 -0700 (PDT) Received: by 10.52.183.137 with HTTP; Fri, 13 Jul 2012 12:05:23 -0700 (PDT) In-Reply-To: <5000483E.5030800@restena.lu> References: <20120712081654.17566.87131.idtracker@ietfa.amsl.com> <4FFE8893.30402@restena.lu> <4FFED1D3.7060706@restena.lu> <5000483E.5030800@restena.lu> Date: Fri, 13 Jul 2012 15:05:23 -0400 Message-ID: From: Dave Nelson To: Stefan Winter X-Gm-Message-State: ALoCoQnvhDxXAFHVJqjOc9fFEqHaVFFhhx2t3vZDKoK/zmUAtzQ5RDNqUFIo7wa3ThkNmXDxBrdR Cc: radext@ietf.org Subject: Re: [radext] Fwd: New Version Notification for draft-winter-radext-fancyaccounting-01.txt X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============4831236664672113907==" Sender: radext-bounces@ietf.org Errors-To: radext-bounces@ietf.org --===============4831236664672113907== Content-Type: multipart/alternative; boundary=14dae9cdbf03199f5c04c4bac388 --14dae9cdbf03199f5c04c4bac388 Content-Type: text/plain; charset=ISO-8859-1 I haven't read the (competing?) drafts in a while, but one issue in your most recent mail caught my attention. What's the fundamental difference between a string type encoding using an (unregistered) user-private URN namespace and a Vendor Specific Enumeration for an integer type? The latter is an officially discouraged technique, in the RADIUS Design Guidelines, as I recall. Flexibility for small users, who can't be bothered with managed namespaces and codepoints is all well and good, but it seems to me that the purpose of doing work in the IETF is to guarantee a high level multi-vendor interoperability by formally defining such things. No? Regards, Dave David B. Nelson Director of Technology Elbrys Networks, Inc. www.elbrys.com +1.603.570.2636 --14dae9cdbf03199f5c04c4bac388 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I haven't read=A0the=A0(competing?) drafts in a while, but one issue in= your most recent mail=A0caught=A0my attention.

What'= ;s the fundamental difference between a string type encoding using an (unre= gistered) user-private URN namespace and a Vendor Specific=A0Enumeration fo= r an=A0integer=A0type?=A0 The=A0latter=A0is an=A0officially=A0discouraged t= echnique, in the RADIUS Design=A0Guidelines, as I recall.

Flexibility for small users, who can't be bothered = with managed namespaces and codepoints is all well and good, but it seems t= o me that the purpose of doing work in=A0the=A0IETF is to=A0guarantee=A0a h= igh level multi-vendor=A0interoperability=A0by formally defining such thing= s. =A0No?

Regards,

Dave

David= B. Nelson
Director of Technology
Elbrys Networks, Inc.
www.elbrys.com
+1.603.570.= 2636
--14dae9cdbf03199f5c04c4bac388-- --===============4831236664672113907== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ radext mailing list radext@ietf.org https://www.ietf.org/mailman/listinfo/radext --===============4831236664672113907==-- From radext-bounces@ietf.org Fri Jul 13 15:10:34 2012 Return-Path: X-Original-To: radext-archive-IeZ9sae2@lists.ietf.org Delivered-To: ietfarch-radext-archive-IeZ9sae2@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D475F11E812F; Fri, 13 Jul 2012 15:10:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1342217434; bh=oLkvv//Fos3hKrgBYwC8+s3CiazP8vY7DJddE0gypsU=; h=Message-ID:Date:From:MIME-Version:To:References:In-Reply-To:Cc: Subject:List-Id:List-Unsubscribe:List-Archive:List-Post:List-Help: List-Subscribe:Content-Type:Content-Transfer-Encoding:Sender; b=n3h4vQpf70LsGRI22mbgsm3i5Npbp6f/VXcBa2GF4DS5dDCOhLwbXg0xLk6scalYU hEN++DSNrA5+jWYMtzIBIxIIybp7JpyKEek5QjORRVyr909mNlkt/7hGZ5xxGQg0nR wfJqXOZsPhiouOA+gaj+K3ugUkZwhpApa2mxC35A= 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 90E8711E812D for ; Fri, 13 Jul 2012 15:10:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HY1mM9xfXaKk for ; Fri, 13 Jul 2012 15:10:32 -0700 (PDT) Received: from liberty.deployingradius.com (liberty.deployingradius.com [88.191.76.128]) by ietfa.amsl.com (Postfix) with ESMTP id CE29311E812F for ; Fri, 13 Jul 2012 15:10:31 -0700 (PDT) Message-ID: <50009CEA.1030405@deployingradius.com> Date: Fri, 13 Jul 2012 18:10:50 -0400 From: Alan DeKok User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: Leaf yeh References: <20120709040655.15521.56871.idtracker@ietfa.amsl.com> <4FFDAD25.2020208@deployingradius.com> In-Reply-To: X-Enigmail-Version: 0.96.0 Cc: "" Subject: Re: [radext] New Version Notification for draft-yeh-radext-ext-traffic-statistics-03.txt X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: radext-bounces@ietf.org Errors-To: radext-bounces@ietf.org Leaf yeh wrote: > Alan - My comments are already on record. > > It is apparent I've missed your records on the List Archive. > Could you explicitly express your concerns or comments here again? Read the list archives. Alan DeKok. _______________________________________________ radext mailing list radext@ietf.org https://www.ietf.org/mailman/listinfo/radext From aland@deployingradius.com Fri Jul 13 15:10:32 2012 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 90E8711E812D for ; Fri, 13 Jul 2012 15:10:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HY1mM9xfXaKk for ; Fri, 13 Jul 2012 15:10:32 -0700 (PDT) Received: from liberty.deployingradius.com (liberty.deployingradius.com [88.191.76.128]) by ietfa.amsl.com (Postfix) with ESMTP id CE29311E812F for ; Fri, 13 Jul 2012 15:10:31 -0700 (PDT) Message-ID: <50009CEA.1030405@deployingradius.com> Date: Fri, 13 Jul 2012 18:10:50 -0400 From: Alan DeKok User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: Leaf yeh References: <20120709040655.15521.56871.idtracker@ietfa.amsl.com> <4FFDAD25.2020208@deployingradius.com> In-Reply-To: X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "" Subject: Re: [radext] New Version Notification for draft-yeh-radext-ext-traffic-statistics-03.txt X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 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 Jul 2012 22:10:33 -0000 Leaf yeh wrote: > Alan - My comments are already on record. > > It is apparent I've missed your records on the List Archive. > Could you explicitly express your concerns or comments here again? Read the list archives. Alan DeKok. From aland@deployingradius.com Sat Jul 14 07:35:20 2012 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 A801421F85A3 for ; Sat, 14 Jul 2012 07:35:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.064 X-Spam-Level: X-Spam-Status: No, score=-102.064 tagged_above=-999 required=5 tests=[AWL=-0.535, BAYES_00=-2.599, DATE_IN_PAST_06_12=1.069, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7z-rcvBvZE50 for ; Sat, 14 Jul 2012 07:35:19 -0700 (PDT) Received: from liberty.deployingradius.com (liberty.deployingradius.com [88.191.76.128]) by ietfa.amsl.com (Postfix) with ESMTP id 9E33C21F84C8 for ; Sat, 14 Jul 2012 07:35:19 -0700 (PDT) Message-ID: <5000DDAB.2070408@deployingradius.com> Date: Fri, 13 Jul 2012 22:47:07 -0400 From: Alan DeKok User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: Stefan Winter References: <20120712081654.17566.87131.idtracker@ietfa.amsl.com> <4FFE8893.30402@restena.lu> In-Reply-To: <4FFE8893.30402@restena.lu> X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "radext@ietf.org" Subject: Re: [radext] Fwd: New Version Notification for draft-winter-radext-fancyaccounting-01.txt X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 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, 14 Jul 2012 14:35:20 -0000 Stefan Winter wrote: > since the interest on the topic of RADIUS Accounting for subsets of the > total traffic has risen again, I have revived my old, expired -00 > version of "fancyaccounting". The major change to -00 is that I drop the > enumerated integer as a means to express which traffic is counted, and > use only the string type instead. I have concerns with that. > Realising that a known vocabulary of traffic classes is useful for > inter-op between ISPs, I introduced an - optional - fixed syntax for > specific accounting traffic classes by using URNs. Among those is, of > course, IPv6, as this was the original trigger for the accounting > traffic class discussion. RFC 4849 defines the NAS-Filter-Rule attribute. It's based on the RFC3588 IPFilterRule, which is in turn largely FreeBSD firewall rules. Why not just leverage that? There's no need to have a new registry (string or integer) for traffic classes. Instead, just describe the traffic by the filter rules it matches. That allowss for nearly unlimited flexibility, without creating any new standard or registry. > If the re-charter with an explicit mention of "RADIUS Accounting > Extensions for Traffic Statistics" gets adopted, I would like to suggest > adopting my draft for that topic. I would like a discussion around the definition of traffic classes. But the document is largely OK for me. Alan DeKok. From radext-bounces@ietf.org Sat Jul 14 07:35:22 2012 Return-Path: X-Original-To: radext-archive-IeZ9sae2@lists.ietf.org Delivered-To: ietfarch-radext-archive-IeZ9sae2@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8B2AE21F85A3; Sat, 14 Jul 2012 07:35:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1342276522; bh=CfdKbGWdCMWxXj6ih1PGhwGCKFFhtYGeg+o5eQ5OSs4=; h=Message-ID:Date:From:MIME-Version:To:References:In-Reply-To:Cc: Subject:List-Id:List-Unsubscribe:List-Archive:List-Post:List-Help: List-Subscribe:Content-Type:Content-Transfer-Encoding:Sender; b=D8H5V9OFzahGyhX38lyZ6qBo6cZU71G7botMP7kLiEdTECIxe0IlC1Rh4c6bLA02H /vv7AU7fNAkYVZmPRR/ZP8qbLZJtfZEWZpo1ZOlSwE7k4SKMClLdwnX9LCdwHOjwV4 JvPcjZzKAIV+AYpjrxDJTj+YEBdOKuxsEIV5wEbs= 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 A801421F85A3 for ; Sat, 14 Jul 2012 07:35:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.064 X-Spam-Level: X-Spam-Status: No, score=-102.064 tagged_above=-999 required=5 tests=[AWL=-0.535, BAYES_00=-2.599, DATE_IN_PAST_06_12=1.069, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7z-rcvBvZE50 for ; Sat, 14 Jul 2012 07:35:19 -0700 (PDT) Received: from liberty.deployingradius.com (liberty.deployingradius.com [88.191.76.128]) by ietfa.amsl.com (Postfix) with ESMTP id 9E33C21F84C8 for ; Sat, 14 Jul 2012 07:35:19 -0700 (PDT) Message-ID: <5000DDAB.2070408@deployingradius.com> Date: Fri, 13 Jul 2012 22:47:07 -0400 From: Alan DeKok User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: Stefan Winter References: <20120712081654.17566.87131.idtracker@ietfa.amsl.com> <4FFE8893.30402@restena.lu> In-Reply-To: <4FFE8893.30402@restena.lu> X-Enigmail-Version: 0.96.0 Cc: "radext@ietf.org" Subject: Re: [radext] Fwd: New Version Notification for draft-winter-radext-fancyaccounting-01.txt X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: radext-bounces@ietf.org Errors-To: radext-bounces@ietf.org Stefan Winter wrote: > since the interest on the topic of RADIUS Accounting for subsets of the > total traffic has risen again, I have revived my old, expired -00 > version of "fancyaccounting". The major change to -00 is that I drop the > enumerated integer as a means to express which traffic is counted, and > use only the string type instead. I have concerns with that. > Realising that a known vocabulary of traffic classes is useful for > inter-op between ISPs, I introduced an - optional - fixed syntax for > specific accounting traffic classes by using URNs. Among those is, of > course, IPv6, as this was the original trigger for the accounting > traffic class discussion. RFC 4849 defines the NAS-Filter-Rule attribute. It's based on the RFC3588 IPFilterRule, which is in turn largely FreeBSD firewall rules. Why not just leverage that? There's no need to have a new registry (string or integer) for traffic classes. Instead, just describe the traffic by the filter rules it matches. That allowss for nearly unlimited flexibility, without creating any new standard or registry. > If the re-charter with an explicit mention of "RADIUS Accounting > Extensions for Traffic Statistics" gets adopted, I would like to suggest > adopting my draft for that topic. I would like a discussion around the definition of traffic classes. But the document is largely OK for me. Alan DeKok. _______________________________________________ radext mailing list radext@ietf.org https://www.ietf.org/mailman/listinfo/radext From aland@deployingradius.com Sat Jul 14 07:35:29 2012 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 C922F21F85F7 for ; Sat, 14 Jul 2012 07:35:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.54 X-Spam-Level: X-Spam-Status: No, score=-102.54 tagged_above=-999 required=5 tests=[AWL=0.059, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RsJqE-QTcO25 for ; Sat, 14 Jul 2012 07:35:29 -0700 (PDT) Received: from liberty.deployingradius.com (liberty.deployingradius.com [88.191.76.128]) by ietfa.amsl.com (Postfix) with ESMTP id 3A98D21F84C8 for ; Sat, 14 Jul 2012 07:35:29 -0700 (PDT) Message-ID: <50016238.9030509@deployingradius.com> Date: Sat, 14 Jul 2012 08:12:40 -0400 From: Alan DeKok User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: Peter Deacon References: <20120712081654.17566.87131.idtracker@ietfa.amsl.com> <4FFE8893.30402@restena.lu> <4FFED600.3000109@restena.lu> In-Reply-To: X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Stefan Winter , "radext@ietf.org" Subject: Re: [radext] Fwd: New Version Notification for draft-winter-radext-fancyaccounting-01.txt X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 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, 14 Jul 2012 14:35:29 -0000 Peter Deacon wrote: > On Thu, 12 Jul 2012, Stefan Winter wrote: >> A concern of mine was that a NAS might send a value in an >> Interim-Update, but then not report the same type of data in the Stop >> packet. Such NASes should be burned with fire. > Agree. I think at point where a class or any sub-attribute of the class > appears in an interim it should be required to be sent in all subsequent > interims and stop record. Forgetting should not be an option. I agree. Alan DeKok. From radext-bounces@ietf.org Sat Jul 14 07:35:31 2012 Return-Path: X-Original-To: radext-archive-IeZ9sae2@lists.ietf.org Delivered-To: ietfarch-radext-archive-IeZ9sae2@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 24C1521F85F7; Sat, 14 Jul 2012 07:35:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1342276531; bh=562WNFzwDxNtPIwyTEN7uqmoJnXeNbLn0PLxtkUByaM=; h=Message-ID:Date:From:MIME-Version:To:References:In-Reply-To:Cc: Subject:List-Id:List-Unsubscribe:List-Archive:List-Post:List-Help: List-Subscribe:Content-Type:Content-Transfer-Encoding:Sender; b=a8o8Kmbhl2ACwRCU1p6w8vcDaZzl+vEMrOE7k6t5jj326l8uAIKmHEWTA3+Sp8riH FP9mMkEBrC4FCVwvDSni9UwFPZJeku3rpRlrjtazO1zREUOhRo2IqCa5UhAA82LGPR ytDkg78SDNrOkIY0sL191iKEHE+J3aeszWIfSz/g= 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 C922F21F85F7 for ; Sat, 14 Jul 2012 07:35:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.54 X-Spam-Level: X-Spam-Status: No, score=-102.54 tagged_above=-999 required=5 tests=[AWL=0.059, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RsJqE-QTcO25 for ; Sat, 14 Jul 2012 07:35:29 -0700 (PDT) Received: from liberty.deployingradius.com (liberty.deployingradius.com [88.191.76.128]) by ietfa.amsl.com (Postfix) with ESMTP id 3A98D21F84C8 for ; Sat, 14 Jul 2012 07:35:29 -0700 (PDT) Message-ID: <50016238.9030509@deployingradius.com> Date: Sat, 14 Jul 2012 08:12:40 -0400 From: Alan DeKok User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: Peter Deacon References: <20120712081654.17566.87131.idtracker@ietfa.amsl.com> <4FFE8893.30402@restena.lu> <4FFED600.3000109@restena.lu> In-Reply-To: X-Enigmail-Version: 0.96.0 Cc: Stefan Winter , "radext@ietf.org" Subject: Re: [radext] Fwd: New Version Notification for draft-winter-radext-fancyaccounting-01.txt X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: radext-bounces@ietf.org Errors-To: radext-bounces@ietf.org Peter Deacon wrote: > On Thu, 12 Jul 2012, Stefan Winter wrote: >> A concern of mine was that a NAS might send a value in an >> Interim-Update, but then not report the same type of data in the Stop >> packet. Such NASes should be burned with fire. > Agree. I think at point where a class or any sub-attribute of the class > appears in an interim it should be required to be sent in all subsequent > interims and stop record. Forgetting should not be an option. I agree. Alan DeKok. _______________________________________________ radext mailing list radext@ietf.org https://www.ietf.org/mailman/listinfo/radext From aland@deployingradius.com Sat Jul 14 07:35:34 2012 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 EFEE921F8692 for ; Sat, 14 Jul 2012 07:35:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.546 X-Spam-Level: X-Spam-Status: No, score=-102.546 tagged_above=-999 required=5 tests=[AWL=0.053, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w0MBgkqYFyn2 for ; Sat, 14 Jul 2012 07:35:34 -0700 (PDT) Received: from liberty.deployingradius.com (liberty.deployingradius.com [88.191.76.128]) by ietfa.amsl.com (Postfix) with ESMTP id 3C6C521F84C8 for ; Sat, 14 Jul 2012 07:35:34 -0700 (PDT) Message-ID: <50016370.3090906@deployingradius.com> Date: Sat, 14 Jul 2012 08:17:52 -0400 From: Alan DeKok User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: Stefan Winter References: <20120712081654.17566.87131.idtracker@ietfa.amsl.com> <4FFE8893.30402@restena.lu> <4FFED600.3000109@restena.lu> In-Reply-To: <4FFED600.3000109@restena.lu> X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "radext@ietf.org" , Peter Deacon Subject: Re: [radext] Fwd: New Version Notification for draft-winter-radext-fancyaccounting-01.txt X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 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, 14 Jul 2012 14:35:35 -0000 Stefan Winter wrote: >> Perhaps a separate container group to signal limits via Access-Accept >> enforced by NAS: >> >> Limit-Traffic-Class >> Limit-Traffic-Class-Name >> Limit-Traffic-Class-Input-Octets >> Limit-Traffic-Class-Output-Octets >> >> 'd volunteer text if theres interest and this is not too much scope creep. > > This part I'm not so comfortable with - at least in the scope of the > current draft. I see Accounting as a one-way flow from the NAS to the > RADIUS server to report about the current reality of a user session. While I agree it's useful, I think it should be out of scope of the accounting document. > Undoubtedly, being able to send Time or Data limits from the RADIUS > server to the NAS is also useful, but it's a different topic IMHO, worth > its own draft. I agree. Alan DeKok. From radext-bounces@ietf.org Sat Jul 14 07:35:36 2012 Return-Path: X-Original-To: radext-archive-IeZ9sae2@lists.ietf.org Delivered-To: ietfarch-radext-archive-IeZ9sae2@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AAABB21F869D; Sat, 14 Jul 2012 07:35:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1342276536; bh=E8KZ5/OG8APlj07aB/JjsK9OxJ/CItgE20v8n7C7Vxw=; h=Message-ID:Date:From:MIME-Version:To:References:In-Reply-To:Cc: Subject:List-Id:List-Unsubscribe:List-Archive:List-Post:List-Help: List-Subscribe:Content-Type:Content-Transfer-Encoding:Sender; b=hrmxTznsSdLjUIG91LOLzfO+CAPzTfZVL6CF4QKLRiKwx3rrJo5H0utoUey5Pu/6C DWrTjAeW+EiAo2bQL8BoXlM9aNvXXQk6CW1dVvyfY0ajgzsdwMQDQ8z+TpVlsY0XEf Hs4CRP+Cgq+W4w05rVToWcrrQdotl2fUZ+/fNyXU= 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 EFEE921F8692 for ; Sat, 14 Jul 2012 07:35:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.546 X-Spam-Level: X-Spam-Status: No, score=-102.546 tagged_above=-999 required=5 tests=[AWL=0.053, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w0MBgkqYFyn2 for ; Sat, 14 Jul 2012 07:35:34 -0700 (PDT) Received: from liberty.deployingradius.com (liberty.deployingradius.com [88.191.76.128]) by ietfa.amsl.com (Postfix) with ESMTP id 3C6C521F84C8 for ; Sat, 14 Jul 2012 07:35:34 -0700 (PDT) Message-ID: <50016370.3090906@deployingradius.com> Date: Sat, 14 Jul 2012 08:17:52 -0400 From: Alan DeKok User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: Stefan Winter References: <20120712081654.17566.87131.idtracker@ietfa.amsl.com> <4FFE8893.30402@restena.lu> <4FFED600.3000109@restena.lu> In-Reply-To: <4FFED600.3000109@restena.lu> X-Enigmail-Version: 0.96.0 Cc: "radext@ietf.org" , Peter Deacon Subject: Re: [radext] Fwd: New Version Notification for draft-winter-radext-fancyaccounting-01.txt X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: radext-bounces@ietf.org Errors-To: radext-bounces@ietf.org Stefan Winter wrote: >> Perhaps a separate container group to signal limits via Access-Accept >> enforced by NAS: >> >> Limit-Traffic-Class >> Limit-Traffic-Class-Name >> Limit-Traffic-Class-Input-Octets >> Limit-Traffic-Class-Output-Octets >> >> 'd volunteer text if theres interest and this is not too much scope creep. > > This part I'm not so comfortable with - at least in the scope of the > current draft. I see Accounting as a one-way flow from the NAS to the > RADIUS server to report about the current reality of a user session. While I agree it's useful, I think it should be out of scope of the accounting document. > Undoubtedly, being able to send Time or Data limits from the RADIUS > server to the NAS is also useful, but it's a different topic IMHO, worth > its own draft. I agree. Alan DeKok. _______________________________________________ radext mailing list radext@ietf.org https://www.ietf.org/mailman/listinfo/radext From radext-bounces@ietf.org Sat Jul 14 22:51:55 2012 Return-Path: X-Original-To: radext-archive-IeZ9sae2@lists.ietf.org Delivered-To: ietfarch-radext-archive-IeZ9sae2@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7830B11E8087; Sat, 14 Jul 2012 22:51:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1342331515; bh=9HZ1KXl3pj6Hx/nzpfmgy3hmgr4ZhgFaYJSSWOu5f+M=; h=Date:From:To:In-Reply-To:Message-ID:References:MIME-Version:Cc: Subject:List-Id:List-Unsubscribe:List-Archive:List-Post:List-Help: List-Subscribe:Content-Transfer-Encoding:Content-Type:Sender; b=S7u8lQkhn5KVIiHylxlCcOYOQ54tevmrBVIX9Ax6sj9LuACEfhfTLPY8MoLc85opa L/trmpXhHrS4z5ZxjYIYKIDJwlNAjOc+AR7V/O9suWDn1O8hfpoWWyOyKlnvWnD3sP P59tyfqHtbYSA7GlXw5Mpuqri3LdOX5MCHlcXGCo= 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 6BC7811E8087 for ; Sat, 14 Jul 2012 22:51:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ceH0smh-N0fg for ; Sat, 14 Jul 2012 22:51:52 -0700 (PDT) Received: from aspen.internal.iea-software.com (remote.iea-software.com [70.89.142.196]) by ietfa.amsl.com (Postfix) with ESMTP id 8DE0811E8072 for ; Sat, 14 Jul 2012 22:51:50 -0700 (PDT) Received: from SMURF (unverified [10.0.3.195]) by aspen.internal.iea-software.com (Rockliffe SMTPRA 7.0.6) with ESMTP id ; Sat, 14 Jul 2012 22:52:54 -0700 Date: Sat, 14 Jul 2012 22:52:31 -0700 (Pacific Daylight Time) From: Peter Deacon To: Alan DeKok In-Reply-To: <5000DDAB.2070408@deployingradius.com> Message-ID: References: <20120712081654.17566.87131.idtracker@ietfa.amsl.com> <4FFE8893.30402@restena.lu> <5000DDAB.2070408@deployingradius.com> User-Agent: Alpine 2.00 (WNT 1167 2008-08-23) MIME-Version: 1.0 Cc: Stefan Winter , "radext@ietf.org" Subject: Re: [radext] Fwd: New Version Notification for draft-winter-radext-fancyaccounting-01.txt X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: radext-bounces@ietf.org Errors-To: radext-bounces@ietf.org On Fri, 13 Jul 2012, Alan DeKok wrote: > Stefan Winter wrote: >> since the interest on the topic of RADIUS Accounting for subsets of the >> total traffic has risen again, I have revived my old, expired -00 >> version of "fancyaccounting". The major change to -00 is that I drop the >> enumerated integer as a means to express which traffic is counted, and >> use only the string type instead. > I have concerns with that. >> Realising that a known vocabulary of traffic classes is useful for >> inter-op between ISPs, I introduced an - optional - fixed syntax for >> specific accounting traffic classes by using URNs. Among those is, of >> course, IPv6, as this was the original trigger for the accounting >> traffic class discussion. > RFC 4849 defines the NAS-Filter-Rule attribute. It's based on the > RFC3588 IPFilterRule, which is in turn largely FreeBSD firewall rules. > Why not just leverage that? There's no need to have a new registry > (string or integer) for traffic classes. Instead, just describe the > traffic by the filter rules it matches. > That allowss for nearly unlimited flexibility, without creating any > new standard or registry. Rules for production of accounting class data are configured OOB from RADIUS. It is not known what the NAS will choose as the basis for classification. It may choose to count non-IP flows or high level protocol exchanges. Either of which are impossible to describe using NAS filter rules. More importantly abstraction to set a named label in the NAS correlating to a counting goal in the accounting system is an important feature operationally as each NAS could have different filters to implement the same overall goal which may not be understood by accounting. For example I want to operate a roaming network using fancy accounting to count local traffic separately from traffic sent over the WAN. Each operator of each NAS defines what is local to itself. Two classes of attributes are sent "local" and "network". If you were to simply upload classes with filter rules the accounting systems of participants would be clueless to interpret what any of the filter definitions actually do as they only have meaning within the administrative domain of each NAS operator. regards, Peter _______________________________________________ radext mailing list radext@ietf.org https://www.ietf.org/mailman/listinfo/radext From peterd@iea-software.com Sat Jul 14 22:51:53 2012 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 6BC7811E8087 for ; Sat, 14 Jul 2012 22:51:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ceH0smh-N0fg for ; Sat, 14 Jul 2012 22:51:52 -0700 (PDT) Received: from aspen.internal.iea-software.com (remote.iea-software.com [70.89.142.196]) by ietfa.amsl.com (Postfix) with ESMTP id 8DE0811E8072 for ; Sat, 14 Jul 2012 22:51:50 -0700 (PDT) Received: from SMURF (unverified [10.0.3.195]) by aspen.internal.iea-software.com (Rockliffe SMTPRA 7.0.6) with ESMTP id ; Sat, 14 Jul 2012 22:52:54 -0700 Date: Sat, 14 Jul 2012 22:52:31 -0700 (Pacific Daylight Time) From: Peter Deacon To: Alan DeKok In-Reply-To: <5000DDAB.2070408@deployingradius.com> Message-ID: References: <20120712081654.17566.87131.idtracker@ietfa.amsl.com> <4FFE8893.30402@restena.lu> <5000DDAB.2070408@deployingradius.com> User-Agent: Alpine 2.00 (WNT 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: Stefan Winter , "radext@ietf.org" Subject: Re: [radext] Fwd: New Version Notification for draft-winter-radext-fancyaccounting-01.txt X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Jul 2012 05:51:53 -0000 On Fri, 13 Jul 2012, Alan DeKok wrote: > Stefan Winter wrote: >> since the interest on the topic of RADIUS Accounting for subsets of the >> total traffic has risen again, I have revived my old, expired -00 >> version of "fancyaccounting". The major change to -00 is that I drop the >> enumerated integer as a means to express which traffic is counted, and >> use only the string type instead. > I have concerns with that. >> Realising that a known vocabulary of traffic classes is useful for >> inter-op between ISPs, I introduced an - optional - fixed syntax for >> specific accounting traffic classes by using URNs. Among those is, of >> course, IPv6, as this was the original trigger for the accounting >> traffic class discussion. > RFC 4849 defines the NAS-Filter-Rule attribute. It's based on the > RFC3588 IPFilterRule, which is in turn largely FreeBSD firewall rules. > Why not just leverage that? There's no need to have a new registry > (string or integer) for traffic classes. Instead, just describe the > traffic by the filter rules it matches. > That allowss for nearly unlimited flexibility, without creating any > new standard or registry. Rules for production of accounting class data are configured OOB from RADIUS. It is not known what the NAS will choose as the basis for classification. It may choose to count non-IP flows or high level protocol exchanges. Either of which are impossible to describe using NAS filter rules. More importantly abstraction to set a named label in the NAS correlating to a counting goal in the accounting system is an important feature operationally as each NAS could have different filters to implement the same overall goal which may not be understood by accounting. For example I want to operate a roaming network using fancy accounting to count local traffic separately from traffic sent over the WAN. Each operator of each NAS defines what is local to itself. Two classes of attributes are sent "local" and "network". If you were to simply upload classes with filter rules the accounting systems of participants would be clueless to interpret what any of the filter definitions actually do as they only have meaning within the administrative domain of each NAS operator. regards, Peter From aland@deployingradius.com Sun Jul 15 14:41:02 2012 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 EB47421F84F3 for ; Sun, 15 Jul 2012 14:41:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.55 X-Spam-Level: X-Spam-Status: No, score=-102.55 tagged_above=-999 required=5 tests=[AWL=0.049, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Yl8-2hWecou3 for ; Sun, 15 Jul 2012 14:41:02 -0700 (PDT) Received: from liberty.deployingradius.com (liberty.deployingradius.com [88.191.76.128]) by ietfa.amsl.com (Postfix) with ESMTP id 55D0D21F84EE for ; Sun, 15 Jul 2012 14:41:02 -0700 (PDT) Message-ID: <500338FB.9070504@deployingradius.com> Date: Sun, 15 Jul 2012 17:41:15 -0400 From: Alan DeKok User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: Peter Deacon References: <20120712081654.17566.87131.idtracker@ietfa.amsl.com> <4FFE8893.30402@restena.lu> <5000DDAB.2070408@deployingradius.com> In-Reply-To: X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Stefan Winter , "radext@ietf.org" Subject: Re: [radext] Fwd: New Version Notification for draft-winter-radext-fancyaccounting-01.txt X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Jul 2012 21:41:03 -0000 Peter Deacon wrote: > Rules for production of accounting class data are configured OOB from > RADIUS. It is not known what the NAS will choose as the basis for > classification. Then how can the accounting data be interpreted? > It may choose to count non-IP flows or high level > protocol exchanges. Either of which are impossible to describe using > NAS filter rules. Both of those use-cases have a much smaller deployment than simple IP accounting. > For example I want to operate a roaming network using fancy accounting > to count local traffic separately from traffic sent over the WAN. Each > operator of each NAS defines what is local to itself. Two classes of > attributes are sent "local" and "network". How are these classes communicated to the other parties in the network? > If you were to simply upload classes with filter rules the accounting > systems of participants would be clueless to interpret what any of the > filter definitions actually do as they only have meaning within the > administrative domain of each NAS operator. Really? "tcp port 80" ? Or "ignore 10/8, 192.168/16, everything else is external, and billed as such". There are *some* cases where NAS filter definitions should be kept locally. There are *more* cases where they can be shared, and can be understood by other parties. Alan DeKok. From radext-bounces@ietf.org Sun Jul 15 14:41:05 2012 Return-Path: X-Original-To: radext-archive-IeZ9sae2@lists.ietf.org Delivered-To: ietfarch-radext-archive-IeZ9sae2@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F38FF21F84F5; Sun, 15 Jul 2012 14:41:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1342388465; bh=QyfqSNv9Px83rSeSs92iPOu8vOYz+3XDe8AWAyPVWaU=; h=Message-ID:Date:From:MIME-Version:To:References:In-Reply-To:Cc: Subject:List-Id:List-Unsubscribe:List-Archive:List-Post:List-Help: List-Subscribe:Content-Type:Content-Transfer-Encoding:Sender; b=vKLfjjWTFTsLMP7RJUONYBBrAhCgG6SB/bzRbP/gyJQoIASOI8QzDSpsz87NnT4Y6 JHEm6nDlqLQxd6yqxzSX9KLqQRWhf1ys/py7ufpEKGlE+gx9Y2dLG9GRAX8xEHwrzS wZDb8r5QR87jWirt7vNyDI8/NfWsfv6iprUkSwzo= 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 EB47421F84F3 for ; Sun, 15 Jul 2012 14:41:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.55 X-Spam-Level: X-Spam-Status: No, score=-102.55 tagged_above=-999 required=5 tests=[AWL=0.049, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Yl8-2hWecou3 for ; Sun, 15 Jul 2012 14:41:02 -0700 (PDT) Received: from liberty.deployingradius.com (liberty.deployingradius.com [88.191.76.128]) by ietfa.amsl.com (Postfix) with ESMTP id 55D0D21F84EE for ; Sun, 15 Jul 2012 14:41:02 -0700 (PDT) Message-ID: <500338FB.9070504@deployingradius.com> Date: Sun, 15 Jul 2012 17:41:15 -0400 From: Alan DeKok User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: Peter Deacon References: <20120712081654.17566.87131.idtracker@ietfa.amsl.com> <4FFE8893.30402@restena.lu> <5000DDAB.2070408@deployingradius.com> In-Reply-To: X-Enigmail-Version: 0.96.0 Cc: Stefan Winter , "radext@ietf.org" Subject: Re: [radext] Fwd: New Version Notification for draft-winter-radext-fancyaccounting-01.txt X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: radext-bounces@ietf.org Errors-To: radext-bounces@ietf.org Peter Deacon wrote: > Rules for production of accounting class data are configured OOB from > RADIUS. It is not known what the NAS will choose as the basis for > classification. Then how can the accounting data be interpreted? > It may choose to count non-IP flows or high level > protocol exchanges. Either of which are impossible to describe using > NAS filter rules. Both of those use-cases have a much smaller deployment than simple IP accounting. > For example I want to operate a roaming network using fancy accounting > to count local traffic separately from traffic sent over the WAN. Each > operator of each NAS defines what is local to itself. Two classes of > attributes are sent "local" and "network". How are these classes communicated to the other parties in the network? > If you were to simply upload classes with filter rules the accounting > systems of participants would be clueless to interpret what any of the > filter definitions actually do as they only have meaning within the > administrative domain of each NAS operator. Really? "tcp port 80" ? Or "ignore 10/8, 192.168/16, everything else is external, and billed as such". There are *some* cases where NAS filter definitions should be kept locally. There are *more* cases where they can be shared, and can be understood by other parties. Alan DeKok. _______________________________________________ radext mailing list radext@ietf.org https://www.ietf.org/mailman/listinfo/radext From peterd@iea-software.com Sun Jul 15 17:47:10 2012 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 00C2F21F8569 for ; Sun, 15 Jul 2012 17:47:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZgVwAlBt-9pg for ; Sun, 15 Jul 2012 17:47:09 -0700 (PDT) Received: from aspen.internal.iea-software.com (remote.iea-software.com [70.89.142.196]) by ietfa.amsl.com (Postfix) with ESMTP id 31E0321F8567 for ; Sun, 15 Jul 2012 17:47:09 -0700 (PDT) Received: from SMURF (unverified [10.0.3.195]) by aspen.internal.iea-software.com (Rockliffe SMTPRA 7.0.6) with ESMTP id ; Sun, 15 Jul 2012 17:47:51 -0700 Date: Sun, 15 Jul 2012 17:47:51 -0700 (Pacific Daylight Time) From: Peter Deacon To: Alan DeKok In-Reply-To: <500338FB.9070504@deployingradius.com> Message-ID: References: <20120712081654.17566.87131.idtracker@ietfa.amsl.com> <4FFE8893.30402@restena.lu> <5000DDAB.2070408@deployingradius.com> <500338FB.9070504@deployingradius.com> User-Agent: Alpine 2.00 (WNT 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: Stefan Winter , "radext@ietf.org" Subject: Re: [radext] Fwd: New Version Notification for draft-winter-radext-fancyaccounting-01.txt X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 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, 16 Jul 2012 00:47:10 -0000 On Sun, 15 Jul 2012, Alan DeKok wrote: > Peter Deacon wrote: >> Rules for production of accounting class data are configured OOB from >> RADIUS. It is not known what the NAS will choose as the basis for >> classification. > Then how can the accounting data be interpreted? The same way it was configured at the NAS in the first place - by out of band agreement. Only difference a label rather than the entire configuration subject to arbitrary change by manual or automatic means must also be duplicated in accounting. >> It may choose to count non-IP flows or high level >> protocol exchanges. Either of which are impossible to describe using >> NAS filter rules. > Both of those use-cases have a much smaller deployment than simple IP > accounting. Plenty of folk using RADIUS for CLI, SIP, Email..etc. No sense excluding anyone. >> For example I want to operate a roaming network using fancy accounting >> to count local traffic separately from traffic sent over the WAN. Each >> operator of each NAS defines what is local to itself. Two classes of >> attributes are sent "local" and "network". > How are these classes communicated to the other parties in the network? See above. In this example likely by convention agreed by all participants. >> If you were to simply upload classes with filter rules the accounting >> systems of participants would be clueless to interpret what any of the >> filter definitions actually do as they only have meaning within the >> administrative domain of each NAS operator. > Really? "tcp port 80" ? > Or "ignore 10/8, 192.168/16, everything else is external, and billed > as such". What happens when RFC 1918/ULA addresses are not used? What happens when local means within an IGP or attachment to named interfaces? Can this even be defined using filter syntax? Classes derived from PBR or exclusions for local CDN traffic? This does not seem like an unfair or academic question to me. Plenty of NASes have global addresses. With IPv6 deployment plenty more will. Expecting accounting systems to have access to configurations of the network to interpret the intention of filter gooblygook even in the case those systems are within the same administrative domain is not realistic. > There are *some* cases where NAS filter definitions should be kept > locally. There are *more* cases where they can be shared, and can be > understood by other parties. I disagree. Everything can be accomplished with the use of labels. The same is not true where filter definitions lacking comments are used. It was already configured once or perhaps thousand of different times by separate configurations in each NAS in the system. Why is it a good idea to also have to duplicate and manage those details in accounting rather than providing a pointer to them with the use of labels? This reminds me of taking a router full of ACLs, removing all comments and then trying to stump the network guy by asking why a random ACL in the list is there. Sure anyone can tell you what it does but knowing what it is for is a different matter entirely... this is precisely the question accounting is being asked to answer. The cost of requiring an accounting system to have to reverse engineer the *intent* of an ACL is nontrivial. regards, Peter From radext-bounces@ietf.org Sun Jul 15 17:47:15 2012 Return-Path: X-Original-To: radext-archive-IeZ9sae2@lists.ietf.org Delivered-To: ietfarch-radext-archive-IeZ9sae2@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0AC3521F856C; Sun, 15 Jul 2012 17:47:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1342399635; bh=N/yNaJLPU0AsZV61yHzqM5WCIdi9cu9z86cGcX1cGs0=; h=Date:From:To:In-Reply-To:Message-ID:References:MIME-Version:Cc: Subject:List-Id:List-Unsubscribe:List-Archive:List-Post:List-Help: List-Subscribe:Content-Transfer-Encoding:Content-Type:Sender; b=HX2+qNzA/tCp36YAKPxKYoVogLCuBeUc8/DO+g0OkckwNg7NOISZDzgYi5te2rTsK 5yEYgEpsWBCRacB6ylq/qQTo9bnEdstKd1imOXeN/opZj+vbfYNx8qiYcjT9+JKMs+ 6goAOwuCKFnKpCQGxYeuq16nO20eHbToqynDp5D4= 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 00C2F21F8569 for ; Sun, 15 Jul 2012 17:47:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZgVwAlBt-9pg for ; Sun, 15 Jul 2012 17:47:09 -0700 (PDT) Received: from aspen.internal.iea-software.com (remote.iea-software.com [70.89.142.196]) by ietfa.amsl.com (Postfix) with ESMTP id 31E0321F8567 for ; Sun, 15 Jul 2012 17:47:09 -0700 (PDT) Received: from SMURF (unverified [10.0.3.195]) by aspen.internal.iea-software.com (Rockliffe SMTPRA 7.0.6) with ESMTP id ; Sun, 15 Jul 2012 17:47:51 -0700 Date: Sun, 15 Jul 2012 17:47:51 -0700 (Pacific Daylight Time) From: Peter Deacon To: Alan DeKok In-Reply-To: <500338FB.9070504@deployingradius.com> Message-ID: References: <20120712081654.17566.87131.idtracker@ietfa.amsl.com> <4FFE8893.30402@restena.lu> <5000DDAB.2070408@deployingradius.com> <500338FB.9070504@deployingradius.com> User-Agent: Alpine 2.00 (WNT 1167 2008-08-23) MIME-Version: 1.0 Cc: Stefan Winter , "radext@ietf.org" Subject: Re: [radext] Fwd: New Version Notification for draft-winter-radext-fancyaccounting-01.txt X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: radext-bounces@ietf.org Errors-To: radext-bounces@ietf.org On Sun, 15 Jul 2012, Alan DeKok wrote: > Peter Deacon wrote: >> Rules for production of accounting class data are configured OOB from >> RADIUS. It is not known what the NAS will choose as the basis for >> classification. > Then how can the accounting data be interpreted? The same way it was configured at the NAS in the first place - by out of band agreement. Only difference a label rather than the entire configuration subject to arbitrary change by manual or automatic means must also be duplicated in accounting. >> It may choose to count non-IP flows or high level >> protocol exchanges. Either of which are impossible to describe using >> NAS filter rules. > Both of those use-cases have a much smaller deployment than simple IP > accounting. Plenty of folk using RADIUS for CLI, SIP, Email..etc. No sense excluding anyone. >> For example I want to operate a roaming network using fancy accounting >> to count local traffic separately from traffic sent over the WAN. Each >> operator of each NAS defines what is local to itself. Two classes of >> attributes are sent "local" and "network". > How are these classes communicated to the other parties in the network? See above. In this example likely by convention agreed by all participants. >> If you were to simply upload classes with filter rules the accounting >> systems of participants would be clueless to interpret what any of the >> filter definitions actually do as they only have meaning within the >> administrative domain of each NAS operator. > Really? "tcp port 80" ? > Or "ignore 10/8, 192.168/16, everything else is external, and billed > as such". What happens when RFC 1918/ULA addresses are not used? What happens when local means within an IGP or attachment to named interfaces? Can this even be defined using filter syntax? Classes derived from PBR or exclusions for local CDN traffic? This does not seem like an unfair or academic question to me. Plenty of NASes have global addresses. With IPv6 deployment plenty more will. Expecting accounting systems to have access to configurations of the network to interpret the intention of filter gooblygook even in the case those systems are within the same administrative domain is not realistic. > There are *some* cases where NAS filter definitions should be kept > locally. There are *more* cases where they can be shared, and can be > understood by other parties. I disagree. Everything can be accomplished with the use of labels. The same is not true where filter definitions lacking comments are used. It was already configured once or perhaps thousand of different times by separate configurations in each NAS in the system. Why is it a good idea to also have to duplicate and manage those details in accounting rather than providing a pointer to them with the use of labels? This reminds me of taking a router full of ACLs, removing all comments and then trying to stump the network guy by asking why a random ACL in the list is there. Sure anyone can tell you what it does but knowing what it is for is a different matter entirely... this is precisely the question accounting is being asked to answer. The cost of requiring an accounting system to have to reverse engineer the *intent* of an ACL is nontrivial. regards, Peter _______________________________________________ radext mailing list radext@ietf.org https://www.ietf.org/mailman/listinfo/radext From radext-bounces@ietf.org Sun Jul 15 18:05:57 2012 Return-Path: X-Original-To: radext-archive-IeZ9sae2@lists.ietf.org Delivered-To: ietfarch-radext-archive-IeZ9sae2@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A2FF911E809C; Sun, 15 Jul 2012 18:05:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1342400757; bh=nd8DvybNO1gxSAJj7T9BMriIOQ6+4+aAkuatREGNVig=; h=Message-ID:Date:From:MIME-Version:To:References:In-Reply-To:Cc: Subject:List-Id:List-Unsubscribe:List-Archive:List-Post:List-Help: List-Subscribe:Content-Type:Content-Transfer-Encoding:Sender; b=i2sebo20xLxkLAlfCNKjocmpxVCKLGCjpWZghFHNDABDuA4rddLGa3jGW9k2gqpEP qlsFRpXGI/UZ+ORAL+mley7kW9OwUZwuukqNWbfyaYvhDDpv7Dxws2ja0KDRwN57K+ vMr2GMbCQnnio+0MoC16v5TTM3oZwHsb/IYGLWdc= 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 7622411E8099 for ; Sun, 15 Jul 2012 18:05:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.554 X-Spam-Level: X-Spam-Status: No, score=-102.554 tagged_above=-999 required=5 tests=[AWL=0.045, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cTfsx8sA8yk9 for ; Sun, 15 Jul 2012 18:05:55 -0700 (PDT) Received: from liberty.deployingradius.com (liberty.deployingradius.com [88.191.76.128]) by ietfa.amsl.com (Postfix) with ESMTP id 76D2521F855B for ; Sun, 15 Jul 2012 18:05:55 -0700 (PDT) Message-ID: <50036902.6080807@deployingradius.com> Date: Sun, 15 Jul 2012 21:06:10 -0400 From: Alan DeKok User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: Peter Deacon References: <20120712081654.17566.87131.idtracker@ietfa.amsl.com> <4FFE8893.30402@restena.lu> <5000DDAB.2070408@deployingradius.com> <500338FB.9070504@deployingradius.com> In-Reply-To: X-Enigmail-Version: 0.96.0 Cc: Stefan Winter , "radext@ietf.org" Subject: Re: [radext] Fwd: New Version Notification for draft-winter-radext-fancyaccounting-01.txt X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: radext-bounces@ietf.org Errors-To: radext-bounces@ietf.org Peter Deacon wrote: > On Sun, 15 Jul 2012, Alan DeKok wrote: >> Then how can the accounting data be interpreted? > > The same way it was configured at the NAS in the first place - by out of > band agreement. Having worked in roaming consortium, that's hard. Having a computer-readable format is very useful >>> It may choose to count non-IP flows or high level >>> protocol exchanges. Either of which are impossible to describe using >>> NAS filter rules. > >> Both of those use-cases have a much smaller deployment than simple IP >> accounting. > > Plenty of folk using RADIUS for CLI, SIP, Email..etc. No sense > excluding anyone. People do accounting for data to/from the CLI of a NAS? Really? And SIP, Email, etc. can all be describe with the NAS filter rule syntax. > What happens when RFC 1918/ULA addresses are not used? What happens > when local means within an IGP or attachment to named interfaces? Can > this even be defined using filter syntax? Classes derived from PBR or > exclusions for local CDN traffic? I'm not looking for a perfect solution. I'm looking for a *useful* solution. > This does not seem like an unfair or academic question to me. Plenty of > NASes have global addresses. With IPv6 deployment plenty more will. How much user traffic is sent to/from a NAS? i.e. to the IP address of a NAS, as opposed to using it as a DSLAM or router? Arguably "none". So the "NASes having global address" issue is irrelevant. > Expecting accounting systems to have access to configurations of the > network to interpret the intention of filter gooblygook even in the case > those systems are within the same administrative domain is not realistic. The RADIUS system doesn't have access to the routing table for the local system? > I disagree. Everything can be accomplished with the use of labels. The > same is not true where filter definitions lacking comments are used. Sure, everything can be accomplished with opaque labels. That doesn't help interoperability or usability. If the goal is *perfect* usability, then we should just label filters with arbitrary opaque binary names. Nothing else will be as general. Other solutions will be much more practical. > It was already configured once or perhaps thousand of different times by > separate configurations in each NAS in the system. Why is it a good > idea to also have to duplicate and manage those details in accounting > rather than providing a pointer to them with the use of labels? Wow... if you're manually managing the configuration of thousands of rules in NASes, you're doing something wrong. Much of that can be automated via widely available tools. My idea was to have a *central* management system. This system already exists: it's called RADIUS. It can dynamically provision accounting rules on NASes. > This reminds me of taking a router full of ACLs, removing all comments > and then trying to stump the network guy by asking why a random ACL in > the list is there. Or, the router could have ACLs taken from RADIUS Access-Accepts, and tied to a specific user session. These ACLs are documented in one place: on the RADIUS server. That's a boatload better than duplicating them thousands of times on different NASes. i.e. a straw-man argument can be countered with another such example > The cost of requiring an accounting system to have to reverse engineer > the *intent* of an ACL is nontrivial. Where did that requirement come from? Alan DeKok. _______________________________________________ radext mailing list radext@ietf.org https://www.ietf.org/mailman/listinfo/radext From aland@deployingradius.com Sun Jul 15 18:05:56 2012 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 7622411E8099 for ; Sun, 15 Jul 2012 18:05:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.554 X-Spam-Level: X-Spam-Status: No, score=-102.554 tagged_above=-999 required=5 tests=[AWL=0.045, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cTfsx8sA8yk9 for ; Sun, 15 Jul 2012 18:05:55 -0700 (PDT) Received: from liberty.deployingradius.com (liberty.deployingradius.com [88.191.76.128]) by ietfa.amsl.com (Postfix) with ESMTP id 76D2521F855B for ; Sun, 15 Jul 2012 18:05:55 -0700 (PDT) Message-ID: <50036902.6080807@deployingradius.com> Date: Sun, 15 Jul 2012 21:06:10 -0400 From: Alan DeKok User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: Peter Deacon References: <20120712081654.17566.87131.idtracker@ietfa.amsl.com> <4FFE8893.30402@restena.lu> <5000DDAB.2070408@deployingradius.com> <500338FB.9070504@deployingradius.com> In-Reply-To: X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Stefan Winter , "radext@ietf.org" Subject: Re: [radext] Fwd: New Version Notification for draft-winter-radext-fancyaccounting-01.txt X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 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, 16 Jul 2012 01:05:56 -0000 Peter Deacon wrote: > On Sun, 15 Jul 2012, Alan DeKok wrote: >> Then how can the accounting data be interpreted? > > The same way it was configured at the NAS in the first place - by out of > band agreement. Having worked in roaming consortium, that's hard. Having a computer-readable format is very useful >>> It may choose to count non-IP flows or high level >>> protocol exchanges. Either of which are impossible to describe using >>> NAS filter rules. > >> Both of those use-cases have a much smaller deployment than simple IP >> accounting. > > Plenty of folk using RADIUS for CLI, SIP, Email..etc. No sense > excluding anyone. People do accounting for data to/from the CLI of a NAS? Really? And SIP, Email, etc. can all be describe with the NAS filter rule syntax. > What happens when RFC 1918/ULA addresses are not used? What happens > when local means within an IGP or attachment to named interfaces? Can > this even be defined using filter syntax? Classes derived from PBR or > exclusions for local CDN traffic? I'm not looking for a perfect solution. I'm looking for a *useful* solution. > This does not seem like an unfair or academic question to me. Plenty of > NASes have global addresses. With IPv6 deployment plenty more will. How much user traffic is sent to/from a NAS? i.e. to the IP address of a NAS, as opposed to using it as a DSLAM or router? Arguably "none". So the "NASes having global address" issue is irrelevant. > Expecting accounting systems to have access to configurations of the > network to interpret the intention of filter gooblygook even in the case > those systems are within the same administrative domain is not realistic. The RADIUS system doesn't have access to the routing table for the local system? > I disagree. Everything can be accomplished with the use of labels. The > same is not true where filter definitions lacking comments are used. Sure, everything can be accomplished with opaque labels. That doesn't help interoperability or usability. If the goal is *perfect* usability, then we should just label filters with arbitrary opaque binary names. Nothing else will be as general. Other solutions will be much more practical. > It was already configured once or perhaps thousand of different times by > separate configurations in each NAS in the system. Why is it a good > idea to also have to duplicate and manage those details in accounting > rather than providing a pointer to them with the use of labels? Wow... if you're manually managing the configuration of thousands of rules in NASes, you're doing something wrong. Much of that can be automated via widely available tools. My idea was to have a *central* management system. This system already exists: it's called RADIUS. It can dynamically provision accounting rules on NASes. > This reminds me of taking a router full of ACLs, removing all comments > and then trying to stump the network guy by asking why a random ACL in > the list is there. Or, the router could have ACLs taken from RADIUS Access-Accepts, and tied to a specific user session. These ACLs are documented in one place: on the RADIUS server. That's a boatload better than duplicating them thousands of times on different NASes. i.e. a straw-man argument can be countered with another such example > The cost of requiring an accounting system to have to reverse engineer > the *intent* of an ACL is nontrivial. Where did that requirement come from? Alan DeKok. From radext-bounces@ietf.org Sun Jul 15 21:03:07 2012 Return-Path: X-Original-To: radext-archive-IeZ9sae2@lists.ietf.org Delivered-To: ietfarch-radext-archive-IeZ9sae2@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8174311E807F; Sun, 15 Jul 2012 21:03:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1342411387; bh=1FLXs8rK0IhcO/DA2NqrcShjq26xqp9QvgFlCQ/PrEc=; h=Date:From:To:In-Reply-To:Message-ID:References:MIME-Version:Cc: Subject:List-Id:List-Unsubscribe:List-Archive:List-Post:List-Help: List-Subscribe:Content-Transfer-Encoding:Content-Type:Sender; b=caeL/l2mA1O/c7kUBOb9zvmMSPH3V2MCUsXmKJPyQjH3tEv4gteHbn3LwpxZDc0FE hHd/vaUfBZ0b+OrhNYf5DwSKOHAXByH9vcKdeX4NRfqcGwd1YGpH3k04wsy4NYApyi 2ioU9a5xiCk3YnhOXq7JFeg7VCnSoOJvONkzKqyQ= 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 1403821F8438 for ; Sun, 15 Jul 2012 21:03:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OWD6cWbjqN7Z for ; Sun, 15 Jul 2012 21:03:06 -0700 (PDT) Received: from aspen.internal.iea-software.com (remote.iea-software.com [70.89.142.196]) by ietfa.amsl.com (Postfix) with ESMTP id 8719311E807F for ; Sun, 15 Jul 2012 21:03:05 -0700 (PDT) Received: from SMURF (unverified [10.0.3.195]) by aspen.internal.iea-software.com (Rockliffe SMTPRA 7.0.6) with ESMTP id ; Sun, 15 Jul 2012 21:03:48 -0700 Date: Sun, 15 Jul 2012 21:03:49 -0700 (Pacific Daylight Time) From: Peter Deacon To: Alan DeKok In-Reply-To: <50036902.6080807@deployingradius.com> Message-ID: References: <20120712081654.17566.87131.idtracker@ietfa.amsl.com> <4FFE8893.30402@restena.lu> <5000DDAB.2070408@deployingradius.com> <500338FB.9070504@deployingradius.com> <50036902.6080807@deployingradius.com> User-Agent: Alpine 2.00 (WNT 1167 2008-08-23) MIME-Version: 1.0 Cc: Stefan Winter , "radext@ietf.org" Subject: Re: [radext] Fwd: New Version Notification for draft-winter-radext-fancyaccounting-01.txt X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: radext-bounces@ietf.org Errors-To: radext-bounces@ietf.org On Sun, 15 Jul 2012, Alan DeKok wrote: >> The same way it was configured at the NAS in the first place - by out of >> band agreement. Your origional response mentioned only class labels be replaced with filter rules. Nothing was said about configuring those rules in the NAS by pushing parameters via Access-Accept. I think this configuration would be useful. However to use filter rules as the analogy we still have and use Filter-Id. If anything I would prefer to see both options made avaliable enabling people to choose the solution which best fits their needs. Not all problems can be or are best solved by pushing filters as syntax is limited. regards, Peter _______________________________________________ radext mailing list radext@ietf.org https://www.ietf.org/mailman/listinfo/radext From peterd@iea-software.com Sun Jul 15 21:03:07 2012 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 1403821F8438 for ; Sun, 15 Jul 2012 21:03:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OWD6cWbjqN7Z for ; Sun, 15 Jul 2012 21:03:06 -0700 (PDT) Received: from aspen.internal.iea-software.com (remote.iea-software.com [70.89.142.196]) by ietfa.amsl.com (Postfix) with ESMTP id 8719311E807F for ; Sun, 15 Jul 2012 21:03:05 -0700 (PDT) Received: from SMURF (unverified [10.0.3.195]) by aspen.internal.iea-software.com (Rockliffe SMTPRA 7.0.6) with ESMTP id ; Sun, 15 Jul 2012 21:03:48 -0700 Date: Sun, 15 Jul 2012 21:03:49 -0700 (Pacific Daylight Time) From: Peter Deacon To: Alan DeKok In-Reply-To: <50036902.6080807@deployingradius.com> Message-ID: References: <20120712081654.17566.87131.idtracker@ietfa.amsl.com> <4FFE8893.30402@restena.lu> <5000DDAB.2070408@deployingradius.com> <500338FB.9070504@deployingradius.com> <50036902.6080807@deployingradius.com> User-Agent: Alpine 2.00 (WNT 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII Cc: Stefan Winter , "radext@ietf.org" Subject: Re: [radext] Fwd: New Version Notification for draft-winter-radext-fancyaccounting-01.txt X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 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, 16 Jul 2012 04:03:07 -0000 On Sun, 15 Jul 2012, Alan DeKok wrote: >> The same way it was configured at the NAS in the first place - by out of >> band agreement. Your origional response mentioned only class labels be replaced with filter rules. Nothing was said about configuring those rules in the NAS by pushing parameters via Access-Accept. I think this configuration would be useful. However to use filter rules as the analogy we still have and use Filter-Id. If anything I would prefer to see both options made avaliable enabling people to choose the solution which best fits their needs. Not all problems can be or are best solved by pushing filters as syntax is limited. regards, Peter From stefan.winter@restena.lu Sun Jul 15 22:59:58 2012 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 E806421F85D1 for ; Sun, 15 Jul 2012 22:59:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2c933RfF1X35 for ; Sun, 15 Jul 2012 22:59:57 -0700 (PDT) Received: from smtprelay.restena.lu (smtprelay.restena.lu [IPv6:2001:a18:1::62]) by ietfa.amsl.com (Postfix) with ESMTP id 6367021F85C5 for ; Sun, 15 Jul 2012 22:59:56 -0700 (PDT) Received: from smtprelay.restena.lu (localhost [127.0.0.1]) by smtprelay.restena.lu (Postfix) with ESMTP id 7B2D01057F for ; Mon, 16 Jul 2012 08:00:38 +0200 (CEST) Received: from [IPv6:2001:a18:1:8:bc9e:f3e5:7034:7903] (unknown [IPv6:2001:a18:1:8:bc9e:f3e5:7034:7903]) by smtprelay.restena.lu (Postfix) with ESMTPS id 42D051057E for ; Mon, 16 Jul 2012 08:00:38 +0200 (CEST) Message-ID: <5003AE01.1020004@restena.lu> Date: Mon, 16 Jul 2012 08:00:33 +0200 From: Stefan Winter User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:13.0) Gecko/20120601 Thunderbird/13.0 MIME-Version: 1.0 To: radext@ietf.org References: <20120712081654.17566.87131.idtracker@ietfa.amsl.com> <4FFE8893.30402@restena.lu> <4FFED600.3000109@restena.lu> <50016238.9030509@deployingradius.com> In-Reply-To: <50016238.9030509@deployingradius.com> X-Enigmail-Version: 1.4.3 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigF1A65EB64781BC3F010EE0DB" X-Virus-Scanned: ClamAV Subject: Re: [radext] Fwd: New Version Notification for draft-winter-radext-fancyaccounting-01.txt X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 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, 16 Jul 2012 05:59:58 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigF1A65EB64781BC3F010EE0DB Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi, >> On Thu, 12 Jul 2012, Stefan Winter wrote: >>> A concern of mine was that a NAS might send a value in an >>> Interim-Update, but then not report the same type of data in the Stop= >>> packet. >=20 > Such NASes should be burned with fire. >=20 >> Agree. I think at point where a class or any sub-attribute of the cla= ss >> appears in an interim it should be required to be sent in all subseque= nt >> interims and stop record. Forgetting should not be an option. >=20 > I agree. At least in this part of the thread, there seems to be violent agreement = :-) I'm updating the source of the draft with more explicit wording that forgetting is not an option. If my time permits, I could upload a new rev just before the cut-off. Greetings, Stefan Winter --=20 Stefan WINTER Ingenieur de Recherche Fondation RESTENA - R=E9seau T=E9l=E9informatique de l'Education National= e et de la Recherche 6, rue Richard Coudenhove-Kalergi L-1359 Luxembourg Tel: +352 424409 1 Fax: +352 422473 --------------enigF1A65EB64781BC3F010EE0DB 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.0.18 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAlADrgUACgkQ+jm90f8eFWbskwCbB1CElQSay35blEfKGMpnb7pb xGIAnRTvIvis5pwz7E+c7BizYf48jqV6 =cn8P -----END PGP SIGNATURE----- --------------enigF1A65EB64781BC3F010EE0DB-- From radext-bounces@ietf.org Sun Jul 15 22:59:58 2012 Return-Path: X-Original-To: radext-archive-IeZ9sae2@lists.ietf.org Delivered-To: ietfarch-radext-archive-IeZ9sae2@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CBF3221F85D2; Sun, 15 Jul 2012 22:59:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1342418398; bh=eyaxLaDS7wkUlVdlNwvIgdq61LK5ErozJ/ZCdm+JAms=; h=Message-ID:Date:From:MIME-Version:To:References:In-Reply-To: Subject:List-Id:List-Unsubscribe:List-Archive:List-Post:List-Help: List-Subscribe:Content-Type:Sender; b=k4qhNai5WqowKBPaYSMi3ff58IQP7JBfHHMwTmzLswshgEefgMz7J/DNq8ttXEnVy r/aFB/5lslx2/aGf+Z9F54SB9sHmmW9MuQcQL+4/jpMzRcDsze4zR+UumjkzdNkL6p taLhdpt+yh6FRlIyU4Xi7jcogFvKrbMk9Qk/LePA= 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 E806421F85D1 for ; Sun, 15 Jul 2012 22:59:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2c933RfF1X35 for ; Sun, 15 Jul 2012 22:59:57 -0700 (PDT) Received: from smtprelay.restena.lu (smtprelay.restena.lu [IPv6:2001:a18:1::62]) by ietfa.amsl.com (Postfix) with ESMTP id 6367021F85C5 for ; Sun, 15 Jul 2012 22:59:56 -0700 (PDT) Received: from smtprelay.restena.lu (localhost [127.0.0.1]) by smtprelay.restena.lu (Postfix) with ESMTP id 7B2D01057F for ; Mon, 16 Jul 2012 08:00:38 +0200 (CEST) Received: from [IPv6:2001:a18:1:8:bc9e:f3e5:7034:7903] (unknown [IPv6:2001:a18:1:8:bc9e:f3e5:7034:7903]) by smtprelay.restena.lu (Postfix) with ESMTPS id 42D051057E for ; Mon, 16 Jul 2012 08:00:38 +0200 (CEST) Message-ID: <5003AE01.1020004@restena.lu> Date: Mon, 16 Jul 2012 08:00:33 +0200 From: Stefan Winter User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:13.0) Gecko/20120601 Thunderbird/13.0 MIME-Version: 1.0 To: radext@ietf.org References: <20120712081654.17566.87131.idtracker@ietfa.amsl.com> <4FFE8893.30402@restena.lu> <4FFED600.3000109@restena.lu> <50016238.9030509@deployingradius.com> In-Reply-To: <50016238.9030509@deployingradius.com> X-Enigmail-Version: 1.4.3 X-Virus-Scanned: ClamAV Subject: Re: [radext] Fwd: New Version Notification for draft-winter-radext-fancyaccounting-01.txt X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0902616654555297233==" Sender: radext-bounces@ietf.org Errors-To: radext-bounces@ietf.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --===============0902616654555297233== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigF1A65EB64781BC3F010EE0DB" This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigF1A65EB64781BC3F010EE0DB Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi, >> On Thu, 12 Jul 2012, Stefan Winter wrote: >>> A concern of mine was that a NAS might send a value in an >>> Interim-Update, but then not report the same type of data in the Stop= >>> packet. >=20 > Such NASes should be burned with fire. >=20 >> Agree. I think at point where a class or any sub-attribute of the cla= ss >> appears in an interim it should be required to be sent in all subseque= nt >> interims and stop record. Forgetting should not be an option. >=20 > I agree. At least in this part of the thread, there seems to be violent agreement = :-) I'm updating the source of the draft with more explicit wording that forgetting is not an option. If my time permits, I could upload a new rev just before the cut-off. Greetings, Stefan Winter --=20 Stefan WINTER Ingenieur de Recherche Fondation RESTENA - R=E9seau T=E9l=E9informatique de l'Education National= e et de la Recherche 6, rue Richard Coudenhove-Kalergi L-1359 Luxembourg Tel: +352 424409 1 Fax: +352 422473 --------------enigF1A65EB64781BC3F010EE0DB 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.0.18 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAlADrgUACgkQ+jm90f8eFWbskwCbB1CElQSay35blEfKGMpnb7pb xGIAnRTvIvis5pwz7E+c7BizYf48jqV6 =cn8P -----END PGP SIGNATURE----- --------------enigF1A65EB64781BC3F010EE0DB-- --===============0902616654555297233== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ radext mailing list radext@ietf.org https://www.ietf.org/mailman/listinfo/radext --===============0902616654555297233==-- From stefan.winter@restena.lu Sun Jul 15 23:29:39 2012 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 63ECC11E807F for ; Sun, 15 Jul 2012 23:29:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8gkgJYwLETsv for ; Sun, 15 Jul 2012 23:29:36 -0700 (PDT) Received: from smtprelay.restena.lu (smtprelay.restena.lu [IPv6:2001:a18:1::62]) by ietfa.amsl.com (Postfix) with ESMTP id 4F83A21F846A for ; Sun, 15 Jul 2012 23:29:36 -0700 (PDT) Received: from smtprelay.restena.lu (localhost [127.0.0.1]) by smtprelay.restena.lu (Postfix) with ESMTP id C46431057F for ; Mon, 16 Jul 2012 08:30:19 +0200 (CEST) Received: from [IPv6:2001:a18:1:8:65bb:1581:80ca:b5b8] (unknown [IPv6:2001:a18:1:8:65bb:1581:80ca:b5b8]) by smtprelay.restena.lu (Postfix) with ESMTPS id 7F36A1057D for ; Mon, 16 Jul 2012 08:30:19 +0200 (CEST) Message-ID: <5003B4F7.7030603@restena.lu> Date: Mon, 16 Jul 2012 08:30:15 +0200 From: Stefan Winter User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:13.0) Gecko/20120601 Thunderbird/13.0 MIME-Version: 1.0 To: radext@ietf.org References: <20120712081654.17566.87131.idtracker@ietfa.amsl.com> <4FFE8893.30402@restena.lu> <4FFED1D3.7060706@restena.lu> <5000483E.5030800@restena.lu> In-Reply-To: X-Enigmail-Version: 1.4.3 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigBF59F13E07E6362A03CAC4CA" X-Virus-Scanned: ClamAV Subject: Re: [radext] Fwd: New Version Notification for draft-winter-radext-fancyaccounting-01.txt X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 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, 16 Jul 2012 06:29:39 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigBF59F13E07E6362A03CAC4CA Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hello, > I haven't read the (competing?) drafts in a while, but one issue in you= r > most recent mail caught my attention. >=20 > What's the fundamental difference between a string type encoding using > an (unregistered) user-private URN namespace and a Vendor > Specific Enumeration for an integer type? The latter is > an officially discouraged technique, in the RADIUS Design Guidelines, a= s > I recall. There is no vendor-specific enumeration in the other draft at all. That draft is very specific about sending IPv6 and/or IPv4 counter values, so there are exactly three defined enum values for those two traffic classes= =2E The attribute is Acct-Traffic-Statistics.Stack-Type - the name suggests that it is not meant to be extensible to carry more meaning than the IP stack version. When discussing DSCP traffic classes as something people might want to count, the author introduced an entire new attribute for that, Acct-Traffic-Statistics.DSCP-Type. It is only meant to be used in conjunction with the IP stack one, to report on the intersecting set of these two orthogonal properties. All other values in these two attributes are reserved, suggesting that IETF Action is necessary to add new values. IOW, there is *no* extensibility in that draft. Assuming that people out there will at some point want to count other conditions in their accounting records, this forces them to hijack one of the reserved numbers, therewith breaking semantics of these attributes and hampering interop. > Flexibility for small users, who can't be bothered with managed > namespaces and codepoints is all well and good, but it seems to me that= > the purpose of doing work in the IETF is to guarantee a high level > multi-vendor interoperability by formally defining such things. No? Sure: that's why the URN namespace option is devised to carry labels with defined and published meanings, which ensures interop. The non-URN strings are only meant for local use. They don't guarantee any interoperability - if the accounting data is to be shared across enterprises, they need to define a "proper" URN one and use that. As I wrote earlier, I don't care much about that use case, I could also live with dropping that option 2. It's just that I believe openness in this aspect doesn't hurt; the strings are compared char-by-char to find the one with a specific meaning anyway and it technically makes no difference at all whether it starts with "urn:" or not. And if we forbid that kind of use, my gut feeling from above applies here at well: if people want to use it in a non-URN way, they will. So if it doesn't hurt protocol-wise to provide a local-use loophole, and might help some people, we can just as well do it. (I am talking of local use as in the current IAB draft about protocol extensions: http://tools.ietf.org/html/draft-iab-extension-recs-17, Section 3.2.2; it might be useful to point to that reference in a later r= ev) Greetings, Stefan Winter >=20 > Regards, >=20 > Dave >=20 > David B. Nelson > Director of Technology > Elbrys Networks, Inc. > www.elbrys.com > +1.603.570.2636 >=20 >=20 > _______________________________________________ > radext mailing list > radext@ietf.org > https://www.ietf.org/mailman/listinfo/radext >=20 --=20 Stefan WINTER Ingenieur de Recherche Fondation RESTENA - R=E9seau T=E9l=E9informatique de l'Education National= e et de la Recherche 6, rue Richard Coudenhove-Kalergi L-1359 Luxembourg Tel: +352 424409 1 Fax: +352 422473 --------------enigBF59F13E07E6362A03CAC4CA 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.0.18 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAlADtPsACgkQ+jm90f8eFWZCVwCdGinyCvIAStqMyf1xM3KRTYEp ZFoAn3Xx/RoceCOg/zcbA2V96ZyxhXCp =YIX5 -----END PGP SIGNATURE----- --------------enigBF59F13E07E6362A03CAC4CA-- From radext-bounces@ietf.org Sun Jul 15 23:29:43 2012 Return-Path: X-Original-To: radext-archive-IeZ9sae2@lists.ietf.org Delivered-To: ietfarch-radext-archive-IeZ9sae2@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 28AB321F85D4; Sun, 15 Jul 2012 23:29:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1342420183; bh=FBig0LfR3S4tT+Rn2yUlY8KudmQqyujt3eB02UFCWvc=; h=Message-ID:Date:From:MIME-Version:To:References:In-Reply-To: Subject:List-Id:List-Unsubscribe:List-Archive:List-Post:List-Help: List-Subscribe:Content-Type:Sender; b=iTNhdtw02p46jJlF6av2z8tkytxQh9vvd5O2kVDQz3ZqYmLCNuq27HP1jSG2XlO/L ggyeuOlJ+eOcZYJUoO09mm5/jvinYLTR2A7d0A83a6XXRrcSh/GdTdnHzoT40qpvHl HbiALB1CTYcQHpefsTqFuPYwCPyN0DC4E4uqQgXg= 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 63ECC11E807F for ; Sun, 15 Jul 2012 23:29:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8gkgJYwLETsv for ; Sun, 15 Jul 2012 23:29:36 -0700 (PDT) Received: from smtprelay.restena.lu (smtprelay.restena.lu [IPv6:2001:a18:1::62]) by ietfa.amsl.com (Postfix) with ESMTP id 4F83A21F846A for ; Sun, 15 Jul 2012 23:29:36 -0700 (PDT) Received: from smtprelay.restena.lu (localhost [127.0.0.1]) by smtprelay.restena.lu (Postfix) with ESMTP id C46431057F for ; Mon, 16 Jul 2012 08:30:19 +0200 (CEST) Received: from [IPv6:2001:a18:1:8:65bb:1581:80ca:b5b8] (unknown [IPv6:2001:a18:1:8:65bb:1581:80ca:b5b8]) by smtprelay.restena.lu (Postfix) with ESMTPS id 7F36A1057D for ; Mon, 16 Jul 2012 08:30:19 +0200 (CEST) Message-ID: <5003B4F7.7030603@restena.lu> Date: Mon, 16 Jul 2012 08:30:15 +0200 From: Stefan Winter User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:13.0) Gecko/20120601 Thunderbird/13.0 MIME-Version: 1.0 To: radext@ietf.org References: <20120712081654.17566.87131.idtracker@ietfa.amsl.com> <4FFE8893.30402@restena.lu> <4FFED1D3.7060706@restena.lu> <5000483E.5030800@restena.lu> In-Reply-To: X-Enigmail-Version: 1.4.3 X-Virus-Scanned: ClamAV Subject: Re: [radext] Fwd: New Version Notification for draft-winter-radext-fancyaccounting-01.txt X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============5067926554390865579==" Sender: radext-bounces@ietf.org Errors-To: radext-bounces@ietf.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --===============5067926554390865579== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigBF59F13E07E6362A03CAC4CA" This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigBF59F13E07E6362A03CAC4CA Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hello, > I haven't read the (competing?) drafts in a while, but one issue in you= r > most recent mail caught my attention. >=20 > What's the fundamental difference between a string type encoding using > an (unregistered) user-private URN namespace and a Vendor > Specific Enumeration for an integer type? The latter is > an officially discouraged technique, in the RADIUS Design Guidelines, a= s > I recall. There is no vendor-specific enumeration in the other draft at all. That draft is very specific about sending IPv6 and/or IPv4 counter values, so there are exactly three defined enum values for those two traffic classes= =2E The attribute is Acct-Traffic-Statistics.Stack-Type - the name suggests that it is not meant to be extensible to carry more meaning than the IP stack version. When discussing DSCP traffic classes as something people might want to count, the author introduced an entire new attribute for that, Acct-Traffic-Statistics.DSCP-Type. It is only meant to be used in conjunction with the IP stack one, to report on the intersecting set of these two orthogonal properties. All other values in these two attributes are reserved, suggesting that IETF Action is necessary to add new values. IOW, there is *no* extensibility in that draft. Assuming that people out there will at some point want to count other conditions in their accounting records, this forces them to hijack one of the reserved numbers, therewith breaking semantics of these attributes and hampering interop. > Flexibility for small users, who can't be bothered with managed > namespaces and codepoints is all well and good, but it seems to me that= > the purpose of doing work in the IETF is to guarantee a high level > multi-vendor interoperability by formally defining such things. No? Sure: that's why the URN namespace option is devised to carry labels with defined and published meanings, which ensures interop. The non-URN strings are only meant for local use. They don't guarantee any interoperability - if the accounting data is to be shared across enterprises, they need to define a "proper" URN one and use that. As I wrote earlier, I don't care much about that use case, I could also live with dropping that option 2. It's just that I believe openness in this aspect doesn't hurt; the strings are compared char-by-char to find the one with a specific meaning anyway and it technically makes no difference at all whether it starts with "urn:" or not. And if we forbid that kind of use, my gut feeling from above applies here at well: if people want to use it in a non-URN way, they will. So if it doesn't hurt protocol-wise to provide a local-use loophole, and might help some people, we can just as well do it. (I am talking of local use as in the current IAB draft about protocol extensions: http://tools.ietf.org/html/draft-iab-extension-recs-17, Section 3.2.2; it might be useful to point to that reference in a later r= ev) Greetings, Stefan Winter >=20 > Regards, >=20 > Dave >=20 > David B. Nelson > Director of Technology > Elbrys Networks, Inc. > www.elbrys.com > +1.603.570.2636 >=20 >=20 > _______________________________________________ > radext mailing list > radext@ietf.org > https://www.ietf.org/mailman/listinfo/radext >=20 --=20 Stefan WINTER Ingenieur de Recherche Fondation RESTENA - R=E9seau T=E9l=E9informatique de l'Education National= e et de la Recherche 6, rue Richard Coudenhove-Kalergi L-1359 Luxembourg Tel: +352 424409 1 Fax: +352 422473 --------------enigBF59F13E07E6362A03CAC4CA 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.0.18 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAlADtPsACgkQ+jm90f8eFWZCVwCdGinyCvIAStqMyf1xM3KRTYEp ZFoAn3Xx/RoceCOg/zcbA2V96ZyxhXCp =YIX5 -----END PGP SIGNATURE----- --------------enigBF59F13E07E6362A03CAC4CA-- --===============5067926554390865579== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ radext mailing list radext@ietf.org https://www.ietf.org/mailman/listinfo/radext --===============5067926554390865579==-- From stefan.winter@restena.lu Sun Jul 15 23:46:28 2012 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 56BC421F85DD for ; Sun, 15 Jul 2012 23:46:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id swzimwSIoppR for ; Sun, 15 Jul 2012 23:46:27 -0700 (PDT) Received: from smtprelay.restena.lu (smtprelay.restena.lu [IPv6:2001:a18:1::62]) by ietfa.amsl.com (Postfix) with ESMTP id A9EFD21F85DB for ; Sun, 15 Jul 2012 23:46:27 -0700 (PDT) Received: from smtprelay.restena.lu (localhost [127.0.0.1]) by smtprelay.restena.lu (Postfix) with ESMTP id 2F77C1057F for ; Mon, 16 Jul 2012 08:47:11 +0200 (CEST) Received: from [IPv6:2001:a18:1:8:65bb:1581:80ca:b5b8] (unknown [IPv6:2001:a18:1:8:65bb:1581:80ca:b5b8]) by smtprelay.restena.lu (Postfix) with ESMTPS id E365F1057D for ; Mon, 16 Jul 2012 08:47:10 +0200 (CEST) Message-ID: <5003B8E9.5080200@restena.lu> Date: Mon, 16 Jul 2012 08:47:05 +0200 From: Stefan Winter User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:13.0) Gecko/20120601 Thunderbird/13.0 MIME-Version: 1.0 To: radext@ietf.org References: <20120712081654.17566.87131.idtracker@ietfa.amsl.com> <4FFE8893.30402@restena.lu> <5000DDAB.2070408@deployingradius.com> In-Reply-To: <5000DDAB.2070408@deployingradius.com> X-Enigmail-Version: 1.4.3 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig03E7A2905BD8DCFA9F6CF86F" X-Virus-Scanned: ClamAV Subject: Re: [radext] Fwd: New Version Notification for draft-winter-radext-fancyaccounting-01.txt X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 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, 16 Jul 2012 06:46:28 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig03E7A2905BD8DCFA9F6CF86F Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hello, >> Realising that a known vocabulary of traffic classes is useful for >> inter-op between ISPs, I introduced an - optional - fixed syntax for >> specific accounting traffic classes by using URNs. Among those is, of >> course, IPv6, as this was the original trigger for the accounting >> traffic class discussion. >=20 > RFC 4849 defines the NAS-Filter-Rule attribute. It's based on the > RFC3588 IPFilterRule, which is in turn largely FreeBSD firewall rules. >=20 > Why not just leverage that? There's no need to have a new registry > (string or integer) for traffic classes. Instead, just describe the > traffic by the filter rules it matches. >=20 > That allowss for nearly unlimited flexibility, without creating any > new standard or registry. I took a look at IPFilterRule some time ago. I realised that it's not entirely flexible when I saw that the fictional use case of "traffic with a specific DSCP value" isn't covered by that attribute. Looking further, I checked RFC5777 - The FilterRule AVP with its numerous Classifiers (which include, but are not limited to IP addresses) looks like better suited *if* we really choose to go in the direction of using the axact filter definition in the accounting data as opposed to a semantic label. I, in turn, have concerns with that ;-) I'll go into details of this in another reply in the thread. Greetings, Stefan Winter >> If the re-charter with an explicit mention of "RADIUS Accounting >> Extensions for Traffic Statistics" gets adopted, I would like to sugge= st >> adopting my draft for that topic. >=20 > I would like a discussion around the definition of traffic classes. > But the document is largely OK for me. >=20 > Alan DeKok. >=20 > _______________________________________________ > radext mailing list > radext@ietf.org > https://www.ietf.org/mailman/listinfo/radext >=20 --=20 Stefan WINTER Ingenieur de Recherche Fondation RESTENA - R=E9seau T=E9l=E9informatique de l'Education National= e et de la Recherche 6, rue Richard Coudenhove-Kalergi L-1359 Luxembourg Tel: +352 424409 1 Fax: +352 422473 --------------enig03E7A2905BD8DCFA9F6CF86F 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.0.18 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAlADuO4ACgkQ+jm90f8eFWYDbQCfaZGxaUuY/JY94VF0EZAp3mx1 4e0An2d1uvAK1W8UuJo2I3p6htNzCQEw =92B7 -----END PGP SIGNATURE----- --------------enig03E7A2905BD8DCFA9F6CF86F-- From radext-bounces@ietf.org Sun Jul 15 23:46:33 2012 Return-Path: X-Original-To: radext-archive-IeZ9sae2@lists.ietf.org Delivered-To: ietfarch-radext-archive-IeZ9sae2@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1BC2121F85DB; Sun, 15 Jul 2012 23:46:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1342421193; bh=I/BPicy0Pk2yi+FtWprvxP/yz9wA1sB+f8mZDdxlFFU=; h=Message-ID:Date:From:MIME-Version:To:References:In-Reply-To: Subject:List-Id:List-Unsubscribe:List-Archive:List-Post:List-Help: List-Subscribe:Content-Type:Sender; b=ZVaFUtTC/w9lndrhdx5IfWayBcWdQSTENRJvz5ZEgfYdTjucTxW4HMHZdtWteCeiO PorH/xEhl4wygHtkGJThh6M177/6DGL/eerXt46PkAfQNjQGw4utDEyCRf6TTs56mr I9yr5wFR5InK56ArL8DsbkQRDxoIYmJuwApbfFLI= 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 56BC421F85DD for ; Sun, 15 Jul 2012 23:46:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id swzimwSIoppR for ; Sun, 15 Jul 2012 23:46:27 -0700 (PDT) Received: from smtprelay.restena.lu (smtprelay.restena.lu [IPv6:2001:a18:1::62]) by ietfa.amsl.com (Postfix) with ESMTP id A9EFD21F85DB for ; Sun, 15 Jul 2012 23:46:27 -0700 (PDT) Received: from smtprelay.restena.lu (localhost [127.0.0.1]) by smtprelay.restena.lu (Postfix) with ESMTP id 2F77C1057F for ; Mon, 16 Jul 2012 08:47:11 +0200 (CEST) Received: from [IPv6:2001:a18:1:8:65bb:1581:80ca:b5b8] (unknown [IPv6:2001:a18:1:8:65bb:1581:80ca:b5b8]) by smtprelay.restena.lu (Postfix) with ESMTPS id E365F1057D for ; Mon, 16 Jul 2012 08:47:10 +0200 (CEST) Message-ID: <5003B8E9.5080200@restena.lu> Date: Mon, 16 Jul 2012 08:47:05 +0200 From: Stefan Winter User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:13.0) Gecko/20120601 Thunderbird/13.0 MIME-Version: 1.0 To: radext@ietf.org References: <20120712081654.17566.87131.idtracker@ietfa.amsl.com> <4FFE8893.30402@restena.lu> <5000DDAB.2070408@deployingradius.com> In-Reply-To: <5000DDAB.2070408@deployingradius.com> X-Enigmail-Version: 1.4.3 X-Virus-Scanned: ClamAV Subject: Re: [radext] Fwd: New Version Notification for draft-winter-radext-fancyaccounting-01.txt X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0504322717267577821==" Sender: radext-bounces@ietf.org Errors-To: radext-bounces@ietf.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --===============0504322717267577821== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig03E7A2905BD8DCFA9F6CF86F" This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig03E7A2905BD8DCFA9F6CF86F Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hello, >> Realising that a known vocabulary of traffic classes is useful for >> inter-op between ISPs, I introduced an - optional - fixed syntax for >> specific accounting traffic classes by using URNs. Among those is, of >> course, IPv6, as this was the original trigger for the accounting >> traffic class discussion. >=20 > RFC 4849 defines the NAS-Filter-Rule attribute. It's based on the > RFC3588 IPFilterRule, which is in turn largely FreeBSD firewall rules. >=20 > Why not just leverage that? There's no need to have a new registry > (string or integer) for traffic classes. Instead, just describe the > traffic by the filter rules it matches. >=20 > That allowss for nearly unlimited flexibility, without creating any > new standard or registry. I took a look at IPFilterRule some time ago. I realised that it's not entirely flexible when I saw that the fictional use case of "traffic with a specific DSCP value" isn't covered by that attribute. Looking further, I checked RFC5777 - The FilterRule AVP with its numerous Classifiers (which include, but are not limited to IP addresses) looks like better suited *if* we really choose to go in the direction of using the axact filter definition in the accounting data as opposed to a semantic label. I, in turn, have concerns with that ;-) I'll go into details of this in another reply in the thread. Greetings, Stefan Winter >> If the re-charter with an explicit mention of "RADIUS Accounting >> Extensions for Traffic Statistics" gets adopted, I would like to sugge= st >> adopting my draft for that topic. >=20 > I would like a discussion around the definition of traffic classes. > But the document is largely OK for me. >=20 > Alan DeKok. >=20 > _______________________________________________ > radext mailing list > radext@ietf.org > https://www.ietf.org/mailman/listinfo/radext >=20 --=20 Stefan WINTER Ingenieur de Recherche Fondation RESTENA - R=E9seau T=E9l=E9informatique de l'Education National= e et de la Recherche 6, rue Richard Coudenhove-Kalergi L-1359 Luxembourg Tel: +352 424409 1 Fax: +352 422473 --------------enig03E7A2905BD8DCFA9F6CF86F 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.0.18 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAlADuO4ACgkQ+jm90f8eFWYDbQCfaZGxaUuY/JY94VF0EZAp3mx1 4e0An2d1uvAK1W8UuJo2I3p6htNzCQEw =92B7 -----END PGP SIGNATURE----- --------------enig03E7A2905BD8DCFA9F6CF86F-- --===============0504322717267577821== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ radext mailing list radext@ietf.org https://www.ietf.org/mailman/listinfo/radext --===============0504322717267577821==-- From stefan.winter@restena.lu Mon Jul 16 00:02:11 2012 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 D569B11E8079 for ; Mon, 16 Jul 2012 00:02:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MKaUmkg7KYNS for ; Mon, 16 Jul 2012 00:02:11 -0700 (PDT) Received: from smtprelay.restena.lu (smtprelay.restena.lu [IPv6:2001:a18:1::62]) by ietfa.amsl.com (Postfix) with ESMTP id 0415611E809B for ; Mon, 16 Jul 2012 00:02:10 -0700 (PDT) Received: from smtprelay.restena.lu (localhost [127.0.0.1]) by smtprelay.restena.lu (Postfix) with ESMTP id 58FA01057F; Mon, 16 Jul 2012 09:02:54 +0200 (CEST) Received: from [IPv6:2001:a18:1:8:65bb:1581:80ca:b5b8] (unknown [IPv6:2001:a18:1:8:65bb:1581:80ca:b5b8]) by smtprelay.restena.lu (Postfix) with ESMTPS id ED3F41057D; Mon, 16 Jul 2012 09:02:53 +0200 (CEST) Message-ID: <5003BC99.7030703@restena.lu> Date: Mon, 16 Jul 2012 09:02:49 +0200 From: Stefan Winter User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:13.0) Gecko/20120601 Thunderbird/13.0 MIME-Version: 1.0 To: Peter Deacon References: <20120712081654.17566.87131.idtracker@ietfa.amsl.com> <4FFE8893.30402@restena.lu> <5000DDAB.2070408@deployingradius.com> <500338FB.9070504@deployingradius.com> <50036902.6080807@deployingradius.com> In-Reply-To: X-Enigmail-Version: 1.4.3 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig16AFC75EEB4E6DA7226A7009" X-Virus-Scanned: ClamAV Cc: "radext@ietf.org" , Alan DeKok Subject: Re: [radext] Fwd: New Version Notification for draft-winter-radext-fancyaccounting-01.txt X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 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, 16 Jul 2012 07:02:12 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig16AFC75EEB4E6DA7226A7009 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi, > Your origional response mentioned only class labels be replaced with > filter rules. Nothing was said about configuring those rules in the NA= S > by pushing parameters via Access-Accept. I think this configuration > would be useful. That certainly sounds useful indeed (but is again nothing I would put into this *accounting* draft). > However to use filter rules as the analogy we still have and use > Filter-Id. If anything I would prefer to see both options made > avaliable enabling people to choose the solution which best fits their > needs. >=20 > Not all problems can be or are best solved by pushing filters as syntax= > is limited. That's right - and my main concern with restricting the traffic descriptor to the exact syntax used. Here is one use case which is (almost) taken from real life, and hopefully shows that pushing the exact syntax over and over again in every accounting packet may be less than practical. Our network is a science network, interconnected with other national science networks over a common backbone ("GEANT"). Since users sometimes use resources outside the scienitfic networks ("the internet"), there is also an outlet on that common backbone to peer with the world at large, called the Dante World Service (DWS). Intra-GEANT traffic is subsidised, DWS is not. A science network *might* want to find out which of their connected entities cause which fraction of traffic on DWS, to send a bill about that traffic - but not the GEANT one. (Disclaimer: the wish to send bills for that is entirely fictional and only made up here for argument purposes; the rest of the example is real life though) The classification "GEANT or DWS" is not simple - there are some 50 ASes in the GEANT backbone, most of which have multiple IP prefixes in their announcement. A NAS would thus need to know a three-digit amount of IP prefixes to classify traffic. Getting the list to the NAS alone is a daunting task, but luckily it needs to be done just one time. Sending the exact filter definition with hundreds of prefixes in *every accounting packet* sounds extremely impractical to me! If I had a traffic label called "urn:geant:dws-traffic" - I would be a lot happier than with receiving a huge blob of IP filter rules all the time. Greetings, Stefan Winter --=20 Stefan WINTER Ingenieur de Recherche Fondation RESTENA - R=E9seau T=E9l=E9informatique de l'Education National= e et de la Recherche 6, rue Richard Coudenhove-Kalergi L-1359 Luxembourg Tel: +352 424409 1 Fax: +352 422473 --------------enig16AFC75EEB4E6DA7226A7009 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.0.18 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAlADvJ0ACgkQ+jm90f8eFWZP7gCgiANndeSByAmnwBe8lVvDKxeh Tu8An0M4BGwiQnHGAQ9yc0tNFLq2oJnR =BnNL -----END PGP SIGNATURE----- --------------enig16AFC75EEB4E6DA7226A7009-- From radext-bounces@ietf.org Mon Jul 16 00:02:13 2012 Return-Path: X-Original-To: radext-archive-IeZ9sae2@lists.ietf.org Delivered-To: ietfarch-radext-archive-IeZ9sae2@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BB84C11E809B; Mon, 16 Jul 2012 00:02:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1342422133; bh=+lAxjIGSw0BYUe/PDB0P8StMVAYNex58moZm5fNv8+Q=; h=Message-ID:Date:From:MIME-Version:To:References:In-Reply-To:Cc: Subject:List-Id:List-Unsubscribe:List-Archive:List-Post:List-Help: List-Subscribe:Content-Type:Sender; b=oCPm+bYBaV9DaC+Ruto+5hrWP2Un/EcjfBdQaInQn8JgAX4rTqxvY7Cwp4PdiDrPK 4o/yPUQi7yebebq5SfjZxAAOtteYAPpzrYXQ43WDBHvC2J0ICmDFH0PB0PQVdzhm23 8cMSs2fsync88WpZ5M+LIvVMe7ngpIEnSMTsbUdo= 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 D569B11E8079 for ; Mon, 16 Jul 2012 00:02:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MKaUmkg7KYNS for ; Mon, 16 Jul 2012 00:02:11 -0700 (PDT) Received: from smtprelay.restena.lu (smtprelay.restena.lu [IPv6:2001:a18:1::62]) by ietfa.amsl.com (Postfix) with ESMTP id 0415611E809B for ; Mon, 16 Jul 2012 00:02:10 -0700 (PDT) Received: from smtprelay.restena.lu (localhost [127.0.0.1]) by smtprelay.restena.lu (Postfix) with ESMTP id 58FA01057F; Mon, 16 Jul 2012 09:02:54 +0200 (CEST) Received: from [IPv6:2001:a18:1:8:65bb:1581:80ca:b5b8] (unknown [IPv6:2001:a18:1:8:65bb:1581:80ca:b5b8]) by smtprelay.restena.lu (Postfix) with ESMTPS id ED3F41057D; Mon, 16 Jul 2012 09:02:53 +0200 (CEST) Message-ID: <5003BC99.7030703@restena.lu> Date: Mon, 16 Jul 2012 09:02:49 +0200 From: Stefan Winter User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:13.0) Gecko/20120601 Thunderbird/13.0 MIME-Version: 1.0 To: Peter Deacon References: <20120712081654.17566.87131.idtracker@ietfa.amsl.com> <4FFE8893.30402@restena.lu> <5000DDAB.2070408@deployingradius.com> <500338FB.9070504@deployingradius.com> <50036902.6080807@deployingradius.com> In-Reply-To: X-Enigmail-Version: 1.4.3 X-Virus-Scanned: ClamAV Cc: "radext@ietf.org" , Alan DeKok Subject: Re: [radext] Fwd: New Version Notification for draft-winter-radext-fancyaccounting-01.txt X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============4936906981995206665==" Sender: radext-bounces@ietf.org Errors-To: radext-bounces@ietf.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --===============4936906981995206665== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig16AFC75EEB4E6DA7226A7009" This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig16AFC75EEB4E6DA7226A7009 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi, > Your origional response mentioned only class labels be replaced with > filter rules. Nothing was said about configuring those rules in the NA= S > by pushing parameters via Access-Accept. I think this configuration > would be useful. That certainly sounds useful indeed (but is again nothing I would put into this *accounting* draft). > However to use filter rules as the analogy we still have and use > Filter-Id. If anything I would prefer to see both options made > avaliable enabling people to choose the solution which best fits their > needs. >=20 > Not all problems can be or are best solved by pushing filters as syntax= > is limited. That's right - and my main concern with restricting the traffic descriptor to the exact syntax used. Here is one use case which is (almost) taken from real life, and hopefully shows that pushing the exact syntax over and over again in every accounting packet may be less than practical. Our network is a science network, interconnected with other national science networks over a common backbone ("GEANT"). Since users sometimes use resources outside the scienitfic networks ("the internet"), there is also an outlet on that common backbone to peer with the world at large, called the Dante World Service (DWS). Intra-GEANT traffic is subsidised, DWS is not. A science network *might* want to find out which of their connected entities cause which fraction of traffic on DWS, to send a bill about that traffic - but not the GEANT one. (Disclaimer: the wish to send bills for that is entirely fictional and only made up here for argument purposes; the rest of the example is real life though) The classification "GEANT or DWS" is not simple - there are some 50 ASes in the GEANT backbone, most of which have multiple IP prefixes in their announcement. A NAS would thus need to know a three-digit amount of IP prefixes to classify traffic. Getting the list to the NAS alone is a daunting task, but luckily it needs to be done just one time. Sending the exact filter definition with hundreds of prefixes in *every accounting packet* sounds extremely impractical to me! If I had a traffic label called "urn:geant:dws-traffic" - I would be a lot happier than with receiving a huge blob of IP filter rules all the time. Greetings, Stefan Winter --=20 Stefan WINTER Ingenieur de Recherche Fondation RESTENA - R=E9seau T=E9l=E9informatique de l'Education National= e et de la Recherche 6, rue Richard Coudenhove-Kalergi L-1359 Luxembourg Tel: +352 424409 1 Fax: +352 422473 --------------enig16AFC75EEB4E6DA7226A7009 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.0.18 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAlADvJ0ACgkQ+jm90f8eFWZP7gCgiANndeSByAmnwBe8lVvDKxeh Tu8An0M4BGwiQnHGAQ9yc0tNFLq2oJnR =BnNL -----END PGP SIGNATURE----- --------------enig16AFC75EEB4E6DA7226A7009-- --===============4936906981995206665== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ radext mailing list radext@ietf.org https://www.ietf.org/mailman/listinfo/radext --===============4936906981995206665==-- From internet-drafts@ietf.org Mon Jul 16 06:19:53 2012 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 91B0F21F8734; Mon, 16 Jul 2012 06:19:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.522 X-Spam-Level: X-Spam-Status: No, score=-102.522 tagged_above=-999 required=5 tests=[AWL=0.077, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RO-cwQKgSiH9; Mon, 16 Jul 2012 06:19:52 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 548A221F85A8; Mon, 16 Jul 2012 06:19:52 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.30p3 Message-ID: <20120716131952.1425.82920.idtracker@ietfa.amsl.com> Date: Mon, 16 Jul 2012 06:19:52 -0700 Cc: radext@ietf.org Subject: [radext] I-D Action: draft-ietf-radext-dtls-02.txt X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 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, 16 Jul 2012 13:19:53 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the RADIUS EXTensions Working Group of the IE= TF. Title : DTLS as a Transport Layer for RADIUS Author(s) : Alan DeKok Filename : draft-ietf-radext-dtls-02.txt Pages : 18 Date : 2012-07-16 Abstract: The RADIUS protocol [RFC2865] has limited support for authentication and encryption of RADIUS packets. The protocol transports data "in the clear", although some parts of the packets can have "obfuscated" content. Packets may be replayed verbatim by an attacker, and client-server authentication is based on fixed shared secrets. This document specifies how the Datagram Transport Layer Security (DTLS) protocol may be used as a fix for these problems. It also describes how implementations of this proposal can co-exist with current RADIUS systems. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-radext-dtls There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-radext-dtls-02 A diff from previous version is available at: http://tools.ietf.org/rfcdiff?url2=3Ddraft-ietf-radext-dtls-02 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From radext-bounces@ietf.org Mon Jul 16 06:19:55 2012 Return-Path: X-Original-To: radext-archive-IeZ9sae2@lists.ietf.org Delivered-To: ietfarch-radext-archive-IeZ9sae2@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0731521F8731; Mon, 16 Jul 2012 06:19:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1342444795; bh=7e1pj2GDFthitZugASB5qyX5iHwiqrrKqF5uv+ejLMY=; h=MIME-Version:From:To:Message-ID:Date:Cc:Subject:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: Content-Type:Content-Transfer-Encoding:Sender; b=N5SNlqu8Zh4EY1JTx/xefBFRvXxn4tKDTCNLd5QvfB4NrHm+rchJezk5xQyPpiwXw cFnkykYZCHqgDjGCb8sf/DEhM7BHWzQPgx+Hpb4WF8+w0mCx5CSyiKnQsLkvveMqUm YU8lBZQLw1DSVaRa9XVJuS9rwjZwIKej4/srCCKE= 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 91B0F21F8734; Mon, 16 Jul 2012 06:19:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.522 X-Spam-Level: X-Spam-Status: No, score=-102.522 tagged_above=-999 required=5 tests=[AWL=0.077, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RO-cwQKgSiH9; Mon, 16 Jul 2012 06:19:52 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 548A221F85A8; Mon, 16 Jul 2012 06:19:52 -0700 (PDT) MIME-Version: 1.0 From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.30p3 Message-ID: <20120716131952.1425.82920.idtracker@ietfa.amsl.com> Date: Mon, 16 Jul 2012 06:19:52 -0700 Cc: radext@ietf.org Subject: [radext] I-D Action: draft-ietf-radext-dtls-02.txt X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: radext-bounces@ietf.org Errors-To: radext-bounces@ietf.org 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 : DTLS as a Transport Layer for RADIUS Author(s) : Alan DeKok Filename : draft-ietf-radext-dtls-02.txt Pages : 18 Date : 2012-07-16 Abstract: The RADIUS protocol [RFC2865] has limited support for authentication and encryption of RADIUS packets. The protocol transports data "in the clear", although some parts of the packets can have "obfuscated" content. Packets may be replayed verbatim by an attacker, and client-server authentication is based on fixed shared secrets. This document specifies how the Datagram Transport Layer Security (DTLS) protocol may be used as a fix for these problems. It also describes how implementations of this proposal can co-exist with current RADIUS systems. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-radext-dtls There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-radext-dtls-02 A diff from previous version is available at: http://tools.ietf.org/rfcdiff?url2=draft-ietf-radext-dtls-02 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ radext mailing list radext@ietf.org https://www.ietf.org/mailman/listinfo/radext From aland@deployingradius.com Mon Jul 16 06:30:09 2012 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 9A2A121F86BB for ; Mon, 16 Jul 2012 06:30:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.558 X-Spam-Level: X-Spam-Status: No, score=-102.558 tagged_above=-999 required=5 tests=[AWL=0.041, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0hQjn6Bf8kB4 for ; Mon, 16 Jul 2012 06:30:09 -0700 (PDT) Received: from liberty.deployingradius.com (liberty.deployingradius.com [88.191.76.128]) by ietfa.amsl.com (Postfix) with ESMTP id DC6A421F883F for ; Mon, 16 Jul 2012 06:30:08 -0700 (PDT) Message-ID: <50041771.3070707@deployingradius.com> Date: Mon, 16 Jul 2012 09:30:25 -0400 From: Alan DeKok User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: radext@ietf.org References: <20120716131952.1425.82920.idtracker@ietfa.amsl.com> In-Reply-To: <20120716131952.1425.82920.idtracker@ietfa.amsl.com> X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [radext] I-D Action: draft-ietf-radext-dtls-02.txt X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 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, 16 Jul 2012 13:30:09 -0000 I found some free time this week, and managed to get it in under the wire. It's still a work in progress (internal cross-references need to be fixed). But it's been updated with all of the latest discussion and references to RFC 6614. This should probably be discussed at the next meeting. internet-drafts@ietf.org wrote: > 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 : DTLS as a Transport Layer for RADIUS > Author(s) : Alan DeKok > Filename : draft-ietf-radext-dtls-02.txt > Pages : 18 > Date : 2012-07-16 > > Abstract: > The RADIUS protocol [RFC2865] has limited support for authentication > and encryption of RADIUS packets. The protocol transports data "in > the clear", although some parts of the packets can have "obfuscated" > content. Packets may be replayed verbatim by an attacker, and > client-server authentication is based on fixed shared secrets. This > document specifies how the Datagram Transport Layer Security (DTLS) > protocol may be used as a fix for these problems. It also describes > how implementations of this proposal can co-exist with current RADIUS > systems. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-radext-dtls > > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-radext-dtls-02 > > A diff from previous version is available at: > http://tools.ietf.org/rfcdiff?url2=draft-ietf-radext-dtls-02 > > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > radext mailing list > radext@ietf.org > https://www.ietf.org/mailman/listinfo/radext > > From radext-bounces@ietf.org Mon Jul 16 06:30:11 2012 Return-Path: X-Original-To: radext-archive-IeZ9sae2@lists.ietf.org Delivered-To: ietfarch-radext-archive-IeZ9sae2@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C185421F86BB; Mon, 16 Jul 2012 06:30:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1342445411; bh=+ek8+F1H+oHldkLI+wIz9uV+EWiq7NrznPYq3Tpxz+8=; h=Message-ID:Date:From:MIME-Version:To:References:In-Reply-To: Subject:List-Id:List-Unsubscribe:List-Archive:List-Post:List-Help: List-Subscribe:Content-Type:Content-Transfer-Encoding:Sender; b=K21JlSrFY7VHivPvgJYIdo00Ux8PdwcdMb/y+AmxgegYKz9jraUtvO7EF6SEzGQpK BMI4dUo4FhsZx/2K1O2NpI3N6FsnzT4H+ihSDpqDHK1SMyyrafx+kNdzjPZsx3LSOj Oe1ixjUQddKroHAfjJsBXu/TjfYt45scyUaD/Bx4= 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 9A2A121F86BB for ; Mon, 16 Jul 2012 06:30:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.558 X-Spam-Level: X-Spam-Status: No, score=-102.558 tagged_above=-999 required=5 tests=[AWL=0.041, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0hQjn6Bf8kB4 for ; Mon, 16 Jul 2012 06:30:09 -0700 (PDT) Received: from liberty.deployingradius.com (liberty.deployingradius.com [88.191.76.128]) by ietfa.amsl.com (Postfix) with ESMTP id DC6A421F883F for ; Mon, 16 Jul 2012 06:30:08 -0700 (PDT) Message-ID: <50041771.3070707@deployingradius.com> Date: Mon, 16 Jul 2012 09:30:25 -0400 From: Alan DeKok User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: radext@ietf.org References: <20120716131952.1425.82920.idtracker@ietfa.amsl.com> In-Reply-To: <20120716131952.1425.82920.idtracker@ietfa.amsl.com> X-Enigmail-Version: 0.96.0 Subject: Re: [radext] I-D Action: draft-ietf-radext-dtls-02.txt X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: radext-bounces@ietf.org Errors-To: radext-bounces@ietf.org I found some free time this week, and managed to get it in under the wire. It's still a work in progress (internal cross-references need to be fixed). But it's been updated with all of the latest discussion and references to RFC 6614. This should probably be discussed at the next meeting. internet-drafts@ietf.org wrote: > 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 : DTLS as a Transport Layer for RADIUS > Author(s) : Alan DeKok > Filename : draft-ietf-radext-dtls-02.txt > Pages : 18 > Date : 2012-07-16 > > Abstract: > The RADIUS protocol [RFC2865] has limited support for authentication > and encryption of RADIUS packets. The protocol transports data "in > the clear", although some parts of the packets can have "obfuscated" > content. Packets may be replayed verbatim by an attacker, and > client-server authentication is based on fixed shared secrets. This > document specifies how the Datagram Transport Layer Security (DTLS) > protocol may be used as a fix for these problems. It also describes > how implementations of this proposal can co-exist with current RADIUS > systems. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-radext-dtls > > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-radext-dtls-02 > > A diff from previous version is available at: > http://tools.ietf.org/rfcdiff?url2=draft-ietf-radext-dtls-02 > > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > radext mailing list > radext@ietf.org > https://www.ietf.org/mailman/listinfo/radext > > _______________________________________________ radext mailing list radext@ietf.org https://www.ietf.org/mailman/listinfo/radext From stefan.winter@restena.lu Mon Jul 16 06:54:07 2012 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 6D55421F8842 for ; Mon, 16 Jul 2012 06:54:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FzcoHSC4EoWU for ; Mon, 16 Jul 2012 06:53:51 -0700 (PDT) Received: from smtprelay.restena.lu (smtprelay.restena.lu [IPv6:2001:a18:1::62]) by ietfa.amsl.com (Postfix) with ESMTP id 3F30721F8811 for ; Mon, 16 Jul 2012 06:53:51 -0700 (PDT) Received: from smtprelay.restena.lu (localhost [127.0.0.1]) by smtprelay.restena.lu (Postfix) with ESMTP id CE21F1057F for ; Mon, 16 Jul 2012 15:54:34 +0200 (CEST) Received: from [IPv6:2001:a18:1:8:106:16d0:fdf7:8359] (unknown [IPv6:2001:a18:1:8:106:16d0:fdf7:8359]) by smtprelay.restena.lu (Postfix) with ESMTPS id C11F61057E for ; Mon, 16 Jul 2012 15:54:34 +0200 (CEST) Message-ID: <50041D1A.8060709@restena.lu> Date: Mon, 16 Jul 2012 15:54:34 +0200 From: Stefan Winter User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:13.0) Gecko/20120601 Thunderbird/13.0 MIME-Version: 1.0 To: "radext@ietf.org" References: <20120716135208.19845.54684.idtracker@ietfa.amsl.com> In-Reply-To: <20120716135208.19845.54684.idtracker@ietfa.amsl.com> X-Enigmail-Version: 1.4.3 X-Forwarded-Message-Id: <20120716135208.19845.54684.idtracker@ietfa.amsl.com> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig34BA0577B17A76F4407309F7" X-Virus-Scanned: ClamAV Subject: [radext] Fwd: New Version Notification for draft-winter-radext-fancyaccounting-02.txt X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 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, 16 Jul 2012 13:54:08 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig34BA0577B17A76F4407309F7 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi, this is a new rev with the two agreed changes: - sub-attributes don't occur exactly once, but at most once - clarify that a value sent during Interim-Update MUST also occur in the final Stop record. Greetings, Stefan Winter -------- Original Message -------- Subject: New Version Notification for draft-winter-radext-fancyaccounting-02.txt Date: Mon, 16 Jul 2012 06:52:08 -0700 From: internet-drafts@ietf.org To: stefan.winter@restena.lu A new version of I-D, draft-winter-radext-fancyaccounting-02.txt has been successfully submitted by Stefan Winter and posted to the IETF repository. Filename: draft-winter-radext-fancyaccounting Revision: 02 Title: RADIUS Accounting for traffic classes Creation date: 2012-07-16 WG ID: Individual Submission Number of pages: 9 URL: http://www.ietf.org/internet-drafts/draft-winter-radext-fancyaccounting-0= 2.txt Status: http://datatracker.ietf.org/doc/draft-winter-radext-fancyaccounting Htmlized: http://tools.ietf.org/html/draft-winter-radext-fancyaccounting-02 Diff: http://tools.ietf.org/rfcdiff?url2=3Ddraft-winter-radext-fancyaccounting-= 02 Abstract: This document specifies new attributes for RADIUS Accounting to enable NAS reporting of subsets of the total traffic in a user session. The IETF Secretariat --------------enig34BA0577B17A76F4407309F7 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.0.18 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAlAEHRoACgkQ+jm90f8eFWaaywCfTtDxrKfkZiIUD07eZ5+pfJRU xTwAoIH2BEUFsS9EMPLQO/+UPj9s9WH7 =d80P -----END PGP SIGNATURE----- --------------enig34BA0577B17A76F4407309F7-- From radext-bounces@ietf.org Mon Jul 16 06:54:10 2012 Return-Path: X-Original-To: radext-archive-IeZ9sae2@lists.ietf.org Delivered-To: ietfarch-radext-archive-IeZ9sae2@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1C36A21F8842; Mon, 16 Jul 2012 06:54:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1342446850; bh=X03iEbTMkFiN8jZle7vaF8nvQdni9sm5McPq1FG88pg=; h=Message-ID:Date:From:MIME-Version:To:References:In-Reply-To: Subject:List-Id:List-Unsubscribe:List-Archive:List-Post:List-Help: List-Subscribe:Content-Type:Sender; b=joEsCFKBlneeLfTE5gYIi/JqTn2gBPG5mFYUkS2OrKPblaP3kC5QJnJcy1558aYzZ Lj3fmSOeBJm8V8XInl4wkNM8OBcrfosDUUnIxkAQ0uutztNn83JFNwTYFQfmC1c52A iNpi3Sr4xR7lOHIe4YDtMGyfBFyJWUVmags1p3Cs= 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 6D55421F8842 for ; Mon, 16 Jul 2012 06:54:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FzcoHSC4EoWU for ; Mon, 16 Jul 2012 06:53:51 -0700 (PDT) Received: from smtprelay.restena.lu (smtprelay.restena.lu [IPv6:2001:a18:1::62]) by ietfa.amsl.com (Postfix) with ESMTP id 3F30721F8811 for ; Mon, 16 Jul 2012 06:53:51 -0700 (PDT) Received: from smtprelay.restena.lu (localhost [127.0.0.1]) by smtprelay.restena.lu (Postfix) with ESMTP id CE21F1057F for ; Mon, 16 Jul 2012 15:54:34 +0200 (CEST) Received: from [IPv6:2001:a18:1:8:106:16d0:fdf7:8359] (unknown [IPv6:2001:a18:1:8:106:16d0:fdf7:8359]) by smtprelay.restena.lu (Postfix) with ESMTPS id C11F61057E for ; Mon, 16 Jul 2012 15:54:34 +0200 (CEST) Message-ID: <50041D1A.8060709@restena.lu> Date: Mon, 16 Jul 2012 15:54:34 +0200 From: Stefan Winter User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:13.0) Gecko/20120601 Thunderbird/13.0 MIME-Version: 1.0 To: "radext@ietf.org" References: <20120716135208.19845.54684.idtracker@ietfa.amsl.com> In-Reply-To: <20120716135208.19845.54684.idtracker@ietfa.amsl.com> X-Enigmail-Version: 1.4.3 X-Forwarded-Message-Id: <20120716135208.19845.54684.idtracker@ietfa.amsl.com> X-Virus-Scanned: ClamAV Subject: [radext] Fwd: New Version Notification for draft-winter-radext-fancyaccounting-02.txt X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============2549657096784148249==" Sender: radext-bounces@ietf.org Errors-To: radext-bounces@ietf.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --===============2549657096784148249== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig34BA0577B17A76F4407309F7" This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig34BA0577B17A76F4407309F7 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi, this is a new rev with the two agreed changes: - sub-attributes don't occur exactly once, but at most once - clarify that a value sent during Interim-Update MUST also occur in the final Stop record. Greetings, Stefan Winter -------- Original Message -------- Subject: New Version Notification for draft-winter-radext-fancyaccounting-02.txt Date: Mon, 16 Jul 2012 06:52:08 -0700 From: internet-drafts@ietf.org To: stefan.winter@restena.lu A new version of I-D, draft-winter-radext-fancyaccounting-02.txt has been successfully submitted by Stefan Winter and posted to the IETF repository. Filename: draft-winter-radext-fancyaccounting Revision: 02 Title: RADIUS Accounting for traffic classes Creation date: 2012-07-16 WG ID: Individual Submission Number of pages: 9 URL: http://www.ietf.org/internet-drafts/draft-winter-radext-fancyaccounting-0= 2.txt Status: http://datatracker.ietf.org/doc/draft-winter-radext-fancyaccounting Htmlized: http://tools.ietf.org/html/draft-winter-radext-fancyaccounting-02 Diff: http://tools.ietf.org/rfcdiff?url2=3Ddraft-winter-radext-fancyaccounting-= 02 Abstract: This document specifies new attributes for RADIUS Accounting to enable NAS reporting of subsets of the total traffic in a user session. The IETF Secretariat --------------enig34BA0577B17A76F4407309F7 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.0.18 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAlAEHRoACgkQ+jm90f8eFWaaywCfTtDxrKfkZiIUD07eZ5+pfJRU xTwAoIH2BEUFsS9EMPLQO/+UPj9s9WH7 =d80P -----END PGP SIGNATURE----- --------------enig34BA0577B17A76F4407309F7-- --===============2549657096784148249== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ radext mailing list radext@ietf.org https://www.ietf.org/mailman/listinfo/radext --===============2549657096784148249==-- From aland@deployingradius.com Mon Jul 16 07:17:44 2012 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 1F5E711E80BF for ; Mon, 16 Jul 2012 07:17:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.561 X-Spam-Level: X-Spam-Status: No, score=-102.561 tagged_above=-999 required=5 tests=[AWL=0.038, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zmryv2qzN5N0 for ; Mon, 16 Jul 2012 07:17:43 -0700 (PDT) Received: from liberty.deployingradius.com (liberty.deployingradius.com [88.191.76.128]) by ietfa.amsl.com (Postfix) with ESMTP id 4BA8F21F884C for ; Mon, 16 Jul 2012 07:17:43 -0700 (PDT) Message-ID: <50042298.5020508@deployingradius.com> Date: Mon, 16 Jul 2012 10:18:00 -0400 From: Alan DeKok User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: Peter Deacon , "radext@ietf.org" References: <20120712081654.17566.87131.idtracker@ietfa.amsl.com> <4FFE8893.30402@restena.lu> <5000DDAB.2070408@deployingradius.com> <500338FB.9070504@deployingradius.com> <50036902.6080807@deployingradius.com> In-Reply-To: X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [radext] Fwd: New Version Notification for draft-winter-radext-fancyaccounting-01.txt X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 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, 16 Jul 2012 14:17:44 -0000 Peter Deacon wrote: > Your origional response mentioned only class labels be replaced with > filter rules. Nothing was said about configuring those rules in the NAS > by pushing parameters via Access-Accept. I think this configuration > would be useful. OK. > However to use filter rules as the analogy we still have and use > Filter-Id. If anything I would prefer to see both options made > avaliable enabling people to choose the solution which best fits their > needs. Yes. > Not all problems can be or are best solved by pushing filters as syntax > is limited. Yes. Alan DeKok. From radext-bounces@ietf.org Mon Jul 16 07:17:46 2012 Return-Path: X-Original-To: radext-archive-IeZ9sae2@lists.ietf.org Delivered-To: ietfarch-radext-archive-IeZ9sae2@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0A37711E80BF; Mon, 16 Jul 2012 07:17:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1342448266; bh=7l9pshpafWnQXMWk/PSKjq4OwkYwpuFcxs3RMdvZFNQ=; h=Message-ID:Date:From:MIME-Version:To:References:In-Reply-To: Subject:List-Id:List-Unsubscribe:List-Archive:List-Post:List-Help: List-Subscribe:Content-Type:Content-Transfer-Encoding:Sender; b=Ak1aI/1AMKHqffJ3OiAs3IMtA0dQGcRN9K203AdrrgilOr64PSf3Ts7uQURC/uMG+ KEXgOU2ei8dqz0Q6gV/pPpe5I8VaiaQXfwFvfPIOe/P6JgUy+sO2ZcX6IxBdLaxxRQ t1MZmKRPmNaG83ro1SDkNBT5IOIz0LnZoPsr1tv8= 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 1F5E711E80BF for ; Mon, 16 Jul 2012 07:17:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.561 X-Spam-Level: X-Spam-Status: No, score=-102.561 tagged_above=-999 required=5 tests=[AWL=0.038, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zmryv2qzN5N0 for ; Mon, 16 Jul 2012 07:17:43 -0700 (PDT) Received: from liberty.deployingradius.com (liberty.deployingradius.com [88.191.76.128]) by ietfa.amsl.com (Postfix) with ESMTP id 4BA8F21F884C for ; Mon, 16 Jul 2012 07:17:43 -0700 (PDT) Message-ID: <50042298.5020508@deployingradius.com> Date: Mon, 16 Jul 2012 10:18:00 -0400 From: Alan DeKok User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: Peter Deacon , "radext@ietf.org" References: <20120712081654.17566.87131.idtracker@ietfa.amsl.com> <4FFE8893.30402@restena.lu> <5000DDAB.2070408@deployingradius.com> <500338FB.9070504@deployingradius.com> <50036902.6080807@deployingradius.com> In-Reply-To: X-Enigmail-Version: 0.96.0 Subject: Re: [radext] Fwd: New Version Notification for draft-winter-radext-fancyaccounting-01.txt X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: radext-bounces@ietf.org Errors-To: radext-bounces@ietf.org Peter Deacon wrote: > Your origional response mentioned only class labels be replaced with > filter rules. Nothing was said about configuring those rules in the NAS > by pushing parameters via Access-Accept. I think this configuration > would be useful. OK. > However to use filter rules as the analogy we still have and use > Filter-Id. If anything I would prefer to see both options made > avaliable enabling people to choose the solution which best fits their > needs. Yes. > Not all problems can be or are best solved by pushing filters as syntax > is limited. Yes. Alan DeKok. _______________________________________________ radext mailing list radext@ietf.org https://www.ietf.org/mailman/listinfo/radext From jouni.nospam@gmail.com Mon Jul 16 07:27:29 2012 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 9EC4011E80E0 for ; Mon, 16 Jul 2012 07:27:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LEA22MEwQkkW for ; Mon, 16 Jul 2012 07:27:29 -0700 (PDT) Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by ietfa.amsl.com (Postfix) with ESMTP id 4E2C911E80C6 for ; Mon, 16 Jul 2012 07:27:28 -0700 (PDT) Received: by lbbgo11 with SMTP id go11so8197010lbb.31 for ; Mon, 16 Jul 2012 07:28:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=MPT6m596m96KZ5XjGL8zcc2gEmv4ZxU3YwBGK1Zji6s=; b=bK5SQSkGSX8PkmjTt9RtpkYQYbmAtQlgc4wr81Q5g/duhtzjFo84r3cmg48ANuLTV7 sfnt7ppakjclDUKTnzF7bK0PMOanG68e5nujSlkWo61iQ0+sFWquNTLia7WF0gS01IDR MTh1WxtKm60JewK8FA8OLKvocUZr7eo5gNMincqLo04ptYPo2jP2bUXU0GmjE+ndLo80 t7L8k/UN9xMEyCU/e2ylp+JHKs4nViY63EuGUWNl33jDujC0vchTcvOe9uIdw/QeXTJm WJ4SNMpfJXyefXj4XTFNjNMdc0eZdREGZ2J0rqA6I63D/AwrqFvOC7Q4kwRV9qxh5yfm xgYA== Received: by 10.112.42.164 with SMTP id p4mr5457253lbl.54.1342448892212; Mon, 16 Jul 2012 07:28:12 -0700 (PDT) Received: from [10.37.150.10] ([77.95.242.69]) by mx.google.com with ESMTPS id jj5sm16217776lab.1.2012.07.16.07.27.59 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 16 Jul 2012 07:28:02 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=iso-8859-1 From: jouni korhonen In-Reply-To: Date: Mon, 16 Jul 2012 17:27:56 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <6FCB2A97-0DE2-4288-A250-361C1C2C151A@gmail.com> References: To: Wojciech Dec (wdec) X-Mailer: Apple Mail (2.1084) Cc: "radext@ietf.org" , Maglione Roberta , Ullio Mario Subject: Re: [radext] Question about draft-ietf-radext-ipv6-access-08.txt X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 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, 16 Jul 2012 14:27:29 -0000 Thanks for doing the update. I noticed that between the update from -07 = to -08 the reference for RFC3162 got dropped from the references listing = (Section 8.2). - Jouni On Jun 28, 2012, at 4:58 PM, Wojciech Dec (wdec) wrote: > Hi Roberta, >=20 > Uhm... Sloppy fingers. Version -09 on its way >=20 > -Woj.. >=20 > On 28/06/2012 15:43, "Maglione Roberta" > wrote: >=20 >> Hello, >> I have a question regarding section 3.6: >> Why in version -08 the attributes Delegated-IPv6-Prefix-Pool and >> Stateful-IPv6-Address-Pool are not allowed any more in Accounting >> messages? >> They were there in previous versions, in addition Framed-IPv6-Pool >> defined in RFC 3162, is allowed in Accounting message. >> Could you please clarify the reasons behind this change? >> Thanks >> Regards, >> Roberta >>=20 >>=20 >> -----Original Message----- >> From: radext-bounces@ietf.org [mailto:radext-bounces@ietf.org] On = Behalf >> Of internet-drafts@ietf.org >> Sent: mercoled=EC 27 giugno 2012 20.19 >> To: i-d-announce@ietf.org >> Cc: radext@ietf.org >> Subject: [radext] I-D Action: draft-ietf-radext-ipv6-access-08.txt >>=20 >>=20 >> 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. >>=20 >> Title : RADIUS attributes for IPv6 Access Networks >> Author(s) : Wojciech Dec >> Behcet Sarikaya >> Glen Zorn >> David Miles >> Benoit Lourdelet >> Filename : draft-ietf-radext-ipv6-access-08.txt >> Pages : 14 >> Date : 2012-06-27 >>=20 >> Abstract: >> This document specifies additional IPv6 RADIUS attributes useful in >> residential broadband network deployments. The attributes, which = are >> used for authorization and accounting, enable assignment of a host >> IPv6 address and IPv6 DNS server address via DHCPv6; assignment of = an >> IPv6 route announced via router advertisement; assignment of a named >> IPv6 delegated prefix pool; and assignment of a named IPv6 pool for >> host DHCPv6 addressing. >>=20 >>=20 >>=20 >> The IETF datatracker status page for this draft is: >> https://datatracker.ietf.org/doc/draft-ietf-radext-ipv6-access >>=20 >> There's also a htmlized version available at: >> http://tools.ietf.org/html/draft-ietf-radext-ipv6-access-08 >>=20 >> A diff from previous version is available at: >> http://tools.ietf.org/rfcdiff?url2=3Ddraft-ietf-radext-ipv6-access-08 >>=20 >>=20 >> Internet-Drafts are also available by anonymous FTP at: >> ftp://ftp.ietf.org/internet-drafts/ >>=20 >> _______________________________________________ >> radext mailing list >> radext@ietf.org >> https://www.ietf.org/mailman/listinfo/radext >>=20 >> Questo messaggio e i suoi allegati sono indirizzati esclusivamente = alle >> persone indicate. La diffusione, copia o qualsiasi altra azione = derivante >> dalla conoscenza di queste informazioni sono rigorosamente vietate. >> Qualora abbiate ricevuto questo documento per errore siete = cortesemente >> pregati di darne immediata comunicazione al mittente e di provvedere = alla >> sua distruzione, Grazie. >>=20 >> This e-mail and any attachments is confidential and may contain >> privileged information intended for the addressee(s) only. = Dissemination, >> copying, printing or use by anybody else is unauthorised. If you are = not >> the intended recipient, please delete this message and any = attachments >> and advise the sender by return e-mail, Thanks. >>=20 >=20 > _______________________________________________ > radext mailing list > radext@ietf.org > https://www.ietf.org/mailman/listinfo/radext From radext-bounces@ietf.org Mon Jul 16 07:27:31 2012 Return-Path: X-Original-To: radext-archive-IeZ9sae2@lists.ietf.org Delivered-To: ietfarch-radext-archive-IeZ9sae2@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8A2BC11E80E0; Mon, 16 Jul 2012 07:27:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1342448851; bh=E0eyT8K2DgghZK8EaQzfX4egMv54xs93eBfLVHjGrBM=; h=Mime-Version:From:In-Reply-To:Date:Message-Id:References:To:Cc: Subject:List-Id:List-Unsubscribe:List-Archive:List-Post:List-Help: List-Subscribe:Content-Type:Content-Transfer-Encoding:Sender; b=Vd2PSHriDPkMpciiNpYjCDwQBmO1YcP96nSave8/9NY5xisL02uxxqhqgO5qfyP1g wEVZY/Ce6t7lO81lWnD4MAatW1VTbVdL6bjyRa5wOi4o7dLJRnQvx1RMHmHnd59Ocb Ju7rY40o5bc8IfRh0bp3dqhg+WF3ceCw5YwxX1LI= 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 9EC4011E80E0 for ; Mon, 16 Jul 2012 07:27:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LEA22MEwQkkW for ; Mon, 16 Jul 2012 07:27:29 -0700 (PDT) Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by ietfa.amsl.com (Postfix) with ESMTP id 4E2C911E80C6 for ; Mon, 16 Jul 2012 07:27:28 -0700 (PDT) Received: by lbbgo11 with SMTP id go11so8197010lbb.31 for ; Mon, 16 Jul 2012 07:28:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=MPT6m596m96KZ5XjGL8zcc2gEmv4ZxU3YwBGK1Zji6s=; b=bK5SQSkGSX8PkmjTt9RtpkYQYbmAtQlgc4wr81Q5g/duhtzjFo84r3cmg48ANuLTV7 sfnt7ppakjclDUKTnzF7bK0PMOanG68e5nujSlkWo61iQ0+sFWquNTLia7WF0gS01IDR MTh1WxtKm60JewK8FA8OLKvocUZr7eo5gNMincqLo04ptYPo2jP2bUXU0GmjE+ndLo80 t7L8k/UN9xMEyCU/e2ylp+JHKs4nViY63EuGUWNl33jDujC0vchTcvOe9uIdw/QeXTJm WJ4SNMpfJXyefXj4XTFNjNMdc0eZdREGZ2J0rqA6I63D/AwrqFvOC7Q4kwRV9qxh5yfm xgYA== Received: by 10.112.42.164 with SMTP id p4mr5457253lbl.54.1342448892212; Mon, 16 Jul 2012 07:28:12 -0700 (PDT) Received: from [10.37.150.10] ([77.95.242.69]) by mx.google.com with ESMTPS id jj5sm16217776lab.1.2012.07.16.07.27.59 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 16 Jul 2012 07:28:02 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1084) From: jouni korhonen In-Reply-To: Date: Mon, 16 Jul 2012 17:27:56 +0300 Message-Id: <6FCB2A97-0DE2-4288-A250-361C1C2C151A@gmail.com> References: To: Wojciech Dec (wdec) X-Mailer: Apple Mail (2.1084) Cc: "radext@ietf.org" , Maglione Roberta , Ullio Mario Subject: Re: [radext] Question about draft-ietf-radext-ipv6-access-08.txt X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: radext-bounces@ietf.org Errors-To: radext-bounces@ietf.org Thanks for doing the update. I noticed that between the update from -07 to = -08 the reference for RFC3162 got dropped from the references listing (Section = 8.2). - Jouni On Jun 28, 2012, at 4:58 PM, Wojciech Dec (wdec) wrote: > Hi Roberta, > = > Uhm... Sloppy fingers. Version -09 on its way > = > -Woj.. > = > On 28/06/2012 15:43, "Maglione Roberta" > wrote: > = >> Hello, >> I have a question regarding section 3.6: >> Why in version -08 the attributes Delegated-IPv6-Prefix-Pool and >> Stateful-IPv6-Address-Pool are not allowed any more in Accounting >> messages? >> They were there in previous versions, in addition Framed-IPv6-Pool >> defined in RFC 3162, is allowed in Accounting message. >> Could you please clarify the reasons behind this change? >> Thanks >> Regards, >> Roberta >> = >> = >> -----Original Message----- >> From: radext-bounces@ietf.org [mailto:radext-bounces@ietf.org] On Behalf >> Of internet-drafts@ietf.org >> Sent: mercoled=EC 27 giugno 2012 20.19 >> To: i-d-announce@ietf.org >> Cc: radext@ietf.org >> Subject: [radext] I-D Action: draft-ietf-radext-ipv6-access-08.txt >> = >> = >> 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 : RADIUS attributes for IPv6 Access Networks >> Author(s) : Wojciech Dec >> Behcet Sarikaya >> Glen Zorn >> David Miles >> Benoit Lourdelet >> Filename : draft-ietf-radext-ipv6-access-08.txt >> Pages : 14 >> Date : 2012-06-27 >> = >> Abstract: >> This document specifies additional IPv6 RADIUS attributes useful in >> residential broadband network deployments. The attributes, which are >> used for authorization and accounting, enable assignment of a host >> IPv6 address and IPv6 DNS server address via DHCPv6; assignment of an >> IPv6 route announced via router advertisement; assignment of a named >> IPv6 delegated prefix pool; and assignment of a named IPv6 pool for >> host DHCPv6 addressing. >> = >> = >> = >> The IETF datatracker status page for this draft is: >> https://datatracker.ietf.org/doc/draft-ietf-radext-ipv6-access >> = >> There's also a htmlized version available at: >> http://tools.ietf.org/html/draft-ietf-radext-ipv6-access-08 >> = >> A diff from previous version is available at: >> http://tools.ietf.org/rfcdiff?url2=3Ddraft-ietf-radext-ipv6-access-08 >> = >> = >> Internet-Drafts are also available by anonymous FTP at: >> ftp://ftp.ietf.org/internet-drafts/ >> = >> _______________________________________________ >> radext mailing list >> radext@ietf.org >> https://www.ietf.org/mailman/listinfo/radext >> = >> Questo messaggio e i suoi allegati sono indirizzati esclusivamente alle >> persone indicate. La diffusione, copia o qualsiasi altra azione derivante >> dalla conoscenza di queste informazioni sono rigorosamente vietate. >> Qualora abbiate ricevuto questo documento per errore siete cortesemente >> pregati di darne immediata comunicazione al mittente e di provvedere alla >> sua distruzione, Grazie. >> = >> This e-mail and any attachments is confidential and may contain >> privileged information intended for the addressee(s) only. Dissemination, >> copying, printing or use by anybody else is unauthorised. If you are not >> the intended recipient, please delete this message and any attachments >> and advise the sender by return e-mail, Thanks. >> = > = > _______________________________________________ > radext mailing list > radext@ietf.org > https://www.ietf.org/mailman/listinfo/radext _______________________________________________ radext mailing list radext@ietf.org https://www.ietf.org/mailman/listinfo/radext From wdec@cisco.com Mon Jul 16 07:54:43 2012 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 3747921F8734 for ; Mon, 16 Jul 2012 07:54:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Tpky1QvtQsQ1 for ; Mon, 16 Jul 2012 07:54:42 -0700 (PDT) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) by ietfa.amsl.com (Postfix) with ESMTP id EE28221F86B1 for ; Mon, 16 Jul 2012 07:54:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4210; q=dns/txt; s=iport; t=1342450527; x=1343660127; h=from:to:cc:subject:date:message-id:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=CfBg+dea3V6dZTqWE8BAGjq7I0ofzhxpvIrBWMZrwN0=; b=Q6QNOHycfDH+zjM/SNQFD8dUUI8Mb56IzHh8B2+rfG4NISM3TwTWyhrd UNWlUAIJwQdudq+855C92jBpK9GcFLNAsxLsBsIgR+T/TgW+7SkcBZo2y hKAm86oblRWFo5rdMY+PJ1GJugX845+6CMHM+J5dDbfTaRWB7/Tf436s8 Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAFAqBFCtJV2c/2dsb2JhbABFuTWBB4IgAQEBBAEBAQ8BWwsMBgEIEQQBAQEnKAYLFAkIAQEEDgUih1wDDAucK5YEDYlOilpmGoYtA4gWjSWBEolygxyBZoJfgV8 X-IronPort-AV: E=Sophos;i="4.77,594,1336348800"; d="scan'208";a="99265757" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-9.cisco.com with ESMTP; 16 Jul 2012 14:55:26 +0000 Received: from xhc-rcd-x14.cisco.com (xhc-rcd-x14.cisco.com [173.37.183.88]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id q6GEtQ5d018919 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 16 Jul 2012 14:55:26 GMT Received: from xmb-aln-x05.cisco.com ([169.254.11.114]) by xhc-rcd-x14.cisco.com ([173.37.183.88]) with mapi id 14.02.0298.004; Mon, 16 Jul 2012 09:55:26 -0500 From: "Wojciech Dec (wdec)" To: jouni korhonen Thread-Topic: [radext] Question about draft-ietf-radext-ipv6-access-08.txt Thread-Index: Ac1UkUrqT0FoP3caRDqdn2VcieK8+gAoj6HQAA9M5wADhhc3AAAFJigA Date: Mon, 16 Jul 2012 14:55:25 +0000 Message-ID: In-Reply-To: <6FCB2A97-0DE2-4288-A250-361C1C2C151A@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.2.120421 x-originating-ip: [10.61.110.121] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19042.006 x-tm-as-result: No--45.338100-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "radext@ietf.org" , Maglione Roberta , Ullio Mario Subject: Re: [radext] Question about draft-ietf-radext-ipv6-access-08.txt X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 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, 16 Jul 2012 14:54:43 -0000 Hmm, I ran a script to remove any seemingly unused references... 4818 seems to have also been axed... Version 11 coming. -Woj.. On 16/07/2012 16:27, "jouni korhonen" wrote: > >Thanks for doing the update. I noticed that between the update from -07 >to -08 >the reference for RFC3162 got dropped from the references listing >(Section 8.2). > >- Jouni > > >On Jun 28, 2012, at 4:58 PM, Wojciech Dec (wdec) wrote: > >> Hi Roberta, >>=20 >> Uhm... Sloppy fingers. Version -09 on its way >>=20 >> -Woj.. >>=20 >> On 28/06/2012 15:43, "Maglione Roberta" >> wrote: >>=20 >>> Hello, >>> I have a question regarding section 3.6: >>> Why in version -08 the attributes Delegated-IPv6-Prefix-Pool and >>> Stateful-IPv6-Address-Pool are not allowed any more in Accounting >>> messages? >>> They were there in previous versions, in addition Framed-IPv6-Pool >>> defined in RFC 3162, is allowed in Accounting message. >>> Could you please clarify the reasons behind this change? >>> Thanks >>> Regards, >>> Roberta >>>=20 >>>=20 >>> -----Original Message----- >>> From: radext-bounces@ietf.org [mailto:radext-bounces@ietf.org] On >>>Behalf >>> Of internet-drafts@ietf.org >>> Sent: mercoled=EC 27 giugno 2012 20.19 >>> To: i-d-announce@ietf.org >>> Cc: radext@ietf.org >>> Subject: [radext] I-D Action: draft-ietf-radext-ipv6-access-08.txt >>>=20 >>>=20 >>> 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. >>>=20 >>> Title : RADIUS attributes for IPv6 Access Networks >>> Author(s) : Wojciech Dec >>> Behcet Sarikaya >>> Glen Zorn >>> David Miles >>> Benoit Lourdelet >>> Filename : draft-ietf-radext-ipv6-access-08.txt >>> Pages : 14 >>> Date : 2012-06-27 >>>=20 >>> Abstract: >>> This document specifies additional IPv6 RADIUS attributes useful in >>> residential broadband network deployments. The attributes, which are >>> used for authorization and accounting, enable assignment of a host >>> IPv6 address and IPv6 DNS server address via DHCPv6; assignment of an >>> IPv6 route announced via router advertisement; assignment of a named >>> IPv6 delegated prefix pool; and assignment of a named IPv6 pool for >>> host DHCPv6 addressing. >>>=20 >>>=20 >>>=20 >>> The IETF datatracker status page for this draft is: >>> https://datatracker.ietf.org/doc/draft-ietf-radext-ipv6-access >>>=20 >>> There's also a htmlized version available at: >>> http://tools.ietf.org/html/draft-ietf-radext-ipv6-access-08 >>>=20 >>> A diff from previous version is available at: >>> http://tools.ietf.org/rfcdiff?url2=3Ddraft-ietf-radext-ipv6-access-08 >>>=20 >>>=20 >>> Internet-Drafts are also available by anonymous FTP at: >>> ftp://ftp.ietf.org/internet-drafts/ >>>=20 >>> _______________________________________________ >>> radext mailing list >>> radext@ietf.org >>> https://www.ietf.org/mailman/listinfo/radext >>>=20 >>> Questo messaggio e i suoi allegati sono indirizzati esclusivamente alle >>> persone indicate. La diffusione, copia o qualsiasi altra azione >>>derivante >>> dalla conoscenza di queste informazioni sono rigorosamente vietate. >>> Qualora abbiate ricevuto questo documento per errore siete cortesemente >>> pregati di darne immediata comunicazione al mittente e di provvedere >>>alla >>> sua distruzione, Grazie. >>>=20 >>> This e-mail and any attachments is confidential and may contain >>> privileged information intended for the addressee(s) only. >>>Dissemination, >>> copying, printing or use by anybody else is unauthorised. If you are >>>not >>> the intended recipient, please delete this message and any attachments >>> and advise the sender by return e-mail, Thanks. >>>=20 >>=20 >> _______________________________________________ >> radext mailing list >> radext@ietf.org >> https://www.ietf.org/mailman/listinfo/radext > From radext-bounces@ietf.org Mon Jul 16 07:54:45 2012 Return-Path: X-Original-To: radext-archive-IeZ9sae2@lists.ietf.org Delivered-To: ietfarch-radext-archive-IeZ9sae2@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F2EF121F8734; Mon, 16 Jul 2012 07:54:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1342450485; bh=EIxIGJNNfzJ7MiZtiV7PRrYloiXoHzfIVTO2QDd5Xk4=; h=From:To:Date:Message-ID:In-Reply-To:Content-ID:MIME-Version:Cc: Subject:List-Id:List-Unsubscribe:List-Archive:List-Post:List-Help: List-Subscribe:Content-Type:Content-Transfer-Encoding:Sender; b=ZvB00+v64HaJ6Z7fbGwrRReiL0WFuZF32ZWSNQUWBDDG8L6/n58xZtMTX5XkbajKL V9hQU4TQG85Gv+kF3zgiTyS3ox4JzdBvqXGnpgoSDB2Ngh00UFFEwC8pVQhNk+dFVc ZrpLQkhelXE+3JVQN2hFFGsP6yocP4ZYKY8m9bWg= 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 3747921F8734 for ; Mon, 16 Jul 2012 07:54:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Tpky1QvtQsQ1 for ; Mon, 16 Jul 2012 07:54:42 -0700 (PDT) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) by ietfa.amsl.com (Postfix) with ESMTP id EE28221F86B1 for ; Mon, 16 Jul 2012 07:54:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4210; q=dns/txt; s=iport; t=1342450527; x=1343660127; h=from:to:cc:subject:date:message-id:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=CfBg+dea3V6dZTqWE8BAGjq7I0ofzhxpvIrBWMZrwN0=; b=Q6QNOHycfDH+zjM/SNQFD8dUUI8Mb56IzHh8B2+rfG4NISM3TwTWyhrd UNWlUAIJwQdudq+855C92jBpK9GcFLNAsxLsBsIgR+T/TgW+7SkcBZo2y hKAm86oblRWFo5rdMY+PJ1GJugX845+6CMHM+J5dDbfTaRWB7/Tf436s8 Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAFAqBFCtJV2c/2dsb2JhbABFuTWBB4IgAQEBBAEBAQ8BWwsMBgEIEQQBAQEnKAYLFAkIAQEEDgUih1wDDAucK5YEDYlOilpmGoYtA4gWjSWBEolygxyBZoJfgV8 X-IronPort-AV: E=Sophos;i="4.77,594,1336348800"; d="scan'208";a="99265757" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-9.cisco.com with ESMTP; 16 Jul 2012 14:55:26 +0000 Received: from xhc-rcd-x14.cisco.com (xhc-rcd-x14.cisco.com [173.37.183.88]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id q6GEtQ5d018919 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 16 Jul 2012 14:55:26 GMT Received: from xmb-aln-x05.cisco.com ([169.254.11.114]) by xhc-rcd-x14.cisco.com ([173.37.183.88]) with mapi id 14.02.0298.004; Mon, 16 Jul 2012 09:55:26 -0500 From: "Wojciech Dec (wdec)" To: jouni korhonen Thread-Topic: [radext] Question about draft-ietf-radext-ipv6-access-08.txt Thread-Index: Ac1UkUrqT0FoP3caRDqdn2VcieK8+gAoj6HQAA9M5wADhhc3AAAFJigA Date: Mon, 16 Jul 2012 14:55:25 +0000 Message-ID: In-Reply-To: <6FCB2A97-0DE2-4288-A250-361C1C2C151A@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.2.120421 x-originating-ip: [10.61.110.121] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19042.006 x-tm-as-result: No--45.338100-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-ID: MIME-Version: 1.0 Cc: "radext@ietf.org" , Maglione Roberta , Ullio Mario Subject: Re: [radext] Question about draft-ietf-radext-ipv6-access-08.txt X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: radext-bounces@ietf.org Errors-To: radext-bounces@ietf.org Hmm, I ran a script to remove any seemingly unused references... 4818 seems to have also been axed... Version 11 coming. -Woj.. On 16/07/2012 16:27, "jouni korhonen" wrote: > >Thanks for doing the update. I noticed that between the update from -07 >to -08 >the reference for RFC3162 got dropped from the references listing >(Section 8.2). > >- Jouni > > >On Jun 28, 2012, at 4:58 PM, Wojciech Dec (wdec) wrote: > >> Hi Roberta, >> = >> Uhm... Sloppy fingers. Version -09 on its way >> = >> -Woj.. >> = >> On 28/06/2012 15:43, "Maglione Roberta" >> wrote: >> = >>> Hello, >>> I have a question regarding section 3.6: >>> Why in version -08 the attributes Delegated-IPv6-Prefix-Pool and >>> Stateful-IPv6-Address-Pool are not allowed any more in Accounting >>> messages? >>> They were there in previous versions, in addition Framed-IPv6-Pool >>> defined in RFC 3162, is allowed in Accounting message. >>> Could you please clarify the reasons behind this change? >>> Thanks >>> Regards, >>> Roberta >>> = >>> = >>> -----Original Message----- >>> From: radext-bounces@ietf.org [mailto:radext-bounces@ietf.org] On >>>Behalf >>> Of internet-drafts@ietf.org >>> Sent: mercoled=EC 27 giugno 2012 20.19 >>> To: i-d-announce@ietf.org >>> Cc: radext@ietf.org >>> Subject: [radext] I-D Action: draft-ietf-radext-ipv6-access-08.txt >>> = >>> = >>> 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 : RADIUS attributes for IPv6 Access Networks >>> Author(s) : Wojciech Dec >>> Behcet Sarikaya >>> Glen Zorn >>> David Miles >>> Benoit Lourdelet >>> Filename : draft-ietf-radext-ipv6-access-08.txt >>> Pages : 14 >>> Date : 2012-06-27 >>> = >>> Abstract: >>> This document specifies additional IPv6 RADIUS attributes useful in >>> residential broadband network deployments. The attributes, which are >>> used for authorization and accounting, enable assignment of a host >>> IPv6 address and IPv6 DNS server address via DHCPv6; assignment of an >>> IPv6 route announced via router advertisement; assignment of a named >>> IPv6 delegated prefix pool; and assignment of a named IPv6 pool for >>> host DHCPv6 addressing. >>> = >>> = >>> = >>> The IETF datatracker status page for this draft is: >>> https://datatracker.ietf.org/doc/draft-ietf-radext-ipv6-access >>> = >>> There's also a htmlized version available at: >>> http://tools.ietf.org/html/draft-ietf-radext-ipv6-access-08 >>> = >>> A diff from previous version is available at: >>> http://tools.ietf.org/rfcdiff?url2=3Ddraft-ietf-radext-ipv6-access-08 >>> = >>> = >>> Internet-Drafts are also available by anonymous FTP at: >>> ftp://ftp.ietf.org/internet-drafts/ >>> = >>> _______________________________________________ >>> radext mailing list >>> radext@ietf.org >>> https://www.ietf.org/mailman/listinfo/radext >>> = >>> Questo messaggio e i suoi allegati sono indirizzati esclusivamente alle >>> persone indicate. La diffusione, copia o qualsiasi altra azione >>>derivante >>> dalla conoscenza di queste informazioni sono rigorosamente vietate. >>> Qualora abbiate ricevuto questo documento per errore siete cortesemente >>> pregati di darne immediata comunicazione al mittente e di provvedere >>>alla >>> sua distruzione, Grazie. >>> = >>> This e-mail and any attachments is confidential and may contain >>> privileged information intended for the addressee(s) only. >>>Dissemination, >>> copying, printing or use by anybody else is unauthorised. If you are >>>not >>> the intended recipient, please delete this message and any attachments >>> and advise the sender by return e-mail, Thanks. >>> = >> = >> _______________________________________________ >> radext mailing list >> radext@ietf.org >> https://www.ietf.org/mailman/listinfo/radext > _______________________________________________ radext mailing list radext@ietf.org https://www.ietf.org/mailman/listinfo/radext From internet-drafts@ietf.org Mon Jul 16 08:03:51 2012 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 5D24621F8711; Mon, 16 Jul 2012 08:03:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.527 X-Spam-Level: X-Spam-Status: No, score=-102.527 tagged_above=-999 required=5 tests=[AWL=0.072, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vp1DI1mytNti; Mon, 16 Jul 2012 08:03:50 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9B5F021F871A; Mon, 16 Jul 2012 08:03:50 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.30p3 Message-ID: <20120716150350.11485.75829.idtracker@ietfa.amsl.com> Date: Mon, 16 Jul 2012 08:03:50 -0700 Cc: radext@ietf.org Subject: [radext] I-D Action: draft-ietf-radext-ipv6-access-10.txt X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 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, 16 Jul 2012 15:03:51 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the RADIUS EXTensions Working Group of the IE= TF. Title : RADIUS attributes for IPv6 Access Networks Author(s) : Wojciech Dec Behcet Sarikaya Glen Zorn David Miles Benoit Lourdelet Filename : draft-ietf-radext-ipv6-access-10.txt Pages : 14 Date : 2012-07-16 Abstract: This document specifies additional IPv6 RADIUS attributes useful in residential broadband network deployments. The attributes, which are used for authorization and accounting, enable assignment of a host IPv6 address and IPv6 DNS server address via DHCPv6; assignment of an IPv6 route announced via router advertisement; assignment of a named IPv6 delegated prefix pool; and assignment of a named IPv6 pool for host DHCPv6 addressing. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-radext-ipv6-access There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-radext-ipv6-access-10 A diff from previous version is available at: http://tools.ietf.org/rfcdiff?url2=3Ddraft-ietf-radext-ipv6-access-10 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From radext-bounces@ietf.org Mon Jul 16 08:03:54 2012 Return-Path: X-Original-To: radext-archive-IeZ9sae2@lists.ietf.org Delivered-To: ietfarch-radext-archive-IeZ9sae2@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9803421F8793; Mon, 16 Jul 2012 08:03:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1342451034; bh=llo3WMwlIS6+tTV9ctTZaKRu5CaEix+BTNcFqBzOUW8=; h=MIME-Version:From:To:Message-ID:Date:Cc:Subject:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: Content-Type:Content-Transfer-Encoding:Sender; b=X7upelFtbIJkz7ZOX0Rbw6pt/eN/8QpSA3kcpHkidhUhuWRHptauyk8LdU7gqoXE+ HBvNcpgm3R7eJJmQaheA2UjORinQ61vU/59GrcxbvvDd/XaoReVkoUIj8lk2x7N6Nn ppJZfLyv7zBNL/R6INixJFKVe/DF2qdLIjGZqRk0= 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 5D24621F8711; Mon, 16 Jul 2012 08:03:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.527 X-Spam-Level: X-Spam-Status: No, score=-102.527 tagged_above=-999 required=5 tests=[AWL=0.072, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vp1DI1mytNti; Mon, 16 Jul 2012 08:03:50 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9B5F021F871A; Mon, 16 Jul 2012 08:03:50 -0700 (PDT) MIME-Version: 1.0 From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.30p3 Message-ID: <20120716150350.11485.75829.idtracker@ietfa.amsl.com> Date: Mon, 16 Jul 2012 08:03:50 -0700 Cc: radext@ietf.org Subject: [radext] I-D Action: draft-ietf-radext-ipv6-access-10.txt X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: radext-bounces@ietf.org Errors-To: radext-bounces@ietf.org 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 : RADIUS attributes for IPv6 Access Networks Author(s) : Wojciech Dec Behcet Sarikaya Glen Zorn David Miles Benoit Lourdelet Filename : draft-ietf-radext-ipv6-access-10.txt Pages : 14 Date : 2012-07-16 Abstract: This document specifies additional IPv6 RADIUS attributes useful in residential broadband network deployments. The attributes, which are used for authorization and accounting, enable assignment of a host IPv6 address and IPv6 DNS server address via DHCPv6; assignment of an IPv6 route announced via router advertisement; assignment of a named IPv6 delegated prefix pool; and assignment of a named IPv6 pool for host DHCPv6 addressing. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-radext-ipv6-access There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-radext-ipv6-access-10 A diff from previous version is available at: http://tools.ietf.org/rfcdiff?url2=draft-ietf-radext-ipv6-access-10 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ radext mailing list radext@ietf.org https://www.ietf.org/mailman/listinfo/radext From jouni.nospam@gmail.com Tue Jul 17 03:40:22 2012 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 C8A6F21F861A for ; Tue, 17 Jul 2012 03:40:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.158 X-Spam-Level: X-Spam-Status: No, score=-3.158 tagged_above=-999 required=5 tests=[AWL=0.441, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6-Liox2uOdhY for ; Tue, 17 Jul 2012 03:40:22 -0700 (PDT) Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id 25E8621F8675 for ; Tue, 17 Jul 2012 03:40:22 -0700 (PDT) Received: by pbcwy7 with SMTP id wy7so655147pbc.31 for ; Tue, 17 Jul 2012 03:41:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=ilIm66xYgMHITbhSunrcC64bsqNRmw6noi6m5Od8n9Q=; b=NcniaatzWQoPt523Z4+3MvbrJEkdqNyGMdM0XXb7tkGaCKcYz/Tqrl+onX8PsxedbN gGdCNH6Ceof/xb1pgCBlXqZbRxNo/kIB1WibMKRaI9y0bY1W5rq/3CduEiXe2YAu1j0p Ft0yXGjD/xttT6Mzr4J/pslmEBT9wne3Gj1wAJ8Bw1SRN6jB6U+wpNI0rE7P/07pLGzD mixBvmiIdNmRD2KsVVLpXYnl4wysZheWNLYrWp66bwLyzYEz+c9kR2TpSaLgthh7rr+1 q/DGkRPI4+w0kS3n39EIyVLgS/u02ivyMFQupOLPnkNnGqNFbLQ0fgQ3XlKjvPLMVIGU d+5g== Received: by 10.68.194.169 with SMTP id hx9mr5581046pbc.8.1342521669315; Tue, 17 Jul 2012 03:41:09 -0700 (PDT) Received: from [10.255.129.242] ([194.251.119.201]) by mx.google.com with ESMTPS id wf7sm13818236pbc.34.2012.07.17.03.41.04 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 17 Jul 2012 03:41:07 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=iso-8859-1 From: jouni korhonen In-Reply-To: Date: Tue, 17 Jul 2012 13:41:01 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <704CF98B-CCF2-4D09-AD1C-4FCCD090E25D@gmail.com> References: To: Wojciech Dec (wdec) X-Mailer: Apple Mail (2.1084) Cc: "radext@ietf.org" , Maglione Roberta , Ullio Mario Subject: Re: [radext] Question about draft-ietf-radext-ipv6-access-08.txt X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 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, 17 Jul 2012 10:40:22 -0000 Thanks Woj. - JOuni On Jul 16, 2012, at 5:55 PM, Wojciech Dec (wdec) wrote: > Hmm, I ran a script to remove any seemingly unused references... 4818 > seems to have also been axed... Version 11 coming. >=20 > -Woj.. >=20 > On 16/07/2012 16:27, "jouni korhonen" wrote: >=20 >>=20 >> Thanks for doing the update. I noticed that between the update from = -07 >> to -08 >> the reference for RFC3162 got dropped from the references listing >> (Section 8.2). >>=20 >> - Jouni >>=20 >>=20 >> On Jun 28, 2012, at 4:58 PM, Wojciech Dec (wdec) wrote: >>=20 >>> Hi Roberta, >>>=20 >>> Uhm... Sloppy fingers. Version -09 on its way >>>=20 >>> -Woj.. >>>=20 >>> On 28/06/2012 15:43, "Maglione Roberta" >>> wrote: >>>=20 >>>> Hello, >>>> I have a question regarding section 3.6: >>>> Why in version -08 the attributes Delegated-IPv6-Prefix-Pool and >>>> Stateful-IPv6-Address-Pool are not allowed any more in Accounting >>>> messages? >>>> They were there in previous versions, in addition Framed-IPv6-Pool >>>> defined in RFC 3162, is allowed in Accounting message. >>>> Could you please clarify the reasons behind this change? >>>> Thanks >>>> Regards, >>>> Roberta >>>>=20 >>>>=20 >>>> -----Original Message----- >>>> From: radext-bounces@ietf.org [mailto:radext-bounces@ietf.org] On >>>> Behalf >>>> Of internet-drafts@ietf.org >>>> Sent: mercoled=EC 27 giugno 2012 20.19 >>>> To: i-d-announce@ietf.org >>>> Cc: radext@ietf.org >>>> Subject: [radext] I-D Action: draft-ietf-radext-ipv6-access-08.txt >>>>=20 >>>>=20 >>>> 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. >>>>=20 >>>> Title : RADIUS attributes for IPv6 Access Networks >>>> Author(s) : Wojciech Dec >>>> Behcet Sarikaya >>>> Glen Zorn >>>> David Miles >>>> Benoit Lourdelet >>>> Filename : draft-ietf-radext-ipv6-access-08.txt >>>> Pages : 14 >>>> Date : 2012-06-27 >>>>=20 >>>> Abstract: >>>> This document specifies additional IPv6 RADIUS attributes useful in >>>> residential broadband network deployments. The attributes, which = are >>>> used for authorization and accounting, enable assignment of a host >>>> IPv6 address and IPv6 DNS server address via DHCPv6; assignment of = an >>>> IPv6 route announced via router advertisement; assignment of a = named >>>> IPv6 delegated prefix pool; and assignment of a named IPv6 pool for >>>> host DHCPv6 addressing. >>>>=20 >>>>=20 >>>>=20 >>>> The IETF datatracker status page for this draft is: >>>> https://datatracker.ietf.org/doc/draft-ietf-radext-ipv6-access >>>>=20 >>>> There's also a htmlized version available at: >>>> http://tools.ietf.org/html/draft-ietf-radext-ipv6-access-08 >>>>=20 >>>> A diff from previous version is available at: >>>> http://tools.ietf.org/rfcdiff?url2=3Ddraft-ietf-radext-ipv6-access-08= >>>>=20 >>>>=20 >>>> Internet-Drafts are also available by anonymous FTP at: >>>> ftp://ftp.ietf.org/internet-drafts/ >>>>=20 >>>> _______________________________________________ >>>> radext mailing list >>>> radext@ietf.org >>>> https://www.ietf.org/mailman/listinfo/radext >>>>=20 >>>> Questo messaggio e i suoi allegati sono indirizzati esclusivamente = alle >>>> persone indicate. La diffusione, copia o qualsiasi altra azione >>>> derivante >>>> dalla conoscenza di queste informazioni sono rigorosamente vietate. >>>> Qualora abbiate ricevuto questo documento per errore siete = cortesemente >>>> pregati di darne immediata comunicazione al mittente e di = provvedere >>>> alla >>>> sua distruzione, Grazie. >>>>=20 >>>> This e-mail and any attachments is confidential and may contain >>>> privileged information intended for the addressee(s) only. >>>> Dissemination, >>>> copying, printing or use by anybody else is unauthorised. If you = are >>>> not >>>> the intended recipient, please delete this message and any = attachments >>>> and advise the sender by return e-mail, Thanks. >>>>=20 >>>=20 >>> _______________________________________________ >>> radext mailing list >>> radext@ietf.org >>> https://www.ietf.org/mailman/listinfo/radext >>=20 >=20 From radext-bounces@ietf.org Tue Jul 17 03:40:25 2012 Return-Path: X-Original-To: radext-archive-IeZ9sae2@lists.ietf.org Delivered-To: ietfarch-radext-archive-IeZ9sae2@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0693821F8675; Tue, 17 Jul 2012 03:40:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1342521625; bh=f+/7QNn3VnsbhTqx+xH25gHTrwnHpMFGE9QbGZ6G7Mw=; h=Mime-Version:From:In-Reply-To:Date:Message-Id:References:To:Cc: Subject:List-Id:List-Unsubscribe:List-Archive:List-Post:List-Help: List-Subscribe:Content-Type:Content-Transfer-Encoding:Sender; b=QVFDAQF/wtNd/EgwJ5ZuRJWzvUU1iemk3obNnl4NmEvDCRZ94asWl1218hOFJFMv8 hJ4rwdk1eGvielRZTK5W+JZ2iuPcJsjQYPSdEx6tJXH69PJRUrFM1CG8Ns1jqiVZdx 3EpVZDkMMQ3+Coh5MJ3pdAFmxd1VeyOpw4CnUYgI= 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 C8A6F21F861A for ; Tue, 17 Jul 2012 03:40:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.158 X-Spam-Level: X-Spam-Status: No, score=-3.158 tagged_above=-999 required=5 tests=[AWL=0.441, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6-Liox2uOdhY for ; Tue, 17 Jul 2012 03:40:22 -0700 (PDT) Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id 25E8621F8675 for ; Tue, 17 Jul 2012 03:40:22 -0700 (PDT) Received: by pbcwy7 with SMTP id wy7so655147pbc.31 for ; Tue, 17 Jul 2012 03:41:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=ilIm66xYgMHITbhSunrcC64bsqNRmw6noi6m5Od8n9Q=; b=NcniaatzWQoPt523Z4+3MvbrJEkdqNyGMdM0XXb7tkGaCKcYz/Tqrl+onX8PsxedbN gGdCNH6Ceof/xb1pgCBlXqZbRxNo/kIB1WibMKRaI9y0bY1W5rq/3CduEiXe2YAu1j0p Ft0yXGjD/xttT6Mzr4J/pslmEBT9wne3Gj1wAJ8Bw1SRN6jB6U+wpNI0rE7P/07pLGzD mixBvmiIdNmRD2KsVVLpXYnl4wysZheWNLYrWp66bwLyzYEz+c9kR2TpSaLgthh7rr+1 q/DGkRPI4+w0kS3n39EIyVLgS/u02ivyMFQupOLPnkNnGqNFbLQ0fgQ3XlKjvPLMVIGU d+5g== Received: by 10.68.194.169 with SMTP id hx9mr5581046pbc.8.1342521669315; Tue, 17 Jul 2012 03:41:09 -0700 (PDT) Received: from [10.255.129.242] ([194.251.119.201]) by mx.google.com with ESMTPS id wf7sm13818236pbc.34.2012.07.17.03.41.04 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 17 Jul 2012 03:41:07 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1084) From: jouni korhonen In-Reply-To: Date: Tue, 17 Jul 2012 13:41:01 +0300 Message-Id: <704CF98B-CCF2-4D09-AD1C-4FCCD090E25D@gmail.com> References: To: Wojciech Dec (wdec) X-Mailer: Apple Mail (2.1084) Cc: "radext@ietf.org" , Maglione Roberta , Ullio Mario Subject: Re: [radext] Question about draft-ietf-radext-ipv6-access-08.txt X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: radext-bounces@ietf.org Errors-To: radext-bounces@ietf.org Thanks Woj. - JOuni On Jul 16, 2012, at 5:55 PM, Wojciech Dec (wdec) wrote: > Hmm, I ran a script to remove any seemingly unused references... 4818 > seems to have also been axed... Version 11 coming. > = > -Woj.. > = > On 16/07/2012 16:27, "jouni korhonen" wrote: > = >> = >> Thanks for doing the update. I noticed that between the update from -07 >> to -08 >> the reference for RFC3162 got dropped from the references listing >> (Section 8.2). >> = >> - Jouni >> = >> = >> On Jun 28, 2012, at 4:58 PM, Wojciech Dec (wdec) wrote: >> = >>> Hi Roberta, >>> = >>> Uhm... Sloppy fingers. Version -09 on its way >>> = >>> -Woj.. >>> = >>> On 28/06/2012 15:43, "Maglione Roberta" >>> wrote: >>> = >>>> Hello, >>>> I have a question regarding section 3.6: >>>> Why in version -08 the attributes Delegated-IPv6-Prefix-Pool and >>>> Stateful-IPv6-Address-Pool are not allowed any more in Accounting >>>> messages? >>>> They were there in previous versions, in addition Framed-IPv6-Pool >>>> defined in RFC 3162, is allowed in Accounting message. >>>> Could you please clarify the reasons behind this change? >>>> Thanks >>>> Regards, >>>> Roberta >>>> = >>>> = >>>> -----Original Message----- >>>> From: radext-bounces@ietf.org [mailto:radext-bounces@ietf.org] On >>>> Behalf >>>> Of internet-drafts@ietf.org >>>> Sent: mercoled=EC 27 giugno 2012 20.19 >>>> To: i-d-announce@ietf.org >>>> Cc: radext@ietf.org >>>> Subject: [radext] I-D Action: draft-ietf-radext-ipv6-access-08.txt >>>> = >>>> = >>>> 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 : RADIUS attributes for IPv6 Access Networks >>>> Author(s) : Wojciech Dec >>>> Behcet Sarikaya >>>> Glen Zorn >>>> David Miles >>>> Benoit Lourdelet >>>> Filename : draft-ietf-radext-ipv6-access-08.txt >>>> Pages : 14 >>>> Date : 2012-06-27 >>>> = >>>> Abstract: >>>> This document specifies additional IPv6 RADIUS attributes useful in >>>> residential broadband network deployments. The attributes, which are >>>> used for authorization and accounting, enable assignment of a host >>>> IPv6 address and IPv6 DNS server address via DHCPv6; assignment of an >>>> IPv6 route announced via router advertisement; assignment of a named >>>> IPv6 delegated prefix pool; and assignment of a named IPv6 pool for >>>> host DHCPv6 addressing. >>>> = >>>> = >>>> = >>>> The IETF datatracker status page for this draft is: >>>> https://datatracker.ietf.org/doc/draft-ietf-radext-ipv6-access >>>> = >>>> There's also a htmlized version available at: >>>> http://tools.ietf.org/html/draft-ietf-radext-ipv6-access-08 >>>> = >>>> A diff from previous version is available at: >>>> http://tools.ietf.org/rfcdiff?url2=3Ddraft-ietf-radext-ipv6-access-08 >>>> = >>>> = >>>> Internet-Drafts are also available by anonymous FTP at: >>>> ftp://ftp.ietf.org/internet-drafts/ >>>> = >>>> _______________________________________________ >>>> radext mailing list >>>> radext@ietf.org >>>> https://www.ietf.org/mailman/listinfo/radext >>>> = >>>> Questo messaggio e i suoi allegati sono indirizzati esclusivamente alle >>>> persone indicate. La diffusione, copia o qualsiasi altra azione >>>> derivante >>>> dalla conoscenza di queste informazioni sono rigorosamente vietate. >>>> Qualora abbiate ricevuto questo documento per errore siete cortesemente >>>> pregati di darne immediata comunicazione al mittente e di provvedere >>>> alla >>>> sua distruzione, Grazie. >>>> = >>>> This e-mail and any attachments is confidential and may contain >>>> privileged information intended for the addressee(s) only. >>>> Dissemination, >>>> copying, printing or use by anybody else is unauthorised. If you are >>>> not >>>> the intended recipient, please delete this message and any attachments >>>> and advise the sender by return e-mail, Thanks. >>>> = >>> = >>> _______________________________________________ >>> radext mailing list >>> radext@ietf.org >>> https://www.ietf.org/mailman/listinfo/radext >> = > = _______________________________________________ radext mailing list radext@ietf.org https://www.ietf.org/mailman/listinfo/radext From mauricio.sanchez@hp.com Tue Jul 24 10:06:27 2012 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 A319621F84F4 for ; Tue, 24 Jul 2012 10:06:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kiUWganQaw6o for ; Tue, 24 Jul 2012 10:06:26 -0700 (PDT) Received: from g4t0014.houston.hp.com (g4t0014.houston.hp.com [15.201.24.17]) by ietfa.amsl.com (Postfix) with ESMTP id C474F21F850B for ; Tue, 24 Jul 2012 10:06:26 -0700 (PDT) Received: from G5W2206G.americas.hpqcorp.net (g5w2206g.atlanta.hp.com [16.228.43.185]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by g4t0014.houston.hp.com (Postfix) with ESMTPS id 38CCE24702 for ; Tue, 24 Jul 2012 17:06:26 +0000 (UTC) Received: from G5W4705G.americas.hpqcorp.net (16.201.136.244) by G5W2206G.americas.hpqcorp.net (16.228.43.185) with Microsoft SMTP Server (TLS) id 14.2.283.4; Tue, 24 Jul 2012 17:05:19 +0000 Received: from G6W2500.americas.hpqcorp.net ([169.254.12.98]) by G5W4705G.americas.hpqcorp.net ([16.201.136.244]) with mapi id 14.02.0283.003; Tue, 24 Jul 2012 17:05:19 +0000 From: "Sanchez, Mauricio (HP Networking)" To: "radext@ietf.org" Thread-Topic: IETF 84: Preliminary Agenda Thread-Index: AQHNab6A95CQY9SUUEyjle6CZVouIg== Date: Tue, 24 Jul 2012 17:05:18 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.3.120616 x-originating-ip: [15.193.49.29] Content-Type: text/plain; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [radext] IETF 84: Preliminary Agenda X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 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, 24 Jul 2012 17:06:27 -0000 At IETF 84 RADEXT has a slightly more than 2 hour time slot allocated (Frid= ay 8/3 11:20AM-1:30PM =96 They have saved the best for last). Below is the= draft agenda consisting of items the chairs would believe would be useful = to discuss. Please respond with any suggested changes or comments. Regards, MS ------------- RADEXT WG IETF 84 Agenda Chairs: Jouni Korhonen Mauricio Sanchez Jabber room: radext at jabber.ietf.org (Please join) Friday, August 3, 2012 11:20AM-1:30PM Room Regency C 11:20 - 11:30 AM, Preliminaries (10 minutes) Audio/Video & Remote Presentation Debugging Note Well Note Takers Jabber scribe Agenda bash Document Status Draft discussion (75 minutes) 11:30 - 11:45 AM RADIUS Protocol Extensions, Alan DeKok (15 minutes) http://tools.ietf.org/html/draft-ietf-radext-radius-extensions 11:45AM-12:00PM DTLS as a Transport Layer for RADIUS, Alan DeKok (15 minute= s) http://tools.ietf.org/id/draft-ietf-radext-dtls 12:00 - 12:15PM NAI-based Dynamic Discovery for RADIUS/TLS and RADIUS/TLS, = Stefan Winter (15 minutes) http://tools.ietf.org/html/draft-ietf-radext-dynamic-discovery 12:15 - 12:30PM RADIUS Accounting for traffic classes, Stefan Winter (15 mi= nutes) http://tools.ietf.org/id/draft-winter-radext-fancyaccounting 12:30 - 12:45 AM RADIUS Accounting Extensions of Traffic Statistics, Leaf Y= eh (15 minutes) http://tools.ietf.org/html/draft-yeh-radext-ext-traffic-statistics 12:45 - 1:00 AM Support of fragmentation of RADIUS packets (15 minutes) http://tools.ietf.org/html/draft-perez-radext-radius-fragmentation 1:00 - 1:15 PM RADIUS Attributes for IEEE 802 Networks, Bernard Aboba (15 m= inutes) http://tools.ietf.org/id/draft-aboba-radext-wlan Wrap-up (15 minutes) 1:15 - 1:30 PM Next Steps: WG Chairs & ADs (15 minutes) WG Goals/Milestones status, next steps From wwwrun@rfc-editor.org Thu Jul 26 06:53:54 2012 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 3997321F876C for ; Thu, 26 Jul 2012 06:53:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.262 X-Spam-Level: X-Spam-Status: No, score=-102.262 tagged_above=-999 required=5 tests=[AWL=0.338, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Qoltns4fJPeg for ; Thu, 26 Jul 2012 06:53:53 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1890:123a::1:2f]) by ietfa.amsl.com (Postfix) with ESMTP id 7B2FF21F875E for ; Thu, 26 Jul 2012 06:53:53 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 127F772E002; Thu, 26 Jul 2012 06:53:38 -0700 (PDT) To: mchiba@cisco.com, gdommety@cisco.com, meklund@cisco.com, david@mitton.com, bernarda@microsoft.com, rbonica@juniper.net, bclaise@cisco.com, jouni.korhonen@nsn.com, mauricio.sanchez@hp.com From: RFC Errata System Message-Id: <20120726135338.127F772E002@rfc-editor.org> Date: Thu, 26 Jul 2012 06:53:38 -0700 (PDT) X-Mailman-Approved-At: Thu, 26 Jul 2012 23:26:40 -0700 Cc: radext@ietf.org, mauricio.sanchez@hp.com, rfc-editor@rfc-editor.org Subject: [radext] [Technical Errata Reported] RFC5176 (3294) X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 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 Jul 2012 13:53:54 -0000 The following errata report has been submitted for RFC5176, "Dynamic Authorization Extensions to Remote Authentication Dial In User Service (RADIUS)". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=5176&eid=3294 -------------------------------------- Type: Technical Reported by: Mauricio Sanchez Section: 3.6 Original Text ------------- Disconnect Messages Request ACK NAK # Attribute 0-1 0 0 1 User-Name (Note 1) 0-1 0 0 4 NAS-IP-Address (Note 1) 0-1 0 0 5 NAS-Port (Note 1) 0 0 0 6 Service-Type 0 0 0 8 Framed-IP-Address (Note 1) Corrected Text -------------- Disconnect Messages Request ACK NAK # Attribute 0-1 0 0 1 User-Name (Note 1) 0-1 0 0 4 NAS-IP-Address (Note 1) 0-1 0 0 5 NAS-Port (Note 1) 0 0 0 6 Service-Type 0-1 0 0 8 Framed-IP-Address (Note 1) Notes ----- Section 3.6 ("Table of Attributes") changed the number of Frame-IP-Address attributes allowed in Disconnect-Message compared to previous RFC3576 (changed from "0-1" to "0"). The table should revert back to its original RFC3576 value in order to maintain backward compatibility with RFC3576. Instructions: ------------- This errata is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party (IESG) can log in to change the status and edit the report, if necessary. -------------------------------------- RFC5176 (draft-ietf-radext-rfc3576bis-13) -------------------------------------- Title : Dynamic Authorization Extensions to Remote Authentication Dial In User Service (RADIUS) Publication Date : January 2008 Author(s) : M. Chiba, G. Dommety, M. Eklund, D. Mitton, B. Aboba Category : INFORMATIONAL Source : RADIUS EXTensions Area : Operations and Management Stream : IETF Verifying Party : IESG From stefan.winter@restena.lu Fri Jul 27 07:51:43 2012 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 2128121F87C7 for ; Fri, 27 Jul 2012 07:51:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XXZ6rlIuNIGR for ; Fri, 27 Jul 2012 07:51:42 -0700 (PDT) Received: from smtprelay.restena.lu (smtprelay.restena.lu [IPv6:2001:a18:1::62]) by ietfa.amsl.com (Postfix) with ESMTP id 7117E21F860B for ; Fri, 27 Jul 2012 07:51:39 -0700 (PDT) Received: from smtprelay.restena.lu (localhost [127.0.0.1]) by smtprelay.restena.lu (Postfix) with ESMTP id 11CC410581 for ; Fri, 27 Jul 2012 16:51:38 +0200 (CEST) Received: from [IPv6:2001:a18:1:8:fdac:6206:22ee:39c] (unknown [IPv6:2001:a18:1:8:fdac:6206:22ee:39c]) by smtprelay.restena.lu (Postfix) with ESMTPS id F349C10580 for ; Fri, 27 Jul 2012 16:51:37 +0200 (CEST) Message-ID: <5012AAF9.2000504@restena.lu> Date: Fri, 27 Jul 2012 16:51:37 +0200 From: Stefan Winter User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:13.0) Gecko/20120601 Thunderbird/13.0 MIME-Version: 1.0 To: radext@ietf.org References: In-Reply-To: X-Enigmail-Version: 1.4.3 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigDF9B08FBA3498E166B44F10F" X-Virus-Scanned: ClamAV Subject: Re: [radext] IETF 84: Preliminary Agenda X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 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, 27 Jul 2012 14:51:43 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigDF9B08FBA3498E166B44F10F Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hi, Just to be sure: I will not attend in person and would need to be impersonated in-a-box. I hope remote attendance facilities are available?= > 12:00 - 12:15PM NAI-based Dynamic Discovery for RADIUS/TLS and RADIUS/T= LS, Stefan Winter (15 minutes) > http://tools.ietf.org/html/draft-ietf-radext-dynamic-discovery Fine. > 12:15 - 12:30PM RADIUS Accounting for traffic classes, Stefan Winter (1= 5 minutes) > http://tools.ietf.org/id/draft-winter-radext-fancyaccounting >=20 > 12:30 - 12:45 AM RADIUS Accounting Extensions of Traffic Statistics, Le= af Yeh (15 minutes) > http://tools.ietf.org/html/draft-yeh-radext-ext-traffic-statistics We can of course discuss each of the drafts individually. However, they are close to each other with only fundamental difference: flexible labels vs. tightly controlled integer enumerators to specify traffic classes. At the last meeting, we concluded that before diving into individual drafts, the WG should have a general discussion which of the two approaches (flexible, i.e. "let people count what they want"; vs. fixed "IPv6 counters, and document action required to count anything else."). I believe it would be more fruitful to converge on the question which of these two approaches to follow, either on the list or in the meeting. Greetings, Stefan Winter > 12:45 - 1:00 AM Support of fragmentation of RADIUS packets (15 minutes)= > http://tools.ietf.org/html/draft-perez-radext-radius-fragmentation >=20 > 1:00 - 1:15 PM RADIUS Attributes for IEEE 802 Networks, Bernard Aboba (= 15 minutes) > http://tools.ietf.org/id/draft-aboba-radext-wlan >=20 > Wrap-up (15 minutes) > 1:15 - 1:30 PM Next Steps: WG Chairs & ADs (15 minutes) > WG Goals/Milestones status, next steps >=20 >=20 > _______________________________________________ > radext mailing list > radext@ietf.org > https://www.ietf.org/mailman/listinfo/radext >=20 --=20 Stefan WINTER Ingenieur de Recherche Fondation RESTENA - R=E9seau T=E9l=E9informatique de l'Education National= e et de la Recherche 6, rue Richard Coudenhove-Kalergi L-1359 Luxembourg Tel: +352 424409 1 Fax: +352 422473 --------------enigDF9B08FBA3498E166B44F10F 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.0.18 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAlASqvkACgkQ+jm90f8eFWbksACeOdi7AExilSyitq6Be7Z0Qx+q 1KEAniowY17FEKOGwceSNctzPx5m1lER =faZJ -----END PGP SIGNATURE----- --------------enigDF9B08FBA3498E166B44F10F-- From leaf.y.yeh@huawei.com Mon Jul 30 04:07:00 2012 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 6729821F8722 for ; Mon, 30 Jul 2012 04:07:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.368 X-Spam-Level: X-Spam-Status: No, score=-6.368 tagged_above=-999 required=5 tests=[AWL=0.231, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v0GErjz1M8Hj for ; Mon, 30 Jul 2012 04:06:59 -0700 (PDT) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id E0B8321F874A for ; Mon, 30 Jul 2012 04:06:58 -0700 (PDT) Received: from 172.18.9.243 (EHLO dfweml202-edg.china.huawei.com) ([172.18.9.243]) by dfwrg02-dlp.huawei.com (MOS 4.2.3-GA FastPath) with ESMTP id AIE85134; Mon, 30 Jul 2012 07:06:58 -0400 (EDT) Received: from DFWEML405-HUB.china.huawei.com (10.193.5.102) by dfweml202-edg.china.huawei.com (172.18.9.108) with Microsoft SMTP Server (TLS) id 14.1.323.3; Mon, 30 Jul 2012 04:05:01 -0700 Received: from SZXEML421-HUB.china.huawei.com (10.82.67.160) by dfweml405-hub.china.huawei.com (10.193.5.102) with Microsoft SMTP Server (TLS) id 14.1.323.3; Mon, 30 Jul 2012 04:05:00 -0700 Received: from SZXEML510-MBS.china.huawei.com ([169.254.8.103]) by szxeml421-hub.china.huawei.com ([10.82.67.160]) with mapi id 14.01.0323.003; Mon, 30 Jul 2012 19:04:55 +0800 From: Leaf yeh To: "radext@ietf.org" Thread-Topic: [radext] IETF 84: Preliminary Agenda Thread-Index: AQHNab6A95CQY9SUUEyjle6CZVouIpc8tQuAgAT1UgA= Date: Mon, 30 Jul 2012 11:04:55 +0000 Message-ID: References: <5012AAF9.2000504@restena.lu> In-Reply-To: <5012AAF9.2000504@restena.lu> Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.66.83.152] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: Re: [radext] IETF 84: Preliminary Agenda X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Jul 2012 11:07:00 -0000 Stefan - At the last meeting, we concluded that before diving into individu= al drafts, the WG should have a general discussion which of the two approac= hes (flexible, i.e. "let people count what they want"; vs. fixed "IPv6 coun= ters, and document action required to count anything else."). I prefer that the attribute design could be based on the solid RFC6158 & dr= aft-ietf(-radext-radius-extensions), which provides the RADIUS design guide= lines.=20 Look forward to that the WG could have a good discussion or comparison betw= een URN (Uniform Resource Names defined in RFC2141 & draft-ietf-urnbis ) wi= th our familiar & traditional type codes.=20 My Qs are: where are the advantages? less work in IETF? Best Regards, Leaf -----Original Message----- From: radext-bounces@ietf.org [mailto:radext-bounces@ietf.org] On Behalf Of= Stefan Winter Sent: Friday, July 27, 2012 10:52 PM To: radext@ietf.org Subject: Re: [radext] IETF 84: Preliminary Agenda Hi, Just to be sure: I will not attend in person and would need to be impersona= ted in-a-box. I hope remote attendance facilities are available? > 12:00 - 12:15PM NAI-based Dynamic Discovery for RADIUS/TLS and=20 > RADIUS/TLS, Stefan Winter (15 minutes)=20 > http://tools.ietf.org/html/draft-ietf-radext-dynamic-discovery Fine. > 12:15 - 12:30PM RADIUS Accounting for traffic classes, Stefan Winter=20 > (15 minutes)=20 > http://tools.ietf.org/id/draft-winter-radext-fancyaccounting >=20 > 12:30 - 12:45 AM RADIUS Accounting Extensions of Traffic Statistics,=20 > Leaf Yeh (15 minutes)=20 > http://tools.ietf.org/html/draft-yeh-radext-ext-traffic-statistics We can of course discuss each of the drafts individually. However, they are= close to each other with only fundamental difference: flexible labels vs. = tightly controlled integer enumerators to specify traffic classes. At the last meeting, we concluded that before diving into individual drafts= , the WG should have a general discussion which of the two approaches (flex= ible, i.e. "let people count what they want"; vs. fixed "IPv6 counters, and document action required to count anything else."). I believe it would be more fruitful to converge on the question which of th= ese two approaches to follow, either on the list or in the meeting. Greetings, Stefan Winter > 12:45 - 1:00 AM Support of fragmentation of RADIUS packets (15=20 > minutes)=20 > http://tools.ietf.org/html/draft-perez-radext-radius-fragmentation >=20 > 1:00 - 1:15 PM RADIUS Attributes for IEEE 802 Networks, Bernard Aboba=20 > (15 minutes) http://tools.ietf.org/id/draft-aboba-radext-wlan >=20 > Wrap-up (15 minutes) > 1:15 - 1:30 PM Next Steps: WG Chairs & ADs (15 minutes) WG=20 > Goals/Milestones status, next steps >=20 >=20 > _______________________________________________ > radext mailing list > radext@ietf.org > https://www.ietf.org/mailman/listinfo/radext >=20 -- Stefan WINTER Ingenieur de Recherche Fondation RESTENA - R=E9seau T=E9l=E9informatique de l'Education Nationale = et de la Recherche 6, rue Richard Coudenhove-Kalergi L-1359 Luxembourg Tel: +352 424409 1 Fax: +352 422473 From roberta.maglione@telecomitalia.it Tue Jul 31 23:21:39 2012 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 CFE6A21F86D4; Tue, 31 Jul 2012 23:21:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.425 X-Spam-Level: * X-Spam-Status: No, score=1.425 tagged_above=-999 required=5 tests=[AWL=-1.059, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5fH7iZ2vytFP; Tue, 31 Jul 2012 23:21:39 -0700 (PDT) Received: from GRFEDG701BA020.telecomitalia.it (grfedg701ba020.telecomitalia.it [156.54.233.200]) by ietfa.amsl.com (Postfix) with ESMTP id 2C78321F86CB; Tue, 31 Jul 2012 23:21:38 -0700 (PDT) Received: from GRFHUB702BA020.griffon.local (10.188.101.112) by GRFEDG701BA020.telecomitalia.it (10.188.45.100) with Microsoft SMTP Server (TLS) id 8.3.245.1; Wed, 1 Aug 2012 08:21:32 +0200 Received: from GRFMBX704BA020.griffon.local ([10.188.101.15]) by GRFHUB702BA020.griffon.local ([10.188.101.112]) with mapi; Wed, 1 Aug 2012 08:21:32 +0200 From: Maglione Roberta To: 'Leaf yeh' , Tassos Chatzithomaoglou Date: Wed, 1 Aug 2012 08:21:31 +0200 Thread-Topic: [dhcwg] I-D Action: draft-ietf-dhc-dhcpv6-radius-opt-01.txt Thread-Index: AQHNbfbnuo3fiIpzMkKxliaPfKNNi5dBHikggACRkICAAOZ4kIAAiG2AgAEgNbCAAECDsA== Message-ID: <282BBE8A501E1F4DA9C775F964BB21FE519702F127@GRFMBX704BA020.griffon.local> References: <20120730015814.6142.26392.idtracker@ietfa.amsl.com> <5016DF55.9040401@forthnetgroup.gr> <5018131B.4090605@forthnetgroup.gr> In-Reply-To: Accept-Language: en-US, it-IT Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, it-IT x-ti-disclaimer: Disclaimer1 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Cc: "dhcwg@ietf.org" , "radext@ietf.org" Subject: Re: [radext] [dhcwg] I-D Action: draft-ietf-dhc-dhcpv6-radius-opt-01.txt X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 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, 01 Aug 2012 06:21:40 -0000 SGVsbG8sDQoNCj4gSSBjb3VsZCBkZWxldGUgRnJhbWVkLVBvb2wgKDg4KSBmcm9tIHRoZSBsaXN0 IGlmIHlvdSBhbGwgYmVsaWV2ZSBpdCBpcw0KPiBvbmx5IGZvciBJUHY0IGFkZHJlc3MgcG9vbC4N Cg0KPiBNYWdsaW9uZSwgeW91ciBvcGluaW9uPw0KDQpJbiBteSBvcGluaW9uIHlvdSBzaG91bGQg cmVtb3ZlIEZyYW1lZC1Qb29sIGJlY2F1c2UgdGhpcyBhdHRyaWJ1dGUgaXMgdXNlZCBmb3IgSVB2 NCBvbmx5IHBvb2wsIHNvIGl0IGRvZXMgbm90IGFwcGx5IGhlcmUuDQoNCkknbSBjYy1pbmcgYWxz byByYWRleHQgbWFpbGluZyBsaXN0Lg0KDQpCZXN0IFJlZ2FyZHMsDQpSb2JlcnRhDQoNCg0KLS0t LS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IExlYWYgeWVoIFttYWlsdG86bGVhZi55Lnll aEBodWF3ZWkuY29tXQ0KU2VudDogbWVyY29sZWSorCAxIGFnb3N0byAyMDEyIDQuNDENClRvOiBU YXNzb3MgQ2hhdHppdGhvbWFvZ2xvdTsgTWFnbGlvbmUgUm9iZXJ0YQ0KQ2M6IGRoY3dnQGlldGYu b3JnDQpTdWJqZWN0OiBSRTogW2RoY3dnXSBJLUQgQWN0aW9uOiBkcmFmdC1pZXRmLWRoYy1kaGNw djYtcmFkaXVzLW9wdC0wMS50eHQNCg0KVGFzc29zIC0gTWF5YmUgeW91IGNvdWxkIHNlcGFyYXRl IHRoZSBhdHRyaWJ1dGVzLCB0byB0aGUgb25lcyBjbGVhcmx5IGRlZmluZWQgZm9yDQpkaGNwIHVz YWdlIChyZXBsaWVzKSBhbmQgdG8gb3RoZXJzIHdoaWNoIGFyZSBkZWZpbmVkIGZvciBwYXNzaW5n IHRvIHRoZQ0KZGhjcCBzZXJ2ZXIgYXMgYSBndWlkYW5jZSBvciBoaW50IG9yIHdoYXRldmVyLg0K DQpJIHByZWZlciBPUFRJT05fUkFESVVTIG9ubHkgY2FycmllZCB0aG9zZSBhdHRyaWJ1dGVzIHRo YXQgc291bmRzIHVzZWZ1bCB0byBESENQdjYgc2VydmVyLCB3aGV0aGVyIGl0IGlzIGhpbnQgb3Ig bm90Lg0KDQoNClRhc3NvcyAtIFJlZ2FyZGluZyB0aGUgcG9vbCBvcHRpb25zLCBpIHdvdWxkIGdp dmUgbGlnaHQgYSBwcmVmZXJlbmNlIHRvDQpTdGF0ZWZ1bC1JUHY2LUFkZHJlc3MtUG9vbCArIERl bGVnYXRlZC1JUHY2LVByZWZpeC1Qb29sLg0KDQpJIGNvdWxkIGRlbGV0ZSBGcmFtZWQtUG9vbCAo ODgpIGZyb20gdGhlIGxpc3QgaWYgeW91IGFsbCBiZWxpZXZlIGl0IGlzIG9ubHkgZm9yIElQdjQg YWRkcmVzcyBwb29sLg0KDQpNYWdsaW9uZSwgeW91ciBvcGluaW9uPw0KDQoNCkJlc3QgUmVnYXJk cywNCkxlYWYNCg0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogVGFzc29zIENo YXR6aXRob21hb2dsb3UgW21haWx0bzphY2hhdHpAZm9ydGhuZXRncm91cC5ncl0NClNlbnQ6IFdl ZG5lc2RheSwgQXVndXN0IDAxLCAyMDEyIDE6MTcgQU0NClRvOiBMZWFmIHllaA0KQ2M6IGRoY3dn QGlldGYub3JnDQpTdWJqZWN0OiBSZTogW2RoY3dnXSBJLUQgQWN0aW9uOiBkcmFmdC1pZXRmLWRo Yy1kaGNwdjYtcmFkaXVzLW9wdC0wMS50eHQNCg0KVGhhbmsgeW91IGZvciB0aGUgZGV0YWlsZWQg YW5zd2VyIExlYWYsDQoNCkkgd2FzIHVuZGVyIHRoZSBpbXByZXNzaW9uIHRoYXQgdGhpcyBkcmFm dCBjb3ZlcmVkIGFsc28gYXR0cmlidXRlcyB0aGF0DQpjb3VsZCBiZSBwYXNzZWQgdG8gdGhlIERI Q1B2NiBzZXJ2ZXIgYXMgYSBoaW50Lg0KU28gaXQgd2Fzbid0IG5lY2Vzc2FyaWx5IGEgc3RyaWN0 IHBhdGggZm9yIHRoZSBESENQdjYgc2VydmVyIHRvIHVzZQ0KdGhlc2UgYXR0cmlidXRlcyB0byB0 aGUgcmVwbGllcyBpdCBzZW5kcyBiYWNrLg0KDQpNYXliZSB5b3UgY291bGQgc2VwYXJhdGUgdGhl IGF0dHJpYnV0ZXMsIHRvIHRoZSBvbmVzIGNsZWFybHkgZGVmaW5lZCBmb3INCmRoY3AgdXNhZ2Ug KHJlcGxpZXMpIGFuZCB0byBvdGhlcnMgd2hpY2ggYXJlIGRlZmluZWQgZm9yIHBhc3NpbmcgdG8g dGhlDQpkaGNwIHNlcnZlciBhcyBhIGd1aWRhbmNlIG9yIGhpbnQgb3Igd2hhdGV2ZXIuDQoNClJl Z2FyZGluZyB0aGUgcG9vbCBvcHRpb25zLCBpIHdvdWxkIGdpdmUgbGlnaHQgYSBwcmVmZXJlbmNl IHRvDQpTdGF0ZWZ1bC1JUHY2LUFkZHJlc3MtUG9vbCArIERlbGVnYXRlZC1JUHY2LVByZWZpeC1Q b29sLg0KDQpUYXNzb3MNCg0KT24gMzAvNy8yMDEyIDg6NDIgpsymzCwgTGVhZiB5ZWggd3JvdGU6 DQo+IFRhc3NvcyAtIElzIHRoZXJlIGFueSBwYXJ0aWN1bGFyIHJlYXNvbiBmb3IgaW5jbHVkaW5n IEZyYW1lZC1Qb29sIGluc3RlYWQgb2YgRnJhbWVkLUlQdjYtUG9vbD8NCj4NCj4gR29vZCBxdWVz dGlvbi4NCj4NCj4gYS4gRnJhbWVkLUlQdjYtUG9vbCBpcyBkZWZpbmVkIGluIHNlY3Rpb24gMi42 IG9mIFJGQzMxNjIgKGh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL3JmYzMxNjIgKSAsIGFuZCAg PHF1b3RlPlRoaXMgQXR0cmlidXRlIGNvbnRhaW5zIHRoZSBuYW1lIG9mIGFuIGFzc2lnbmVkIHBv b2wgdGhhdCBTSE9VTEQgYmUgdXNlZCB0byBhc3NpZ24gYW4gSVB2NiBwcmVmaXggZm9yIHRoZSB1 c2VyLjwvcXVvdGU+ICBSRkMzMTYyIHdhcyBwdWJsaXNoZWQgaW4gMjAwMSwgYXQgdGhhdCB0aW1l LCB3ZSBkb24ndCBoYXZlIERIQ1B2NiAoUkZDMzMxNSkgcHVibGlzaGVkIGluIDIwMDMuIFNvIEkg Z3Vlc3MgRnJhbWVkLUlQdjYtUG9vbCBpcyBkZXNpZ25lZCBmb3IgU0xBQUMgKFN0YXRlbGVzcyBB ZGRyZXNzIEF1dG9jb25maWd1cmF0aW9uKS4gQnV0IHdlIG5lZWQgc29tZXRoaW5nIGZvciBESENQ djYuDQo+DQo+IGIuIFdoZW4gd2UgbG9vayBpbnRvIHRoZSBkZWZpbml0aW9uIG9mIEZyYW1lZC1Q b29sICg4OCksIHRoZSBmb3JtYXQgb2YgaXQgaXMgZXhhY3RseSB0aGUgc2FtZSBhcyBGcmFtZWQt SVB2Ni1Qb29sICgxMDApLiBUaGUgY29udGVudCBvZiB0aGVzZSAyIGF0dHJpYnV0ZXMgYXJlIHRo ZSBuYW1lIG9mIHBvb2wgaW4gc3RyaW5nLiBJIHN1cHBvc2UgaXQgd2lsbCBiZSBmaW5lIGZvciB0 aGUgdXNhZ2Ugd2hldGhlciBpdCBpcyBJUHY0IHBvb2wgb3IgSVB2NiBwb29sLCBvciB3aGV0aGVy IGl0IGlzIGFkZHJlc3MgcG9vbCBuYW1lIG9yIHByZWZpeCBwb29sIG5hbWUuIEFncmVlPw0KPg0K PiBjLiBXaGVuIHdlIHJlYWQgc2VjdGlvbiAyLjQgb2YgZHJhZnQtaWV0Zi1yYWRleHQtaXB2Ni1h Y2Nlc3MgKGh0dHA6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi1yYWRleHQt aXB2Ni1hY2Nlc3MvP2luY2x1ZGVfdGV4dD0xICksIDxxdW90ZT5UbyBhdm9pZCBhbWJpZ3VpdHkg aW4gdGhpcyBzY2VuYXJpbywgdXNlIG9mIHRoZSBEZWxlZ2F0ZWQtSVB2Ni1QcmVmaXgtUG9vbCBh dHRyaWJ1dGUgc2hvdWxkIGJlIHJlc3RyaWN0ZWQgdG8gYXV0aG9yaXphdGlvbiBhbmQgIGFjY291 bnRpbmcgb2YgcHJlZml4IHBvb2xzIHVzZWQgaW4gREhDUHY2IFByZWZpeCBEZWxlZ2F0aW9uIGFu ZCB0aGUgRnJhbWVkLUlQdjYtUG9vbCBhdHRyaWJ1dGUgc2hvdWxkIGJlIHVzZWQgZm9yIGF1dGhv cml6YXRpb24gYW5kIGFjY291bnRpbmcgb2YgcHJlZml4IHBvb2xzIHVzZWQgaW4gU0xBQUMuIDwv cXVvdGU+LiBTbyBpdCBpcyBhbHNvIG5vdCByZWNvbW1lbmRlZCB0byB1c2UgRnJhbWVkLUlQdjYt UG9vbCAoMTAwKSBmb3IgREhDUHY2Lg0KPg0KPiBkLiBUaGUgYWx0ZXJuYXRpdmUgb3B0aW9ucyBm b3IgREhDUHY2IGFkZHJlc3MvIHByZWZpeCBwb29sIG1pZ2h0IGJlIDogMS4gRnJhbWVkLVBvb2wg KDg4KTsgMi4gU3RhdGVmdWwtSVB2Ni1BZGRyZXNzLVBvb2wgKyBEZWxlZ2F0ZWQtSVB2Ni1QcmVm aXgtUG9vbCBkZWZpbmVkIGluIGRyYWZ0LWlldGYtcmFkZXh0LWlwdjYtYWNjZXNzLiBXaGljaCBv bmUgZG8geW91IHByZWZlciBpbiB5b3VyIGltcGxlbWVudGF0aW9uIG9yIHN1Z2dlc3Rpb24/IE9y IHdvdWxkIHlvdSBsaWtlIGJvdGggb2YgdGhlbT8NCj4NCj4gVGFzc29zIC0gV2hhdCBhYm91dCBG cmFtZWQtSVB2Ni1QcmVmaXg/DQo+DQo+IEFnYWluLiBGcmFtZWQtSVB2Ni1QcmVmaXgoOTcpIGlz IGRlc2lnbiBmb3IgU0xBQUMsIG5vdCBmb3IgREhDUHY2LiBQbHMuIHJlZmVyIHRvIHNlY3Rpb24g Mi4yIG9mIGRyYWZ0LWlldGYtcmFkZXh0LWlwdjYtYWNjZXNzICwgPHF1b3RlPlRvIGF2b2lkIGFt YmlndWl0eSwgdGhlIEZyYW1lZC1JUHY2LUFkZHJlc3MgYXR0cmlidXRlIGlzIG9ubHkgdXNlZCBm b3IgYXV0aG9yaXphdGlvbiBhbmQgYWNjb3VudGluZyBvZiBESENQdjYtYXNzaWduZWQgYWRkcmVz c2VzIGFuZCB0aGUgRnJhbWVkLUlQdjYtUHJlZml4IGFuZCBGcmFtZWQtSW50ZXJmYWNlLUlkIGF0 dHJpYnV0ZXMgYXJlIHVzZWQgZm9yIGF1dGhvcml6YXRpb24gYW5kIGFjY291bnRpbmcgb2YgYWRk cmVzc2VzIGFzc2lnbmVkIHZpYSBTTEFBQy4gPC9xdW90ZT4NCj4NCj4gVGFzc29zIC0gR2VuZXJh bGx5LCB3aGF0J3MgdGhlIGNyaXRlcmlhIGZvciBjaG9vc2luZyB3aGljaCBhdHRyaWJ1dGVzIHRv IGluY2x1ZGU/DQo+DQo+IFRoZSBvcmlnaW5hbCB0aG91Z2ggd2FzIHRvIGRlc2lnbiBPUFRJT05f UkFESVVTIHRvIGNvbnZleSB0aGUgQUFBLWF1dGhvcml6ZWQgcG9vbC9hZGRyZXNzL3ByZWZpeCBm b3IgdGhlIHJpZ2h0IHNlbGVjdGlvbiBvZiB0aGUgY29uZmlndXJhdGlvbiBwYXJhbWV0ZXIgYXQg REhDUHY2IHNlcnZlciwgYnV0ICBJIHN1cHBvc2UgZWFjaCBvZiB0aGUgYXR0cmlidXRlcywgd2hp Y2ggaXMgYXNzb2NpYXRlZCB3aXRoIElQdjYgYW5kIG1pZ2h0IGJlIHVzZWQgYnkgREhDUHY2IHNl cnZlciwgY291bGQgYmUgdGhlIGNhbmRpZGF0ZS4gQnV0IEkgZ3Vlc3Mgd2Ugd2lsbCBub3QgcmV1 c2UgdGhlIGFuYWx5c2lzIGluIFJGQzM1ODAgaGVyZSwgd2hpY2ggaXMgb25seSBkZXNpZ25lZCBm b3IgSUVFRSA4MDIuMXguIFRoZSBzY2VuYXJpb3MgbWVudGlvbmVkIGluIHRoaXMgZHJhZnQgYXJl IGZvY3VzZWQgb24gdGhlIGJyb2FkYmFuZCBhY2Nlc3MsIGluY2x1ZGluZyBJUG9FIGFuZCBQUFBv RS4gQWdyZWU/DQo+DQo+DQo+IEJlc3QgUmVnYXJkcywNCj4gTGVhZg0KPg0KPg0KPg0KPiBGcm9t OiBUYXNzb3MgQ2hhdHppdGhvbWFvZ2xvdSBbbWFpbHRvOmFjaGF0ekBmb3J0aG5ldGdyb3VwLmdy XQ0KPiBTZW50OiBUdWVzZGF5LCBKdWx5IDMxLCAyMDEyIDM6MjQgQU0NCj4gVG86IExlYWYgeWVo DQo+IENjOiBkaGN3Z0BpZXRmLm9yZw0KPiBTdWJqZWN0OiBSZTogW2RoY3dnXSBJLUQgQWN0aW9u OiBkcmFmdC1pZXRmLWRoYy1kaGNwdjYtcmFkaXVzLW9wdC0wMS50eHQNCj4NCj4gSnVzdCB0d28g cXVlc3Rpb25zIGFmdGVyIGEgcXVpY2sgcmVhZGluZy4uLg0KPg0KPiBJcyB0aGVyZSBhbnkgcGFy dGljdWxhciByZWFzb24gZm9yIGluY2x1ZGluZyBGcmFtZWQtUG9vbCBpbnN0ZWFkIG9mIEZyYW1l ZC1JUHY2LVBvb2w/DQo+IFdoYXQgYWJvdXQgRnJhbWVkLUlQdjYtUHJlZml4Pw0KPiBHZW5lcmFs bHksIHdoYXQncyB0aGUgY3JpdGVyaWEgZm9yIGNob29zaW5nIHdoaWNoIGF0dHJpYnV0ZXMgdG8g aW5jbHVkZT8NCj4NCj4gWW91ciBkcmFmdCBzdGF0ZXM6DQo+DQo+DQo+ICAgICBUaGUgb3B0aW9u LWRhdGEgb2YgT1BUSU9OX1JBRElVUyBpcyBvbmUgb3IgYSBsaXN0IG9mIFJBRElVUw0KPiAgICAg YXR0cmlidXRlcyByZWNlaXZlZCBpbiB0aGUgQWNjZXNzLUFjY2VwdCBtZXNzYWdlIGZyb20gdGhl IFJBRElVUw0KPiAgICAgc2VydmVyLiAgQXMgdGhlIHNhbWUgbWV0aG9kIGluIFtSRkM0MDE0XSwg b25seSB0aGUgYXR0cmlidXRlcyBsaXN0ZWQNCj4gICAgIGluIHRoZSB0YWJsZSBiZWxvdyBtYXkg YmUgaW5jbHVkZWQgaW4gdGhlIE9QVElPTl9SQURJVVMuDQo+DQo+IFJGQyA0MDE0IHN0YXRlczoN Cj4NCj4NCj4gICAgIFRvIGF2b2lkIGRlcGVuZGVuY2llcyBiZXR3ZWVuIHRoZSBhZGRyZXNzIGFs bG9jYXRpb24gYW5kIG90aGVyIHN0YXRlDQo+ICAgICBpbmZvcm1hdGlvbiBiZXR3ZWVuIHRoZSBS QURJVVMgc2VydmVyIGFuZCB0aGUgREhDUCBzZXJ2ZXIsIHRoZSBESENQDQo+ICAgICByZWxheSBh Z2VudCBTSE9VTEQgaW5jbHVkZSBvbmx5IHRoZSBhdHRyaWJ1dGVzIGluIHRoZSB0YWJsZSBiZWxv dyBpbg0KPiAgICAgYW4gaW5zdGFuY2Ugb2YgdGhlIFJBRElVUyBBdHRyaWJ1dGVzIHN1Ym9wdGlv bi4gIFRoZSB0YWJsZSwgYmFzZWQgb24NCj4gICAgIHRoZSBhbmFseXNpcyBpbiBSRkMgMzU4MCBb OF0sIGxpc3RzIGF0dHJpYnV0ZXMgdGhhdCBNQVkgYmUgaW5jbHVkZWQ6DQo+DQo+DQo+IEknbSB0 cnlpbmcgdG8gdW5kZXJzdGFuZCBpZiBSRkMgNDAxNCByZWZlcnMgdG8gREhDUHY0IG9ubHkgYW5k IGlmIHlvdXIgZHJhZnQgcmVmZXJzIHRvIERIQ1B2NiBvbmx5LCBhbmQgaWYgeWVzLCB3aHkgYSBE SENQdjQgc2VydmVyIHNob3VsZCBrbm93IGFib3V0IGFuIElQdjYgYXR0cmlidXRlIGFuZCB2aWNl IHZlcnNhLg0KPg0KPg0KPiAtLQ0KPiBUYXNzb3MNCj4gT24gMjkvNy8yMDEyIDg6MDIgpsymzCwg TGVhZiB5ZWggd3JvdGU6DQo+IERlYXIgREhDIGZvbGtzLA0KPg0KPiBUaGUgZHJhZnQtaWV0ZiAo dmVyLi0wMSkgJiB0aGUgcHJvcG9zZWQgKE9QVElPTl9SQURJVVMpIG9uIHRoZSBhZ2VuZGEgb2Yg SUVURjg0IERIQyBzZXNzaW9uLCBpcyB3YWl0aW5nIGZvciB5b3VyIHJldmlldyBhbmQgY29tbWVu dHMuDQo+DQo+DQo+IEJlc3QgUmVnYXJkcywNCj4gTGVhZg0KPg0KPiBQUy4gKGh0dHBzOi8vZGF0 YXRyYWNrZXIuaWV0Zi5vcmcvbWVldGluZy84NC9hZ2VuZGEvZGhjLyApDQo+DQo+DQo+IC0tLS0t T3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+IEZyb206IGRoY3dnLWJvdW5jZXNAaWV0Zi5vcmcgW21h aWx0bzpkaGN3Zy1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgaW50ZXJuZXQtZHJhZnRz QGlldGYub3JnDQo+IFNlbnQ6IE1vbmRheSwgSnVseSAzMCwgMjAxMiA5OjU4IEFNDQo+IFRvOiBp LWQtYW5ub3VuY2VAaWV0Zi5vcmcNCj4gQ2M6IGRoY3dnQGlldGYub3JnDQo+IFN1YmplY3Q6IFtk aGN3Z10gSS1EIEFjdGlvbjogZHJhZnQtaWV0Zi1kaGMtZGhjcHY2LXJhZGl1cy1vcHQtMDEudHh0 DQo+DQo+DQo+IEEgTmV3IEludGVybmV0LURyYWZ0IGlzIGF2YWlsYWJsZSBmcm9tIHRoZSBvbi1s aW5lIEludGVybmV0LURyYWZ0cyBkaXJlY3Rvcmllcy4NCj4gICBUaGlzIGRyYWZ0IGlzIGEgd29y ayBpdGVtIG9mIHRoZSBEeW5hbWljIEhvc3QgQ29uZmlndXJhdGlvbiBXb3JraW5nIEdyb3VwIG9m IHRoZSBJRVRGLg0KPg0KPiAgICAgICBUaXRsZSAgICAgICAgICAgOiBSQURJVVMgT3B0aW9uIGZv ciBESENQdjYgUmVsYXkgQWdlbnRzIG9uIEJyb2FkYmFuZCBBY2Nlc3MgU2VydmVyDQo+ICAgICAg IEF1dGhvcihzKSAgICAgICA6IExlYWYgWS4gWWVoDQo+ICAgICAgICAgICAgICAgICAgICAgICAg ICAgIE1vaGFtZWQgQm91Y2FkYWlyDQo+ICAgICAgICAgICAgICAgICAgICAgICAgICAgIFRlZCBM ZW1vbg0KPiAgICAgICBGaWxlbmFtZSAgICAgICAgOiBkcmFmdC1pZXRmLWRoYy1kaGNwdjYtcmFk aXVzLW9wdC0wMS50eHQNCj4gICAgICAgUGFnZXMgICAgICAgICAgIDogOQ0KPiAgICAgICBEYXRl ICAgICAgICAgICAgOiAyMDEyLTA3LTI5DQo+DQo+IEFic3RyYWN0Og0KPiAgICAgVGhlIERIQ1B2 NiBSQURJVVMgb3B0aW9uIHByb3ZpZGVzIGEgY29tbXVuaWNhdGlvbiBtZWNoYW5pc20gYmV0d2Vl bg0KPiAgICAgcmVsYXkgYWdlbnQgYW5kIHRoZSBzZXJ2ZXIuICBUaGlzIG1lY2hhbmlzbSBjYW4g aGVscCB0aGUgY2VudHJhbGl6ZWQNCj4gICAgIERIQ1B2NiBzZXJ2ZXIgdG8gc2VsZWN0IHRoZSBy aWdodCBjb25maWd1cmF0aW9uIGZvciB0aGUgY2xpZW50IGJhc2VkDQo+ICAgICBvbiB0aGUgYXV0 aG9yaXphdGlvbiBpbmZvcm1hdGlvbiByZWNlaXZlZCBmcm9tIGEgc2VwYXJhdGUgUkFESVVTDQo+ ICAgICBzZXJ2ZXIgd2hpY2ggaXMgbm90IGxvY2F0ZWQgYXQgdGhlIHNhbWUgcGxhY2Ugb2YgREhD UHY2IHNlcnZlciBpbiB0aGUNCj4gICAgIGNhc2VzIHdoZXJlIHRoZSBOQVMgYWN0cyBhcyBESENQ djYgcmVsYXkgYWdlbnQgYW5kIFJBRElVUyBjbGllbnQNCj4gICAgIHNpbXVsdGFuZW91c2x5Lg0K Pg0KPg0KPiBUaGUgSUVURiBkYXRhdHJhY2tlciBzdGF0dXMgcGFnZSBmb3IgdGhpcyBkcmFmdCBp czoNCj4gaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi1kaGMtZGhj cHY2LXJhZGl1cy1vcHQNCj4NCj4gVGhlcmUncyBhbHNvIGEgaHRtbGl6ZWQgdmVyc2lvbiBhdmFp bGFibGUgYXQ6DQo+IGh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtZGhjLWRo Y3B2Ni1yYWRpdXMtb3B0LTAxDQo+DQo+IEEgZGlmZiBmcm9tIHByZXZpb3VzIHZlcnNpb24gaXMg YXZhaWxhYmxlIGF0Og0KPiBodHRwOi8vdG9vbHMuaWV0Zi5vcmcvcmZjZGlmZj91cmwyPWRyYWZ0 LWlldGYtZGhjLWRoY3B2Ni1yYWRpdXMtb3B0LTAxDQo+DQo+DQo+IEludGVybmV0LURyYWZ0cyBh cmUgYWxzbyBhdmFpbGFibGUgYnkgYW5vbnltb3VzIEZUUCBhdDoNCj4gZnRwOi8vZnRwLmlldGYu b3JnL2ludGVybmV0LWRyYWZ0cy8NCj4NCj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX18NCj4gZGhjd2cgbWFpbGluZyBsaXN0DQo+IGRoY3dnQGlldGYub3Jn DQo+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vZGhjd2cNCj4gX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gZGhjd2cgbWFpbGlu ZyBsaXN0DQo+IGRoY3dnQGlldGYub3JnDQo+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4v bGlzdGluZm8vZGhjd2cNCj4NCj4NCj4NCj4NCg0KDQpRdWVzdG8gbWVzc2FnZ2lvIGUgaSBzdW9p IGFsbGVnYXRpIHNvbm8gaW5kaXJpenphdGkgZXNjbHVzaXZhbWVudGUgYWxsZSBwZXJzb25lIGlu ZGljYXRlLiBMYSBkaWZmdXNpb25lLCBjb3BpYSBvIHF1YWxzaWFzaSBhbHRyYSBhemlvbmUgZGVy aXZhbnRlIGRhbGxhIGNvbm9zY2VuemEgZGkgcXVlc3RlIGluZm9ybWF6aW9uaSBzb25vIHJpZ29y b3NhbWVudGUgdmlldGF0ZS4gUXVhbG9yYSBhYmJpYXRlIHJpY2V2dXRvIHF1ZXN0byBkb2N1bWVu dG8gcGVyIGVycm9yZSBzaWV0ZSBjb3J0ZXNlbWVudGUgcHJlZ2F0aSBkaSBkYXJuZSBpbW1lZGlh dGEgY29tdW5pY2F6aW9uZSBhbCBtaXR0ZW50ZSBlIGRpIHByb3Z2ZWRlcmUgYWxsYSBzdWEgZGlz dHJ1emlvbmUsIEdyYXppZS4NCg0KVGhpcyBlLW1haWwgYW5kIGFueSBhdHRhY2htZW50cyBpcyBj b25maWRlbnRpYWwgYW5kIG1heSBjb250YWluIHByaXZpbGVnZWQgaW5mb3JtYXRpb24gaW50ZW5k ZWQgZm9yIHRoZSBhZGRyZXNzZWUocykgb25seS4gRGlzc2VtaW5hdGlvbiwgY29weWluZywgcHJp bnRpbmcgb3IgdXNlIGJ5IGFueWJvZHkgZWxzZSBpcyB1bmF1dGhvcmlzZWQuIElmIHlvdSBhcmUg bm90IHRoZSBpbnRlbmRlZCByZWNpcGllbnQsIHBsZWFzZSBkZWxldGUgdGhpcyBtZXNzYWdlIGFu ZCBhbnkgYXR0YWNobWVudHMgYW5kIGFkdmlzZSB0aGUgc2VuZGVyIGJ5IHJldHVybiBlLW1haWws IFRoYW5rcy4NCg0K