From nobody Tue Jan 3 02:22:32 2017 Return-Path: X-Original-To: aaa-doctors@ietfa.amsl.com Delivered-To: aaa-doctors@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5FAD1129500; Tue, 3 Jan 2017 02:22:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.593 X-Spam-Level: X-Spam-Status: No, score=-2.593 tagged_above=-999 required=5 tests=[BAD_CREDIT=2.415, BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-3.1, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9p0Hjn3BGQJe; Tue, 3 Jan 2017 02:22:28 -0800 (PST) Received: from relais-inet.orange.com (mta241.mail.business.static.orange.com [80.12.66.41]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1C1CB129434; Tue, 3 Jan 2017 02:22:27 -0800 (PST) Received: from opfedar05.francetelecom.fr (unknown [xx.xx.xx.7]) by opfedar26.francetelecom.fr (ESMTP service) with ESMTP id 51DE01C0C00; Tue, 3 Jan 2017 11:22:26 +0100 (CET) Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.57]) by opfedar05.francetelecom.fr (ESMTP service) with ESMTP id 2F30360064; Tue, 3 Jan 2017 11:22:26 +0100 (CET) Received: from OPEXCLILM43.corporate.adroot.infra.ftgroup ([fe80::ec23:902:c31f:731c]) by OPEXCLILM23.corporate.adroot.infra.ftgroup ([fe80::787e:db0c:23c4:71b3%19]) with mapi id 14.03.0319.002; Tue, 3 Jan 2017 11:22:25 +0100 From: To: Benoit Claise , "aaa-doctors@ietf.org" , "sec-ads@ietf.org" Thread-Topic: [AAA-DOCTORS] Fwd: [Technical Errata Reported] RFC4006 (4892) Thread-Index: AQHSWeL84EnpJ9EndkmU6ufRj5ZM+aEmof+w Date: Tue, 3 Jan 2017 10:22:25 +0000 Message-ID: <784_1483438946_586B7B62_784_1775_1_6B7134B31289DC4FAF731D844122B36E0BFC5C89@OPEXCLILM43.corporate.adroot.infra.ftgroup> References: <20161219091457.EF44BB80224@rfc-editor.org> In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.5] Content-Type: multipart/alternative; boundary="_000_6B7134B31289DC4FAF731D844122B36E0BFC5C89OPEXCLILM43corp_" MIME-Version: 1.0 Archived-At: Cc: "Bertz, Lyle T \[CTO\]" , Dave Dolson Subject: Re: [AAA-DOCTORS] Fwd: [Technical Errata Reported] RFC4006 (4892) X-BeenThere: aaa-doctors@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: AAA Doctors E-mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Jan 2017 10:22:30 -0000 --_000_6B7134B31289DC4FAF731D844122B36E0BFC5C89OPEXCLILM43corp_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable If I'm correct, this is not an erratum against 4006 but a proposed change i= n the draft RFC4006bis (https://tools.ietf.org/html/draft-ietf-dime-rfc4006= bis-00). The original text quoted below is not in the RFC4006 but in the draft. Let me know if I'm correct. Regards, Lionel De : AAA-DOCTORS [mailto:aaa-doctors-bounces@ietf.org] De la part de Benoit= Claise Envoy=E9 : lundi 19 d=E9cembre 2016 11:31 =C0 : aaa-doctors@ietf.org; sec-ads@ietf.org Objet : [AAA-DOCTORS] Fwd: [Technical Errata Reported] RFC4006 (4892) Dear all, What do you think? Regards, Benoit -------- Forwarded Message -------- Subject: [Technical Errata Reported] RFC4006 (4892) Date: Mon, 19 Dec 2016 01:14:57 -0800 From: RFC Errata System To: Harri.Hakala@ericsson.com, Leena.Mattila@= ericsson.com, juha-pekka.koskinen@nokia.= com, marco.stura@nokia.com, John.Loughney@nokia.com, bclaise@cisco.com, joelja@bogus.com, Bernard_Aboba@hotmail.com= , david@mitton.com, john.loughney@nokia.com CC: dengzhenjie@huawei.com, rfc-editor@rfc-edito= r.org The following errata report has been submitted for RFC4006, "Diameter Credit-Control Application". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=3D4006&eid=3D4892 -------------------------------------- Type: Technical Reported by: dengzhenjie Section: 7 Original Text ------------- | PendingU | CC update answer received | Terminate | Idle | | | with result code equal to | end user's | | | | CREDIT_CONTROL_NOT_APPLICABLE | service | | Corrected Text -------------- | PendingU | CC update answer received | Grant | Idle | | | with result code equal to | service to| | | | CREDIT_CONTROL_NOT_APPLICABLE | end user | | Notes ----- Note that in Section 9, It said: when the result code in the CCA is DIAMETER_CREDIT_CONTROL_NOT_APPLICABLE= 4011, it indicates that the credit-control server determines that the serv= ice can be granted to the end user but that no further credit-control is ne= eded for the service (e.g., service is free of charge). Instructions: ------------- This erratum 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 can log in to change the status and edit the report, if necessary. -------------------------------------- RFC4006 (draft-ietf-aaa-diameter-cc-06) -------------------------------------- Title : Diameter Credit-Control Application Publication Date : August 2005 Author(s) : H. Hakala, L. Mattila, J-P. Koskinen, M. Stura, J. Lo= ughney Category : PROPOSED STANDARD Source : Authentication, Authorization and Accounting Area : Operations and Management Stream : IETF Verifying Party : IESG . ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou = falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. --_000_6B7134B31289DC4FAF731D844122B36E0BFC5C89OPEXCLILM43corp_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

If I'm cor= rect, this is not an erratum against 4006 but a proposed change in the draf= t RFC4006bis (https://tools.ietf.org/html/draft-ietf-dime-rfc4006bis-00).

The origin= al text quoted below is not in the RFC4006 but in the draft.

 = ;

Let me kno= w if I'm correct.

 = ;

Regards,

 = ;

Lionel

 = ;

De := AAA-DOCTORS [mailto:aaa-doctors-bounces@ietf.= org] De la part de Benoit Claise
Envoy=E9 : lundi 19 d=E9cembre 2016 11:31
=C0 : aaa-doctors@ietf.org; sec-ads@ietf.org
Objet : [AAA-DOCTORS] Fwd: [Technical Errata Reported] RFC4006 = (4892)

 

Dear all,

What do you think?

Regards, Benoit



-------- Forwarded Message --------

Subjec= t:

[Technical Errata Reported] RFC4006 (4892)

Date: =

Mon, 19 Dec 2016 01:14:57 -0800

From: =

RFC Errata System <rfc-editor@rfc-editor.org>

To:

Harri.H= akala@ericsson.com, Leena.Mattila@ericsson.com, juha-pekka.koskinen@nokia.com, marco.stura@nokia.com, John.Loughney@nokia.com, bclaise@cisco.com, joelja@bogus.com= , Bernard_Aboba@hotmail.com, david@mi= tton.com, john.loughney@nokia.com=

CC:

dengzhenji= e@huawei.com, rfc-editor@rfc-editor.org<= o:p>

 

The following errata report has been submitted for RFC4006,=

"Diameter Credit-Control Application".
 
--------------------------------------
You may review the report below and at:
http://www.rfc-editor.org/errata_search.php?rfc=3D4006&eid=
=3D4892
 
--------------------------------------
Type: Technical
Reported by: dengzhenjie <=
;dengzhenjie@huawei.com>
 
Section: 7
 
Original Text
-------------
   | PendingU | CC update answer received   &=
nbsp; | Terminate   | Idle     |

   |          |=
 with result code equal to     | end user's  |&nbs=
p;         |


   |          |=
 CREDIT_CONTROL_NOT_APPLICABLE | service     | &nb=
sp;        |


 


 


Corrected Text


--------------


   | PendingU | CC update answer received   &=
nbsp; | Grant     |   Idle   |=



   |          |=
 with result code equal to     | service to|  =
;        |


   |          |=
 CREDIT_CONTROL_NOT_APPLICABLE | end user  |    &n=
bsp;     |


 


 


Notes


-----


Note that in Section 9, It said:


  when the result code in the CCA is DIAMETER_CREDIT_CONTROL_NOT_=
APPLICABLE 4011, it indicates that the credit-control server determines tha=
t the service can be granted to the end user but that no further credit-con=
trol is needed for the service (e.g., service is free of charge).


 


Instructions:


-------------


This erratum is currently posted as "Reported". If necessary=
, please


use "Reply All" to discuss whether it should be verified or<=
o:p>


rejected. When a decision is reached, the verifying party  <=
/o:p>


can log in to change the status and edit the report, if necessary. 


 


--------------------------------------


RFC4006 (draft-ietf-aaa-diameter-cc-06)


--------------------------------------


Title           =
;    : Diameter Credit-Control Application


Publication Date    : August 2005


Author(s)           =
: H. Hakala, L. Mattila, J-P. Koskinen, M. Stura, J. Loughney

Category          &n=
bsp; : PROPOSED STANDARD


Source          &nbs=
p;   : Authentication, Authorization and Accounting

Area           =
     : Operations and Management


Stream          &nbs=
p;   : IETF


Verifying Party     : IESG


.


 


______________________________________________________________________=
___________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confiden=
tielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu=
 ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el=
ectroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou =
falsifie. Merci.

This message and its attachments may contain confidential or privileged inf=
ormation that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and dele=
te this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been =
modified, changed or falsified.
Thank you.
--_000_6B7134B31289DC4FAF731D844122B36E0BFC5C89OPEXCLILM43corp_-- From nobody Tue Jan 3 02:28:16 2017 Return-Path: X-Original-To: aaa-doctors@ietfa.amsl.com Delivered-To: aaa-doctors@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2861112955F; Tue, 3 Jan 2017 02:28:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.708 X-Spam-Level: X-Spam-Status: No, score=-5.708 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-3.1, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5Th-MeBrPHcK; Tue, 3 Jan 2017 02:28:11 -0800 (PST) Received: from relais-inet.orange.com (mta134.mail.business.static.orange.com [80.12.70.34]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9E756129559; Tue, 3 Jan 2017 02:28:11 -0800 (PST) Received: from opfednr07.francetelecom.fr (unknown [xx.xx.xx.71]) by opfednr24.francetelecom.fr (ESMTP service) with ESMTP id 520A140D9D; Tue, 3 Jan 2017 11:28:10 +0100 (CET) Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.62]) by opfednr07.francetelecom.fr (ESMTP service) with ESMTP id F40A01C0078; Tue, 3 Jan 2017 11:28:09 +0100 (CET) Received: from OPEXCLILM43.corporate.adroot.infra.ftgroup ([fe80::ec23:902:c31f:731c]) by OPEXCLILM5E.corporate.adroot.infra.ftgroup ([fe80::2912:bfa5:91d3:bf63%19]) with mapi id 14.03.0319.002; Tue, 3 Jan 2017 11:28:09 +0100 From: To: Benoit Claise , "aaa-doctors@ietf.org" , "sec-ads@ietf.org" Thread-Topic: [AAA-DOCTORS] Fwd: [Editorial Errata Reported] RFC4006 (4890) Thread-Index: AQHSWePAD+Jg4xNwPEaM9ScgfjmgIaEmpAUw Date: Tue, 3 Jan 2017 10:28:08 +0000 Message-ID: <32602_1483439290_586B7CBA_32602_637_1_6B7134B31289DC4FAF731D844122B36E0BFC5CDA@OPEXCLILM43.corporate.adroot.infra.ftgroup> References: <20161216063032.A1093B80FA4@rfc-editor.org> In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.5] Content-Type: multipart/alternative; boundary="_000_6B7134B31289DC4FAF731D844122B36E0BFC5CDAOPEXCLILM43corp_" MIME-Version: 1.0 Archived-At: Cc: "Bertz, Lyle T \[CTO\]" , Dave Dolson Subject: Re: [AAA-DOCTORS] Fwd: [Editorial Errata Reported] RFC4006 (4890) X-BeenThere: aaa-doctors@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: AAA Doctors E-mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Jan 2017 10:28:14 -0000 --_000_6B7134B31289DC4FAF731D844122B36E0BFC5CDAOPEXCLILM43corp_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable As for another errata report, it seems that this one is also related to the= draft RFC4006bis and not to the existing RFC. Please confirm. Regards, Lionel De : AAA-DOCTORS [mailto:aaa-doctors-bounces@ietf.org] De la part de Benoit= Claise Envoy=E9 : lundi 19 d=E9cembre 2016 11:36 =C0 : aaa-doctors@ietf.org; sec-ads@ietf.org Objet : [AAA-DOCTORS] Fwd: [Editorial Errata Reported] RFC4006 (4890) And what about this one? Simple editorial errata? Regards, Benoit -------- Forwarded Message -------- Subject: [Editorial Errata Reported] RFC4006 (4890) Date: Thu, 15 Dec 2016 22:30:32 -0800 From: RFC Errata System To: Harri.Hakala@ericsson.com, Leena.Mattila@= ericsson.com, juha-pekka.koskinen@nokia.= com, marco.stura@nokia.com, John.Loughney@nokia.com, bclaise@cisco.com, joelja@bogus.com, Bernard_Aboba@hotmail.com= , david@mitton.com, john.loughney@nokia.com CC: dengzhenjie@huawei.com, rfc-editor@rfc-edito= r.org The following errata report has been submitted for RFC4006, "Diameter Credit-Control Application". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=3D4006&eid=3D4890 -------------------------------------- Type: Editorial Reported by: dengzhenjie Section: 7 Original Text ------------- | PendingE | Failure to send; requested | Store | Idle | | | action DIRECT_DEBITING; DDFH | request | | | | equal to TERMINATE_OR_BUFFER | with | | | | | T-flag | | | PendingE | Failure to send; requested | Store | Idle | | | action DIRECT_DEBITING; DDFH | request | | | | equal to TERMINATE_OR_BUFFER | with | | | | | T-flag | | Corrected Text -------------- | PendingE | Failure to send; requested | Store | Idle | | | action DIRECT_DEBITING; DDFH | request | | | | equal to TERMINATE_OR_BUFFER | with | | | | | T-flag | | Notes ----- the state machine in the table of ''client, event based'' is duplicated Instructions: ------------- This erratum 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 can log in to change the status and edit the report, if necessary. -------------------------------------- RFC4006 (draft-ietf-aaa-diameter-cc-06) -------------------------------------- Title : Diameter Credit-Control Application Publication Date : August 2005 Author(s) : H. Hakala, L. Mattila, J-P. Koskinen, M. Stura, J. Lo= ughney Category : PROPOSED STANDARD Source : Authentication, Authorization and Accounting Area : Operations and Management Stream : IETF Verifying Party : IESG . ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou = falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. --_000_6B7134B31289DC4FAF731D844122B36E0BFC5CDAOPEXCLILM43corp_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

As for ano= ther errata report, it seems that this one is also related to the draft RFC= 4006bis and not to the existing RFC.

 = ;

Please con= firm.

 = ;

Regards,

 = ;

Lionel

 = ;

De := AAA-DOCTORS [mailto:aaa-doctors-bounces@ietf.= org] De la part de Benoit Claise
Envoy=E9 : lundi 19 d=E9cembre 2016 11:36
=C0 : aaa-doctors@ietf.org; sec-ads@ietf.org
Objet : [AAA-DOCTORS] Fwd: [Editorial Errata Reported] RFC4006 = (4890)

 

And what about this one?
Simple editorial errata?

Regards, Benoit



-------- Forwarded Message --------

Subjec= t:

[Editorial Errata Reported] RFC4006 (4890)

Date: =

Thu, 15 Dec 2016 22:30:32 -0800

From: =

RFC Errata System <rfc-editor@rfc-editor.org>

To:

Harri.H= akala@ericsson.com, Leena.Mattila@ericsson.com, juha-pekka.koskinen@nokia.com, marco.stura@nokia.com, John.Loughney@nokia.com, bclaise@cisco.com, joelja@bogus.com= , Bernard_Aboba@hotmail.com, david@mi= tton.com, john.loughney@nokia.com=

CC:

dengzhenji= e@huawei.com, rfc-editor@rfc-editor.org<= o:p>

 

The following errata report has been submitted for RFC4006,=

"Diameter Credit-Control Application".
 
--------------------------------------
You may review the report below and at:
http://www.rfc-editor.org/errata_search.php?rfc=3D4006&eid=
=3D4890
 
--------------------------------------
Type: Editorial
Reported by: dengzhenjie <=
;dengzhenjie@huawei.com>
 
Section: 7
 
Original Text
-------------
   | PendingE | Failure to send; requested   =
  | Store      | Idle    =
 |
   |          |=
 action DIRECT_DEBITING; DDFH   | request    |&nbs=
p;         |
   |          |=
 equal to TERMINATE_OR_BUFFER   | with    &nb=
sp;  |          |
   |          |=
            &nb=
sp;            =
       | T-flag     |&nbs=
p;         |
   | PendingE | Failure to send; requested   =
  | Store      | Idle    =
 |
   |          |=
 action DIRECT_DEBITING; DDFH   | request    |&nbs=
p;         |
   |          |=
 equal to TERMINATE_OR_BUFFER   | with    &nb=
sp;  |          |
   |          |=
            &nb=
sp;            =
       | T-flag     |&nbs=
p;         |
 
Corrected Text
--------------
   | PendingE | Failure to send; requested   =
  | Store      | Idle    =
 |
   |          |=
 action DIRECT_DEBITING; DDFH   | request    |&nbs=
p;         |
   |          |=
 equal to TERMINATE_OR_BUFFER   | with    &nb=
sp;  |          |
   |          |=
             &n=
bsp;            =
;      | T-flag     |&nbs=
p;         |
 
Notes
-----
the state machine  in the table of ''client, event based'' is dup=
licated
 
Instructions:
-------------
This erratum is currently posted as "Reported". If necessary=
, please
use "Reply All" to discuss whether it should be verified or<=
o:p>
rejected. When a decision is reached, the verifying party  <=
/o:p>
can log in to change the status and edit the report, if necessary. 
 
--------------------------------------
RFC4006 (draft-ietf-aaa-diameter-cc-06)
--------------------------------------
Title           =
;    : Diameter Credit-Control Application
Publication Date    : August 2005
Author(s)           =
: H. Hakala, L. Mattila, J-P. Koskinen, M. Stura, J. Loughney

Category          &n=
bsp; : PROPOSED STANDARD


Source           &nb=
sp;  : Authentication, Authorization and Accounting

Area           =
     : Operations and Management


Stream          &nbs=
p;   : IETF


Verifying Party     : IESG


.


 


______________________________________________________________________=
___________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confiden=
tielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu=
 ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el=
ectroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou =
falsifie. Merci.

