Subject: [AAA-DOCTORS] Fwd: [Technical Errata Reported] RFC7683 (5277)

From: Benoit Claise <[email-masked]>
Date: Tue, 6 Mar 2018 12:21:50 +0100

Feedback on this one?

Regards, B.

-------- Forwarded Message --------
Subject: 	[Technical Errata Reported] RFC7683 (5277)
Date: 	Tue, 6 Mar 2018 02:47:50 -0800
From: 	RFC Errata System <[email-masked]>
To: 	[email-masked], [email-masked], [email-masked], 
[email-masked], [email-masked], [email-masked], 
[email-masked], [email-masked]
CC: 	[email-masked], [email-masked], [email-masked]

The following errata report has been submitted for RFC7683,
"Diameter Overload Indication Conveyance".

--------------------------------------
You may review the report below and at:
http://www.rfc-editor.org/errata/eid5277

--------------------------------------
Type: Technical
Reported by: Lionel Morand <[email-masked]>

Section: 7.2

Original Text
-------------
7.2.  OC-Feature-Vector AVP

    The OC-Feature-Vector AVP (AVP Code 622) is of type Unsigned64 and
    contains a 64-bit flags field of announced capabilities of a DOIC
    node.  The value of zero (0) is reserved.

    The OC-Feature-Vector sub-AVP is used to announce the DOIC features
    supported by the DOIC node, in the form of a flag-bits field in which
    each bit announces one feature or capability supported by the node.
    The absence of the OC-Feature-Vector AVP in request messages
    indicates that only the default traffic abatement algorithm described
    in this specification is supported.  The absence of the OC-Feature-
    Vector AVP in answer messages indicates that the default traffic
    abatement algorithm described in this specification is selected
    (while other traffic abatement algorithms may be supported), and no
    features other than abatement algorithms are supported.

    The following capability is defined in this document:

    OLR_DEFAULT_ALGO (0x0000000000000001)

       When this flag is set by the a DOIC reacting node, it means that
       the default traffic abatement (loss) algorithm is supported.  When
       this flag is set by a DOIC reporting node, it means that the loss
       algorithm will be used for requested overload abatement.

Corrected Text
--------------
7.2.  OC-Feature-Vector AVP

    The OC-Feature-Vector AVP (AVP Code 622) is of type Unsigned64 and
    contains a 64-bit flags field of announced capabilities of a DOIC
    node.  The value of zero (0) is reserved.

       Note: The value of zero (0) any DOIC node supports at least the
             Loss algorithm. Therefore, the OC-Feature-Vector AVP
             cannot be sent with no bit set.

    The OC-Feature-Vector sub-AVP is used to announce the DOIC features
    supported by the DOIC node, in the form of a flag-bits field in which
    each bit announces one feature or capability supported by the node.
    The absence of the OC-Feature-Vector AVP in request messages
    indicates that only the default traffic abatement algorithm described
    in this specification is supported.  The absence of the OC-Feature-
    Vector AVP in answer messages indicates that the default traffic
    abatement algorithm described in this specification is selected
    (while other traffic abatement algorithms may be supported), and no
    features other than abatement algorithms are supported.

    The following capability is defined in this document:

+---+------------------+----------------------------------------------+
|bit|  Feature Name    |  Description                                 |
+---+------------------+----------------------------------------------+
| 0 | OLR_DEFAULT_ALGO |When set by a DOIC reacting node, it means    |
|   |                  |that the default traffic abatement (loss)     |
|   |                  |algorithm is supported. When set by a DOIC    |
|   |                  |reporting node, it means that the loss        |
|   |                  |algorithm will be used for requested overload |
|   |                  |abatment.                                     |
+---+------------------+----------------------------------------------+

Notes
-----
The OC-Feature-Vector AVP is a 64-bit flag field and not a set of values (one per feature). Using the hexadecimal notation, it gives the feeling that there is a unique value for the OC-Feature-Vector AVP per supported capability, hich is incorrect. It is only required to define the use of each bit. This errata report has an impact on the associated IANA regisrty.

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.

--------------------------------------
RFC7683 (draft-ietf-dime-ovli-10)
--------------------------------------
Title               : Diameter Overload Indication Conveyance
Publication Date    : October 2015
Author(s)           : J. Korhonen, Ed., S. Donovan, Ed., B. Campbell, L. Morand
Category            : PROPOSED STANDARD
Source              : Diameter Maintenance and Extensions
Area                : Operations and Management
Stream              : IETF
Verifying Party     : IESG
.

