Subject: [Dime] DOIC WGLC: Editorial Comments

From: Ben Campbell <[email-masked]>
Date: Tue, 16 Dec 2014 21:02:45 -0600

Here's some nits, editorial, and structural comments that are generally non-substantive. With the possible exception of comments about 2119 language, most of these could be ignored without consequence, but I think we'd have a better document if we at least thought about them:

-- General: 

We keep referring to the DOIC "solution". I think "mechanism" is more appropriate. I would think of a DOIC "solution" as a deployment that leverages the DOIC "mechanism".

We overuse the word Diameter in front of other things. E.g. Diameter nodes, Diameter Agents, Diameter clients, Diameter servers, etc. This entire draft is about Diameter; we don't have to keep saying it. It tends to get awkward when we use it a lot in close proximity.

Should we put consistently quotes around "loss" when we describe the "loss" algorithm?

-- Requirements (2119 language section)

This is oddly placed. I'm used to seeing that after the introduction, either stand-alone or as part of a larger terminology section. The RFC editor recommends putting it as section 2. 

-- section 2, Abatement Algorithm: "A mechanism..."

I suggest "An extensible mechanism..."

-- Section 2, Diversion:

Still needs work.  the "by selecting" phrase needs to indicate what does the selecting. "Path" should probably be "path or destination".

Proposed text:

"An overload abatement mechanism, where the reacting node selects alternate destinations or paths for for requests."

-- section 2, OCS: "Reporting and reacting node internally maintained state..."

I suggest "Internal state maintained by a reporting or reacting node..."

-- section 2, Realm-Routed Requests: "... does not know the host that will service..."

I suggest: "... does not know which host will service ..."

We should also add a comment that it may be possible to apply diversion to realm routed requests.

-- section 2, Throttling: " ... a Diameter Client not sending requests..."

I suggest " ... a Client choosing to not send requests ..."

-- section 3, 2nd paragraph:

Client, servers, and agents should not be capitalized. Should "Reporting node" and "Reacting node" be hyphenated?  Consider moving the last sentence to the start of the next paragraph.

-- section 3.1, paragraph 1: " This is made possible by adding overload control AVPs, the OC-OLR AVP and the OC- Supported-Features AVP, as optional AVPs into existing commands..."

I suggest "This is made possible by adding the optional overload control AVPs OC-OLR and OC-Supported-Features into existing commands."

-- section 3.1, 3rd paragraph: "Reporting nodes also include overload reports..."

"Reporting nodes _may_ also include overload reports..."

-- section 3.1, 4th paragraph: "Clients MAY report..."

Should not be normative in this section.

-- section 3.2, 6th paragraph: "The OC-Feature-Vector AVP will contain..."

"... will _always_ contain..."

-- section 3.2, 7th paragraph: " ... all answer messages to requests ..."

suggest "... all answers to requests..."

-- section 3.2, paragraph 9: "Reporting nodes are allowed to..."

"Reporting nodes can..."

Also consider clarifying that they can change algorithms _between_transactions_, as long as there's no active overload condition.

