Re: [Dime] I-D Action: draft-ietf-dime-ovli-03.txt

["Wiehe, Ulrich (NSN - DE/Munich)" <[e-mail]>]

Hi Steve,
here are my comments.
They focus on new text you introduced. I agree that restructuring may require new text, however, I believe that with the new text a new concepts is introduced which macerates the agreed end-to-end concept and allows all DOIC agents on the path to do what they wants, so that we end up in a hop-by-hop concept.

1. clause 2.3, second paragraph:
Should read: "Reacting nodes indicate support for DOIC by including the OC-Supported-Features AVP into all request messages originated or relayed by the Reacting node."

2. clause 2.3, 3rd paragraph, 1st sentence:
OC-xxx AVPs must not be included in an answer message when the corresponding request did not contain an OC-S-F AVP.

3. clause 3.3, 7th paragraph:
Should read "The reporting node only includes an indication of support for one overload abatement algorithm.  This is the algorithm that the reporting node intends to use should it enter an overload condition or requests to use while it actually is in an overload condition. Reacting nodes can use the indicated overload abatement algorithm to prepare for possible overload reports and must use the indicated overload abatement algorithm if traffic reduction is actually requested."

4. clause 3.3, 10th paragraph:
The 1st sentence is misleading. In the general case, agents on the path between reacting node and reporting node are transparent. I agree that there are exceptions to the general case where an agent on the path is not transparent, but then the agent IS the reporting node (reporting to the sender of the request) and it also IS the reacting node (reacting on reports received from the upstream reporting node).  
The first 3 words of the second sentence "in this case" need clarification: "In the case where an agent takes the role of a reporting node (reporting to the downstream reacting node) and at the same time takes the role of a reacting node (reacting on reports received from an upstream reporting node)".
Last sentence: Its not an update but a replacement. The two DOIC associations are handled independently.

5. clause 3.3, last paragraph:
General rules shall be followed for each of the two associations separately. The content of the OC-S-F AVP sent by the agent upstream should reflect what the agent is able and willing to support (as always).

6. clause 3.4, 2nd paragraph:
Should read: "The OC-OLR AVP is referred to as an overload report.  The OC-OLR AVP includes the type of report, a sequence number, the length of time that the report is valid and abatement algorithm specific AVPs."

7. clause 3.4, 4th paragraph, 2nd sentence:
I cannot understand this sentence. Probably only simple typos but I don't know. 

8. clause 3.4, 4th paragraph last 2 sentences:
I don't understand and probably do not agree.

9. clause 3.5, 3rd paragraph, last word:
Should read "communicated"

10. clause 3.5, 4th paragraph, 1st sentence:
I don't understand. I can understand: "Reporting nodes use the OC-OLR AVP to communicate overload occurances towards reacting nodes."

11. clause 4.1, 3rd paragraph, last 4 words:
may be misleading. A DOIC supporting agent sitting between DOIC supporting client and DOIC supporting Server is transparent with regard to DOIC. This agent does not indicate DOIC support.

12. clause 4.1, 4th paragraph, 2nd sentence:
Should read:"If a request message handled by the DOIC agent does not include the OC-Supported-Features AVP then the DOIC agent inserts the AVP."

13. clause 4.1, last sentence:
Should read "If the message already has the AVP then the agent either leaves it unchanged in the relayed message or replaces it to reflect the features the agent is able and willing to support." Clarification is needed to say that strict rules must be followed by the agent to select the correct option. These rules take into account whether the request is host-routed or relam-routed and whether the agent is configured to select the server for realm-routed requests.

14. clause 4.1.2, 2nd paragraph:
Should read: "Based on the content of the OC-Supported-Features AVP in the request message, the reporting node knows what overload control functionality is supported by the reacting node.  The reporting node then acts accordingly for the subsequent answer messages it initiates for the transaction."
  
15. clause 4.1, 4th paragraph, 2nd sentence, 17th word:
Should read: "message's"

16. clause 4.1, 6th paragraph:
This should be left to the (future) specification that introduces other DOIC features.

17. clause 4.1, 7th paragraph, last 6 words:
should be based on requiements set by the (future) specification that introduces other DOIC features 

18. clause 4.1, 8th paragraph, last sentence:
Should read: "Lack of the OC-Supported-Features AVP in the request message indicates that there is no downstream reacting node for the transaction."

19. clause 4.1, last sentence:
Should read: "An agent MAY replace the OC-Supported-Features AVP carried in answer messages." This replacement must follow general rules. Its not so that the agent may do what ever it wants to. The decision must be based on whether or not the agent has replaced the OC-S-F in the corresponding request.

20. clause 5.2, 1st sentence:
Should read: "A reporting node using the loss algorithm must use the OC-Reduction-Percentage AVP (Section 6.7) to indicated the desired percentage of traffic reduction."

21. clause 5.2, last sentence:
Should read: "Editor's note: The above duplicates what is in the OC-Reduction-Percentage AVP section and can probably be removed."

22. clause 5.4, 6th paragraph:
Should read: "If the reacting node does not receive a an OLR in the answer that corresponds to the probe request messages sent to the formally overloaded node then the reacting node should slowly increase the rate of traffic sent to the overloaded node."


Best regards
Ulrich



-----Original Message-----
From: DiME [mailto:[e-mail]] On Behalf Of ext Steve Donovan
Sent: Saturday, July 05, 2014 9:42 PM
To: [e-mail]
Subject: Re: [Dime] I-D Action: draft-ietf-dime-ovli-03.txt

All,

This version of the DOIC draft is a restructuring of previously agreed 
to content.

The master plan for the restructuring is in Appendix C.  This outlines 
where material from -02 was moved in -03.

For those interested, the work was done in steps, with a snapshot for 
each step available here:

https://github.com/jounikor/draft-docdt-dime-ovli

Each step has the name draft-ietf-dime-ovli-03-nn-text.txt

where nn indicates the subversion and "text" indicates the focus for 
that subversion.

The next step will be to resolve open issues already identified and 
those yet those yet to be identified.

Regards,

Steve


On 7/3/14, 2:31 PM, [e-mail] wrote:
> A New Internet-Draft is available from the on-line Internet-Drafts directories.
>   This draft is a work item of the Diameter Maintenance and Extensions Working Group of the IETF.
>
>          Title           : Diameter Overload Indication Conveyance
>          Authors         : Jouni Korhonen
>                            Steve Donovan
>                            Ben Campbell
>                            Lionel Morand
> 	Filename        : draft-ietf-dime-ovli-03.txt
> 	Pages           : 48
> 	Date            : 2014-07-03
>
> Abstract:
>     This specification documents a Diameter Overload Control (DOC) base
>     solution and the dissemination of the overload report information.
>
> Requirements
>
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-dime-ovli/
>
> There's also a htmlized version available at:
> http://tools.ietf.org/html/draft-ietf-dime-ovli-03
>
> A diff from the previous version is available at:
> http://www.ietf.org/rfcdiff?url2=draft-ietf-dime-ovli-03
>
>
> Please note that it may take a couple of minutes from the time of submission
> until the htmlized version and diff are available at tools.ietf.org.
>
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
>
> _______________________________________________
> DiME mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dime
>

_______________________________________________
DiME mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/dime