From gwz@net-zen.net Thu Jul 1 00:10:28 2010 Return-Path: X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D33C33A6887 for ; Thu, 1 Jul 2010 00:10:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.945 X-Spam-Level: X-Spam-Status: No, score=-1.945 tagged_above=-999 required=5 tests=[AWL=0.654, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f8GI8bd+Ccmu for ; Thu, 1 Jul 2010 00:10:27 -0700 (PDT) Received: from p3plsmtpa01-10.prod.phx3.secureserver.net (p3plsmtpa01-10.prod.phx3.secureserver.net [72.167.82.90]) by core3.amsl.com (Postfix) with SMTP id AEB1B3A6835 for ; Thu, 1 Jul 2010 00:10:27 -0700 (PDT) Received: (qmail 13891 invoked from network); 1 Jul 2010 07:10:38 -0000 Received: from unknown (124.157.141.182) by p3plsmtpa01-10.prod.phx3.secureserver.net (72.167.82.90) with ESMTP; 01 Jul 2010 07:10:37 -0000 From: "Glen Zorn" To: "'Romascanu, Dan \(Dan\)'" References: In-Reply-To: Date: Thu, 1 Jul 2010 14:10:29 +0700 Organization: Network Zen Message-ID: <004801cb18ec$7f16a4d0$7d43ee70$@net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcsY1ige+KLIbwB9TGepu7S0z3jI5wAEZT9gAADy7wA= Content-Language: en-us Cc: dime@ietf.org, souheil.benayed@gmail.com Subject: Re: [Dime] FW: [Editorial Errata Reported] RFC4072 (2317) X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Jul 2010 07:10:28 -0000 Dan Romascanu [mailto://dromasca@avaya.com] writes: > Dime WG, > > Please assess this errata report. > > If I understand well then Souheil's observation is that more > Accounting-EAP-Auth-Method AVPs can be included. This seems more like a > Technical errata, which if accepted can create interoperability problems > with existing deployment. Am I correct? I think that your understanding is correct, but the errata makes no sense to me: AFAIK, only one EAP method can be used in authenticating a user (EAP methods cannot be chained) & even if they could (as proposed for the new tunneled EAP method under development in EMU), the structure of the Diameter EAP app mirrors that of EAP (request/response). Two EAP methods cannot be operational simultaneously, so why would two method identifiers need to be in the same Diameter message? > > Thanks and Regards, > > Dan > > -----Original Message----- > From: RFC Errata System [mailto:rfc-editor@rfc-editor.org] > Sent: Thursday, July 01, 2010 7:31 AM > To: pasi.eronen@nokia.com; tomhiller@lucent.com; gwz@cisco.com; > Romascanu, Dan (Dan); rbonica@juniper.net; Bernard_Aboba@hotmail.com; > david@mitton.com; john.loughney@nokia.com > Cc: souheil.benayed@gmail.com; rfc-editor@rfc-editor.org > Subject: [Editorial Errata Reported] RFC4072 (2317) > > > The following errata report has been submitted for RFC4072, "Diameter > Extensible Authentication Protocol (EAP) Application". > > -------------------------------------- > You may review the report below and at: > http://www.rfc-editor.org/errata_search.php?rfc=4072&eid=2317 > > -------------------------------------- > Type: Editorial > Reported by: Souheil Ben Ayed > > Section: 3.2. > > Original Text > ------------- > ::= < Diameter Header: 268, PXY > > > < Session-Id > > > { Auth-Application-Id } > > { Auth-Request-Type } > > { Result-Code } > > { Origin-Host } > > { Origin-Realm } > > [ User-Name ] > > [ EAP-Payload ] > > [ EAP-Reissued-Payload ] > > [ EAP-Master-Session-Key ] > > [ EAP-Key-Name ] > > [ Multi-Round-Time-Out ] > > [ Accounting-EAP-Auth-Method ] > > [ Service-Type ] > > Corrected Text > -------------- > ::= < Diameter Header: 268, PXY > > > < Session-Id > > > { Auth-Application-Id } > > { Auth-Request-Type } > > { Result-Code } > > { Origin-Host } > > { Origin-Realm } > > [ User-Name ] > > [ EAP-Payload ] > > [ EAP-Reissued-Payload ] > > [ EAP-Master-Session-Key ] > > [ EAP-Key-Name ] > > [ Multi-Round-Time-Out ] > > * [ Accounting-EAP-Auth-Method ] > > [ Service-Type ] > > Notes > ----- > When one or more EAP methods used for authenticating the user, for each > used EAP method an Accounting-EAP-Auth-Method AVP is added in the > Diameter-EAP-Answer with a successful result code. In the message format > of Diameter-EAP-Answer, one or more Accounting-EAP-Auth-Method AVPs can > be included. > > 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. > > -------------------------------------- > RFC4072 (draft-ietf-aaa-eap-10) > -------------------------------------- > Title : Diameter Extensible Authentication Protocol (EAP) > Application > Publication Date : August 2005 > Author(s) : P. Eronen, Ed., T. Hiller, G. Zorn > Category : PROPOSED STANDARD > Source : Authentication, Authorization and Accounting > Area : Operations and Management > Stream : IETF > Verifying Party : IESG > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime From souheil@tera.ics.keio.ac.jp Thu Jul 1 02:23:55 2010 Return-Path: X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C44C53A67F7 for ; Thu, 1 Jul 2010 02:23:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.368 X-Spam-Level: * X-Spam-Status: No, score=1.368 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, HTML_MESSAGE=0.001, MIME_HTML_ONLY=1.457] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HtRQ3GJ+Wyr7 for ; Thu, 1 Jul 2010 02:23:54 -0700 (PDT) Received: from maro.tera.ics.keio.ac.jp (maro.tera.ics.keio.ac.jp [131.113.71.3]) by core3.amsl.com (Postfix) with ESMTP id 884133A67E5 for ; Thu, 1 Jul 2010 02:23:54 -0700 (PDT) Received: from [131.113.71.108] (dhcp108.tera.ics.keio.ac.jp [131.113.71.108]) by maro.tera.ics.keio.ac.jp (Postfix) with ESMTPSA id EF9B220F; Thu, 1 Jul 2010 18:24:04 +0900 (JST) Message-ID: <4C2C5EAE.70800@tera.ics.keio.ac.jp> Date: Thu, 01 Jul 2010 18:23:58 +0900 From: Souheil Ben Ayed User-Agent: Thunderbird 2.0.0.24 (X11/20100411) MIME-Version: 1.0 To: Glen Zorn References: <004801cb18ec$7f16a4d0$7d43ee70$@net> In-Reply-To: <004801cb18ec$7f16a4d0$7d43ee70$@net> Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: dime@ietf.org Subject: Re: [Dime] FW: [Editorial Errata Reported] RFC4072 (2317) X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Jul 2010 09:23:55 -0000
Dear all,

Please read the section " 2.7.  Accounting" of the RFC 4072.

In this section, it is described that one or more Accounting-EAP-Auth-Method AVPs may be added in a Diameter-EAP-Answer with a successful result code.

So what is correct ?
- Allow adding one or more Accounting-EAP-Auth-Method AVPs?
- or only one Accounting-EAP-Auth-Method AVP can be included in a Diameter-EAP-Answer?

Souheil Ben Ayed

Glen Zorn wrote: 
Dan Romascanu [mailto://dromasca@avaya.com] writes:

  
Dime WG,

Please assess this errata report.

If I understand well then Souheil's observation is that more
Accounting-EAP-Auth-Method AVPs can be included. This seems more like a
Technical errata, which if accepted can create interoperability problems
with existing deployment. Am I correct?
    

I think that your understanding is correct, but the errata makes no sense to
me: AFAIK, only one EAP method can be used in authenticating a user (EAP
methods cannot be chained) & even if they could (as proposed for the new
tunneled EAP method under development in EMU), the structure of the Diameter
EAP app mirrors that of EAP (request/response).  Two EAP methods cannot be
operational simultaneously, so why would two method identifiers need to be
in the same Diameter message?

  
Thanks and Regards,

Dan

-----Original Message-----
From: RFC Errata System [mailto:rfc-editor@rfc-editor.org]
Sent: Thursday, July 01, 2010 7:31 AM
To: pasi.eronen@nokia.com; tomhiller@lucent.com; gwz@cisco.com;
Romascanu, Dan (Dan); rbonica@juniper.net; Bernard_Aboba@hotmail.com;
david@mitton.com; john.loughney@nokia.com
Cc: souheil.benayed@gmail.com; rfc-editor@rfc-editor.org
Subject: [Editorial Errata Reported] RFC4072 (2317)


The following errata report has been submitted for RFC4072, "Diameter
Extensible Authentication Protocol (EAP) Application".

--------------------------------------
You may review the report below and at:
http://www.rfc-editor.org/errata_search.php?rfc=4072&eid=2317

--------------------------------------
Type: Editorial
Reported by: Souheil Ben Ayed <souheil.benayed@gmail.com>

Section: 3.2.

Original Text
-------------
      <Diameter-EAP-Answer> ::= < Diameter Header: 268, PXY >

                                < Session-Id >

                                { Auth-Application-Id }

                                { Auth-Request-Type }

                                { Result-Code }

                                { Origin-Host }

                                { Origin-Realm }

                                [ User-Name ]

                                [ EAP-Payload ]

                                [ EAP-Reissued-Payload ]

                                [ EAP-Master-Session-Key ]

                                [ EAP-Key-Name ]

                                [ Multi-Round-Time-Out ]

                                [ Accounting-EAP-Auth-Method ]

                                [ Service-Type ]

Corrected Text
--------------
      <Diameter-EAP-Answer> ::= < Diameter Header: 268, PXY >

                                < Session-Id >

                                { Auth-Application-Id }

                                { Auth-Request-Type }

                                { Result-Code }

                                { Origin-Host }

                                { Origin-Realm }

                                [ User-Name ]

                                [ EAP-Payload ]

                                [ EAP-Reissued-Payload ]

                                [ EAP-Master-Session-Key ]

                                [ EAP-Key-Name ]

                                [ Multi-Round-Time-Out ]

                              * [ Accounting-EAP-Auth-Method ]

                                [ Service-Type ]

Notes
-----
When one or more EAP methods used for authenticating the user, for each
used EAP method an Accounting-EAP-Auth-Method AVP is added in the
Diameter-EAP-Answer with a successful result code. In the message format
of Diameter-EAP-Answer, one or more Accounting-EAP-Auth-Method AVPs can
be included.

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.

--------------------------------------
RFC4072 (draft-ietf-aaa-eap-10)
--------------------------------------
Title               : Diameter Extensible Authentication Protocol (EAP)
Application
Publication Date    : August 2005
Author(s)           : P. Eronen, Ed., T. Hiller, G. Zorn
Category            : PROPOSED STANDARD
Source              : Authentication, Authorization and Accounting
Area                : Operations and Management
Stream              : IETF
Verifying Party     : IESG
_______________________________________________
DiME mailing list
DiME@ietf.org
https://www.ietf.org/mailman/listinfo/dime
    


_______________________________________________
DiME mailing list
DiME@ietf.org
https://www.ietf.org/mailman/listinfo/dime

From souheil@tera.ics.keio.ac.jp Thu Jul 1 02:31:59 2010 Return-Path: X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 612953A68AB for ; Thu, 1 Jul 2010 02:31:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.368 X-Spam-Level: * X-Spam-Status: No, score=1.368 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, HTML_MESSAGE=0.001, MIME_HTML_ONLY=1.457] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h-tgSnA7H5Zs for ; Thu, 1 Jul 2010 02:31:50 -0700 (PDT) Received: from maro.tera.ics.keio.ac.jp (maro.tera.ics.keio.ac.jp [131.113.71.3]) by core3.amsl.com (Postfix) with ESMTP id 5456D3A68BD for ; Thu, 1 Jul 2010 02:31:44 -0700 (PDT) Received: from [131.113.71.108] (dhcp108.tera.ics.keio.ac.jp [131.113.71.108]) by maro.tera.ics.keio.ac.jp (Postfix) with ESMTPSA id 4ADE51B; Thu, 1 Jul 2010 17:52:40 +0900 (JST) Message-ID: <4C2C5750.5080504@tera.ics.keio.ac.jp> Date: Thu, 01 Jul 2010 17:52:32 +0900 From: Souheil Ben Ayed User-Agent: Thunderbird 2.0.0.24 (X11/20100411) MIME-Version: 1.0 To: Glen Zorn References: <004801cb18ec$7f16a4d0$7d43ee70$@net> In-Reply-To: <004801cb18ec$7f16a4d0$7d43ee70$@net> Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: dime@ietf.org, souheil.benayed@gmail.com Subject: Re: [Dime] FW: [Editorial Errata Reported] RFC4072 (2317) X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Jul 2010 09:31:59 -0000 Dear all,

Please read the section " 2.7.  Accounting" of the RFC 4072.

In this section, it is described that one or more
Accounting-EAP-Auth-Method AVPs may be added in a Diameter-EAP-Answer with a successful result code.

So what is correct ?
- Allow adding one or more Accounting-EAP-Auth-Method AVPs?
- or only one Accounting-EAP-Auth-Method AVP can be included in a Diameter-EAP-Answer?

Souheil


Glen Zorn wrote: 
Dan Romascanu [mailto://dromasca@avaya.com] writes:

  
Dime WG,

Please assess this errata report.

If I understand well then Souheil's observation is that more
Accounting-EAP-Auth-Method AVPs can be included. This seems more like a
Technical errata, which if accepted can create interoperability problems
with existing deployment. Am I correct?
    

I think that your understanding is correct, but the errata makes no sense to
me: AFAIK, only one EAP method can be used in authenticating a user (EAP
methods cannot be chained) & even if they could (as proposed for the new
tunneled EAP method under development in EMU), the structure of the Diameter
EAP app mirrors that of EAP (request/response).  Two EAP methods cannot be
operational simultaneously, so why would two method identifiers need to be
in the same Diameter message?

  
Thanks and Regards,

Dan

-----Original Message-----
From: RFC Errata System [mailto:rfc-editor@rfc-editor.org]
Sent: Thursday, July 01, 2010 7:31 AM
To: pasi.eronen@nokia.com; tomhiller@lucent.com; gwz@cisco.com;
Romascanu, Dan (Dan); rbonica@juniper.net; Bernard_Aboba@hotmail.com;
david@mitton.com; john.loughney@nokia.com
Cc: souheil.benayed@gmail.com; rfc-editor@rfc-editor.org
Subject: [Editorial Errata Reported] RFC4072 (2317)


The following errata report has been submitted for RFC4072, "Diameter
Extensible Authentication Protocol (EAP) Application".

--------------------------------------
You may review the report below and at:
http://www.rfc-editor.org/errata_search.php?rfc=4072&eid=2317

--------------------------------------
Type: Editorial
Reported by: Souheil Ben Ayed <souheil.benayed@gmail.com>

Section: 3.2.

Original Text
-------------
      <Diameter-EAP-Answer> ::= < Diameter Header: 268, PXY >

                                < Session-Id >

                                { Auth-Application-Id }

                                { Auth-Request-Type }

                                { Result-Code }

                                { Origin-Host }

                                { Origin-Realm }

                                [ User-Name ]

                                [ EAP-Payload ]

                                [ EAP-Reissued-Payload ]

                                [ EAP-Master-Session-Key ]

                                [ EAP-Key-Name ]

                                [ Multi-Round-Time-Out ]

                                [ Accounting-EAP-Auth-Method ]

                                [ Service-Type ]

Corrected Text
--------------
      <Diameter-EAP-Answer> ::= < Diameter Header: 268, PXY >

                                < Session-Id >

                                { Auth-Application-Id }

                                { Auth-Request-Type }

                                { Result-Code }

                                { Origin-Host }

                                { Origin-Realm }

                                [ User-Name ]

                                [ EAP-Payload ]

                                [ EAP-Reissued-Payload ]

                                [ EAP-Master-Session-Key ]

                                [ EAP-Key-Name ]

                                [ Multi-Round-Time-Out ]

                              * [ Accounting-EAP-Auth-Method ]

                                [ Service-Type ]

Notes
-----
When one or more EAP methods used for authenticating the user, for each
used EAP method an Accounting-EAP-Auth-Method AVP is added in the
Diameter-EAP-Answer with a successful result code. In the message format
of Diameter-EAP-Answer, one or more Accounting-EAP-Auth-Method AVPs can
be included.

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.

--------------------------------------
RFC4072 (draft-ietf-aaa-eap-10)
--------------------------------------
Title               : Diameter Extensible Authentication Protocol (EAP)
Application
Publication Date    : August 2005
Author(s)           : P. Eronen, Ed., T. Hiller, G. Zorn
Category            : PROPOSED STANDARD
Source              : Authentication, Authorization and Accounting
Area                : Operations and Management
Stream              : IETF
Verifying Party     : IESG
_______________________________________________
DiME mailing list
DiME@ietf.org
https://www.ietf.org/mailman/listinfo/dime
    


_______________________________________________
DiME mailing list
DiME@ietf.org
https://www.ietf.org/mailman/listinfo/dime

From gwz@net-zen.net Thu Jul 1 02:58:36 2010 Return-Path: X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D2A543A6835 for ; Thu, 1 Jul 2010 02:58:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.995 X-Spam-Level: X-Spam-Status: No, score=-1.995 tagged_above=-999 required=5 tests=[AWL=0.603, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FwkquLXTG5mB for ; Thu, 1 Jul 2010 02:58:32 -0700 (PDT) Received: from smtpout09.prod.mesa1.secureserver.net (smtpout09-01.prod.mesa1.secureserver.net [64.202.165.14]) by core3.amsl.com (Postfix) with SMTP id 2E9D53A67FA for ; Thu, 1 Jul 2010 02:58:31 -0700 (PDT) Received: (qmail 4537 invoked from network); 1 Jul 2010 09:58:42 -0000 Received: from unknown (124.157.141.182) by smtpout09.prod.mesa1.secureserver.net (64.202.165.14) with ESMTP; 01 Jul 2010 09:58:39 -0000 From: "Glen Zorn" To: "'Souheil Ben Ayed'" References: <004801cb18ec$7f16a4d0$7d43ee70$@net> <4C2C5750.5080504@tera.ics.keio.ac.jp> In-Reply-To: <4C2C5750.5080504@tera.ics.keio.ac.jp> Date: Thu, 1 Jul 2010 16:58:31 +0700 Organization: Network Zen Message-ID: <006b01cb1903$f83b8e40$e8b2aac0$@net> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_006C_01CB193E.A49A6640" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcsY+sXS+NBWrDSfRbqWHxHnvl1XvAACPcNg Content-Language: en-us Cc: dime@ietf.org, souheil.benayed@gmail.com Subject: Re: [Dime] FW: [Editorial Errata Reported] RFC4072 (2317) X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Jul 2010 09:58:36 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_006C_01CB193E.A49A6640 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Souheil Ben Ayed [mailto:souheil@tera.ics.keio.ac.jp] writes: Dear all, Please read the section " 2.7. Accounting" of the RFC 4072. In this section, it is described that one or more Accounting-EAP-Auth-Method AVPs may be added in a Diameter-EAP-Answer with a successful result code. So what is correct ? - Allow adding one or more Accounting-EAP-Auth-Method AVPs? - or only one Accounting-EAP-Auth-Method AVP can be included in a Diameter-EAP-Answer? The latter, I think. Souheil Glen Zorn wrote: Dan Romascanu [mailto://dromasca@avaya.com] writes: Dime WG, Please assess this errata report. If I understand well then Souheil's observation is that more Accounting-EAP-Auth-Method AVPs can be included. This seems more like a Technical errata, which if accepted can create interoperability problems with existing deployment. Am I correct? I think that your understanding is correct, but the errata makes no sense to me: AFAIK, only one EAP method can be used in authenticating a user (EAP methods cannot be chained) & even if they could (as proposed for the new tunneled EAP method under development in EMU), the structure of the Diameter EAP app mirrors that of EAP (request/response). Two EAP methods cannot be operational simultaneously, so why would two method identifiers need to be in the same Diameter message? Thanks and Regards, Dan -----Original Message----- From: RFC Errata System [mailto:rfc-editor@rfc-editor.org] Sent: Thursday, July 01, 2010 7:31 AM To: pasi.eronen@nokia.com; tomhiller@lucent.com; gwz@cisco.com; Romascanu, Dan (Dan); rbonica@juniper.net; Bernard_Aboba@hotmail.com; david@mitton.com; john.loughney@nokia.com Cc: souheil.benayed@gmail.com; rfc-editor@rfc-editor.org Subject: [Editorial Errata Reported] RFC4072 (2317) The following errata report has been submitted for RFC4072, "Diameter Extensible Authentication Protocol (EAP) Application". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=4072 &eid=2317 -------------------------------------- Type: Editorial Reported by: Souheil Ben Ayed Section: 3.2. Original Text ------------- ::= < Diameter Header: 268, PXY > < Session-Id > { Auth-Application-Id } { Auth-Request-Type } { Result-Code } { Origin-Host } { Origin-Realm } [ User-Name ] [ EAP-Payload ] [ EAP-Reissued-Payload ] [ EAP-Master-Session-Key ] [ EAP-Key-Name ] [ Multi-Round-Time-Out ] [ Accounting-EAP-Auth-Method ] [ Service-Type ] Corrected Text -------------- ::= < Diameter Header: 268, PXY > < Session-Id > { Auth-Application-Id } { Auth-Request-Type } { Result-Code } { Origin-Host } { Origin-Realm } [ User-Name ] [ EAP-Payload ] [ EAP-Reissued-Payload ] [ EAP-Master-Session-Key ] [ EAP-Key-Name ] [ Multi-Round-Time-Out ] * [ Accounting-EAP-Auth-Method ] [ Service-Type ] Notes ----- When one or more EAP methods used for authenticating the user, for each used EAP method an Accounting-EAP-Auth-Method AVP is added in the Diameter-EAP-Answer with a successful result code. In the message format of Diameter-EAP-Answer, one or more Accounting-EAP-Auth-Method AVPs can be included. 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. -------------------------------------- RFC4072 (draft-ietf-aaa-eap-10) -------------------------------------- Title : Diameter Extensible Authentication Protocol (EAP) Application Publication Date : August 2005 Author(s) : P. Eronen, Ed., T. Hiller, G. Zorn Category : PROPOSED STANDARD Source : Authentication, Authorization and Accounting Area : Operations and Management Stream : IETF Verifying Party : IESG _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime ------=_NextPart_000_006C_01CB193E.A49A6640 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Souheil Ben Ayed [mailto:souheil@tera.ics.keio.ac.jp] = writes:

 

Dear all,

Please read the section " 2.7.  Accounting" of the RFC = 4072.

In this section, it is described that one or more
Accounting-EAP-Auth-Method AVPs may be added in a Diameter-EAP-Answer = with a successful result code.

 

So what is correct ?
- Allow adding one or more Accounting-EAP-Auth-Method AVPs?
- or only one Accounting-EAP-Auth-Method AVP can be included in a Diameter-EAP-Answer?

The latter, I think.



Souheil


Glen Zorn wrote: 

Dan Romascanu [mailto://dromasca@avaya.com] =
writes:
 
  =

Dime =
WG,
 
Please assess this =
errata report.
 
If I =
understand well then Souheil's observation is that =
more
Accounting-EAP-Auth-Method AVPs can be =
included. This seems more like a
Technical errata, =
which if accepted can create interoperability =
problems
with existing deployment. Am I =
correct?
    =

 
I think that your understanding is =
correct, but the errata makes no sense to
me: =
AFAIK, only one EAP method can be used in authenticating a user =
(EAP
methods cannot be chained) & even if they =
could (as proposed for the new
tunneled EAP method =
under development in EMU), the structure of the =
Diameter
EAP app mirrors that of EAP =
(request/response).  Two EAP methods cannot =
be
operational simultaneously, so why would two =
method identifiers need to be
in the same Diameter =
message?
 
  =

Thanks =
and =
Regards,
 
Dan<=
/pre>
 
-----Original =
Message-----
From: RFC Errata System [mailto:rfc-editor@rfc-editor.or=
g]
Sent: Thursday, July 01, 2010 7:31 =
AM
To: pasi.eronen@nokia.com; tomhiller@lucent.com; gwz@cisco.com;
Rom=
ascanu, Dan (Dan); rbonica@juniper.net; Bernard_Aboba@hotmail.com;<=
o:p>
david@mitton.com; john.loughney@nokia.com<=
/o:p>
Cc: souheil.benayed@gmail.com; =
rfc-editor@rfc-editor.org
Subject: [Editorial Errata Reported] RFC4072 =
(2317)
 
 =

The following errata report has been submitted for RFC4072, =
"Diameter
Extensible Authentication Protocol =
(EAP) =
Application".
 
-----=
---------------------------------
You may review =
the report below and at:
http://www.rfc-editor.org/errata_search.php?rfc=3D4072&eid=3D23=
17
 
-----------------=
---------------------
Type: =
Editorial
Reported by: Souheil Ben Ayed <souheil.benayed@gmail.com&g=
t;
 
Section: =
3.2.
 
Original =
Text
-------------
  =
    <Diameter-EAP-Answer> ::=3D < Diameter =
Header: 268, PXY =
>
 
   &=
nbsp;           &n=
bsp;           &nb=
sp;    < Session-Id =
>
 
   &=
nbsp;           &n=
bsp;           &nb=
sp;    { Auth-Application-Id =
}
 
   &nbs=
p;            =
;            =
    { Auth-Request-Type =
}
 
   &nbs=
p;            =
            &=
nbsp;   { Result-Code =
}
 
   &nbs=
p;            =
;            =
    { Origin-Host =
}
 
   &nbs=
p;            =
;            =
    { Origin-Realm =
}
 
   &nbs=
p;            =
;            =
    [ User-Name =
]
 
   &nbs=
p;            =
;            =
    [ EAP-Payload =
]
 
   &nbs=
p;            =
;            =
    [ EAP-Reissued-Payload =
]
 
   &nbs=
p;            =
;            =
    [ EAP-Master-Session-Key =
]
 
   &nbs=
p;            =
;            =
    [ EAP-Key-Name =
]
 
   &nbs=
p;            =
;            =
    [ Multi-Round-Time-Out =
]
 
   &nbs=
p;            =
;            =
    [ Accounting-EAP-Auth-Method =
]
 
   &nbs=
p;            =
;            =
    [ Service-Type =
]
 
Corrected =
Text
--------------
  =
;    <Diameter-EAP-Answer> ::=3D < Diameter =
Header: 268, PXY =
>
 
   &=
nbsp;           &n=
bsp;           &nb=
sp;    < Session-Id =
>
 
   &=
nbsp;           &n=
bsp;           &nb=
sp;    { Auth-Application-Id =
}
 
  =
            &=
nbsp;           &n=
bsp;     { Auth-Request-Type =
}
 
   &nbs=
p;            =
;            =
    { Result-Code =
}
 
   &nbs=
p;            =
;            =
    { Origin-Host =
}
 
   &nbs=
p;            =
;            =
    { Origin-Realm =
}
 
   &nbs=
p;            =
;            =
    [ User-Name =
]
 
   &nbs=
p;    =
            &=
nbsp;           [ =
EAP-Payload =
]
 
   &nbs=
p;            =
;            =
    [ EAP-Reissued-Payload =
]
 
   &nbs=
p;            =
;            =
    [ EAP-Master-Session-Key =
]
 
   &nbs=
p;            =
;            =
    [ EAP-Key-Name =
]
 
   &nbs=
p;            =
;            =
    [ Multi-Round-Time-Out =
]
 
   &nbs=
p;            =
;            =
  * [ Accounting-EAP-Auth-Method =
]
 
   &nbs=
p;            =
;            =
    [ Service-Type =
]
 
Notes
=

-----
When one or more EAP methods used for =
authenticating the user, for each
used EAP method =
an Accounting-EAP-Auth-Method AVP is added in =
the
Diameter-EAP-Answer with a successful result =
code. In the message format
of Diameter-EAP-Answer, =
one or more Accounting-EAP-Auth-Method AVPs can
be =
included.
 
Instructions:<=
o:p>
-------------
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.
 
-------------=
-------------------------
RFC4072 =
(draft-ietf-aaa-eap-10)
----------------------------=
----------
Title      =
         : Diameter Extensible =
Authentication Protocol =
(EAP)
Application
Publication =
Date    : August =
2005
Author(s)      &n=
bsp;    : P. Eronen, Ed., T. Hiller, G. =
Zorn
Category      &nb=
sp;     : PROPOSED =
STANDARD
Source      &=
nbsp;       : Authentication, =
Authorization and =
Accounting
Area      &=
nbsp;         : Operations and =
Management
Stream      =
;        : =
IETF
Verifying Party     : =
IESG
_______________________________________________=

DiME mailing list
DiME@ietf.org
https://www.ietf.org/=
mailman/listinfo/dime
    =

 
 
____________=
___________________________________
DiME mailing =
list
DiME@ietf.org
https://www.ietf.org/=
mailman/listinfo/dime
 
 

 

------=_NextPart_000_006C_01CB193E.A49A6640-- From souheil@tera.ics.keio.ac.jp Fri Jul 2 01:56:37 2010 Return-Path: X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 43A353A68C0 for ; Fri, 2 Jul 2010 01:56:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.639 X-Spam-Level: X-Spam-Status: No, score=0.639 tagged_above=-999 required=5 tests=[AWL=0.729, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1wFiHhQJXajQ for ; Fri, 2 Jul 2010 01:56:36 -0700 (PDT) Received: from maro.tera.ics.keio.ac.jp (maro.tera.ics.keio.ac.jp [131.113.71.3]) by core3.amsl.com (Postfix) with ESMTP id 001613A68B8 for ; Fri, 2 Jul 2010 01:56:35 -0700 (PDT) Received: from [131.113.71.108] (dhcp108.tera.ics.keio.ac.jp [131.113.71.108]) by maro.tera.ics.keio.ac.jp (Postfix) with ESMTPSA id 2E39F2D4; Fri, 2 Jul 2010 17:51:03 +0900 (JST) Message-ID: <4C2DA86D.5060401@tera.ics.keio.ac.jp> Date: Fri, 02 Jul 2010 17:50:53 +0900 From: Souheil Ben Ayed User-Agent: Thunderbird 2.0.0.24 (X11/20100411) MIME-Version: 1.0 To: Glen Zorn References: <004801cb18ec$7f16a4d0$7d43ee70$@net> <4C2C5750.5080504@tera.ics.keio.ac.jp> <006b01cb1903$f83b8e40$e8b2aac0$@net> In-Reply-To: <006b01cb1903$f83b8e40$e8b2aac0$@net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: dime@ietf.org Subject: Re: [Dime] FW: [Editorial Errata Reported] RFC4072 (2317) X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Jul 2010 08:56:37 -0000 Glen Zorn wrote: > > Souheil Ben Ayed [mailto:souheil@tera.ics.keio.ac.jp] writes: > > > > Dear all, > > Please read the section " 2.7. Accounting" of the RFC 4072. > > In this section, it is described that one or more > Accounting-EAP-Auth-Method AVPs may be added in a Diameter-EAP-Answer > with a successful result code. > > > > So what is correct ? > - Allow adding one or more Accounting-EAP-Auth-Method AVPs? > - or only one Accounting-EAP-Auth-Method AVP can be included in a > Diameter-EAP-Answer? > > The latter, I think. > > When only one Accounting-EAP-Auth-Method AVP is included in a Diameter-EAP-Answer, which EAP method will be included in this AVP in the case of an authentication with EAP-TTLS/EAP-MD5, EAP-TTLS/EAP-TLS or any other EAP method that creates a tunnel then authenticates the user with a second EAP method? Should we include only the first used EAP method (in this case EAP-TTLS Type 21), or the second EAP method used for the authentication ? Souheil > > > Souheil > > > Glen Zorn wrote: > > Dan Romascanu [mailto://dromasca@avaya.com] writes: > > > > Dime WG, > > > > Please assess this errata report. > > > > If I understand well then Souheil's observation is that more > > Accounting-EAP-Auth-Method AVPs can be included. This seems more like a > > Technical errata, which if accepted can create interoperability problems > > with existing deployment. Am I correct? > > > > > I think that your understanding is correct, but the errata makes no sense to > me: AFAIK, only one EAP method can be used in authenticating a user (EAP > methods cannot be chained) & even if they could (as proposed for the new > tunneled EAP method under development in EMU), the structure of the Diameter > EAP app mirrors that of EAP (request/response). Two EAP methods cannot be > operational simultaneously, so why would two method identifiers need to be > in the same Diameter message? > > > > Thanks and Regards, > > > > Dan > > > > -----Original Message----- > > From: RFC Errata System [mailto:rfc-editor@rfc-editor.org] > > Sent: Thursday, July 01, 2010 7:31 AM > > To: pasi.eronen@nokia.com ; tomhiller@lucent.com ; gwz@cisco.com ; > > Romascanu, Dan (Dan); rbonica@juniper.net ; Bernard_Aboba@hotmail.com ; > > david@mitton.com ; john.loughney@nokia.com > > Cc: souheil.benayed@gmail.com ; rfc-editor@rfc-editor.org > > Subject: [Editorial Errata Reported] RFC4072 (2317) > > > > > > The following errata report has been submitted for RFC4072, "Diameter > > Extensible Authentication Protocol (EAP) Application". > > > > -------------------------------------- > > You may review the report below and at: > > http://www.rfc-editor.org/errata_search.php?rfc=4072&eid=2317 > > > > -------------------------------------- > > Type: Editorial > > Reported by: Souheil Ben Ayed > > > > Section: 3.2. > > > > Original Text > > ------------- > > ::= < Diameter Header: 268, PXY > > > > > < Session-Id > > > > > { Auth-Application-Id } > > > > { Auth-Request-Type } > > > > { Result-Code } > > > > { Origin-Host } > > > > { Origin-Realm } > > > > [ User-Name ] > > > > [ EAP-Payload ] > > > > [ EAP-Reissued-Payload ] > > > > [ EAP-Master-Session-Key ] > > > > [ EAP-Key-Name ] > > > > [ Multi-Round-Time-Out ] > > > > [ Accounting-EAP-Auth-Method ] > > > > [ Service-Type ] > > > > Corrected Text > > -------------- > > ::= < Diameter Header: 268, PXY > > > > > < Session-Id > > > > > { Auth-Application-Id } > > > > { Auth-Request-Type } > > > > { Result-Code } > > > > { Origin-Host } > > > > { Origin-Realm } > > > > [ User-Name ] > > > > [ EAP-Payload ] > > > > [ EAP-Reissued-Payload ] > > > > [ EAP-Master-Session-Key ] > > > > [ EAP-Key-Name ] > > > > [ Multi-Round-Time-Out ] > > > > * [ Accounting-EAP-Auth-Method ] > > > > [ Service-Type ] > > > > Notes > > ----- > > When one or more EAP methods used for authenticating the user, for each > > used EAP method an Accounting-EAP-Auth-Method AVP is added in the > > Diameter-EAP-Answer with a successful result code. In the message format > > of Diameter-EAP-Answer, one or more Accounting-EAP-Auth-Method AVPs can > > be included. > > > > 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. > > > > -------------------------------------- > > RFC4072 (draft-ietf-aaa-eap-10) > > -------------------------------------- > > Title : Diameter Extensible Authentication Protocol (EAP) > > Application > > Publication Date : August 2005 > > Author(s) : P. Eronen, Ed., T. Hiller, G. Zorn > > Category : PROPOSED STANDARD > > Source : Authentication, Authorization and Accounting > > Area : Operations and Management > > Stream : IETF > > Verifying Party : IESG > > _______________________________________________ > > DiME mailing list > > DiME@ietf.org > > https://www.ietf.org/mailman/listinfo/dime > > > > > > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime > > > > > From souheil@tera.ics.keio.ac.jp Fri Jul 2 02:01:36 2010 Return-Path: X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 726983A696C for ; Fri, 2 Jul 2010 02:01:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.639 X-Spam-Level: X-Spam-Status: No, score=0.639 tagged_above=-999 required=5 tests=[AWL=0.729, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V8sC2d8EAwMA for ; Fri, 2 Jul 2010 02:01:36 -0700 (PDT) Received: from maro.tera.ics.keio.ac.jp (maro.tera.ics.keio.ac.jp [131.113.71.3]) by core3.amsl.com (Postfix) with ESMTP id 051703A689C for ; Fri, 2 Jul 2010 02:01:36 -0700 (PDT) Received: from [131.113.71.108] (dhcp108.tera.ics.keio.ac.jp [131.113.71.108]) by maro.tera.ics.keio.ac.jp (Postfix) with ESMTPSA id 23F612C; Fri, 2 Jul 2010 17:23:06 +0900 (JST) Message-ID: <4C2DA1E3.9020400@tera.ics.keio.ac.jp> Date: Fri, 02 Jul 2010 17:22:59 +0900 From: Souheil Ben Ayed User-Agent: Thunderbird 2.0.0.24 (X11/20100411) MIME-Version: 1.0 To: Glen Zorn References: <004801cb18ec$7f16a4d0$7d43ee70$@net> <4C2C5750.5080504@tera.ics.keio.ac.jp> <006b01cb1903$f83b8e40$e8b2aac0$@net> In-Reply-To: <006b01cb1903$f83b8e40$e8b2aac0$@net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: dime@ietf.org Subject: Re: [Dime] FW: [Editorial Errata Reported] RFC4072 (2317) X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Jul 2010 09:01:36 -0000 Glen Zorn wrote: > > Souheil Ben Ayed [mailto:souheil@tera.ics.keio.ac.jp] writes: > > > > Dear all, > > Please read the section " 2.7. Accounting" of the RFC 4072. > > In this section, it is described that one or more > Accounting-EAP-Auth-Method AVPs may be added in a Diameter-EAP-Answer > with a successful result code. > > > > So what is correct ? > - Allow adding one or more Accounting-EAP-Auth-Method AVPs? > - or only one Accounting-EAP-Auth-Method AVP can be included in a > Diameter-EAP-Answer? > > The latter, I think. > > When only one Accounting-EAP-Auth-Method AVP is included in a Diameter-EAP-Answer, which EAP method will be included in this AVP in the case of an authentication with EAP-TTLS/EAP-MD5, EAP-TTLS/EAP-TLS or any other EAP method that creates a tunnel then authenticates the user with a second EAP method? Should we include only the first used EAP method (in this case EAP-TTLS Type 21), or the second EAP method used for the authentication ? Souheil > > > Souheil > > > Glen Zorn wrote: > > Dan Romascanu [mailto://dromasca@avaya.com] writes: > > > > Dime WG, > > > > Please assess this errata report. > > > > If I understand well then Souheil's observation is that more > > Accounting-EAP-Auth-Method AVPs can be included. This seems more like a > > Technical errata, which if accepted can create interoperability problems > > with existing deployment. Am I correct? > > > > > I think that your understanding is correct, but the errata makes no sense to > me: AFAIK, only one EAP method can be used in authenticating a user (EAP > methods cannot be chained) & even if they could (as proposed for the new > tunneled EAP method under development in EMU), the structure of the Diameter > EAP app mirrors that of EAP (request/response). Two EAP methods cannot be > operational simultaneously, so why would two method identifiers need to be > in the same Diameter message? > > > > Thanks and Regards, > > > > Dan > > > > -----Original Message----- > > From: RFC Errata System [mailto:rfc-editor@rfc-editor.org] > > Sent: Thursday, July 01, 2010 7:31 AM > > To: pasi.eronen@nokia.com ; tomhiller@lucent.com ; gwz@cisco.com ; > > Romascanu, Dan (Dan); rbonica@juniper.net ; Bernard_Aboba@hotmail.com ; > > david@mitton.com ; john.loughney@nokia.com > > Cc: souheil.benayed@gmail.com ; rfc-editor@rfc-editor.org > > Subject: [Editorial Errata Reported] RFC4072 (2317) > > > > > > The following errata report has been submitted for RFC4072, "Diameter > > Extensible Authentication Protocol (EAP) Application". > > > > -------------------------------------- > > You may review the report below and at: > > http://www.rfc-editor.org/errata_search.php?rfc=4072&eid=2317 > > > > -------------------------------------- > > Type: Editorial > > Reported by: Souheil Ben Ayed > > > > Section: 3.2. > > > > Original Text > > ------------- > > ::= < Diameter Header: 268, PXY > > > > > < Session-Id > > > > > { Auth-Application-Id } > > > > { Auth-Request-Type } > > > > { Result-Code } > > > > { Origin-Host } > > > > { Origin-Realm } > > > > [ User-Name ] > > > > [ EAP-Payload ] > > > > [ EAP-Reissued-Payload ] > > > > [ EAP-Master-Session-Key ] > > > > [ EAP-Key-Name ] > > > > [ Multi-Round-Time-Out ] > > > > [ Accounting-EAP-Auth-Method ] > > > > [ Service-Type ] > > > > Corrected Text > > -------------- > > ::= < Diameter Header: 268, PXY > > > > > < Session-Id > > > > > { Auth-Application-Id } > > > > { Auth-Request-Type } > > > > { Result-Code } > > > > { Origin-Host } > > > > { Origin-Realm } > > > > [ User-Name ] > > > > [ EAP-Payload ] > > > > [ EAP-Reissued-Payload ] > > > > [ EAP-Master-Session-Key ] > > > > [ EAP-Key-Name ] > > > > [ Multi-Round-Time-Out ] > > > > * [ Accounting-EAP-Auth-Method ] > > > > [ Service-Type ] > > > > Notes > > ----- > > When one or more EAP methods used for authenticating the user, for each > > used EAP method an Accounting-EAP-Auth-Method AVP is added in the > > Diameter-EAP-Answer with a successful result code. In the message format > > of Diameter-EAP-Answer, one or more Accounting-EAP-Auth-Method AVPs can > > be included. > > > > 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. > > > > -------------------------------------- > > RFC4072 (draft-ietf-aaa-eap-10) > > -------------------------------------- > > Title : Diameter Extensible Authentication Protocol (EAP) > > Application > > Publication Date : August 2005 > > Author(s) : P. Eronen, Ed., T. Hiller, G. Zorn > > Category : PROPOSED STANDARD > > Source : Authentication, Authorization and Accounting > > Area : Operations and Management > > Stream : IETF > > Verifying Party : IESG > > _______________________________________________ > > DiME mailing list > > DiME@ietf.org > > https://www.ietf.org/mailman/listinfo/dime > > > > > > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime > > > > > From gwz@net-zen.net Fri Jul 2 04:57:57 2010 Return-Path: X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3D17F3A687E for ; Fri, 2 Jul 2010 04:57:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.039 X-Spam-Level: X-Spam-Status: No, score=-2.039 tagged_above=-999 required=5 tests=[AWL=0.560, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aCko-1HK5ORi for ; Fri, 2 Jul 2010 04:57:56 -0700 (PDT) Received: from smtpauth14.prod.mesa1.secureserver.net (smtpauth14.prod.mesa1.secureserver.net [64.202.165.39]) by core3.amsl.com (Postfix) with SMTP id 6A7073A635F for ; Fri, 2 Jul 2010 04:57:56 -0700 (PDT) Received: (qmail 13882 invoked from network); 2 Jul 2010 11:58:08 -0000 Received: from unknown (124.157.141.182) by smtpauth14.prod.mesa1.secureserver.net (64.202.165.39) with ESMTP; 02 Jul 2010 11:58:07 -0000 From: "Glen Zorn" To: Date: Fri, 2 Jul 2010 18:57:53 +0700 Organization: Network Zen Message-ID: <01f601cb19dd$cff1aca0$6fd505e0$@net> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_01F7_01CB1A18.7C5084A0" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcsZ3BJBn1j7zFESRLKaU+zQ6TItkgAATPgw Content-Language: en-us Subject: [Dime] FYI: I-D Action:draft-wu-hokey-rfc5296bis-00.txt X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Jul 2010 11:57:57 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_01F7_01CB1A18.7C5084A0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit -----Original Message----- From: i-d-announce-bounces@ietf.org [mailto:i-d-announce-bounces@ietf.org] On Behalf Of Internet-Drafts@ietf.org Sent: Friday, July 02, 2010 6:45 PM To: i-d-announce@ietf.org Subject: I-D Action:draft-wu-hokey-rfc5296bis-00.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : EAP Extensions for EAP Re-authentication Protocol (ERP) Author(s) : G. Zorn, et al. Filename : draft-wu-hokey-rfc5296bis-00.txt Pages : 42 Date : 2010-07-02 The Extensible Authentication Protocol (EAP) is a generic framework supporting multiple types of authentication methods. In systems where EAP is used for authentication, it is desirable to not repeat the entire EAP exchange with another authenticator. This document specifies extensions to EAP and the EAP keying hierarchy to support an EAP method-independent protocol for efficient re-authentication between the peer and an EAP re-authentication server through any authenticator. The re-authentication server may be in the home network or in the local network to which the peer is connecting. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-wu-hokey-rfc5296bis-00.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. ------=_NextPart_000_01F7_01CB1A18.7C5084A0 Content-Type: Message/External-body; name="draft-wu-hokey-rfc5296bis-00.txt" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="draft-wu-hokey-rfc5296bis-00.txt" Content-Type: text/plain Content-ID: <2010-07-02043902.I-D@ietf.org> ------=_NextPart_000_01F7_01CB1A18.7C5084A0 Content-Type: text/plain; name="ATT00500.txt" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="ATT00500.txt" _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www.ietf.org/mailman/listinfo/i-d-announce Internet-Draft directories: http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt ------=_NextPart_000_01F7_01CB1A18.7C5084A0-- From gwz@net-zen.net Sat Jul 3 00:46:16 2010 Return-Path: X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D7A953A6970 for ; Sat, 3 Jul 2010 00:46:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.869 X-Spam-Level: X-Spam-Status: No, score=-0.869 tagged_above=-999 required=5 tests=[AWL=-0.684, BAYES_40=-0.185] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RsZOPpJk216W for ; Sat, 3 Jul 2010 00:46:15 -0700 (PDT) Received: from smtpauth11.prod.mesa1.secureserver.net (smtpauth11.prod.mesa1.secureserver.net [64.202.165.33]) by core3.amsl.com (Postfix) with SMTP id 1DDA93A6985 for ; Sat, 3 Jul 2010 00:46:15 -0700 (PDT) Received: (qmail 25511 invoked from network); 3 Jul 2010 07:46:26 -0000 Received: from unknown (124.157.141.182) by smtpauth11.prod.mesa1.secureserver.net (64.202.165.33) with ESMTP; 03 Jul 2010 07:46:25 -0000 From: "Glen Zorn" To: Date: Sat, 3 Jul 2010 14:46:07 +0700 Organization: Network Zen Message-ID: <000001cb1a83$cebcd1b0$6c367510$@net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Acsag8tqv08vbcFMRo2pPHiMbpGNgw== Content-Language: en-us Cc: draft-ietf-dime-extended-naptr@tools.ietf.org Subject: [Dime] comments on draft-ietf-dime-extended-naptr-01 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Jul 2010 07:46:17 -0000 1) The last paragraph of Section 3 says: The DNS administrator of some domain SHOULD also provision base RFC 3588 style NAPTR records [RFC2915] in order to guarantee backwards compatibility with legacy RFC 3588 compliant Diameter peers. The word "some" doesn't really make sense to me; suggest changing it to "the" or "a". 2) The reference to I-D.ietf-dime-diameter-qos needs to be updated to RFC 5866. Aside from these minor problems, I think that the draft is ready for publication. From jouni.nospam@gmail.com Mon Jul 5 01:48:06 2010 Return-Path: X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4D8193A68CD for ; Mon, 5 Jul 2010 01:48: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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1LyoWkSFOxb8 for ; Mon, 5 Jul 2010 01:48:05 -0700 (PDT) Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by core3.amsl.com (Postfix) with ESMTP id 466CF3A65A5 for ; Mon, 5 Jul 2010 01:48:05 -0700 (PDT) Received: by fxm1 with SMTP id 1so3714533fxm.31 for ; Mon, 05 Jul 2010 01:48:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:subject:mime-version :content-type:from:in-reply-to:date:cc:content-transfer-encoding :message-id:references:to:x-mailer; bh=St5d0IPSR/I04vwZcQ+W5/Gtdtf7dqeHY9UjGEujcpg=; b=JLo6woTN6HQZDtlZjc6cd3gTZSJBzUxOfI3vqN3A9ajMqZMBHBrXGGSMGXyHkOVRgI +PVRrz5XRcuJHASSgHWre3u3boG2CsdpYtpuPsUG7s/wLGDn4FaUNAaUyz8tzjWQPeVO KP4cKJs8/6c41JzK3H4ApDxABp5+FAYsRmuD0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; b=W0rOzG3UhOVtJAJLnFuQ2H51LsItu+YsakOMJSTzxvFVyBm041LrWI8CUYCzGL1Gel Vf+rJNi8LCttwX71g/7XM3kcMWywQie3fz2PSUCqiqGsX9foOWSbX8PjOzJiyEgOYm6V wMrEcXRNF/eV4nM6+YLg6BEav+h8xfyc5twDU= Received: by 10.223.107.143 with SMTP id b15mr1933130fap.93.1278319682405; Mon, 05 Jul 2010 01:48:02 -0700 (PDT) Received: from a88-114-167-71.elisa-laajakaista.fi (a88-114-167-71.elisa-laajakaista.fi [88.114.167.71]) by mx.google.com with ESMTPS id 8sm8611567fau.28.2010.07.05.01.48.00 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 05 Jul 2010 01:48:01 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1078) Content-Type: text/plain; charset=us-ascii From: jouni korhonen In-Reply-To: Date: Mon, 5 Jul 2010 11:47:57 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <794BF457-D758-414D-851C-4EAEA23851C0@gmail.com> References: To: dime@ietf.org X-Mailer: Apple Mail (2.1078) Subject: Re: [Dime] Request for agenda slots X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Jul 2010 08:48:06 -0000 Just a reminder. There has not been too many requests so far. Remember = that Dime WG is not taking in new work item until we complete our = current batch. However, presenting new good ideas/I-Ds is always = possible and we will give slots as the agenda allows. - Jouni & Lionel On Jun 2, 2010, at 10:59 AM, jouni korhonen wrote: > Hi all, >=20 > (resending as I used wrong email address again when sending..) >=20 > We have requested a 2 hour slot for the DIME WG meeting at IETF#78. > If you need a slot on the agenda to present an I-D related to the DIME > charter, please send a request (to chairs) including: >=20 > 1. I-D name > 2. Time required > 3. How is the I-D associated with the charter and WG goals >=20 > Please note that WG items will take priority over others. >=20 > - Chairs From Hannes.Tschofenig@gmx.net Tue Jul 6 02:15:21 2010 Return-Path: X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D08F13A683E for ; Tue, 6 Jul 2010 02:15:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.961 X-Spam-Level: * X-Spam-Status: No, score=1.961 tagged_above=-999 required=5 tests=[BAYES_50=0.001, RCVD_IN_BL_SPAMCOP_NET=1.96] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KagzdGet10GT for ; Tue, 6 Jul 2010 02:15:21 -0700 (PDT) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id AA2823A6823 for ; Tue, 6 Jul 2010 02:15:20 -0700 (PDT) Received: (qmail 13442 invoked by uid 0); 6 Jul 2010 09:15:21 -0000 Received: from 213.162.68.121 by www051.gmx.net with HTTP; Tue, 06 Jul 2010 11:15:19 +0200 (CEST) Content-Type: text/plain; charset="utf-8" Date: Tue, 06 Jul 2010 11:15:19 +0200 From: "Hannes Tschofenig" Message-ID: <20100706091519.251510@gmx.net> MIME-Version: 1.0 To: dime@ietf.org, radiusext@ops.ietf.org X-Authenticated: #29516787 X-Flags: 0001 X-Mailer: WWW-Mail 6100 (Global Message Exchange) X-Priority: 3 X-Provags-ID: V01U2FsdGVkX19iPQlUcmtiqZL30xV42pf90g5GUUbnwfzbHsZ2AR ADM1CGfkHuY0OMwjh7rWvZUAPH+BdpAEwTLQ== Content-Transfer-Encoding: 8bit X-GMX-UID: E8YAfw5VPTR+KcRQ8zMwleA5c2tpZAu3 X-FuHaFi: 0.68999999999999995 Subject: [Dime] Federated Authentication Beyond The Web: Problem Statement and Requirements X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Jul 2010 09:15:21 -0000 Hi all, at the next IETF meeting we are going to have a BOF about "Federated Authentication Beyond The Web". In case you have not noticed the work relates to RADIUS and Diameter. I wrote this very short problem statement document to explain the purpose of the BOF: http://www.ietf.org/internet-drafts/draft-tschofenig-moonshot-ps-00.txt Let me know if you find the description useful. Feedback about the BOF topic would also be appreciated. Ciao Hannes From root@core3.amsl.com Thu Jul 8 10:00:03 2010 Return-Path: X-Original-To: dime@ietf.org Delivered-To: dime@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 7EEBD3A6B4A; Thu, 8 Jul 2010 10:00:02 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20100708170003.7EEBD3A6B4A@core3.amsl.com> Date: Thu, 8 Jul 2010 10:00:03 -0700 (PDT) Cc: dime@ietf.org Subject: [Dime] I-D ACTION:draft-ietf-dime-priority-avps-02.txt X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Jul 2010 17:00:03 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Diameter Maintenance and Extensions Working Group of the IETF. Title : Diameter Priority Attribute Value Pairs Author(s) : K. Carlberg, T. Taylor Filename : draft-ietf-dime-priority-avps-02.txt Pages : 7 Date : 2010-7-8 This document defines Attribute-Value Pair (AVP) containers for various priority parameters for use with Diameter and the AAA framework. The parameters themselves are defined in several different protocols that operate at either the network or application layer. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dime-priority-avps-02.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-dime-priority-avps-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2010-7-8095907.I-D@ietf.org> --NextPart-- From Hannes.Tschofenig@gmx.net Fri Jul 9 10:31:28 2010 Return-Path: X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 06EE03A6AB7 for ; Fri, 9 Jul 2010 10:31:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.332 X-Spam-Level: X-Spam-Status: No, score=-0.332 tagged_above=-999 required=5 tests=[AWL=0.307, BAYES_00=-2.599, RCVD_IN_BL_SPAMCOP_NET=1.96] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tPCuhYLPz27V for ; Fri, 9 Jul 2010 10:30:50 -0700 (PDT) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id B55923A69B9 for ; Fri, 9 Jul 2010 10:30:34 -0700 (PDT) Received: (qmail 4906 invoked by uid 0); 9 Jul 2010 17:30:25 -0000 Received: from 213.162.68.138 by www161.gmx.net with HTTP; Fri, 09 Jul 2010 19:30:22 +0200 (CEST) Content-Type: text/plain; charset="utf-8" Date: Fri, 09 Jul 2010 19:30:23 +0200 From: "Hannes Tschofenig" In-Reply-To: <4C330810.6010003@wierenga.net> Message-ID: <20100709173023.107930@gmx.net> MIME-Version: 1.0 References: <20100706091519.251510@gmx.net> <4C330810.6010003@wierenga.net> To: Klaas Wierenga X-Authenticated: #29516787 X-Flags: 0001 X-Mailer: WWW-Mail 6100 (Global Message Exchange) X-Priority: 3 X-Provags-ID: V01U2FsdGVkX18utzlm5XYuc57u7LsFv8WbZe8Y+WFPbIE9hA5dYe 8rkUIEheBM+d0bVR/dFFpXrZl7HlGHdpxnZQ== Content-Transfer-Encoding: 8bit X-GMX-UID: zjBcJGB/TlI8cJsGtWlr231OU2poZRnR X-FuHaFi: 0.54000000000000004 Cc: dime@ietf.org, radiusext@ops.ietf.org Subject: Re: [Dime] Federated Authentication Beyond The Web: Problem Statement and Requirements X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Jul 2010 17:31:28 -0000 Hi Klaas, sorry for the late response. Interesting statement. I agree that there are other approaches (and probably everyone would agree with that; we could even list Kerberos). However, the MOONSHOT BOF is (if I understood it correctly) constraint to the mentioned constraints. The usage of OpenID in SASL/GSS-API (like you pointed out) will be done in KITTEN independently and has different design constraints. Ciao Hannes > On 7/6/10 11:15 AM, Hannes Tschofenig wrote: > > Hi Hannes, > > > at the next IETF meeting we are going to have a BOF about "Federated > Authentication Beyond The Web". In case you have not noticed the work relates > to RADIUS and Diameter. > > > > I wrote this very short problem statement document to explain the > purpose of the BOF: > > http://www.ietf.org/internet-drafts/draft-tschofenig-moonshot-ps-00.txt > > > > Let me know if you find the description useful. Feedback about the BOF > topic would also be appreciated. > > I find the description useful, however I would like to challenge the > MUST for RADIUS and/or Diamter. There are a number of Federated > Authentication for applications access protocols out there, SAML, OpenID > and others. RADIUS and Diamter are typically associated with network > access. And while I do see the attractiveness of marrying the two (and > thus leveraging existing trust fabrics), I wonder why you want to > restrict a priori to just those. As an example > draft-cantor-ietf-sasl-saml-ec-00.txt, draft-lear-ietf-sasl-openid-00, > and draft-wierenga-ietf-sasl-saml-00 specify the use of federated > authentication in a SASL context. And services like eduroam are an > example of the use of just RADIUS to implement federated authentication > for non-web applications. > I do understand that it is not possible nor desirable to take on > everything, but let's at least have this scoping discussion in the BoF. > > Klaas > > -- > to unsubscribe send a message to radiusext-request@ops.ietf.org with > the word 'unsubscribe' in a single line as the message text body. > archive: From Hannes.Tschofenig@gmx.net Mon Jul 12 04:13:10 2010 Return-Path: X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8B58A3A6919 for ; Mon, 12 Jul 2010 04:13:10 -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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cZk-KTZI0iss for ; Mon, 12 Jul 2010 04:13:09 -0700 (PDT) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id 3579B3A657C for ; Mon, 12 Jul 2010 04:13:08 -0700 (PDT) Received: (qmail 19538 invoked by uid 0); 12 Jul 2010 11:13:15 -0000 Received: from 62.213.134.242 by www060.gmx.net with HTTP; Mon, 12 Jul 2010 13:13:14 +0200 (CEST) Content-Type: text/plain; charset="utf-8" Date: Mon, 12 Jul 2010 13:13:14 +0200 From: "Hannes Tschofenig" In-Reply-To: <4C3AF682.3080507@wierenga.net> Message-ID: <20100712111314.159820@gmx.net> MIME-Version: 1.0 References: <20100706091519.251510@gmx.net> <4C330810.6010003@wierenga.net> <20100709173023.107930@gmx.net> <4C3AF682.3080507@wierenga.net> To: Klaas Wierenga X-Authenticated: #29516787 X-Flags: 0001 X-Mailer: WWW-Mail 6100 (Global Message Exchange) X-Priority: 3 X-Provags-ID: V01U2FsdGVkX18MJlYysWYMVt2aoFdXAdvQcb73Fj2U/wIaRbhePl 3IfRUD+i5z5L05COcJdoCM7lCr+p3T0YcxCw== Content-Transfer-Encoding: 8bit X-GMX-UID: hY1bKAdfa0A7V5IMtzAzISo/Njh6dM7q X-FuHaFi: 0.70999999999999996 Cc: dime@ietf.org, MOONSHOT-COMMUNITY@JISCMAIL.AC.UK, radiusext@ops.ietf.org Subject: Re: [Dime] Federated Authentication Beyond The Web: Problem Statement and Requirements X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Jul 2010 11:13:10 -0000 > My point is that I'd like the BoF to start open-minded. I believe > federated authentication for non-Web is a large and interesting area. I > would like to make sure that we don't rule out beforehand alternative > approaches. I am happy with a charter as outcome that specifies that the > WG is going to take the Moonshot approach, but imo that should be the > *result* of the BoF, not a *precondition*. I understand your thinking. I actually had the same concerns initially but a more focused discussion really helps. Additionally, nothing prevents someone else to propose another activity (either in form of a BOF, or by submitting drafts to a working group). I am quite happy with the scope of the work as being proposed. Ciao Hannes From root@core3.amsl.com Mon Jul 12 11:15:09 2010 Return-Path: X-Original-To: dime@ietf.org Delivered-To: dime@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 31A853A67D9; Mon, 12 Jul 2010 11:15:04 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20100712181505.31A853A67D9@core3.amsl.com> Date: Mon, 12 Jul 2010 11:15:04 -0700 (PDT) Cc: dime@ietf.org Subject: [Dime] I-D Action:draft-ietf-dime-nat-control-03.txt X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Jul 2010 18:15:09 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Diameter Maintenance and Extensions Working Group of the IETF. Title : Diameter Network Address and Port Translation Control Application Author(s) : F. Brockners, et al. Filename : draft-ietf-dime-nat-control-03.txt Pages : 40 Date : 2010-07-12 This document describes the framework, messages, and procedures for the Diameter Network address and port translation Control Application (DNCA). The DNCA allows per endpoint control of large scale Network Address Translators (NATs) and Network Address and Port Translators (NAPTs), which are added to cope with IPv4-address space completion. The DNCA allows external devices to configure and manage a NAT device - expanding the existing Diameter-based AAA and policy control capabilities with a NAT and NAPT control component. These external devices can be network elements in the data plane such as a Network Access Server (NAS), or can be more centralized control plane devices such as AAA-servers. DNCA establishes a context to commonly identify and manage endpoints on a gateway or server, and a large scale NAT/ NAPT device. This includes, for example, the control of the total number of NAT bindings allowed or the allocation of a specific NAT binding for a particular endpoint. In addition, it allows large scale NAT devices to provide information relevant to accounting purposes. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dime-nat-control-03.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-dime-nat-control-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2010-07-12111002.I-D@ietf.org> --NextPart-- From tom111.taylor@bell.net Mon Jul 12 11:34:41 2010 Return-Path: X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3A9CF3A6BD7 for ; Mon, 12 Jul 2010 11:34:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.076 X-Spam-Level: * X-Spam-Status: No, score=1.076 tagged_above=-999 required=5 tests=[AWL=0.272, BAYES_50=0.001, MSGID_FROM_MTA_HEADER=0.803] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ETmMu8cSUgpj for ; Mon, 12 Jul 2010 11:34:33 -0700 (PDT) Received: from blu0-omc3-s4.blu0.hotmail.com (blu0-omc3-s4.blu0.hotmail.com [65.55.116.79]) by core3.amsl.com (Postfix) with ESMTP id 340E13A6B6E for ; Mon, 12 Jul 2010 11:34:03 -0700 (PDT) Received: from BLU0-SMTP74 ([65.55.116.72]) by blu0-omc3-s4.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 12 Jul 2010 11:34:04 -0700 X-Originating-IP: [70.26.17.94] X-Originating-Email: [tom111.taylor@bell.net] Message-ID: Received: from [192.168.2.11] ([70.26.17.94]) by BLU0-SMTP74.blu0.hotmail.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Mon, 12 Jul 2010 11:34:03 -0700 Date: Mon, 12 Jul 2010 14:33:59 -0400 From: Tom Taylor User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: "dime@ietf.org" Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 12 Jul 2010 18:34:04.0090 (UTC) FILETIME=[CDECB1A0:01CB21F0] Subject: [Dime] [Fwd: New Version Notification for draft-ietf-dime-realm-based-redirect-03] X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Jul 2010 18:34:41 -0000 I've updated this draft at last, based on comments from Sebastien and Jouni. Thank you both. I'll remind you of the Huawei IPR associated with this draft. Tom Taylor -------- Original Message -------- Subject: New Version Notification for draft-ietf-dime-realm-based-redirect-03 Date: Mon, 12 Jul 2010 11:32:14 -0700 (PDT) From: IETF I-D Submission Tool To: tom111.taylor@bell.net CC: tena@huawei.com A new version of I-D, draft-ietf-dime-realm-based-redirect-03.txt has been successfully submitted by Tom Taylor and posted to the IETF repository. Filename: draft-ietf-dime-realm-based-redirect Revision: 03 Title: Realm-Based Redirection In Diameter Creation_date: 2010-07-12 WG ID: dime Number_of_pages: 6 Abstract: RFC 3588 allows a Diameter redirect agent to specify one or more individual hosts to which a Diameter message may be redirected by an upstream Diameter node. However, in some circumstances an operator may wish to redirect messages to an alternate domain without specifying individual hosts. This document specifies a mechanism by which this can be achieved. New applications may incorporate this capability by reference to the present document. The IETF Secretariat. From root@core3.amsl.com Mon Jul 12 11:45:03 2010 Return-Path: X-Original-To: dime@ietf.org Delivered-To: dime@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id F41FD3A69C8; Mon, 12 Jul 2010 11:45:02 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20100712184502.F41FD3A69C8@core3.amsl.com> Date: Mon, 12 Jul 2010 11:45:02 -0700 (PDT) Cc: dime@ietf.org Subject: [Dime] I-D Action:draft-ietf-dime-realm-based-redirect-03.txt X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Jul 2010 18:45:03 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Diameter Maintenance and Extensions Working Group of the IETF. Title : Realm-Based Redirection In Diameter Author(s) : T. Tsou (Ting ZOU), T. Taylor Filename : draft-ietf-dime-realm-based-redirect-03.txt Pages : 6 Date : 2010-07-12 RFC 3588 allows a Diameter redirect agent to specify one or more individual hosts to which a Diameter message may be redirected by an upstream Diameter node. However, in some circumstances an operator may wish to redirect messages to an alternate domain without specifying individual hosts. This document specifies a mechanism by which this can be achieved. New applications may incorporate this capability by reference to the present document. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dime-realm-based-redirect-03.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-dime-realm-based-redirect-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2010-07-12113214.I-D@ietf.org> --NextPart-- From tom111.taylor@bell.net Mon Jul 12 16:50:45 2010 Return-Path: X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 497513A68FD for ; Mon, 12 Jul 2010 16:50:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.058 X-Spam-Level: * X-Spam-Status: No, score=1.058 tagged_above=-999 required=5 tests=[AWL=0.254, BAYES_50=0.001, MSGID_FROM_MTA_HEADER=0.803] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id si7V7nFNMByl for ; Mon, 12 Jul 2010 16:50:44 -0700 (PDT) Received: from blu0-omc3-s19.blu0.hotmail.com (blu0-omc3-s19.blu0.hotmail.com [65.55.116.94]) by core3.amsl.com (Postfix) with ESMTP id DE3A03A68CD for ; Mon, 12 Jul 2010 16:50:43 -0700 (PDT) Received: from BLU0-SMTP31 ([65.55.116.72]) by blu0-omc3-s19.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 12 Jul 2010 16:50:52 -0700 X-Originating-IP: [70.26.17.94] X-Originating-Email: [tom111.taylor@bell.net] Message-ID: Received: from [192.168.2.11] ([70.26.17.94]) by BLU0-SMTP31.blu0.hotmail.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Mon, 12 Jul 2010 16:50:51 -0700 Date: Mon, 12 Jul 2010 19:50:46 -0400 From: Tom Taylor User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: "dime@ietf.org" Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 12 Jul 2010 23:50:51.0859 (UTC) FILETIME=[0F701230:01CB221D] Subject: [Dime] [Fwd: New Version Notification for draft-huang-dime-pcn-collection-03] X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Jul 2010 23:50:45 -0000 I've updated this draft to match the contents of the PCN documents on which it depends. These documents are now in WGLC. As far as I know at the moment, there is no IPR hidden here. -------- Original Message -------- Subject: New Version Notification for draft-huang-dime-pcn-collection-03 Date: Mon, 12 Jul 2010 16:48:40 -0700 (PDT) From: IETF I-D Submission Tool To: tom111.taylor@bell.net CC: fqhuang@huawei.com,gwz@net-zen.net,Hannes.Tschofenig@nsn.com A new version of I-D, draft-huang-dime-pcn-collection-03.txt has been successfully submitted by Tom Taylor and posted to the IETF repository. Filename: draft-huang-dime-pcn-collection Revision: 03 Title: Diameter Application To Transfer PCN Data From Edge Nodes To a Centralized Decision Point Creation_date: 2010-07-13 WG ID: Independent Submission Number_of_pages: 17 Abstract: Pre-congestion notification (PCN) is a technique for maintaining QoS for inelastic flows in a DIFFServ domain. The PCN architecture requires that egress nodes send regular reports of PCN-defined measurements to a decision point. It requires further that the decision point occasionally be able to request certain measurements from ingress nodes. The decision point can be located in different places in the network. This memo defines a Diameter application to support communications between the ingress and egress nodes and a Diameter server acting as a PCN decision point. The IETF Secretariat. From Hannes.Tschofenig@gmx.net Tue Jul 13 01:55:21 2010 Return-Path: X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BB7183A68CC for ; Tue, 13 Jul 2010 01:55:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.851 X-Spam-Level: X-Spam-Status: No, score=-0.851 tagged_above=-999 required=5 tests=[AWL=-0.666, BAYES_40=-0.185] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sfEosh9o-c-M for ; Tue, 13 Jul 2010 01:55:17 -0700 (PDT) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id 1AAF73A6A08 for ; Tue, 13 Jul 2010 01:55:16 -0700 (PDT) Received: (qmail 16916 invoked by uid 0); 13 Jul 2010 08:55:24 -0000 Received: from 62.213.134.242 by www096.gmx.net with HTTP; Tue, 13 Jul 2010 10:55:23 +0200 (CEST) Content-Type: multipart/mixed; boundary="========GMX107941279011323929753" Date: Tue, 13 Jul 2010 10:55:23 +0200 From: "Hannes Tschofenig" Message-ID: <20100713085523.107940@gmx.net> MIME-Version: 1.0 To: MOONSHOT-COMMUNITY@JISCMAIL.AC.UK, dime@ietf.org, radiusext@ops.ietf.org X-Authenticated: #29516787 X-Flags: 0001 X-Mailer: WWW-Mail 6100 (Global Message Exchange) X-Priority: 3 X-Provags-ID: V01U2FsdGVkX1/xg6JYVirxu6NGFD5//+vleIzjvPoav03PoWgt/4 gncO2+QLtWCzakKz7b8dLUhaHKqmVr/0mjKA== X-GMX-UID: yR8JfV9CbUk7LcVQ8Gkn4mtsZ2hlN8ql X-FuHaFi: 0.77000000000000002 Subject: [Dime] Updated draft about "Federated Authentication Beyond The Web: Problem Statement and Requirements" X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Jul 2010 08:55:21 -0000 --========GMX107941279011323929753 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit Hi all, I updated the draft based on the received feedback (but missed the submission deadline). Please find it attached to this mail. Let me know if you think the writeup useful. Ciao Hannes --========GMX107941279011323929753 Content-Type: text/plain; charset="iso-8859-15"; name="draft-tschofenig-moonshot-ps-01.txt" Content-Transfer-Encoding: 8bit Content-Disposition: attachment; filename="draft-tschofenig-moonshot-ps-01.txt" MOONSHOT H. Tschofenig Internet-Draft Nokia Siemens Networks Intended status: Standards Track July 13, 2010 Expires: January 14, 2011 Federated Authentication Beyond The Web: Problem Statement and Requirements draft-tschofenig-moonshot-ps-01.txt Abstract It is quite common that application developers and system architects are in need for authentication and authorization support in a distributed environment. At least three parties need to cooperate, namely the end host, the identity provider, and the relying party. At the end of the exchange the identity provider asserts identity information or certain attributes to the relying party without exposing the user's long-term secret to the relying party. Although the problem sounds challenging and interesting, it is not new. In fact, various IETF groups have produced specifications to solve this problem, such as Kerberos, RADIUS, and Diameter. Outside the IETF various Single-Sign-On solution for HTTP-based applications have been developed as well. The reader might therefore wonder about the need for new work given the existence of readily available solutions. This document tries to answer this question in a compact fashion. Note that the description in this document focuses on the scope of the new work as part of the "Federated Authentication Beyond The Web" BOF being proposed rather than what could be theoretically done. Status of this Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." Tschofenig Expires January 14, 2011 [Page 1] Internet-Draft Federated Auth. Beyond The Web: PS July 2010 This Internet-Draft will expire on January 14, 2011. Copyright Notice Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Tschofenig Expires January 14, 2011 [Page 2] Internet-Draft Federated Auth. Beyond The Web: PS July 2010 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 7 3. Assumptions and Requirements . . . . . . . . . . . . . . . . . 8 4. Security Considerations . . . . . . . . . . . . . . . . . . . 10 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 12 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 7.1. Normative References . . . . . . . . . . . . . . . . . . . 13 7.2. Informative References . . . . . . . . . . . . . . . . . . 13 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 14 Tschofenig Expires January 14, 2011 [Page 3] Internet-Draft Federated Auth. Beyond The Web: PS July 2010 1. Introduction The typical setup for a three party protocol involves the End-host, the identity-provider and relying party as illustrated in Figure 1. It might be of surprise that there are actually four parties shown in Figure 1; we will address the invisible party in the middle a little bit later. With three party protocols there are a number of different protocol variants possible, as the available crypto-literature shows. We will not discuss the different options in this document. What is relevant is that a real world entity is behind the end host and responsible for establishing some form of contract with the identity provider, even if it is only as weak as completing a web form and confirming the verification email. The outcome of this initial registration step is that credentials are made available to the identity provider and to the end host (or the user). It is important to highlight that in some scenarios there might indeed be a human behind the device denoted as end host and in other cases there is no human involved in the actual protocol execution. We assume that the identity provider and the relying party belong to different administrative domains. Very often there is some form of relationship between the identity provider and the relying party. This is particularly important when the relying party wants to use information obtained from the identity provider for authorization decisions and when the identity provider does not want to release information to every relying party (or only under certain conditions). While it is possible to have a bilateral agreement between every identity provider and every relying party; on an Internet scale this setup does require some intermediary, the "stuff- in-the-middle". Please note that the lack of scalability is not caused by technical limitations but rather by business limitations since the agreements between identity providers and the relying parties are often business contracts that are financially motivated. The "stuff-in-the-middle" is a placeholder for technical interoperability as well as business practices and operational arrangements, many aspects are outside the scope of the IETF. Agreed terminology for what is labeled as generically "stuff-in- the-middle" is unfortunately not available. Sometimes the term "identity federation", or "trust framework" are used. To make it worse, different terminology is used when looking at specific protocols. Tschofenig Expires January 14, 2011 [Page 4] Internet-Draft Federated Auth. Beyond The Web: PS July 2010 ----- /- -\ // \\ / \ ---- | | ---- ///- -\\\ | | ///- -\\\ / \ | Stuff-in- | / \ | |-+ the-Middle +-| | | Identity | | | | Relying | | Provider | | | | Party | | | | | | | \ / \ / \ / \\\- -/// \\ // \\\- -/// ---- \- -/ ---- < ----- > \ / \ / \ / \ / \ / \ / \ +------------+ / \ | | / v| End Host |v | | | | +------------+ Figure 1: Three Party Authentication Framework Designing new three party authentication and authorization protocols is hard and cryptographic flaws common in designs. Achieving widespead deployment is even more difficult. The HTTP-based Web has enjoyed a lot of attention from the industry with respect to this problem and some amount of success can be noticed even though many of the business aspects with the "stuff-in-the-middle" still has to be sorted out. This document does not focus on an HTTP-based environment and instead focuses on those protocols where HTTP is not used. Despite the increased excitement for layering every protocol on top of HTTP there are still a number of protocols available that do not use HTTP-based transports. Many of these protocols are lacking an authentication and authorization framework of the style shown in Figure 1. Interestingly, for network access authentication the usage of the AAA framework with RADIUS [RFC2865] and Diameter [RFC3588] was quite successful from a deployment point of view. To map the terminology used in Figure 1 to the AAA framework the identity provider Tschofenig Expires January 14, 2011 [Page 5] Internet-Draft Federated Auth. Beyond The Web: PS July 2010 corresponds to the AAA server, the relying party corresponds to the AAA client, and the "stuff-in-the-middle" are AAA proxies and relays (particularly if they are operated by third parties, such as AAA brokers and clearing houses). The front-end, i.e. the end host to AAA client communication, is in case of network access authentication offered by link layer protocols that forward authentication protocol exchanges back-and-forth. Is it possible to design a system that builds on top of successful protocols to offer non-Web-based protocols with a solid starting point for authentication and authorization in a distributed system? Tschofenig Expires January 14, 2011 [Page 6] Internet-Draft Federated Auth. Beyond The Web: PS July 2010 2. Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. Tschofenig Expires January 14, 2011 [Page 7] Internet-Draft Federated Auth. Beyond The Web: PS July 2010 3. Assumptions and Requirements Some requirements restrict the solution space more than others. In this particular case the main requirement is to re-use an existing infrastructure, namely the AAA framework. Briefly stated: The solution MUST make use of the AAA infrastructure (RADIUS and Diameter). Ideally, modifications at AAA servers SHOULD be kept at a minimum. Modifications to the AAA infrastructure that affect operational aspects MUST NOT be made. The next requirement concerns security: The relying party MUST NOT get in possession of the long-term secret of the entity that is authenticated towards the AAA server. Since there is no single authentication mechanism that will be used everywhere there is another associated requirement: The authentication framework MUST allow for the flexible integration of authentication mechanisms. Those who are familiar with the AAA framework might realize that the choices are limited. The standardized Extensible Authentication Protocol (EAP) framework [RFC3748] fits the above requirements and is widely deployed. Assuming that this design decision is taken for granted the remaining work is with the integration of the AAA infrastructure into non-Web- based application protocols. Figure 2 illustrates it graphically. Tschofenig Expires January 14, 2011 [Page 8] Internet-Draft Federated Auth. Beyond The Web: PS July 2010 +--------------+ business |AAA Server | agreements |(Identity | <......+ |Provider) | . | | . +------------+-+ . --^----------|-- . . ///// | | \\\\\ . // | | \\ . *** | | AAA | |. back- | | protocol | |. end | | | |. *** \\ | | // . \\\\\ | | ///// . --|----------|-- . . Authentication | | . and Security | v . +-------------+ Layer +-+----------+--+ . | |<---------------->| |<-.....+ | Application | | Server Side | | @ End Host | Application | Application | | |<================>|(Relying Party)| +-------------+ Application +---------------+ Data *** front-end *** Figure 2: Front-End Integration The front-end (end host to relying party) communication MUST be integrated into the authentication framework available to the back- end. As argued previously the end-to-end authentication framework is EAP. Although EAP support is already integrated in AAA systems (see [RFC3579] and [RFC4072]) the challenge remains to carry EAP payloads from the end host to the relying party using some mechanism. For illustrative purposes, some examples of the front-end protocols suitable for carrying EAP are "TLS using EAP Authentication" [I-D.nir-tls-eap], and GSS-API Mechanism for the EAP [I-D.howlett-eap-gss]. The changes to the end host and the changes to the relying party SHOULD be kept at a minimum. A mechanism that can demonstrate deployment benefits (based on ease of update of existing software, low implementation effort, etc.) MUST be preferred. There MAY be a need to specify multiple mechanisms to support the range of different deployment scenarios. Tschofenig Expires January 14, 2011 [Page 9] Internet-Draft Federated Auth. Beyond The Web: PS July 2010 4. Security Considerations This entire document is about security. Tschofenig Expires January 14, 2011 [Page 10] Internet-Draft Federated Auth. Beyond The Web: PS July 2010 5. IANA Considerations This document does not require actions by IANA. Tschofenig Expires January 14, 2011 [Page 11] Internet-Draft Federated Auth. Beyond The Web: PS July 2010 6. Acknowledgments The author would like to thank Sam Hartman for a discussion about all aspects of the "Federated Authentication Beyond The Web" effort when he was visiting MIT in June 2010. I would like to thank Mayutan Arumaithurai and Klaas Wierenga for their feedback. Tschofenig Expires January 14, 2011 [Page 12] Internet-Draft Federated Auth. Beyond The Web: PS July 2010 7. References 7.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson, "Remote Authentication Dial In User Service (RADIUS)", RFC 2865, June 2000. [RFC3588] Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J. Arkko, "Diameter Base Protocol", RFC 3588, September 2003. [RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. Levkowetz, "Extensible Authentication Protocol (EAP)", RFC 3748, June 2004. [RFC3579] Aboba, B. and P. Calhoun, "RADIUS (Remote Authentication Dial In User Service) Support For Extensible Authentication Protocol (EAP)", RFC 3579, September 2003. [RFC4072] Eronen, P., Hiller, T., and G. Zorn, "Diameter Extensible Authentication Protocol (EAP) Application", RFC 4072, August 2005. 7.2. Informative References [I-D.nir-tls-eap] Nir, Y., Sheffer, Y., Tschofenig, H., and P. Gutmann, "TLS using EAP Authentication", draft-nir-tls-eap-08 (work in progress), July 2010. [I-D.howlett-eap-gss] Hartman, S. and J. Howlett, "A GSS-API Mechanism for the Extensible Authentication Protocol", draft-howlett-eap-gss-00 (work in progress), March 2010. Tschofenig Expires January 14, 2011 [Page 13] Internet-Draft Federated Auth. Beyond The Web: PS July 2010 Author's Address Hannes Tschofenig Nokia Siemens Networks Linnoitustie 6 Espoo 02600 Finland Phone: +358 (50) 4871445 Email: Hannes.Tschofenig@gmx.net URI: http://www.tschofenig.priv.at Tschofenig Expires January 14, 2011 [Page 14] --========GMX107941279011323929753-- From jouni.nospam@gmail.com Wed Jul 14 03:16:28 2010 Return-Path: X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 18A3F3A677C for ; Wed, 14 Jul 2010 03:16: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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J+La1oC1YFOp for ; Wed, 14 Jul 2010 03:16:27 -0700 (PDT) Received: from mail-bw0-f44.google.com (mail-bw0-f44.google.com [209.85.214.44]) by core3.amsl.com (Postfix) with ESMTP id 532103A6A20 for ; Wed, 14 Jul 2010 03:16:26 -0700 (PDT) Received: by bwz7 with SMTP id 7so4326719bwz.31 for ; Wed, 14 Jul 2010 03:16:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:from:content-type :content-transfer-encoding:subject:date:message-id:to:mime-version :x-mailer; bh=53AIR494zhvjdDHLua9hLnIz6lfQmR9jrye00VUCeNI=; b=bLWE1R1MFJl6rDspF++rhXYg2yymZhEHhA+i9q526LlfK+OvMRMg3ntTZYNOTcat61 gjPbjm2ZsiBCwEc5pNL9V0eQyQuAmE/hEp+XuqF9m7nwbFqB4u/1EZ9EQchxoP4fdXA/ unBPRoDKyT5dw92UNs/8JqaI+wcyygDflqhGo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:content-type:content-transfer-encoding:subject:date:message-id :to:mime-version:x-mailer; b=ejyjEboXRzKaV29czko8pfDITgZd9HYABOeo9KjiKw5K6mZoYnUxvVoLJwTACoe2Rg jeSrsaFWhk05AHn/R4853NbrJLWyD8lMHwoGG6pZ9pz8gEsDdzZzu3UiUQKq5Te/Axra Iml+hGPCAm+xVWp2YfWRazN+poK2h9MjdKpwc= Received: by 10.204.48.102 with SMTP id q38mr6115855bkf.125.1279102591223; Wed, 14 Jul 2010 03:16:31 -0700 (PDT) Received: from a83-245-211-124.elisa-laajakaista.fi (a83-245-211-124.elisa-laajakaista.fi [83.245.211.124]) by mx.google.com with ESMTPS id g11sm31547955bkw.10.2010.07.14.03.16.29 (version=TLSv1/SSLv3 cipher=RC4-MD5); Wed, 14 Jul 2010 03:16:30 -0700 (PDT) From: jouni korhonen Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Wed, 14 Jul 2010 13:16:28 +0300 Message-Id: <9F01C7DF-5900-47BF-B211-0A01A715A8A0@gmail.com> To: dime@ietf.org Mime-Version: 1.0 (Apple Message framework v1078) X-Mailer: Apple Mail (2.1078) Subject: [Dime] Dime draft agenda for IETF#78 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Jul 2010 10:16:28 -0000 Diameter Maintenance and Extensions - *preliminary agenda* Still subject to modifications.. - Jouni & Lionel =3D=3D Logistics = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D TUESDAY, July 27, 2010 1300-1500 Afternoon Session I Chairs: Jouni Korhonen (jouni.nospam@gmail.com) Lionel Morand (lionel.morand@orange-ftgroup.com) Room: Athens Conflicts: decade, hashmat BoF, multimob, trill, enum, ccamp, nea =3D=3D Administrative = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D 1) Agenda Bashing (chairs, = 5min) o Jabber: xyz o Note taker #1: xyz o Note taker #2: xyz 2) WG Status Update (chairs, = 15min) o Documents completed WGLC: - Diameter Priority Attribute Value Pairs http://www.ietf.org/id/draft-ietf-dime-priority-avps-02.txt =20 - Diameter Attribute-Value Pairs for Cryptographic Key Transport http://www.ietf.org/id/draft-ietf-dime-local-keytran-07.txt o New IPRs disclosures (RFC5866) o Pending erratas (#1946, ...) o Documents waiting for Proto Write-Up - Diameter Capabilities Update Application http://www.ietf.org/id/draft-ietf-dime-capablities-update-05.txt=20= - Diameter Base Protocol http://www.ietf.org/id/draft-ietf-dime-rfc3588bis-21.txt o Documents in IESG process - Diameter Base Protocol MIB = http://www.ietf.org/id/draft-ietf-dime-diameter-base-protocol-mib-04.txt * AD Evaluation::Revised ID Needed - Diameter Credit Control Application MIB = http://www.ietf.org/id/draft-ietf-dime-diameter-cc-appl-mib-03.txt * AD Evaluation::Revised ID Needed o Other WG documents (not updated/progressed since March) - Diameter support for the EAP Re-authentication Protocol http://tools.ietf.org/id/draft-ietf-dime-erp-03.txt - Diameter IKEv2 PSK = http://tools.ietf.org/id/draft-ietf-dime-ikev2-psk-diameter-02.txt - Diameter Applications Design Guidelines http://tools.ietf.org/id/draft-ietf-dime-app-design-guide-11.txt =3D=3D Working group draft presentations = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D 3) Diameter NAT Control Application (Frank Brockners, = 10min) http://www.ietf.org/id/draft-ietf-dime-nat-control-03.txt o Ready for WGLC? 4) Diameter Support for Proxy Mobile IPv6 Localized Routing (Glen/Qin, = 10min) http://www.ietf.org/id/draft-ietf-dime-pmip6-lr-01.txt 5) Diameter Extended NAPTR (Mark Jones, = 10min) http://www.ietf.org/id/draft-ietf-dime-extended-naptr-01.txt 6) Realm-Based Redirection In Diameter (Tom Taylor, = 10min) http://www.ietf.org/id/draft-ietf-dime-realm-based-redirect-03.txt o Ready for WGLC? =3D=3D Individual drafts presentations = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D 7) Diameter Network Access Server Application (Glen, = 20min) http://www.ietf.org/id/draft-zorn-dime-rfc4005bis-01 o Need for a bis realized among AAA Doctors 8) Diameter General Purpose Session (Marco Liebsch, = 10min) http://www.ietf.org/id/draft-liebsch-dime-diameter-gps-00.txt =3D=3D AOB = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D total = 90min= From dlehmann@ulticom.com Wed Jul 14 08:28:59 2010 Return-Path: X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 48D083A6852 for ; Wed, 14 Jul 2010 08:28:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.739 X-Spam-Level: X-Spam-Status: No, score=-0.739 tagged_above=-999 required=5 tests=[BAYES_20=-0.74, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lDubWSp0M51A for ; Wed, 14 Jul 2010 08:28:55 -0700 (PDT) Received: from bw.ulticom.com (bw.ulticom.com [208.255.120.43]) by core3.amsl.com (Postfix) with ESMTP id 84DB63A6803 for ; Wed, 14 Jul 2010 08:28:55 -0700 (PDT) Received: from colby.ulticom.com (colby.ulticom.com [192.73.206.10]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by bw.ulticom.com (BorderWare Security Platform) with ESMTP id F0DAA06C01E0E8EE for ; Wed, 14 Jul 2010 11:29:03 -0400 (EDT) Received: from MTLEXVS01.ulticom.com (mtlex01.ulticom.com [172.16.40.5]) by colby.ulticom.com (8.13.4/8.12.10) with ESMTP id o6EFT3t4008366 for ; Wed, 14 Jul 2010 11:29:03 -0400 (EDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CB2369.4A617BA1" Date: Wed, 14 Jul 2010 11:29:03 -0400 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: clarification of message length Thread-Index: AcsjaSU8EQPbSoWFSkGRJH8C9GcLLg== From: "David Lehmann" To: Received-SPF: none Subject: [Dime] clarification of message length X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Jul 2010 15:28:59 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CB2369.4A617BA1 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable The RFC states the following for AVPs in section 4. "The length of the padding is not reflected in the AVP Length field." =20 In section 4.2, it states: "Thus the AVP length field of an AVP of type Grouped is always a multiple of 4." =20 These statements are clear for the AVP lengths. However, the length of the message is not so clear. Section 3 states: "The Message Length field is three octets and indicates the length of the Diameter message including the header fields." =20 My question is: Is the message length always a multiple of 4, as is the case for grouped AVPs? If so, should section 3 provide a clear statement to that fact? e.g. "The Message Length field is three octets and indicates the length of the Diameter message including the header fields and the padded AVPs. Thus the message length field is always a multiple of 4." =20 -David =20 ------_=_NextPart_001_01CB2369.4A617BA1 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

The RFC states the following for AVPs in section = 4.

“The length of the padding is not reflected in the AVP Length = field.”

 

In section 4.2, it states:

“Thus the AVP length field of an AVP of type Grouped is =
always a multiple of =
4.”
 
These =
statements are clear for the AVP lengths.  However, the length of =
the message is not so clear.  Section 3 =
states:
“The Message Length field is =
three octets and indicates the length of the Diameter message including =
the header fields.”
 

My question is:  Is the message length always = a multiple of 4, as is the case for grouped AVPs?  If so, should = section 3 provide a clear statement to that fact?

e.g.=
 “The Message Length field is three octets and indicates the =
length of the Diameter message including the header fields and the =
padded AVPs. Thus the message length field is always a multiple of =
4.”

 

-David

 

------_=_NextPart_001_01CB2369.4A617BA1-- From jouni.nospam@gmail.com Fri Jul 16 00:54:05 2010 Return-Path: X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 09E253A6990 for ; Fri, 16 Jul 2010 00:54:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.355 X-Spam-Level: X-Spam-Status: No, score=-2.355 tagged_above=-999 required=5 tests=[AWL=-0.245, BAYES_05=-1.11, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QwT2xuTvnRa2 for ; Fri, 16 Jul 2010 00:54:04 -0700 (PDT) Received: from vs12.mail.saunalahti.fi (vs12.mail.saunalahti.fi [195.197.172.107]) by core3.amsl.com (Postfix) with ESMTP id 08DEA3A6829 for ; Fri, 16 Jul 2010 00:54:04 -0700 (PDT) Received: from saunalahti-vams (localhost [127.0.0.1]) by vs12.mail.saunalahti.fi (Postfix) with SMTP id 5ABF81A9058; Fri, 16 Jul 2010 10:54:14 +0300 (EEST) Received: from vs12.mail.saunalahti.fi ([127.0.0.1]) by vs12.mail.saunalahti.fi ([195.197.172.107]) with SMTP (gateway) id A01331570FE; Fri, 16 Jul 2010 10:54:14 +0300 Received: from gw03.mail.saunalahti.fi (gw03.mail.saunalahti.fi [195.197.172.111]) by vs12.mail.saunalahti.fi (Postfix) with ESMTP id 4CD631A9058; Fri, 16 Jul 2010 10:54:14 +0300 (EEST) Received: from a83-245-209-228.elisa-laajakaista.fi (a83-245-209-228.elisa-laajakaista.fi [83.245.209.228]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by gw03.mail.saunalahti.fi (Postfix) with ESMTP id C572821660C; Fri, 16 Jul 2010 10:54:11 +0300 (EEST) From: Jouni Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Fri, 16 Jul 2010 10:54:11 +0300 Message-Id: <1CCD5EDB-5B3D-4EAF-81F5-4B45D8B545D2@gmail.com> To: dime@ietf.org Mime-Version: 1.0 (Apple Message framework v1078) X-Mailer: Apple Mail (2.1078) X-Antivirus: VAMS Cc: dime-chairs@tools.ietf.org Subject: [Dime] IETF#78 meeting logistics X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Jul 2010 07:54:05 -0000 If you feel like volunteering as a notes taker or a jabber scribe for = the upcoming Dime WG meeting in Maastricht, please drop the chairs a = mail. Having named persons in advance would cut away the traditional = uncomfortable 5 mins of asking volunteers from the crowd who all try to = be faraway ;) Jouni & Lionel= From dlehmann@ulticom.com Fri Jul 16 07:15:35 2010 Return-Path: X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DB4A33A6952 for ; Fri, 16 Jul 2010 07:15:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.739 X-Spam-Level: X-Spam-Status: No, score=-0.739 tagged_above=-999 required=5 tests=[BAYES_20=-0.74, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RBH+p7NXlEXu for ; Fri, 16 Jul 2010 07:15:32 -0700 (PDT) Received: from bw.ulticom.com (bw.ulticom.com [208.255.120.43]) by core3.amsl.com (Postfix) with ESMTP id C154A3A68CB for ; Fri, 16 Jul 2010 07:15:31 -0700 (PDT) Received: from colby.ulticom.com (colby.ulticom.com [192.73.206.10]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by bw.ulticom.com (BorderWare Security Platform) with ESMTP id 630AB06F8DC30496 for ; Fri, 16 Jul 2010 10:15:42 -0400 (EDT) Received: from MTLEXVS01.ulticom.com (mtlex01.ulticom.com [172.16.40.5]) by colby.ulticom.com (8.13.4/8.12.10) with ESMTP id o6GEFdfv007125 for ; Fri, 16 Jul 2010 10:15:41 -0400 (EDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CB24F1.529641FC" Date: Fri, 16 Jul 2010 10:15:20 -0400 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] clarification of message length Thread-Index: AcsjaSU8EQPbSoWFSkGRJH8C9GcLLgBh37cw References: From: "David Lehmann" To: Received-SPF: none Subject: Re: [Dime] clarification of message length X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Jul 2010 14:15:35 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CB24F1.529641FC Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable No comments? I thought the response would be quick for this question. Maybe everybody is too busy packing for Maastricht. J =20 -- David Lehmann Ulticom, Inc. 856-787-2952 =20 From: dime-bounces@ietf.org [mailto:dime-bounces@ietf.org] On Behalf Of David Lehmann Sent: Wednesday, July 14, 2010 11:29 AM To: dime@ietf.org Subject: [Dime] clarification of message length =20 The RFC states the following for AVPs in section 4. "The length of the padding is not reflected in the AVP Length field." =20 In section 4.2, it states: "Thus the AVP length field of an AVP of type Grouped is always a multiple of 4." =20 These statements are clear for the AVP lengths. However, the length of the message is not so clear. Section 3 states: "The Message Length field is three octets and indicates the length of the Diameter message including the header fields." =20 My question is: Is the message length always a multiple of 4, as is the case for grouped AVPs? If so, should section 3 provide a clear statement to that fact? e.g. "The Message Length field is three octets and indicates the length of the Diameter message including the header fields and the padded AVPs. Thus the message length field is always a multiple of 4." =20 -David =20 ------_=_NextPart_001_01CB24F1.529641FC Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

No comments?  I = thought the response would be quick for this question.  Maybe everybody is too = busy packing for Maastricht. J

 

--

David Lehmann

Ulticom, = Inc.

856-787-2952

 

From:= dime-bounces@ietf.org [mailto:dime-bounces@ietf.org] On Behalf Of = David Lehmann
Sent: Wednesday, July 14, 2010 11:29 AM
To: dime@ietf.org
Subject: [Dime] clarification of message = length

 

The RFC states the following for AVPs in section = 4.

“The length of the padding is not reflected in the AVP Length = field.”

 

In section 4.2, it states:

“Thus the AVP length field of an AVP of type Grouped is =
always a multiple of =
4.”
 
These =
statements are clear for the AVP lengths.  However, the length of =
the message is not so clear.  Section 3 =
states:
“The Message Length field is =
three octets and indicates the length of the Diameter message including =
the header fields.”
 

My question is:  Is the message length always = a multiple of 4, as is the case for grouped AVPs?  If so, should = section 3 provide a clear statement to that fact?

e.g.=
 “The Message Length field is three octets and indicates the =
length of the Diameter message including the header fields and the =
padded AVPs. Thus the message length field is always a multiple of =
4.”

 

-David

 

------_=_NextPart_001_01CB24F1.529641FC-- From jouni.nospam@gmail.com Fri Jul 16 07:41:29 2010 Return-Path: X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F00083A6986 for ; Fri, 16 Jul 2010 07:41: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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uBtoZ7eYCq-t for ; Fri, 16 Jul 2010 07:41:26 -0700 (PDT) Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by core3.amsl.com (Postfix) with ESMTP id 38E443A6908 for ; Fri, 16 Jul 2010 07:41:26 -0700 (PDT) Received: by fxm1 with SMTP id 1so1234918fxm.31 for ; Fri, 16 Jul 2010 07:41:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:subject:mime-version :content-type:from:in-reply-to:date:cc:content-transfer-encoding :message-id:references:to:x-mailer; bh=jS2QXHwoL9jArw7+lisGfqd/ElyMxDIRpQCY4a5rJyk=; b=tv3PTuT70UUnTMYDXEtFUrTtmoMce+ueNcAULCOYGy0khanfInQ4anmSikaDfdgINO +GsRs94KbkROjNO8TrMA0mS1rGEQIvo6zzZq7dYEGxQEemaYpXbOVb8pexWF0m/3sg0s OHZZG9d7oKaX6WzR34ETxsOLkdSBGGrlpjoYY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; b=ofkvW1YNEbQ+XsF+arrvkj/GAIuOFwm9XrL6Kj7RXO2l9cUYfe8kQaV3kl2oFMs8mv niqi0mowtYiSMCf6CBLigmFXHIE+/meJGRjHIBbSkLgUumKaPRwKCtJfyAXLvjXZezd6 R1Gi0rJ1kU5UB98IO1XvSKxjeM596tpxiOznk= Received: by 10.223.119.133 with SMTP id z5mr770502faq.62.1279291297192; Fri, 16 Jul 2010 07:41:37 -0700 (PDT) Received: from a88-112-207-39.elisa-laajakaista.fi (a88-112-207-39.elisa-laajakaista.fi [88.112.207.39]) by mx.google.com with ESMTPS id b9sm786197faq.31.2010.07.16.07.41.35 (version=TLSv1/SSLv3 cipher=RC4-MD5); Fri, 16 Jul 2010 07:41:36 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1078) Content-Type: text/plain; charset=windows-1252 From: jouni korhonen In-Reply-To: Date: Fri, 16 Jul 2010 17:41:33 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: David Lehmann X-Mailer: Apple Mail (2.1078) Cc: dime@ietf.org Subject: Re: [Dime] clarification of message length X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Jul 2010 14:41:29 -0000 Hi David, Yes, the message length is always a multiple of 4, just like it is the = case with grouped AVPs. I am not sure whether that needs to be = explicitly stated, because all AVPs the message "sees" are already = multiple of 4. I can understand why that was stated for grouped AVPs as = their length field *does* take the padding of the last sub-AVP into = account, which might not be immediately obvious based on the Section 4 = text. - Jouni On Jul 14, 2010, at 6:29 PM, David Lehmann wrote: > The RFC states the following for AVPs in section 4. > =93The length of the padding is not reflected in the AVP Length = field.=94 > =20 > In section 4.2, it states: > =93Thus the AVP length field of an AVP of type Grouped is always a = multiple of 4.=94 > =20 > These statements are clear for the AVP lengths. However, the length = of the message is not so clear. Section 3 states: > =93The Message Length field is three octets and indicates the length = of the Diameter message including the header fields.=94 > =20 > My question is: Is the message length always a multiple of 4, as is = the case for grouped AVPs? If so, should section 3 provide a clear = statement to that fact? > e.g. =93The Message Length field is three octets and indicates the = length of the Diameter message including the header fields and the = padded AVPs. Thus the message length field is always a multiple of 4.=94 > =20 > -David > =20 > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime From dlehmann@ulticom.com Fri Jul 16 08:14:23 2010 Return-Path: X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 51C5D3A6A66 for ; Fri, 16 Jul 2010 08:14:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.669 X-Spam-Level: X-Spam-Status: No, score=-1.669 tagged_above=-999 required=5 tests=[AWL=0.930, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id opE1Nt16V7Ip for ; Fri, 16 Jul 2010 08:14:21 -0700 (PDT) Received: from bw.ulticom.com (bw.ulticom.com [208.255.120.43]) by core3.amsl.com (Postfix) with ESMTP id 845713A69FF for ; Fri, 16 Jul 2010 08:14:20 -0700 (PDT) Received: from colby.ulticom.com (colby.ulticom.com [192.73.206.10]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by bw.ulticom.com (BorderWare Security Platform) with ESMTP id F0DE906E85E009DD for ; Fri, 16 Jul 2010 11:14:30 -0400 (EDT) Received: from MTLEXVS01.ulticom.com (mtlex01.ulticom.com [172.16.40.5]) by colby.ulticom.com (8.13.4/8.12.10) with ESMTP id o6GFESL4015897 for ; Fri, 16 Jul 2010 11:14:30 -0400 (EDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 16 Jul 2010 11:13:37 -0400 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] clarification of message length Thread-Index: Acsk9QApZb7p6xWrTLygkhqkEW92pwAApVmQ References: From: "David Lehmann" To: Received-SPF: none Subject: Re: [Dime] clarification of message length X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Jul 2010 15:14:23 -0000 Jouni, Thanks for the response. I also worked on an implementation of SCTP. In SCTP, when DATA chunks are bundled into one SCTP packet, the SCTP packet length includes the padding for all of the data chunks, except for the last data chunk. Since another IETF protocol (namely SCTP) uses a different methodology in calculating the length of a message based on padded components, I think explicit wording is prudent. It certainly won't hurt, especially since there is a bis I-D already in the works. -- David Lehmann Ulticom, Inc. 856-787-2952 > -----Original Message----- > From: jouni korhonen [mailto:jouni.nospam@gmail.com] > Sent: Friday, July 16, 2010 10:42 AM > To: David Lehmann > Cc: dime@ietf.org > Subject: Re: [Dime] clarification of message length >=20 > Hi David, >=20 > Yes, the message length is always a multiple of 4, just like it is the case > with grouped AVPs. I am not sure whether that needs to be explicitly stated, > because all AVPs the message "sees" are already multiple of 4. I can > understand why that was stated for grouped AVPs as their length field *does* > take the padding of the last sub-AVP into account, which might not be > immediately obvious based on the Section 4 text. >=20 > - Jouni >=20 > On Jul 14, 2010, at 6:29 PM, David Lehmann wrote: >=20 > > The RFC states the following for AVPs in section 4. > > "The length of the padding is not reflected in the AVP Length field." > > > > In section 4.2, it states: > > "Thus the AVP length field of an AVP of type Grouped is always a multiple > of 4." > > > > These statements are clear for the AVP lengths. However, the length of > the message is not so clear. Section 3 states: > > "The Message Length field is three octets and indicates the length of the > Diameter message including the header fields." > > > > My question is: Is the message length always a multiple of 4, as is the > case for grouped AVPs? If so, should section 3 provide a clear statement to > that fact? > > e.g. "The Message Length field is three octets and indicates the length of > the Diameter message including the header fields and the padded AVPs. Thus > the message length field is always a multiple of 4." > > > > -David > > > > _______________________________________________ > > DiME mailing list > > DiME@ietf.org > > https://www.ietf.org/mailman/listinfo/dime From klaas@wierenga.net Tue Jul 6 03:40:17 2010 Return-Path: X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C72303A68E0 for ; Tue, 6 Jul 2010 03:40:17 -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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BGjItkQ201Hl for ; Tue, 6 Jul 2010 03:40:16 -0700 (PDT) Received: from teletubbie.het.net.je (teletubbie.het.net.je [IPv6:2001:610:508:110:192:87:110:29]) by core3.amsl.com (Postfix) with ESMTP id 9CA773A67B6 for ; Tue, 6 Jul 2010 03:40:16 -0700 (PDT) Received: from 64-103-25-233.cisco.com ([64.103.25.233] helo=macmini.wierenga.net) by teletubbie.het.net.je with esmtpsa (TLSv1:CAMELLIA256-SHA:256) (Exim 4.71 (FreeBSD)) (envelope-from ) id 1OW5ZT-000Psf-Tv; Tue, 06 Jul 2010 12:40:12 +0200 Message-ID: <4C330810.6010003@wierenga.net> Date: Tue, 06 Jul 2010 12:40:16 +0200 From: Klaas Wierenga User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-GB; rv:1.9.1.10) Gecko/20100512 Thunderbird/3.0.5 MIME-Version: 1.0 To: Hannes Tschofenig References: <20100706091519.251510@gmx.net> In-Reply-To: <20100706091519.251510@gmx.net> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Antivirus: no malware found X-Mailman-Approved-At: Tue, 20 Jul 2010 04:41:54 -0700 Cc: dime@ietf.org, radiusext@ops.ietf.org Subject: Re: [Dime] Federated Authentication Beyond The Web: Problem Statement and Requirements X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Jul 2010 10:40:17 -0000 On 7/6/10 11:15 AM, Hannes Tschofenig wrote: Hi Hannes, > at the next IETF meeting we are going to have a BOF about "Federated Authentication Beyond The Web". In case you have not noticed the work relates to RADIUS and Diameter. > > I wrote this very short problem statement document to explain the purpose of the BOF: > http://www.ietf.org/internet-drafts/draft-tschofenig-moonshot-ps-00.txt > > Let me know if you find the description useful. Feedback about the BOF topic would also be appreciated. I find the description useful, however I would like to challenge the MUST for RADIUS and/or Diamter. There are a number of Federated Authentication for applications access protocols out there, SAML, OpenID and others. RADIUS and Diamter are typically associated with network access. And while I do see the attractiveness of marrying the two (and thus leveraging existing trust fabrics), I wonder why you want to restrict a priori to just those. As an example draft-cantor-ietf-sasl-saml-ec-00.txt, draft-lear-ietf-sasl-openid-00, and draft-wierenga-ietf-sasl-saml-00 specify the use of federated authentication in a SASL context. And services like eduroam are an example of the use of just RADIUS to implement federated authentication for non-web applications. I do understand that it is not possible nor desirable to take on everything, but let's at least have this scoping discussion in the BoF. Klaas From klaas@wierenga.net Mon Jul 12 04:03:29 2010 Return-Path: X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5801A3A6991 for ; Mon, 12 Jul 2010 04:03:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.367 X-Spam-Level: X-Spam-Status: No, score=-2.367 tagged_above=-999 required=5 tests=[AWL=0.232, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vEoh06mlRwo5 for ; Mon, 12 Jul 2010 04:03:28 -0700 (PDT) Received: from teletubbie.het.net.je (teletubbie.het.net.je [IPv6:2001:610:508:110:192:87:110:29]) by core3.amsl.com (Postfix) with ESMTP id 9DA003A6B3B for ; Mon, 12 Jul 2010 04:03:25 -0700 (PDT) Received: from 64-103-25-233.cisco.com ([64.103.25.233] helo=macmini.wierenga.net) by teletubbie.het.net.je with esmtpsa (TLSv1:CAMELLIA256-SHA:256) (Exim 4.71 (FreeBSD)) (envelope-from ) id 1OYGn9-0009Jm-LT; Mon, 12 Jul 2010 13:03:19 +0200 Message-ID: <4C3AF682.3080507@wierenga.net> Date: Mon, 12 Jul 2010 13:03:30 +0200 From: Klaas Wierenga User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-GB; rv:1.9.1.10) Gecko/20100512 Thunderbird/3.0.5 MIME-Version: 1.0 To: Hannes Tschofenig References: <20100706091519.251510@gmx.net> <4C330810.6010003@wierenga.net> <20100709173023.107930@gmx.net> In-Reply-To: <20100709173023.107930@gmx.net> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Antivirus: no malware found X-Mailman-Approved-At: Tue, 20 Jul 2010 04:41:54 -0700 Cc: Moonshot community list , dime@ietf.org, radiusext@ops.ietf.org Subject: Re: [Dime] Federated Authentication Beyond The Web: Problem Statement and Requirements X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Jul 2010 11:03:29 -0000 On 7/9/10 7:30 PM, Hannes Tschofenig wrote: Hi Hannes, > sorry for the late response. np > > Interesting statement. > > I agree that there are other approaches (and probably everyone would > agree with that; we could even list Kerberos). > > However, the MOONSHOT BOF is (if I understood it correctly) > constraint to the mentioned constraints. hmm, afaik it is a federated authentication BoF, not a Moonshot BoF > > The usage of OpenID in SASL/GSS-API (like you pointed out) will be > done in KITTEN independently and has different design constraints. I think there is a bit of misunderstanding, I gave those just as an example because I happen to be familiar with them. I am happy with those drafts being in KITTEN, if only to speed things up. So that is not the point. My point is that I'd like the BoF to start open-minded. I believe federated authentication for non-Web is a large and interesting area. I would like to make sure that we don't rule out beforehand alternative approaches. I am happy with a charter as outcome that specifies that the WG is going to take the Moonshot approach, but imo that should be the *result* of the BoF, not a *precondition*. Hope this clarifies the misunderstanding. Klaas > > Ciao Hannes > >> On 7/6/10 11:15 AM, Hannes Tschofenig wrote: >> >> Hi Hannes, >> >>> at the next IETF meeting we are going to have a BOF about >>> "Federated >> Authentication Beyond The Web". In case you have not noticed the >> work relates to RADIUS and Diameter. >>> >>> I wrote this very short problem statement document to explain >>> the >> purpose of the BOF: >>> http://www.ietf.org/internet-drafts/draft-tschofenig-moonshot-ps-00.txt >>> >>> >>> Let me know if you find the description useful. Feedback about the BOF >> topic would also be appreciated. >> >> I find the description useful, however I would like to challenge >> the MUST for RADIUS and/or Diamter. There are a number of >> Federated Authentication for applications access protocols out >> there, SAML, OpenID and others. RADIUS and Diamter are typically >> associated with network access. And while I do see the >> attractiveness of marrying the two (and thus leveraging existing >> trust fabrics), I wonder why you want to restrict a priori to just >> those. As an example draft-cantor-ietf-sasl-saml-ec-00.txt, >> draft-lear-ietf-sasl-openid-00, and >> draft-wierenga-ietf-sasl-saml-00 specify the use of federated >> authentication in a SASL context. And services like eduroam are an >> example of the use of just RADIUS to implement federated >> authentication for non-web applications. I do understand that it is >> not possible nor desirable to take on everything, but let's at >> least have this scoping discussion in the BoF. >> >> Klaas >> >> -- to unsubscribe send a message to radiusext-request@ops.ietf.org >> with the word 'unsubscribe' in a single line as the message text >> body. archive: From wwwrun@rfc-editor.org Mon Jul 19 20:04:56 2010 Return-Path: X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9FF543A681D for ; Mon, 19 Jul 2010 20:04:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.413 X-Spam-Level: X-Spam-Status: No, score=-2.413 tagged_above=-999 required=5 tests=[AWL=0.187, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yWaf+gZxg-2Q for ; Mon, 19 Jul 2010 20:04:55 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1890:1112:1::2f]) by core3.amsl.com (Postfix) with ESMTP id C1F1B3A6804 for ; Mon, 19 Jul 2010 20:04:55 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 0C76AE066E; Mon, 19 Jul 2010 20:05:11 -0700 (PDT) To: jouni.korhonen@nsn.com, Hannes.Tschofenig@gmx.net, mayutan.arumaithurai@gmail.com, mark.jones@bridgewatersystems.com, avi@bridgewatersystems.com, dromasca@avaya.com, rbonica@juniper.net, lionel.morand@orange-ftgroup.com, jouni.korhonen@nsn.com From: RFC Errata System Message-Id: <20100720030511.0C76AE066E@rfc-editor.org> Date: Mon, 19 Jul 2010 20:05:11 -0700 (PDT) X-Mailman-Approved-At: Tue, 20 Jul 2010 04:41:54 -0700 Cc: francois@tera.ics.keio.ac.jp, dime@ietf.org, rfc-editor@rfc-editor.org Subject: [Dime] [Editorial Errata Reported] RFC5777 (2333) X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Jul 2010 03:04:56 -0000 The following errata report has been submitted for RFC5777, "Traffic Classification and Quality of Service (QoS) Attributes for Diameter". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=5777&eid=2333 -------------------------------------- Type: Editorial Reported by: Francois Bard Section: 4.2.1 Original Text ------------- Time-Of-Day-Condition ::= < AVP Header: 560 > [ Time-Of-Day-Start ] [ Time-Of-Day-End ] [ Day-Of-Week-Mask ] [ Day-Of-Month-Mask ] [ Month-Of-Year-Mask ] [ Absolute-Start-Time ] [ Absolute-End-Time ] [ Timezone-Flag ] * [ AVP ] Corrected Text -------------- Time-Of-Day-Condition ::= < AVP Header: 560 > [ Time-Of-Day-Start ] [ Time-Of-Day-End ] [ Day-Of-Week-Mask ] [ Day-Of-Month-Mask ] [ Month-Of-Year-Mask ] [ Absolute-Start-Time ] [ Absolute-Start-Fractional-Seconds ] [ Absolute-End-Time ] [ Absolute-End-Fractional-Seconds ] [ Timezone-Flag ] [ Timezone-Offset ] * [ AVP ] Notes ----- 3 AVPs are omitted in the ABNF for the Time-Of-Day-Condition AVP. 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. -------------------------------------- RFC5777 (draft-ietf-dime-qos-attributes-15) -------------------------------------- Title : Traffic Classification and Quality of Service (QoS) Attributes for Diameter Publication Date : February 2010 Author(s) : J. Korhonen, H. Tschofenig, M. Arumaithurai, M. Jones, Ed., A. Lior Category : PROPOSED STANDARD Source : Diameter Maintanence and Extensions Area : Operations and Management Stream : IETF Verifying Party : IESG From wwwrun@rfc-editor.org Mon Jul 19 20:08:31 2010 Return-Path: X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 366153A69CF for ; Mon, 19 Jul 2010 20:08:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.421 X-Spam-Level: X-Spam-Status: No, score=-2.421 tagged_above=-999 required=5 tests=[AWL=0.179, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ekUA6Bwr98U9 for ; Mon, 19 Jul 2010 20:08:29 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1890:1112:1::2f]) by core3.amsl.com (Postfix) with ESMTP id BCFD33A679F for ; Mon, 19 Jul 2010 20:08:29 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 0AF09E066E; Mon, 19 Jul 2010 20:08:45 -0700 (PDT) To: jouni.korhonen@nsn.com, Hannes.Tschofenig@gmx.net, mayutan.arumaithurai@gmail.com, mark.jones@bridgewatersystems.com, avi@bridgewatersystems.com, dromasca@avaya.com, rbonica@juniper.net, lionel.morand@orange-ftgroup.com, jouni.korhonen@nsn.com From: RFC Errata System Message-Id: <20100720030845.0AF09E066E@rfc-editor.org> Date: Mon, 19 Jul 2010 20:08:45 -0700 (PDT) X-Mailman-Approved-At: Tue, 20 Jul 2010 04:41:54 -0700 Cc: francois@tera.ics.keio.ac.jp, dime@ietf.org, rfc-editor@rfc-editor.org Subject: [Dime] [Editorial Errata Reported] RFC5777 (2334) X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Jul 2010 03:08:31 -0000 The following errata report has been submitted for RFC5777, "Traffic Classification and Quality of Service (QoS) Attributes for Diameter". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=5777&eid=2334 -------------------------------------- Type: Editorial Reported by: Francois Bard Section: 10.1 Original Text ------------- |Timezone-Offset 571 4.2.12 Integer32 | |Treatment-Action 572 5.1 Grouped | |QoS-Profile-Id 573 5.2 Unsigned32 | Corrected Text -------------- |Timezone-Offset 571 4.2.12 Integer32 | |Treatment-Action 572 5.1 Enumerated | |QoS-Profile-Id 573 5.2 Unsigned32 | Notes ----- The Treatment-Action AVP is of type Enumerated, as defined in 5.1 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. -------------------------------------- RFC5777 (draft-ietf-dime-qos-attributes-15) -------------------------------------- Title : Traffic Classification and Quality of Service (QoS) Attributes for Diameter Publication Date : February 2010 Author(s) : J. Korhonen, H. Tschofenig, M. Arumaithurai, M. Jones, Ed., A. Lior Category : PROPOSED STANDARD Source : Diameter Maintanence and Extensions Area : Operations and Management Stream : IETF Verifying Party : IESG From wwwrun@rfc-editor.org Mon Jul 19 20:13:41 2010 Return-Path: X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D10E53A6869 for ; Mon, 19 Jul 2010 20:13:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.428 X-Spam-Level: X-Spam-Status: No, score=-2.428 tagged_above=-999 required=5 tests=[AWL=0.172, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UiJZL5naAyXY for ; Mon, 19 Jul 2010 20:13:39 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1890:1112:1::2f]) by core3.amsl.com (Postfix) with ESMTP id 798903A679F for ; Mon, 19 Jul 2010 20:13:39 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id BF689E066E; Mon, 19 Jul 2010 20:13:54 -0700 (PDT) To: jouni.korhonen@nsn.com, Hannes.Tschofenig@gmx.net, mayutan.arumaithurai@gmail.com, mark.jones@bridgewatersystems.com, avi@bridgewatersystems.com, dromasca@avaya.com, rbonica@juniper.net, lionel.morand@orange-ftgroup.com, jouni.korhonen@nsn.com From: RFC Errata System Message-Id: <20100720031354.BF689E066E@rfc-editor.org> Date: Mon, 19 Jul 2010 20:13:54 -0700 (PDT) X-Mailman-Approved-At: Tue, 20 Jul 2010 04:41:54 -0700 Cc: francois@tera.ics.keio.ac.jp, dime@ietf.org, rfc-editor@rfc-editor.org Subject: [Dime] [Editorial Errata Reported] RFC5777 (2335) X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Jul 2010 03:13:41 -0000 The following errata report has been submitted for RFC5777, "Traffic Classification and Quality of Service (QoS) Attributes for Diameter". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=5777&eid=2335 -------------------------------------- Type: Editorial Reported by: Francois Bard Section: GLOBAL Original Text ------------- IP-Bit-Mask-Width Corrected Text -------------- IP-Mask-Bit-Mask-Width Notes ----- The original name, IP-Bit-Mask-Width, seems to have been corrupted at some point. Since the AVP is referred as IP-Mask-Bit-Mask-Width in the IANA registry, this name should be used. 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. -------------------------------------- RFC5777 (draft-ietf-dime-qos-attributes-15) -------------------------------------- Title : Traffic Classification and Quality of Service (QoS) Attributes for Diameter Publication Date : February 2010 Author(s) : J. Korhonen, H. Tschofenig, M. Arumaithurai, M. Jones, Ed., A. Lior Category : PROPOSED STANDARD Source : Diameter Maintanence and Extensions Area : Operations and Management Stream : IETF Verifying Party : IESG From wwwrun@rfc-editor.org Mon Jul 19 20:40:58 2010 Return-Path: X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1EBE03A69B3 for ; Mon, 19 Jul 2010 20:40:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.434 X-Spam-Level: X-Spam-Status: No, score=-2.434 tagged_above=-999 required=5 tests=[AWL=0.166, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tGMYr3VfYRf8 for ; Mon, 19 Jul 2010 20:40:57 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1890:1112:1::2f]) by core3.amsl.com (Postfix) with ESMTP id 3414C3A69DD for ; Mon, 19 Jul 2010 20:40:57 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 7D09DE066E; Mon, 19 Jul 2010 20:41:12 -0700 (PDT) To: jouni.korhonen@nsn.com, Hannes.Tschofenig@gmx.net, mayutan.arumaithurai@gmail.com, mark.jones@bridgewatersystems.com, avi@bridgewatersystems.com, dromasca@avaya.com, rbonica@juniper.net, lionel.morand@orange-ftgroup.com, jouni.korhonen@nsn.com From: RFC Errata System Message-Id: <20100720034112.7D09DE066E@rfc-editor.org> Date: Mon, 19 Jul 2010 20:41:12 -0700 (PDT) X-Mailman-Approved-At: Tue, 20 Jul 2010 04:41:54 -0700 Cc: francois@tera.ics.keio.ac.jp, dime@ietf.org, rfc-editor@rfc-editor.org Subject: [Dime] [Editorial Errata Reported] RFC5777 (2336) X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Jul 2010 03:40:58 -0000 The following errata report has been submitted for RFC5777, "Traffic Classification and Quality of Service (QoS) Attributes for Diameter". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=5777&eid=2336 -------------------------------------- Type: Editorial Reported by: Francois Bard Section: 4.2.8 Original Text ------------- The Absolute-Start-Fractional-Seconds AVP (AVP Code 567) is of type Unsigned32. The value specifies the fractional seconds that are added to Absolute-Start-Time value in order to determine when the time window starts. If this AVP is absent from the Time-Of-Day- Condition AVP, then the fractional seconds are assumed to be zero. Corrected Text -------------- The Absolute-Start-Fractional-Seconds AVP (AVP Code 567) is of type Unsigned32. The value specifies the fractional seconds that are added to Absolute-Start-Time value in order to determine when the time window starts. The Absolute-Start-Fractional-Seconds represent a 32-bit fraction field giving a precision of about 232 picoseconds ( 1/((2^32)-1)) seconds ). If this AVP is absent from the Time-Of-Day- Condition AVP, then the fractional seconds are assumed to be zero. See the Network Time Protocol [RFC 1305] for more precision. Notes ----- The AVP description lacked a explanation about what a fractional second is. 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. -------------------------------------- RFC5777 (draft-ietf-dime-qos-attributes-15) -------------------------------------- Title : Traffic Classification and Quality of Service (QoS) Attributes for Diameter Publication Date : February 2010 Author(s) : J. Korhonen, H. Tschofenig, M. Arumaithurai, M. Jones, Ed., A. Lior Category : PROPOSED STANDARD Source : Diameter Maintanence and Extensions Area : Operations and Management Stream : IETF Verifying Party : IESG From wwwrun@rfc-editor.org Mon Jul 19 21:27:51 2010 Return-Path: X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8217C3A6A8E for ; Mon, 19 Jul 2010 21:27:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.4 X-Spam-Level: X-Spam-Status: No, score=-2.4 tagged_above=-999 required=5 tests=[AWL=0.200, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r66XtLcBvj2T for ; Mon, 19 Jul 2010 21:27:50 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1890:1112:1::2f]) by core3.amsl.com (Postfix) with ESMTP id 6DDD83A6AFB for ; Mon, 19 Jul 2010 21:27:36 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id A61BCE066E; Mon, 19 Jul 2010 21:27:51 -0700 (PDT) To: jouni.korhonen@nsn.com, Hannes.Tschofenig@gmx.net, mayutan.arumaithurai@gmail.com, mark.jones@bridgewatersystems.com, avi@bridgewatersystems.com, dromasca@avaya.com, rbonica@juniper.net, lionel.morand@orange-ftgroup.com, jouni.korhonen@nsn.com From: RFC Errata System Message-Id: <20100720042751.A61BCE066E@rfc-editor.org> Date: Mon, 19 Jul 2010 21:27:51 -0700 (PDT) X-Mailman-Approved-At: Tue, 20 Jul 2010 04:41:54 -0700 Cc: francois@tera.ics.keio.ac.jp, dime@ietf.org, rfc-editor@rfc-editor.org Subject: [Dime] [Editorial Errata Reported] RFC5777 (2337) X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Jul 2010 04:27:51 -0000 The following errata report has been submitted for RFC5777, "Traffic Classification and Quality of Service (QoS) Attributes for Diameter". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=5777&eid=2337 -------------------------------------- Type: Editorial Reported by: Francois Bard Section: 4.2.10 Original Text ------------- The Absolute-End-Fractional-Seconds AVP (AVP Code 569) is of type Unsigned32. The value specifies the fractional seconds that are added to Absolute-End-Time value in order to determine when the time window ends. If this AVP is absent from the Time-Of-Day-Condition AVP, then the fractional seconds are assumed to be zero. Corrected Text -------------- The Absolute-Start-Fractional-Seconds AVP (AVP Code 569) is of type Unsigned32. The value specifies the fractional seconds that are added to Absolute-End-Time value in order to determine when the time window ends. The Absolute-End-Fractional-Seconds represent a 32-bit fraction field giving a precision of about 232 picoseconds ( 1/((2^32)-1)) seconds ). If this AVP is absent from the Time-Of-Day- Condition AVP, then the fractional seconds are assumed to be zero. See the Network Time Protocol [RFC 1305] for more precision. Notes ----- The AVP description lacked a explanation about what a fractional second is. 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. -------------------------------------- RFC5777 (draft-ietf-dime-qos-attributes-15) -------------------------------------- Title : Traffic Classification and Quality of Service (QoS) Attributes for Diameter Publication Date : February 2010 Author(s) : J. Korhonen, H. Tschofenig, M. Arumaithurai, M. Jones, Ed., A. Lior Category : PROPOSED STANDARD Source : Diameter Maintanence and Extensions Area : Operations and Management Stream : IETF Verifying Party : IESG From Mark.Jones@bridgewatersystems.com Tue Jul 20 05:19:44 2010 Return-Path: X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C2A823A68AF for ; Tue, 20 Jul 2010 05:19:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0npDLJdHmCXl for ; Tue, 20 Jul 2010 05:19:43 -0700 (PDT) Received: from mail201.messagelabs.com (mail201.messagelabs.com [216.82.254.211]) by core3.amsl.com (Postfix) with ESMTP id E10093A679C for ; Tue, 20 Jul 2010 05:19:42 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: Mark.Jones@bridgewatersystems.com X-Msg-Ref: server-15.tower-201.messagelabs.com!1279628397!72863730!1 X-StarScan-Version: 6.2.4; banners=-,-,- X-Originating-IP: [72.35.6.119] Received: (qmail 11517 invoked from network); 20 Jul 2010 12:19:57 -0000 Received: from mail.bridgewatersystems.com (HELO webmail.bridgewatersystems.com) (72.35.6.119) by server-15.tower-201.messagelabs.com with RC4-SHA encrypted SMTP; 20 Jul 2010 12:19:57 -0000 Received: from m679t05.fpmis.bridgewatersys.com ([10.52.81.148]) by m679t01.fpmis.bridgewatersys.com ([10.52.81.144]) with mapi; Tue, 20 Jul 2010 08:19:56 -0400 From: Mark Jones To: RFC Errata System , "jouni.korhonen@nsn.com" , "Hannes.Tschofenig@gmx.net" , "mayutan.arumaithurai@gmail.com" , Avi Lior , "dromasca@avaya.com" , "rbonica@juniper.net" , "lionel.morand@orange-ftgroup.com" , "jouni.korhonen@nsn.com" Date: Tue, 20 Jul 2010 08:19:54 -0400 Thread-Topic: [Editorial Errata Reported] RFC5777 (2333) Thread-Index: AcsnuF7O8pDNe5mvTnu0/jp/Kf5iZgATN5ZA Message-ID: References: <20100720030511.0C76AE066E@rfc-editor.org> In-Reply-To: <20100720030511.0C76AE066E@rfc-editor.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US x-exclaimer-md-config: f069778a-5a3c-4a57-aa01-0f5f3f2623e3 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Mailman-Approved-At: Tue, 20 Jul 2010 05:31:53 -0700 Cc: "francois@tera.ics.keio.ac.jp" , "dime@ietf.org" Subject: Re: [Dime] [Editorial Errata Reported] RFC5777 (2333) X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Jul 2010 12:19:44 -0000 The RFC5777 authors have discussed this errata with Francois Bard prior to = submission and agree that it should proceed to IESG verification.=20 Regards Mark > -----Original Message----- > From: RFC Errata System [mailto:rfc-editor@rfc-editor.org] > Sent: July 19, 2010 11:05 PM > To: jouni.korhonen@nsn.com; Hannes.Tschofenig@gmx.net; > mayutan.arumaithurai@gmail.com; Mark Jones; Avi Lior; > dromasca@avaya.com; rbonica@juniper.net; lionel.morand@orange- > ftgroup.com; jouni.korhonen@nsn.com > Cc: francois@tera.ics.keio.ac.jp; dime@ietf.org; rfc-editor@rfc- > editor.org > Subject: [Editorial Errata Reported] RFC5777 (2333) >=20 >=20 > The following errata report has been submitted for RFC5777, > "Traffic Classification and Quality of Service (QoS) Attributes for > Diameter". >=20 > -------------------------------------- > You may review the report below and at: > http://www.rfc-editor.org/errata_search.php?rfc=3D5777&eid=3D2333 >=20 > -------------------------------------- > Type: Editorial > Reported by: Francois Bard >=20 > Section: 4.2.1 >=20 > Original Text > ------------- > Time-Of-Day-Condition ::=3D < AVP Header: 560 > > [ Time-Of-Day-Start ] > [ Time-Of-Day-End ] > [ Day-Of-Week-Mask ] > [ Day-Of-Month-Mask ] > [ Month-Of-Year-Mask ] > [ Absolute-Start-Time ] > [ Absolute-End-Time ] > [ Timezone-Flag ] > * [ AVP ] >=20 > Corrected Text > -------------- > Time-Of-Day-Condition ::=3D < AVP Header: 560 > > [ Time-Of-Day-Start ] > [ Time-Of-Day-End ] > [ Day-Of-Week-Mask ] > [ Day-Of-Month-Mask ] > [ Month-Of-Year-Mask ] > [ Absolute-Start-Time ] > [ Absolute-Start-Fractional-Seconds ] > [ Absolute-End-Time ] > [ Absolute-End-Fractional-Seconds ] > [ Timezone-Flag ] > [ Timezone-Offset ] > * [ AVP ] >=20 > Notes > ----- > 3 AVPs are omitted in the ABNF for the Time-Of-Day-Condition AVP. >=20 > 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. >=20 > -------------------------------------- > RFC5777 (draft-ietf-dime-qos-attributes-15) > -------------------------------------- > Title : Traffic Classification and Quality of Service > (QoS) Attributes for Diameter > Publication Date : February 2010 > Author(s) : J. Korhonen, H. Tschofenig, M. Arumaithurai, M. > Jones, Ed., A. Lior > Category : PROPOSED STANDARD > Source : Diameter Maintanence and Extensions > Area : Operations and Management > Stream : IETF > Verifying Party : IESG From Mark.Jones@bridgewatersystems.com Tue Jul 20 05:19:56 2010 Return-Path: X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CC0DC3A6A05 for ; Tue, 20 Jul 2010 05:19:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sCx8SIJZLPyC for ; Tue, 20 Jul 2010 05:19:55 -0700 (PDT) Received: from mail29.messagelabs.com (mail29.messagelabs.com [216.82.249.147]) by core3.amsl.com (Postfix) with ESMTP id D70853A679C for ; Tue, 20 Jul 2010 05:19:55 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: Mark.Jones@bridgewatersystems.com X-Msg-Ref: server-12.tower-29.messagelabs.com!1279628410!25615863!1 X-StarScan-Version: 6.2.4; banners=-,-,- X-Originating-IP: [72.35.6.119] Received: (qmail 22877 invoked from network); 20 Jul 2010 12:20:11 -0000 Received: from mail.bridgewatersystems.com (HELO webmail.bridgewatersystems.com) (72.35.6.119) by server-12.tower-29.messagelabs.com with RC4-SHA encrypted SMTP; 20 Jul 2010 12:20:11 -0000 Received: from m679t05.fpmis.bridgewatersys.com ([10.52.81.148]) by m679t01.fpmis.bridgewatersys.com ([10.52.81.144]) with mapi; Tue, 20 Jul 2010 08:20:09 -0400 From: Mark Jones To: RFC Errata System , "jouni.korhonen@nsn.com" , "Hannes.Tschofenig@gmx.net" , "mayutan.arumaithurai@gmail.com" , Avi Lior , "dromasca@avaya.com" , "rbonica@juniper.net" , "lionel.morand@orange-ftgroup.com" , "jouni.korhonen@nsn.com" Date: Tue, 20 Jul 2010 08:20:07 -0400 Thread-Topic: [Editorial Errata Reported] RFC5777 (2334) Thread-Index: AcsnuN/C2OcC+/GqSleftcEHzspo7wATP71g Message-ID: References: <20100720030845.0AF09E066E@rfc-editor.org> In-Reply-To: <20100720030845.0AF09E066E@rfc-editor.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US x-exclaimer-md-config: f069778a-5a3c-4a57-aa01-0f5f3f2623e3 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Mailman-Approved-At: Tue, 20 Jul 2010 05:31:58 -0700 Cc: "francois@tera.ics.keio.ac.jp" , "dime@ietf.org" Subject: Re: [Dime] [Editorial Errata Reported] RFC5777 (2334) X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Jul 2010 12:19:56 -0000 The RFC5777 authors have discussed this errata with Francois Bard prior to = submission and agree that it should proceed to IESG verification.=20 Regards Mark > -----Original Message----- > From: RFC Errata System [mailto:rfc-editor@rfc-editor.org] > Sent: July 19, 2010 11:09 PM > To: jouni.korhonen@nsn.com; Hannes.Tschofenig@gmx.net; > mayutan.arumaithurai@gmail.com; Mark Jones; Avi Lior; > dromasca@avaya.com; rbonica@juniper.net; lionel.morand@orange- > ftgroup.com; jouni.korhonen@nsn.com > Cc: francois@tera.ics.keio.ac.jp; dime@ietf.org; rfc-editor@rfc- > editor.org > Subject: [Editorial Errata Reported] RFC5777 (2334) >=20 >=20 > The following errata report has been submitted for RFC5777, > "Traffic Classification and Quality of Service (QoS) Attributes for > Diameter". >=20 > -------------------------------------- > You may review the report below and at: > http://www.rfc-editor.org/errata_search.php?rfc=3D5777&eid=3D2334 >=20 > -------------------------------------- > Type: Editorial > Reported by: Francois Bard >=20 > Section: 10.1 >=20 > Original Text > ------------- > |Timezone-Offset 571 4.2.12 Integer32 > | > |Treatment-Action 572 5.1 Grouped > | > |QoS-Profile-Id 573 5.2 Unsigned32 > | >=20 > Corrected Text > -------------- > |Timezone-Offset 571 4.2.12 Integer32 > | > |Treatment-Action 572 5.1 Enumerated > | > |QoS-Profile-Id 573 5.2 Unsigned32 > | >=20 > Notes > ----- > The Treatment-Action AVP is of type Enumerated, as defined in 5.1 >=20 > 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. >=20 > -------------------------------------- > RFC5777 (draft-ietf-dime-qos-attributes-15) > -------------------------------------- > Title : Traffic Classification and Quality of Service > (QoS) Attributes for Diameter > Publication Date : February 2010 > Author(s) : J. Korhonen, H. Tschofenig, M. Arumaithurai, M. > Jones, Ed., A. Lior > Category : PROPOSED STANDARD > Source : Diameter Maintanence and Extensions > Area : Operations and Management > Stream : IETF > Verifying Party : IESG From Mark.Jones@bridgewatersystems.com Tue Jul 20 05:20:16 2010 Return-Path: X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 269393A6A05 for ; Tue, 20 Jul 2010 05:20:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bzPzknoiVIZR for ; Tue, 20 Jul 2010 05:20:14 -0700 (PDT) Received: from mail51.messagelabs.com (mail51.messagelabs.com [216.82.241.99]) by core3.amsl.com (Postfix) with ESMTP id 670D53A6A46 for ; Tue, 20 Jul 2010 05:20:14 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: Mark.Jones@bridgewatersystems.com X-Msg-Ref: server-13.tower-51.messagelabs.com!1279628429!52031712!1 X-StarScan-Version: 6.2.4; banners=-,-,- X-Originating-IP: [72.35.6.119] Received: (qmail 2627 invoked from network); 20 Jul 2010 12:20:29 -0000 Received: from mail.bridgewatersystems.com (HELO webmail.bridgewatersystems.com) (72.35.6.119) by server-13.tower-51.messagelabs.com with RC4-SHA encrypted SMTP; 20 Jul 2010 12:20:29 -0000 Received: from m679t05.fpmis.bridgewatersys.com ([10.52.81.148]) by m679t01.fpmis.bridgewatersys.com ([10.52.81.144]) with mapi; Tue, 20 Jul 2010 08:20:28 -0400 From: Mark Jones To: RFC Errata System , "jouni.korhonen@nsn.com" , "Hannes.Tschofenig@gmx.net" , "mayutan.arumaithurai@gmail.com" , Avi Lior , "dromasca@avaya.com" , "rbonica@juniper.net" , "lionel.morand@orange-ftgroup.com" , "jouni.korhonen@nsn.com" Date: Tue, 20 Jul 2010 08:20:27 -0400 Thread-Topic: [Editorial Errata Reported] RFC5777 (2335) Thread-Index: AcsnuZaO3LBeZU4vQQaUSFPuPWkFiQATFCeg Message-ID: References: <20100720031354.BF689E066E@rfc-editor.org> In-Reply-To: <20100720031354.BF689E066E@rfc-editor.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US x-exclaimer-md-config: f069778a-5a3c-4a57-aa01-0f5f3f2623e3 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Mailman-Approved-At: Tue, 20 Jul 2010 05:31:58 -0700 Cc: "francois@tera.ics.keio.ac.jp" , "dime@ietf.org" Subject: Re: [Dime] [Editorial Errata Reported] RFC5777 (2335) X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Jul 2010 12:20:16 -0000 The RFC5777 authors have discussed this errata with Francois Bard prior to = submission and agree that it should proceed to IESG verification.=20 Regards Mark > -----Original Message----- > From: RFC Errata System [mailto:rfc-editor@rfc-editor.org] > Sent: July 19, 2010 11:14 PM > To: jouni.korhonen@nsn.com; Hannes.Tschofenig@gmx.net; > mayutan.arumaithurai@gmail.com; Mark Jones; Avi Lior; > dromasca@avaya.com; rbonica@juniper.net; lionel.morand@orange- > ftgroup.com; jouni.korhonen@nsn.com > Cc: francois@tera.ics.keio.ac.jp; dime@ietf.org; rfc-editor@rfc- > editor.org > Subject: [Editorial Errata Reported] RFC5777 (2335) >=20 >=20 > The following errata report has been submitted for RFC5777, > "Traffic Classification and Quality of Service (QoS) Attributes for > Diameter". >=20 > -------------------------------------- > You may review the report below and at: > http://www.rfc-editor.org/errata_search.php?rfc=3D5777&eid=3D2335 >=20 > -------------------------------------- > Type: Editorial > Reported by: Francois Bard >=20 > Section: GLOBAL >=20 > Original Text > ------------- > IP-Bit-Mask-Width >=20 > Corrected Text > -------------- > IP-Mask-Bit-Mask-Width >=20 > Notes > ----- > The original name, IP-Bit-Mask-Width, seems to have been corrupted at > some point. Since the AVP is referred as IP-Mask-Bit-Mask-Width in the > IANA registry, this name should be used. >=20 > 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. >=20 > -------------------------------------- > RFC5777 (draft-ietf-dime-qos-attributes-15) > -------------------------------------- > Title : Traffic Classification and Quality of Service > (QoS) Attributes for Diameter > Publication Date : February 2010 > Author(s) : J. Korhonen, H. Tschofenig, M. Arumaithurai, M. > Jones, Ed., A. Lior > Category : PROPOSED STANDARD > Source : Diameter Maintanence and Extensions > Area : Operations and Management > Stream : IETF > Verifying Party : IESG From jouni.nospam@gmail.com Wed Jul 21 03:09:08 2010 Return-Path: X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 03BAE3A6BB1 for ; Wed, 21 Jul 2010 03: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=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CTqcfdqgU09p for ; Wed, 21 Jul 2010 03:09:06 -0700 (PDT) Received: from mail-bw0-f44.google.com (mail-bw0-f44.google.com [209.85.214.44]) by core3.amsl.com (Postfix) with ESMTP id 5688D3A6B8D for ; Wed, 21 Jul 2010 03:09:06 -0700 (PDT) Received: by bwz7 with SMTP id 7so56238bwz.31 for ; Wed, 21 Jul 2010 03:09:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:from:content-type :content-transfer-encoding:subject:date:message-id:to:mime-version :x-mailer; bh=GhHuRtklf+nBHRzaq6syFdPz9A13tQFjfXMBQQnCnEo=; b=Si4keA0BC+tzvaew2wb8LRLbMKrt1D6c1DQinoWa4FXVx/lZumSoxS4t6izDUy8X9a pbaPcorrzBABmXFUyR7K2hyzPRkvorR15BOkFuhPdhsGvecLYhO010bWZnRgjlA+QFEA bS38IiNUozJdoRNt7PQ0TF6wLrJC4MH85nN2c= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:content-type:content-transfer-encoding:subject:date:message-id :to:mime-version:x-mailer; b=FhENgRZq2ppEZ0JFQYz94GEbjY1fkjqxEbD9X7lMmkM9DJRBwEtz1vsGmLgtcoRAlf C9qNsWnyopGiCNJcbJTDmfdPm30tKiYSWZEK/1rMwg8Vy4h08RtkXlYf7UbjeprSffje kh9meuVlTka+GKIen8ho5Z3UxRvsnbz7/OsDE= Received: by 10.204.25.151 with SMTP id z23mr1492847bkb.46.1279706958360; Wed, 21 Jul 2010 03:09:18 -0700 (PDT) Received: from a88-114-171-65.elisa-laajakaista.fi (a88-114-171-65.elisa-laajakaista.fi [88.114.171.65]) by mx.google.com with ESMTPS id a9sm28943848bky.23.2010.07.21.03.09.17 (version=TLSv1/SSLv3 cipher=RC4-MD5); Wed, 21 Jul 2010 03:09:17 -0700 (PDT) From: jouni korhonen Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Wed, 21 Jul 2010 13:09:16 +0300 Message-Id: To: dime@ietf.org Mime-Version: 1.0 (Apple Message framework v1078) X-Mailer: Apple Mail (2.1078) Subject: [Dime] DIME agenda X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Jul 2010 10:09:08 -0000 The latest agenda (update) can be found at: http://www.ietf.org/proceedings/78/agenda/dime.txt - Jouni From jouni.nospam@gmail.com Wed Jul 21 05:41:56 2010 Return-Path: X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D2C1F3A689D for ; Wed, 21 Jul 2010 05:41:56 -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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kkyEOKfPMaTd for ; Wed, 21 Jul 2010 05:41:55 -0700 (PDT) Received: from mail-bw0-f44.google.com (mail-bw0-f44.google.com [209.85.214.44]) by core3.amsl.com (Postfix) with ESMTP id 8C7EA3A6A18 for ; Wed, 21 Jul 2010 05:41:55 -0700 (PDT) Received: by bwz7 with SMTP id 7so144601bwz.31 for ; Wed, 21 Jul 2010 05:42:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:from:content-type :content-transfer-encoding:subject:date:message-id:to:mime-version :x-mailer; bh=/GbcY+wbSbHtP+G27LMSyuvL+5uo6dkwy1wxkrrcUqo=; b=NYDzGNSHPPz1T6evAPNFAlmsoZDrayBjPPRNxfsiiAebfY8V99EGK/IZM6AUGut8BI jWU6gSHwTsr/dRiKF3rMsLwocxhdBUU9IIyx6Nec1MHrog9CZyjZDCMk5xhjX0njGXPs VjMNgnTf1u1AbUaEiVZCx/r3Au0aGBAZRIGcs= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:content-type:content-transfer-encoding:subject:date:message-id :to:mime-version:x-mailer; b=xeZyFBulo6HoMTKGHpPkD0x6GXPekqapak/gnU1JkIshdQ8oz8BcyB3mCIsV3LtCXx bIGEgZP6lCC6OPfJWOjFQjKVQR36d1Cu6KaEUxmVhEPLifHoxx6Ux06CiIpDVkfpflPI 7t13q8F5Bypb6xetbUbfV9k72qTlDDjr+Lu4Q= Received: by 10.204.142.205 with SMTP id r13mr44114bku.207.1279716128377; Wed, 21 Jul 2010 05:42:08 -0700 (PDT) Received: from a88-114-171-65.elisa-laajakaista.fi (a88-114-171-65.elisa-laajakaista.fi [88.114.171.65]) by mx.google.com with ESMTPS id g11sm29063059bkw.22.2010.07.21.05.42.07 (version=TLSv1/SSLv3 cipher=RC4-MD5); Wed, 21 Jul 2010 05:42:08 -0700 (PDT) From: jouni korhonen Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Wed, 21 Jul 2010 15:42:06 +0300 Message-Id: <92BBD1AA-5740-4057-85C7-66D16018FCA5@gmail.com> To: dime@ietf.org Mime-Version: 1.0 (Apple Message framework v1078) X-Mailer: Apple Mail (2.1078) Subject: [Dime] last review of RFC3588bis before the proto write-up - please comment X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Jul 2010 12:41:56 -0000 Hello all, [in chair mode] During the process of writing the Proto Write-up for = draft-ietf-dime-rfc3588bis-21.txt I made my last review to the document. = I started to think few points that might still need some input from the = WG.. sorry. Purely editorial, could be done during AUTH48 o Section 5.2 step 2. gives an impression that only NAPTR flag "s" is = supported. However, this is not the case according to the referenced S-NAPTR = RFC3958. We did "fix" this in one place i.e. examples in Appendix B. where "a" = flags use is also illustrated. I would add a note regarding "a" flag to the = Section 5.2.=20 o Section 11.5 should explicitly mention the TLS/TCP port number here = (before IANA actions marked as TBD like the rest of the document does). o (suggested by David L.) In Section 3 add a note that the message = length is always a multiple of 4. For the following I must to hear comments _before_ I proceed with the = completion of the Proto Write-up: o RFC3588bis keeps version as 1 so a RFC3588 node does not really know = if it is=20 connecting with another RFC3588 or RFC3588bis node, or vice versa. In = Sections 5.4.1, 5.4.2, 5.5.1, 5.5.2, and 7.2 we actually _change_ the existing = command ABNFs that are more than just adding optional AVPs or sending less = AVPs than before (for example adding *[AVP] to a request, which means the = receiver may see AVPs that are beyond the ABNF it knows). According to the = RFC3588bis Section 1.3.3 this could mean an allocation of a new command code, = which again would require an allocation of a new application id for applications = using the new command.. This would impact backwards compatibility with RFC3588. Can we expect then receiving errors like 5008 and 5009 when the other = end is fully RFC3588 compliant and the other is RFC3588bis compliant? Is = this unlikely to happen? Can a change to AVP multiplicity in ABNF considered such = ABNF change that requires a new command code? - Jouni= From Mark.Jones@bridgewatersystems.com Tue Jul 20 05:35:00 2010 Return-Path: X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C9DB43A6BFA for ; Tue, 20 Jul 2010 05:34:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gfvpkAABHfU7 for ; Tue, 20 Jul 2010 05:33:46 -0700 (PDT) Received: from mail200.messagelabs.com (mail200.messagelabs.com [216.82.254.195]) by core3.amsl.com (Postfix) with ESMTP id CFCF23A6C61 for ; Tue, 20 Jul 2010 05:32:35 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: Mark.Jones@bridgewatersystems.com X-Msg-Ref: server-9.tower-200.messagelabs.com!1279629158!54608949!1 X-StarScan-Version: 6.2.4; banners=-,-,- X-Originating-IP: [72.35.6.119] Received: (qmail 26157 invoked from network); 20 Jul 2010 12:32:38 -0000 Received: from mail.bridgewatersystems.com (HELO webmail.bridgewatersystems.com) (72.35.6.119) by server-9.tower-200.messagelabs.com with RC4-SHA encrypted SMTP; 20 Jul 2010 12:32:38 -0000 Received: from m679t05.fpmis.bridgewatersys.com ([10.52.81.148]) by m679t01.fpmis.bridgewatersys.com ([10.52.81.144]) with mapi; Tue, 20 Jul 2010 08:32:35 -0400 From: Mark Jones To: RFC Errata System , "jouni.korhonen@nsn.com" , "Hannes.Tschofenig@gmx.net" , "mayutan.arumaithurai@gmail.com" , Avi Lior , "dromasca@avaya.com" , "rbonica@juniper.net" , "lionel.morand@orange-ftgroup.com" , "jouni.korhonen@nsn.com" Date: Tue, 20 Jul 2010 08:32:33 -0400 Thread-Topic: [Editorial Errata Reported] RFC5777 (2336) Thread-Index: AcsnvWe6GUSyyN/gQUWhfz9EPkW3SQASIxYQ Message-ID: References: <20100720034112.7D09DE066E@rfc-editor.org> In-Reply-To: <20100720034112.7D09DE066E@rfc-editor.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US x-exclaimer-md-config: f069778a-5a3c-4a57-aa01-0f5f3f2623e3 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Mailman-Approved-At: Wed, 21 Jul 2010 23:44:37 -0700 Cc: "francois@tera.ics.keio.ac.jp" , "dime@ietf.org" Subject: Re: [Dime] [Editorial Errata Reported] RFC5777 (2336) X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Jul 2010 12:35:00 -0000 The RFC5777 authors have discussed this errata with Francois Bard prior to = submission and agree that it should proceed to IESG verification.=20 Regards Mark > -----Original Message----- > From: RFC Errata System [mailto:rfc-editor@rfc-editor.org] > Sent: July 19, 2010 11:41 PM > To: jouni.korhonen@nsn.com; Hannes.Tschofenig@gmx.net; > mayutan.arumaithurai@gmail.com; Mark Jones; Avi Lior; > dromasca@avaya.com; rbonica@juniper.net; lionel.morand@orange- > ftgroup.com; jouni.korhonen@nsn.com > Cc: francois@tera.ics.keio.ac.jp; dime@ietf.org; rfc-editor@rfc- > editor.org > Subject: [Editorial Errata Reported] RFC5777 (2336) >=20 >=20 > The following errata report has been submitted for RFC5777, > "Traffic Classification and Quality of Service (QoS) Attributes for > Diameter". >=20 > -------------------------------------- > You may review the report below and at: > http://www.rfc-editor.org/errata_search.php?rfc=3D5777&eid=3D2336 >=20 > -------------------------------------- > Type: Editorial > Reported by: Francois Bard >=20 > Section: 4.2.8 >=20 > Original Text > ------------- > The Absolute-Start-Fractional-Seconds AVP (AVP Code 567) is of type > Unsigned32. The value specifies the fractional seconds that are > added to Absolute-Start-Time value in order to determine when the > time window starts. If this AVP is absent from the Time-Of-Day- > Condition AVP, then the fractional seconds are assumed to be zero. >=20 > Corrected Text > -------------- > The Absolute-Start-Fractional-Seconds AVP (AVP Code 567) is of type > Unsigned32. The value specifies the fractional seconds that are > added to Absolute-Start-Time value in order to determine when the > time window starts. The Absolute-Start-Fractional-Seconds represent > a 32-bit fraction field giving a precision of about 232 picoseconds > ( 1/((2^32)-1)) seconds ). If this AVP is absent from the Time-Of-Day- > Condition AVP, then the fractional seconds are assumed to be zero. > See the Network Time Protocol [RFC 1305] for more precision. >=20 > Notes > ----- > The AVP description lacked a explanation about what a fractional second > is. >=20 > 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. >=20 > -------------------------------------- > RFC5777 (draft-ietf-dime-qos-attributes-15) > -------------------------------------- > Title : Traffic Classification and Quality of Service > (QoS) Attributes for Diameter > Publication Date : February 2010 > Author(s) : J. Korhonen, H. Tschofenig, M. Arumaithurai, M. > Jones, Ed., A. Lior > Category : PROPOSED STANDARD > Source : Diameter Maintanence and Extensions > Area : Operations and Management > Stream : IETF > Verifying Party : IESG From Mark.Jones@bridgewatersystems.com Tue Jul 20 05:38:06 2010 Return-Path: X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C2CB63A6C00 for ; Tue, 20 Jul 2010 05:38:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q9mIqBoXQQmn for ; Tue, 20 Jul 2010 05:38:04 -0700 (PDT) Received: from mail200.messagelabs.com (mail200.messagelabs.com [216.82.254.195]) by core3.amsl.com (Postfix) with ESMTP id 32F693A6C07 for ; Tue, 20 Jul 2010 05:37:15 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: Mark.Jones@bridgewatersystems.com X-Msg-Ref: server-3.tower-200.messagelabs.com!1279629417!42600757!1 X-StarScan-Version: 6.2.4; banners=-,-,- X-Originating-IP: [72.35.6.119] Received: (qmail 20303 invoked from network); 20 Jul 2010 12:36:57 -0000 Received: from mail.bridgewatersystems.com (HELO webmail.bridgewatersystems.com) (72.35.6.119) by server-3.tower-200.messagelabs.com with RC4-SHA encrypted SMTP; 20 Jul 2010 12:36:57 -0000 Received: from m679t05.fpmis.bridgewatersys.com ([10.52.81.148]) by m679t01.fpmis.bridgewatersys.com ([10.52.81.144]) with mapi; Tue, 20 Jul 2010 08:36:56 -0400 From: Mark Jones To: RFC Errata System , "jouni.korhonen@nsn.com" , "Hannes.Tschofenig@gmx.net" , "mayutan.arumaithurai@gmail.com" , Avi Lior , "dromasca@avaya.com" , "rbonica@juniper.net" , "lionel.morand@orange-ftgroup.com" , "jouni.korhonen@nsn.com" Date: Tue, 20 Jul 2010 08:36:55 -0400 Thread-Topic: [Editorial Errata Reported] RFC5777 (2337) Thread-Index: Acsnw+ulQwrFrqVCQM+ze2fORLP79QAQ8H/Q Message-ID: References: <20100720042751.A61BCE066E@rfc-editor.org> In-Reply-To: <20100720042751.A61BCE066E@rfc-editor.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US x-exclaimer-md-config: f069778a-5a3c-4a57-aa01-0f5f3f2623e3 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Mailman-Approved-At: Wed, 21 Jul 2010 23:44:37 -0700 Cc: "francois@tera.ics.keio.ac.jp" , "dime@ietf.org" Subject: Re: [Dime] [Editorial Errata Reported] RFC5777 (2337) X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Jul 2010 12:38:06 -0000 The RFC5777 authors have discussed this errata with Francois Bard prior to = submission. However, there is a typo in the first sentence of the proposed corrected te= xt: "Absolute-Start-Fractional-Seconds" should read "Absolute-End-Fractiona= l-Seconds". With this correction, we agree that it should proceed to IESG verification. Regards Mark > -----Original Message----- > From: RFC Errata System [mailto:rfc-editor@rfc-editor.org] > Sent: July 20, 2010 12:28 AM > To: jouni.korhonen@nsn.com; Hannes.Tschofenig@gmx.net; > mayutan.arumaithurai@gmail.com; Mark Jones; Avi Lior; > dromasca@avaya.com; rbonica@juniper.net; lionel.morand@orange- > ftgroup.com; jouni.korhonen@nsn.com > Cc: francois@tera.ics.keio.ac.jp; dime@ietf.org; rfc-editor@rfc- > editor.org > Subject: [Editorial Errata Reported] RFC5777 (2337) >=20 >=20 > The following errata report has been submitted for RFC5777, > "Traffic Classification and Quality of Service (QoS) Attributes for > Diameter". >=20 > -------------------------------------- > You may review the report below and at: > http://www.rfc-editor.org/errata_search.php?rfc=3D5777&eid=3D2337 >=20 > -------------------------------------- > Type: Editorial > Reported by: Francois Bard >=20 > Section: 4.2.10 >=20 > Original Text > ------------- > The Absolute-End-Fractional-Seconds AVP (AVP Code 569) is of type > Unsigned32. The value specifies the fractional seconds that are > added to Absolute-End-Time value in order to determine when the time > window ends. If this AVP is absent from the Time-Of-Day-Condition > AVP, then the fractional seconds are assumed to be zero. >=20 > Corrected Text > -------------- > The Absolute-Start-Fractional-Seconds AVP (AVP Code 569) is of type > Unsigned32. The value specifies the fractional seconds that are > added to Absolute-End-Time value in order to determine when the time > window ends. The Absolute-End-Fractional-Seconds represent > a 32-bit fraction field giving a precision of about 232 picoseconds > ( 1/((2^32)-1)) seconds ). If this AVP is absent from the Time-Of-Day- > Condition AVP, then the fractional seconds are assumed to be zero. > See the Network Time Protocol [RFC 1305] for more precision. >=20 > Notes > ----- > The AVP description lacked a explanation about what a fractional second > is. >=20 > 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. >=20 > -------------------------------------- > RFC5777 (draft-ietf-dime-qos-attributes-15) > -------------------------------------- > Title : Traffic Classification and Quality of Service > (QoS) Attributes for Diameter > Publication Date : February 2010 > Author(s) : J. Korhonen, H. Tschofenig, M. Arumaithurai, M. > Jones, Ed., A. Lior > Category : PROPOSED STANDARD > Source : Diameter Maintanence and Extensions > Area : Operations and Management > Stream : IETF > Verifying Party : IESG From jouni.korhonen@nsn.com Wed Jul 21 23:36:36 2010 Return-Path: X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F0BD83A68F1 for ; Wed, 21 Jul 2010 23:36:35 -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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kyuDp-ozvAuo for ; Wed, 21 Jul 2010 23:36:34 -0700 (PDT) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [93.183.12.32]) by core3.amsl.com (Postfix) with ESMTP id 3CBE33A6783 for ; Wed, 21 Jul 2010 23:36:34 -0700 (PDT) Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd001.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id o6M6aiWa006941; Thu, 22 Jul 2010 08:36:44 +0200 Received: from demuexc022.nsn-intra.net (demuexc022.nsn-intra.net [10.150.128.35]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id o6M6ae0U001947; Thu, 22 Jul 2010 08:36:41 +0200 Received: from FIESEXC035.nsn-intra.net ([10.159.0.25]) by demuexc022.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.4675); Thu, 22 Jul 2010 08:36:39 +0200 Received: from 10.144.225.109 ([10.144.225.109]) by FIESEXC035.nsn-intra.net ([10.159.0.182]) via Exchange Front-End Server 10.150.128.35 ([10.150.128.35]) with Microsoft Exchange Server HTTP-DAV ; Thu, 22 Jul 2010 06:36:38 +0000 User-Agent: Microsoft-Entourage/12.25.0.100505 Date: Thu, 22 Jul 2010 09:36:37 +0300 From: Jouni Korhonen To: ext Mark Jones , RFC Errata System , "Hannes.Tschofenig@gmx.net" , "mayutan.arumaithurai@gmail.com" , Avi Lior , "dromasca@avaya.com" , "rbonica@juniper.net" , "lionel.morand@orange-ftgroup.com" Message-ID: Thread-Topic: [Editorial Errata Reported] RFC5777 (2333) Thread-Index: AcsnuF7O8pDNe5mvTnu0/jp/Kf5iZgATN5ZAAFi/tW0= In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 22 Jul 2010 06:36:39.0475 (UTC) FILETIME=[3D773030:01CB2968] X-Mailman-Approved-At: Wed, 21 Jul 2010 23:44:35 -0700 Cc: "francois@tera.ics.keio.ac.jp" , "dime@ietf.org" Subject: Re: [Dime] [Editorial Errata Reported] RFC5777 (2333) X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Jul 2010 06:36:36 -0000 >From a Dime co-chair point of view I agree with the errata #2333. - Jouni On 7/20/10 3:19 PM, "ext Mark Jones" wrote: > The RFC5777 authors have discussed this errata with Francois Bard prior to > submission and agree that it should proceed to IESG verification. > > Regards > Mark > >> -----Original Message----- >> From: RFC Errata System [mailto:rfc-editor@rfc-editor.org] >> Sent: July 19, 2010 11:05 PM >> To: jouni.korhonen@nsn.com; Hannes.Tschofenig@gmx.net; >> mayutan.arumaithurai@gmail.com; Mark Jones; Avi Lior; >> dromasca@avaya.com; rbonica@juniper.net; lionel.morand@orange- >> ftgroup.com; jouni.korhonen@nsn.com >> Cc: francois@tera.ics.keio.ac.jp; dime@ietf.org; rfc-editor@rfc- >> editor.org >> Subject: [Editorial Errata Reported] RFC5777 (2333) >> >> >> The following errata report has been submitted for RFC5777, >> "Traffic Classification and Quality of Service (QoS) Attributes for >> Diameter". >> >> -------------------------------------- >> You may review the report below and at: >> http://www.rfc-editor.org/errata_search.php?rfc=5777&eid=2333 >> >> -------------------------------------- >> Type: Editorial >> Reported by: Francois Bard >> >> Section: 4.2.1 >> >> Original Text >> ------------- >> Time-Of-Day-Condition ::= < AVP Header: 560 > >> [ Time-Of-Day-Start ] >> [ Time-Of-Day-End ] >> [ Day-Of-Week-Mask ] >> [ Day-Of-Month-Mask ] >> [ Month-Of-Year-Mask ] >> [ Absolute-Start-Time ] >> [ Absolute-End-Time ] >> [ Timezone-Flag ] >> * [ AVP ] >> >> Corrected Text >> -------------- >> Time-Of-Day-Condition ::= < AVP Header: 560 > >> [ Time-Of-Day-Start ] >> [ Time-Of-Day-End ] >> [ Day-Of-Week-Mask ] >> [ Day-Of-Month-Mask ] >> [ Month-Of-Year-Mask ] >> [ Absolute-Start-Time ] >> [ Absolute-Start-Fractional-Seconds ] >> [ Absolute-End-Time ] >> [ Absolute-End-Fractional-Seconds ] >> [ Timezone-Flag ] >> [ Timezone-Offset ] >> * [ AVP ] >> >> Notes >> ----- >> 3 AVPs are omitted in the ABNF for the Time-Of-Day-Condition AVP. >> >> 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. >> >> -------------------------------------- >> RFC5777 (draft-ietf-dime-qos-attributes-15) >> -------------------------------------- >> Title : Traffic Classification and Quality of Service >> (QoS) Attributes for Diameter >> Publication Date : February 2010 >> Author(s) : J. Korhonen, H. Tschofenig, M. Arumaithurai, M. >> Jones, Ed., A. Lior >> Category : PROPOSED STANDARD >> Source : Diameter Maintanence and Extensions >> Area : Operations and Management >> Stream : IETF >> Verifying Party : IESG From jouni.korhonen@nsn.com Wed Jul 21 23:36:58 2010 Return-Path: X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0F0173A68A2 for ; Wed, 21 Jul 2010 23:36:58 -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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GMwqF+LK7gk9 for ; Wed, 21 Jul 2010 23:36:55 -0700 (PDT) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [93.183.12.31]) by core3.amsl.com (Postfix) with ESMTP id 61BAB3A6897 for ; Wed, 21 Jul 2010 23:36:55 -0700 (PDT) Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd002.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id o6M6b6Y4008456; Thu, 22 Jul 2010 08:37:06 +0200 Received: from demuexc022.nsn-intra.net (demuexc022.nsn-intra.net [10.150.128.35]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id o6M6b4fP029949; Thu, 22 Jul 2010 08:37:05 +0200 Received: from FIESEXC035.nsn-intra.net ([10.159.0.25]) by demuexc022.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.4675); Thu, 22 Jul 2010 08:37:04 +0200 Received: from 10.144.225.109 ([10.144.225.109]) by FIESEXC035.nsn-intra.net ([10.159.0.182]) via Exchange Front-End Server 10.150.128.35 ([10.150.128.35]) with Microsoft Exchange Server HTTP-DAV ; Thu, 22 Jul 2010 06:37:03 +0000 User-Agent: Microsoft-Entourage/12.25.0.100505 Date: Thu, 22 Jul 2010 09:37:03 +0300 From: Jouni Korhonen To: ext Mark Jones , RFC Errata System , "Hannes.Tschofenig@gmx.net" , "mayutan.arumaithurai@gmail.com" , Avi Lior , "dromasca@avaya.com" , "rbonica@juniper.net" , "lionel.morand@orange-ftgroup.com" Message-ID: Thread-Topic: [Editorial Errata Reported] RFC5777 (2335) Thread-Index: AcsnuZaO3LBeZU4vQQaUSFPuPWkFiQATFCegAFiZFGw= In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 22 Jul 2010 06:37:04.0850 (UTC) FILETIME=[4C971B20:01CB2968] X-Mailman-Approved-At: Wed, 21 Jul 2010 23:44:35 -0700 Cc: "francois@tera.ics.keio.ac.jp" , "dime@ietf.org" Subject: Re: [Dime] [Editorial Errata Reported] RFC5777 (2335) X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Jul 2010 06:36:58 -0000 >From a Dime co-chair point of view I agree with the errata #2335. - Jouni On 7/20/10 3:20 PM, "ext Mark Jones" wrote: > The RFC5777 authors have discussed this errata with Francois Bard prior to > submission and agree that it should proceed to IESG verification. > > Regards > Mark > >> -----Original Message----- >> From: RFC Errata System [mailto:rfc-editor@rfc-editor.org] >> Sent: July 19, 2010 11:14 PM >> To: jouni.korhonen@nsn.com; Hannes.Tschofenig@gmx.net; >> mayutan.arumaithurai@gmail.com; Mark Jones; Avi Lior; >> dromasca@avaya.com; rbonica@juniper.net; lionel.morand@orange- >> ftgroup.com; jouni.korhonen@nsn.com >> Cc: francois@tera.ics.keio.ac.jp; dime@ietf.org; rfc-editor@rfc- >> editor.org >> Subject: [Editorial Errata Reported] RFC5777 (2335) >> >> >> The following errata report has been submitted for RFC5777, >> "Traffic Classification and Quality of Service (QoS) Attributes for >> Diameter". >> >> -------------------------------------- >> You may review the report below and at: >> http://www.rfc-editor.org/errata_search.php?rfc=5777&eid=2335 >> >> -------------------------------------- >> Type: Editorial >> Reported by: Francois Bard >> >> Section: GLOBAL >> >> Original Text >> ------------- >> IP-Bit-Mask-Width >> >> Corrected Text >> -------------- >> IP-Mask-Bit-Mask-Width >> >> Notes >> ----- >> The original name, IP-Bit-Mask-Width, seems to have been corrupted at >> some point. Since the AVP is referred as IP-Mask-Bit-Mask-Width in the >> IANA registry, this name should be used. >> >> 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. >> >> -------------------------------------- >> RFC5777 (draft-ietf-dime-qos-attributes-15) >> -------------------------------------- >> Title : Traffic Classification and Quality of Service >> (QoS) Attributes for Diameter >> Publication Date : February 2010 >> Author(s) : J. Korhonen, H. Tschofenig, M. Arumaithurai, M. >> Jones, Ed., A. Lior >> Category : PROPOSED STANDARD >> Source : Diameter Maintanence and Extensions >> Area : Operations and Management >> Stream : IETF >> Verifying Party : IESG From jouni.korhonen@nsn.com Wed Jul 21 23:37:02 2010 Return-Path: X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4DDE53A68F1 for ; Wed, 21 Jul 2010 23:37:02 -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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id buak+aB1Xg1i for ; Wed, 21 Jul 2010 23:37:01 -0700 (PDT) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [93.183.12.31]) by core3.amsl.com (Postfix) with ESMTP id 6103B3A68A2 for ; Wed, 21 Jul 2010 23:37:00 -0700 (PDT) Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd002.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id o6M6b9Kw008535; Thu, 22 Jul 2010 08:37:09 +0200 Received: from demuexc023.nsn-intra.net (demuexc023.nsn-intra.net [10.150.128.36]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id o6M6b9Zr030110; Thu, 22 Jul 2010 08:37:09 +0200 Received: from FIESEXC035.nsn-intra.net ([10.159.0.25]) by demuexc023.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.4675); Thu, 22 Jul 2010 08:36:54 +0200 Received: from 10.144.225.109 ([10.144.225.109]) by FIESEXC035.nsn-intra.net ([10.159.0.182]) via Exchange Front-End Server 10.150.128.35 ([10.150.128.35]) with Microsoft Exchange Server HTTP-DAV ; Thu, 22 Jul 2010 06:36:54 +0000 User-Agent: Microsoft-Entourage/12.25.0.100505 Date: Thu, 22 Jul 2010 09:36:51 +0300 From: Jouni Korhonen To: ext Mark Jones , RFC Errata System , "Hannes.Tschofenig@gmx.net" , "mayutan.arumaithurai@gmail.com" , Avi Lior , "dromasca@avaya.com" , "rbonica@juniper.net" , "lionel.morand@orange-ftgroup.com" Message-ID: Thread-Topic: [Editorial Errata Reported] RFC5777 (2334) Thread-Index: AcsnuN/C2OcC+/GqSleftcEHzspo7wATP71gAFiZZ64= In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 22 Jul 2010 06:36:54.0942 (UTC) FILETIME=[46AF43E0:01CB2968] X-Mailman-Approved-At: Wed, 21 Jul 2010 23:44:35 -0700 Cc: "francois@tera.ics.keio.ac.jp" , "dime@ietf.org" Subject: Re: [Dime] [Editorial Errata Reported] RFC5777 (2334) X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Jul 2010 06:37:02 -0000 >From a Dime co-chair point of view I agree with the errata #2334. - Jouni On 7/20/10 3:20 PM, "ext Mark Jones" wrote: > The RFC5777 authors have discussed this errata with Francois Bard prior to > submission and agree that it should proceed to IESG verification. > > Regards > Mark > >> -----Original Message----- >> From: RFC Errata System [mailto:rfc-editor@rfc-editor.org] >> Sent: July 19, 2010 11:09 PM >> To: jouni.korhonen@nsn.com; Hannes.Tschofenig@gmx.net; >> mayutan.arumaithurai@gmail.com; Mark Jones; Avi Lior; >> dromasca@avaya.com; rbonica@juniper.net; lionel.morand@orange- >> ftgroup.com; jouni.korhonen@nsn.com >> Cc: francois@tera.ics.keio.ac.jp; dime@ietf.org; rfc-editor@rfc- >> editor.org >> Subject: [Editorial Errata Reported] RFC5777 (2334) >> >> >> The following errata report has been submitted for RFC5777, >> "Traffic Classification and Quality of Service (QoS) Attributes for >> Diameter". >> >> -------------------------------------- >> You may review the report below and at: >> http://www.rfc-editor.org/errata_search.php?rfc=5777&eid=2334 >> >> -------------------------------------- >> Type: Editorial >> Reported by: Francois Bard >> >> Section: 10.1 >> >> Original Text >> ------------- >> |Timezone-Offset 571 4.2.12 Integer32 >> | >> |Treatment-Action 572 5.1 Grouped >> | >> |QoS-Profile-Id 573 5.2 Unsigned32 >> | >> >> Corrected Text >> -------------- >> |Timezone-Offset 571 4.2.12 Integer32 >> | >> |Treatment-Action 572 5.1 Enumerated >> | >> |QoS-Profile-Id 573 5.2 Unsigned32 >> | >> >> Notes >> ----- >> The Treatment-Action AVP is of type Enumerated, as defined in 5.1 >> >> 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. >> >> -------------------------------------- >> RFC5777 (draft-ietf-dime-qos-attributes-15) >> -------------------------------------- >> Title : Traffic Classification and Quality of Service >> (QoS) Attributes for Diameter >> Publication Date : February 2010 >> Author(s) : J. Korhonen, H. Tschofenig, M. Arumaithurai, M. >> Jones, Ed., A. Lior >> Category : PROPOSED STANDARD >> Source : Diameter Maintanence and Extensions >> Area : Operations and Management >> Stream : IETF >> Verifying Party : IESG From jouni.korhonen@nsn.com Wed Jul 21 23:37:16 2010 Return-Path: X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B86D03A6783 for ; Wed, 21 Jul 2010 23:37:16 -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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r2-y6ROAo6Vl for ; Wed, 21 Jul 2010 23:37:15 -0700 (PDT) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [93.183.12.32]) by core3.amsl.com (Postfix) with ESMTP id 0B78C3A6897 for ; Wed, 21 Jul 2010 23:37:14 -0700 (PDT) Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd001.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id o6M6bQT7008351; Thu, 22 Jul 2010 08:37:26 +0200 Received: from demuexc022.nsn-intra.net (demuexc022.nsn-intra.net [10.150.128.35]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id o6M6bO16003799; Thu, 22 Jul 2010 08:37:26 +0200 Received: from FIESEXC035.nsn-intra.net ([10.159.0.25]) by demuexc022.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.4675); Thu, 22 Jul 2010 08:37:23 +0200 Received: from 10.144.225.109 ([10.144.225.109]) by FIESEXC035.nsn-intra.net ([10.159.0.182]) via Exchange Front-End Server 10.150.128.35 ([10.150.128.35]) with Microsoft Exchange Server HTTP-DAV ; Thu, 22 Jul 2010 06:37:23 +0000 User-Agent: Microsoft-Entourage/12.25.0.100505 Date: Thu, 22 Jul 2010 09:37:22 +0300 From: Jouni Korhonen To: ext Mark Jones , RFC Errata System , "Hannes.Tschofenig@gmx.net" , "mayutan.arumaithurai@gmail.com" , Avi Lior , "dromasca@avaya.com" , "rbonica@juniper.net" , "lionel.morand@orange-ftgroup.com" Message-ID: Thread-Topic: [Editorial Errata Reported] RFC5777 (2336) Thread-Index: AcsnvWe6GUSyyN/gQUWhfz9EPkW3SQASIxYQAFiYr/A= In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 22 Jul 2010 06:37:23.0881 (UTC) FILETIME=[57EF0190:01CB2968] X-Mailman-Approved-At: Wed, 21 Jul 2010 23:44:35 -0700 Cc: "francois@tera.ics.keio.ac.jp" , "dime@ietf.org" Subject: Re: [Dime] [Editorial Errata Reported] RFC5777 (2336) X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Jul 2010 06:37:16 -0000 >From a Dime co-chair point of view I agree with the errata #2336. - Jouni On 7/20/10 3:32 PM, "ext Mark Jones" wrote: > The RFC5777 authors have discussed this errata with Francois Bard prior to > submission and agree that it should proceed to IESG verification. > > Regards > Mark > >> -----Original Message----- >> From: RFC Errata System [mailto:rfc-editor@rfc-editor.org] >> Sent: July 19, 2010 11:41 PM >> To: jouni.korhonen@nsn.com; Hannes.Tschofenig@gmx.net; >> mayutan.arumaithurai@gmail.com; Mark Jones; Avi Lior; >> dromasca@avaya.com; rbonica@juniper.net; lionel.morand@orange- >> ftgroup.com; jouni.korhonen@nsn.com >> Cc: francois@tera.ics.keio.ac.jp; dime@ietf.org; rfc-editor@rfc- >> editor.org >> Subject: [Editorial Errata Reported] RFC5777 (2336) >> >> >> The following errata report has been submitted for RFC5777, >> "Traffic Classification and Quality of Service (QoS) Attributes for >> Diameter". >> >> -------------------------------------- >> You may review the report below and at: >> http://www.rfc-editor.org/errata_search.php?rfc=5777&eid=2336 >> >> -------------------------------------- >> Type: Editorial >> Reported by: Francois Bard >> >> Section: 4.2.8 >> >> Original Text >> ------------- >> The Absolute-Start-Fractional-Seconds AVP (AVP Code 567) is of type >> Unsigned32. The value specifies the fractional seconds that are >> added to Absolute-Start-Time value in order to determine when the >> time window starts. If this AVP is absent from the Time-Of-Day- >> Condition AVP, then the fractional seconds are assumed to be zero. >> >> Corrected Text >> -------------- >> The Absolute-Start-Fractional-Seconds AVP (AVP Code 567) is of type >> Unsigned32. The value specifies the fractional seconds that are >> added to Absolute-Start-Time value in order to determine when the >> time window starts. The Absolute-Start-Fractional-Seconds represent >> a 32-bit fraction field giving a precision of about 232 picoseconds >> ( 1/((2^32)-1)) seconds ). If this AVP is absent from the Time-Of-Day- >> Condition AVP, then the fractional seconds are assumed to be zero. >> See the Network Time Protocol [RFC 1305] for more precision. >> >> Notes >> ----- >> The AVP description lacked a explanation about what a fractional second >> is. >> >> 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. >> >> -------------------------------------- >> RFC5777 (draft-ietf-dime-qos-attributes-15) >> -------------------------------------- >> Title : Traffic Classification and Quality of Service >> (QoS) Attributes for Diameter >> Publication Date : February 2010 >> Author(s) : J. Korhonen, H. Tschofenig, M. Arumaithurai, M. >> Jones, Ed., A. Lior >> Category : PROPOSED STANDARD >> Source : Diameter Maintanence and Extensions >> Area : Operations and Management >> Stream : IETF >> Verifying Party : IESG From jouni.korhonen@nsn.com Wed Jul 21 23:40:02 2010 Return-Path: X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2A28E3A68F1 for ; Wed, 21 Jul 2010 23:40:02 -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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aUlWb5Vtdc8u for ; Wed, 21 Jul 2010 23:40:00 -0700 (PDT) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [93.183.12.32]) by core3.amsl.com (Postfix) with ESMTP id 0767C3A6783 for ; Wed, 21 Jul 2010 23:39:59 -0700 (PDT) Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd001.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id o6M6e5io014958; Thu, 22 Jul 2010 08:40:05 +0200 Received: from demuexc025.nsn-intra.net (demuexc025.nsn-intra.net [10.159.32.12]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id o6M6e3F0017220; Thu, 22 Jul 2010 08:40:05 +0200 Received: from FIESEXC035.nsn-intra.net ([10.159.0.25]) by demuexc025.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.4675); Thu, 22 Jul 2010 08:40:02 +0200 Received: from 10.144.225.109 ([10.144.225.109]) by FIESEXC035.nsn-intra.net ([10.159.0.182]) via Exchange Front-End Server 10.150.128.35 ([10.150.128.35]) with Microsoft Exchange Server HTTP-DAV ; Thu, 22 Jul 2010 06:40:01 +0000 User-Agent: Microsoft-Entourage/12.25.0.100505 Date: Thu, 22 Jul 2010 09:40:01 +0300 From: Jouni Korhonen To: ext Mark Jones , RFC Errata System , "Hannes.Tschofenig@gmx.net" , "mayutan.arumaithurai@gmail.com" , Avi Lior , "dromasca@avaya.com" , "rbonica@juniper.net" , "lionel.morand@orange-ftgroup.com" Message-ID: Thread-Topic: [Editorial Errata Reported] RFC5777 (2337) Thread-Index: Acsnw+ulQwrFrqVCQM+ze2fORLP79QAQ8H/QAFhB/R8= In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 22 Jul 2010 06:40:02.0635 (UTC) FILETIME=[B68EF1B0:01CB2968] X-Mailman-Approved-At: Wed, 21 Jul 2010 23:44:36 -0700 Cc: "francois@tera.ics.keio.ac.jp" , "dime@ietf.org" Subject: Re: [Dime] [Editorial Errata Reported] RFC5777 (2337) X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Jul 2010 06:40:02 -0000 >From a Dime co-chair point of view I agree with the errata #2337 if/when the correction below asked by Mark is added. - Jouni On 7/20/10 3:36 PM, "ext Mark Jones" wrote: > The RFC5777 authors have discussed this errata with Francois Bard prior to > submission. > > However, there is a typo in the first sentence of the proposed corrected text: > "Absolute-Start-Fractional-Seconds" should read > "Absolute-End-Fractional-Seconds". > > With this correction, we agree that it should proceed to IESG verification. > > Regards > Mark > >> -----Original Message----- >> From: RFC Errata System [mailto:rfc-editor@rfc-editor.org] >> Sent: July 20, 2010 12:28 AM >> To: jouni.korhonen@nsn.com; Hannes.Tschofenig@gmx.net; >> mayutan.arumaithurai@gmail.com; Mark Jones; Avi Lior; >> dromasca@avaya.com; rbonica@juniper.net; lionel.morand@orange- >> ftgroup.com; jouni.korhonen@nsn.com >> Cc: francois@tera.ics.keio.ac.jp; dime@ietf.org; rfc-editor@rfc- >> editor.org >> Subject: [Editorial Errata Reported] RFC5777 (2337) >> >> >> The following errata report has been submitted for RFC5777, >> "Traffic Classification and Quality of Service (QoS) Attributes for >> Diameter". >> >> -------------------------------------- >> You may review the report below and at: >> http://www.rfc-editor.org/errata_search.php?rfc=5777&eid=2337 >> >> -------------------------------------- >> Type: Editorial >> Reported by: Francois Bard >> >> Section: 4.2.10 >> >> Original Text >> ------------- >> The Absolute-End-Fractional-Seconds AVP (AVP Code 569) is of type >> Unsigned32. The value specifies the fractional seconds that are >> added to Absolute-End-Time value in order to determine when the time >> window ends. If this AVP is absent from the Time-Of-Day-Condition >> AVP, then the fractional seconds are assumed to be zero. >> >> Corrected Text >> -------------- >> The Absolute-Start-Fractional-Seconds AVP (AVP Code 569) is of type >> Unsigned32. The value specifies the fractional seconds that are >> added to Absolute-End-Time value in order to determine when the time >> window ends. The Absolute-End-Fractional-Seconds represent >> a 32-bit fraction field giving a precision of about 232 picoseconds >> ( 1/((2^32)-1)) seconds ). If this AVP is absent from the Time-Of-Day- >> Condition AVP, then the fractional seconds are assumed to be zero. >> See the Network Time Protocol [RFC 1305] for more precision. >> >> Notes >> ----- >> The AVP description lacked a explanation about what a fractional second >> is. >> >> 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. >> >> -------------------------------------- >> RFC5777 (draft-ietf-dime-qos-attributes-15) >> -------------------------------------- >> Title : Traffic Classification and Quality of Service >> (QoS) Attributes for Diameter >> Publication Date : February 2010 >> Author(s) : J. Korhonen, H. Tschofenig, M. Arumaithurai, M. >> Jones, Ed., A. Lior >> Category : PROPOSED STANDARD >> Source : Diameter Maintanence and Extensions >> Area : Operations and Management >> Stream : IETF >> Verifying Party : IESG From lionel.morand@orange-ftgroup.com Thu Jul 22 00:41:58 2010 Return-Path: X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 29FAC3A6922 for ; Thu, 22 Jul 2010 00:41:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.249 X-Spam-Level: X-Spam-Status: No, score=-3.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QkmWjF9Yzoj8 for ; Thu, 22 Jul 2010 00:41:57 -0700 (PDT) Received: from p-mail1.rd.francetelecom.com (p-mail1.rd.francetelecom.com [195.101.245.15]) by core3.amsl.com (Postfix) with ESMTP id 2C5933A67B4 for ; Thu, 22 Jul 2010 00:41:57 -0700 (PDT) Received: from p-mail1.rd.francetelecom.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 378F48B800D; Thu, 22 Jul 2010 09:42:23 +0200 (CEST) Received: from ftrdsmtp2.rd.francetelecom.fr (unknown [10.192.128.47]) by p-mail1.rd.francetelecom.com (Postfix) with ESMTP id 9F1C28B800A; Thu, 22 Jul 2010 09:42:15 +0200 (CEST) Received: from ftrdmel1.rd.francetelecom.fr ([10.192.128.40]) by ftrdsmtp2.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.3959); Thu, 22 Jul 2010 09:41:48 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Thu, 22 Jul 2010 09:41:46 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Status of the Documents in WGLC Thread-Index: AcspcVYe/zF97kdkQPiW8Is6Z1feMQ== From: To: X-OriginalArrivalTime: 22 Jul 2010 07:41:48.0407 (UTC) FILETIME=[575EE070:01CB2971] Cc: jouni.korhonen@nsn.com Subject: [Dime] Status of the Documents in WGLC X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Jul 2010 07:41:58 -0000 Hi Folks, The following documents have completed the WGLC process: =20 1) draft-ietf-dime-priority-avps 2) draft-ietf-dime-capablities-update 3) draft-ietf-dime-local-keytran 4) draft-ietf-dime-rfc3588bis The PROTO Write-Up for draft-ietf-dime-capablities-update is done. The PROTO Write-Up for draft-ietf-dime-local-keytran and draft-ietf-dime-rfc3588bis will be soon edited. The PROTO Write-Up for draft-ietf-dime-priority-avps will be done just after a last revision of the draft taking into account comments received during the WGLC process. Next step for these documents: IESG review. Best Regards, Lionel & Jouni From lionel.morand@orange-ftgroup.com Thu Jul 22 00:56:04 2010 Return-Path: X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 064633A68A2; Thu, 22 Jul 2010 00:56:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Fqc9SLD82OUr; Thu, 22 Jul 2010 00:56:03 -0700 (PDT) Received: from r-mail2.rd.francetelecom.com (r-mail2.rd.francetelecom.com [217.108.152.42]) by core3.amsl.com (Postfix) with ESMTP id C40DF3A63C9; Thu, 22 Jul 2010 00:56:02 -0700 (PDT) Received: from r-mail2.rd.francetelecom.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 7595FFC401A; Thu, 22 Jul 2010 09:55:14 +0200 (CEST) Received: from ftrdsmtp1.rd.francetelecom.fr (unknown [10.192.128.46]) by r-mail2.rd.francetelecom.com (Postfix) with ESMTP id 350BDFC4012; Thu, 22 Jul 2010 09:53:41 +0200 (CEST) Received: from ftrdmel1.rd.francetelecom.fr ([10.192.128.40]) by ftrdsmtp1.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.3959); Thu, 22 Jul 2010 09:53:23 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Thu, 22 Jul 2010 09:53:21 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: PROTO Writeup for draft-ietf-dime-capablities-update-05.txt Thread-Index: AcspcvS9xACFcBSgRPOS9U5jR+1HNw== From: To: , X-OriginalArrivalTime: 22 Jul 2010 07:53:23.0714 (UTC) FILETIME=[F5CE4E20:01CB2972] Cc: dime@ietf.org Subject: [Dime] PROTO Writeup for draft-ietf-dime-capablities-update-05.txt X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Jul 2010 07:56:04 -0000 PROTO WRITEUP for draft-ietf-dime-capablities-update-05.txt =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=20 http://www.ietf.org/id/draft-ietf-dime-capablities-update-05.txt =20 (1.a) Who is the Document Shepherd for this document?=20 =3D=3D> Lionel Morand Has the Document Shepherd personally reviewed this version of the=20 document and, in particular, does he or she believe this=20 version is ready for forwarding to the IESG for publication?=20 =3D=3D> Yes. (1.b) Has the document had adequate review both from key WG members=20 and from key non-WG members?=20 =3D=3D> Yes. Does the Document Shepherd have any concerns about the depth=20 or breadth of the reviews that have been performed?=20 =3D=3D> No.=20 (1.c) Does the Document Shepherd have concerns that the document=20 needs more review from a particular or broader perspective,=20 e.g., security, operational complexity, someone familiar with=20 AAA, internationalization or XML?=20 =3D=3D> No. (1.d) Does the Document Shepherd have any specific concerns or=20 issues with this document that the Responsible Area Director and/or the IESG should be aware of?=20 =3D=3D> No. Has an IPR disclosure related to this document=20 been filed?=20 =3D=3D> No.=20 (1.e) How solid is the WG consensus behind this document? Does it=20 represent the strong concurrence of a few individuals, with=20 others being silent, or does the WG as a whole understand and=20 agree with it?=20 =3D=3D> This document was pushed mainly by the authors but captures a solution for a problem understood and agreed by the Dime WG.=20 (1.f) Has anyone threatened an appeal or otherwise indicated extreme=20 discontent?=20 =3D=3D> No. (1.g) Has the Document Shepherd personally verified that the=20 document satisfies all ID nits? (See the Internet-Drafts Checklist=20 and http://tools.ietf.org/tools/idnits/). Boilerplate checks are not enough; this check needs to be thorough. Has the document=20 met all formal review criteria it needs to, such as the MIB=20 Doctor, media type and URI type reviews? =3D=3D> The document was verified. No issue found.=20 (1.h) Has the document split its references into normative and=20 informative? =3D=3D> Yes. Are there normative references to documents that=20 are not ready for advancement or are otherwise in an unclear=20 state? If such normative references exist, what is the=20 strategy for their completion? =09 =3D=3D> The draft has a normative reference to the draft-ietf-dime-rfc3588bis that is not yet published as RFC. However, this draft is under review process and should be soon published. (1.i) Has the Document Shepherd verified that the document IANA=20 consideration section exists and is consistent with the body=20 of the document? =09 =3D=3D> Yes. If the document specifies protocol=20 extensions, are reservations requested in appropriate IANA=20 registries? Are the IANA registries clearly identified? =3D=3D> Yes. One new Diameter application id and two new Diameter command code values are requested in the corresponding existing IANA registries. (1.j) Has the Document Shepherd verified that sections of the=20 document that are written in a formal language, such as XML=20 code, BNF rules, MIB definitions, etc., validate correctly in=20 an automated checker?=20 =20 =3D=3D> Yes. (1.k) The IESG approval announcement includes a Document=20 Announcement Write-Up. Please provide such a Document=20 Announcement Write-Up? Recent examples can be found in the "Action" announcements for approved documents. The approval=20 announcement contains the following sections:=20 Technical Summary=20 This document defines a new Diameter application and associated command codes. The Diameter Capabilities Update application is intended to allow the dynamic update of certain Diameter peer capabilities while the peer-to-peer connection is in the open state. This application relies=20 on the exchange of the Capabilities-Update-Request/Answer (CUR/CUA) messages between peers supporting the Diameter Capabilities Update application Working Group Summary=20 =20 There was consensus in the WG to publish the document. =20 Document Quality=20 =20 This document has been reviewed and commented from key people in the Dime WG. From dromasca@avaya.com Thu Jul 22 02:15:53 2010 Return-Path: X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 002383A6A40; Thu, 22 Jul 2010 02:15:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.437 X-Spam-Level: X-Spam-Status: No, score=-2.437 tagged_above=-999 required=5 tests=[AWL=0.162, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1diexitmAfRZ; Thu, 22 Jul 2010 02:15:51 -0700 (PDT) Received: from p-us1-iereast-outbound-tmp.us1.avaya.com (p-us1-iereast-outbound-tmp.us1.avaya.com [135.11.29.16]) by core3.amsl.com (Postfix) with ESMTP id 896FF3A6A10; Thu, 22 Jul 2010 02:15:51 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.55,242,1278302400"; d="scan'208";a="26262218" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by p-us1-iereast-outbound-tmp.us1.avaya.com with ESMTP; 22 Jul 2010 05:16:07 -0400 X-IronPort-AV: E=Sophos;i="4.55,242,1278302400"; d="scan'208";a="493738336" Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.12]) by co300216-co-erhwest-out.avaya.com with ESMTP; 22 Jul 2010 05:16:06 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 22 Jul 2010 11:15:44 +0200 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: PROTO Writeup for draft-ietf-dime-capablities-update-05.txt Thread-Index: AcspcvS9xACFcBSgRPOS9U5jR+1HNwAC1MBA References: From: "Romascanu, Dan (Dan)" To: , Cc: dime@ietf.org Subject: Re: [Dime] PROTO Writeup for draft-ietf-dime-capablities-update-05.txt X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Jul 2010 09:15:53 -0000 Lionel, I guess that the IESG-Secretary should take this as an official request to consider http://www.ietf.org/id/draft-ietf-dime-capablities-update-05.txt for Proposed Standard. Correct?=20 Regards, Dan > -----Original Message----- > From: lionel.morand@orange-ftgroup.com=20 > [mailto:lionel.morand@orange-ftgroup.com]=20 > Sent: Thursday, July 22, 2010 10:53 AM > To: Romascanu, Dan (Dan); iesg-secretary@ietf.org > Cc: dime@ietf.org > Subject: PROTO Writeup for draft-ietf-dime-capablities-update-05.txt >=20 >=20 > PROTO WRITEUP for draft-ietf-dime-capablities-update-05.txt > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=20 >=20 > http://www.ietf.org/id/draft-ietf-dime-capablities-update-05.txt >=20 > =20 > (1.a) Who is the Document Shepherd for this document?=20 >=20 > =3D=3D> Lionel Morand >=20 > Has the Document Shepherd personally reviewed this=20 > version of the=20 > document and, in particular, does he or she believe this=20 > version is ready for forwarding to the IESG for publication?=20 >=20 > =3D=3D> Yes. >=20 > (1.b) Has the document had adequate review both from key WG members=20 > and from key non-WG members?=20 >=20 > =3D=3D> Yes. >=20 > Does the Document Shepherd have any concerns about the depth=20 > or breadth of the reviews that have been performed?=20 >=20 > =3D=3D> No.=20 >=20 > (1.c) Does the Document Shepherd have concerns that the document=20 > needs more review from a particular or broader perspective,=20 > e.g., security, operational complexity, someone familiar with=20 > AAA, internationalization or XML?=20 >=20 > =3D=3D> No. >=20 > (1.d) Does the Document Shepherd have any specific concerns or=20 > issues with this document that the Responsible Area Director > and/or the IESG should be aware of?=20 >=20 > =3D=3D> No. >=20 > Has an IPR disclosure related to this document=20 > been filed?=20 >=20 > =3D=3D> No.=20 >=20 > (1.e) How solid is the WG consensus behind this document? Does it=20 > represent the strong concurrence of a few individuals, with=20 > others being silent, or does the WG as a whole understand and=20 > agree with it?=20 >=20 > =3D=3D> This document was pushed mainly by the authors=20 > but captures a solution > for a problem understood and agreed by the Dime WG.=20 >=20 > (1.f) Has anyone threatened an appeal or otherwise=20 > indicated extreme=20 > discontent?=20 >=20 > =3D=3D> No. >=20 > (1.g) Has the Document Shepherd personally verified that the=20 > document satisfies all ID nits? (See the=20 > Internet-Drafts Checklist=20 > and http://tools.ietf.org/tools/idnits/). Boilerplate=20 > checks are >=20 > not enough; this check needs to be thorough. Has the document=20 > met all formal review criteria it needs to, such as the MIB=20 > Doctor, media type and URI type reviews? >=20 > =3D=3D> The document was verified. No issue found.=20 >=20 > (1.h) Has the document split its references into normative and=20 > informative? >=20 > =3D=3D> Yes. >=20 > Are there normative references to documents that=20 > are not ready for advancement or are otherwise in an unclear=20 > state? If such normative references exist, what is the=20 > strategy for their completion? > =09 > =3D=3D> The draft has a normative reference to the=20 > draft-ietf-dime-rfc3588bis that is not yet published as RFC. > However, this draft is under review process and=20 > should be soon published. >=20 > (1.i) Has the Document Shepherd verified that the document IANA=20 > consideration section exists and is consistent with the body=20 > of the document? > =09 > =3D=3D> Yes. >=20 > If the document specifies protocol=20 > extensions, are reservations requested in appropriate IANA=20 > registries? Are the IANA registries clearly identified? >=20 > =3D=3D> Yes. > One new Diameter application id and two new Diameter=20 > command code values are requested in the corresponding=20 > existing IANA registries. >=20 > (1.j) Has the Document Shepherd verified that sections of the=20 > document that are written in a formal language, such as XML=20 > code, BNF rules, MIB definitions, etc., validate correctly in=20 > an automated checker?=20 > =20 > =3D=3D> Yes. >=20 > (1.k) The IESG approval announcement includes a Document=20 > Announcement Write-Up. Please provide such a Document=20 > Announcement Write-Up? Recent examples can be found in the > "Action" announcements for approved documents. The approval=20 > announcement contains the following sections:=20 >=20 > Technical Summary=20 >=20 > This document defines a new Diameter application and=20 > associated > command codes. The Diameter Capabilities Update=20 > application is intended to > allow the dynamic update of certain Diameter peer=20 > capabilities while > the peer-to-peer connection is in the open state.=20 > This application relies=20 > on the exchange of the Capabilities-Update-Request/Answer > (CUR/CUA) messages > between peers supporting the Diameter Capabilities=20 > Update application >=20 > Working Group Summary=20 > =20 > There was consensus in the WG to publish the document. =20 >=20 > Document Quality=20 > =20 > This document has been reviewed and commented from=20 > key people in the Dime WG. >=20 From lionel.morand@orange-ftgroup.com Thu Jul 22 02:44:08 2010 Return-Path: X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 194663A6A41; Thu, 22 Jul 2010 02:44:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7Bz5CgAtJdcV; Thu, 22 Jul 2010 02:44:07 -0700 (PDT) Received: from r-mail2.rd.francetelecom.com (r-mail2.rd.francetelecom.com [217.108.152.42]) by core3.amsl.com (Postfix) with ESMTP id 804AA3A6A64; Thu, 22 Jul 2010 02:44:06 -0700 (PDT) Received: from r-mail2.rd.francetelecom.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 0B02BFC403A; Thu, 22 Jul 2010 11:37:00 +0200 (CEST) Received: from ftrdsmtp1.rd.francetelecom.fr (unknown [10.192.128.46]) by r-mail2.rd.francetelecom.com (Postfix) with ESMTP id 28D5FFC4043; Thu, 22 Jul 2010 11:25:14 +0200 (CEST) Received: from ftrdmel1.rd.francetelecom.fr ([10.192.128.40]) by ftrdsmtp1.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.3959); Thu, 22 Jul 2010 11:25:02 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Thu, 22 Jul 2010 11:25:00 +0200 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: PROTO Writeup for draft-ietf-dime-capablities-update-05.txt Thread-Index: AcspcvS9xACFcBSgRPOS9U5jR+1HNwAC1MBAAABHT2A= References: From: To: , X-OriginalArrivalTime: 22 Jul 2010 09:25:02.0757 (UTC) FILETIME=[C37DAD50:01CB297F] Cc: dime@ietf.org Subject: Re: [Dime] PROTO Writeup for draft-ietf-dime-capablities-update-05.txt X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Jul 2010 09:44:08 -0000 Correct. The draft is ready for publication. BR, Lionel=20 > -----Message d'origine----- > De : Romascanu, Dan (Dan) [mailto:dromasca@avaya.com]=20 > Envoy=E9 : jeudi 22 juillet 2010 11:16 > =C0 : MORAND Lionel RD-CORE-ISS; iesg-secretary@ietf.org > Cc : dime@ietf.org > Objet : RE: PROTO Writeup for=20 > draft-ietf-dime-capablities-update-05.txt >=20 > Lionel, >=20 > I guess that the IESG-Secretary should take this as an=20 > official request to consider=20 > http://www.ietf.org/id/draft-ietf-dime-capablities-update-05.t > xt for Proposed Standard. Correct?=20 >=20 > Regards, >=20 > Dan >=20 >=20 > > -----Original Message----- > > From: lionel.morand@orange-ftgroup.com=20 > > [mailto:lionel.morand@orange-ftgroup.com] > > Sent: Thursday, July 22, 2010 10:53 AM > > To: Romascanu, Dan (Dan); iesg-secretary@ietf.org > > Cc: dime@ietf.org > > Subject: PROTO Writeup for draft-ietf-dime-capablities-update-05.txt > >=20 > >=20 > > PROTO WRITEUP for draft-ietf-dime-capablities-update-05.txt > > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > >=20 > > http://www.ietf.org/id/draft-ietf-dime-capablities-update-05.txt > >=20 > > =20 > > (1.a) Who is the Document Shepherd for this document?=20 > >=20 > > =3D=3D> Lionel Morand > >=20 > > Has the Document Shepherd personally reviewed this=20 > version of=20 > > the > > document and, in particular, does he or she believe this=20 > > version is ready for forwarding to the IESG for=20 > publication?=20 > >=20 > > =3D=3D> Yes. > >=20 > > (1.b) Has the document had adequate review both from key=20 > WG members=20 > > and from key non-WG members?=20 > >=20 > > =3D=3D> Yes. > >=20 > > Does the Document Shepherd have any concerns about the depth=20 > > or breadth of the reviews that have been performed?=20 > >=20 > > =3D=3D> No.=20 > >=20 > > (1.c) Does the Document Shepherd have concerns that the document=20 > > needs more review from a particular or broader perspective,=20 > > e.g., security, operational complexity, someone=20 > familiar with=20 > > AAA, internationalization or XML?=20 > >=20 > > =3D=3D> No. > >=20 > > (1.d) Does the Document Shepherd have any specific concerns or=20 > > issues with this document that the Responsible Area Director > > and/or the IESG should be aware of?=20 > >=20 > > =3D=3D> No. > >=20 > > Has an IPR disclosure related to this document=20 > > been filed?=20 > >=20 > > =3D=3D> No.=20 > >=20 > > (1.e) How solid is the WG consensus behind this document? Does it=20 > > represent the strong concurrence of a few individuals, with=20 > > others being silent, or does the WG as a whole=20 > understand and=20 > > agree with it?=20 > >=20 > > =3D=3D> This document was pushed mainly by the authors=20 > but captures a=20 > > solution > > for a problem understood and agreed by the Dime WG.=20 > >=20 > > (1.f) Has anyone threatened an appeal or otherwise=20 > indicated extreme > > discontent?=20 > >=20 > > =3D=3D> No. > >=20 > > (1.g) Has the Document Shepherd personally verified that the=20 > > document satisfies all ID nits? (See the Internet-Drafts=20 > > Checklist > > and http://tools.ietf.org/tools/idnits/).=20 > Boilerplate checks=20 > > are > >=20 > > not enough; this check needs to be thorough. Has=20 > the document=20 > > met all formal review criteria it needs to, such as the MIB=20 > > Doctor, media type and URI type reviews? > >=20 > > =3D=3D> The document was verified. No issue found.=20 > >=20 > > (1.h) Has the document split its references into normative and=20 > > informative? > >=20 > > =3D=3D> Yes. > >=20 > > Are there normative references to documents that=20 > > are not ready for advancement or are otherwise in=20 > an unclear=20 > > state? If such normative references exist, what is the=20 > > strategy for their completion? > > =09 > > =3D=3D> The draft has a normative reference to the=20 > > draft-ietf-dime-rfc3588bis that is not yet published as RFC. > > However, this draft is under review process and=20 > should be soon=20 > > published. > >=20 > > (1.i) Has the Document Shepherd verified that the document IANA=20 > > consideration section exists and is consistent with=20 > the body=20 > > of the document? > > =09 > > =3D=3D> Yes. > >=20 > > If the document specifies protocol=20 > > extensions, are reservations requested in appropriate IANA=20 > > registries? Are the IANA registries clearly identified? > >=20 > > =3D=3D> Yes. > > One new Diameter application id and two new Diameter=20 > command code=20 > > values are requested in the corresponding existing IANA registries. > >=20 > > (1.j) Has the Document Shepherd verified that sections of the=20 > > document that are written in a formal language, such as XML=20 > > code, BNF rules, MIB definitions, etc., validate=20 > correctly in=20 > > an automated checker?=20 > > =20 > > =3D=3D> Yes. > >=20 > > (1.k) The IESG approval announcement includes a Document=20 > > Announcement Write-Up. Please provide such a Document=20 > > Announcement Write-Up? Recent examples can be found in the > > "Action" announcements for approved documents. The approval=20 > > announcement contains the following sections:=20 > >=20 > > Technical Summary > >=20 > > This document defines a new Diameter application and=20 > associated > > command codes. The Diameter Capabilities Update=20 > application is=20 > > intended to > > allow the dynamic update of certain Diameter peer=20 > capabilities=20 > > while > > the peer-to-peer connection is in the open state.=20 > > This application relies=20 > > on the exchange of the Capabilities-Update-Request/Answer > > (CUR/CUA) messages > > between peers supporting the Diameter Capabilities Update=20 > > application > >=20 > > Working Group Summary > > =20 > > There was consensus in the WG to publish the document. =20 > >=20 > > Document Quality > > =20 > > This document has been reviewed and commented from=20 > key people in=20 > > the Dime WG. > >=20 >=20 From jouni.nospam@gmail.com Fri Jul 23 02:29:48 2010 Return-Path: X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 48B503A6B33 for ; Fri, 23 Jul 2010 02:29:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.518 X-Spam-Level: X-Spam-Status: No, score=-2.518 tagged_above=-999 required=5 tests=[AWL=0.082, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f8mW+4Ksq1k2 for ; Fri, 23 Jul 2010 02:29:47 -0700 (PDT) Received: from vs14.mail.saunalahti.fi (vs14.mail.saunalahti.fi [195.197.172.102]) by core3.amsl.com (Postfix) with ESMTP id 125BC3A6A17 for ; Fri, 23 Jul 2010 02:29:46 -0700 (PDT) Received: from saunalahti-vams (localhost [127.0.0.1]) by vs14.mail.saunalahti.fi (Postfix) with SMTP id 5FC70A6044; Fri, 23 Jul 2010 12:30:03 +0300 (EEST) Received: from vs14.mail.saunalahti.fi ([127.0.0.1]) by vs14.mail.saunalahti.fi ([195.197.172.102]) with SMTP (gateway) id A01A355D6F2; Fri, 23 Jul 2010 12:30:03 +0300 Received: from gw01.mail.saunalahti.fi (gw01.mail.saunalahti.fi [195.197.172.115]) by vs14.mail.saunalahti.fi (Postfix) with ESMTP id 533A5A6044; Fri, 23 Jul 2010 12:30:03 +0300 (EEST) Received: from a83-245-209-228.elisa-laajakaista.fi (a83-245-209-228.elisa-laajakaista.fi [83.245.209.228]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by gw01.mail.saunalahti.fi (Postfix) with ESMTP id CDE351513E7; Fri, 23 Jul 2010 12:29:58 +0300 (EEST) Mime-Version: 1.0 (Apple Message framework v1078) Content-Type: text/plain; charset=us-ascii From: Jouni In-Reply-To: <1CCD5EDB-5B3D-4EAF-81F5-4B45D8B545D2@gmail.com> Date: Fri, 23 Jul 2010 12:29:57 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: References: <1CCD5EDB-5B3D-4EAF-81F5-4B45D8B545D2@gmail.com> To: dime@ietf.org X-Mailer: Apple Mail (2.1078) X-Antivirus: VAMS Cc: dime-chairs@tools.ietf.org Subject: [Dime] Note takers & scribes needed - was: IETF#78 meeting logistics X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Jul 2010 09:29:48 -0000 Tom Taylor already volunteered for taking notes. Thanks! Second note taker and especially a jabber scribe would still be needed, = so please volunteer. - Jouni On Jul 16, 2010, at 10:54 AM, Jouni wrote: >=20 > If you feel like volunteering as a notes taker or a jabber scribe for = the upcoming Dime WG meeting in Maastricht, please drop the chairs a = mail. Having named persons in advance would cut away the traditional = uncomfortable 5 mins of asking volunteers from the crowd who all try to = be faraway ;) >=20 > Jouni & Lionel From jouni.nospam@gmail.com Sun Jul 25 08:10:31 2010 Return-Path: X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1D2523A68C8 for ; Sun, 25 Jul 2010 08:10:31 -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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id exIk+cqCO1XB for ; Sun, 25 Jul 2010 08:10:26 -0700 (PDT) Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by core3.amsl.com (Postfix) with ESMTP id DB98E3A68A9 for ; Sun, 25 Jul 2010 08:10:25 -0700 (PDT) Received: by fxm1 with SMTP id 1so6345175fxm.31 for ; Sun, 25 Jul 2010 08:10:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:from:content-type :content-transfer-encoding:subject:date:message-id:cc:to :mime-version:x-mailer; bh=Mmb06iSW26iboCniwtYm2krwuaT7NWCpxteOjOajOr0=; b=Kn2cD4KAjTtaMJKlaRSs5ZxxFkevw4JIDySo7nxiSF5EVSV7PH6atCny6pvPsby/w9 eRsRcvaSHn4cfTgjl/YMWzx/IgXG8NRWY+dp375o/GMoDvETq+7zVdcUubWF/d/+zpY3 aXkM2z8u9MANnY2qrZrU0d0zL5Dqo0WdoYV8E= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:content-type:content-transfer-encoding:subject:date:message-id :cc:to:mime-version:x-mailer; b=Bz+oEKqtlcb1UqjNPLPaw+9gf2Bi60ICKK52RkVF+DO88KwsIUfPdgCsY+pGscc6Uz D3iAclE9+3/oVyOnM6pLEqDG/JA2rTLrsmtvcGsre9pgfy2CkmttO9nDqsH+nbT0uo79 NWX0FAvjybmbpq8KvFNsyboJhf7yOOGL1OeyU= Received: by 10.223.104.130 with SMTP id p2mr5351229fao.9.1280070645491; Sun, 25 Jul 2010 08:10:45 -0700 (PDT) Received: from 85-156-74-126.elisa-mobile.fi (85-156-74-126.elisa-mobile.fi [85.156.74.126]) by mx.google.com with ESMTPS id f11sm973197fak.44.2010.07.25.08.10.44 (version=TLSv1/SSLv3 cipher=RC4-MD5); Sun, 25 Jul 2010 08:10:45 -0700 (PDT) From: jouni korhonen Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Sun, 25 Jul 2010 18:10:41 +0300 Message-Id: <94081065-8C02-4990-A290-00AED6993A0E@gmail.com> To: dime@ietf.org Mime-Version: 1.0 (Apple Message framework v1078) X-Mailer: Apple Mail (2.1078) Cc: dime-chairs@tools.ietf.org Subject: [Dime] DIME presentations X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 Jul 2010 15:10:31 -0000 Hello, Tuesday DIME WG meeting is approaching. Send your slideware latest = Monday 6pm to the chairs! - Jouni & Lionel= From vshaikh@telcordia.com Mon Jul 26 11:52:04 2010 Return-Path: X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E17563A67B3 for ; Mon, 26 Jul 2010 11:52:04 -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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ezj6lNxg9i0T for ; Mon, 26 Jul 2010 11:52:03 -0700 (PDT) Received: from dnsmx1pya.telcordia.com (dnsmx1pya.telcordia.com [128.96.20.31]) by core3.amsl.com (Postfix) with ESMTP id 441B83A6867 for ; Mon, 26 Jul 2010 11:52:02 -0700 (PDT) Received: from rrc-dte-ieg01.dte.telcordia.com (rrc-dte-ieg01.cc.telcordia.com [128.96.20.22]) by dnsmx1pya.telcordia.com (8.13.8+Sun/8.13.8) with ESMTP id o6QIqMnL026464 for ; Mon, 26 Jul 2010 14:52:22 -0400 (EDT) X-AuditID: 80601416-000006c400000554-6e-4c4dd963470e Received: from rrc-dte-exhb1.dte.telcordia.com ([128.96.20.12]) by rrc-dte-ieg01.dte.telcordia.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 26 Jul 2010 14:52:19 -0400 Received: from rrc-dte-exmb2.dte.telcordia.com ([128.96.180.27]) by rrc-dte-exhb1.dte.telcordia.com ([128.96.20.12]) with mapi; Mon, 26 Jul 2010 14:52:19 -0400 From: "Shaikh, Viqar A" To: "'dime@ietf.org'" Date: Mon, 26 Jul 2010 14:52:18 -0400 Thread-Topic: Draft-ietf-dime-priority-avps-01.txt Thread-Index: Acss86wa36oCnFv9TtqfsQO8zeDq0A== Message-ID: <8B6A9EC265011E4CB70F99C64426E8C205870D7893@rrc-dte-exmb2.dte.telcordia.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Subject: [Dime] Draft-ietf-dime-priority-avps-01.txt X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Jul 2010 18:52:05 -0000 Rm9yIE1hcnRpbiBEb2xseS4NCg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KSGVsbG8s4oCs DQoNCuKAqg0KDQpEcmFmdC1pZXRmLWRpbWUtcHJpb3JpdHktYXZwcy0wMS50eHQgZGVmaW5lcyBh IG5ldyBBVlAgZm9yIFNJUC1SZXNvdXJjZS1Qcmlvcml0eS7igKwNCg0K4oCqDQoNCldoYXQgYXBw bGljYXRpb24vc2VydmljZSBpcyB0aGlzIGluIHN1cHBvcnQgb2YsIGFzIEFWUHMgaGF2ZSBhbHJl YWR5IGJlZW4gZGVmaW5lZCBmb3IgTkdOIEdFVFMgKGV0cywgd3BzKT/igKwNCg0K4oCqVGhhbmsg eW91LOKArA0KDQrigKrigKwNCg0K4oCqDQpNYXJ0aW4gRG9sbHkNCkxlYWQgTWVtYmVyIFRlY2hu aWNhbCBTdGFmZuKArA0K4oCqQ29yZSAmIEdvdmVybm1lbnQvUmVndWxhdG9yeSBTdGFuZGFyZHMN CkFUJlQgTGFicywgSW5jLg0KbWQzMTM1QGF0dC5jb23igKwNCisxLTYwOS05MDMtMzM2MOKArA== From jgunn6@csc.com Mon Jul 26 12:05:53 2010 Return-Path: X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A36F63A688A; Mon, 26 Jul 2010 12:05:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.338 X-Spam-Level: X-Spam-Status: No, score=-6.338 tagged_above=-999 required=5 tests=[AWL=0.260, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sEeyR8fWXFCn; Mon, 26 Jul 2010 12:05:52 -0700 (PDT) Received: from mail87.messagelabs.com (mail87.messagelabs.com [216.82.250.19]) by core3.amsl.com (Postfix) with ESMTP id 910E23A683C; Mon, 26 Jul 2010 12:05:52 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: jgunn6@csc.com X-Msg-Ref: server-7.tower-87.messagelabs.com!1280171169!21368302!1 X-StarScan-Version: 6.2.4; banners=-,-,- X-Originating-IP: [20.137.2.88] Received: (qmail 29543 invoked from network); 26 Jul 2010 19:06:10 -0000 Received: from amer-mta102.csc.com (HELO amer-mta102.csc.com) (20.137.2.88) by server-7.tower-87.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 26 Jul 2010 19:06:10 -0000 Received: from amer-gw09.amer.csc.com (amer-gw09.amer.csc.com [20.6.39.245]) by amer-mta102.csc.com (Switch-3.4.3/Switch-3.3.3mp) with ESMTP id o6QJ69g4024846; Mon, 26 Jul 2010 15:06:09 -0400 In-Reply-To: <8B6A9EC265011E4CB70F99C64426E8C205870D7893@rrc-dte-exmb2.dte.telcordia.com> References: <8B6A9EC265011E4CB70F99C64426E8C205870D7893@rrc-dte-exmb2.dte.telcordia.com> To: "Shaikh, Viqar A" MIME-Version: 1.0 X-KeepSent: D8CDDF92:0244ADC7-8525776C:0068C0D3; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 8.0.2FP1 CCH2 April 23, 2009 From: Janet P Gunn Message-ID: Date: Mon, 26 Jul 2010 15:06:00 -0400 X-MIMETrack: Serialize by Router on AMER-GW09/SRV/CSC(Release 8.5.1FP1 HF440|June 18, 2010) at 07/26/2010 03:06:34 PM, Serialize complete at 07/26/2010 03:06:34 PM Content-Type: multipart/alternative; boundary="=_alternative 0068D85F8525776C_=" Cc: dime-bounces@ietf.org, "'dime@ietf.org'" Subject: Re: [Dime] Draft-ietf-dime-priority-avps-01.txt X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Jul 2010 19:05:53 -0000 This is a multipart message in MIME format. --=_alternative 0068D85F8525776C_= Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: base64 SXQgaXMgYWN0dWFsbHkgRHJhZnQtaWV0Zi1kaW1lLXByaW9yaXR5LWF2cHMtMDIgbm93LWJ1dCBz dGlsbCBkZWZpbmVzIHRoZSANCnNhbWUgQVZQcy4NCg0KSmFuZXQNCg0KDQoNCkZyb206DQoiU2hh aWtoLCBWaXFhciBBIiA8dnNoYWlraEB0ZWxjb3JkaWEuY29tPg0KVG86DQoiJ2RpbWVAaWV0Zi5v cmcnIiA8ZGltZUBpZXRmLm9yZz4NCkRhdGU6DQowNy8yNi8yMDEwIDAyOjUyIFBNDQpTdWJqZWN0 Og0KW0RpbWVdIERyYWZ0LWlldGYtZGltZS1wcmlvcml0eS1hdnBzLTAxLnR4dA0KDQoNCg0KRm9y IE1hcnRpbiBEb2xseS4NCg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KSGVsbG8s4oCsDQoN CuKAqg0KDQpEcmFmdC1pZXRmLWRpbWUtcHJpb3JpdHktYXZwcy0wMS50eHQgZGVmaW5lcyBhIG5l dyBBVlAgZm9yIA0KU0lQLVJlc291cmNlLVByaW9yaXR5LuKArA0KDQrigKoNCg0KV2hhdCBhcHBs aWNhdGlvbi9zZXJ2aWNlIGlzIHRoaXMgaW4gc3VwcG9ydCBvZiwgYXMgQVZQcyBoYXZlIGFscmVh ZHkgYmVlbiANCmRlZmluZWQgZm9yIE5HTiBHRVRTIChldHMsIHdwcyk/4oCsDQoNCuKAqlRoYW5r IHlvdSzigKwNCg0K4oCq4oCsDQoNCuKAqg0KTWFydGluIERvbGx5DQpMZWFkIE1lbWJlciBUZWNo bmljYWwgU3RhZmbigKwNCuKAqkNvcmUgJiBHb3Zlcm5tZW50L1JlZ3VsYXRvcnkgU3RhbmRhcmRz DQpBVCZUIExhYnMsIEluYy4NCm1kMzEzNUBhdHQuY29t4oCsDQorMS02MDktOTAzLTMzNjDigKwN Cl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpEaU1FIG1h aWxpbmcgbGlzdA0KRGlNRUBpZXRmLm9yZw0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9s aXN0aW5mby9kaW1lDQoNCg0KDQo= --=_alternative 0068D85F8525776C_= Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: base64 DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPjxicj4NCkl0IGlzIGFjdHVhbGx5 IDwvZm9udD48dHQ+PGZvbnQgc2l6ZT0yPkRyYWZ0LWlldGYtZGltZS1wcmlvcml0eS1hdnBzLTAy DQpub3ctYnV0IHN0aWxsIGRlZmluZXMgdGhlIHNhbWUgQVZQcy48L2ZvbnQ+PC90dD4NCjxicj4N Cjxicj48dHQ+PGZvbnQgc2l6ZT0yPkphbmV0PC9mb250PjwvdHQ+DQo8YnI+DQo8YnI+DQo8YnI+ DQo8dGFibGUgd2lkdGg9MTAwJT4NCjx0ciB2YWxpZ249dG9wPg0KPHRkPjxmb250IHNpemU9MSBj b2xvcj0jNWY1ZjVmIGZhY2U9InNhbnMtc2VyaWYiPkZyb206PC9mb250Pg0KPHRkPjxmb250IHNp emU9MSBmYWNlPSJzYW5zLXNlcmlmIj4mcXVvdDtTaGFpa2gsIFZpcWFyIEEmcXVvdDsgJmx0O3Zz aGFpa2hAdGVsY29yZGlhLmNvbSZndDs8L2ZvbnQ+DQo8dHIgdmFsaWduPXRvcD4NCjx0ZD48Zm9u dCBzaXplPTEgY29sb3I9IzVmNWY1ZiBmYWNlPSJzYW5zLXNlcmlmIj5Ubzo8L2ZvbnQ+DQo8dGQ+ PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPiZxdW90OydkaW1lQGlldGYub3JnJyZxdW90 OyAmbHQ7ZGltZUBpZXRmLm9yZyZndDs8L2ZvbnQ+DQo8dHIgdmFsaWduPXRvcD4NCjx0ZD48Zm9u dCBzaXplPTEgY29sb3I9IzVmNWY1ZiBmYWNlPSJzYW5zLXNlcmlmIj5EYXRlOjwvZm9udD4NCjx0 ZD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+MDcvMjYvMjAxMCAwMjo1MiBQTTwvZm9u dD4NCjx0ciB2YWxpZ249dG9wPg0KPHRkPjxmb250IHNpemU9MSBjb2xvcj0jNWY1ZjVmIGZhY2U9 InNhbnMtc2VyaWYiPlN1YmplY3Q6PC9mb250Pg0KPHRkPjxmb250IHNpemU9MSBmYWNlPSJzYW5z LXNlcmlmIj5bRGltZV0gRHJhZnQtaWV0Zi1kaW1lLXByaW9yaXR5LWF2cHMtMDEudHh0PC9mb250 PjwvdGFibGU+DQo8YnI+DQo8aHIgbm9zaGFkZT4NCjxicj4NCjxicj4NCjxicj48dHQ+PGZvbnQg c2l6ZT0yPkZvciBNYXJ0aW4gRG9sbHkuPGJyPg0KPGJyPg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLTxicj4NCkhlbGxvLOKArDxicj4NCjxicj4NCuKAqjxicj4NCjxicj4NCkRyYWZ0LWlldGYt ZGltZS1wcmlvcml0eS1hdnBzLTAxLnR4dCBkZWZpbmVzIGEgbmV3IEFWUCBmb3IgU0lQLVJlc291 cmNlLVByaW9yaXR5LuKArDxicj4NCjxicj4NCuKAqjxicj4NCjxicj4NCldoYXQgYXBwbGljYXRp b24vc2VydmljZSBpcyB0aGlzIGluIHN1cHBvcnQgb2YsIGFzIEFWUHMgaGF2ZSBhbHJlYWR5IGJl ZW4NCmRlZmluZWQgZm9yIE5HTiBHRVRTIChldHMsIHdwcyk/4oCsPGJyPg0KPGJyPg0K4oCqVGhh bmsgeW91LOKArDxicj4NCjxicj4NCuKAquKArDxicj4NCjxicj4NCuKAqjxicj4NCk1hcnRpbiBE b2xseTxicj4NCkxlYWQgTWVtYmVyIFRlY2huaWNhbCBTdGFmZuKArDxicj4NCuKAqkNvcmUgJmFt cDsgR292ZXJubWVudC9SZWd1bGF0b3J5IFN0YW5kYXJkczxicj4NCkFUJmFtcDtUIExhYnMsIElu Yy48YnI+DQptZDMxMzVAYXR0LmNvbeKArDxicj4NCisxLTYwOS05MDMtMzM2MOKArDxicj4NCl9f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0KRGlNRSBt YWlsaW5nIGxpc3Q8YnI+DQpEaU1FQGlldGYub3JnPGJyPg0KPC9mb250PjwvdHQ+PGEgaHJlZj1o dHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2RpbWU+PHR0Pjxmb250IHNpemU9 Mj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2RpbWU8L2ZvbnQ+PC90dD48 L2E+PHR0Pjxmb250IHNpemU9Mj48YnI+DQo8L2ZvbnQ+PC90dD4NCjxicj4NCjxicj4NCg== --=_alternative 0068D85F8525776C_=-- From jouni.nospam@gmail.com Mon Jul 26 14:54:45 2010 Return-Path: X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D19EF3A6A6E for ; Mon, 26 Jul 2010 14:54:45 -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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LmUIIQIJudaF for ; Mon, 26 Jul 2010 14:54:45 -0700 (PDT) Received: from mail-ey0-f172.google.com (mail-ey0-f172.google.com [209.85.215.172]) by core3.amsl.com (Postfix) with ESMTP id C00AB3A6A73 for ; Mon, 26 Jul 2010 14:54:44 -0700 (PDT) Received: by eyb7 with SMTP id 7so683083eyb.31 for ; Mon, 26 Jul 2010 14:55:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:subject:mime-version :content-type:from:in-reply-to:date:cc:content-transfer-encoding :message-id:references:to:x-mailer; bh=nLw+nC5THQ+4xXjw0GyztVMFy10kpg8SzS7wzshVReE=; b=uUbmI1mwBaSO635lkpjiqem2Hfb0MShABP1/EoaAxbyBYliJsAlIuABKsPRMqW4UkB jGQvhONadMixfn5aCCGKSsGmGV/47nVItb/mLLXJ98EAyDXoWfqs5oqyNKZ2qIMokOzX j4vRY1m5LVXBBrZQyF/tJwuFMZZusu1Eo7SOg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; b=fxHJwWNp8+SNRFb191pVnkArmAgFDd7i9XHV+vnb/ww7tXbEUQMXYoN2F/GkxUZ6RK cBdIwabVnz4mHQ/8iJopW+h4fyqgqFWM85X+5+8lF+f7xMAcMrzeqzYYkAPtxdTUhZjc L+K+LBK32J1i4tRO5fJuXaeJPvefWwI+gvrWA= Received: by 10.14.53.2 with SMTP id f2mr573477eec.33.1280181305268; Mon, 26 Jul 2010 14:55:05 -0700 (PDT) Received: from [192.168.1.13] ([87.213.214.66]) by mx.google.com with ESMTPS id v8sm6418538eeh.8.2010.07.26.14.55.01 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 26 Jul 2010 14:55:04 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1078) Content-Type: text/plain; charset=us-ascii From: jouni korhonen In-Reply-To: <94081065-8C02-4990-A290-00AED6993A0E@gmail.com> Date: Tue, 27 Jul 2010 00:54:53 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <603F2E40-7B89-4DD4-BB75-47DA4B93691F@gmail.com> References: <94081065-8C02-4990-A290-00AED6993A0E@gmail.com> To: dime@ietf.org X-Mailer: Apple Mail (2.1078) Cc: dime-chairs@tools.ietf.org Subject: Re: [Dime] DIME presentations X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Jul 2010 21:54:45 -0000 We are still missing the slideware for the following agenda presentation = slots: 7) Diameter Network Access Server Application (Glen, = 20min) http://www.ietf.org/id/draft-zorn-dime-rfc4005bis-01 o Need for a bis realized among AAA Doctors - Jouni On Jul 25, 2010, at 6:10 PM, jouni korhonen wrote: > Hello, >=20 > Tuesday DIME WG meeting is approaching. Send your slideware latest = Monday 6pm to the chairs! >=20 > - Jouni & Lionel From mark@azu.ca Tue Jul 27 11:36:34 2010 Return-Path: X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1F7AD3A68C1 for ; Tue, 27 Jul 2010 11:36:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.623 X-Spam-Level: X-Spam-Status: No, score=0.623 tagged_above=-999 required=5 tests=[BAYES_50=0.001, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4NXryHvvHQJn for ; Tue, 27 Jul 2010 11:36:33 -0700 (PDT) Received: from mail-qy0-f172.google.com (mail-qy0-f172.google.com [209.85.216.172]) by core3.amsl.com (Postfix) with ESMTP id 12AE73A67E3 for ; Tue, 27 Jul 2010 11:36:32 -0700 (PDT) Received: by qyk1 with SMTP id 1so2862677qyk.10 for ; Tue, 27 Jul 2010 11:36:54 -0700 (PDT) MIME-Version: 1.0 Received: by 10.224.78.221 with SMTP id m29mr7737508qak.321.1280255814552; Tue, 27 Jul 2010 11:36:54 -0700 (PDT) Received: by 10.231.156.131 with HTTP; Tue, 27 Jul 2010 11:36:54 -0700 (PDT) In-Reply-To: <92BBD1AA-5740-4057-85C7-66D16018FCA5@gmail.com> References: <92BBD1AA-5740-4057-85C7-66D16018FCA5@gmail.com> Date: Tue, 27 Jul 2010 14:36:54 -0400 Message-ID: From: Mark Jones To: dime@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Re: [Dime] last review of RFC3588bis before the proto write-up - please comment X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Jul 2010 18:36:34 -0000 Hi Jouni, I agree with your proposed editorial changes. See inline for my comments on the ABNF issues. On Wed, Jul 21, 2010 at 8:42 AM, jouni korhonen wr= ote: > For the following I must to hear comments _before_ I proceed with the com= pletion of the Proto Write-up: > > =A0o RFC3588bis keeps version as 1 so a RFC3588 node does not really know= if it is > =A0 connecting with another RFC3588 or RFC3588bis node, or vice versa. > In Sections > =A0 5.4.1, 5.4.2, 5.5.1, 5.5.2, and 7.2 we actually _change_ the existing= command > =A0 ABNFs that are more than just adding optional AVPs or sending less AV= Ps than > =A0 before (for example adding *[AVP] to a request, which means the recei= ver may > =A0 see AVPs that are beyond the ABNF it knows). According to the RFC3588= bis > =A0 Section 1.3.3 this could mean an allocation of a new command code, wh= ich again > =A0 would require an allocation of a new application id for applications = using the > =A0 new command.. This would impact backwards compatibility with RFC3588. > Sections 5.4.1, 5.4.2, 5.5.1 and 5.5.2 added *[ AVP ] to DPR/DPA/DWR/DWA respectively. This was presumably added for consistency with the ABNF for other base protocol commands. I view the change as editorial because RFC3588 also says: "An implementation MAY add arbitrary non-mandatory AVPs to any command defined in an application, including vendor-specific AVPs without needing to define a new application." Although this text was reworked in 3588bis, an implementation strictly coded to RFC3588 is not going to barf a 5008 if these commands do contain extra "non-mandatory" AVPs. There is no reason to exclude *[AVP] from these commands and the omission from the ABNF was probably an oversight. I suspect it would have been approved if raised as an Errata on RFC3588. Section 7.2 adds two optional AVPs to an ABNF that already had *[ AVP ] so the new format would not result in 5008 or 5009. The Failed-AVP AVP has the M-bit set but RFC3588 was sufficiently vague on whether mandatory meant presence or comprehension that a 5008 is unlikely. Given the descriptions of the missing AVPs, I think these are clearly oversights and they would have been approved as Errata. > =A0 Can we expect then receiving errors like 5008 and 5009 when the other= end is > =A0 fully RFC3588 compliant and the other is RFC3588bis compliant? Is thi= s unlikely > =A0 to happen? No and no. Silence from the other stack implementers obviously means they agree. ;) > Can a change to AVP multiplicity in ABNF considered such ABNF change > that requires a new command code? It is tough to generalize; Did the ABNF contradict normative text? I think of 3588bis as a collection of Errata. There were several places in RFC3588 where ambiguity could create interop issues. When we've hit those, we've been able to consult (and refer partners to) 3588bis in much the same way as we'd consult Errata. Regards Mark From mark@azu.ca Wed Jul 28 06:22:06 2010 Return-Path: X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EE44C28C0F6 for ; Wed, 28 Jul 2010 06:22:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.677 X-Spam-Level: X-Spam-Status: No, score=-0.677 tagged_above=-999 required=5 tests=[AWL=1.300, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mQZNitZjOWYa for ; Wed, 28 Jul 2010 06:22:06 -0700 (PDT) Received: from mail-iw0-f172.google.com (mail-iw0-f172.google.com [209.85.214.172]) by core3.amsl.com (Postfix) with ESMTP id 151E83A68D9 for ; Wed, 28 Jul 2010 06:22:05 -0700 (PDT) Received: by iwn38 with SMTP id 38so5129854iwn.31 for ; Wed, 28 Jul 2010 06:22:28 -0700 (PDT) MIME-Version: 1.0 Received: by 10.231.172.75 with SMTP id k11mr1033464ibz.4.1280323348795; Wed, 28 Jul 2010 06:22:28 -0700 (PDT) Received: by 10.231.156.131 with HTTP; Wed, 28 Jul 2010 06:22:28 -0700 (PDT) In-Reply-To: <000001cb1a83$cebcd1b0$6c367510$@net> References: <000001cb1a83$cebcd1b0$6c367510$@net> Date: Wed, 28 Jul 2010 09:22:28 -0400 Message-ID: From: Mark Jones To: dime@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Re: [Dime] comments on draft-ietf-dime-extended-naptr-01 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Jul 2010 13:22:07 -0000 Thank you for the review, Glen. I'll fix these issues in the next revision. Regards Mark On Sat, Jul 3, 2010 at 3:46 AM, Glen Zorn wrote: > 1) The last paragraph of Section 3 says: > > =A0 The DNS administrator of some domain SHOULD also > =A0 provision base RFC 3588 style NAPTR records [RFC2915] in order to > =A0 guarantee backwards compatibility with legacy RFC 3588 compliant > =A0 Diameter peers. > > The word "some" doesn't really make sense to me; suggest changing it to > "the" or "a". > > 2) The reference to I-D.ietf-dime-diameter-qos needs to be updated to RFC > 5866. > > Aside from these minor problems, I think that the draft is ready for > publication. > > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime > From sdecugis@nict.go.jp Thu Jul 29 03:08:09 2010 Return-Path: X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BDFFA3A6959 for ; Thu, 29 Jul 2010 03:08:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.134 X-Spam-Level: X-Spam-Status: No, score=0.134 tagged_above=-999 required=5 tests=[BAYES_05=-1.11, HELO_EQ_JP=1.244] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mPSXJUaEb9ms for ; Thu, 29 Jul 2010 03:08:08 -0700 (PDT) Received: from ns1.nict.go.jp (ns1.nict.go.jp [IPv6:2001:2f8:29:300::1]) by core3.amsl.com (Postfix) with ESMTP id E9B6E3A68E7 for ; Thu, 29 Jul 2010 03:08:07 -0700 (PDT) Received: from gw1.nict.go.jp (gw1 [133.243.18.250]) by ns1.nict.go.jp with ESMTP id o6TA8TqZ005910 for ; Thu, 29 Jul 2010 19:08:29 +0900 (JST) Received: from gw1.nict.go.jp (localhost [127.0.0.1]) by gw1.nict.go.jp with ESMTP id o6TA8T8F005435 for ; Thu, 29 Jul 2010 19:08:29 +0900 (JST) Received: from mail1.nict.go.jp (mail.nict.go.jp [133.243.18.3]) by gw1.nict.go.jp with ESMTP id o6TA8SW5005432 for ; Thu, 29 Jul 2010 19:08:28 +0900 (JST) Received: from mail1.nict.go.jp (localhost [127.0.0.1]) by mail1.nict.go.jp (NICT Mail) with ESMTP id E3FC52C4F1 for ; Thu, 29 Jul 2010 19:08:28 +0900 (JST) Received: from [133.243.146.201] (5gou2f-dhcp41.nict.go.jp [133.243.146.201]) by mail1.nict.go.jp (NICT Mail) with ESMTP id DF8892C40E for ; Thu, 29 Jul 2010 19:08:28 +0900 (JST) Message-ID: <4C515310.6000908@nict.go.jp> Date: Thu, 29 Jul 2010 19:08:16 +0900 From: Sebastien Decugis User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; fr; rv:1.9.2.7) Gecko/20100713 Thunderbird/3.1.1 MIME-Version: 1.0 To: "dime@ietf.org" X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [Dime] freeDiameter 1.0.0 released X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Jul 2010 10:08:09 -0000 Dear DiME members, It is my pleasure to announce the first release of freeDiameter, a new open-source implementation of the Diameter protocol. freeDiameter is released under the BSD license. It is written in C, and should run on any modern POSIX system (tested on GNU/Linux and FreeBSD). freeDiameter is designed as a framework: a daemon handles the Diameter Base Protocol operations (network management, messages routing) common to all Diameter nodes, while extensions provide the additional Diameter applications logic to each peer. The daemon is fully compliant to RFC3588 and draft-ietf-dime-rfc3588bis-21, including native support for IPv6, SCTP, and TLS. In this first release, the following extensions are available: - A Diameter EAP server implementation (RFC4072) with support for EAP TLS and MD5 methods (additional methods to be added later). - A Diameter SIP server implementation (RFC4740) -- experimental. - A RADIUS/Diameter translation gateway with support for NASREQ (RFC4005), EAP (RFC4072), SIP (RFC4740) and Accounting (RFC3588) applications. - A simple Diameter Accounting (RFC3588) implementation. freeDiameter also comes with a set of debug tools and mechanisms that may be handy to anyone involved with Diameter. For more information and download information, please visit the freeDiameter homepage at http://www.freediameter.net Thank you, The freeDiameter team. (supported by NICT and Teraoka-Lab., Keio University) -- Sebastien Decugis Research fellow Network Architecture Group NICT (nict.go.jp) From aland@deployingradius.com Thu Jul 29 03:15:03 2010 Return-Path: X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 226B83A63C9 for ; Thu, 29 Jul 2010 03:15:03 -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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EI+VuVgwjXxR for ; Thu, 29 Jul 2010 03:14:59 -0700 (PDT) Received: from liberty.deployingradius.com (liberty.deployingradius.com [88.191.76.128]) by core3.amsl.com (Postfix) with ESMTP id C05853A6964 for ; Thu, 29 Jul 2010 03:14:59 -0700 (PDT) Received: from dhcp-27d6.meeting.ietf.org (dhcp-27d6.meeting.ietf.org [130.129.39.214]) by liberty.deployingradius.com (Postfix) with ESMTPSA id 53DFB12342F5; Thu, 29 Jul 2010 12:15:22 +0200 (CEST) Message-ID: <4C5154BA.30708@deployingradius.com> Date: Thu, 29 Jul 2010 12:15:22 +0200 From: Alan DeKok User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: Sebastien Decugis References: <4C515310.6000908@nict.go.jp> In-Reply-To: <4C515310.6000908@nict.go.jp> X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "dime@ietf.org" Subject: Re: [Dime] freeDiameter 1.0.0 released X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Jul 2010 10:15:03 -0000 Sebastien Decugis wrote: > It is my pleasure to announce the first release of freeDiameter, a new > open-source implementation of the Diameter protocol. We were just talking about this in the AAA doctors meeting. Good timing, and congratulations! Alan DeKok. From jouni.nospam@gmail.com Thu Jul 29 08:39:39 2010 Return-Path: X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DA77228C105 for ; Thu, 29 Jul 2010 08:39: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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3M4wuipM4Kqt for ; Thu, 29 Jul 2010 08:39:35 -0700 (PDT) Received: from mail-ey0-f172.google.com (mail-ey0-f172.google.com [209.85.215.172]) by core3.amsl.com (Postfix) with ESMTP id 59FED3A6802 for ; Thu, 29 Jul 2010 08:39:35 -0700 (PDT) Received: by eyb7 with SMTP id 7so216646eyb.31 for ; Thu, 29 Jul 2010 08:39:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:subject:mime-version :content-type:from:in-reply-to:date:cc:content-transfer-encoding :message-id:references:to:x-mailer; bh=FFn0pFoOKf5tkx1i3mlpNhra8o+qk5XHLUwkJsjmchw=; b=mmJ8RfxIBPwQqVXLIwJcN4ug+rzpD4EKZCxQdVMt847Jjt3QZHbTL+VPkQaD9aqq2y kzxlhdVkudP5YRXMjnovOl9QGkmFup/zoERrFAyEPf/rs7MXgNRhB6yN14IVMabbFJ7F tqKjeGk/qen+SAO4n+vUq1fvymxM+RTJiAdIM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; b=kmhWyEL8NRhX5421m+wN9/ESQvlCb1OBjqGmU4pELrf9RwoLD41Rz6Yr1paHT5GMmU 8+/94iyR8OER0Ht06VaE3Ks0CoLoCzUg3BJ7iT5+eqrhLn0LLvM6IBc541Vm3Z2nKpii RXhnoD0W01I443p32/pcsH56ey3hPoicOGZTw= Received: by 10.14.6.203 with SMTP id 51mr239222een.51.1280417971366; Thu, 29 Jul 2010 08:39:31 -0700 (PDT) Received: from dhcp-67f0.meeting.ietf.org (dhcp-67f0.meeting.ietf.org [130.129.103.240]) by mx.google.com with ESMTPS id v59sm1431765eeh.4.2010.07.29.08.39.16 (version=TLSv1/SSLv3 cipher=RC4-MD5); Thu, 29 Jul 2010 08:39:19 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1078) Content-Type: text/plain; charset=us-ascii From: jouni korhonen In-Reply-To: Date: Thu, 29 Jul 2010 18:39:15 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: References: <92BBD1AA-5740-4057-85C7-66D16018FCA5@gmail.com> To: Mark Jones X-Mailer: Apple Mail (2.1078) Cc: dime@ietf.org Subject: Re: [Dime] last review of RFC3588bis before the proto write-up - please comment X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Jul 2010 15:39:40 -0000 Hi Mark, Thanks for the quick reply. Read below.. On Jul 27, 2010, at 9:36 PM, Mark Jones wrote: > Hi Jouni, >=20 > I agree with your proposed editorial changes. See inline for my > comments on the ABNF issues. Ack. >=20 > On Wed, Jul 21, 2010 at 8:42 AM, jouni korhonen = wrote: >> For the following I must to hear comments _before_ I proceed with the = completion of the Proto Write-up: >>=20 >> o RFC3588bis keeps version as 1 so a RFC3588 node does not really = know if it is >> connecting with another RFC3588 or RFC3588bis node, or vice versa. >> In Sections >> 5.4.1, 5.4.2, 5.5.1, 5.5.2, and 7.2 we actually _change_ the = existing command >> ABNFs that are more than just adding optional AVPs or sending less = AVPs than >> before (for example adding *[AVP] to a request, which means the = receiver may >> see AVPs that are beyond the ABNF it knows). According to the = RFC3588bis >> Section 1.3.3 this could mean an allocation of a new command code, = which again >> would require an allocation of a new application id for = applications using the >> new command.. This would impact backwards compatibility with = RFC3588. >>=20 >=20 > Sections 5.4.1, 5.4.2, 5.5.1 and 5.5.2 added *[ AVP ] to > DPR/DPA/DWR/DWA respectively. This was presumably added for > consistency with the ABNF for other base protocol commands. I view the > change as editorial because RFC3588 also says: >=20 > "An implementation MAY add arbitrary non-mandatory AVPs to any = command > defined in an application, including vendor-specific AVPs without > needing to define a new application." >=20 > Although this text was reworked in 3588bis, an implementation strictly > coded to RFC3588 is not going to barf a 5008 if these commands do > contain extra "non-mandatory" AVPs. Personally I tend to agree. Some implementations I know just ignore = excess AVPs outside ABFN with M=3D0, and continue processing the command = like nothing happened. I.e. the assumed behavior from Section 1.2.3 = quoted above.. =20 > There is no reason to exclude *[AVP] from these commands and the > omission from the ABNF was probably an oversight. I suspect it would > have been approved if raised as an Errata on RFC3588. >=20 > Section 7.2 adds two optional AVPs to an ABNF that already had *[ AVP > ] so the new format would not result in 5008 or 5009. The Failed-AVP Ok. > AVP has the M-bit set but RFC3588 was sufficiently vague on whether > mandatory meant presence or comprehension that a 5008 is unlikely. > Given the descriptions of the missing AVPs, I think these are clearly > oversights and they would have been approved as Errata. Right. Actually when reading Section 7 onwards then remaining text makes = it quite clear that Failed-AVP is part of the error. Following that I = would also add [Experimental-Result] to the Section 7.2 ABNF (as that = AVP also has M=3D1). >=20 >> Can we expect then receiving errors like 5008 and 5009 when the = other end is >> fully RFC3588 compliant and the other is RFC3588bis compliant? Is = this unlikely >> to happen? >=20 > No and no. Silence from the other stack implementers obviously means > they agree. ;) Right, hearing more opinions wouldn't make harm though. >=20 >> Can a change to AVP multiplicity in ABNF considered such ABNF change >> that requires a new command code? >=20 > It is tough to generalize; Did the ABNF contradict normative text? >=20 > I think of 3588bis as a collection of Errata. There were several > places in RFC3588 where ambiguity could create interop issues. When > we've hit those, we've been able to consult (and refer partners to) > 3588bis in much the same way as we'd consult Errata. Ok. - Jouni >=20 > Regards > Mark > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime From jouni.nospam@gmail.com Thu Jul 29 08:51:39 2010 Return-Path: X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AC8DE3A681F for ; Thu, 29 Jul 2010 08:51: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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5wPiIN635yQK for ; Thu, 29 Jul 2010 08:51:38 -0700 (PDT) Received: from mail-ew0-f44.google.com (mail-ew0-f44.google.com [209.85.215.44]) by core3.amsl.com (Postfix) with ESMTP id 4070D3A679F for ; Thu, 29 Jul 2010 08:51:38 -0700 (PDT) Received: by ewy22 with SMTP id 22so250382ewy.31 for ; Thu, 29 Jul 2010 08:52:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:subject:mime-version :content-type:from:in-reply-to:date:cc:content-transfer-encoding :message-id:references:to:x-mailer; bh=FFn0pFoOKf5tkx1i3mlpNhra8o+qk5XHLUwkJsjmchw=; b=o/N43IzhSTabyhZCnvef+qRfBnO7tKtP5d0AqQONCvZRlmX1O4jSDIwg/8PkOYk4Kg q+IiGDHMM5eX+7B4xFerLOAji3y2rE2hh7Q7BhL5ekfv3Hy2EwawDss2jyscJ0MrWfLS wke+KFmtaDrgYQ95pV22jc/dRbTnDGUtUigUA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; b=kmhWyEL8NRhX5421m+wN9/ESQvlCb1OBjqGmU4pELrf9RwoLD41Rz6Yr1paHT5GMmU 8+/94iyR8OER0Ht06VaE3Ks0CoLoCzUg3BJ7iT5+eqrhLn0LLvM6IBc541Vm3Z2nKpii RXhnoD0W01I443p32/pcsH56ey3hPoicOGZTw= Received: by 10.213.32.17 with SMTP id a17mr269617ebd.11.1280418721488; Thu, 29 Jul 2010 08:52:01 -0700 (PDT) Received: from dhcp-67f0.meeting.ietf.org (dhcp-67f0.meeting.ietf.org [130.129.103.240]) by mx.google.com with ESMTPS id v8sm1447077eeh.2.2010.07.29.08.51.56 (version=TLSv1/SSLv3 cipher=RC4-MD5); Thu, 29 Jul 2010 08:51:57 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1078) Content-Type: text/plain; charset=us-ascii From: jouni korhonen In-Reply-To: Date: Thu, 29 Jul 2010 18:39:15 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: References: <92BBD1AA-5740-4057-85C7-66D16018FCA5@gmail.com> To: Mark Jones X-Mailer: Apple Mail (2.1078) Cc: dime@ietf.org Subject: Re: [Dime] last review of RFC3588bis before the proto write-up - please comment X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Jul 2010 15:51:39 -0000 Hi Mark, Thanks for the quick reply. Read below.. On Jul 27, 2010, at 9:36 PM, Mark Jones wrote: > Hi Jouni, >=20 > I agree with your proposed editorial changes. See inline for my > comments on the ABNF issues. Ack. >=20 > On Wed, Jul 21, 2010 at 8:42 AM, jouni korhonen = wrote: >> For the following I must to hear comments _before_ I proceed with the = completion of the Proto Write-up: >>=20 >> o RFC3588bis keeps version as 1 so a RFC3588 node does not really = know if it is >> connecting with another RFC3588 or RFC3588bis node, or vice versa. >> In Sections >> 5.4.1, 5.4.2, 5.5.1, 5.5.2, and 7.2 we actually _change_ the = existing command >> ABNFs that are more than just adding optional AVPs or sending less = AVPs than >> before (for example adding *[AVP] to a request, which means the = receiver may >> see AVPs that are beyond the ABNF it knows). According to the = RFC3588bis >> Section 1.3.3 this could mean an allocation of a new command code, = which again >> would require an allocation of a new application id for = applications using the >> new command.. This would impact backwards compatibility with = RFC3588. >>=20 >=20 > Sections 5.4.1, 5.4.2, 5.5.1 and 5.5.2 added *[ AVP ] to > DPR/DPA/DWR/DWA respectively. This was presumably added for > consistency with the ABNF for other base protocol commands. I view the > change as editorial because RFC3588 also says: >=20 > "An implementation MAY add arbitrary non-mandatory AVPs to any = command > defined in an application, including vendor-specific AVPs without > needing to define a new application." >=20 > Although this text was reworked in 3588bis, an implementation strictly > coded to RFC3588 is not going to barf a 5008 if these commands do > contain extra "non-mandatory" AVPs. Personally I tend to agree. Some implementations I know just ignore = excess AVPs outside ABFN with M=3D0, and continue processing the command = like nothing happened. I.e. the assumed behavior from Section 1.2.3 = quoted above.. =20 > There is no reason to exclude *[AVP] from these commands and the > omission from the ABNF was probably an oversight. I suspect it would > have been approved if raised as an Errata on RFC3588. >=20 > Section 7.2 adds two optional AVPs to an ABNF that already had *[ AVP > ] so the new format would not result in 5008 or 5009. The Failed-AVP Ok. > AVP has the M-bit set but RFC3588 was sufficiently vague on whether > mandatory meant presence or comprehension that a 5008 is unlikely. > Given the descriptions of the missing AVPs, I think these are clearly > oversights and they would have been approved as Errata. Right. Actually when reading Section 7 onwards then remaining text makes = it quite clear that Failed-AVP is part of the error. Following that I = would also add [Experimental-Result] to the Section 7.2 ABNF (as that = AVP also has M=3D1). >=20 >> Can we expect then receiving errors like 5008 and 5009 when the = other end is >> fully RFC3588 compliant and the other is RFC3588bis compliant? Is = this unlikely >> to happen? >=20 > No and no. Silence from the other stack implementers obviously means > they agree. ;) Right, hearing more opinions wouldn't make harm though. >=20 >> Can a change to AVP multiplicity in ABNF considered such ABNF change >> that requires a new command code? >=20 > It is tough to generalize; Did the ABNF contradict normative text? >=20 > I think of 3588bis as a collection of Errata. There were several > places in RFC3588 where ambiguity could create interop issues. When > we've hit those, we've been able to consult (and refer partners to) > 3588bis in much the same way as we'd consult Errata. Ok. - Jouni >=20 > Regards > Mark > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime From jouni.nospam@gmail.com Thu Jul 29 08:51:49 2010 Return-Path: X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8143228C172 for ; Thu, 29 Jul 2010 08:51:49 -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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9NtHGtxASqIB for ; Thu, 29 Jul 2010 08:51:46 -0700 (PDT) Received: from mail-ey0-f172.google.com (mail-ey0-f172.google.com [209.85.215.172]) by core3.amsl.com (Postfix) with ESMTP id 696AF3A679F for ; Thu, 29 Jul 2010 08:51:46 -0700 (PDT) Received: by eyb7 with SMTP id 7so229142eyb.31 for ; Thu, 29 Jul 2010 08:52:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:subject:mime-version :content-type:from:in-reply-to:date:cc:content-transfer-encoding :message-id:references:to:x-mailer; bh=z2F3BzPyXQZQd3HR+V9frsJGPknkbiKeoDqWXd5skyk=; b=QBPRNixd1wyFN9/tl4pcT+Qs4Qk50Qpt1eyT87r7WZNV03zsq6CLC0wUYLdSKVjypb Te3DEUzLXwRuxTvFMpumwyJx3XWRGYCaVnC5moRULUAX0XRkO0UJ/RAQJey/m9rNKmKQ DzZs9NX+yEkFYeX6IUR2c+S31uNlm2rwdY1Ww= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; b=mapAKQyeSPLnFxzxE9z6mjcFFeNT9rrInQPjWwn41JvduCFBa7piAVUatY0z715wfZ pnEWXbD5ANwZJ9eVYt9XHrKT7+E2trxFodorqU7ZVfRAf5ey50KxEJBdA/Dni19pZ/5G mTlQbzq/yxgR8sdCSsRgjtgGvz+yykszdNKV8= Received: by 10.213.4.81 with SMTP id 17mr6208764ebq.97.1280418729782; Thu, 29 Jul 2010 08:52:09 -0700 (PDT) Received: from dhcp-67f0.meeting.ietf.org (dhcp-67f0.meeting.ietf.org [130.129.103.240]) by mx.google.com with ESMTPS id v8sm1447077eeh.2.2010.07.29.08.52.08 (version=TLSv1/SSLv3 cipher=RC4-MD5); Thu, 29 Jul 2010 08:52:08 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1078) Content-Type: text/plain; charset=us-ascii From: jouni korhonen In-Reply-To: Date: Thu, 29 Jul 2010 18:51:57 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <36827A5B-B697-41D7-BAA3-D9D79650B447@gmail.com> References: <92BBD1AA-5740-4057-85C7-66D16018FCA5@gmail.com> To: Mark Jones X-Mailer: Apple Mail (2.1078) Cc: dime@ietf.org Subject: Re: [Dime] last review of RFC3588bis before the proto write-up - please comment X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Jul 2010 15:51:49 -0000 Hi Mark, Thanks for the quick reply. Read below.. On Jul 27, 2010, at 9:36 PM, Mark Jones wrote: > Hi Jouni, >=20 > I agree with your proposed editorial changes. See inline for my > comments on the ABNF issues. Ack. >=20 > On Wed, Jul 21, 2010 at 8:42 AM, jouni korhonen = wrote: >> For the following I must to hear comments _before_ I proceed with the = completion of the Proto Write-up: >>=20 >> o RFC3588bis keeps version as 1 so a RFC3588 node does not really = know if it is >> connecting with another RFC3588 or RFC3588bis node, or vice versa. >> In Sections >> 5.4.1, 5.4.2, 5.5.1, 5.5.2, and 7.2 we actually _change_ the = existing command >> ABNFs that are more than just adding optional AVPs or sending less = AVPs than >> before (for example adding *[AVP] to a request, which means the = receiver may >> see AVPs that are beyond the ABNF it knows). According to the = RFC3588bis >> Section 1.3.3 this could mean an allocation of a new command code, = which again >> would require an allocation of a new application id for applications = using the >> new command.. This would impact backwards compatibility with = RFC3588. >>=20 >=20 > Sections 5.4.1, 5.4.2, 5.5.1 and 5.5.2 added *[ AVP ] to > DPR/DPA/DWR/DWA respectively. This was presumably added for > consistency with the ABNF for other base protocol commands. I view the > change as editorial because RFC3588 also says: >=20 > "An implementation MAY add arbitrary non-mandatory AVPs to any = command > defined in an application, including vendor-specific AVPs without > needing to define a new application." >=20 > Although this text was reworked in 3588bis, an implementation strictly > coded to RFC3588 is not going to barf a 5008 if these commands do > contain extra "non-mandatory" AVPs. Personally I tend to agree. Some implementations I know just ignore = excess AVPs outside ABFN with M=3D0, and continue processing the command = like nothing happened. I.e. the assumed behavior from Section 1.2.3 = quoted above.. =20 > There is no reason to exclude *[AVP] from these commands and the > omission from the ABNF was probably an oversight. I suspect it would > have been approved if raised as an Errata on RFC3588. >=20 > Section 7.2 adds two optional AVPs to an ABNF that already had *[ AVP > ] so the new format would not result in 5008 or 5009. The Failed-AVP Ok. > AVP has the M-bit set but RFC3588 was sufficiently vague on whether > mandatory meant presence or comprehension that a 5008 is unlikely. > Given the descriptions of the missing AVPs, I think these are clearly > oversights and they would have been approved as Errata. Right. Actually when reading Section 7 onwards then remaining text makes = it quite clear that Failed-AVP is part of the error. Following that I = would also add [Experimental-Result] to the Section 7.2 ABNF (as that = AVP also has M=3D1). >=20 >> Can we expect then receiving errors like 5008 and 5009 when the = other end is >> fully RFC3588 compliant and the other is RFC3588bis compliant? Is = this unlikely >> to happen? >=20 > No and no. Silence from the other stack implementers obviously means > they agree. ;) Right, hearing more opinions wouldn't make harm though. >=20 >> Can a change to AVP multiplicity in ABNF considered such ABNF change >> that requires a new command code? >=20 > It is tough to generalize; Did the ABNF contradict normative text? >=20 > I think of 3588bis as a collection of Errata. There were several > places in RFC3588 where ambiguity could create interop issues. When > we've hit those, we've been able to consult (and refer partners to) > 3588bis in much the same way as we'd consult Errata. Ok. - Jouni >=20 > Regards > Mark > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime From lionel.morand@orange-ftgroup.com Thu Jul 29 12:06:14 2010 Return-Path: X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DC8EA3A6894 for ; Thu, 29 Jul 2010 12:06:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.898 X-Spam-Level: X-Spam-Status: No, score=-2.898 tagged_above=-999 required=5 tests=[AWL=0.351, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YqZ9VbW8sDtt for ; Thu, 29 Jul 2010 12:06:13 -0700 (PDT) Received: from p-mail1.rd.francetelecom.com (p-mail1.rd.francetelecom.com [195.101.245.15]) by core3.amsl.com (Postfix) with ESMTP id 5F85F3A683A for ; Thu, 29 Jul 2010 12:06:13 -0700 (PDT) Received: from p-mail1.rd.francetelecom.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id B64AF93000D; Thu, 29 Jul 2010 18:28:44 +0200 (CEST) Received: from ftrdsmtp2.rd.francetelecom.fr (unknown [10.192.128.47]) by p-mail1.rd.francetelecom.com (Postfix) with ESMTP id AE99E93000A; Thu, 29 Jul 2010 18:28:44 +0200 (CEST) Received: from ftrdmel1.rd.francetelecom.fr ([10.192.128.40]) by ftrdsmtp2.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.3959); Thu, 29 Jul 2010 18:28:16 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Thu, 29 Jul 2010 18:28:14 +0200 Message-ID: In-Reply-To: <36827A5B-B697-41D7-BAA3-D9D79650B447@gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] last review of RFC3588bis before the proto write-up -please comment Thread-Index: AcsvNgVoSZCpgJS+SzqUs0Jt0MRXPgABHXDg References: <92BBD1AA-5740-4057-85C7-66D16018FCA5@gmail.com> <36827A5B-B697-41D7-BAA3-D9D79650B447@gmail.com> From: To: , X-OriginalArrivalTime: 29 Jul 2010 16:28:16.0588 (UTC) FILETIME=[0C4908C0:01CB2F3B] Cc: dime@ietf.org Subject: Re: [Dime] last review of RFC3588bis before the proto write-up -please comment X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Jul 2010 19:06:15 -0000 I agree with Mark understanding, regarding to addition of missing *[AVP] = in some commands and decision to keep the version number unchanged. It would be great if other WG members confirm/contradict these = statements. Cheers, Lionel=20 > -----Message d'origine----- > De : dime-bounces@ietf.org [mailto:dime-bounces@ietf.org] De=20 > la part de jouni korhonen > Envoy=E9 : jeudi 29 juillet 2010 17:52 > =C0 : Mark Jones > Cc : dime@ietf.org > Objet : Re: [Dime] last review of RFC3588bis before the proto=20 > write-up -please comment >=20 > Hi Mark, >=20 > Thanks for the quick reply. Read below.. >=20 >=20 > On Jul 27, 2010, at 9:36 PM, Mark Jones wrote: >=20 > > Hi Jouni, > >=20 > > I agree with your proposed editorial changes. See inline for my=20 > > comments on the ABNF issues. >=20 > Ack. >=20 >=20 > >=20 > > On Wed, Jul 21, 2010 at 8:42 AM, jouni korhonen=20 > wrote: > >> For the following I must to hear comments _before_ I=20 > proceed with the completion of the Proto Write-up: > >>=20 > >> o RFC3588bis keeps version as 1 so a RFC3588 node does not really=20 > >> know if it is connecting with another RFC3588 or=20 > RFC3588bis node, or vice versa. > >> In Sections > >> 5.4.1, 5.4.2, 5.5.1, 5.5.2, and 7.2 we actually _change_ the=20 > >> existing command ABNFs that are more than just adding=20 > optional AVPs=20 > >> or sending less AVPs than before (for example adding *[AVP] to a=20 > >> request, which means the receiver may see AVPs that are=20 > beyond the=20 > >> ABNF it knows). According to the RFC3588bis Section 1.3.3=20 > this could=20 > >> mean an allocation of a new command code, which again =20 > would require=20 > >> an allocation of a new application id for applications=20 > using the new command.. This would impact backwards=20 > compatibility with RFC3588. > >>=20 > >=20 > > Sections 5.4.1, 5.4.2, 5.5.1 and 5.5.2 added *[ AVP ] to=20 > > DPR/DPA/DWR/DWA respectively. This was presumably added for=20 > > consistency with the ABNF for other base protocol commands.=20 > I view the=20 > > change as editorial because RFC3588 also says: > >=20 > > "An implementation MAY add arbitrary non-mandatory AVPs to any=20 > > command defined in an application, including vendor-specific AVPs=20 > > without needing to define a new application." > >=20 > > Although this text was reworked in 3588bis, an=20 > implementation strictly=20 > > coded to RFC3588 is not going to barf a 5008 if these commands do=20 > > contain extra "non-mandatory" AVPs. >=20 > Personally I tend to agree. Some implementations I know just=20 > ignore excess AVPs outside ABFN with M=3D0, and continue=20 > processing the command like nothing happened. I.e. the=20 > assumed behavior from Section 1.2.3 quoted above.. =20 >=20 > > There is no reason to exclude *[AVP] from these commands and the=20 > > omission from the ABNF was probably an oversight. I suspect=20 > it would=20 > > have been approved if raised as an Errata on RFC3588. > >=20 > > Section 7.2 adds two optional AVPs to an ABNF that already=20 > had *[ AVP=20 > > ] so the new format would not result in 5008 or 5009. The Failed-AVP >=20 > Ok. >=20 > > AVP has the M-bit set but RFC3588 was sufficiently vague on whether=20 > > mandatory meant presence or comprehension that a 5008 is unlikely. > > Given the descriptions of the missing AVPs, I think these=20 > are clearly=20 > > oversights and they would have been approved as Errata. >=20 > Right. Actually when reading Section 7 onwards then remaining=20 > text makes it quite clear that Failed-AVP is part of the=20 > error. Following that I would also add [Experimental-Result]=20 > to the Section 7.2 ABNF (as that AVP also has M=3D1). > >=20 > >> Can we expect then receiving errors like 5008 and 5009 when the=20 > >> other end is fully RFC3588 compliant and the other is RFC3588bis=20 > >> compliant? Is this unlikely to happen? > >=20 > > No and no. Silence from the other stack implementers=20 > obviously means=20 > > they agree. ;) >=20 > Right, hearing more opinions wouldn't make harm though. >=20 > >=20 > >> Can a change to AVP multiplicity in ABNF considered such=20 > ABNF change=20 > >> that requires a new command code? > >=20 > > It is tough to generalize; Did the ABNF contradict normative text? > >=20 > > I think of 3588bis as a collection of Errata. There were several=20 > > places in RFC3588 where ambiguity could create interop issues. When=20 > > we've hit those, we've been able to consult (and refer partners to)=20 > > 3588bis in much the same way as we'd consult Errata. >=20 > Ok. >=20 >=20 > - Jouni >=20 >=20 > >=20 > > Regards > > Mark > > _______________________________________________ > > DiME mailing list > > DiME@ietf.org > > https://www.ietf.org/mailman/listinfo/dime >=20 > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime >=20 From sdecugis@nict.go.jp Thu Jul 29 20:37:41 2010 Return-Path: X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0B57E3A683C for ; Thu, 29 Jul 2010 20:37:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.611 X-Spam-Level: X-Spam-Status: No, score=-0.611 tagged_above=-999 required=5 tests=[AWL=0.744, BAYES_00=-2.599, HELO_EQ_JP=1.244] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TItxYqlSfvpV for ; Thu, 29 Jul 2010 20:37:38 -0700 (PDT) Received: from ns2.nict.go.jp (ns2.nict.go.jp [IPv6:2001:2f8:29:300::2]) by core3.amsl.com (Postfix) with ESMTP id B5E203A65A6 for ; Thu, 29 Jul 2010 20:37:36 -0700 (PDT) Received: from gw2.nict.go.jp (gw2 [133.243.18.251]) by ns2.nict.go.jp with ESMTP id o6U3buLL001645 for ; Fri, 30 Jul 2010 12:37:56 +0900 (JST) Received: from gw2.nict.go.jp (localhost [127.0.0.1]) by gw2.nict.go.jp with ESMTP id o6U3bumv000068 for ; Fri, 30 Jul 2010 12:37:56 +0900 (JST) Received: from mail2.nict.go.jp (mail.nict.go.jp [133.243.18.3]) by gw2.nict.go.jp with ESMTP id o6U3buiJ000065 for ; Fri, 30 Jul 2010 12:37:56 +0900 (JST) Received: from mail2.nict.go.jp (localhost [127.0.0.1]) by mail2.nict.go.jp (NICT Mail) with ESMTP id 8102D1633F for ; Fri, 30 Jul 2010 12:37:56 +0900 (JST) Received: from [133.243.146.201] (5gou2f-dhcp41.nict.go.jp [133.243.146.201]) by mail2.nict.go.jp (NICT Mail) with ESMTP id 7C1E916337 for ; Fri, 30 Jul 2010 12:37:56 +0900 (JST) Message-ID: <4C524906.8070103@nict.go.jp> Date: Fri, 30 Jul 2010 12:37:42 +0900 From: Sebastien Decugis User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; fr; rv:1.9.2.7) Gecko/20100713 Thunderbird/3.1.1 MIME-Version: 1.0 To: dime@ietf.org References: <92BBD1AA-5740-4057-85C7-66D16018FCA5@gmail.com> <36827A5B-B697-41D7-BAA3-D9D79650B447@gmail.com> In-Reply-To: X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Subject: Re: [Dime] last review of RFC3588bis before the proto write-up -please comment X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Jul 2010 03:37:41 -0000 I also agree with these statements. Beside, it is possible in many cases for a peer to decide whether the remote peer is RFC3588 or rfc3588bis as a side effect of the new security mechanism (indicated by the Inband-Security-Id AVP in the CER/CEA exchange), in case an implementation really needs to know it. Best regards, Sebastien. Le 30/07/2010 01:28, lionel.morand@orange-ftgroup.com a écrit : > I agree with Mark understanding, regarding to addition of missing *[AVP] in some commands and decision to keep the version number unchanged. > It would be great if other WG members confirm/contradict these statements. > > Cheers, > > Lionel > >> -----Message d'origine----- >> De : dime-bounces@ietf.org [mailto:dime-bounces@ietf.org] De >> la part de jouni korhonen >> Envoyé : jeudi 29 juillet 2010 17:52 >> À : Mark Jones >> Cc : dime@ietf.org >> Objet : Re: [Dime] last review of RFC3588bis before the proto >> write-up -please comment >> >> Hi Mark, >> >> Thanks for the quick reply. Read below.. >> >> >> On Jul 27, 2010, at 9:36 PM, Mark Jones wrote: >> >>> Hi Jouni, >>> >>> I agree with your proposed editorial changes. See inline for my >>> comments on the ABNF issues. >> Ack. >> >> >>> On Wed, Jul 21, 2010 at 8:42 AM, jouni korhonen >> wrote: >>>> For the following I must to hear comments _before_ I >> proceed with the completion of the Proto Write-up: >>>> o RFC3588bis keeps version as 1 so a RFC3588 node does not really >>>> know if it is connecting with another RFC3588 or >> RFC3588bis node, or vice versa. >>>> In Sections >>>> 5.4.1, 5.4.2, 5.5.1, 5.5.2, and 7.2 we actually _change_ the >>>> existing command ABNFs that are more than just adding >> optional AVPs >>>> or sending less AVPs than before (for example adding *[AVP] to a >>>> request, which means the receiver may see AVPs that are >> beyond the >>>> ABNF it knows). According to the RFC3588bis Section 1.3.3 >> this could >>>> mean an allocation of a new command code, which again >> would require >>>> an allocation of a new application id for applications >> using the new command.. This would impact backwards >> compatibility with RFC3588. >>> Sections 5.4.1, 5.4.2, 5.5.1 and 5.5.2 added *[ AVP ] to >>> DPR/DPA/DWR/DWA respectively. This was presumably added for >>> consistency with the ABNF for other base protocol commands. >> I view the >>> change as editorial because RFC3588 also says: >>> >>> "An implementation MAY add arbitrary non-mandatory AVPs to any >>> command defined in an application, including vendor-specific AVPs >>> without needing to define a new application." >>> >>> Although this text was reworked in 3588bis, an >> implementation strictly >>> coded to RFC3588 is not going to barf a 5008 if these commands do >>> contain extra "non-mandatory" AVPs. >> Personally I tend to agree. Some implementations I know just >> ignore excess AVPs outside ABFN with M=0, and continue >> processing the command like nothing happened. I.e. the >> assumed behavior from Section 1.2.3 quoted above.. >> >>> There is no reason to exclude *[AVP] from these commands and the >>> omission from the ABNF was probably an oversight. I suspect >> it would >>> have been approved if raised as an Errata on RFC3588. >>> >>> Section 7.2 adds two optional AVPs to an ABNF that already >> had *[ AVP >>> ] so the new format would not result in 5008 or 5009. The Failed-AVP >> Ok. >> >>> AVP has the M-bit set but RFC3588 was sufficiently vague on whether >>> mandatory meant presence or comprehension that a 5008 is unlikely. >>> Given the descriptions of the missing AVPs, I think these >> are clearly >>> oversights and they would have been approved as Errata. >> Right. Actually when reading Section 7 onwards then remaining >> text makes it quite clear that Failed-AVP is part of the >> error. Following that I would also add [Experimental-Result] >> to the Section 7.2 ABNF (as that AVP also has M=1). >>>> Can we expect then receiving errors like 5008 and 5009 when the >>>> other end is fully RFC3588 compliant and the other is RFC3588bis >>>> compliant? Is this unlikely to happen? >>> No and no. Silence from the other stack implementers >> obviously means >>> they agree. ;) >> Right, hearing more opinions wouldn't make harm though. >> >>>> Can a change to AVP multiplicity in ABNF considered such >> ABNF change >>>> that requires a new command code? >>> It is tough to generalize; Did the ABNF contradict normative text? >>> >>> I think of 3588bis as a collection of Errata. There were several >>> places in RFC3588 where ambiguity could create interop issues. When >>> we've hit those, we've been able to consult (and refer partners to) >>> 3588bis in much the same way as we'd consult Errata. >> Ok. >> >> >> - Jouni >> >> >>> Regards >>> Mark >>> _______________________________________________ >>> DiME mailing list >>> DiME@ietf.org >>> https://www.ietf.org/mailman/listinfo/dime >> _______________________________________________ >> DiME mailing list >> DiME@ietf.org >> https://www.ietf.org/mailman/listinfo/dime >> > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime -- Sebastien Decugis Research fellow Network Architecture Group NICT (nict.go.jp)