This message and its attachments may contain confidential or privileged inf=
ormation that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and dele=
te this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been =
modified, changed or falsified.
Thank you.
--_000_6B7134B31289DC4FAF731D844122B36E0BFC5CDAOPEXCLILM43corp_-- From nobody Tue Jan 3 02:39:05 2017 Return-Path: X-Original-To: aaa-doctors@ietfa.amsl.com Delivered-To: aaa-doctors@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C93EF129559; Tue, 3 Jan 2017 02:39:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.679 X-Spam-Level: X-Spam-Status: No, score=-5.679 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, RP_MATCHES_RCVD=-3.1, SPF_PASS=-0.001, T_FILL_THIS_FORM_SHORT=0.01, T_KAM_HTML_FONT_INVALID=0.01, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ObQGaJE0e7Pi; Tue, 3 Jan 2017 02:39:01 -0800 (PST) Received: from relais-inet.orange.com (mta135.mail.business.static.orange.com [80.12.70.35]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F2F06129558; Tue, 3 Jan 2017 02:39:00 -0800 (PST) Received: from opfednr02.francetelecom.fr (unknown [xx.xx.xx.66]) by opfednr20.francetelecom.fr (ESMTP service) with ESMTP id 3790140832; Tue, 3 Jan 2017 11:38:59 +0100 (CET) Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.19]) by opfednr02.francetelecom.fr (ESMTP service) with ESMTP id EF5FE120082; Tue, 3 Jan 2017 11:38:58 +0100 (CET) Received: from OPEXCLILM43.corporate.adroot.infra.ftgroup ([fe80::ec23:902:c31f:731c]) by OPEXCLILM44.corporate.adroot.infra.ftgroup ([fe80::b08d:5b75:e92c:a45f%18]) with mapi id 14.03.0319.002; Tue, 3 Jan 2017 11:38:58 +0100 From: To: Benoit Claise , "aaa-doctors@ietf.org" , "sec-ads@ietf.org" Thread-Topic: [AAA-DOCTORS] Fwd: [Technical Errata Reported] RFC6733 (4887) Thread-Index: AQHSVXzbcM7ap3o53EuRwtm6g39gBaEPD7GAgBee83A= Date: Tue, 3 Jan 2017 10:38:58 +0000 Message-ID: <27146_1483439939_586B7F43_27146_1228_1_6B7134B31289DC4FAF731D844122B36E0BFC5D70@OPEXCLILM43.corporate.adroot.infra.ftgroup> References: <20161213200945.E8146B80BF0@rfc-editor.org> <61648d44-00e8-5acd-64ea-77ae876c7a6d@cisco.com> In-Reply-To: <61648d44-00e8-5acd-64ea-77ae876c7a6d@cisco.com> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.5] Content-Type: multipart/alternative; boundary="_000_6B7134B31289DC4FAF731D844122B36E0BFC5D70OPEXCLILM43corp_" MIME-Version: 1.0 Archived-At: Subject: Re: [AAA-DOCTORS] Fwd: [Technical Errata Reported] RFC6733 (4887) X-BeenThere: aaa-doctors@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: AAA Doctors E-mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Jan 2017 10:39:04 -0000 --_000_6B7134B31289DC4FAF731D844122B36E0BFC5D70OPEXCLILM43corp_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable This one is correct. It was missed. But, as said in the report, it is just = an omission in this part of the document, and it is clarified in the sectio= n 6.4: The Origin-Realm AVP (AVP Code 296) is of type DiameterIdentity. This AVP contains the Realm of the originator of any Diameter message and MUST be present in all messages. Regards, Lionel De : AAA-DOCTORS [mailto:aaa-doctors-bounces@ietf.org] De la part de Benoit= Claise Envoy=E9 : lundi 19 d=E9cembre 2016 11:51 =C0 : aaa-doctors@ietf.org; sec-ads@ietf.org Objet : [AAA-DOCTORS] Fwd: [Technical Errata Reported] RFC6733 (4887) As you can guess, today is errata day... Regards, Benoit -------- Forwarded Message -------- Subject: [Technical Errata Reported] RFC6733 (4887) Date: Tue, 13 Dec 2016 12:09:45 -0800 From: RFC Errata System To: vf0213@gmail.com, jari.arkko@ericsson.com, john.loughney@nokia.com, glenzorn@gmail.com, bclaise@cisco.com, joelja@bogus.com, jouni.no= spam@gmail.com, lionel.morand@orange.com CC: misha.zaytsev.rus@gmail.com, dime@ietf.= org, rfc-editor@rfc-editor.org The following errata report has been submitted for RFC6733, "Diameter Base Protocol". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=3D6733&eid=3D4887 -------------------------------------- Type: Technical Reported by: Mikhail Zaytsev Section: 6.2 Original Text ------------- When a request is locally processed, the following procedures MUST be applied to create the associated answer, in addition to any additional procedures that MAY be discussed in the Diameter application defining the command: o The same Hop-by-Hop Identifier in the request is used in the answer. o The local host's identity is encoded in the Origin-Host AVP. o The Destination-Host and Destination-Realm AVPs MUST NOT be present in the answer message. Corrected Text -------------- When a request is locally processed, the following procedures MUST be applied to create the associated answer, in addition to any additional procedures that MAY be discussed in the Diameter application defining the command: o The same Hop-by-Hop Identifier in the request is used in the answer. o The local host's identity is encoded in the Origin-Host AVP. o The local realm's identity is encoded in the Origin-Realm AVP. o The Destination-Host and Destination-Realm AVPs MUST NOT be present in the answer message. Notes ----- Unlike Origin-Host AVP, it is not stated explicitly that Origin-Realm AVP M= UST be encoded in the associated answer. While both these AVPs MUST be pres= ent in all Diameter messages according to their descriptions. Instructions: ------------- This erratum 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 can log in to change the status and edit the report, if necessary. -------------------------------------- RFC6733 (draft-ietf-dime-rfc3588bis-33) -------------------------------------- Title : Diameter Base Protocol Publication Date : October 2012 Author(s) : V. Fajardo, Ed., J. Arkko, J. Loughney, G. Zorn, Ed. Category : PROPOSED STANDARD Source : Diameter Maintenance and Extensions Area : Operations and Management Stream : IETF Verifying Party : IESG . ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou = falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. --_000_6B7134B31289DC4FAF731D844122B36E0BFC5D70OPEXCLILM43corp_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

This one i= s correct. It was missed. But, as said in the report, it is just an omissio= n in this part of the document, and it is clarified in the section 6.4:

 = ;

 &nbs= p; The Origin-Realm AVP (AVP Code 296) is of type DiameterIdentity.

 &nbs= p; This AVP contains the Realm of the originator of any Diameter message

 &nbs= p; and MUST be present in all messages.

 = ;

Regards,

 = ;

Lionel

 = ;

De := AAA-DOCTORS [mailto:aaa-doctors-bounces@ietf.= org] De la part de Benoit Claise
Envoy=E9 : lundi 19 d=E9cembre 2016 11:51
=C0 : aaa-doctors@ietf.org; sec-ads@ietf.org
Objet : [AAA-DOCTORS] Fwd: [Technical Errata Reported] RFC6733 = (4887)

 

As you can guess, today is errata day...

Regards, Benoit



-------- Forwarded Message --------

Subjec= t:

[Technical Errata Reported] RFC6733 (4887)

Date: =

Tue, 13 Dec 2016 12:09:45 -0800

From: =

RFC Errata System <rfc-editor@rfc-editor.org>

To:

vf0213@gmail.com= , jari.arkko@ericsson.com, joh= n.loughney@nokia.com, glenzorn@gmail.com, bclaise@cisco.com, joelja@bogus.com= , jouni.nospam@gmail.com, lio= nel.morand@orange.com

CC:

misha= .zaytsev.rus@gmail.com, dime@ietf.org, rfc-editor@rfc-editor.org

 

The following errata report has been submitted for RFC6733,=

"Diameter Base Protocol".
 
--------------------------------------
You may review the report below and at:
http://www.rfc-editor.org/errata_search.php?rfc=3D6733&eid=
=3D4887
 
--------------------------------------
Type: Technical
Reported by: Mikhail Zaytsev <misha.zaytsev.rus@gmail.com>
 
Section: 6.2
 
Original Text
-------------
 When a request is locally processed, the following procedures MUST be=

   applied to create the associated answer, in addition to a=
ny
   additional procedures that MAY be discussed in the Diamet=
er
   application defining the command:
 
   o  The same Hop-by-Hop Identifier in the request is =
used in the
      answer.
 
   o  The local host's identity is encoded in the Origi=
n-Host AVP.
 
   o  The Destination-Host and Destination-Realm AVPs M=
UST NOT be
      present in the answer message.
 
 
Corrected Text
--------------
 When a request is locally processed, the following procedures MUST be=

   applied to create the associated answer, in addition to a=
ny
   additional procedures that MAY be discussed in the Diamet=
er
   application defining the command:
 
   o  The same Hop-by-Hop Identifier in the request is =
used in the
      answer.
 
   o  The local host's identity is encoded in the Origi=
n-Host AVP.
 
   o  The local realm's identity is encoded in the Orig=
in-Realm AVP.
 
   o  The Destination-Host and Destination-Realm AVPs M=
UST NOT be
      present in the answer message.
 
Notes
-----
Unlike Origin-Host AVP, it is not stated explicitly that Origin-Realm =
AVP MUST be encoded in the associated answer. While both these AVPs MUST be=
 present in all Diameter messages according to their descriptions.
 
Instructions:
-------------
This erratum is currently posted as "Reported". If necessary=
, please
use "Reply All" to discuss whether it should be verified or<=
o:p>
rejected. When a decision is reached, the verifying party  <=
/o:p>
can log in to change the status and edit the report, if necessary. 
 
--------------------------------------
RFC6733 (draft-ietf-dime-rfc3588bis-33)
--------------------------------------
Title           =
;    : Diameter Base Protocol
Publication Date    : October 2012
Author(s)           =
: V. Fajardo, Ed., J. Arkko, J. Loughney, G. Zorn, Ed.
Category          &n=
bsp; : PROPOSED STANDARD
Source          &nbs=
p;   : Diameter Maintenance and Extensions
Area           =
     : Operations and Management
Stream          &nbs=
p;   : IETF
Verifying Party     : IESG
.
 
______________________________________________________________________=
___________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confiden=
tielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu=
 ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el=
ectroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou =
falsifie. Merci.

This message and its attachments may contain confidential or privileged inf=
ormation that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and dele=
te this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been =
modified, changed or falsified.
Thank you.
--_000_6B7134B31289DC4FAF731D844122B36E0BFC5D70OPEXCLILM43corp_-- From nobody Tue Jan 3 03:16:54 2017 Return-Path: X-Original-To: aaa-doctors@ietfa.amsl.com Delivered-To: aaa-doctors@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B410412947C; Tue, 3 Jan 2017 03:16:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.708 X-Spam-Level: X-Spam-Status: No, score=-5.708 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-3.1, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t5q29LESgtDm; Tue, 3 Jan 2017 03:16:50 -0800 (PST) Received: from relais-inet.orange.com (mta136.mail.business.static.orange.com [80.12.70.36]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5B447129435; Tue, 3 Jan 2017 03:16:50 -0800 (PST) Received: from opfednr05.francetelecom.fr (unknown [xx.xx.xx.69]) by opfednr21.francetelecom.fr (ESMTP service) with ESMTP id 978F4C0DB6; Tue, 3 Jan 2017 12:16:48 +0100 (CET) Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.3]) by opfednr05.francetelecom.fr (ESMTP service) with ESMTP id 589CF20069; Tue, 3 Jan 2017 12:16:48 +0100 (CET) Received: from OPEXCLILM43.corporate.adroot.infra.ftgroup ([fe80::ec23:902:c31f:731c]) by OPEXCLILM5D.corporate.adroot.infra.ftgroup ([fe80::9898:741c:bc1d:258d%19]) with mapi id 14.03.0319.002; Tue, 3 Jan 2017 12:16:48 +0100 From: To: Benoit Claise , "aaa-doctors@ietf.org" , "sec-ads@ietf.org" Thread-Topic: [AAA-DOCTORS] Fwd: [Editorial Errata Reported] RFC6733 (4803) Thread-Index: AQHSWeYdhHq35r8PM0yaMog4/GN22aEmqGdw Date: Tue, 3 Jan 2017 11:16:47 +0000 Message-ID: <2069_1483442208_586B8820_2069_7324_1_6B7134B31289DC4FAF731D844122B36E0BFC5E94@OPEXCLILM43.corporate.adroot.infra.ftgroup> References: <20160913214213.4DBFAB80B89@rfc-editor.org> <372e075c-1564-b36a-1eb3-e62c8717535f@cisco.com> In-Reply-To: <372e075c-1564-b36a-1eb3-e62c8717535f@cisco.com> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.5] Content-Type: multipart/alternative; boundary="_000_6B7134B31289DC4FAF731D844122B36E0BFC5E94OPEXCLILM43corp_" MIME-Version: 1.0 Archived-At: Subject: Re: [AAA-DOCTORS] Fwd: [Editorial Errata Reported] RFC6733 (4803) X-BeenThere: aaa-doctors@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: AAA Doctors E-mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Jan 2017 11:16:52 -0000 --_000_6B7134B31289DC4FAF731D844122B36E0BFC5E94OPEXCLILM43corp_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable This errata report is correct on the inconsistency regarding the definition= of the command header and AVP header and how they are used in the rest of = the document in the ABNF description of commands and Grouped AVPs. For commands, the header is defined as follow: header =3D "" whereas "" whereas " In section 3.2. Command Code Format Specification OLD: header =3D "" NEW: header =3D "" --> And in section 4.4 OLD: header =3D "<" "AVP-Header:" avpcode [vendor] ">" NEW: header =3D "<" "AVP Header:" avpcode [vendor] ">" For command-def =3D "<" command-name ">" "::=3D" diameter-message, I would= propose to simply correct the example as all the command definitions given= in the document are following the command-def definition. For the grouped-avp-def, I don't know what would be the best approach. We c= ould follow the same approach and require the addition of "<>" but I don't = know what would be the impacts on existing Grouped AVPs defined without. Regards, Lionel. De : AAA-DOCTORS [mailto:aaa-doctors-bounces@ietf.org] De la part de Benoit= Claise Envoy=E9 : lundi 19 d=E9cembre 2016 11:52 =C0 : aaa-doctors@ietf.org; sec-ads@ietf.org Objet : [AAA-DOCTORS] Fwd: [Editorial Errata Reported] RFC6733 (4803) Ditto ... Regards, B. -------- Forwarded Message -------- Subject: [Editorial Errata Reported] RFC6733 (4803) Date: Tue, 13 Sep 2016 14:42:13 -0700 From: RFC Errata System To: vf0213@gmail.com, jari.arkko@ericsson.com, john.loughney@nokia.com, glenzorn@gmail.com, bclaise@cisco.com, joelja@bogus.com, jouni.no= spam@gmail.com, lionel.morand@orange.com CC: holger+ietf@freyther.de, dime@ietf.org, rfc-editor@rfc-editor.org The following errata report has been submitted for RFC6733, "Diameter Base Protocol". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=3D6733&eid=3D4803 -------------------------------------- Type: Editorial Reported by: Holger Freyther Section: 3.2 Original Text ------------- Example-Request ::=3D < Diameter Header: 9999999, REQ, PXY > { User-Name } 1* { Origin-Host } * [ AVP ] Corrected Text -------------- ::=3D < Diameter-Header: 9999999, REQ, PXY > { User-Name } 1* { Origin-Host } * [ AVP ] Notes ----- I converted the BNF into a PetitParser parser in Smalltalk/Pharo and notice= d that example and grammar do not match. The first issue is with the exampl= e following the grammar but most definitions do not follow the BNF so maybe= it is best to update the BNF. header =3D "" But "Diameter-Header:" is not used throughout the text so maybe it is bette= r to update the grammar to "Diameter Header:". command-def =3D "<" command-name ">" "::=3D" diameter-message but the example is not using <> for the command-name ("Example-Request"). F= or the grouped-avp-def application is sometimes used with "<" name ">" and = sometimes just name. Instructions: ------------- This erratum 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. -------------------------------------- RFC6733 (draft-ietf-dime-rfc3588bis-33) -------------------------------------- Title : Diameter Base Protocol Publication Date : October 2012 Author(s) : V. Fajardo, Ed., J. Arkko, J. Loughney, G. Zorn, Ed. Category : PROPOSED STANDARD Source : Diameter Maintenance and Extensions Area : Operations and Management Stream : IETF Verifying Party : IESG . ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou = falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. --_000_6B7134B31289DC4FAF731D844122B36E0BFC5E94OPEXCLILM43corp_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

This errat= a report is correct on the inconsistency regarding the definition of the co= mmand header and AVP header and how they are used in the rest of the document in the ABNF description of commands and Grouped AVPs.=

 = ;

For comman= ds, the header is defined as follow:

 = ;

 &nbs= p; header           =3D &= quot;<Diameter-Header:" command-id

 &nbs= p;            &= nbsp;          [r-bit] [p-bit]= [e-bit] [application-id]">"

 = ;

whereas &q= uot;<Diameter Header:" is used when defining commands.

 = ;

Same for G= rouped AVP. It is defined as follow:

 = ;

 &nbs= p;       header     =       =3D "<" "AVP-Header:"= avpcode [vendor] ">"

 = ;

whereas &q= uot;<AVP Header:" is used when defining Grouped AVPs.

 = ;

Considerin= g that most (if not all) the ABNF descriptions have been copied from the co= mmands and Grouped AVPs defined in the RFC3588 or RFC6733, I would be in favor to correct the specification by modifying the definiti= on of the headers, i.e.

 = ;

--> In = section 3.2.  Command Code Format Specification

 = ;

OLD:<= /o:p>

 = ;

 &nbs= p; header           = =3D "<Diameter-Header:" command-id

 &nbs= p;            &= nbsp;          [r-bit] [p-bit]= [e-bit] [application-id]">"

 = ;

NEW:<= /o:p>

 = ;

 &nbs= p; header           = =3D "<Diameter Header:" command-id

 &nbs= p;            &= nbsp;          [r-bit] [p-bit]= [e-bit] [application-id]">"

 = ;

 = ;

--> And= in section 4.4

 = ;

OLD:<= /o:p>

 = ;

 &nbs= p;       header     =       =3D "<" "AVP-Header:"= avpcode [vendor] ">"

 = ;

NEW:<= /o:p>

 = ;

 &nbs= p;       header     =       =3D "<" "AVP Header:"= avpcode [vendor] ">"

 = ;

For comman= d-def  =3D "<" command-name ">" "::=3D&= quot; diameter-message, I would propose to simply correct the example as al= l the command definitions given in the document are following the command-def definition.

For the gr= ouped-avp-def, I don't know what would be the best approach. We could follo= w the same approach and require the addition of "<>" but I don't know what would be the impacts on existing Grouped AVPs defined with= out.

 = ;

Regards,

 = ;

Lionel.

 = ;

 = ;

De := AAA-DOCTORS [mailto:aaa-doctors-bounces@ietf.= org] De la part de Benoit Claise
Envoy=E9 : lundi 19 d=E9cembre 2016 11:52
=C0 : aaa-doctors@ietf.org; sec-ads@ietf.org
Objet : [AAA-DOCTORS] Fwd: [Editorial Errata Reported] RFC6733 = (4803)

 

Ditto ...

Regards, B.



-------- Forwarded Message --------

Subjec= t:

[Editorial Errata Reported] RFC6733 (4803)

Date: =

Tue, 13 Sep 2016 14:42:13 -0700

From: =

RFC Errata System <rfc-editor@rfc-editor.org>

To:

vf0213@gmail.com= , jari.arkko@ericsson.com, joh= n.loughney@nokia.com, glenzorn@gmail.com, bclaise@cisco.com, joelja@bogus.com= , jouni.nospam@gmail.com, lio= nel.morand@orange.com

CC:

holge= r+ietf@freyther.de, dime@ietf.org, rfc-editor@rfc-editor.org

 

The following errata report has been submitted for RFC6733,=

"Diameter Base Protocol".
 
--------------------------------------
You may review the report below and at:
http://www.rfc-editor.org/errata_search.php?rfc=3D6733&eid=
=3D4803
 
--------------------------------------
Type: Editorial
Reported by: Holger Freyther <holger+ietf@freyther.de>
 
Section: 3.2
 
Original Text
-------------
   Example-Request ::=3D < Diameter Header: 9999999, REQ,=
 PXY >
           &nbs=
p;           { User-Name =
}
           &nbs=
p;        1* { Origin-Host }<=
/pre>

           &nbs=
p;         * [ AVP ]

 


 


 


Corrected Text


--------------


   <Example-Request> ::=3D < Diameter-Header: 99999=
99, REQ, PXY >


           &nbs=