-- section 3.2, paragraph 10 (starting with "The individual features..."

Consider moving this entire paragraph to earlier in the section.

-- section 3.2, paragraph 11: "The DCA mechanism must also allow..."

--> "The DCA mechanism allows..."

"... the agent updates the OC-Supported-Features..." --> " ... the agent can update the OC-Supported-Features..."

-- section 3.3, general:

Much of this section is redundant to stuff in the parent section. I suggest reducing the parent section detail, and keeping it here. (This may be true for subsequent children of section 3.)

-- 3.3, third paragraph:

s/ , / : /

-- 3.3, paragraph 4:

In this overview, I suggest text saying that HOST_REPORT indicates a host report, and just using the term "host report" the rest of the time. (Same for realm report)

-- 3.3, para 7: "A host-report, for instance, will generally by generated by tracking utilization of resources..."

I suggest "A host-report might be generated by tracking use of resources..."

-- 3.3, para 9: " ... are responsible for applying the overload abatement algorithm..."

I suggest " ... apply the abatement algorithm..."

-- 3.4, para 2: " ... the definition of new report types and the definition of new scopes ..."

Aren't these sort of the same thing? That is, you add new scopes by extending report type?

-- 3.4, para 3:

First two sentences are a bit confusing. A new reader will likely think they contradict, without some explanation that OC-Feature-Vector is a child of OC-S-F.

-- 3.4, para 4:

First sentence has already been stated more than once. No need to repeat here.

-- 4.1.1, Para 1: "It MAY include the OC-Feature-Vector AVP."

consider adding  ", as a sub-avp of OC-Supported-Features."

- 4.1.1, last paragraph: "This behavior is described in ..."

What is the antecedent to "this"? If it's "loss algorithm" behavior, then the reference to section 4.2 should not be needed.

-- 4.1.2, para 2:

It's probably worth reiterating that the reacting node may not be the server, and this requirement may mean inserting AVPS into answers that came from upstream.

-- 4.1.2, para 3: "...response messages ... "

"... _answer_ messages ... "

-- 4.1.2, para 7: "If it selects a different algorithm, it MUST...:

This is also true if it needs to announce some other feature that needs to be indicated.

-- 4.1.3, para 3: "... Agent MUST include OC-Supported-Features in request messages it receives..."

I suspect this should say "... requests that it _forwards_" or "_relays_".

-- 4.1.3, para 5 and 6:

Is the reporting node section limited to endpoints? If not, the these paragraphs effectively restate normative language about reporting node behavior from that section. Once we've said what a reporting node normatively has to do, we should just be able to say that an agent acting as a reporting node has all the responsibilities of a reporting node, and not restate the normative requirements.

-- 4.1.3, para 7:

The first MAY is a consequence (the complement) of the 2nd MAY. It should at least not be 2119 language, and probably can be omitted entirely.

-- 4.1.3, para 9, last sentence:

Does this mean an agent can only change OC-S-F in an answer if it changed it in the request? I don't think we want that restriction, but the context and "as such," seem to scope the MAY to that situation.

-- 4.1.3, para 9: "ambiguity"

I'm not sure that's is the word we want here. An agent could muck things up without being ambiguous. Perhaps "inconsistency"?

-- 4.2.1.1, para 1:

Do I understand correctly that the reacting node only keeps OCS for those combinations that it has actually received an OLR for? If so, that's not clear from the wording.

-- 4.2.1.2, para 1:

Likewise, the reporting node only keeps OCS for actual overload conditions where it sends OLRs?

-- 4.2.1.3, para 2:

Should this combination include origin-host or origin-realm? App-Id?

-- 4.2.1.3,  para 3: ... a reporting node MUST process..."

Should that be "reacting node"?

-- 4.2.1.3, para 4: 

Paragraph does not make sense. (I think we've already discussed this one from Ulrich's comments).

-- 4.2.1.3, 3rd para from end: "... update the OCS entry as being expired."

I suggest language like " invalid" or "terminated". I take "expired" to mean "naturally expired", which is different from the case described here. There may be subtle behavior difference. (For example, a reacting node might choose to log "expirations" differently than "explicit terminations".)

-- 4.2.1.4, para 9: "... including the reduction percentage..."

I suggest "... including, for example, the reduction percentage..."

-- 4.2.1.4, para 11: " ... MUST update the sequence number ..."

I suggest s / update / increment

-- 4.2.2, 2nd to last para:

 I think we need something a bit stronger here. The endpoint needs to take some action that makes sense for the application. The details of that are beyond our scope, but the general need is not.

-- 4.2.3, para 2:

Doesn't this also need to match the scope for the request type? E.g. Destination realm or destination host? For example, a host report for host A would not match OCS for host B, even though both had the same report type and application id.

-- 4.2.3, paras 8 and 9:

We put the currently less favored approach first, with the favored approach in the following paragraph. I suggest we put the more favored approach first.

-- 4.2.3, last para:

An example of what we have in mind could be helpful here.

-- 4.3, para 4:

We should clarify that this is talking about mandatory to understand for DOIC, but not for the enclosing transaction. 

-- 4.3, para 5:

Why is it different depending on whether the feature is an algorithm or not? Also, isn't this mostly redundant to the paragraph about new normative behavior?

-- 4.3, para 6, last sentence

This is redundant to earlier normative language in the section (assuming a new report type will always involve new normative behavior.)

-- 4.3, para 7, last sentence

Also redundant

-- 4.3, last para, last sentence:

It's not clear if this means section 8 of this doc, or 6733. I suggest putting this sentence before the subsequent one.

-- 5.1, para 4:

Convoluted paragraph. How about "How about "reporting nodes request the stateless reduction of the number of requests by an indicated percentage." 

We should also clarify that this reduction is in comparison to what the reacting node otherwise would have sent, rather than what it may have previously sent.

-- 5.3, para 5:

Needs a sentence or paragraph to describe the 100% issue before describing how to back down from it.

"... following concerns are RECOMMENDED ..."

following procedures...?

-- 5.3, para 6: "... does not receive an OLR in messages sent to the formerly overloaded node..."

Do we mean "... does not receive an OLR in answers received from the formerly overloaded node..."?

-- para 6, last paragraph

Paragraph is off topic for section. It probably belongs in the extensibility section, or at least somewhere other than here.

-- 6.1, last para:

I think we moved this to 6.2, but forgot to delete it here.

-- 6.2:

Why did the AVP code jump to TBD6? (Also seems out of order in the table.)

Is it to late to rename the value to OLR_LOSS_ALGO?

-- 9.4, para 2: "A node MUST not..."

"A node MUST _NOT_ ..."

-- References:

5905 and 5729 are not cited in the document.

draft-ietf-dime-e2e-sec-req-00: Outdated version.

---

From: Steve Donovan <[email-masked]>
Date: Wed, 17 Dec 2014 10:26:47 -0600

> We keep referring to the DOIC "solution". I think "mechanism" is more appropriate. I would think of a DOIC "solution" as a deployment that leverages the DOIC "mechanism".
SRD> I don't see an issue here, as long as we are consistent.
> We overuse the word Diameter in front of other things. E.g. Diameter nodes, Diameter Agents, Diameter clients, Diameter servers, etc. This entire draft is about Diameter; we don't have to keep sayi…
SRD> This was done based on feedback from Benoit.  We are being 
explicit.  If there are paragraphs where it is particularly cumbersome, 
please point out those paragraphs and we can try to make them less 
cumbersome.
> This is oddly placed. I'm used to seeing that after the introduction, either stand-alone or as part of a larger terminology section. The RFC editor recommends putting it as section 2.
SRD> Ok.
> I suggest "An extensible mechanism..."
SRD> Ok.
> "An overload abatement mechanism, where the reacting node selects alternate destinations or paths for for requests."
SRD> I'm ok with this wording.
> I suggest "Internal state maintained by a reporting or reacting node..."
SRD> Ok.
> I suggest: "... does not know which host will service ..."
SRD> Ok.
> We should also add a comment that it may be possible to apply diversion to realm routed requests.
SRD> Where?
> I suggest " ... a Client choosing to not send requests ..."
SRD> A Diameter Client...
> Client, servers, and agents should not be capitalized. Should "Reporting node" and "Reacting node" be hyphenated?  Consider moving the last sentence to the start of the next paragraph.
SRD> The capitalization of Diameter Clients, Diameter Servers and 
Diameter agents was Benoit's suggestion to make it explicit what is 
being referred to.  I don't see the need for hyphenation in this 
context.  I'm ok with moving the sentence.
> I suggest "This is made possible by adding the optional overload control AVPs OC-OLR and OC-Supported-Features into existing commands."
SRD> OK.
> "Reporting nodes _may_ also include overload reports..."
SRD> OK.
> Should not be normative in this section.
SRD> Agreed.
> "... will _always_ contain..."
SRD> Ok.
> suggest "... all answers to requests..."
SRD> Ok.
> -- section 3.2, paragraph 9: "Reporting nodes are allowed to..."
SRD> Ok.
> -- section 3.2, paragraph 11: "The DCA mechanism must also allow..."
SRD> This paragraph looks redundant.  I suggest removing it.
> "... the agent updates the OC-Supported-Features..." --> " ... the agent can update the OC-Supported-Features..."
SRD> Ok.
> Much of this section is redundant to stuff in the parent section. I suggest reducing the parent section detail, and keeping it here. (This may be true for subsequent children of section 3.)
SRD> Do you have specific suggestions?
> s/ , / : /
SRD> I don't agree.  The commas are there because it is a list.
> In this overview, I suggest text saying that HOST_REPORT indicates a host report, and just using the term "host report" the rest of the time. (Same for realm report)
SRD> Why?
> I suggest "A host-report might be generated by tracking use of resources..."
SRD> OK.
> I suggest " ... apply the abatement algorithm..."
SRD> Ok.
> Aren't these sort of the same thing? That is, you add new scopes by extending report type?
SRD> Can't you have a how report that applies only to sessions on that host?
> First two sentences are a bit confusing. A new reader will likely think they contradict, without some explanation that OC-Feature-Vector is a child of OC-S-F.
SRD> They seam clear to me.  Do you have a suggested clarification?
> First sentence has already been stated more than once. No need to repeat here.
SRD> The first sentence is there to provide context for the second 
sentence.
> consider adding  ", as a sub-avp of OC-Supported-Features."
SRD> OK
> What is the antecedent to "this"? If it's "loss algorithm" behavior, then the reference to section 4.2 should not be needed.
SRD> Agreed.
> It's probably worth reiterating that the reacting node may not be the server, and this requirement may mean inserting AVPS into answers that came from upstream.
SRD> I don't see the need.  Do you have suggested wording?
> "... _answer_ messages ..."
SRD> OK.
> This is also true if it needs to announce some other feature that needs to be indicated.
SRD> This paragraph is talking specifically about algorithms and is 
needed because the AVP is optional.  Are you suggesting another 
sentence, another paragraph?  I'm guessing that the case you talk about 
is already covered elsewhere.
> I suspect this should say "... requests that it _forwards_" or "_relays_".
SRD> To differentiate between the requests that it rejects.  Ok, I think 
relays is the better word.
> Is the reporting node section limited to endpoints? If not, the these paragraphs effectively restate normative language about reporting node behavior from that section. Once we've said what a repor…
SRD> I'm ok with this but it feels like more than an editorial change to me.
> The first MAY is a consequence (the complement) of the 2nd MAY. It should at least not be 2119 language, and probably can be omitted entirely.
SRD> Do you have suggested wording?
> Does this mean an agent can only change OC-S-F in an answer if it changed it in the request? I don't think we want that restriction, but the context and "as such," seem to scope the MAY to that sit…
SRD> I don't read it that way.  The first sentence is describing one 
reason why an agent might change OC-S-F.  It doesn't say it is the only 
reason.
> I'm not sure that's is the word we want here. An agent could muck things up without being ambiguous. Perhaps "inconsistency"?
SRD> The point is that the reacting nodes and reporting nodes must 
unambiguously know what to do.  I think ambiguous is the right word.
> Do I understand correctly that the reacting node only keeps OCS for those combinations that it has actually received an OLR for? If so, that's not clear from the wording.
SRD> Do you have suggested wording?
> Likewise, the reporting node only keeps OCS for actual overload conditions where it sends OLRs?
SRD> Do you have suggested wording?
> Should this combination include origin-host or origin-realm? App-Id?
SRD> I don't understand this.
> Should that be "reacting node"?
SRD> Yes.
> Paragraph does not make sense. (I think we've already discussed this one from Ulrich's comments).
SRD> Yes, this is addressed already.
> I suggest language like " invalid" or "terminated". I take "expired" to mean "naturally expired", which is different from the case described here. There may be subtle behavior difference. (For exam…
SRD> For the context of this specification I think expired works.  
Implementations can differentiate types of expired if they have a 
reason.  Nothing here prevents that.
> I suggest "... including, for example, the reduction percentage..."
SRD> OK.
> I suggest s / update / increment
SRD> OK.
>   I think we need something a bit stronger here. The endpoint needs to take some action that makes sense for the application. The details of that are beyond our scope, but the general need is not.
SRD> We cannot enforce application behavior in a Diameter 
specification.   I don't see the need for anything more .  Do you have 
suggested wording?
> Doesn't this also need to match the scope for the request type? E.g. Destination realm or destination host? For example, a host report for host A would not match OCS for host B, even though both ha…
SRD> I guess this matters when an agent is the reporting node.
> We put the currently less favored approach first, with the favored approach in the following paragraph. I suggest we put the more favored approach first.
SRD> OK.
> An example of what we have in mind could be helpful here.
SRD> I'm open to suggested wording...
> We should clarify that this is talking about mandatory to understand for DOIC, but not for the enclosing transaction.
SRD> i'm not clear on what you are suggesting.  Do you have suggested 
wording?
> Why is it different depending on whether the feature is an algorithm or not? Also, isn't this mostly redundant to the paragraph about new normative behavior?
SRD> I agree, this paragraph can be removed.
> This is redundant to earlier normative language in the section (assuming a new report type will always involve new normative behavior.)
SRD> I agree, the last sentence can be removed.
> -- 4.3, para 7, last sentence
SRD> Agreed.
> It's not clear if this means section 8 of this doc, or 6733. I suggest putting this sentence before the subsequent one.
SRD> OK.
> Convoluted paragraph. How about "How about "reporting nodes request the stateless reduction of the number of requests by an indicated percentage."
SRD> Ok.
> We should also clarify that this reduction is in comparison to what the reacting node otherwise would have sent, rather than what it may have previously sent.
SRD> Isn't this already covered?  Do you have suggested wording?
> Needs a sentence or paragraph to describe the 100% issue before describing how to back down from it.
SRD> It's discussed earlier in the document.  I'm ok with adding it 
again.  Do you have suggested wording?
> "... following concerns are RECOMMENDED ..."
SRD> OK.
> Do we mean "... does not receive an OLR in answers received from the formerly overloaded node..."?
SRD> Agreed.
> Paragraph is off topic for section. It probably belongs in the extensibility section, or at least somewhere other than here.
SRD> Do you mean section 6? This isn't about extensibility but about how 
Diameter applications integrate DOIC.  It probably belongs in the intro 
or overview sections.
> I think we moved this to 6.2, but forgot to delete it here.
SRD> Yup, already addressed as part of Ulrich's comments.
> Why did the AVP code jump to TBD6? (Also seems out of order in the table.)
SRD> Historical reasons.  Doesn't matter, the real values will be filled 
in eventually.
> Is it to late to rename the value to OLR_LOSS_ALGO?
SRD> Yes. :-)
> -- 9.4, para 2: "A node MUST not..."
SRD> Ok.
> 5905 and 5729 are not cited in the document.
SRD> Ok.
> draft-ietf-dime-e2e-sec-req-00: Outdated version.
SRD> Ok.
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> _______________________________________________
> DiME mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dime
>

---

From: Ben Campbell <[email-masked]>
Date: Fri, 19 Dec 2014 15:45:20 -0600

> On Dec 17, 2014, at 10:26 AM, Steve Donovan <[email-masked]> wrote:
> 
> 

[...]

> SRD> I don't see an issue here, as long as we are consistent.

I think we are pretty consistent in saying "solution". I guess that seems a bit pretentious to me, but I can live with it.

> SRD> This was done based on feedback from Benoit.  We are being explicit.  If there are paragraphs where it is particularly cumbersome, please point out those paragraphs and we can try to make them less cumbersome.

I'd argue that explicit and redundant are not the same things. (The document is pretty explicit that we are talking Diameter.)  But if Benoit wants it, I won't complain further, other than to note that RFC 6733 uses the terms client, agent, and server regularly without prefixing them with Diameter.  :-)