---

From: "john.zhao" <[email-masked]>
Date: Tue, 13 Mar 2018 00:35:45 +0800

Hi Benoit,

        The last word of "abatment" should be "abatement". In side of the
'description' column, the "OLR_DEFAULT_ALGO"could be set but as 1 always
should be stated. As any other features could be set but 0 or 1 in the
future.

        Just FYI.

        Thanks,
BR//John Zhao

2018-03-06 19:21 GMT+08:00 Benoit Claise <[email-masked]>:

> <[email-masked]>
> You may review the report below and at:http://www.rfc-editor.org/errata/eid5277
>
> Reported by: Lionel Morand <[email-masked]> <[email-masked]>
>
> Section: 7.2
>
> Original Text
> -------------
> _______________________________________________
> AAA-DOCTORS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/aaa-doctors
>
>

---

From: Benoit Claise <[email-masked]>
Date: Wed, 14 Mar 2018 21:44:40 +0100

Dear all,

Any other views on the last two errata?

Regards, B.
> Hi Benoit,
>
>         The last word of "abatment" should be "abatement". In side of 
> the 'description' column, the "OLR_DEFAULT_ALGO"could be set but as 1 
> always should be stated. As any other features could be set but 0 or 1 
> in the future.
>
>         Just FYI.
>
>         Thanks,
> BR//John Zhao
>
> 2018-03-06 19:21 GMT+08:00 Benoit Claise <[email-masked] 
> <mailto:[email-masked]>>:
>
>     Feedback on this one?
>
>     Regards, B.
>
>
>     <mailto:[email-masked]>
>     To: 	[email-masked] <mailto:[email-masked]>,
>     [email-masked] <mailto:[email-masked]>,
>     [email-masked] <mailto:[email-masked]>, [email-masked]
>     <mailto:[email-masked]>, [email-masked]
>     <mailto:[email-masked]>, [email-masked]
>     <mailto:[email-masked]>, [email-masked]
>     <mailto:[email-masked]>, [email-masked]
>     <mailto:[email-masked]>
>     CC: 	[email-masked] <mailto:[email-masked]>,
>     [email-masked] <mailto:[email-masked]>, [email-masked]
>     <mailto:[email-masked]>
>
>
>
>     <http://www.rfc-editor.org/errata/eid5277>
>
>     Reported by: Lionel Morand<[email-masked]> <mailto:[email-masked]>
>
>     Section: 7.2
>
>     Original Text
>     -------------
>     [email-masked] <mailto:[email-masked]>
>     <https://www.ietf.org/mailman/listinfo/aaa-doctors>
>
>

---

From: <[email-masked]>
Date: Thu, 15 Mar 2018 09:24:40 +0000

This errata report has been discussed with authors (including Ben Campbell) and is triggered after the review of another diameter draft that want to define a new feature.
The conclusion was that the clarification was needed. The only issue was about IANA impacts and if the proposed erratum was enough to trigger an update of the IANA registry.

Regards,

Lionel

De : AAA-DOCTORS [mailto:[email-masked]] De la part de Benoit Claise
Envoyé : mercredi 14 mars 2018 21:45
À : john.zhao
Cc : [email-masked]
Objet : Re: [AAA-DOCTORS] Fwd: [Technical Errata Reported] RFC7683 (5277)

Dear all,

Regards, B.
Hi Benoit,
        The last word of "abatment" should be "abatement". In side of the 'description' column, the "OLR_DEFAULT_ALGO"could be set but as 1 always should be stated. As any other features could be set but 0 or 1 in the future.
        Just FYI.

        Thanks,
BR//John Zhao

2018-03-06 19:21 GMT+08:00 Benoit Claise <[email-masked]<mailto:[email-masked]>>:
Feedback on this one?

Regards, B.

-------- Forwarded Message --------
Subject:

[Technical Errata Reported] RFC7683 (5277)

Date:

Tue, 6 Mar 2018 02:47:50 -0800

From:

RFC Errata System <[email-masked]><mailto:[email-masked]>

To:

[email-masked]<mailto:[email-masked]>, [email-masked]<mailto:[email-masked]>, [email-masked]<mailto:[email-masked]>, [email-masked]<mailto:[email-masked]>, [email-masked]<mailto:[email-masked]>, [email-masked]<mailto:[email-masked]>, [email-masked]<mailto:[email-masked]>, [email-masked]<mailto:[email-masked]>