p;           { User-Name =
}


           &nbs=
p;        1* { Origin-Host }<=
/pre>

           &nbs=
p;         * [ AVP ]

 


 


 


Notes


-----


I converted the BNF into a PetitParser parser in Smalltalk/Pharo and n=
oticed that example and grammar do not match. The first issue is with the e=
xample following the grammar but most definitions do not follow the BNF so =
maybe it is best to update the BNF. 


 


  header         &nb=
sp; =3D "<Diameter-Header:" command-id


           &nbs=
p;             =
[r-bit] [p-bit] [e-bit] [application-id]">"


 


But "Diameter-Header:" is not used throughout the text so ma=
ybe it is better to update the grammar to "Diameter Header:".


 


 


 command-def      =3D "<" comman=
d-name ">" "::=3D" diameter-message


 


but the example is not using <> for the command-name ("Exam=
ple-Request"). For the grouped-avp-def application is sometimes used w=
ith "<" name ">" and sometimes just name.


 


Instructions:


-------------


This erratum is currently posted as "Reported". If necessary=
, please


use "Reply All" to discuss whether it should be verified or<=
o:p>


rejected. When a decision is reached, the verifying party (IESG)<=
/o:p>


can log in to change the status and edit the report, if necessary. 


 


--------------------------------------


RFC6733 (draft-ietf-dime-rfc3588bis-33)


--------------------------------------


Title           =
;    : Diameter Base Protocol


Publication Date    : October 2012


Author(s)           =
: V. Fajardo, Ed., J. Arkko, J. Loughney, G. Zorn, Ed.


Category          &n=
bsp; : PROPOSED STANDARD


Source          &nbs=
p;   : Diameter Maintenance and Extensions


Area           =
     : Operations and Management


Stream          &nbs=
p;   : IETF


Verifying Party     : IESG


 


.


 


______________________________________________________________________=
___________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confiden=
tielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu=
 ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el=
ectroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou =
falsifie. Merci.

This message and its attachments may contain confidential or privileged inf=
ormation that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and dele=
te this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been =
modified, changed or falsified.
Thank you.
--_000_6B7134B31289DC4FAF731D844122B36E0BFC5E94OPEXCLILM43corp_-- From nobody Tue Jan 3 03:23:56 2017 Return-Path: X-Original-To: aaa-doctors@ietfa.amsl.com Delivered-To: aaa-doctors@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B83DA129569; Tue, 3 Jan 2017 03:23:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.611 X-Spam-Level: X-Spam-Status: No, score=-17.611 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-3.1, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tk_UfvSfyDW2; Tue, 3 Jan 2017 03:23:54 -0800 (PST) Received: from aer-iport-4.cisco.com (aer-iport-4.cisco.com [173.38.203.54]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 24774129492; Tue, 3 Jan 2017 03:23:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=22263; q=dns/txt; s=iport; t=1483442633; x=1484652233; h=subject:to:references:cc:from:message-id:date: mime-version:in-reply-to; bh=EIqXr56SPYxUsf0yZE9IXeukn8HNvebtXYlWcuAeT0s=; b=giESTWV+cbyd6b+6j23CwOSf9/kAT7g2vN2HCqHmiw1fSUEZmuNpqR/4 90Iq5q5fgKuN5zNbPRnCvQKp6N3Yo2o2AiBWs/Y+6l1vQKmn0sPVaJDi1 mtGB2Oz66lT5YFCtpl0PGnfCvUJ34C5ur8gKbtMvkWQ4p6+Y+osUAglfV k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0D/AABmiWtY/xbLJq1DEQkZAQEBAQEBA?= =?us-ascii?q?QEBAQEHAQEBAQGCcUYBAQEBAX4vXY1XcpNTh3uLEYIPgggqhXgCgh4UAQIBAQE?= =?us-ascii?q?BAQEBYiiEaAEBAQQtTBALEQMBAiEHByElCQgGAQwGAgEBiFEDGA4tsQUrhn0Ng?= =?us-ascii?q?wkBAQEBAQEBAQEBAQEBAQEBAQEBAQEdhkWCAgiCV4E7gRM7gQQLBwoBPAwKhQ0?= =?us-ascii?q?eBYhmEYdRhEGFPzWNRYN5gXWFCIMnhjGJc1WDZoQPHzhoHxYNFoN7DQ+BXz00A?= =?us-ascii?q?ROFfIIuAQEB?= X-IronPort-AV: E=Sophos;i="5.33,451,1477958400"; d="scan'208,217";a="651300793" Received: from aer-iport-nat.cisco.com (HELO aer-core-3.cisco.com) ([173.38.203.22]) by aer-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 03 Jan 2017 11:23:48 +0000 Received: from [10.60.67.87] (ams-bclaise-8916.cisco.com [10.60.67.87]) by aer-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id v03BNmGC013754; Tue, 3 Jan 2017 11:23:48 GMT To: lionel.morand@orange.com, "aaa-doctors@ietf.org" , "sec-ads@ietf.org" References: <20161213200945.E8146B80BF0@rfc-editor.org> <61648d44-00e8-5acd-64ea-77ae876c7a6d@cisco.com> <27146_1483439939_586B7F43_27146_1228_1_6B7134B31289DC4FAF731D844122B36E0BFC5D70@OPEXCLILM43.corporate.adroot.infra.ftgroup> From: Benoit Claise Message-ID: <6046c5a7-1951-162b-2485-c427429d2167@cisco.com> Date: Tue, 3 Jan 2017 12:23:48 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.6.0 MIME-Version: 1.0 In-Reply-To: <27146_1483439939_586B7F43_27146_1228_1_6B7134B31289DC4FAF731D844122B36E0BFC5D70@OPEXCLILM43.corporate.adroot.infra.ftgroup> Content-Type: multipart/alternative; boundary="------------AF298331AB4F627CDC228B93" Archived-At: Subject: Re: [AAA-DOCTORS] Fwd: [Technical Errata Reported] RFC6733 (4887) X-BeenThere: aaa-doctors@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: AAA Doctors E-mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Jan 2017 11:23:55 -0000 This is a multi-part message in MIME format. --------------AF298331AB4F627CDC228B93 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Thanks Lionel. This erratum has been verified. Regards, Benoit > > This one is correct. It was missed. But, as said in the report, it is > just an omission in this part of the document, and it is clarified in > the section 6.4: > > The Origin-Realm AVP (AVP Code 296) is of type DiameterIdentity. > > This AVP contains the Realm of the originator of any Diameter message > > and MUST be present in all messages. > > Regards, > > Lionel > > *De :*AAA-DOCTORS [mailto:aaa-doctors-bounces@ietf.org] *De la part > de* Benoit Claise > *Envoyé :* lundi 19 décembre 2016 11:51 > *À :* aaa-doctors@ietf.org; sec-ads@ietf.org > *Objet :* [AAA-DOCTORS] Fwd: [Technical Errata Reported] RFC6733 (4887) > > As you can guess, today is errata day... > > Regards, Benoit > > > > -------- Forwarded Message -------- > > *Subject: * > > > > [Technical Errata Reported] RFC6733 (4887) > > *Date: * > > > > Tue, 13 Dec 2016 12:09:45 -0800 > > *From: * > > > > RFC Errata System > > > *To: * > > > > vf0213@gmail.com , jari.arkko@ericsson.com > , john.loughney@nokia.com > , glenzorn@gmail.com > , bclaise@cisco.com > , joelja@bogus.com > , jouni.nospam@gmail.com > , lionel.morand@orange.com > > > *CC: * > > > > misha.zaytsev.rus@gmail.com , > dime@ietf.org , rfc-editor@rfc-editor.org > > > The following errata report has been submitted for RFC6733, > "Diameter Base Protocol". > -------------------------------------- > You may review the report below and at: > http://www.rfc-editor.org/errata_search.php?rfc=6733&eid=4887 > -------------------------------------- > Type: Technical > Reported by: Mikhail Zaytsev > Section: 6.2 > Original Text > ------------- > When a request is locally processed, the following procedures MUST be > applied to create the associated answer, in addition to any > additional procedures that MAY be discussed in the Diameter > application defining the command: > o The same Hop-by-Hop Identifier in the request is used in the > answer. > o The local host's identity is encoded in the Origin-Host AVP. > o The Destination-Host and Destination-Realm AVPs MUST NOT be > present in the answer message. > Corrected Text > -------------- > When a request is locally processed, the following procedures MUST be > applied to create the associated answer, in addition to any > additional procedures that MAY be discussed in the Diameter > application defining the command: > o The same Hop-by-Hop Identifier in the request is used in the > answer. > o The local host's identity is encoded in the Origin-Host AVP. > o The local realm's identity is encoded in the Origin-Realm AVP. > o The Destination-Host and Destination-Realm AVPs MUST NOT be > present in the answer message. > Notes > ----- > Unlike Origin-Host AVP, it is not stated explicitly that Origin-Realm AVP MUST be encoded in the associated answer. While both these AVPs MUST be present in all Diameter messages according to their descriptions. > Instructions: > ------------- > This erratum 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 > can log in to change the status and edit the report, if necessary. > -------------------------------------- > RFC6733 (draft-ietf-dime-rfc3588bis-33) > -------------------------------------- > Title : Diameter Base Protocol > Publication Date : October 2012 > Author(s) : V. Fajardo, Ed., J. Arkko, J. Loughney, G. Zorn, Ed. > Category : PROPOSED STANDARD > Source : Diameter Maintenance and Extensions > Area : Operations and Management > Stream : IETF > Verifying Party : IESG > . > _________________________________________________________________________________________________________________________ > > Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc > pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler > a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, > Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. > > This message and its attachments may contain confidential or privileged information that may be protected by law; > they should not be distributed, used or copied without authorisation. > If you have received this email in error, please notify the sender and delete this message and its attachments. > As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified. > Thank you. --------------AF298331AB4F627CDC228B93 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit
Thanks Lionel.
This erratum has been verified.

Regards, Benoit

This one is correct. It was missed. But, as said in the report, it is just an omission in this part of the document, and it is clarified in the section 6.4:

 

   The Origin-Realm AVP (AVP Code 296) is of type DiameterIdentity.

   This AVP contains the Realm of the originator of any Diameter message

   and MUST be present in all messages.

 

Regards,

 

Lionel

 

De : AAA-DOCTORS [mailto:aaa-doctors-bounces@ietf.org] De la part de Benoit Claise
Envoyé : lundi 19 décembre 2016 11:51
À : aaa-doctors@ietf.org; sec-ads@ietf.org
Objet : [AAA-DOCTORS] Fwd: [Technical Errata Reported] RFC6733 (4887)

 

As you can guess, today is errata day...

Regards, Benoit



-------- Forwarded Message --------

Subject:

[Technical Errata Reported] RFC6733 (4887)

Date:

Tue, 13 Dec 2016 12:09:45 -0800

From:

RFC Errata System <rfc-editor@rfc-editor.org>

To:

vf0213@gmail.com, jari.arkko@ericsson.com, john.loughney@nokia.com, glenzorn@gmail.com, bclaise@cisco.com, joelja@bogus.com, jouni.nospam@gmail.com, lionel.morand@orange.com

CC:

misha.zaytsev.rus@gmail.com, dime@ietf.org, rfc-editor@rfc-editor.org

 

The following errata report has been submitted for RFC6733,
"Diameter Base Protocol".
 
--------------------------------------
You may review the report below and at:
http://www.rfc-editor.org/errata_search.php?rfc=6733&eid=4887
 
--------------------------------------
Type: Technical
Reported by: Mikhail Zaytsev <misha.zaytsev.rus@gmail.com>
 
Section: 6.2
 
Original Text
-------------
 When a request is locally processed, the following procedures MUST be
   applied to create the associated answer, in addition to any
   additional procedures that MAY be discussed in the Diameter
   application defining the command:
 
   o  The same Hop-by-Hop Identifier in the request is used in the
      answer.
 
   o  The local host's identity is encoded in the Origin-Host AVP.
 
   o  The Destination-Host and Destination-Realm AVPs MUST NOT be
      present in the answer message.
 
 
Corrected Text
--------------
 When a request is locally processed, the following procedures MUST be
   applied to create the associated answer, in addition to any
   additional procedures that MAY be discussed in the Diameter
   application defining the command:
 
   o  The same Hop-by-Hop Identifier in the request is used in the
      answer.
 
   o  The local host's identity is encoded in the Origin-Host AVP.
 
   o  The local realm's identity is encoded in the Origin-Realm AVP.
 
   o  The Destination-Host and Destination-Realm AVPs MUST NOT be
      present in the answer message.
 
Notes
-----
Unlike Origin-Host AVP, it is not stated explicitly that Origin-Realm AVP MUST be encoded in the associated answer. While both these AVPs MUST be present in all Diameter messages according to their descriptions.
 
Instructions:
-------------
This erratum 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  
can log in to change the status and edit the report, if necessary. 
 
--------------------------------------
RFC6733 (draft-ietf-dime-rfc3588bis-33)
--------------------------------------
Title               : Diameter Base Protocol
Publication Date    : October 2012
Author(s)           : V. Fajardo, Ed., J. Arkko, J. Loughney, G. Zorn, Ed.
Category            : PROPOSED STANDARD
Source              : Diameter Maintenance and Extensions
Area                : Operations and Management
Stream              : IETF
Verifying Party     : IESG
.
 
_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.

--------------AF298331AB4F627CDC228B93-- From nobody Tue Jan 3 03:27:25 2017 Return-Path: X-Original-To: aaa-doctors@ietfa.amsl.com Delivered-To: aaa-doctors@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 58BFA12956A; Tue, 3 Jan 2017 03:27:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.611 X-Spam-Level: X-Spam-Status: No, score=-17.611 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-3.1, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hG3_3XXmUswm; Tue, 3 Jan 2017 03:27:22 -0800 (PST) Received: from aer-iport-1.cisco.com (aer-iport-1.cisco.com [173.38.203.51]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C0FDE1294EB; Tue, 3 Jan 2017 03:27:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=20637; q=dns/txt; s=iport; t=1483442842; x=1484652442; h=subject:to:references:cc:from:message-id:date: mime-version:in-reply-to; bh=mPZiC9Yl4JpbRt29ClxHI3KK7kGVKZ1z+Pvo/xXZO4g=; b=HBJiQp80IPME8uHAfN8IlgThnJ4wJClXiYQY614cOvm5BjN0GMn6LEeM ERSghOYk859K35cDKzFnRhr8l+V+sa88GYcy03iiv2pz4oGM3Poj/aVGS /DmYS6mGDW4+cZ48idxASMLOAgSQPNAds91EYwg+hzzGdQWGyz1Au4kSC o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0D/AABmiWtY/xbLJq1DGhkBAQEBAQEBA?= =?us-ascii?q?QEBAQcBAQEBAYJxRgEBAQEBfi9djVdyk1OCNIVHixGCD4IIKoV4AoIeFAECAQE?= =?us-ascii?q?BAQEBAWIohGgBAQEELRoyEAsRAwECKAdGCQgGAQwGAgEBiFEDGA4tsQUrgxOHA?= =?us-ascii?q?AEBAQEBAQEBAQEBAQEBAQEBAQEBAR2GRYICCIJXgTuBEzuBDxEBPAwKhQ0eBYh?= =?us-ascii?q?mEYdRhEGFPzWNRoN4gXWFCIMnhjGJc1WDZoQPHzhoHxYNFoN7DQ+BXz00AROFf?= =?us-ascii?q?IIuAQEB?= X-IronPort-AV: E=Sophos;i="5.33,451,1477958400"; d="scan'208,217";a="691021146" Received: from aer-iport-nat.cisco.com (HELO aer-core-4.cisco.com) ([173.38.203.22]) by aer-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 03 Jan 2017 11:27:19 +0000 Received: from [10.60.67.87] (ams-bclaise-8916.cisco.com [10.60.67.87]) by aer-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id v03BRIBQ032716; Tue, 3 Jan 2017 11:27:18 GMT To: lionel.morand@orange.com, "aaa-doctors@ietf.org" , "sec-ads@ietf.org" References: <20161216063032.A1093B80FA4@rfc-editor.org> <32602_1483439290_586B7CBA_32602_637_1_6B7134B31289DC4FAF731D844122B36E0BFC5CDA@OPEXCLILM43.corporate.adroot.infra.ftgroup> From: Benoit Claise Message-ID: <1a7315df-91d7-4213-152c-cd289321e30d@cisco.com> Date: Tue, 3 Jan 2017 12:27:18 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.6.0 MIME-Version: 1.0 In-Reply-To: <32602_1483439290_586B7CBA_32602_637_1_6B7134B31289DC4FAF731D844122B36E0BFC5CDA@OPEXCLILM43.corporate.adroot.infra.ftgroup> Content-Type: multipart/alternative; boundary="------------77870E2AAD77E3E13736A699" Archived-At: Cc: "Bertz, Lyle T \[CTO\]" , Dave Dolson Subject: Re: [AAA-DOCTORS] Fwd: [Editorial Errata Reported] RFC4006 (4890) X-BeenThere: aaa-doctors@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: AAA Doctors E-mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Jan 2017 11:27:24 -0000 This is a multi-part message in MIME format. --------------77870E2AAD77E3E13736A699 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit If it's a simple duplicate, isn't an editorial mistake? Regards, B. > > As for another errata report, it seems that this one is also related > to the draft RFC4006bis and not to the existing RFC. > > Please confirm. > > Regards, > > Lionel > > *De :*AAA-DOCTORS [mailto:aaa-doctors-bounces@ietf.org] *De la part > de* Benoit Claise > *Envoyé :* lundi 19 décembre 2016 11:36 > *À :* aaa-doctors@ietf.org; sec-ads@ietf.org > *Objet :* [AAA-DOCTORS] Fwd: [Editorial Errata Reported] RFC4006 (4890) > > And what about this one? > Simple editorial errata? > > Regards, Benoit > > > > -------- Forwarded Message -------- > > *Subject: * > > > > [Editorial Errata Reported] RFC4006 (4890) > > *Date: * > > > > Thu, 15 Dec 2016 22:30:32 -0800 > > *From: * > > > > RFC Errata System > > > *To: * > > > > Harri.Hakala@ericsson.com , > Leena.Mattila@ericsson.com , > juha-pekka.koskinen@nokia.com , > marco.stura@nokia.com , > John.Loughney@nokia.com , > bclaise@cisco.com , joelja@bogus.com > , Bernard_Aboba@hotmail.com > , david@mitton.com > , john.loughney@nokia.com > > > *CC: * > > > > dengzhenjie@huawei.com , > rfc-editor@rfc-editor.org > > The following errata report has been submitted for RFC4006, > "Diameter Credit-Control Application". > -------------------------------------- > You may review the report below and at: > http://www.rfc-editor.org/errata_search.php?rfc=4006&eid=4890 > -------------------------------------- > Type: Editorial > Reported by: dengzhenjie > Section: 7 > Original Text > ------------- > | PendingE | Failure to send; requested | Store | Idle | > | | action DIRECT_DEBITING; DDFH | request | | > | | equal to TERMINATE_OR_BUFFER | with | | > | | | T-flag | | > | PendingE | Failure to send; requested | Store | Idle | > | | action DIRECT_DEBITING; DDFH | request | | > | | equal to TERMINATE_OR_BUFFER | with | | > | | | T-flag | | > Corrected Text > -------------- > | PendingE | Failure to send; requested | Store | Idle | > | | action DIRECT_DEBITING; DDFH | request | | > | | equal to TERMINATE_OR_BUFFER | with | | > | | | T-flag | | > Notes > ----- > the state machine in the table of ''client, event based'' is duplicated > Instructions: > ------------- > This erratum 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 > can log in to change the status and edit the report, if necessary. > -------------------------------------- > RFC4006 (draft-ietf-aaa-diameter-cc-06) > -------------------------------------- > Title : Diameter Credit-Control Application > Publication Date : August 2005 > Author(s) : H. Hakala, L. Mattila, J-P. Koskinen, M. Stura, J. Loughney > Category : PROPOSED STANDARD > Source : Authentication, Authorization and Accounting > Area : Operations and Management > Stream : IETF > Verifying Party : IESG > . > _________________________________________________________________________________________________________________________ > > Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc > pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler > a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, > Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. > > This message and its attachments may contain confidential or privileged information that may be protected by law; > they should not be distributed, used or copied without authorisation. > If you have received this email in error, please notify the sender and delete this message and its attachments. > As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified. > Thank you. --------------77870E2AAD77E3E13736A699 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit
If it's a simple duplicate, isn't an editorial mistake?

Regards, B.

As for another errata report, it seems that this one is also related to the draft RFC4006bis and not to the existing RFC.

 

Please confirm.

 

Regards,

 

Lionel

 

De : AAA-DOCTORS [mailto:aaa-doctors-bounces@ietf.org] De la part de Benoit Claise
Envoyé : lundi 19 décembre 2016 11:36
À : aaa-doctors@ietf.org; sec-ads@ietf.org
Objet : [AAA-DOCTORS] Fwd: [Editorial Errata Reported] RFC4006 (4890)

 

And what about this one?
Simple editorial errata?

Regards, Benoit



-------- Forwarded Message --------

Subject:

[Editorial Errata Reported] RFC4006 (4890)

Date:

Thu, 15 Dec 2016 22:30:32 -0800

From:

RFC Errata System <rfc-editor@rfc-editor.org>

To:

Harri.Hakala@ericsson.com, Leena.Mattila@ericsson.com, juha-pekka.koskinen@nokia.com, marco.stura@nokia.com, John.Loughney@nokia.com, bclaise@cisco.com, joelja@bogus.com, Bernard_Aboba@hotmail.com, david@mitton.com, john.loughney@nokia.com

CC:

dengzhenjie@huawei.com, rfc-editor@rfc-editor.org

 

The following errata report has been submitted for RFC4006,
"Diameter Credit-Control Application".
 
--------------------------------------
You may review the report below and at:
http://www.rfc-editor.org/errata_search.php?rfc=4006&eid=4890
 
--------------------------------------
Type: Editorial
Reported by: dengzhenjie <dengzhenjie@huawei.com>
 
Section: 7
 
Original Text
-------------
   | PendingE | Failure to send; requested     | Store      | Idle     |
   |          | action DIRECT_DEBITING; DDFH   | request    |          |
   |          | equal to TERMINATE_OR_BUFFER   | with       |          |
   |          |                                | T-flag     |          |
   | PendingE | Failure to send; requested     | Store      | Idle     |
   |          | action DIRECT_DEBITING; DDFH   | request    |          |
   |          | equal to TERMINATE_OR_BUFFER   | with       |          |
   |          |                                | T-flag     |          |
 
Corrected Text
--------------
   | PendingE | Failure to send; requested     | Store      | Idle     |
   |          | action DIRECT_DEBITING; DDFH   | request    |          |
   |          | equal to TERMINATE_OR_BUFFER   | with       |          |
   |          |                                | T-flag     |          |
 
Notes
-----
the state machine  in the table of ''client, event based'' is duplicated
 
Instructions:
-------------
This erratum 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  
can log in to change the status and edit the report, if necessary. 
 
--------------------------------------
RFC4006 (draft-ietf-aaa-diameter-cc-06)
--------------------------------------
Title               : Diameter Credit-Control Application
Publication Date    : August 2005
Author(s)           : H. Hakala, L. Mattila, J-P. Koskinen, M. Stura, J. Loughney
Category            : PROPOSED STANDARD
Source              : Authentication, Authorization and Accounting
Area                : Operations and Management
Stream              : IETF
Verifying Party     : IESG
.
 
_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.

--------------77870E2AAD77E3E13736A699-- From nobody Tue Jan 3 03:29:26 2017 Return-Path: X-Original-To: aaa-doctors@ietfa.amsl.com Delivered-To: aaa-doctors@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 77980129570; Tue, 3 Jan 2017 03:29:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.708 X-Spam-Level: X-Spam-Status: No, score=-5.708 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-3.1, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MepAHblKFP8V; Tue, 3 Jan 2017 03:29:22 -0800 (PST) Received: from relais-inet.orange.com (mta134.mail.business.static.orange.com [80.12.70.34]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 662F11294EB; Tue, 3 Jan 2017 03:29:22 -0800 (PST) Received: from opfednr01.francetelecom.fr (unknown [xx.xx.xx.65]) by opfednr21.francetelecom.fr (ESMTP service) with ESMTP id 123AAC0DE0; Tue, 3 Jan 2017 12:29:21 +0100 (CET) Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.41]) by opfednr01.francetelecom.fr (ESMTP service) with ESMTP id C472A1A0056; Tue, 3 Jan 2017 12:29:20 +0100 (CET) Received: from OPEXCLILM43.corporate.adroot.infra.ftgroup ([fe80::ec23:902:c31f:731c]) by OPEXCLILM31.corporate.adroot.infra.ftgroup ([fe80::2cc9:4bac:7b7d:229d%19]) with mapi id 14.03.0319.002; Tue, 3 Jan 2017 12:29:20 +0100 From: To: Benoit Claise , "aaa-doctors@ietf.org" , "sec-ads@ietf.org" Thread-Topic: [AAA-DOCTORS] Fwd: [Editorial Errata Reported] RFC4006 (4890) Thread-Index: AQHSWePAD+Jg4xNwPEaM9ScgfjmgIaEmpAUwgAAAHgCAABDuAA== Date: Tue, 3 Jan 2017 11:29:19 +0000 Message-ID: <15517_1483442960_586B8B10_15517_799_3_6B7134B31289DC4FAF731D844122B36E0BFC5F10@OPEXCLILM43.corporate.adroot.infra.ftgroup> References: <20161216063032.A1093B80FA4@rfc-editor.org> <32602_1483439290_586B7CBA_32602_637_1_6B7134B31289DC4FAF731D844122B36E0BFC5CDA@OPEXCLILM43.corporate.adroot.infra.ftgroup> <1a7315df-91d7-4213-152c-cd289321e30d@cisco.com> In-Reply-To: <1a7315df-91d7-4213-152c-cd289321e30d@cisco.com> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.5] Content-Type: multipart/alternative; boundary="_000_6B7134B31289DC4FAF731D844122B36E0BFC5F10OPEXCLILM43corp_" MIME-Version: 1.0 Archived-At: Cc: "Bertz, Lyle T \[CTO\]" , Dave Dolson Subject: Re: [AAA-DOCTORS] Fwd: [Editorial Errata Reported] RFC4006 (4890) X-BeenThere: aaa-doctors@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: AAA Doctors E-mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Jan 2017 11:29:24 -0000 --_000_6B7134B31289DC4FAF731D844122B36E0BFC5F10OPEXCLILM43corp_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I think it is just an editorial mistake. but this not related to the RFC400= 6 but to the current version of the draft https://datatracker.ietf.org/doc/= draft-ietf-dime-rfc4006bis/ Lionel De : Benoit Claise [mailto:bclaise@cisco.com] Envoy=E9 : mardi 3 janvier 2017 12:27 =C0 : MORAND Lionel IMT/OLN; aaa-doctors@ietf.org; sec-ads@ietf.org Cc : Jouni; Dave Dolson; Bertz, Lyle T [CTO] Objet : Re: [AAA-DOCTORS] Fwd: [Editorial Errata Reported] RFC4006 (4890) If it's a simple duplicate, isn't an editorial mistake? Regards, B. As for another errata report, it seems that this one is also related to the= draft RFC4006bis and not to the existing RFC. Please confirm. Regards, Lionel De : AAA-DOCTORS [mailto:aaa-doctors-bounces@ietf.org] De la part de Benoit= Claise Envoy=E9 : lundi 19 d=E9cembre 2016 11:36 =C0 : aaa-doctors@ietf.org; sec-ads@ietf.org Objet : [AAA-DOCTORS] Fwd: [Editorial Errata Reported] RFC4006 (4890) And what about this one? Simple editorial errata? Regards, Benoit -------- Forwarded Message -------- Subject: [Editorial Errata Reported] RFC4006 (4890) Date: Thu, 15 Dec 2016 22:30:32 -0800 From: RFC Errata System To: Harri.Hakala@ericsson.com, Leena.Mattila@= ericsson.com, juha-pekka.koskinen@nokia.= com, marco.stura@nokia.com, John.Loughney@nokia.com, bclaise@cisco.com, joelja@bogus.com, Bernard_Aboba@hotmail.com= , david@mitton.com, john.loughney@nokia.com CC: dengzhenjie@huawei.com, rfc-editor@rfc-edito= r.org The following errata report has been submitted for RFC4006, "Diameter Credit-Control Application". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=3D4006&eid=3D4890 -------------------------------------- Type: Editorial Reported by: dengzhenjie Section: 7 Original Text ------------- | PendingE | Failure to send; requested | Store | Idle | | | action DIRECT_DEBITING; DDFH | request | | | | equal to TERMINATE_OR_BUFFER | with | | | | | T-flag | | | PendingE | Failure to send; requested | Store | Idle | | | action DIRECT_DEBITING; DDFH | request | | | | equal to TERMINATE_OR_BUFFER | with | | | | | T-flag | | Corrected Text -------------- | PendingE | Failure to send; requested | Store | Idle | | | action DIRECT_DEBITING; DDFH | request | | | | equal to TERMINATE_OR_BUFFER | with | | | | | T-flag | | Notes ----- the state machine in the table of ''client, event based'' is duplicated Instructions: ------------- This erratum 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 can log in to change the status and edit the report, if necessary. -------------------------------------- RFC4006 (draft-ietf-aaa-diameter-cc-06) -------------------------------------- Title : Diameter Credit-Control Application Publication Date : August 2005 Author(s) : H. Hakala, L. Mattila, J-P. Koskinen, M. Stura, J. Lo= ughney Category : PROPOSED STANDARD Source : Authentication, Authorization and Accounting Area : Operations and Management Stream : IETF Verifying Party : IESG . ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou = falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou = falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. --_000_6B7134B31289DC4FAF731D844122B36E0BFC5F10OPEXCLILM43corp_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

I think it= is just an editorial mistake. but this not related to the RFC4006 but to t= he current version of the draft ht= tps://datatracker.ietf.org/doc/draft-ietf-dime-rfc4006bis/

 = ;

Lionel

 = ;

De := Benoit Claise [mailto:bclaise@cisco.com]
Envoy=E9 : mardi 3 janvier 2017 12:27
=C0 : MORAND Lionel IMT/OLN; aaa-doctors@ietf.org; sec-ads@ietf= .org
Cc : Jouni; Dave Dolson; Bertz, Lyle T [CTO]
Objet : Re: [AAA-DOCTORS] Fwd: [Editorial Errata Reported] RFC4= 006 (4890)

 

If it's a simple duplicate, isn't an editorial mista= ke?

Regards, B.

As for ano= ther errata report, it seems that this one is also related to the draft RFC= 4006bis and not to the existing RFC.

 

Please con= firm.

 

Regards,

 

Lionel

 

De := AAA-DOCTORS [mailto:aaa-doctors-bounces@ietf.org] De la part de Benoit Claise
Envoy=E9 : lundi 19 d=E9cembre 2016 11:36
=C0 : aaa-doctors@ietf.= org; sec-ads@ietf.org
Objet : [AAA-DOCTORS] Fwd: [Editorial Errata Reported] RFC4006 = (4890)

 

And what about this one?
Simple editorial errata?

Regards, Benoit



-------- Forwarded Message --------

Subjec= t:

[Editorial Errata Reported] RFC4006 (4890)

Date: =

Thu, 15 Dec 2016 22:30:32 -0800

From: =

RFC Errata System <rfc-editor@rfc-editor.org>

To:

Harri.H= akala@ericsson.com, Leena.Mattila@ericsson.com, juha-pekka.koskinen@nokia.com, marco.stura@nokia.com, John.Loughney@nokia.com, bclaise@cisco.com, joelja@bogus.com= , Bernard_Aboba@hotmail.com, david@mi= tton.com, john.loughney@nokia.com=

CC:

dengzhenji= e@huawei.com, rfc-editor@rfc-editor.org<= o:p>

 

The following errata report has been submitted for RFC4006,=

"Diameter Credit-Control Application".
 
--------------------------------------
You may review the report below and at:
http://www.rfc-editor.org/errata_search.php?rfc=3D4006&eid=
=3D4890
 
--------------------------------------
Type: Editorial
Reported by: dengzhenjie <=
;dengzhenjie@huawei.com>
 
Section: 7
 
Original Text
-------------
   | PendingE | Failure to send; requested   =
  | Store      | Idle    =
 |
   |          |=
 action DIRECT_DEBITING; DDFH   | request    |&nbs=
p;         |
   |          |=
 equal to TERMINATE_OR_BUFFER   | with    &nb=
sp;  |          |
   |          |=
            &nb=
sp;            =
       | T-flag     |&nbs=
p;         |
   | PendingE | Failure to send; requested   =
  | Store      | Idle    =
 |
   |          |=
 action DIRECT_DEBITING; DDFH   | request    |&nbs=
p;         |
   |          |=
 equal to TERMINATE_OR_BUFFER   | with    &nb=
sp;  |          |
   |          |=
            &nb=
sp;            =
       | T-flag     |&nbs=
p;         |
 
Corrected Text
--------------
   | PendingE | Failure to send; requested   =
  | Store      | Idle    =
 |
   |          |=
 action DIRECT_DEBITING; DDFH   | request    |&nbs=
p;         |
   |          |=
 equal to TERMINATE_OR_BUFFER   | with    &nb=
sp;  |          |
   |          |=
             &n=
bsp;            =
;      | T-flag     |&nbs=
p;         |
 
Notes
-----
the state machine  in the table of ''client, event based'' is dup=
licated
 
Instructions:
-------------
This erratum is currently posted as "Reported". If necessary=
, please
use "Reply All" to discuss whether it should be verified or<=
o:p>
rejected. When a decision is reached, the verifying party  <=
/o:p>
can log in to change the status and edit the report, if necessary. 
 
--------------------------------------
RFC4006 (draft-ietf-aaa-diameter-cc-06)
--------------------------------------
Title           =
;    : Diameter Credit-Control Application
Publication Date    : August 2005
Author(s)           =
: H. Hakala, L. Mattila, J-P. Koskinen, M. Stura, J. Loughney

Category          &n=
bsp; : PROPOSED STANDARD


Source           &nb=
sp;  : Authentication, Authorization and Accounting

Area           =
     : Operations and Management


Stream          &nbs=
p;   : IETF


Verifying Party     : IESG


.


 


______________________________________________________________________=
___________________________________________________
 
Ce message et ses pieces jointes peuvent contenir des informations con=
fidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez=
 recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messag=
es electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deform=
e ou falsifie. Merci.
 
This message and its attachments may contain confidential or privilege=
d information that may be protected by law;
they should not be distributed, used or copied without authorisation.<=
o:p>
If you have received this email in error, please notify the sender and=
 delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have =
been modified, changed or falsified.
Thank you.

 

______________________________________________________________________=
___________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confiden=
tielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu=
 ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el=
ectroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou =
falsifie. Merci.

This message and its attachments may contain confidential or privileged inf=
ormation that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and dele=
te this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been =
modified, changed or falsified.
Thank you.
--_000_6B7134B31289DC4FAF731D844122B36E0BFC5F10OPEXCLILM43corp_-- From nobody Tue Jan 3 03:31:46 2017 Return-Path: X-Original-To: aaa-doctors@ietfa.amsl.com Delivered-To: aaa-doctors@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CA3191294EB; Tue, 3 Jan 2017 03:31:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.611 X-Spam-Level: X-Spam-Status: No, score=-17.611 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-3.1, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EXZrj1zIB_Bt; Tue, 3 Jan 2017 03:31:42 -0800 (PST) Received: from aer-iport-4.cisco.com (aer-iport-4.cisco.com [173.38.203.54]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BFCD91294FD; Tue, 3 Jan 2017 03:31:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=32394; q=dns/txt; s=iport; t=1483443102; x=1484652702; h=subject:to:references:cc:from:message-id:date: mime-version:in-reply-to; bh=UORMvm9ibmjqmhosaivOuMuUFE0ON/UrAj3fvg20hIo=; b=IgeysjLshBBAxz/HMsQjOfv8Smh81B2SGk7ZY6QItowzFXmmKvQDQCPO nYZX3WVSbAuOh8qloi5W/+A7y5g3CcpCtOdpuz6MLEwGcmcSBVDFc8gSn ZVCaZKMMvfSO7nsUXRUzvtdr4RsaB+qPnTiSIctGPAImrofKJN532QZrg g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0D/AACdimtY/xbLJq1DGhkBAQEBAQEBA?= =?us-ascii?q?QEBAQcBAQEBAYJxOQ0BAQEBAX4vXY1XcpNTh3uLEYIPgggqhXgCgh4UAQIBAQE?= =?us-ascii?q?BAQEBYiiEaAEBAQQnBkELEAsRAwECIQEGByElCQgGAQwGAgEBiFEDGA4tsEw6K?= =?us-ascii?q?4Z9DYMJAQEBAQEBAQEBAQEBAQEBAQEBAQEBHYZFggKBWYEGgTuBEzuBBAsRATw?= =?us-ascii?q?MCoUNHgWIZhGGD4FChEGFPzWNRYN5gXWFCIMnhjGHfoF1VYNmhA8fOGgfFg0WG?= =?us-ascii?q?INjDQ+BXz00AROFfIIuAQEB?= X-IronPort-AV: E=Sophos;i="5.33,451,1477958400"; d="scan'208,217";a="651301116" Received: from aer-iport-nat.cisco.com (HELO aer-core-1.cisco.com) ([173.38.203.22]) by aer-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 03 Jan 2017 11:31:37 +0000 Received: from [10.60.67.87] (ams-bclaise-8916.cisco.com [10.60.67.87]) by aer-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id v03BVan3029182; Tue, 3 Jan 2017 11:31:37 GMT To: lionel.morand@orange.com, "aaa-doctors@ietf.org" , "sec-ads@ietf.org" References: <20160913214213.4DBFAB80B89@rfc-editor.org> <372e075c-1564-b36a-1eb3-e62c8717535f@cisco.com> <2069_1483442208_586B8820_2069_7324_1_6B7134B31289DC4FAF731D844122B36E0BFC5E94@OPEXCLILM43.corporate.adroot.infra.ftgroup> From: Benoit Claise Message-ID: <0e62d5b8-98ea-dfc2-0eb6-2993e22955c9@cisco.com> Date: Tue, 3 Jan 2017 12:31:36 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.6.0 MIME-Version: 1.0 In-Reply-To: <2069_1483442208_586B8820_2069_7324_1_6B7134B31289DC4FAF731D844122B36E0BFC5E94@OPEXCLILM43.corporate.adroot.infra.ftgroup> Content-Type: multipart/alternative; boundary="------------2143CBDADDD5EFC259AADD83" Archived-At: Subject: Re: [AAA-DOCTORS] Fwd: [Editorial Errata Reported] RFC6733 (4803) X-BeenThere: aaa-doctors@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: AAA Doctors E-mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Jan 2017 11:31:44 -0000 This is a multi-part message in MIME format. --------------2143CBDADDD5EFC259AADD83 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Thanks Lionel, Where should the resolution be discussed? Here on the mailing list? At least the reporter Holger Freyther should be included IMO. Regards, Benoit > > This errata report is correct on the inconsistency regarding the > definition of the command header and AVP header and how they are used > in the rest of the document in the ABNF description of commands and > Grouped AVPs. > > For commands, the header is defined as follow: > > header = " > [r-bit] [p-bit] [e-bit] [application-id]">" > > whereas " > Same for Grouped AVP. It is defined as follow: > > header = "<" "AVP-Header:" avpcode [vendor] ">" > > whereas " > Considering that most (if not all) the ABNF descriptions have been > copied from the commands and Grouped AVPs defined in the RFC3588 or > RFC6733, I would be in favor to correct the specification by modifying > the definition of the headers, i.e. > > --> In section 3.2. Command Code Format Specification > > OLD: > > header = " > [r-bit] [p-bit] [e-bit] [application-id]">" > > NEW: > > header = " > [r-bit] [p-bit] [e-bit] [application-id]">" > > --> And in section 4.4 > > OLD: > > header = "<" "AVP-Header:" avpcode [vendor] ">" > > NEW: > > header = "<" "AVP Header:" avpcode [vendor] ">" > > For command-def = "<" command-name ">" "::=" diameter-message, I > would propose to simply correct the example as all the command > definitions given in the document are following the command-def > definition. > > For the grouped-avp-def, I don't know what would be the best approach. > We could follow the same approach and require the addition of "<>" but > I don't know what would be the impacts on existing Grouped AVPs > defined without. > > Regards, > > Lionel. > > *De :*AAA-DOCTORS [mailto:aaa-doctors-bounces@ietf.org] *De la part > de* Benoit Claise > *Envoyé :* lundi 19 décembre 2016 11:52 > *À :* aaa-doctors@ietf.org; sec-ads@ietf.org > *Objet :* [AAA-DOCTORS] Fwd: [Editorial Errata Reported] RFC6733 (4803) > > Ditto ... > > Regards, B. > > > > -------- Forwarded Message -------- > > *Subject: * > > > > [Editorial Errata Reported] RFC6733 (4803) > > *Date: * > > > > Tue, 13 Sep 2016 14:42:13 -0700 > > *From: * > > > > RFC Errata System > > > *To: * > > > > vf0213@gmail.com , jari.arkko@ericsson.com > , john.loughney@nokia.com > , glenzorn@gmail.com > , bclaise@cisco.com > , joelja@bogus.com > , jouni.nospam@gmail.com > , lionel.morand@orange.com > > > *CC: * > > > > holger+ietf@freyther.de , > dime@ietf.org , rfc-editor@rfc-editor.org > > > The following errata report has been submitted for RFC6733, > "Diameter Base Protocol". > -------------------------------------- > You may review the report below and at: > http://www.rfc-editor.org/errata_search.php?rfc=6733&eid=4803 > -------------------------------------- > Type: Editorial > Reported by: Holger Freyther > Section: 3.2 > Original Text > ------------- > Example-Request ::= < Diameter Header: 9999999, REQ, PXY > > { User-Name } > 1* { Origin-Host } > * [ AVP ] > Corrected Text > -------------- > ::= < Diameter-Header: 9999999, REQ, PXY > > { User-Name } > 1* { Origin-Host } > * [ AVP ] > Notes > ----- > I converted the BNF into a PetitParser parser in Smalltalk/Pharo and noticed that example and grammar do not match. The first issue is with the example following the grammar but most definitions do not follow the BNF so maybe it is best to update the BNF. > header = " [r-bit] [p-bit] [e-bit] [application-id]">" > But "Diameter-Header:" is not used throughout the text so maybe it is better to update the grammar to "Diameter Header:". > command-def = "<" command-name ">" "::=" diameter-message > but the example is not using <> for the command-name ("Example-Request"). For the grouped-avp-def application is sometimes used with "<" name ">" and sometimes just name. > Instructions: > ------------- > This erratum 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. > -------------------------------------- > RFC6733 (draft-ietf-dime-rfc3588bis-33) > -------------------------------------- > Title : Diameter Base Protocol > Publication Date : October 2012 > Author(s) : V. Fajardo, Ed., J. Arkko, J. Loughney, G. Zorn, Ed. > Category : PROPOSED STANDARD > Source : Diameter Maintenance and Extensions > Area : Operations and Management > Stream : IETF > Verifying Party : IESG > . > _________________________________________________________________________________________________________________________ > > Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc > pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler > a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, > Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. > > This message and its attachments may contain confidential or privileged information that may be protected by law; > they should not be distributed, used or copied without authorisation. > If you have received this email in error, please notify the sender and delete this message and its attachments. > As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified. > Thank you. --------------2143CBDADDD5EFC259AADD83 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit
Thanks Lionel,

Where should the resolution be discussed? Here on the mailing list?
At least the reporter Holger Freyther should be included IMO.

Regards, Benoit

This errata report is correct on the inconsistency regarding the definition of the command header and AVP header and how they are used in the rest of the document in the ABNF description of commands and Grouped AVPs.

 

For commands, the header is defined as follow:

 

   header           = "<Diameter-Header:" command-id

                         [r-bit] [p-bit] [e-bit] [application-id]">"

 

whereas "<Diameter Header:" is used when defining commands.

 

Same for Grouped AVP. It is defined as follow:

 

         header           = "<" "AVP-Header:" avpcode [vendor] ">"

 

whereas "<AVP Header:" is used when defining Grouped AVPs.

 

Considering that most (if not all) the ABNF descriptions have been copied from the commands and Grouped AVPs defined in the RFC3588 or RFC6733, I would be in favor to correct the specification by modifying the definition of the headers, i.e.

 

--> In section 3.2.  Command Code Format Specification

 

OLD:

 

   header           = "<Diameter-Header:" command-id

                         [r-bit] [p-bit] [e-bit] [application-id]">"

 

NEW:

 

   header           = "<Diameter Header:" command-id

                         [r-bit] [p-bit] [e-bit] [application-id]">"

 

 

--> And in section 4.4

 

OLD:

 

         header           = "<" "AVP-Header:" avpcode [vendor] ">"

 

NEW:

 

         header           = "<" "AVP Header:" avpcode [vendor] ">"

 

For command-def  = "<" command-name ">" "::=" diameter-message, I would propose to simply correct the example as all the command definitions given in the document are following the command-def definition.

For the grouped-avp-def, I don't know what would be the best approach. We could follow the same approach and require the addition of "<>" but I don't know what would be the impacts on existing Grouped AVPs defined without.

 

Regards,

 

Lionel.

 

 

De : AAA-DOCTORS [mailto:aaa-doctors-bounces@ietf.org] De la part de Benoit Claise
Envoyé : lundi 19 décembre 2016 11:52
À : aaa-doctors@ietf.org; sec-ads@ietf.org
Objet : [AAA-DOCTORS] Fwd: [Editorial Errata Reported] RFC6733 (4803)

 

Ditto ...

Regards, B.



-------- Forwarded Message --------

Subject:

[Editorial Errata Reported] RFC6733 (4803)

Date:

Tue, 13 Sep 2016 14:42:13 -0700

From:

RFC Errata System <rfc-editor@rfc-editor.org>

To:

vf0213@gmail.com, jari.arkko@ericsson.com, john.loughney@nokia.com, glenzorn@gmail.com, bclaise@cisco.com, joelja@bogus.com, jouni.nospam@gmail.com, lionel.morand@orange.com

CC:

holger+ietf@freyther.de, dime@ietf.org, rfc-editor@rfc-editor.org

 

The following errata report has been submitted for RFC6733,
"Diameter Base Protocol".
 
--------------------------------------
You may review the report below and at:
http://www.rfc-editor.org/errata_search.php?rfc=6733&eid=4803
 
--------------------------------------
Type: Editorial
Reported by: Holger Freyther <holger+ietf@freyther.de>
 
Section: 3.2
 
Original Text
-------------
   Example-Request ::= < Diameter Header: 9999999, REQ, PXY >
                       { User-Name }
                    1* { Origin-Host }
                     * [ AVP ]
 
 
 
Corrected Text
--------------
   <Example-Request> ::= < Diameter-Header: 9999999, REQ, PXY >
                       { User-Name }
                    1* { Origin-Host }
                     * [ AVP ]
 
 
 
Notes
-----
I converted the BNF into a PetitParser parser in Smalltalk/Pharo and noticed that example and grammar do not match. The first issue is with the example following the grammar but most definitions do not follow the BNF so maybe it is best to update the BNF. 
 
  header           = "<Diameter-Header:" command-id
                         [r-bit] [p-bit] [e-bit] [application-id]">"
 
But "Diameter-Header:" is not used throughout the text so maybe it is better to update the grammar to "Diameter Header:".
 
 
 command-def      = "<" command-name ">" "::=" diameter-message
 
but the example is not using <> for the command-name ("Example-Request"). For the grouped-avp-def application is sometimes used with "<" name ">" and sometimes just name.
 
Instructions:
-------------
This erratum 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. 
 
--------------------------------------
RFC6733 (draft-ietf-dime-rfc3588bis-33)
--------------------------------------
Title               : Diameter Base Protocol
Publication Date    : October 2012
Author(s)           : V. Fajardo, Ed., J. Arkko, J. Loughney, G. Zorn, Ed.
Category            : PROPOSED STANDARD
Source              : Diameter Maintenance and Extensions
Area                : Operations and Management
Stream              : IETF
Verifying Party     : IESG
 
.
 
_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.

--------------2143CBDADDD5EFC259AADD83-- From nobody Tue Jan 3 03:40:03 2017 Return-Path: X-Original-To: aaa-doctors@ietfa.amsl.com Delivered-To: aaa-doctors@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DD58D1294EB; Tue, 3 Jan 2017 03:40:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.708 X-Spam-Level: X-Spam-Status: No, score=-5.708 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-3.1, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wKKM6XyDt_qt; Tue, 3 Jan 2017 03:39:59 -0800 (PST) Received: from relais-inet.orange.com (mta136.mail.business.static.orange.com [80.12.70.36]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 68BC9128AC9; Tue, 3 Jan 2017 03:39:59 -0800 (PST) Received: from opfednr07.francetelecom.fr (unknown [xx.xx.xx.71]) by opfednr23.francetelecom.fr (ESMTP service) with ESMTP id 2A31EC0BE2; Tue, 3 Jan 2017 12:39:58 +0100 (CET) Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.43]) by opfednr07.francetelecom.fr (ESMTP service) with ESMTP id B735C1C0064; Tue, 3 Jan 2017 12:39:57 +0100 (CET) Received: from OPEXCLILM43.corporate.adroot.infra.ftgroup ([fe80::ec23:902:c31f:731c]) by OPEXCLILM5F.corporate.adroot.infra.ftgroup ([fe80::e172:f13e:8be6:71cc%18]) with mapi id 14.03.0319.002; Tue, 3 Jan 2017 12:39:57 +0100 From: To: Benoit Claise , "aaa-doctors@ietf.org" , "sec-ads@ietf.org" Thread-Topic: [AAA-DOCTORS] Fwd: [Editorial Errata Reported] RFC6733 (4803) Thread-Index: AQHSWeYdhHq35r8PM0yaMog4/GN22aEmqGdw///86wCAABLq4A== Date: Tue, 3 Jan 2017 11:39:56 +0000 Message-ID: <1426_1483443597_586B8D8D_1426_6386_1_6B7134B31289DC4FAF731D844122B36E0BFC5FC0@OPEXCLILM43.corporate.adroot.infra.ftgroup> References: <20160913214213.4DBFAB80B89@rfc-editor.org> <372e075c-1564-b36a-1eb3-e62c8717535f@cisco.com> <2069_1483442208_586B8820_2069_7324_1_6B7134B31289DC4FAF731D844122B36E0BFC5E94@OPEXCLILM43.corporate.adroot.infra.ftgroup> <0e62d5b8-98ea-dfc2-0eb6-2993e22955c9@cisco.com> In-Reply-To: <0e62d5b8-98ea-dfc2-0eb6-2993e22955c9@cisco.com> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.5] Content-Type: multipart/alternative; boundary="_000_6B7134B31289DC4FAF731D844122B36E0BFC5FC0OPEXCLILM43corp_" MIME-Version: 1.0 Archived-At: Subject: Re: [AAA-DOCTORS] Fwd: [Editorial Errata Reported] RFC6733 (4803) X-BeenThere: aaa-doctors@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: AAA Doctors E-mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Jan 2017 11:40:03 -0000 --_000_6B7134B31289DC4FAF731D844122B36E0BFC5FC0OPEXCLILM43corp_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I will forward it on the mailing list, copying the Holger. Lionel De : Benoit Claise [mailto:bclaise@cisco.com] Envoy=E9 : mardi 3 janvier 2017 12:32 =C0 : MORAND Lionel IMT/OLN; aaa-doctors@ietf.org; sec-ads@ietf.org Cc : Jouni Objet : Re: [AAA-DOCTORS] Fwd: [Editorial Errata Reported] RFC6733 (4803) Thanks Lionel, Where should the resolution be discussed? Here on the mailing list? At least the reporter Holger Freyther should be included IMO. Regards, Benoit This errata report is correct on the inconsistency regarding the definition= of the command header and AVP header and how they are used in the rest of = the document in the ABNF description of commands and Grouped AVPs. For commands, the header is defined as follow: header =3D "" whereas "" whereas " In section 3.2. Command Code Format Specification OLD: header =3D "" NEW: header =3D "" --> And in section 4.4 OLD: header =3D "<" "AVP-Header:" avpcode [vendor] ">" NEW: header =3D "<" "AVP Header:" avpcode [vendor] ">" For command-def =3D "<" command-name ">" "::=3D" diameter-message, I would= propose to simply correct the example as all the command definitions given= in the document are following the command-def definition. For the grouped-avp-def, I don't know what would be the best approach. We c= ould follow the same approach and require the addition of "<>" but I don't = know what would be the impacts on existing Grouped AVPs defined without. Regards, Lionel. De : AAA-DOCTORS [mailto:aaa-doctors-bounces@ietf.org] De la part de Benoit= Claise Envoy=E9 : lundi 19 d=E9cembre 2016 11:52 =C0 : aaa-doctors@ietf.org; sec-ads@ietf.org Objet : [AAA-DOCTORS] Fwd: [Editorial Errata Reported] RFC6733 (4803) Ditto ... Regards, B. -------- Forwarded Message -------- Subject: [Editorial Errata Reported] RFC6733 (4803) Date: Tue, 13 Sep 2016 14:42:13 -0700 From: RFC Errata System To: vf0213@gmail.com, jari.arkko@ericsson.com, john.loughney@nokia.com, glenzorn@gmail.com, bclaise@cisco.com, joelja@bogus.com, jouni.no= spam@gmail.com, lionel.morand@orange.com CC: holger+ietf@freyther.de, dime@ietf.org, rfc-editor@rfc-editor.org The following errata report has been submitted for RFC6733, "Diameter Base Protocol". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=3D6733&eid=3D4803 -------------------------------------- Type: Editorial Reported by: Holger Freyther Section: 3.2 Original Text ------------- Example-Request ::=3D < Diameter Header: 9999999, REQ, PXY > { User-Name } 1* { Origin-Host } * [ AVP ] Corrected Text -------------- ::=3D < Diameter-Header: 9999999, REQ, PXY > { User-Name } 1* { Origin-Host } * [ AVP ] Notes ----- I converted the BNF into a PetitParser parser in Smalltalk/Pharo and notice= d that example and grammar do not match. The first issue is with the exampl= e following the grammar but most definitions do not follow the BNF so maybe= it is best to update the BNF. header =3D "" But "Diameter-Header:" is not used throughout the text so maybe it is bette= r to update the grammar to "Diameter Header:". command-def =3D "<" command-name ">" "::=3D" diameter-message but the example is not using <> for the command-name ("Example-Request"). F= or the grouped-avp-def application is sometimes used with "<" name ">" and = sometimes just name. Instructions: ------------- This erratum 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. -------------------------------------- RFC6733 (draft-ietf-dime-rfc3588bis-33) -------------------------------------- Title : Diameter Base Protocol Publication Date : October 2012 Author(s) : V. Fajardo, Ed., J. Arkko, J. Loughney, G. Zorn, Ed. Category : PROPOSED STANDARD Source : Diameter Maintenance and Extensions Area : Operations and Management Stream : IETF Verifying Party : IESG . ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou = falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou = falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. --_000_6B7134B31289DC4FAF731D844122B36E0BFC5FC0OPEXCLILM43corp_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

I will for= ward it on the mailing list, copying the Holger.

 = ;

Lionel

 = ;

De := Benoit Claise [mailto:bclaise@cisco.com]
Envoy=E9 : mardi 3 janvier 2017 12:32
=C0 : MORAND Lionel IMT/OLN; aaa-doctors@ietf.org; sec-ads@ietf= .org
Cc : Jouni
Objet : Re: [AAA-DOCTORS] Fwd: [Editorial Errata Reported] RFC6= 733 (4803)

 

Thanks Lionel,

Where should the resolution be discussed? Here on the mailing list?
At least the reporter Holger Freyther should be included IMO.

Regards, Benoit

This errat= a report is correct on the inconsistency regarding the definition of the co= mmand header and AVP header and how they are used in the rest of the document in the ABNF description of commands and Grouped AVPs.

 

For comman= ds, the header is defined as follow:

 

 &nbs= p; header           =3D &= quot;<Diameter-Header:" command-id

 &nbs= p;            &= nbsp;          [r-bit] [p-bit]= [e-bit] [application-id]">"

 

whereas &q= uot;<Diameter Header:" is used when defining commands.<= /o:p>

 

Same for G= rouped AVP. It is defined as follow:

 

 &nbs= p;       header     =       =3D "<" "AVP-Header:"= avpcode [vendor] ">"

 

whereas &q= uot;<AVP Header:" is used when defining Grouped AVPs.

 

Considerin= g that most (if not all) the ABNF descriptions have been copied from the co= mmands and Grouped AVPs defined in the RFC3588 or RFC6733, I would be in favor to correct the specification by modifying the definiti= on of the headers, i.e.

 

--> In = section 3.2.  Command Code Format Specification

 

OLD:

 

 &nbs= p; header           = =3D "<Diameter-Header:" command-id

 &nbs= p;            &= nbsp;          [r-bit] [p-bit]= [e-bit] [application-id]">"

 

NEW:

 

 &nbs= p; header           = =3D "<Diameter Header:" command-id

 &nbs= p;            &= nbsp;          [r-bit] [p-bit]= [e-bit] [application-id]">"

 

 

--> And= in section 4.4

 

OLD:

 

 &nbs= p;       header     =       =3D "<" "AVP-Header:"= avpcode [vendor] ">"

 

NEW:

 

 &nbs= p;       header     =       =3D "<" "AVP Header:"= avpcode [vendor] ">"

 

For comman= d-def  =3D "<" command-name ">" "::=3D&= quot; diameter-message, I would propose to simply correct the example as al= l the command definitions given in the document are following the command-def definition.

For the gr= ouped-avp-def, I don't know what would be the best approach. We could follo= w the same approach and require the addition of "<>" but I don't know what would be the impacts on existing Grouped AVPs defined with= out.

 

Regards,

 

Lionel.

 

 

De := AAA-DOCTORS [mailto:aaa-doctors-bounces@ietf.org] De la part de Benoit Claise
Envoy=E9 : lundi 19 d=E9cembre 2016 11:52
=C0 : aaa-doctors@ietf.= org; sec-ads@ietf.org
Objet : [AAA-DOCTORS] Fwd: [Editorial Errata Reported] RFC6733 = (4803)

 

Ditto ...

Regards, B.



-------- Forwarded Message --------

Subjec= t:

[Editorial Errata Reported] RFC6733 (4803)

Date: =

Tue, 13 Sep 2016 14:42:13 -0700

From: =

RFC Errata System <rfc-editor@rfc-editor.org>

To:

vf0213@gmail.com= , jari.arkko@ericsson.com, joh= n.loughney@nokia.com, glenzorn@gmail.com, bclaise@cisco.com, joelja@bogus.com= , jouni.nospam@gmail.com, lio= nel.morand@orange.com

CC:

holge= r+ietf@freyther.de, dime@ietf.org, rfc-editor@rfc-editor.org

 

The following errata report has been submitted for RFC6733,=

"Diameter Base Protocol".
 
--------------------------------------
You may review the report below and at:
http://www.rfc-editor.org/errata_search.php?rfc=3D6733&eid=
=3D4803
 
--------------------------------------
Type: Editorial
Reported by: Holger Freyther <holger+ietf@freyther.de>
 
Section: 3.2
 
Original Text
-------------
   Example-Request ::=3D < Diameter Header: 9999999, REQ,=
 PXY >
           &nbs=
p;           { User-Name =
}
           &nbs=
p;        1* { Origin-Host }<=
/pre>

           &nbs=
p;         * [ AVP ]

 


 


 


Corrected Text


--------------


   <Example-Request> ::=3D < Diameter-Header: 99999=
99, REQ, PXY >


           &nbs=
p;           { User-Name =
}


           &nbs=
p;        1* { Origin-Host }<=
/pre>

           &nbs=
p;         * [ AVP ]

 


 


 


Notes


-----


I converted the BNF into a PetitParser parser in Smalltalk/Pharo and n=
oticed that example and grammar do not match. The first issue is with the e=
xample following the grammar but most definitions do not follow the BNF so =
maybe it is best to update the BNF. 


 


  header         &nb=
sp; =3D "<Diameter-Header:" command-id


           &nbs=
p;             =
[r-bit] [p-bit] [e-bit] [application-id]">"


 


But "Diameter-Header:" is not used throughout the text so ma=
ybe it is better to update the grammar to "Diameter Header:".


 


 


 command-def      =3D "<" comman=
d-name ">" "::=3D" diameter-message


 


but the example is not using <> for the command-name ("Exam=
ple-Request"). For the grouped-avp-def application is sometimes used w=
ith "<" name ">" and sometimes just name.


 


Instructions:


-------------


This erratum is currently posted as "Reported". If necessary=
, please


use "Reply All" to discuss whether it should be verified or<=
o:p>


rejected. When a decision is reached, the verifying party (IESG)<=
/o:p>


can log in to change the status and edit the report, if necessary. 


 


--------------------------------------


RFC6733 (draft-ietf-dime-rfc3588bis-33)


--------------------------------------


Title           =
;    : Diameter Base Protocol


Publication Date    : October 2012


Author(s)           =
: V. Fajardo, Ed., J. Arkko, J. Loughney, G. Zorn, Ed.


Category          &n=
bsp; : PROPOSED STANDARD


Source          &nbs=
p;   : Diameter Maintenance and Extensions


Area           =
     : Operations and Management


Stream          &nbs=
p;   : IETF


Verifying Party     : IESG


 


.


 


______________________________________________________________________=
___________________________________________________
 
Ce message et ses pieces jointes peuvent contenir des informations con=
fidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez=
 recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messag=
es electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deform=
e ou falsifie. Merci.
 
This message and its attachments may contain confidential or privilege=
d information that may be protected by law;
they should not be distributed, used or copied without authorisation.<=
o:p>
If you have received this email in error, please notify the sender and=
 delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have =
been modified, changed or falsified.
Thank you.

 

______________________________________________________________________=
___________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confiden=
tielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu=
 ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el=
ectroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou =
falsifie. Merci.

This message and its attachments may contain confidential or privileged inf=
ormation that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and dele=
te this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been =
modified, changed or falsified.
Thank you.
--_000_6B7134B31289DC4FAF731D844122B36E0BFC5FC0OPEXCLILM43corp_-- From nobody Tue Jan 3 03:45:42 2017 Return-Path: X-Original-To: aaa-doctors@ietfa.amsl.com Delivered-To: aaa-doctors@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D91B01294EB; Tue, 3 Jan 2017 03:45:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.018 X-Spam-Level: X-Spam-Status: No, score=-5.018 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-3.1, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Uyn_LudljQEN; Tue, 3 Jan 2017 03:45:36 -0800 (PST) Received: from relais-inet.orange.com (mta239.mail.business.static.orange.com [80.12.66.39]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A2BE8129435; Tue, 3 Jan 2017 03:45:35 -0800 (PST) Received: from opfedar02.francetelecom.fr (unknown [xx.xx.xx.4]) by opfedar24.francetelecom.fr (ESMTP service) with ESMTP id 5232EC0958; Tue, 3 Jan 2017 12:45:34 +0100 (CET) Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.57]) by opfedar02.francetelecom.fr (ESMTP service) with ESMTP id 33016180062; Tue, 3 Jan 2017 12:45:34 +0100 (CET) Received: from OPEXCLILM43.corporate.adroot.infra.ftgroup ([fe80::ec23:902:c31f:731c]) by OPEXCLILM23.corporate.adroot.infra.ftgroup ([fe80::787e:db0c:23c4:71b3%19]) with mapi id 14.03.0319.002; Tue, 3 Jan 2017 12:45:33 +0100 From: To: Benoit Claise , "aaa-doctors@ietf.org" , "sec-ads@ietf.org" Thread-Topic: [AAA-DOCTORS] Fwd: [Editorial Errata Reported] RFC6733 (4803) Thread-Index: AQHSWeYdhHq35r8PM0yaMog4/GN22aEmqGdwgAAQ10A= Date: Tue, 3 Jan 2017 11:45:33 +0000 Message-ID: <17526_1483443934_586B8EDE_17526_11792_1_6B7134B31289DC4FAF731D844122B36E0BFC600A@OPEXCLILM43.corporate.adroot.infra.ftgroup> References: <20160913214213.4DBFAB80B89@rfc-editor.org> <372e075c-1564-b36a-1eb3-e62c8717535f@cisco.com> <2069_1483442208_586B8820_2069_7324_1_6B7134B31289DC4FAF731D844122B36E0BFC5E94@OPEXCLILM43.corporate.adroot.infra.ftgroup> In-Reply-To: <2069_1483442208_586B8820_2069_7324_1_6B7134B31289DC4FAF731D844122B36E0BFC5E94@OPEXCLILM43.corporate.adroot.infra.ftgroup> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.5] Content-Type: multipart/alternative; boundary="_000_6B7134B31289DC4FAF731D844122B36E0BFC600AOPEXCLILM43corp_" MIME-Version: 1.0 Archived-At: Cc: "dime@ietf.org" , "holger+ietf@freyther.de" Subject: Re: [AAA-DOCTORS] Fwd: [Editorial Errata Reported] RFC6733 (4803) X-BeenThere: aaa-doctors@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: AAA Doctors E-mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Jan 2017 11:45:38 -0000 --_000_6B7134B31289DC4FAF731D844122B36E0BFC600AOPEXCLILM43corp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable This errata report is correct on the inconsistency regarding the definition= of the command header and AVP header and how they are used in the rest of = the document in the ABNF description of commands and Grouped AVPs. For commands, the header is defined as follow: header =3D "" whereas "" whereas " In section 3.2. Command Code Format Specification OLD: header =3D "" NEW: header =3D "" --> And in section 4.4 OLD: header =3D "<" "AVP-Header:" avpcode [vendor] ">" NEW: header =3D "<" "AVP Header:" avpcode [vendor] ">" ******************* There are other issues pointed out in this report. For command-def =3D "<" command-name ">" "::=3D" diameter-message, I would= propose to simply correct the example as all the command definitions given= in the document are following the command-def definition. For the grouped-avp-def, I don't know what would be the best approach. We c= ould follow the same approach and require the addition of "<>" but I don't = know what would be the impacts on existing Grouped AVPs defined without. Regards, Lionel. -------- Forwarded Message -------- Subject: [Editorial Errata Reported] RFC6733 (4803) Date: Tue, 13 Sep 2016 14:42:13 -0700 From: RFC Errata System To: vf0213@gmail.com, jari.arkko@ericsson.com, john.loughney@nokia.com, glenzorn@gmail.com, bclaise@cisco.com, joelja@bogus.com, jouni.no= spam@gmail.com, lionel.morand@orange.com CC: holger+ietf@freyther.de, dime@ietf.org, rfc-editor@rfc-editor.org The following errata report has been submitted for RFC6733, "Diameter Base Protocol". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=3D6733&eid=3D4803 -------------------------------------- Type: Editorial Reported by: Holger Freyther Section: 3.2 Original Text ------------- Example-Request ::=3D < Diameter Header: 9999999, REQ, PXY > { User-Name } 1* { Origin-Host } * [ AVP ] Corrected Text -------------- ::=3D < Diameter-Header: 9999999, REQ, PXY > { User-Name } 1* { Origin-Host } * [ AVP ] Notes ----- I converted the BNF into a PetitParser parser in Smalltalk/Pharo and notice= d that example and grammar do not match. The first issue is with the exampl= e following the grammar but most definitions do not follow the BNF so maybe= it is best to update the BNF. header =3D "" But "Diameter-Header:" is not used throughout the text so maybe it is bette= r to update the grammar to "Diameter Header:". command-def =3D "<" command-name ">" "::=3D" diameter-message but the example is not using <> for the command-name ("Example-Request"). F= or the grouped-avp-def application is sometimes used with "<" name ">" and = sometimes just name. Instructions: ------------- This erratum 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. -------------------------------------- RFC6733 (draft-ietf-dime-rfc3588bis-33) -------------------------------------- Title : Diameter Base Protocol Publication Date : October 2012 Author(s) : V. Fajardo, Ed., J. Arkko, J. Loughney, G. Zorn, Ed. Category : PROPOSED STANDARD Source : Diameter Maintenance and Extensions Area : Operations and Management Stream : IETF Verifying Party : IESG . ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou = falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou = falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. --_000_6B7134B31289DC4FAF731D844122B36E0BFC600AOPEXCLILM43corp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