[...]

>> We should also add a comment that it may be possible to apply diversion to realm routed requests.

In the realm-routed request definition. (This was a continuation of the previous comment.)

> SRD> The capitalization of Diameter Clients, Diameter Servers and Diameter agents was Benoit's suggestion to make it explicit what is being referred to.

RFC 6733 does not generally capitalize client, agent, or server. I agree that Diameter is  a proper name, but the other terms are not. 

>  I don't see the need for hyphenation in this context.

I don't have strong feelings on that one.

>  I'm ok with moving the sentence.
>> 

> SRD> This paragraph looks redundant.  I suggest removing it.

Isn't this the first mention of the feature vector indicating things other than algorithms? If so, I'm not sure I agree that it's redundant.

> SRD> Do you have specific suggestions?

Remove the 2nd to last and 3rd to last paragraph in 3.0.

> SRD> I don't agree.  The commas are there because it is a list.

A colon is the appropriate punctuation to set a list or enumeration off from the preceding text. This would be more obvious if the list included more than 2 items, so that it would have imbedded commas.  (e.g. "I have three things: The first thing, the second thing, and the third thing.")

>> In this overview, I suggest text saying that HOST_REPORT indicates a host report, and just using the term "host report" the rest of the time. (Same for realm report)

We currently aren't consistent. Sometimes we say "host report", and sometimes we say "report of type 'HOST_REPORT'". I suggest we make that consistent, and "host report" is the less cumbersome.