CC:

[email-masked]<mailto:[email-masked]>, [email-masked]<mailto:[email-masked]>, [email-masked]<mailto:[email-masked]>

Type: Technical

Reported by: Lionel Morand <[email-masked]><mailto:[email-masked]>

Section: 7.2

Original Text

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

Corrected Text

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

|   |                  |abatment.                                     |

Notes

-----

Instructions:

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

Stream              : IETF

Verifying Party     : IESG

.

_______________________________________________
AAA-DOCTORS mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/aaa-doctors

_________________________________________________________________________________________________________________________

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.

---

From: "john.zhao" <[email-masked]>
Date: Fri, 16 Mar 2018 01:53:45 +0800

Hi Lionel and Benoit,

My minor comments : Beyond the 'OLR_DEFAULT_ALGO‘, any coming feature could
be set per legacy version and update version.

+---+------------------+----------------------------------------------+
|bit|  Feature Name    |  Description                                 |
+---+------------------+----------------------------------------------+
| 0 | OLR_DEFAULT_ALGO |*This bit should be set as 1 always.*           |
|   |                  |When set by a DOIC reacting node, it means    |
|   |                  |that the default traffic abatement (loss)     |
|   |                  |algorithm is supported. When set by a DOIC    |
|   |                  |reporting node, it means that the loss        |
|   |                  |algorithm will be used for requested overload |
|   |                  |abat*e*ment.                                    |
+---+------------------+----------------------------------------------+

Note: changes has been marked by the "under score".

In addition, both erratas are necessary from my perspective.

        Thanks,

BR//John Zhao

2018-03-15 17:24 GMT+08:00 <[email-masked]>:

> This errata report has been discussed with authors (including Ben
> Campbell) and is triggered after the review of another diameter draft that
> want to define a new feature.
>
> The conclusion was that the clarification was needed. The only issue was
> about IANA impacts and if the proposed erratum was enough to trigger an
> update of the IANA registry.
>
>
>
> Regards,
>
>
>
> Lionel
>
>
>
> *De :* AAA-DOCTORS [mailto:[email-masked]] *De la part de*
> Benoit Claise
> *Envoyé :* mercredi 14 mars 2018 21:45
> *À :* john.zhao
> *Cc :* [email-masked]
> *Objet :* Re: [AAA-DOCTORS] Fwd: [Technical Errata Reported] RFC7683
> (5277)
>
>
>
> Dear all,
>
> *Subject: *
> *Date: *
> *From: *
> RFC Errata System <[email-masked]> <[email-masked]>
>
> *To: *
>
> [email-masked], [email-masked], [email-masked],
> *CC: *
> [email-masked], [email-masked], [email-masked]
>
>
>

---

From: Jouni <[email-masked]>
Date: Sun, 18 Mar 2018 19:22:41 +0200

Sorry for being a late comer to his discussion. (I am also one of the authors but did not participate to the discussion of the errata earlier - shame on me).

First I do not think the added note in the proposed errata text adds any value. The reserved _value_ 0 is reserved. One cannot use/send such in OC-Feature-Vector AVP. Also the wording in the note is somewhat confusing "The value of zero (0) any DOIC node supports at least the Loss algorithm.” Something is missing from that sentence.

The new added table is OK.. but not necessarily needed. What I think really would be useful is the change to Section 9.2. (new IANA registries) that was proposed during the initial discussion of the errata but not in the reported errata. That changed the “value” to “ assigned bit”, which in my opinion makes the use of the assignment very clear.

Regards,
	Jouni

> On 15 Mar 2018, at 11:24, [email-masked] wrote:
> 
> RFC Errata System <[email-masked]>
> To: 
> [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked]
> CC:

---

From: <[email-masked]>
Date: Mon, 19 Mar 2018 05:22:22 +0000

Hi Jouni,

Please see below.