This errat= a report is correct on the inconsistency regarding the definition of the co= mmand header and AVP header and how they are used in the rest of the document in the ABNF description of commands and Grouped AVPs.=

 = ;

For comman= ds, the header is defined as follow:

 = ;

 &nbs= p; header           =3D &= quot;<Diameter-Header:" command-id

 &nbs= p;            &= nbsp;          [r-bit] [p-bit]= [e-bit] [application-id]">"

 = ;

whereas &q= uot;<Diameter Header:" is used when defining commands.

 = ;

Same for G= rouped AVP. It is defined as follow:

 = ;

 &nbs= p;       header     =       =3D "<" "AVP-Header:"= avpcode [vendor] ">"

 = ;

whereas &q= uot;<AVP Header:" is used when defining Grouped AVPs.

 = ;

Considerin= g that most (if not all) the ABNF descriptions have been copied from the co= mmands and Grouped AVPs defined in the RFC3588 or RFC6733, I would be in favor to correct the specification by modifying the definiti= on of the headers, i.e.

 = ;

--> In = section 3.2.  Command Code Format Specification

 = ;

OLD:<= /o:p>

 = ;

 &nbs= p; header           = =3D "<Diameter-Header:" command-id

 &nbs= p;            &= nbsp;          [r-bit] [p-bit]= [e-bit] [application-id]">"

 = ;