[...]

> SRD> Can't you have a how report that applies only to sessions on that host?

By adding some new AVP that indicates sessions? I guess so.

> SRD> They seam clear to me.  Do you have a suggested clarification?

"A DOIC node communicates supported features by including them in the OC-Feature-Vector AVP, as a sub-AVP of OC-Supported-Features.

> SRD> The first sentence is there to provide context for the second sentence.

That can be done less redundantly. For example:

"Overload reports can be also extended by adding new sub-AVPs to the OC-OLR AVP, allowing ..."

> SRD> I don't see the need.  Do you have suggested wording?

Nevermind. I think 4.1.3 handles this.
> SRD> This paragraph is talking specifically about algorithms and is needed because the AVP is optional.  Are you suggesting another sentence, another paragraph?  I'm guessing that the case you talk about is already covered elsewhere.

We say this in 4.1.1 on reacting node behavior. We should make the same statement for reporting node behavior. This is the definitive section on reporting node behavior. If it's repeated elsewhere, we should consider whether _that_ text is redundant.

> SRD> To differentiate between the requests that it rejects.

Or requests that it normally wouldn't relay. (e.g. watchdogs, capabilities exchange, etc.)

>  Ok, I think relays is the better word.

Ok.

> SRD> I'm ok with this but it feels like more than an editorial change to me.