> -----Message d'origine-----
> De : Jouni [mailto:[email-masked]]
> Envoyé : dimanche 18 mars 2018 18:23
> À : MORAND Lionel IMT/OLN; Benoit Claise
> Cc : john.zhao; [email-masked]
> Objet : Re: [AAA-DOCTORS] [Technical Errata Reported] RFC7683 (5277)
> 
> Sorry for being a late comer to his discussion. (I am also one of the authors
> but did not participate to the discussion of the errata earlier - shame on me).
> 
> First I do not think the added note in the proposed errata text adds any
> value. The reserved _value_ 0 is reserved. One cannot use/send such in OC-
> Feature-Vector AVP. Also the wording in the note is somewhat confusing
> "The value of zero (0) any DOIC node supports at least the Loss algorithm.”
> Something is missing from that sentence.
> 
[ML] The NOTE is there because the value (0) is not reserved for future use or anything else. This value cannot be sent at all and it is the clarification given in the NOTE (which is only for information).
And obviously, a word is missing in the NOTE. It should be:

       Note: The value of zero (0) BECAUSE any DOIC node supports at least the
                     Loss algorithm. Therefore, the OC-Feature-Vector AVP
                     cannot be sent with no bit set.

> The new added table is OK.. but not necessarily needed. What I think really
> would be useful is the change to Section 9.2. (new IANA registries) that was
> proposed during the initial discussion of the errata but not in the reported
> errata. That changed the “value” to “ assigned bit”, which in my opinion
> makes the use of the assignment very clear.

[ML] change to Section 9.2 is covered in errata report ID 5278, copied hereafter:

Section: 9.2

Original Text
-------------
9.2.  New Registries

   Two new registries have been created in the "AVP Specific Values"
   sub-registry under the "Authentication, Authorization, and Accounting
   (AAA) Parameters" registry.

   A new "OC-Feature-Vector AVP Values (code 622)" registry has been
   created.  This registry contains the following:

      Feature Vector Value Name

      Feature Vector Value

      Specification defining the new value

   See Section 7.2 for the initial Feature Vector Value in the registry.
   This specification defines the value.  New values can be added to the
   registry using the Specification Required policy [RFC5226].

   A new "OC-Report-Type AVP Values (code 626)" registry has been
   created.  This registry contains the following:

      Report Type Value Name

      Report Type Value

      Specification defining the new value

   See Section 7.6 for the initial assignment in the registry.  New
   types can be added using the Specification Required policy [RFC5226].

Corrected Text
--------------
9.2.  New Registries

   Two new registries have been created in the "AVP Specific Values"
   sub-registry under the "Authentication, Authorization, and Accounting
   (AAA) Parameters" registry.

   A new "OC-Feature-Vector AVP Values (code 622)" registry has been
   created.  This registry contains the following:

      Assigned Bit

      Feature Name

      Specification defining the new capability

   See Section 7.2 for the initial assigned bit in the registry.
   This specification defines the capbility announced by the setting of 
   this bit.  New values can be added to the registry using the 
   Specification Required policy [RFC5226].

   A new "OC-Report-Type AVP Values (code 626)" registry has been
   created.  This registry contains the following:

      Report Type Value Name

      Report Type Value

      Specification defining the new value

   See Section 7.6 for the initial assignment in the registry.  New
   types can be added using the Specification Required policy [RFC5226].

Notes
-----
This errata report is linked to the following errata report: Errata ID: 5277 The IANA registry created for the OC-Feature-Vector AVP Values (code 622) should only describe the use of the bit assigned to a given feature. There is no AVP value assigned to a given feature. The associated IANA registry should provide a table describing the setting of the bit assigned to a given feature/capability.

Regards,

Lionel
> > De : AAA-DOCTORS [mailto:[email-masked]] De la part de
> > Benoit Claise Envoyé : mercredi 14 mars 2018 21:45 À : john.zhao Cc :
> > [email-masked] Objet : Re: [AAA-DOCTORS] Fwd: [Technical Errata
> > Reported] RFC7683 (5277)
> >
> > Dear all,
> >
> should be stated. As any other features could be set but 0 or 1 in the future.
> >
> >         Just FYI.
> >
> >         Thanks,
> > BR//John Zhao
> >
> > The following errata report has been submitted for RFC7683, "Diameter
> > Overload Indication Conveyance".
> >
> > The OC-Feature-Vector AVP is a 64-bit flag field and not a set of values (one
> per feature). Using the hexadecimal notation, it gives the feeling that there is
> a unique value for the OC-Feature-Vector AVP per supported capability, hich
> is incorrect. It is only required to define the use of each bit. This errata report
> has an impact on the associated IANA regisrty.
> >
> > Instructions:
> > -------------
> > 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.
> >
> __________________________________________________________
> ____________
> > ___________________________________________________
> >
> > 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,
> > 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.