NEW:<= /o:p>

 = ;

 &nbs= p; header           = =3D "<Diameter Header:" command-id

 &nbs= p;            &= nbsp;          [r-bit] [p-bit]= [e-bit] [application-id]">"

 = ;

 = ;

--> And= in section 4.4

 = ;

OLD:<= /o:p>

 = ;

 &nbs= p;       header     =       =3D "<" "AVP-Header:"= avpcode [vendor] ">"

 = ;

NEW:<= /o:p>

 = ;

 &nbs= p;       header     =       =3D "<" "AVP Header:"= avpcode [vendor] ">"

 = ;

**********= *********

There are = other issues pointed out in this report.

 = ;

For comman= d-def  =3D "<" command-name ">" "::=3D&= quot; diameter-message, I would propose to simply correct the example as al= l the command definitions given in the document are following the command-def definition.

For the gr= ouped-avp-def, I don't know what would be the best approach. We could follo= w the same approach and require the addition of "<>" but I don't know what would be the impacts on existing Grouped AVPs defined with= out.

 = ;

Regards,

 = ;

Lionel.

 <= /p>


-------- Forwarded Message --------

Subjec= t:

[Editorial Errata Reported] RFC6733 (4803)

Date: =

Tue, 13 Sep 2016 14:42:13 -0700