I don't think it would change the meaning, just the structure. (I _did_ mention "structural" in the preface to my comments :-)  )

> SRD> Do you have suggested wording?

"If a request already has the OC-Supported-Features AVP, a Diameter agent MAY modify it to reflect the features appropriate for the transaction."

Any MAY has an an implied "MIGHT NOT". But if we think it's not clear, we can tack on "Otherwise, the agent relays the OC-Supported-Features AVP without change."

> SRD> I don't read it that way.  The first sentence is describing one reason why an agent might change OC-S-F.  It doesn't say it is the only reason.

I read "as such" to make the second sentence dependent on the first. If we want to make them equal, I suggest removing the "as such".

> SRD> The point is that the reacting nodes and reporting nodes must unambiguously know what to do.  I think ambiguous is the right word.

I can construct behavior that is not ambiguous to upstream or downstream nodes, but still breaks normative requirements. How about " ... ensure that it does not introduce incorrect behavior for either the upstream or downstream DOIC nodes."

> SRD> Do you have suggested wording?

It depends. Does a reacting node keep OCS when it hasn't received an OLR?

If no:

"A reacting node SHOULD maintain the following OCS for each active OLR it receives per Diameter application..."

if yes:

Then I think the section needs some more thought to distinguish between what is stored for OLRs, vs when no OLR is received.

Also, I think the preface to the second bullet list seems wrong. I don't see how you could make an implementation work right without at least keeping sequence number and expiration time, at least when you have an active OLR.

> SRD> Do you have suggested wording?

This seems dependent on the same question as for the last comment. But assuming it only has to keep state of actual OLRs:

"A reporting node SHOULD maintain OCS entries for each OLR it sends, per ..."

> SRD> I don't understand this.

Ah, I misread the paragraph. But I think we are really talking about the algorithm, OC-OLR AVP, and other AVPs in the answer that are needed to understand the OLR. (e.g. Origin-Host, Origin-Realm, Application)

[...]

> SRD> For the context of this specification I think expired works.  Implementations can differentiate types of expired if they have a reason.  Nothing here prevents that.

Ok.

[...]

> SRD> We cannot enforce application behavior in a Diameter specification.   I don't see the need for anything more .  Do you have suggested wording?