From: =

RFC Errata System <rfc-editor@rfc-editor.org>

To:

vf0213@gmail.com= , jari.arkko@ericsson.com, joh= n.loughney@nokia.com, glenzorn@gmail.com, bclaise@cisco.com, joelja@bogus.com= , jouni.nospam@gmail.com, lio= nel.morand@orange.com

CC:

holge= r+ietf@freyther.de, dime@ietf.org, rfc-editor@rfc-editor.org

 

The following errata report has been submitted for RFC6733,=

"Diameter Base Protocol".
 
--------------------------------------
You may review the report below and at:
http://www.rfc-editor.org/errata_search.php?rfc=3D6733&eid=
=3D4803
 
--------------------------------------
Type: Editorial
Reported by: Holger Freyther <holger+ietf@freyther.de>
 
Section: 3.2
 
Original Text
-------------
   Example-Request ::=3D < Diameter Header: 9999999, REQ,=
 PXY >
           &nbs=
p;           { User-Name =
}
           &nbs=
p;        1* { Origin-Host }<=
/pre>

           &nbs=
p;         * [ AVP ]

 


 


 


Corrected Text


--------------


   <Example-Request> ::=3D < Diameter-Header: 99999=
99, REQ, PXY >


           &nbs=
p;           { User-Name =
}


           &nbs=
p;        1* { Origin-Host }<=
/pre>

           &nbs=
p;         * [ AVP ]

 


 


 


Notes


-----


I converted the BNF into a PetitParser parser in Smalltalk/Pharo and n=
oticed that example and grammar do not match. The first issue is with the e=
xample following the grammar but most definitions do not follow the BNF so =
maybe it is best to update the BNF. 


 


  header         &nb=
sp; =3D "<Diameter-Header:" command-id


           &nbs=
p;             =
[r-bit] [p-bit] [e-bit] [application-id]">"


 


But "Diameter-Header:" is not used throughout the text so ma=
ybe it is better to update the grammar to "Diameter Header:".


 


 


 command-def      =3D "<" comman=
d-name ">" "::=3D" diameter-message


 