Diameter endpoints that throttle requests [ MUST /need to ] do so according to the rules of the client application. Those rules will vary by application, and are beyond the scope of this document.

> SRD> I guess this matters when an agent is the reporting node.

I think it matters the same if the reporting node is an endpoint. For example, would you consider a host-routed-request with D-H: "foo" to match an host report for host "bar"?  (I'm on the fence here whether that is correct behavior, but I think the behavior should be the same for endpoints and agents.)

Actually, on reflection, how does this affect the scenario of an agent that passes through a host report and generates a realm report? Or a server that generates both?

> SRD> I'm open to suggested wording...

Add "For example, it might wait some period of time after overload ends before terminating the OLR, or it might send a series of OLRs indicating progressively less overload severity."

> SRD> i'm not clear on what you are suggesting.

We need to be clear that receiving a DOIC avp with a mandatory AVP that you don't understand means you ignore the DOIC AVPs, but does not cause the Diameter transaction to fail. Or was it your intent to allow an application to say that if you get a DOIC avp that you can't process, you have to fail the Diameter transaction?

>  Do you have suggested wording?

Depends on the answer to the question above.

[...]

> SRD> Isn't this already covered?  Do you have suggested wording?

I don't see where we say it in the definition of "loss". It's implied by the example logic, but I think it needs to be more explicit. How about adding the following sentence:

"This percentage reduction is in comparison to the number of messages the node otherwise would send, regardless of how many requests the node might have sent in the past."

> SRD> Do you mean section 6? This isn't about extensibility but about how Diameter applications integrate DOIC.

Agreed that it is probably not about extensibility. But it's not about AVP definitions, either.

>  It probably belongs in the intro or overview sections.

Agreed. I'd suggest the intro.

> SRD> Historical reasons.  Doesn't matter, the real values will be filled in eventually.
>> 

IANA will probably allocate them in order of TBDX numbers. I'd suggest reordering them (here and in the table) to keep child AVP definitions with their parent definition.

---

From: Steve Donovan <[email-masked]>
Date: Mon, 22 Dec 2014 10:56:17 -0600

> In the realm-routed request definition. (This was a continuation of the previous comment.)
SRD> I don't see the need.
> Isn't this the first mention of the feature vector indicating things other than algorithms? If so, I'm not sure I agree that it's redundant.
SRD> I moved the paragraph.
> Remove the 2nd to last and 3rd to last paragraph in 3.0.
SRD> Done
> A colon is the appropriate punctuation to set a list or enumeration off from the preceding text. This would be more obvious if the list included more than 2 items, so that it would have imbedded co…
SRD> I was looking at the wrong paragraph.  I agree with this change.
> We currently aren't consistent. Sometimes we say "host report", and sometimes we say "report of type 'HOST_REPORT'". I suggest we make that consistent, and "host report" is the less cumbersome.
SRD> I still don't see the need.
SRD> Ok.
SRD> Ok.
> We say this in 4.1.1 on reacting node behavior. We should make the same statement for reporting node behavior. This is the definitive section on reporting node behavior. If it's repeated elsewhere,…
SRD> Again, this paragraph is dealing specifically with rules around 
which the algorithms supported by the reporting node interact with the 
OC-Features-Vector AVP.  The statement on other features is three 
paragraphs later.
> I don't think it would change the meaning, just the structure. (I _did_ mention "structural" in the preface to my comments :-)  )
SRD> I have removed the two offending paragraphs.
> Any MAY has an an implied "MIGHT NOT". But if we think it's not clear, we can tack on "Otherwise, the agent relays the OC-Supported-Features AVP without change."
SRD> Changed, including the Otherwise... sentence.
SRD> Ok.
SRD> Ok.
> "A reporting node SHOULD maintain OCS entries for each OLR it sends, per ..."
SRD> I'll start a thread to discuss these two items.
> Diameter endpoints that throttle requests [ MUST /need to ] do so according to the rules of the client application. Those rules will vary by application, and are beyond the scope of this document.
SRD> Ok, without the MUST.
> Actually, on reflection, how does this affect the scenario of an agent that passes through a host report and generates a realm report? Or a server that generates both?
SRD> Yes, I believe it does.  I suggest we delete paragraph 2, as the 
criteria for matching an OCS will be report type dependent.
SRD> Ok.
> Depends on the answer to the question above.
SRD> This requires discussion on the list.  I'll start a thread.
SRD> Ok.
> Agreed. I'd suggest the intro.
SRD> Done.
> IANA will probably allocate them in order of TBDX numbers. I'd suggest reordering them (here and in the table) to keep child AVP definitions with their parent definition.
SRD> Done.

---

From: "TROTTIN, JEAN-JACQUES (JEAN-JACQUES)" <[email-masked]>
Date: Mon, 22 Dec 2014 20:24:43 +0000

Dear all

Hereafter some comments (with JJ>)on some of the points discussed between Ben and Steve. They are not essential

"Reporting nodes _may_ also include overload reports..." 
JJ> The "may" is ambiguous as there is a SHOULD in 4.2.3 when an active OCS. For my clarification, has a "may" in lower case a different meaning from a MAY in upper case. To be only descriptive as with 1st sentence of the paragraph : eg " Reporting nodes communicate overload occurrences by sending the OLR AVP in answers (coming from 3.4, para 4". 

 [...]

-- section 3.3, general:

Much of this section is redundant to stuff in the parent section. (**JJ section 3)I suggest reducing the parent section detail, and keeping it here. (This may be true for subsequent children of section 3.) (**JJ effectively, but may need significant modifications ) 
SRD> Do you have specific suggestions?
Ben> Remove the 2nd to last and 3rd to last paragraph in 3.0.
JJ> OK but in 3.3 to use the text of the removed paragraphs from 3.0 for host report as well as for realm report

 [...]

I'm not sure that's is the word we want here. An agent could muck things up without being ambiguous. Perhaps "inconsistency"? 
SRD> The point is that the reacting nodes and reporting nodes must
unambiguously know what to do.  I think ambiguous is the right word

Ben> I can construct behavior that is not ambiguous to upstream or downstream nodes, but still breaks normative requirements. How about " ... ensure that it does not introduce incorrect behavior for either the upstream or downstream DOIC nodes."

JJ> as Ben, ambiguity is not so right. 
A proposal: "When making changes to the OC-Supported-Features or OC-OLR AVPs, the Diameter Agent needs to ensure  consistency in its behavior with both upstream and downstream DOIC nodes".

-- 4.2.1.1, para 1:

Do I understand correctly that the reacting node only keeps OCS for those combinations that it has actually received an OLR for? If so, that's not clear from the wording. 
SRD> Do you have suggested wording?
Ben> It depends. Does a reacting node keep OCS when it hasn't received an OLR?

If no:

if yes:

JJ>  my point would be to describe in 4.2.1.3 when an OCS is created / deleted (as in 4.2.1.4 for Reporting node which addresses the creation of an OCS, deletion should also be added))
About the MAY in the preface to the second bullet list, to a have a SHOULD in line with 1st paragraph statement "the A reacting node SHOULD maintain the following OCS..." As it is implementation, there were remarks that various ways can  address the OCS or equivalent  handling

[...]

-- 4.2.1.3, para 2:

Should this combination include origin-host or origin-realm? App-Id? 
SRD> I don't understand this.
JJ> not sure we need additional text as it is elsewhere described the matching of an OLR to an OCS

[...]

Ben> Diameter endpoints that throttle requests [ MUST /need to ] do so according to the rules of the client application. Those rules will vary by application, and are beyond the scope of this document.
SRD> Ok, without the MUST

JJ> We have in the same section:.: "The abatement treatment applied depends on the context of the request". We can write "...depends on the application and on the context of the request". Is it not enough?

[...]

-- 4.2.3, para 2:

Doesn't this also need to match the scope for the request type? E.g. Destination realm or destination host? For example, a host report for host A would not match OCS for host B, even though both had the same report type and application id. 
SRD> I guess this matters when an agent is the reporting node

Ben> I think it matters the same if the reporting node is an endpoint. For example, would you consider a host-routed-request with D-H: "foo" to match an host report for host "bar"?  (I'm on the fence here whether that is correct behavior, but I think the behavior should be the same for endpoints and agents.)

JJ>  here 4.2.3 is for the reporting node behavior. It was discussed a while ago if the OCS in the reporting node  was per client (so taking into account the Origin Host of the request or an  OCS common to all clients, so independent of the Origin Host of the request and with the same OLR sent to all clients. The second option (common OCS)  was retained for this draft. The OCS per client would be an option for a further extension.  Si I am OK with the current wording.

-- 4.2.3, last para:

Ben> Add "For example, it might wait some period of time after overload ends before terminating the OLR, or it might send a series of OLRs indicating progressively less overload severity."
SRD> Ok

JJ>  Avoiding  oscillation is an important requirement of RFC7068  and this sentence is one in the draft dealing with oscillations.?  A basic oscillation case is the following one, can we a text (in fact a guidance ) on this/ point. There are also somùe relma	ted qtement in 
"e.g a reporting node having requested a strong traffic reduction, then normally a bit later may observe that it is no more overloaded due to the reduced  traffic received, but it should not immediately send an OLR with a small traffic reduction or even terminates the overload condition as this will most probably again result in a strong increase of the incoming traffic as no more reduced, so creating an oscillation."
This point is somewhat also addressed in the two last paragraphs of 5, in the context of the loss algorithm. This oscillation aspect is more general and so be addressed in this 4.2.3 section

[...]

-- 4.3, para 4: 

Ben> We need to be clear that receiving a DOIC avp with a mandatory AVP that you don't understand means you ignore the DOIC AVPs, but does not cause the Diameter transaction to fail. Or was it your intent to allow an application to say that if you get a DOIC avp that you can't process, you have to fail the Diameter transaction?

JJ> In OC-Supported-Features AVP sent by reacting node, no bit in the OC-Feature-Vector is mandatory except the bit for loss algorithm support. Then if there are additional AVPs in the OC-Supported-Features AVP, they can be ignored except if they are related to a particular feature bit in the OC-Feature-Vector which make this additional AVP mandatory to be supported if the feature is supported by the reporting node.  In any case, the request should not fail.
If the OLR AVP contains new AVPs, this will be also related to the corresponding feature bit that, if supported,  may require the new AVP be  mandatory in the OLRS sent back by the reporting node.. This will be part of the new feature description introducing additional AVPs. So I do not think we need to say more in this draft. This will be in the extension.

[...]

-- 5.1, para 4:

Convoluted paragraph. How about "How about "reporting nodes request the stateless reduction of the number of requests by an indicated percentage." 
SRD> Ok. 
JJ> OK on Ben wording but "stateless" can be removed as  mentioned earlier in the section and not directly linked to this sentence. 

Then about "...to what the reacting node otherwise would have sent" , this point, I think, is described in 5.3 paragraph 4

Best regards

JJacques 

-----Message d'origine-----
De : DiME [mailto:[email-masked]] De la part de Steve Donovan
Envoyé : mercredi 17 décembre 2014 17:27
À : [email-masked]
Objet : Re: [Dime] DOIC WGLC: Editorial Comments

SRD> This was done based on feedback from Benoit.  We are being
explicit.  If there are paragraphs where it is particularly cumbersome, please point out those paragraphs and we can try to make them less cumbersome.
SRD> Ok.
SRD> Ok.
SRD> Ok.
SRD> Ok.
SRD> Where?
SRD> The capitalization of Diameter Clients, Diameter Servers and
Diameter agents was Benoit's suggestion to make it explicit what is being referred to.  I don't see the need for hyphenation in this context.  I'm ok with moving the sentence.
SRD> OK.
SRD> OK.
SRD> Agreed.
SRD> Ok.
SRD> Ok.
SRD> Ok.
SRD> Ok.
>
> -- section 3.3, general:
>
> Much of this section is redundant to stuff in the parent section. I 
> suggest reducing the parent section detail, and keeping it here. (This 
> may be true for subsequent children of section 3.)
>
> -- 3.3, paragraph 4:
>
> In this overview, I suggest text saying that HOST_REPORT indicates a 
> host report, and just using the term "host report" the rest of the 
> time. (Same for realm report)
SRD> Why?
SRD> OK.
SRD> Ok.
SRD> OK
SRD> Agreed.
SRD> OK.
SRD> This paragraph is talking specifically about algorithms and is
needed because the AVP is optional.  Are you suggesting another sentence, another paragraph?  I'm guessing that the case you talk about is already covered elsewhere.
SRD> I don't read it that way.  The first sentence is describing one
reason why an agent might change OC-S-F.  It doesn't say it is the only reason.
SRD> Yes.
> I suggest language like " invalid" or "terminated". I take "expired" 
> to mean "naturally expired", which is different from the case 
> described here. There may be subtle behavior difference. (For example, 
> a reacting node might choose to log "expirations" differently than 
> "explicit terminations".)
SRD> For the context of this specification I think expired works.  
Implementations can differentiate types of expired if they have a reason.  Nothing here prevents that.
SRD> OK.
SRD> OK.
SRD> OK.
> This is redundant to earlier normative language in the section 
> (assuming a new report type will always involve new normative 
> behavior.)
SRD> Agreed.
SRD> OK.
SRD> Ok.
SRD> OK.
SRD> Agreed.
SRD> Do you mean section 6? This isn't about extensibility but about how
Diameter applications integrate DOIC.  It probably belongs in the intro or overview sections.
SRD> Yes. :-)
SRD> Ok.
SRD> Ok.
SRD> Ok.

---

From: Ben Campbell <[email-masked]>
Date: Mon, 22 Dec 2014 18:11:17 -0600

Hi, I've removed sections that seem to need no further discussion, where you've suggested moving to separate threads, or where I'm just gonna roll over :-)

> On Dec 22, 2014, at 10:56 AM, Steve Donovan <[email-masked]> wrote:

[...]
> SRD> Again, this paragraph is dealing specifically with rules around which the algorithms supported by the reporting node interact with the OC-Features-Vector AVP.  The statement on other features is three paragraphs later.

If you mean this paragraph:

"  The reporting node SHOULD indicate support for other DOIC features
   defined in extension drafts that it supports and that apply to the
   transaction."

Nothing in that (3 paragraphs later) paragraph says you MUST include OC-Features-Vector to do that. It's left for the reader to infer. We do explicitly say that for reacting nodes in 4.1.1.

[...]

---

From: Steve Donovan <[email-masked]>
Date: Mon, 29 Dec 2014 10:38:51 -0600

> Nothing in that (3 paragraphs later) paragraph says you MUST include OC-Features-Vector to do that. It's left for the reader to infer. We do explicitly say that for reacting nodes in 4.1.1.
SRD>  How about adding ..."it does so using the OC-Feature-Vector AVP" 
to the end of the above paragraph.