but the example is not using <> for the command-name ("Exam=
ple-Request"). For the grouped-avp-def application is sometimes used w=
ith "<" name ">" and sometimes just name.


 


Instructions:


-------------


This erratum is currently posted as "Reported". If necessary=
, please


use "Reply All" to discuss whether it should be verified or<=
o:p>


rejected. When a decision is reached, the verifying party (IESG)<=
/o:p>


can log in to change the status and edit the report, if necessary. 


 


--------------------------------------


RFC6733 (draft-ietf-dime-rfc3588bis-33)


--------------------------------------


Title           =
;    : Diameter Base Protocol


Publication Date    : October 2012


Author(s)           =
: V. Fajardo, Ed., J. Arkko, J. Loughney, G. Zorn, Ed.


Category          &n=
bsp; : PROPOSED STANDARD


Source          &nbs=
p;   : Diameter Maintenance and Extensions


Area           =
     : Operations and Management


Stream          &nbs=
p;   : IETF


Verifying Party     : IESG


 


.


 


______________________________________________________________________=
___________________________________________________
 
Ce message et ses pieces jointes peuvent contenir des informations con=
fidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez=
 recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messag=
es electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deform=
e ou falsifie. Merci.
 
This message and its attachments may contain confidential or privilege=
d information that may be protected by law;
they should not be distributed, used or copied without authorisation.<=
o:p>
If you have received this email in error, please notify the sender and=
 delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have =
been modified, changed or falsified.
Thank you.
______________________________________________________________________=
___________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confiden=
tielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu=
 ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el=
ectroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou =
falsifie. Merci.

This message and its attachments may contain confidential or privileged inf=
ormation that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and dele=
te this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been =
modified, changed or falsified.
Thank you.
--_000_6B7134B31289DC4FAF731D844122B36E0BFC600AOPEXCLILM43corp_-- From nobody Tue Jan 3 04:50:20 2017 Return-Path: X-Original-To: aaa-doctors@ietfa.amsl.com Delivered-To: aaa-doctors@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 87F531295B2; Tue, 3 Jan 2017 04:50:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.611 X-Spam-Level: X-Spam-Status: No, score=-17.611 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-3.1, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vnZgFIMgHlme; Tue, 3 Jan 2017 04:50:16 -0800 (PST) Received: from aer-iport-1.cisco.com (aer-iport-1.cisco.com [173.38.203.51]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5A1E412945B; Tue, 3 Jan 2017 04:50:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=28376; q=dns/txt; s=iport; t=1483447815; x=1484657415; h=subject:to:references:cc:from:message-id:date: mime-version:in-reply-to; bh=dUMW/2Z7WyQj3lQoIQaX579enN8rjPYO3dWa3ilVbMM=; b=QH5yoSB8d9qgRbaKObbaHlCH5xspXLsPG+XEyW6uz5eW/ZO0NxoNVg+s 61a4+ZsBA2wuKVtL2IM85CUC/Am1BWSt8mgUCz7haqDGhqvol5/uvdf+f rzZLx8iXK+rs44rTgr12PoCCjsfO1HsmCLM9TBy1FrgbCEJFKdi4Y3U+i s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0D/AABQnWtY/xbLJq1DGhkBAQEBAQEBA?= =?us-ascii?q?QEBAQcBAQEBAYJxRgEBAQEBfoEMjVdyk1OCNIVHixGCD4IIKoV4AoIeFAECAQE?= =?us-ascii?q?BAQEBAWIohGgBAQEELRoyEAsRAwECIQcHRgkIBgEMBgIBAYhRAxgOLbBxK4MTh?= =?us-ascii?q?wABAQEBAQEBAQEBAQEBAQEBAQEBAQEdhkWCAgiCV4E7gRM7gQ8RATwMCoUNHgW?= =?us-ascii?q?IZhGHUYRBhT81hlSGcoN4gXWFCIMnhjGJc1WDZoQPHzhoHxYNFoN7DQ+BXz00A?= =?us-ascii?q?ROFfIIuAQEB?= X-IronPort-AV: E=Sophos;i="5.33,451,1477958400"; d="scan'208,217";a="691023788" Received: from aer-iport-nat.cisco.com (HELO aer-core-1.cisco.com) ([173.38.203.22]) by aer-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 03 Jan 2017 12:50:10 +0000 Received: from [10.60.67.87] (ams-bclaise-8916.cisco.com [10.60.67.87]) by aer-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id v03Co9A8019558; Tue, 3 Jan 2017 12:50:09 GMT To: lionel.morand@orange.com, "aaa-doctors@ietf.org" , "sec-ads@ietf.org" References: <20161216063032.A1093B80FA4@rfc-editor.org> <32602_1483439290_586B7CBA_32602_637_1_6B7134B31289DC4FAF731D844122B36E0BFC5CDA@OPEXCLILM43.corporate.adroot.infra.ftgroup> <1a7315df-91d7-4213-152c-cd289321e30d@cisco.com> <15517_1483442960_586B8B10_15517_799_3_6B7134B31289DC4FAF731D844122B36E0BFC5F10@OPEXCLILM43.corporate.adroot.infra.ftgroup> From: Benoit Claise Message-ID: <6f7379d6-76ee-41a1-3469-a319d56b564e@cisco.com> Date: Tue, 3 Jan 2017 13:50:08 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.6.0 MIME-Version: 1.0 In-Reply-To: <15517_1483442960_586B8B10_15517_799_3_6B7134B31289DC4FAF731D844122B36E0BFC5F10@OPEXCLILM43.corporate.adroot.infra.ftgroup> Content-Type: multipart/alternative; boundary="------------C45A88CADD7DAE7597CD933E" Archived-At: Cc: "Bertz, Lyle T \[CTO\]" , Dave Dolson Subject: Re: [AAA-DOCTORS] Fwd: [Editorial Errata Reported] RFC4006 (4890) X-BeenThere: aaa-doctors@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: AAA Doctors E-mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Jan 2017 12:50:18 -0000 This is a multi-part message in MIME format. --------------C45A88CADD7DAE7597CD933E Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Thanks, I will reject this erratum. Regards, B. > > I think it is just an editorial mistake. but this not related to the > RFC4006 but to the current version of the draft > https://datatracker.ietf.org/doc/draft-ietf-dime-rfc4006bis/ > > Lionel > > *De :*Benoit Claise [mailto:bclaise@cisco.com] > *Envoyé :* mardi 3 janvier 2017 12:27 > *À :* MORAND Lionel IMT/OLN; aaa-doctors@ietf.org; sec-ads@ietf.org > *Cc :* Jouni; Dave Dolson; Bertz, Lyle T [CTO] > *Objet :* Re: [AAA-DOCTORS] Fwd: [Editorial Errata Reported] RFC4006 > (4890) > > If it's a simple duplicate, isn't an editorial mistake? > > Regards, B. > > As for another errata report, it seems that this one is also > related to the draft RFC4006bis and not to the existing RFC. > > Please confirm. > > Regards, > > Lionel > > *De :*AAA-DOCTORS [mailto:aaa-doctors-bounces@ietf.org] *De la > part de* Benoit Claise > *Envoyé :* lundi 19 décembre 2016 11:36 > *À :* aaa-doctors@ietf.org ; > sec-ads@ietf.org > *Objet :* [AAA-DOCTORS] Fwd: [Editorial Errata Reported] RFC4006 > (4890) > > And what about this one? > Simple editorial errata? > > Regards, Benoit > > > > -------- Forwarded Message -------- > > *Subject: * > > > > [Editorial Errata Reported] RFC4006 (4890) > > *Date: * > > > > Thu, 15 Dec 2016 22:30:32 -0800 > > *From: * > > > > RFC Errata System > > > *To: * > > > > Harri.Hakala@ericsson.com , > Leena.Mattila@ericsson.com , > juha-pekka.koskinen@nokia.com > , marco.stura@nokia.com > , John.Loughney@nokia.com > , bclaise@cisco.com > , joelja@bogus.com > , Bernard_Aboba@hotmail.com > , david@mitton.com > , john.loughney@nokia.com > > > *CC: * > > > > dengzhenjie@huawei.com , > rfc-editor@rfc-editor.org > > The following errata report has been submitted for RFC4006, > > "Diameter Credit-Control Application". > > > > -------------------------------------- > > You may review the report below and at: > > http://www.rfc-editor.org/errata_search.php?rfc=4006&eid=4890 > > > > -------------------------------------- > > Type: Editorial > > Reported by: dengzhenjie > > > > Section: 7 > > > > Original Text > > ------------- > > | PendingE | Failure to send; requested | Store | Idle | > > | | action DIRECT_DEBITING; DDFH | request | | > > | | equal to TERMINATE_OR_BUFFER | with | | > > | | | T-flag | | > > | PendingE | Failure to send; requested | Store | Idle | > > | | action DIRECT_DEBITING; DDFH | request | | > > | | equal to TERMINATE_OR_BUFFER | with | | > > | | | T-flag | | > > > > Corrected Text > > -------------- > > | PendingE | Failure to send; requested | Store | Idle | > > | | action DIRECT_DEBITING; DDFH | request | | > > | | equal to TERMINATE_OR_BUFFER | with | | > > | | | T-flag | | > > > > Notes > > ----- > > the state machine in the table of ''client, event based'' is duplicated > > > > Instructions: > > ------------- > > This erratum 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 > > can log in to change the status and edit the report, if necessary. > > > > -------------------------------------- > > RFC4006 (draft-ietf-aaa-diameter-cc-06) > > -------------------------------------- > > Title : Diameter Credit-Control Application > > Publication Date : August 2005 > > Author(s) : H. Hakala, L. Mattila, J-P. Koskinen, M. Stura, J. Loughney > > Category : PROPOSED STANDARD > > Source : Authentication, Authorization and Accounting > > Area : Operations and Management > > Stream : IETF > > Verifying Party : IESG > > . > > > > _________________________________________________________________________________________________________________________ > > Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc > > pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler > > a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, > > Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. > > This message and its attachments may contain confidential or privileged information that may be protected by law; > > they should not be distributed, used or copied without authorisation. > > If you have received this email in error, please notify the sender and delete this message and its attachments. > > As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified. > > Thank you. > > _________________________________________________________________________________________________________________________ > > Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc > pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler > a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, > Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. > > This message and its attachments may contain confidential or privileged information that may be protected by law; > they should not be distributed, used or copied without authorisation. > If you have received this email in error, please notify the sender and delete this message and its attachments. > As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified. > Thank you. --------------C45A88CADD7DAE7597CD933E Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit
Thanks, I will reject this erratum.

Regards, B.

I think it is just an editorial mistake. but this not related to the RFC4006 but to the current version of the draft https://datatracker.ietf.org/doc/draft-ietf-dime-rfc4006bis/

 

Lionel

 

De : Benoit Claise [mailto:bclaise@cisco.com]
Envoyé : mardi 3 janvier 2017 12:27
À : MORAND Lionel IMT/OLN; aaa-doctors@ietf.org; sec-ads@ietf.org
Cc : Jouni; Dave Dolson; Bertz, Lyle T [CTO]
Objet : Re: [AAA-DOCTORS] Fwd: [Editorial Errata Reported] RFC4006 (4890)

 

If it's a simple duplicate, isn't an editorial mistake?

Regards, B.

As for another errata report, it seems that this one is also related to the draft RFC4006bis and not to the existing RFC.

 

Please confirm.

 

Regards,

 

Lionel

 

De : AAA-DOCTORS [mailto:aaa-doctors-bounces@ietf.org] De la part de Benoit Claise
Envoyé : lundi 19 décembre 2016 11:36
À : aaa-doctors@ietf.org; sec-ads@ietf.org
Objet : [AAA-DOCTORS] Fwd: [Editorial Errata Reported] RFC4006 (4890)

 

And what about this one?
Simple editorial errata?

Regards, Benoit



-------- Forwarded Message --------

Subject:

[Editorial Errata Reported] RFC4006 (4890)

Date:

Thu, 15 Dec 2016 22:30:32 -0800

From:

RFC Errata System <rfc-editor@rfc-editor.org>

To:

Harri.Hakala@ericsson.com, Leena.Mattila@ericsson.com, juha-pekka.koskinen@nokia.com, marco.stura@nokia.com, John.Loughney@nokia.com, bclaise@cisco.com, joelja@bogus.com, Bernard_Aboba@hotmail.com, david@mitton.com, john.loughney@nokia.com

CC:

dengzhenjie@huawei.com, rfc-editor@rfc-editor.org

 

The following errata report has been submitted for RFC4006,
"Diameter Credit-Control Application".
 
--------------------------------------
You may review the report below and at:
http://www.rfc-editor.org/errata_search.php?rfc=4006&eid=4890
 
--------------------------------------
Type: Editorial
Reported by: dengzhenjie <dengzhenjie@huawei.com>
 
Section: 7
 
Original Text
-------------
   | PendingE | Failure to send; requested     | Store      | Idle     |
   |          | action DIRECT_DEBITING; DDFH   | request    |          |
   |          | equal to TERMINATE_OR_BUFFER   | with       |          |
   |          |                                | T-flag     |          |
   | PendingE | Failure to send; requested     | Store      | Idle     |
   |          | action DIRECT_DEBITING; DDFH   | request    |          |
   |          | equal to TERMINATE_OR_BUFFER   | with       |          |
   |          |                                | T-flag     |          |
 
Corrected Text
--------------
   | PendingE | Failure to send; requested     | Store      | Idle     |
   |          | action DIRECT_DEBITING; DDFH   | request    |          |
   |          | equal to TERMINATE_OR_BUFFER   | with       |          |
   |          |                                | T-flag     |          |
 
Notes
-----
the state machine  in the table of ''client, event based'' is duplicated
 
Instructions:
-------------
This erratum 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  
can log in to change the status and edit the report, if necessary. 
 
--------------------------------------
RFC4006 (draft-ietf-aaa-diameter-cc-06)
--------------------------------------
Title               : Diameter Credit-Control Application
Publication Date    : August 2005
Author(s)           : H. Hakala, L. Mattila, J-P. Koskinen, M. Stura, J. Loughney
Category            : PROPOSED STANDARD
Source              : Authentication, Authorization and Accounting
Area                : Operations and Management
Stream              : IETF
Verifying Party     : IESG
.
 
_________________________________________________________________________________________________________________________
 
Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.
 
This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.

 

_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.

--------------C45A88CADD7DAE7597CD933E-- From nobody Tue Jan 3 04:57:52 2017 Return-Path: X-Original-To: aaa-doctors@ietfa.amsl.com Delivered-To: aaa-doctors@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E04881294BC; Tue, 3 Jan 2017 04:57:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.196 X-Spam-Level: X-Spam-Status: No, score=-15.196 tagged_above=-999 required=5 tests=[BAD_CREDIT=2.415, BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-3.1, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rHlr0UUxgBmG; Tue, 3 Jan 2017 04:57:48 -0800 (PST) Received: from aer-iport-3.cisco.com (aer-iport-3.cisco.com [173.38.203.53]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D5C791295B2; Tue, 3 Jan 2017 04:57:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=20561; q=dns/txt; s=iport; t=1483448268; x=1484657868; h=subject:to:references:cc:from:message-id:date: mime-version:in-reply-to; bh=FDCOIF4F6hXLQ5mdSpSxGa68qa7dFZR3A96NYwmBHfg=; b=dRt6n7Ua9RhIFzi4Ikn59QikMoE+Tb4fIIcIqobkimcyzvEjJH5SzLPt 7cIbKWWjH/VJIk7jcWolhCx2ka2PA70CAoWm5/jaP2ThyVBTkkMsDqcy5 FCo4SZXR6EHzHf/19X+KaiF1d2kMuoDflUshXzNhe10nrFvD0Ki7hAC8z o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0D+AAB/nmtY/xbLJq1DGhkBAQEBAQEBA?= =?us-ascii?q?QEBAQcBAQEBAYJxRgEBAQEBfoEMjVdyk1OCNIVHixGCD4IIKoV4AoIfFAECAQE?= =?us-ascii?q?BAQEBAWIohGgBAQEELUwQCxEDAQIhBwdGCQgGAQwGAgEBiFEDGA4tsHArihMBA?= =?us-ascii?q?QEBAQEBAQEBAQEBAQEBAQEBAQEdhkWCAoJfgTuBEzuBDxEBBjYMCoUNHgWIZhG?= =?us-ascii?q?HUYoANYZUhnKDeIF1hQiDJ4Yxh36BdVWDZoQPHzhoHxYNFoN7DQ+BXz00AROFf?= =?us-ascii?q?IIuAQEB?= X-IronPort-AV: E=Sophos;i="5.33,451,1477958400"; d="scan'208,217";a="649483460" Received: from aer-iport-nat.cisco.com (HELO aer-core-3.cisco.com) ([173.38.203.22]) by aer-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 03 Jan 2017 12:57:43 +0000 Received: from [10.60.67.87] (ams-bclaise-8916.cisco.com [10.60.67.87]) by aer-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id v03CvgZM008469; Tue, 3 Jan 2017 12:57:43 GMT To: lionel.morand@orange.com, "aaa-doctors@ietf.org" , "sec-ads@ietf.org" References: <20161219091457.EF44BB80224@rfc-editor.org> <784_1483438946_586B7B62_784_1775_1_6B7134B31289DC4FAF731D844122B36E0BFC5C89@OPEXCLILM43.corporate.adroot.infra.ftgroup> From: Benoit Claise Message-ID: <602f5ce9-43d8-22d3-3d9a-427ebd8b80c9@cisco.com> Date: Tue, 3 Jan 2017 13:57:42 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.6.0 MIME-Version: 1.0 In-Reply-To: <784_1483438946_586B7B62_784_1775_1_6B7134B31289DC4FAF731D844122B36E0BFC5C89@OPEXCLILM43.corporate.adroot.infra.ftgroup> Content-Type: multipart/alternative; boundary="------------15EF9249747447D756C405AA" Archived-At: Cc: "Bertz, Lyle T \[CTO\]" , Dave Dolson Subject: Re: [AAA-DOCTORS] Fwd: [Technical Errata Reported] RFC4006 (4892) X-BeenThere: aaa-doctors@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: AAA Doctors E-mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Jan 2017 12:57:51 -0000 This is a multi-part message in MIME format. --------------15EF9249747447D756C405AA Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Thanks, "rejected". Regards, B. > > If I'm correct, this is not an erratum against 4006 but a proposed > change in the draft RFC4006bis > (https://tools.ietf.org/html/draft-ietf-dime-rfc4006bis-00). > > The original text quoted below is not in the RFC4006 but in the draft. > > Let me know if I'm correct. > > Regards, > > Lionel > > *De :*AAA-DOCTORS [mailto:aaa-doctors-bounces@ietf.org] *De la part > de* Benoit Claise > *Envoyé :* lundi 19 décembre 2016 11:31 > *À :* aaa-doctors@ietf.org; sec-ads@ietf.org > *Objet :* [AAA-DOCTORS] Fwd: [Technical Errata Reported] RFC4006 (4892) > > Dear all, > > What do you think? > > Regards, Benoit > > > > -------- Forwarded Message -------- > > *Subject: * > > > > [Technical Errata Reported] RFC4006 (4892) > > *Date: * > > > > Mon, 19 Dec 2016 01:14:57 -0800 > > *From: * > > > > RFC Errata System > > > *To: * > > > > Harri.Hakala@ericsson.com , > Leena.Mattila@ericsson.com , > juha-pekka.koskinen@nokia.com , > marco.stura@nokia.com , > John.Loughney@nokia.com , > bclaise@cisco.com , joelja@bogus.com > , Bernard_Aboba@hotmail.com > , david@mitton.com > , john.loughney@nokia.com > > > *CC: * > > > > dengzhenjie@huawei.com , > rfc-editor@rfc-editor.org > > The following errata report has been submitted for RFC4006, > "Diameter Credit-Control Application". > -------------------------------------- > You may review the report below and at: > http://www.rfc-editor.org/errata_search.php?rfc=4006&eid=4892 > -------------------------------------- > Type: Technical > Reported by: dengzhenjie > Section: 7 > Original Text > ------------- > | PendingU | CC update answer received | Terminate | Idle | > | | with result code equal to | end user's | | > | | CREDIT_CONTROL_NOT_APPLICABLE | service | | > Corrected Text > -------------- > | PendingU | CC update answer received | Grant | Idle | > | | with result code equal to | service to| | > | | CREDIT_CONTROL_NOT_APPLICABLE | end user | | > Notes > ----- > Note that in Section 9, It said: > when the result code in the CCA is DIAMETER_CREDIT_CONTROL_NOT_APPLICABLE 4011, it indicates that the credit-control server determines that the service can be granted to the end user but that no further credit-control is needed for the service (e.g., service is free of charge). > Instructions: > ------------- > This erratum 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 > can log in to change the status and edit the report, if necessary. > -------------------------------------- > RFC4006 (draft-ietf-aaa-diameter-cc-06) > -------------------------------------- > Title : Diameter Credit-Control Application > Publication Date : August 2005 > Author(s) : H. Hakala, L. Mattila, J-P. Koskinen, M. Stura, J. Loughney > Category : PROPOSED STANDARD > Source : Authentication, Authorization and Accounting > Area : Operations and Management > Stream : IETF > Verifying Party : IESG > . > _________________________________________________________________________________________________________________________ > > Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc > pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler > a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, > Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. > > This message and its attachments may contain confidential or privileged information that may be protected by law; > they should not be distributed, used or copied without authorisation. > If you have received this email in error, please notify the sender and delete this message and its attachments. > As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified. > Thank you. --------------15EF9249747447D756C405AA Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit
Thanks, "rejected".

Regards, B.

If I'm correct, this is not an erratum against 4006 but a proposed change in the draft RFC4006bis (https://tools.ietf.org/html/draft-ietf-dime-rfc4006bis-00).

The original text quoted below is not in the RFC4006 but in the draft.

 

Let me know if I'm correct.

 

Regards,

 

Lionel

 

De : AAA-DOCTORS [mailto:aaa-doctors-bounces@ietf.org] De la part de Benoit Claise
Envoyé : lundi 19 décembre 2016 11:31
À : aaa-doctors@ietf.org; sec-ads@ietf.org
Objet : [AAA-DOCTORS] Fwd: [Technical Errata Reported] RFC4006 (4892)

 

Dear all,

What do you think?

Regards, Benoit



-------- Forwarded Message --------

Subject:

[Technical Errata Reported] RFC4006 (4892)

Date:

Mon, 19 Dec 2016 01:14:57 -0800

From:

RFC Errata System <rfc-editor@rfc-editor.org>

To:

Harri.Hakala@ericsson.com, Leena.Mattila@ericsson.com, juha-pekka.koskinen@nokia.com, marco.stura@nokia.com, John.Loughney@nokia.com, bclaise@cisco.com, joelja@bogus.com, Bernard_Aboba@hotmail.com, david@mitton.com, john.loughney@nokia.com

CC:

dengzhenjie@huawei.com, rfc-editor@rfc-editor.org

 

The following errata report has been submitted for RFC4006,
"Diameter Credit-Control Application".
 
--------------------------------------
You may review the report below and at:
http://www.rfc-editor.org/errata_search.php?rfc=4006&eid=4892
 
--------------------------------------
Type: Technical
Reported by: dengzhenjie <dengzhenjie@huawei.com>
 
Section: 7
 
Original Text
-------------
   | PendingU | CC update answer received     | Terminate   | Idle     |
   |          | with result code equal to     | end user's  |          |
   |          | CREDIT_CONTROL_NOT_APPLICABLE | service     |          |
 
 
Corrected Text
--------------
   | PendingU | CC update answer received     | Grant     |   Idle   |
   |          | with result code equal to     | service to|          |
   |          | CREDIT_CONTROL_NOT_APPLICABLE | end user  |          |
 
 
Notes
-----
Note that in Section 9, It said:
  when the result code in the CCA is DIAMETER_CREDIT_CONTROL_NOT_APPLICABLE 4011, it indicates that the credit-control server determines that the service can be granted to the end user but that no further credit-control is needed for the service (e.g., service is free of charge).
 
Instructions:
-------------
This erratum 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  
can log in to change the status and edit the report, if necessary. 
 
--------------------------------------
RFC4006 (draft-ietf-aaa-diameter-cc-06)
--------------------------------------
Title               : Diameter Credit-Control Application
Publication Date    : August 2005
Author(s)           : H. Hakala, L. Mattila, J-P. Koskinen, M. Stura, J. Loughney
Category            : PROPOSED STANDARD
Source              : Authentication, Authorization and Accounting
Area                : Operations and Management
Stream              : IETF
Verifying Party     : IESG
.
 
_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.

--------------15EF9249747447D756C405AA-- From nobody Sat Jan 7 16:32:07 2017 Return-Path: X-Original-To: aaa-doctors@ietfa.amsl.com Delivered-To: aaa-doctors@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 89725129C69 for ; Sat, 7 Jan 2017 16:32:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.398 X-Spam-Level: X-Spam-Status: No, score=-2.398 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RP_MATCHES_RCVD=-3.199, SPF_FAIL=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ttnH1KgsRq_R for ; Sat, 7 Jan 2017 16:32:04 -0800 (PST) Received: from power.freeradius.org (power.freeradius.org [195.154.231.44]) by ietfa.amsl.com (Postfix) with ESMTP id EE329129C74 for ; Sat, 7 Jan 2017 16:32:02 -0800 (PST) Received: by power.freeradius.org (Postfix, from userid 1000) id E24AD2240CFB; Sun, 8 Jan 2017 01:32:01 +0100 (CET) From: aland@freeradius.org To: X-Mailer: mail (GNU Mailutils 2.99.99) Message-Id: <20170108003201.E24AD2240CFB@power.freeradius.org> Date: Sun, 8 Jan 2017 01:32:01 +0100 (CET) Archived-At: Subject: [AAA-DOCTORS] Automatic tech report for Sun Jan 8 01:32:01 CET 2017 X-BeenThere: aaa-doctors@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: AAA Doctors E-mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Jan 2017 00:32:05 -0000 This is an automatically generated email. It lists the IETF internet-drafts which are WG items and which reference RADIUS. Drafts from the RADEXT and DIME working groups are not included. -- draft-ietf-abfab-aaa-saml-14 In IESG processing - ID Tracker state draft-ietf-abfab-arch-13 In IESG processing - ID Tracker state draft-ietf-dnsop-isp-ip6rdns-01 Active draft-ietf-softwire-map-radius-05 Active From nobody Thu Jan 12 10:05:41 2017 Return-Path: X-Original-To: aaa-doctors@ietfa.amsl.com Delivered-To: aaa-doctors@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CD8D4128AB0; Thu, 12 Jan 2017 10:05:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.72 X-Spam-Level: X-Spam-Status: No, score=-17.72 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-3.199, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kqBdt7eT5nhS; Thu, 12 Jan 2017 10:05:34 -0800 (PST) Received: from aer-iport-4.cisco.com (aer-iport-4.cisco.com [173.38.203.54]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 804D6129421; Thu, 12 Jan 2017 10:05:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=34560; q=dns/txt; s=iport; t=1484244333; x=1485453933; h=subject:to:references:cc:from:message-id:date: mime-version:in-reply-to; bh=So2MHZZp8xX4aKQApkCWj/zF96eG5NPBC8W+CpyK8Sk=; b=NE+SoE1/cQo1T30Ko7LK94NgdfyDThl9hxqyuPFAFy0Wt0kzI+EtBz1P Z8bJH78jlOC8YGxuPyAEJV1spfoPPpYtRm2rh2DIXplbj9snImR+sRNQH gVsjYJZx7IQiKwBZmgMN1U+FLH+UQvWgFNVLzyAeTO7lQuD86CD2RU8AW U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AYAQB8xHdY/xbLJq1DGhkBAQEBAQEBA?= =?us-ascii?q?QEBAQcBAQEBAYJyOw8BAQEBAX4DgQaNWHKRIogCixmCD4INKoV4AoJFFAECAQE?= =?us-ascii?q?BAQEBAWMohGkBAQEEJwZMEAsRAwECIQEGByElCQgGAQwGAgEBiGEDGA4tsiU6K?= =?us-ascii?q?4cXDYJJAQEBAQEBAQEBAQEBAQEBAQEBAQEBHYZFggIIgVGBBoE7gRM7gQQLEQE?= =?us-ascii?q?8DAqFDx8FiHYRhheBRYRFhUw4jVWEAYF3hQ6DKoY7iBOBfVmDaIQTHzgQYSQSC?= =?us-ascii?q?BUVGIRWDQ+BYD01AROGJIIuAQEB?= X-IronPort-AV: E=Sophos;i="5.33,219,1477958400"; d="scan'208,217";a="651569988" Received: from aer-iport-nat.cisco.com (HELO aer-core-1.cisco.com) ([173.38.203.22]) by aer-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 12 Jan 2017 18:05:29 +0000 Received: from [10.60.67.85] (ams-bclaise-8914.cisco.com [10.60.67.85]) by aer-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id v0CI5ROO003507; Thu, 12 Jan 2017 18:05:27 GMT To: lionel.morand@orange.com, "aaa-doctors@ietf.org" , "sec-ads@ietf.org" References: <20160913214213.4DBFAB80B89@rfc-editor.org> <372e075c-1564-b36a-1eb3-e62c8717535f@cisco.com> <2069_1483442208_586B8820_2069_7324_1_6B7134B31289DC4FAF731D844122B36E0BFC5E94@OPEXCLILM43.corporate.adroot.infra.ftgroup> <17526_1483443934_586B8EDE_17526_11792_1_6B7134B31289DC4FAF731D844122B36E0BFC600A@OPEXCLILM43.corporate.adroot.infra.ftgroup> From: Benoit Claise Message-ID: <909d02b4-3f2e-4839-ac0e-7519e5efb8aa@cisco.com> Date: Thu, 12 Jan 2017 19:05:26 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.6.0 MIME-Version: 1.0 In-Reply-To: <17526_1483443934_586B8EDE_17526_11792_1_6B7134B31289DC4FAF731D844122B36E0BFC600A@OPEXCLILM43.corporate.adroot.infra.ftgroup> Content-Type: multipart/alternative; boundary="------------CC8BC7BF956EE68156085C4C" Archived-At: Cc: "dime@ietf.org" , "holger+ietf@freyther.de" Subject: Re: [AAA-DOCTORS] Fwd: [Editorial Errata Reported] RFC6733 (4803) X-BeenThere: aaa-doctors@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: AAA Doctors E-mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jan 2017 18:05:38 -0000 This is a multi-part message in MIME format. --------------CC8BC7BF956EE68156085C4C Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Dear all, I would appreciate if others would share their views. Regards, B. > > This errata report is correct on the inconsistency regarding the > definition of the command header and AVP header and how they are used > in the rest of the document in the ABNF description of commands and > Grouped AVPs. > > For commands, the header is defined as follow: > > header = " > [r-bit] [p-bit] [e-bit] [application-id]">" > > whereas " > Same for Grouped AVP. It is defined as follow: > > header = "<" "AVP-Header:" avpcode [vendor] ">" > > whereas " > Considering that most (if not all) the ABNF descriptions have been > copied from the commands and Grouped AVPs defined in the RFC3588 or > RFC6733, I would be in favor to correct the specification by modifying > the definition of the headers, i.e. > > --> In section 3.2. Command Code Format Specification > > OLD: > > header = " > [r-bit] [p-bit] [e-bit] [application-id]">" > > NEW: > > header = " > [r-bit] [p-bit] [e-bit] [application-id]">" > > --> And in section 4.4 > > OLD: > > header = "<" "AVP-Header:" avpcode [vendor] ">" > > NEW: > > header = "<" "AVP Header:" avpcode [vendor] ">" > > ******************* > > There are other issues pointed out in this report. > > For command-def = "<" command-name ">" "::=" diameter-message, I > would propose to simply correct the example as all the command > definitions given in the document are following the command-def > definition. > > For the grouped-avp-def, I don't know what would be the best approach. > We could follow the same approach and require the addition of "<>" but > I don't know what would be the impacts on existing Grouped AVPs > defined without. > > Regards, > > Lionel. > > > -------- Forwarded Message -------- > > *Subject: * > > > > [Editorial Errata Reported] RFC6733 (4803) > > *Date: * > > > > Tue, 13 Sep 2016 14:42:13 -0700 > > *From: * > > > > RFC Errata System > > > *To: * > > > > vf0213@gmail.com , jari.arkko@ericsson.com > , john.loughney@nokia.com > , glenzorn@gmail.com > , bclaise@cisco.com > , joelja@bogus.com > , jouni.nospam@gmail.com > , lionel.morand@orange.com > > > *CC: * > > > > holger+ietf@freyther.de , > dime@ietf.org , rfc-editor@rfc-editor.org > > > The following errata report has been submitted for RFC6733, > "Diameter Base Protocol". > -------------------------------------- > You may review the report below and at: > http://www.rfc-editor.org/errata_search.php?rfc=6733&eid=4803 > -------------------------------------- > Type: Editorial > Reported by: Holger Freyther > Section: 3.2 > Original Text > ------------- > Example-Request ::= < Diameter Header: 9999999, REQ, PXY > > { User-Name } > 1* { Origin-Host } > * [ AVP ] > Corrected Text > -------------- > ::= < Diameter-Header: 9999999, REQ, PXY > > { User-Name } > 1* { Origin-Host } > * [ AVP ] > Notes > ----- > I converted the BNF into a PetitParser parser in Smalltalk/Pharo and noticed that example and grammar do not match. The first issue is with the example following the grammar but most definitions do not follow the BNF so maybe it is best to update the BNF. > header = " [r-bit] [p-bit] [e-bit] [application-id]">" > But "Diameter-Header:" is not used throughout the text so maybe it is better to update the grammar to "Diameter Header:". > command-def = "<" command-name ">" "::=" diameter-message > but the example is not using <> for the command-name ("Example-Request"). For the grouped-avp-def application is sometimes used with "<" name ">" and sometimes just name. > Instructions: > ------------- > This erratum 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. > -------------------------------------- > RFC6733 (draft-ietf-dime-rfc3588bis-33) > -------------------------------------- > Title : Diameter Base Protocol > Publication Date : October 2012 > Author(s) : V. Fajardo, Ed., J. Arkko, J. Loughney, G. Zorn, Ed. > Category : PROPOSED STANDARD > Source : Diameter Maintenance and Extensions > Area : Operations and Management > Stream : IETF > Verifying Party : IESG > . > _________________________________________________________________________________________________________________________ > Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc > pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler > a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, > Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. > This message and its attachments may contain confidential or privileged information that may be protected by law; > they should not be distributed, used or copied without authorisation. > If you have received this email in error, please notify the sender and delete this message and its attachments. > As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified. > Thank you. > _________________________________________________________________________________________________________________________ > > Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc > pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler > a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, > Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. > > This message and its attachments may contain confidential or privileged information that may be protected by law; > they should not be distributed, used or copied without authorisation. > If you have received this email in error, please notify the sender and delete this message and its attachments. > As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified. > Thank you. --------------CC8BC7BF956EE68156085C4C Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit
Dear all,

I would appreciate if others would share their views.

Regards, B.

This errata report is correct on the inconsistency regarding the definition of the command header and AVP header and how they are used in the rest of the document in the ABNF description of commands and Grouped AVPs.

 

For commands, the header is defined as follow:

 

   header           = "<Diameter-Header:" command-id

                         [r-bit] [p-bit] [e-bit] [application-id]">"

 

whereas "<Diameter Header:" is used when defining commands.

 

Same for Grouped AVP. It is defined as follow:

 

         header           = "<" "AVP-Header:" avpcode [vendor] ">"

 

whereas "<AVP Header:" is used when defining Grouped AVPs.

 

Considering that most (if not all) the ABNF descriptions have been copied from the commands and Grouped AVPs defined in the RFC3588 or RFC6733, I would be in favor to correct the specification by modifying the definition of the headers, i.e.

 

--> In section 3.2.  Command Code Format Specification

 

OLD:

 

   header           = "<Diameter-Header:" command-id

                         [r-bit] [p-bit] [e-bit] [application-id]">"

 

NEW:

 

   header           = "<Diameter Header:" command-id

                         [r-bit] [p-bit] [e-bit] [application-id]">"

 

 

--> And in section 4.4

 

OLD:

 

         header           = "<" "AVP-Header:" avpcode [vendor] ">"

 

NEW:

 

         header           = "<" "AVP Header:" avpcode [vendor] ">"

 

*******************

There are other issues pointed out in this report.

 

For command-def  = "<" command-name ">" "::=" diameter-message, I would propose to simply correct the example as all the command definitions given in the document are following the command-def definition.

For the grouped-avp-def, I don't know what would be the best approach. We could follow the same approach and require the addition of "<>" but I don't know what would be the impacts on existing Grouped AVPs defined without.

 

Regards,

 

Lionel.

 


-------- Forwarded Message --------

Subject:

[Editorial Errata Reported] RFC6733 (4803)

Date:

Tue, 13 Sep 2016 14:42:13 -0700

From:

RFC Errata System <rfc-editor@rfc-editor.org>

To:

vf0213@gmail.com, jari.arkko@ericsson.com, john.loughney@nokia.com, glenzorn@gmail.com, bclaise@cisco.com, joelja@bogus.com, jouni.nospam@gmail.com, lionel.morand@orange.com

CC:

holger+ietf@freyther.de, dime@ietf.org, rfc-editor@rfc-editor.org

 

The following errata report has been submitted for RFC6733,
"Diameter Base Protocol".
 
--------------------------------------
You may review the report below and at:
http://www.rfc-editor.org/errata_search.php?rfc=6733&eid=4803
 
--------------------------------------
Type: Editorial
Reported by: Holger Freyther <holger+ietf@freyther.de>
 
Section: 3.2
 
Original Text
-------------
   Example-Request ::= < Diameter Header: 9999999, REQ, PXY >
                       { User-Name }
                    1* { Origin-Host }
                     * [ AVP ]
 
 
 
Corrected Text
--------------
   <Example-Request> ::= < Diameter-Header: 9999999, REQ, PXY >
                       { User-Name }
                    1* { Origin-Host }
                     * [ AVP ]
 
 
 
Notes
-----
I converted the BNF into a PetitParser parser in Smalltalk/Pharo and noticed that example and grammar do not match. The first issue is with the example following the grammar but most definitions do not follow the BNF so maybe it is best to update the BNF. 
 
  header           = "<Diameter-Header:" command-id
                         [r-bit] [p-bit] [e-bit] [application-id]">"
 
But "Diameter-Header:" is not used throughout the text so maybe it is better to update the grammar to "Diameter Header:".
 
 
 command-def      = "<" command-name ">" "::=" diameter-message
 
but the example is not using <> for the command-name ("Example-Request"). For the grouped-avp-def application is sometimes used with "<" name ">" and sometimes just name.
 
Instructions:
-------------
This erratum 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. 
 
--------------------------------------
RFC6733 (draft-ietf-dime-rfc3588bis-33)
--------------------------------------
Title               : Diameter Base Protocol
Publication Date    : October 2012
Author(s)           : V. Fajardo, Ed., J. Arkko, J. Loughney, G. Zorn, Ed.
Category            : PROPOSED STANDARD
Source              : Diameter Maintenance and Extensions
Area                : Operations and Management
Stream              : IETF
Verifying Party     : IESG
 
.
 
_________________________________________________________________________________________________________________________
 
Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.
 
This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.
_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.

--------------CC8BC7BF956EE68156085C4C-- From nobody Sat Jan 14 16:32:42 2017 Return-Path: X-Original-To: aaa-doctors@ietfa.amsl.com Delivered-To: aaa-doctors@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 82D08129EA4 for ; Sat, 14 Jan 2017 16:32:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.098 X-Spam-Level: X-Spam-Status: No, score=-5.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-3.199, SPF_FAIL=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lxl0S3rONtnc for ; Sat, 14 Jan 2017 16:32:34 -0800 (PST) Received: from power.freeradius.org (power.freeradius.org [195.154.231.44]) by ietfa.amsl.com (Postfix) with ESMTP id B850A129EA3 for ; Sat, 14 Jan 2017 16:32:34 -0800 (PST) Received: by power.freeradius.org (Postfix, from userid 1000) id 1898F2240FF3; Sun, 15 Jan 2017 01:32:02 +0100 (CET) From: aland@freeradius.org To: X-Mailer: mail (GNU Mailutils 2.99.99) Message-Id: <20170115003202.1898F2240FF3@power.freeradius.org> Date: Sun, 15 Jan 2017 01:32:02 +0100 (CET) Archived-At: Subject: [AAA-DOCTORS] Automatic tech report for Sun Jan 15 01:32:01 CET 2017 X-BeenThere: aaa-doctors@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: AAA Doctors E-mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Jan 2017 00:32:40 -0000 This is an automatically generated email. It lists the IETF internet-drafts which are WG items and which reference RADIUS. Drafts from the RADEXT and DIME working groups are not included. -- draft-ietf-abfab-aaa-saml-14 In IESG processing - ID Tracker state draft-ietf-abfab-arch-13 In IESG processing - ID Tracker state draft-ietf-dnsop-isp-ip6rdns-01 Active draft-ietf-softwire-map-radius-05 Active From nobody Sat Jan 21 16:32:06 2017 Return-Path: X-Original-To: aaa-doctors@ietfa.amsl.com Delivered-To: aaa-doctors@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 75C2F129546 for ; Sat, 21 Jan 2017 16:32:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.698 X-Spam-Level: X-Spam-Status: No, score=-3.698 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, RP_MATCHES_RCVD=-3.199, SPF_FAIL=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TqIshTRRcclK for ; Sat, 21 Jan 2017 16:32:03 -0800 (PST) Received: from power.freeradius.org (power.freeradius.org [195.154.231.44]) by ietfa.amsl.com (Postfix) with ESMTP id CCF1E129543 for ; Sat, 21 Jan 2017 16:32:02 -0800 (PST) Received: by power.freeradius.org (Postfix, from userid 1000) id 9516E2240FF3; Sun, 22 Jan 2017 01:32:01 +0100 (CET) From: aland@freeradius.org To: X-Mailer: mail (GNU Mailutils 2.99.99) Message-Id: <20170122003201.9516E2240FF3@power.freeradius.org> Date: Sun, 22 Jan 2017 01:32:01 +0100 (CET) Archived-At: Subject: [AAA-DOCTORS] Automatic tech report for Sun Jan 22 01:32:01 CET 2017 X-BeenThere: aaa-doctors@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: AAA Doctors E-mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Jan 2017 00:32:04 -0000 This is an automatically generated email. It lists the IETF internet-drafts which are WG items and which reference RADIUS. Drafts from the RADEXT and DIME working groups are not included. -- draft-ietf-abfab-aaa-saml-14 In IESG processing - ID Tracker state draft-ietf-abfab-arch-13 In IESG processing - ID Tracker state draft-ietf-dnsop-isp-ip6rdns-01 Active draft-ietf-softwire-map-radius-05 Active From nobody Sat Jan 28 16:32:36 2017 Return-Path: X-Original-To: aaa-doctors@ietfa.amsl.com Delivered-To: aaa-doctors@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BC645126CD8 for ; Sat, 28 Jan 2017 16:32:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.098 X-Spam-Level: X-Spam-Status: No, score=-5.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-3.199, SPF_FAIL=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y4Wzuq0Y9CvF for ; Sat, 28 Jan 2017 16:32:33 -0800 (PST) Received: from power.freeradius.org (power.freeradius.org [195.154.231.44]) by ietfa.amsl.com (Postfix) with ESMTP id 3B43512009C for ; Sat, 28 Jan 2017 16:32:32 -0800 (PST) Received: by power.freeradius.org (Postfix, from userid 1000) id B77832240F88; Sun, 29 Jan 2017 01:32:01 +0100 (CET) From: aland@freeradius.org To: X-Mailer: mail (GNU Mailutils 2.99.99) Message-Id: <20170129003201.B77832240F88@power.freeradius.org> Date: Sun, 29 Jan 2017 01:32:01 +0100 (CET) Archived-At: Subject: [AAA-DOCTORS] Automatic tech report for Sun Jan 29 01:32:01 CET 2017 X-BeenThere: aaa-doctors@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: AAA Doctors E-mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 29 Jan 2017 00:32:34 -0000 This is an automatically generated email. It lists the IETF internet-drafts which are WG items and which reference RADIUS. Drafts from the RADEXT and DIME working groups are not included. -- draft-ietf-abfab-aaa-saml-14 In IESG processing - ID Tracker state draft-ietf-abfab-arch-13 In IESG processing - ID Tracker state draft-ietf-dnsop-isp-ip6rdns-01 Active draft-ietf-softwire-map-radius-05 Active