Subject: [Dime] Resolution on action to discuss the need for Realm-Routed-Reports

From: Steve Donovan <[email-masked]>
Date: Fri, 21 Mar 2014 09:32:56 -0500

All,

Ben and I took the action item to discuss the need for the
Realm-Routed-Reports (RRR) report type.

As you may recall, the consensus coming out of the DIME WG meeting in
London was to support two report types:

- Host -- Impacting requests with a Destination-Host AVP matching the
host in the overload report (with the host implicitly determined from
the Origin-Host AVP of the answer message carrying the overload report).

- Realm -- Impacting 100% of the requests with a Destination-Realm AVP
matching the realm in the overload report (with the realm implicitly
determine from the Origin-Realm of the answer message carrying the
overload report).

The action Ben and I took was to come back with an opinion on whether
RRR reports should also be supported.

My summary of the discussion is that we recommend to NOT include RRR
reports in the current version of the base DOIC draft. 

We still have some concerns with the granularity of control enabled by
having just the two report types but the analysis of whether RRR reports
are still needed can occur independent of the base DOIC draft.  If there
is a determination that RRRs are needed in time to include in the base
draft then it can be considered at that time.

Based on this, I propose the following

- Resolution to issue #23 is to remove RRR reports from the document.
- Resolution to issue #55 is to add Realm reports (actually to redefine
them per the above definition).
- Resolution to issue #57 is that it no longer applies (as it deals with
RRRs).

There is also need for text describing the interaction between host and
the realm reports.  I don't expect we will have consensus on this
wording prior to the -02 draft being submitted.  To this end, I'll open
a new issue to deal with the need for wording on the interaction.

Regards,

Steve

---

From: "Wiehe, Ulrich (NSN - DE/Munich)" <[email-masked]>
Date: Fri, 21 Mar 2014 15:09:41 +0000

Steve,

I don't know what happend in London.
Can you please summarize the technical reasons that led to the London agreement.
E-mail discussions prior to London have clearly directed towards a report type that requests throttling of realm routed request messages (i.e. not containing a destination host) rather than a report type that requests throttling of messages routed towards a realm (no matter whether they contain a destination host or not).

Ulrich

From: DiME [mailto:[email-masked]] On Behalf Of ext Steve Donovan
Sent: Friday, March 21, 2014 3:33 PM
To: [email-masked]
Subject: [Dime] Resolution on action to discuss the need for Realm-Routed-Reports

All,

Ben and I took the action item to discuss the need for the Realm-Routed-Reports (RRR) report type.

As you may recall, the consensus coming out of the DIME WG meeting in London was to support two report types:

- Host -- Impacting requests with a Destination-Host AVP matching the host in the overload report (with the host implicitly determined from the Origin-Host AVP of the answer message carrying the overload report).

- Realm -- Impacting 100% of the requests with a Destination-Realm AVP matching the realm in the overload report (with the realm implicitly determine from the Origin-Realm of the answer message carrying the overload report).

The action Ben and I took was to come back with an opinion on whether RRR reports should also be supported.

My summary of the discussion is that we recommend to NOT include RRR reports in the current version of the base DOIC draft.

We still have some concerns with the granularity of control enabled by having just the two report types but the analysis of whether RRR reports are still needed can occur independent of the base DOIC draft.  If there is a determination that RRRs are needed in time to include in the base draft then it can be considered at that time.

- Resolution to issue #23 is to remove RRR reports from the document.
- Resolution to issue #55 is to add Realm reports (actually to redefine them per the above definition).
- Resolution to issue #57 is that it no longer applies (as it deals with RRRs).

There is also need for text describing the interaction between host and the realm reports.  I don't expect we will have consensus on this wording prior to the -02 draft being submitted.  To this end, I'll open a new issue to deal with the need for wording on the interaction.

Regards,

Steve

---

From: Steve Donovan <[email-masked]>
Date: Fri, 21 Mar 2014 16:05:35 -0500

Ulrich,

The discussion should be captured in the minutes to the meeting.  I
wasn't able to find them posted yet.

Jouni, Lionel, what is the status of the minutes for the meeting?

My reading of emails prior to the London meeting is different from
yours.  I believe we had come to the conclusion that we needed host and
realm (with the definition of realm as outlined below).  We were still
discussing the need for Realm-Routed-Request reports.

Regards,

Steve

On 3/21/14 10:09 AM, Wiehe, Ulrich (NSN - DE/Munich) wrote:
> E-mail discussions prior to London have clearly directed towards a
> report type that requests throttling of realm routed request messages
> (i.e. not containing a destination host) rather than a report type
> that requests throttling of messages routed towards a realm (no matter
> whether they contain a destination host or not).   
>
>  
>
> Ulrich
>
>  
>
> *From:*DiME [mailto:[email-masked]] *On Behalf Of *ext Steve
> Donovan
> *Sent:* Friday, March 21, 2014 3:33 PM
> *To:* [email-masked]
> *Subject:* [Dime] Resolution on action to discuss the need for
> Realm-Routed-Reports
>
>  
>
> All,
>
> having just the two report types but the analysis of whether RRR
> reports are still needed can occur independent of the base DOIC
> draft.  If there is a determination that RRRs are needed in time to
> include in the base draft then it can be considered at that time.
>
> There is also need for text describing the interaction between host
> and the realm reports.  I don't expect we will have consensus on this
> wording prior to the -02 draft being submitted.  To this end, I'll
> open a new issue to deal with the need for wording on the interaction.
>
> Regards,
>
> Steve
>

---

From: Dave Dolson <[email-masked]>
Date: Sat, 22 Mar 2014 11:43:59 +0000

It is difficult to judge this issue without knowing how the reported values are to be resolved when contradictory.

To send a request with both realm and host name, and having reported realm and host percentages, what should be done?

Does the client have to keep track of how much it has sent to each host, and also the realm as a whole?

This needs to be part of the spec, not left to vendor-specific implementation, because the overloaded realm/node needs a model of how the client will react.

The approach of having feedback for realm-only messages made it easier to understand what the client should do.

-Dave

From: Steve Donovan [mailto:[email-masked]]
Sent: Friday, March 21, 2014 05:05 PM
To: [email-masked] <[email-masked]>
Subject: Re: [Dime] Resolution on action to discuss the need for Realm-Routed-Reports

Ulrich,

The discussion should be captured in the minutes to the meeting.  I wasn't able to find them posted yet.

My reading of emails prior to the London meeting is different from yours.  I believe we had come to the conclusion that we needed host and realm (with the definition of realm as outlined below).  We were still discussing the need for Realm-Routed-Request reports.

Regards,

Steve

I don’t know what happend in London.
Can you please summarize the technical reasons that led to the London agreement.
E-mail discussions prior to London have clearly directed towards a report type that requests throttling of realm routed request messages (i.e. not containing a destination host) rather than a report type that requests throttling of messages routed towards a realm (no matter whether they contain a destination host or not).

Ulrich

From: DiME [mailto:[email-masked]] On Behalf Of ext Steve Donovan
Sent: Friday, March 21, 2014 3:33 PM
To: [email-masked]<mailto:[email-masked]>
Subject: [Dime] Resolution on action to discuss the need for Realm-Routed-Reports

All,

Regards,

Steve

---

From: Steve Donovan <[email-masked]>
Date: Mon, 24 Mar 2014 07:21:30 -0500

Dave,

You are correct, we need to have wording on the interaction between the
report types, thus the last paragraph in my proposal.

This will likely be shown as an open issue in the -02 version of the
draft, unless we come to consensus on wording between now and Thursday. 

Steve

On 3/22/14 6:43 AM, Dave Dolson wrote:
> It is difficult to judge this issue without knowing how the reported
> values are to be resolved when contradictory.
>
> To send a request with both realm and host name, and having reported
> realm and host percentages, what should be done?
>
> This needs to be part of the spec, not left to vendor-specific
> implementation, because the overloaded realm/node needs a model of how
> the client will react.
>
>
> *From*: Steve Donovan [mailto:[email-masked]]
> *Sent*: Friday, March 21, 2014 05:05 PM
> *To*: [email-masked] <[email-masked]>
> *Subject*: Re: [Dime] Resolution on action to discuss the need for
> Realm-Routed-Reports
>  
> Ulrich,
>
> yours.  I believe we had come to the conclusion that we needed host
> and realm (with the definition of realm as outlined below).  We were
> still discussing the need for Realm-Routed-Request reports.
>
> Regards,
>
> Steve
>
>> that requests throttling of messages routed towards a realm (no
>> matter whether they contain a destination host or not).   
>>
>>  
>>
>> Ulrich
>>
>>  
>>
>> - Realm -- Impacting 100% of the requests with a Destination-Realm
>> AVP matching the realm in the overload report (with the realm
>> implicitly determine from the Origin-Realm of the answer message
>> carrying the overload report).
>>
>> We still have some concerns with the granularity of control enabled
>> by having just the two report types but the analysis of whether RRR

---

From: Steve Donovan <[email-masked]>
Date: Mon, 24 Mar 2014 08:56:33 -0500

Ulrich,
All,

We have two options for the -02 draft.

1) Support Host and Realm as proposed below, removing RRR reports.
2) Support Host, Realm and RRR reports.

The default plan is to go with option 1 in the -02 draft, as that was
the proposal that came out of the meeting in London.  RRR reports can be
added back in if and when we are convinced of the need. 

If there are strong objections to this then I will update the -02 draft
to reflect all three report types.

I plan to make these updates Wednesday morning, Dallas, Texas time.

Either way I do not expect we will have agreed to wording on the
interaction between the report types when a reacting node has multiple
report types, all of which apply to individual requests.  This will need
to be addressed in the -03 draft.

Regards,

Steve

On 3/21/14 4:05 PM, Steve Donovan wrote:
> _______________________________________________
> DiME mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dime

---

From: "TROTTIN, JEAN-JACQUES (JEAN-JACQUES)" <[email-masked]>
Date: Mon, 24 Mar 2014 14:25:40 +0000

Hi all

This topic is not an easy one, and for me we have  not taken  conclusion in London

-          One question is how to deal with requests for which we do not know the destination host but only the realm, which is an important point (so with the  RRR OLRs)

-          Another question is what is a realm overload . On this one, not yet straight forward for me; we can consider a realm overload when a lot of servers overloaded (but this overload is handled by host OLRs, so there would be overlap with a realm OLR ),  and DA overload (which is to be studied, and   probably not  using a realm OLR) ). What are the other sources of overload  at realm level for which I have not had clear explanations or use cases on this ?

-          As Dave mentioned , what happens when for the same request, we can apply the host OLR and the realm OLR, we ahev to be careful there. Wuth the so called RRR OLRs are not overlapping with the Hosts OLR.

-          The objective we retained in London is to try to avoid two types of realm OLRs.

So here we are, and I would not like to too quckly drop the RRR OLRS  which   we recognize useful as we  introduced  them in the version 01 of the draft.

Best regards

JJacques

.

De : DiME [mailto:[email-masked]] De la part de Steve Donovan
Envoyé : lundi 24 mars 2014 14:57
À : [email-masked]
Objet : Re: [Dime] Resolution on action to discuss the need for Realm-Routed-Reports

Ulrich,
All,

The default plan is to go with option 1 in the -02 draft, as that was the proposal that came out of the meeting in London.  RRR reports can be added back in if and when we are convinced of the need.

If there are strong objections to this then I will update the -02 draft to reflect all three report types.

Either way I do not expect we will have agreed to wording on the interaction between the report types when a reacting node has multiple report types, all of which apply to individual requests.  This will need to be addressed in the -03 draft.

Regards,

Steve

Regards,

Steve

Ulrich

All,

Regards,

Steve

DiME mailing list

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

---

From: "Wiehe, Ulrich (NSN - DE/Munich)" <[email-masked]>
Date: Mon, 24 Mar 2014 16:13:37 +0000

Steve,

I do not agree.

We should still have the option
3) support report type 0 (this is called host report) and support of report type 1 (this has been called relam report but people argued it should better be called realm routed request report).

Whether or not we need in addition to type 0 and type 1 (or as a replacement of type 1) a realm-no-matter-whether-destination-host-is present-or-not report   is an open issue (see #55).
There are a lot of open questions  with regard to #55 and I have not seen a conclusion.
Where I have seen a conclusion is issue #34 and that is inline with option 3).

Unless we conclude on #55, or decide to re-open #34, option 3) is what should go in the -02 draft.

Ulrich

From: DiME [mailto:[email-masked]] On Behalf Of ext Steve Donovan
Sent: Monday, March 24, 2014 2:57 PM
To: [email-masked]
Subject: Re: [Dime] Resolution on action to discuss the need for Realm-Routed-Reports

Ulrich,
All,

Regards,

Steve

Regards,

Steve

Ulrich

All,

Regards,

Steve

DiME mailing list

---

From: Steve Donovan <[email-masked]>
Date: Mon, 24 Mar 2014 13:37:48 -0500

Ok, we are going backwards on this one.

I did not include option three because we had moved past that option in
our discussions, both on the list (I thought), and in the meeting.

I believe that we had come to rough consensus on the need for a realm
report and the only remaining issue was whether we also included the RRR
report type.

At this point, the only option is to leave all of the issues related to
the report types open and attempt to resolve them in the -03 draft.

Steve

On 3/24/14 11:13 AM, Wiehe, Ulrich (NSN - DE/Munich) wrote:
> 3) support report type 0 (this is called host report) and support of
> report type 1 (this has been called relam report but people argued it
> should better be called realm routed request report).
>
>  
>
> Whether or not we need in addition to type 0 and type 1 (or as a
> replacement of type 1) a realm-no-matter-whether-destination-host-is
> present-or-not report   is an open issue (see #55).
>
> *Sent:* Monday, March 24, 2014 2:57 PM
> *To:* [email-masked]
> *Subject:* Re: [Dime] Resolution on action to discuss the need for
> Realm-Routed-Reports
>
>  
>
> Ulrich,
> All,
>
> the proposal that came out of the meeting in London.  RRR reports can
> be added back in if and when we are convinced of the need. 
>
> report types, all of which apply to individual requests.  This will
> need to be addressed in the -03 draft.
>
> Regards,
>
> Steve
>
>     yours.  I believe we had come to the conclusion that we needed
>     host and realm (with the definition of realm as outlined below). 
>     We were still discussing the need for Realm-Routed-Request reports.
>
>     Regards,
>
>     Steve
>
>         E-mail discussions prior to London have clearly directed
>         towards a report type that requests throttling of realm routed
>         request messages (i.e. not containing a destination host)
>         rather than a report type that requests throttling of messages
>         routed towards a realm (no matter whether they contain a
>         destination host or not).   
>
>          
>
>         Ulrich
>
>          
>
>         *From:*DiME [mailto:[email-masked]] *On Behalf Of *ext
>         Steve Donovan
>         *To:* [email-masked] <mailto:[email-masked]>
>         As you may recall, the consensus coming out of the DIME WG
>         meeting in London was to support two report types:
>
>         - Host -- Impacting requests with a Destination-Host AVP
>         matching the host in the overload report (with the host
>         implicitly determined from the Origin-Host AVP of the answer
>         message carrying the overload report).
>
>         - Realm -- Impacting 100% of the requests with a
>         Destination-Realm AVP matching the realm in the overload
>         report (with the realm implicitly determine from the
>         Origin-Realm of the answer message carrying the overload report).
>
>         The action Ben and I took was to come back with an opinion on
>         whether RRR reports should also be supported.
>
>         My summary of the discussion is that we recommend to NOT
>         include RRR reports in the current version of the base DOIC
>         draft. 
>
>         We still have some concerns with the granularity of control
>         enabled by having just the two report types but the analysis
>         of whether RRR reports are still needed can occur independent
>         of the base DOIC draft.  If there is a determination that RRRs
>         are needed in time to include in the base draft then it can be
>         considered at that time.
>
>         There is also need for text describing the interaction between
>         host and the realm reports.  I don't expect we will have
>         consensus on this wording prior to the -02 draft being
>         submitted.  To this end, I'll open a new issue to deal with
>         the need for wording on the interaction.
>
>         Regards,
>
>         Steve
>
>
>
>
>
>     [email-masked] <mailto:[email-masked]>
>

---

From: <[email-masked]>
Date: Mon, 24 Mar 2014 19:27:10 +0000

Let say that we have a working assumption on this one and please move on.

There is no need to reach a 100% agreement on this one to be able to publish the version 02 and to have something consistent.

So please Ulrich, don't forget your concern but please accept that the current working assumption. And let see if the concern is still valid afterward.

Regards,

Lionel

De : DiME [mailto:[email-masked]] De la part de Steve Donovan
Envoyé : lundi 24 mars 2014 19:38
À : Wiehe, Ulrich (NSN - DE/Munich); [email-masked]
Objet : Re: [Dime] Resolution on action to discuss the need for Realm-Routed-Reports

I did not include option three because we had moved past that option in our discussions, both on the list (I thought), and in the meeting.

I believe that we had come to rough consensus on the need for a realm report and the only remaining issue was whether we also included the RRR report type.

At this point, the only option is to leave all of the issues related to the report types open and attempt to resolve them in the -03 draft.

Steve

I do not agree.

Ulrich

Ulrich,
All,

Regards,

Steve

Regards,

Steve

Ulrich

All,

Regards,

Steve

DiME mailing list

_________________________________________________________________________________________________________________________

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: "Wiehe, Ulrich (NSN - DE/Munich)" <[email-masked]>
Date: Tue, 25 Mar 2014 07:48:10 +0000

I don't agree with this working assumption.

And I strongly disagree with the proposed way forward.

Ulrich

From: ext [email-masked] [mailto:[email-masked]]
Sent: Monday, March 24, 2014 8:27 PM
To: Steve Donovan; Wiehe, Ulrich (NSN - DE/Munich); [email-masked]
Subject: RE: [Dime] Resolution on action to discuss the need for Realm-Routed-Reports

Regards,

Lionel

De : DiME [mailto:[email-masked]] De la part de Steve Donovan
Envoyé : lundi 24 mars 2014 19:38
À : Wiehe, Ulrich (NSN - DE/Munich); [email-masked]<mailto:[email-masked]>
Objet : Re: [Dime] Resolution on action to discuss the need for Realm-Routed-Reports

Steve

I do not agree.

Ulrich

Ulrich,
All,

Regards,

Steve

Regards,

Steve

Ulrich

All,

Regards,

Steve

DiME mailing list

Thank you.

---

From: "Shishufeng (Susan)" <[email-masked]>
Date: Tue, 25 Mar 2014 07:57:40 +0000

+1

From: Wiehe, Ulrich (NSN - DE/Munich) [mailto:[email-masked]]
Sent: Tuesday, March 25, 2014 12:14 AM
To: ext Steve Donovan; [email-masked]
Subject: Re: [Dime] Resolution on action to discuss the need for Realm-Routed-Reports

Steve,

I do not agree.

Ulrich

Ulrich,
All,

Regards,

Steve

Regards,

Steve

Ulrich

All,

Regards,

Steve

DiME mailing list

---

From: "Wiehe, Ulrich (NSN - DE/Munich)" <[email-masked]>
Date: Tue, 25 Mar 2014 11:44:17 +0000

Steve,
I don't think we are going backwards (we may be out of synch though)

Can you please summarize the status of #23 and #55.

Ulrich

From: ext Steve Donovan [mailto:[email-masked]]
Sent: Monday, March 24, 2014 7:38 PM
To: Wiehe, Ulrich (NSN - DE/Munich); [email-masked]
Subject: Re: [Dime] Resolution on action to discuss the need for Realm-Routed-Reports

Steve

I do not agree.

Ulrich

Ulrich,
All,

Regards,

Steve

Regards,

Steve

Ulrich

All,

Regards,

Steve

DiME mailing list

---

From: Steve Donovan <[email-masked]>
Date: Tue, 25 Mar 2014 08:49:17 -0500

Ulrich,

I mean going backwards from where I thought we were after the London
meeting.

We are clearly out of sync but hopefully we can fix that.

Here's my understanding of the status of #23 and #55.

Prior to London meeting:

#23 status:
 - Agreement to change the name of existing realm reports to
realm-routed-reports (RRR).
 - Discussions were ongoing as to the need for both realm reports and
RRR reports.

#55 status:
  - Agreement on adding Realm reports based on the definition that realm
reports apply to all traffic sent to the realm.
  - Limited discussion on the interaction between the new realm reports
and the existing host and RRR reports.

After London meeting:

#23 status:
  - Tentative agreement in London meeting to remove RRR reports.
  - Ben expressed the strongest concern with this plan.  Steve and Ben
took action to discuss and come back with a recommendation. 

#55 status:
  - No change

Summary:
  - Tentative consensus reached to move forward with two report types -
host and realm, with realm having the new definition.

Current status:

#23 status:
 - Change the name to RRR
 - Whether or not to remove RRR and revisit later or keep RRR and
revisit later is an open issue.

#55 status:
  - My opinion is that we have at least rough consensus on the need to
support realm reports.  Others might have a different opinion.

Summary:
  - I believe we have three options:

   1) Support host and RRR reports
   2) Support host and Realm reports -- This was the tentative plan
coming out of the London meeting
   3) Support host, RRR and Realm reports

Regards,

Steve

On 3/25/14 6:44 AM, Wiehe, Ulrich (NSN - DE/Munich) wrote:
> *From:*ext Steve Donovan [mailto:[email-masked]]
> *Sent:* Monday, March 24, 2014 7:38 PM
> *To:* Wiehe, Ulrich (NSN - DE/Munich); [email-masked]
> I did not include option three because we had moved past that option
> in our discussions, both on the list (I thought), and in the meeting.
>
> report and the only remaining issue was whether we also included the
> RRR report type.
>
> At this point, the only option is to leave all of the issues related
> to the report types open and attempt to resolve them in the -03 draft.
>
> Steve
>
>     3) support report type 0 (this is called host report) and support
>     of report type 1 (this has been called relam report but people
>     argued it should better be called realm routed request report).
>
>      
>
>     replacement of type 1) a
>     realm-no-matter-whether-destination-host-is present-or-not report
>       is an open issue (see #55).
>
>     The default plan is to go with option 1 in the -02 draft, as that
>     was the proposal that came out of the meeting in London.  RRR
>     reports can be added back in if and when we are convinced of the
>     need. 
>
>     interaction between the report types when a reacting node has
>     multiple report types, all of which apply to individual requests. 
>     This will need to be addressed in the -03 draft.
>
>     Regards,
>
>     Steve
>
>         The discussion should be captured in the minutes to the
>         meeting.  I wasn't able to find them posted yet.
>
>         My reading of emails prior to the London meeting is different
>         from yours.  I believe we had come to the conclusion that we
>         needed host and realm (with the definition of realm as
>         outlined below).  We were still discussing the need for
>         Realm-Routed-Request reports.
>
>         Regards,
>
>         Steve
>
>             towards a report type that requests throttling of realm
>             routed request messages (i.e. not containing a destination
>             host) rather than a report type that requests throttling
>             of messages routed towards a realm (no matter whether they
>             contain a destination host or not).   
>
>              
>
>             Ulrich
>
>              
>
>             *From:*DiME [mailto:[email-masked]] *On Behalf Of
>             *ext Steve Donovan
>             *Subject:* [Dime] Resolution on action to discuss the need
>             for Realm-Routed-Reports
>
>              
>
>             All,
>
>             implicitly determined from the Origin-Host AVP of the
>             answer message carrying the overload report).
>
>             The action Ben and I took was to come back with an opinion
>             on whether RRR reports should also be supported.
>
>             include RRR reports in the current version of the base
>             DOIC draft. 
>
>             We still have some concerns with the granularity of
>             control enabled by having just the two report types but
>             the analysis of whether RRR reports are still needed can
>             occur independent of the base DOIC draft.  If there is a
>             determination that RRRs are needed in time to include in
>             the base draft then it can be considered at that time.
>
>             - Resolution to issue #55 is to add Realm reports
>             (actually to redefine them per the above definition).
>             There is also need for text describing the interaction
>             between host and the realm reports.  I don't expect we
>             will have consensus on this wording prior to the -02 draft
>             being submitted.  To this end, I'll open a new issue to
>             deal with the need for wording on the interaction.
>
>             Regards,
>
>             Steve
>
>
>
>
>
>

---

From: "Wiehe, Ulrich (NSN - DE/Munich)" <[email-masked]>
Date: Tue, 25 Mar 2014 15:14:48 +0000

Steve,
Thank you for this summary.
Please see inline.

Ulrich

From: ext Steve Donovan [mailto:[email-masked]]
Sent: Tuesday, March 25, 2014 2:49 PM
To: Wiehe, Ulrich (NSN - DE/Munich); [email-masked]
Subject: Re: [Dime] Resolution on action to discuss the need for Realm-Routed-Reports

Ulrich,

I mean going backwards from where I thought we were after the London meeting.

Prior to London meeting:

#23 status:
 - Agreement to change the name of existing realm reports to realm-routed-reports (RRR).
<Ulrich>this includes agreement to keep the (newly called) realm-routed-reports</Ulrich>
 - Discussions were ongoing as to the need for both realm reports and RRR reports.
<Ulrich>I would say "...as to the need for realm reports in addition to realm-routed-reports" </Ulrich>

#55 status:
  - Agreement on adding Realm reports based on the definition that realm reports apply to all traffic sent to the realm.
<Ulrich>This is what I'm missing. The issue has been very briefly discussed under #34 without conclusion. There was no discussion under #55</Ulrich>

  - Limited discussion on the interaction between the new realm reports and the existing host and RRR reports.

After London meeting:

#23 status:
  - Tentative agreement in London meeting to remove RRR reports.
<Ulrich>What was the technical argument?</Ulrich>

  - Ben expressed the strongest concern with this plan.  Steve and Ben took action to discuss and come back with a recommendation.

#55 status:
  - No change

Summary:
  - Tentative consensus reached to move forward with two report types - host and realm, with realm having the new definition.
<Ulrich>What was the technical argument?</Ulrich>

Current status:

#23 status:
 - Change the name to RRR
 - Whether or not to remove RRR and revisit later or keep RRR and revisit later is an open issue.

#55 status:
  - My opinion is that we have at least rough consensus on the need to support realm reports.  Others might have a different opinion.
<Ulrich> There was no comment posted to issue #55, also no proposed solution, so I cannot see where the consensus came from</Ulrich>

Summary:

   1) Support host and RRR reports
   2) Support host and Realm reports -- This was the tentative plan coming out of the London meeting
< Ulrich> There is not even an issue number identifying problems with RRR and proposing to remove RRR</Ulrich>

<Ulrich> I support option 1</Ulrich>

Regards,

Steve

Ulrich

From: ext Steve Donovan [mailto:[email-masked]]
Sent: Monday, March 24, 2014 7:38 PM
To: Wiehe, Ulrich (NSN - DE/Munich); [email-masked]<mailto:[email-masked]>
Subject: Re: [Dime] Resolution on action to discuss the need for Realm-Routed-Reports

Steve

I do not agree.

Ulrich

Ulrich,
All,

Regards,

Steve

Regards,

Steve

Ulrich

All,

Regards,

Steve

DiME mailing list

---

From: Maria Cruz Bartolome <[email-masked]>
Date: Tue, 25 Mar 2014 15:16:36 +0000

+1
My understanding of the discussion before London's meeting and in that meeting was that option 3 was considered.
That is, we have two reports, host and realm.
Host applies when Destination_host is present, and then it takes precedence over Realm. If both are present, only Host is applied.
Realm applies when only Destination_realm is present.

And.. we did not have consensus on nothing else, at least this was my interpretation.
Cheers
/MCruz

From: DiME [mailto:[email-masked]] On Behalf Of Shishufeng (Susan)
Sent: martes, 25 de marzo de 2014 8:58
To: Wiehe, Ulrich (NSN - DE/Munich); ext Steve Donovan; [email-masked]
Subject: Re: [Dime] Resolution on action to discuss the need for Realm-Routed-Reports

+1

From: Wiehe, Ulrich (NSN - DE/Munich) [mailto:[email-masked]]
Sent: Tuesday, March 25, 2014 12:14 AM
To: ext Steve Donovan; [email-masked]<mailto:[email-masked]>
Subject: Re: [Dime] Resolution on action to discuss the need for Realm-Routed-Reports

Steve,

I do not agree.

Ulrich

Ulrich,
All,

Regards,

Steve

Regards,

Steve

Ulrich

All,

Regards,

Steve

DiME mailing list

---

From: Maria Cruz Bartolome <[email-masked]>
Date: Tue, 25 Mar 2014 15:20:44 +0000

Dear all,

I support option 1 a well
Cheers
/MCruz

From: DiME [mailto:[email-masked]] On Behalf Of Wiehe, Ulrich (NSN - DE/Munich)
Sent: martes, 25 de marzo de 2014 16:15
To: ext Steve Donovan; [email-masked]
Subject: Re: [Dime] Resolution on action to discuss the need for Realm-Routed-Reports

Steve,

Ulrich

Ulrich,

Prior to London meeting:

#23 status:

#55 status:

After London meeting:

#23 status:

#55 status:
  - No change

Summary:

Current status:

#23 status:
 - Change the name to RRR

#55 status:

Summary:

Regards,

Steve

Ulrich

Steve

I do not agree.

Ulrich

Ulrich,
All,

Regards,

Steve

Regards,

Steve

Ulrich

All,

Regards,

Steve

DiME mailing list

---

From: <[email-masked]>
Date: Tue, 25 Mar 2014 15:27:02 +0000

Hi Maria Cruz, All,

In the previous mail, you wrote:

And I agree with this statement. But I'm not sure that this is the case discussed by Ulrich.

Whatever the name of the realm report type, is there an agreement on the description given above by Maria Cruz and discussed in London?

Regards,

Lionel

De : DiME [mailto:[email-masked]] De la part de Maria Cruz Bartolome
Envoyé : mardi 25 mars 2014 16:21
À : Wiehe, Ulrich (NSN - DE/Munich); ext Steve Donovan; [email-masked]
Objet : Re: [Dime] Resolution on action to discuss the need for Realm-Routed-Reports

Dear all,

Steve,

Ulrich

Ulrich,

Prior to London meeting:

#23 status:

#55 status:

After London meeting:

#23 status:

#55 status:
  - No change

Summary:

Current status:

#23 status:
 - Change the name to RRR

#55 status:

Summary:

Regards,

Steve

Ulrich

Steve

I do not agree.

Ulrich

Ulrich,
All,

Regards,

Steve

Regards,

Steve

Ulrich

All,

Regards,

Steve

DiME mailing list

---

From: Steve Donovan <[email-masked]>
Date: Tue, 25 Mar 2014 11:40:53 -0500

Consensus is obviously a fleeting and temporary thing.

Let us make sure that we are precise in our definitions of the report
types we are discussing.

Host report - Applies when the destination-host AVP is present in the
request.
Realm-Routed-Request (RRR) - Applies when there is no destination-host
AVP in the request.
Realm - Applies to 100% of requests sent to the realm.

These are the definitions used in our discussions in London and in
various places in our email discussions. 

Can we please agree to use these definitions going forward so we are all
talking about the same thing.

Regards,

Steve

On 3/25/14 10:27 AM, [email-masked] wrote:
> /That is, we have two reports, host and realm. /
>
> /Host applies when Destination_host is present, and then it takes
> precedence over Realm. If both are present, only Host is applied./
>
> /Realm applies when only Destination_realm is present./
>
>  
>
> Whatever the name of the realm report type, is there an agreement on
> the description given above by Maria Cruz and discussed in London?
>
>  
>
> Regards,
>
>  
>
> Lionel
>
>  
>
> *De :*DiME [mailto:[email-masked]] *De la part de* Maria Cruz
> Bartolome
> *Envoyé :* mardi 25 mars 2014 16:21
> *À :* Wiehe, Ulrich (NSN - DE/Munich); ext Steve Donovan; [email-masked]
> *Objet :* Re: [Dime] Resolution on action to discuss the need for
> Realm-Routed-Reports
>
>  
>
> Dear all,
>
>  
>
> *From:*DiME [mailto:[email-masked]] *On Behalf Of *Wiehe,
> Ulrich (NSN - DE/Munich)
> *Sent:* martes, 25 de marzo de 2014 16:15
> *To:* ext Steve Donovan; [email-masked]
> *Sent:* Tuesday, March 25, 2014 2:49 PM
> <mailto:[email-masked]>
>   - Agreement on adding Realm reports based on the definition that
> realm reports apply to all traffic sent to the realm.
>
> <Ulrich>This is what I'm missing. The issue has been very briefly
> discussed under #34 without conclusion. There was no discussion under
> #55</Ulrich>*//*
>
>
>   - Limited discussion on the interaction between the new realm
> reports and the existing host and RRR reports.
>
> After London meeting:
>
> #23 status:
>   - Tentative consensus reached to move forward with two report types
> - host and realm, with realm having the new definition.
> <Ulrich> There was no comment posted to issue #55, also no proposed
> solution, so I cannot see where the consensus came from</Ulrich>
>
>
>
> Summary:
>     <mailto:[email-masked]>
>     I did not include option three because we had moved past that
>     option in our discussions, both on the list (I thought), and in
>     the meeting.
>
>     I believe that we had come to rough consensus on the need for a
>     realm report and the only remaining issue was whether we also
>     included the RRR report type.
>
>     At this point, the only option is to leave all of the issues
>     related to the report types open and attempt to resolve them in
>     the -03 draft.
>
>     Steve
>
>         3) support report type 0 (this is called host report) and
>         support of report type 1 (this has been called relam report
>         but people argued it should better be called realm routed
>         request report).
>
>          
>
>         Whether or not we need in addition to type 0 and type 1 (or as
>         a replacement of type 1) a
>         realm-no-matter-whether-destination-host-is present-or-not
>         report   is an open issue (see #55).
>
>         *Subject:* Re: [Dime] Resolution on action to discuss the need
>         for Realm-Routed-Reports
>
>          
>
>         Ulrich,
>         All,
>
>         The default plan is to go with option 1 in the -02 draft, as
>         that was the proposal that came out of the meeting in London. 
>         RRR reports can be added back in if and when we are convinced
>         of the need. 
>
>         If there are strong objections to this then I will update the
>         -02 draft to reflect all three report types.
>
>         Either way I do not expect we will have agreed to wording on
>         the interaction between the report types when a reacting node
>         has multiple report types, all of which apply to individual
>         requests.  This will need to be addressed in the -03 draft.
>
>         Regards,
>
>         Steve
>
>             My reading of emails prior to the London meeting is
>             different from yours.  I believe we had come to the
>             conclusion that we needed host and realm (with the
>             definition of realm as outlined below).  We were still
>                 E-mail discussions prior to London have clearly
>                 directed towards a report type that requests
>                 throttling of realm routed request messages (i.e. not
>                 containing a destination host) rather than a report
>                 type that requests throttling of messages routed
>                 towards a realm (no matter whether they contain a
>                 *From:*DiME [mailto:[email-masked]] *On Behalf
>                 Of *ext Steve Donovan
>                 *Subject:* [Dime] Resolution on action to discuss the
>                 need for Realm-Routed-Reports
>
>                  
>
>                 All,
>
>                 Ben and I took the action item to discuss the need for
>                 the Realm-Routed-Reports (RRR) report type.
>
>                 As you may recall, the consensus coming out of the
>                 DIME WG meeting in London was to support two report types:
>
>                 - Host -- Impacting requests with a Destination-Host
>                 AVP matching the host in the overload report (with the
>                 host implicitly determined from the Origin-Host AVP of
>                 the answer message carrying the overload report).
>
>                 Destination-Realm AVP matching the realm in the
>                 overload report (with the realm implicitly determine
>                 from the Origin-Realm of the answer message carrying
>                 the overload report).
>
>                 The action Ben and I took was to come back with an
>                 opinion on whether RRR reports should also be supported.
>
>                 My summary of the discussion is that we recommend to
>                 NOT include RRR reports in the current version of the
>                 base DOIC draft. 
>
>                 control enabled by having just the two report types
>                 but the analysis of whether RRR reports are still
>                 needed can occur independent of the base DOIC draft. 
>                 If there is a determination that RRRs are needed in
>                 time to include in the base draft then it can be
>                 considered at that time.
>
>                 will have consensus on this wording prior to the -02
>                 draft being submitted.  To this end, I'll open a new
>                 issue to deal with the need for wording on the
>                 interaction.
>
>                 Regards,
>
>                 Steve
>
>
>
>
>

---

From: Steve Donovan <[email-masked]>
Date: Tue, 25 Mar 2014 16:59:10 -0500

Ulrich,

Please see inline.

Steve

> realm-routed-reports</Ulrich>
SRD> At the time, yes.  This changed in the London meeting and appears
to be changing back now.
> to realm-routed-reports" </Ulrich>
SRD> Ok, I would say it as I typed it.
> #55</Ulrich>
SRD> There was quite a bit of discussion as part of multiple issues.  I
agree there was no discussion tagged with issue #55, but many of these
issues overlap. 
> *//*
SRD> My concern with RRR reports is that they don't provide a consistent
and predictable mechanism for controlling traffic sent to the realm.  If
we support Realm reports that control all traffic sent to the Realm,
then I see limited value in also supporting RRR reports. 
> <Ulrich>What was the technical argument?</Ulrich>
SRD>  There is also a requirement in RFC 7068 to be able to control the
amount of traffic sent to the realm.  The primary use case for Realm
reports is inter domain cases where one domain wants to throttle traffic
coming from another domain without exposing the identity of servers in
the domain.
> solution, so I cannot see where the consensus came from</Ulrich>
SRD> This was discussed, just not in a thread tagged #55.  There was
also significant discussion in the thread on issues #23, #34 adn #57.
> RRR and proposing to remove RRR</Ulrich>
SRD> That doesn't mean there aren't issues. :-)
> <Ulrich> I support option 1</Ulrich>
SRD> Option 1 is the only option I don't support.

---

From: <[email-masked]>
Date: Wed, 26 Mar 2014 06:34:39 +0000

Hi Steve,

In London, we ended up with the following proposal:

- ONLY two report types
- "Host" that applies when destination-host is present in the request.
- "Realm" that applies to any request sent to a realm, except when a destination-host is present in the request AND a "Host" applies for this destination-host.

About renaming "Realm" as "Realm-Routed-Request", no strong issue as soon as the principle above are kept.

The need for realm-based type that would apply to any request (even if a "Host" exists for a destination-host in the request) was challenged and not retained. Ben was supposed to lock you in a room and to convince you that this last report type was not needed.

Lionel

Envoyé depuis mon Sony Xperia SP d'Orange

Steve Donovan <[email-masked]> a écrit :

Let us make sure that we are precise in our definitions of the report types we are discussing.

Host report - Applies when the destination-host AVP is present in the request.
Realm-Routed-Request (RRR) - Applies when there is no destination-host AVP in the request.
Realm - Applies to 100% of requests sent to the realm.

These are the definitions used in our discussions in London and in various places in our email discussions.

Can we please agree to use these definitions going forward so we are all talking about the same thing.

Regards,

Steve

On 3/25/14 10:27 AM, [email-masked]<mailto:[email-masked]> wrote:
Hi Maria Cruz, All,

Regards,

Lionel

De : DiME [mailto:[email-masked]] De la part de Maria Cruz Bartolome
Envoyé : mardi 25 mars 2014 16:21
À : Wiehe, Ulrich (NSN - DE/Munich); ext Steve Donovan; [email-masked]<mailto:[email-masked]>
Objet : Re: [Dime] Resolution on action to discuss the need for Realm-Routed-Reports

Dear all,

Steve,

Ulrich

Ulrich,

Prior to London meeting:

#23 status:
 - Agreement to change the name of existing realm reports to realm-routed-reports (RRR).
<Ulrich>this includes agreement to keep the (newly called) realm-routed-reports</Ulrich>
 - Discussions were ongoing as to the need for both realm reports and RRR reports.
<Ulrich>I would say “…as to the need for realm reports in addition to realm-routed-reports” </Ulrich>

#55 status:
  - Agreement on adding Realm reports based on the definition that realm reports apply to all traffic sent to the realm.
<Ulrich>This is what I’m missing. The issue has been very briefly discussed under #34 without conclusion. There was no discussion under #55</Ulrich>

After London meeting:

#23 status:

#55 status:
  - No change

Summary:

Current status:

#23 status:
 - Change the name to RRR

#55 status:

Summary:

Regards,

Steve
On 3/25/14 6:44 AM, Wiehe, Ulrich (NSN - DE/Munich) wrote:
Steve,
I don’t think we are going backwards (we may be out of synch though)

Ulrich

Steve

I do not agree.

Ulrich

Ulrich,
All,

Regards,

Steve

Regards,

Steve

Ulrich

All,

Regards,

Steve

DiME mailing list

---

From: "TROTTIN, JEAN-JACQUES (JEAN-JACQUES)" <[email-masked]>
Date: Wed, 26 Mar 2014 11:56:29 +0000

Hi

With others, I share Lionel summary on this topic, and the v02 draft should be on this statement. I also agree with  Mcruz, for the meantime to keep the the "realm" report   name as it is in current  draft
Then there can be a ticket about other ways to understand the  realm  report

Best regards

JJacques

De : DiME [mailto:[email-masked]] De la part de [email-masked]
Envoyé : mercredi 26 mars 2014 07:35
À : Maria Cruz Bartolome; Wiehe, Ulrich (NSN - DE/Munich); [email-masked]; Steve Donovan
Objet : Re: [Dime] Resolution on action to discuss the need for Realm-Routed-Reports

Hi Steve,

- ONLY two report types

Lionel

Steve Donovan <[email-masked]<mailto:[email-masked]>> a écrit :

Regards,

Steve

Regards,

Lionel

Dear all,

Steve,

Ulrich

Ulrich,

Prior to London meeting:

#23 status:

#55 status:

After London meeting:

#23 status:

#55 status:
  - No change

Summary:

Current status:

#23 status:
 - Change the name to RRR

#55 status:

Summary:

Regards,

Steve

Ulrich

Steve

I do not agree.

Ulrich

Ulrich,
All,

Regards,

Steve

Regards,

Steve

Ulrich

All,

Regards,

Steve

DiME mailing list

Thank you.

Thank you.

---

From: Steve Donovan <[email-masked]>
Date: Wed, 26 Mar 2014 07:14:57 -0500

Lionel,

Please see inline.

Steve

On 3/26/14 1:34 AM, [email-masked] wrote:
> - ONLY two report types - "Host" that applies when destination-host
> is present in the request. - "Realm" that applies to any request
> sent to a realm, except when a destination-host is present in the
> request AND a "Host" applies for this destination-host.

SRD> Yes, we agreed to two report types, Host and Realm.  The definition
of Realm was all traffic sent to the realm.  Look back at slide 4 in the
slides for the meeting to confirm:

http://tools.ietf.org/agenda/89/slides/slides-89-dime-1.pdf

My reading of the above is consistent with these definitions.  The above
statement also defines the interaction between host and realm reports. 
Restating, the following normative statements would apply:

When determining if a request should be throttled, there are three cases:

- Only a Realm report (based on the definition from the meeting) matches
the message -- In this case the Realm report MUST be used to determine
if the message is throttled.
- Only a Host report matches the message -- In this case the Host report
MUST be used to determine if the message is throttled.
- Both a Realm and Host report match the message -- In this case the
Host report MUST be used to determine if the message is throttled and
throttling based on the Realm report MUST NOT also be applied to the
message.

I'm ok at the moment with this wording, but I don't think we've thought
through the implications of prioritizing Host reports over Realm reports
when both apply.  As such, this is open to change in a future version of
the draft.

> soon as the principle above are kept.

SRD> If we go with your proposal above then there is no name change but
rather a change in the definition of Realm report.

If we go with Ulrich's proposal then we should change the name from
Realm to RRR (or some other name yet to be suggested).

If we go with three reports then we also need to change the name of the
existing Realm report to RRR and redefine Realm to match the above logic.

> 
> The need for realm-based type that would apply to any request (even
> if a "Host" exists for a destination-host in the request) was
> challenged and not retained. Ben was supposed to lock you in a room
> and to convince you that this last report type was not needed.

This is NOT my recollection of the decision and is NOT what is reflected
in the minutes.  This is also NOT what you say above.

Here's the relevant portion of the minutes:

Report types - there was consensus that Host and Realm report types
needed to be retained. Ben suggested that if a node sent a Realm report,
it needed to be an absolute authority for the realm. Dave did not agree
that agents needed to be authoritative and felt that clients should be
able to make their own decisions on conflicting realm reports, which
Lionel disagreed with. Maria Cruz agreed with both proposals because it
would be deployment dependent. Steve said that the draft should provide
guidance that a sender of the realm report should be an authority and
that realm reports should not contradict. It should provide guidance on
what the client should do if does receive different realm reports. Ben
pointed out that, in the case where a realm was sending overload
reports, individual servers could send Reductions of 0% in their reports
to provide more information to clients.

ACTION: Ben and Steve to discuss Realm-Routed-Request and come up with a
proposal on whether to remove or to incorporate.

ACTION: Next version of DOIC will keep Host and Realm and leave
Realm-Routed-Request an open issue.

ACTION: Clarify precedence of the host and realm report types and what
actions to take when they are received.

> Host report - Applies when the destination-host AVP is present in
> the request. Realm-Routed-Request (RRR) - Applies when there is no
> destination-host AVP in the request. Realm - Applies to 100% of
> requests sent to the realm.
>
>> Whatever the name of the realm report type, is there an agreement
>> on the description given above by Maria Cruz and discussed in
>> London?
>>
>>
>>
>> Regards,
>>
>>
>>
>> Lionel
>>
>>
>>
>> *De :*DiME [mailto:[email-masked]] *De la part de* Maria
>> Cruz Bartolome *Envoyé :* mardi 25 mars 2014 16:21 *À :* Wiehe,
>> Ulrich (NSN - DE/Munich); ext Steve Donovan; [email-masked] *Objet
>> :* Re: [Dime] Resolution on action to discuss the need for
>> Realm-Routed-Reports
>>
>>
>>
>> Dear all,
>>
>>
>>
>> Ulrich (NSN - DE/Munich) *Sent:* martes, 25 de marzo de 2014 16:15
>>  *To:* ext Steve Donovan; [email-masked] *Subject:* Re: [Dime]
>> Resolution on action to discuss the need for Realm-Routed-Reports
>>
>>
>>
>> Steve,
>>
>> *From:*ext Steve Donovan [mailto:[email-masked]] *Sent:*
>> Tuesday, March 25, 2014 2:49 PM *To:* Wiehe, Ulrich (NSN -
>> DE/Munich); [email-masked] <mailto:[email-masked]> *Subject:* Re:
>> [Dime] Resolution on action to discuss the need for
>> Realm-Routed-Reports
>>
>>
>>
>> Ulrich,
>>
>> #23 status: - Agreement to change the name of existing realm
>> reports to realm-routed-reports (RRR).
>>
>> <Ulrich>this includes agreement to keep the (newly called)
>> realm-routed-reports</Ulrich> - Discussions were ongoing as to the
>> need for both realm reports and RRR reports.
>>
>> #55 status: - Agreement on adding Realm reports based on the
>> definition that realm reports apply to all traffic sent to the
>> realm.
>>
>> <Ulrich>This is what I’m missing. The issue has been very briefly
>> discussed under #34 without conclusion. There was no discussion
>> under #55</Ulrich>
>>
>>
>> #23 status: - Tentative agreement in London meeting to remove RRR
>> reports.
>>
>> - Ben expressed the strongest concern with this plan.  Steve and
>> Ben took action to discuss and come back with a recommendation.
>>
>> #55 status: - No change
>>
>> Summary: - Tentative consensus reached to move forward with two
>> report types - host and realm, with realm having the new
>> definition. <Ulrich>What was the technical argument?</Ulrich>
>>
>>
>> Current status:
>>
>> #23 status: - Change the name to RRR - Whether or not to remove
>> RRR and revisit later or keep RRR and revisit later is an open
>> issue.
>>
>> #55 status: - My opinion is that we have at least rough consensus
>> on the need to support realm reports.  Others might have a
>> different opinion.
>>
>> <Ulrich> There was no comment posted to issue #55, also no
>> proposed solution, so I cannot see where the consensus came
>> from</Ulrich>
>>
>>
>>
>> Summary: - I believe we have three options:
>>
>> 1) Support host and RRR reports 2) Support host and Realm reports
>> -- This was the tentative plan coming out of the London meeting
>>
>> < Ulrich> There is not even an issue number identifying problems
>> with RRR and proposing to remove RRR</Ulrich>
>>
>>
>> *From:*ext Steve Donovan [mailto:[email-masked]] *Sent:*
>> Monday, March 24, 2014 7:38 PM *To:* Wiehe, Ulrich (NSN -
>> DE/Munich); [email-masked] <mailto:[email-masked]> *Subject:* Re:
>> [Dime] Resolution on action to discuss the need for
>> Realm-Routed-Reports
>>
>>
>>
>> Steve Donovan *Sent:* Monday, March 24, 2014 2:57 PM *To:*
>> [email-masked] <mailto:[email-masked]> *Subject:* Re: [Dime]
>> Resolution on action to discuss the need for Realm-Routed-Reports
>>
>>
>>
>> Ulrich, All,
>>
>> report type that requests throttling of realm routed request
>> messages (i.e. not containing a destination host) rather than a
>> report type that requests throttling of messages routed towards a
>> realm (no matter whether they contain a destination host or not).
>>
>>
>>
>>
>> Ulrich
>>
>>
>>
>> Steve Donovan *Sent:* Friday, March 21, 2014 3:33 PM *To:*
>> [email-masked] <mailto:[email-masked]> *Subject:* [Dime] Resolution
>> on action to discuss the need for Realm-Routed-Reports
>>
>>
>>
>> All,
>>
>> As you may recall, the consensus coming out of the DIME WG meeting
>> in London was to support two report types:
>>
>> - Host -- Impacting requests with a Destination-Host AVP matching
>> the host in the overload report (with the host implicitly
>> determined from the Origin-Host AVP of the answer message carrying
>> the overload report).
>>
>> My summary of the discussion is that we recommend to NOT include
>> RRR reports in the current version of the base DOIC draft.
>>
>> enabled by having just the two report types but the analysis of
>> whether RRR reports are still needed can occur independent of the
>> base DOIC draft.  If there is a determination that RRRs are needed
>> in time to include in the base draft then it can be considered at
>> that time.
>>
>> - Resolution to issue #23 is to remove RRR reports from the
>> document. - Resolution to issue #55 is to add Realm reports
>> (actually to redefine them per the above definition). - Resolution
>> to issue #57 is that it no longer applies (as it deals with RRRs).
>>
>> host and the realm reports.  I don't expect we will have consensus
>> on this wording prior to the -02 draft being submitted.  To this
>> end, I'll open a new issue to deal with the need for wording on
>> the interaction.
>>
>> Regards,
>>
>> Steve
>>
>>
>>
>>
>>
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.

---

From: Steve Donovan <[email-masked]>
Date: Wed, 26 Mar 2014 07:35:21 -0500

I disagree with keeping the name Realm.  We had consensus on the name
change a long time ago. 

In addition, Lionel's email is not internally consistent.  I have
responded with proposed clarifications.

Steve

On 3/26/14 6:56 AM, TROTTIN, JEAN-JACQUES (JEAN-JACQUES) wrote:
>
> Hi
>
>  
>
> With others, I share Lionel summary on this topic, and the v02 draft
> should be on this statement. I also agree with  Mcruz, for the
> meantime to keep the the "realm" report   name as it is in current  draft
>
> *De :*DiME [mailto:[email-masked]] *De la part de*
> [email-masked]
> *Envoyé :* mercredi 26 mars 2014 07:35
> *À :* Maria Cruz Bartolome; Wiehe, Ulrich (NSN - DE/Munich);
> [email-masked]; Steve Donovan
> Steve Donovan <[email-masked] <mailto:[email-masked]>> a écrit :
>  
>
>     on the description given above by Maria Cruz and discussed in London?
>
>      
>
>     Regards,
>
>      
>
>     Lionel
>
>      
>
>     Cruz Bartolome
>     *À :* Wiehe, Ulrich (NSN - DE/Munich); ext Steve Donovan;
>     [email-masked] <mailto:[email-masked]>
>     *To:* ext Steve Donovan; [email-masked] <mailto:[email-masked]>
>     realm-routed-reports</Ulrich>
>     <Ulrich>I would say "...as to the need for realm reports in
>     addition to realm-routed-reports" </Ulrich>
>
>
>
>     #55 status:
>       - Tentative consensus reached to move forward with two report
>     types - host and realm, with realm having the new definition.
>       - My opinion is that we have at least rough consensus on the
>     need to support realm reports.  Others might have a different opinion.
>
>         option in our discussions, both on the list (I thought), and
>         in the meeting.
>
>         I believe that we had come to rough consensus on the need for
>         a realm report and the only remaining issue was whether we
>         also included the RRR report type.
>
>         related to the report types open and attempt to resolve them
>         in the -03 draft.
>
>         Steve
>
>             support of report type 1 (this has been called relam
>             report but people argued it should better be called realm
>             routed request report).
>
>              
>
>             Whether or not we need in addition to type 0 and type 1
>             (or as a replacement of type 1) a
>             Unless we conclude on #55, or decide to re-open #34,
>             option 3) is what should go in the -02 draft.
>
>              
>
>              
>
>             Ulrich
>
>              
>
>             *Subject:* Re: [Dime] Resolution on action to discuss the
>             The default plan is to go with option 1 in the -02 draft,
>             as that was the proposal that came out of the meeting in
>             London.  RRR reports can be added back in if and when we
>             are convinced of the need. 
>
>             If there are strong objections to this then I will update
>             the -02 draft to reflect all three report types.
>
>             Either way I do not expect we will have agreed to wording
>             on the interaction between the report types when a
>             reacting node has multiple report types, all of which
>             apply to individual requests.  This will need to be
>             addressed in the -03 draft.
>
>             Regards,
>
>             Steve
>
>                 The discussion should be captured in the minutes to
>                 the meeting.  I wasn't able to find them posted yet.
>
>                     throttling of realm routed request messages (i.e.
>                     not containing a destination host) rather than a
>                     report type that requests throttling of messages
>                     routed towards a realm (no matter whether they
>                     *From:*DiME [mailto:[email-masked]] *On
>                     Behalf Of *ext Steve Donovan
>                     *Subject:* [Dime] Resolution on action to discuss
>                     the need for Realm-Routed-Reports
>
>                      
>
>                     All,
>
>                     Ben and I took the action item to discuss the need
>                     for the Realm-Routed-Reports (RRR) report type.
>
>                     - Host -- Impacting requests with a
>                     Destination-Host AVP matching the host in the
>                     overload report (with the host implicitly
>                     determined from the Origin-Host AVP of the answer
>                     overload report (with the realm implicitly
>                     determine from the Origin-Realm of the answer
>                     My summary of the discussion is that we recommend
>                     to NOT include RRR reports in the current version
>                     of the base DOIC draft. 
>
>                     We still have some concerns with the granularity
>                     of control enabled by having just the two report
>                     types but the analysis of whether RRR reports are
>                     still needed can occur independent of the base
>                     DOIC draft.  If there is a determination that RRRs
>                     are needed in time to include in the base draft
>                     then it can be considered at that time.
>
>                     There is also need for text describing the
>                     interaction between host and the realm reports.  I
>                     don't expect we will have consensus on this
>                     wording prior to the -02 draft being submitted. 
>                     To this end, I'll open a new issue to deal with

---

From: <[email-masked]>
Date: Wed, 26 Mar 2014 13:15:59 +0000

- Only a Realm report (based on the definition from the meeting) matches the message -- In this case the Realm report MUST be used to determine if the message is throttled.
- Only a Host report matches the message -- In this case the Host report MUST be used to determine if the message is throttled.
- Both a Realm and Host report match the message -- In this case the Host report MUST be used to determine if the message is throttled and throttling based on the Realm report MUST NOT also be applied to the message.

I'm ok at the moment with this wording, but I don't think we've thought through the implications of prioritizing Host reports over Realm reports when both apply.  As such, this is open to change in a future version of the draft.

[LM] OK

      > About renaming "Realm" as "Realm-Routed-Request", no strong
      issue as

      > soon as the principle above are kept.

SRD> If we go with your proposal above then there is no name change but rather a change in the definition of Realm report.

[LM] don't think that the current definition needs to be changed. However the behavior of the reacting node should be clarified when both Host and Realm report type are applicable to a single message.

If we go with Ulrich's proposal then we should change the name from Realm to RRR (or some other name yet to be suggested).

If we go with three reports then we also need to change the name of the existing Realm report to RRR and redefine Realm to match the above logic.

[LM] let's play with only two for now.

      > and to convince you that this last report type was not
      needed.

This is NOT my recollection of the decision and is NOT what is reflected in the minutes.  This is also NOT what you say above.

Report types - there was consensus that Host and Realm report types needed to be retained. Ben suggested that if a node sent a Realm report, it needed to be an absolute authority for the realm. Dave did not agree that agents needed to be authoritative and felt that clients should be able to make their own decisions on conflicting realm reports, which Lionel disagreed with. Maria Cruz agreed with both proposals because it would be deployment dependent. Steve said that the draft should provide guidance that a sender of the realm report should be an authority and that realm reports should not contradict. It should provide guidance on what the client should do if does receive different realm reports. Ben pointed out that, in the case where a realm was sending overload reports, individual servers could send Reductions of 0% in their reports to provide more information to clients.

ACTION: Ben and Steve to discuss Realm-Routed-Request and come up with a proposal on whether to remove or to incorporate.

ACTION: Next version of DOIC will keep Host and Realm and leave Realm-Routed-Request an open issue.

ACTION: Clarify precedence of the host and realm report types and what actions to take when they are received.

[LM] ok

      > Steve Donovan <[email-masked]><mailto:[email-masked]> a écrit :

      > Let us make sure that we are precise in our definitions of
      the

      > report types we are discussing.

      > Can we please agree to use these definitions going forward so
      we are

      > all talking about the same thing.

      >> And I agree with this statement. But I'm not sure that
      this is the

      >> case discussed by Ulrich.

      >> *De :*DiME [mailto:[email-masked]] *De la part de*
      Maria

      >> Ulrich (NSN - DE/Munich); ext Steve Donovan;
      [email-masked]<mailto:[email-masked]> *Objet

      >> *From:*DiME [mailto:[email-masked]] *On Behalf Of
      *Wiehe,

      >>  *To:* ext Steve Donovan; [email-masked]<mailto:[email-masked]> *Subject:* Re:
      [Dime]

      >> *From:*ext Steve Donovan
      [mailto:[email-masked]] *Sent:*

      >> DE/Munich); [email-masked]<mailto:[email-masked]> <mailto:[email-masked]><mailto:[email-masked]>

      >> I mean going backwards from where I thought we were after
      the

      >> London meeting.

      >> <Ulrich>I would say "...as to the need for realm
      reports in addition

      >> to realm-routed-reports" </Ulrich>

      >> I don't think we are going backwards (we may be out of
      synch

      >> though)

      >> *From:*ext Steve Donovan
      [mailto:[email-masked]] *Sent:*

      >> DE/Munich); [email-masked]<mailto:[email-masked]> <mailto:[email-masked]><mailto:[email-masked]>

      >> 3) support report type 0 (this is called host report) and
      support

      >> Whether or not we need in addition to type 0 and type 1
      (or as a

      >> There are a lot of open questions  with regard to #55 and
      I have

      >> not seen a conclusion.

      >> Where I have seen a conclusion is issue #34 and that is
      inline

      >> with option 3).

      >> Unless we conclude on #55, or decide to re-open #34,
      option 3) is

      >> what should go in the -02 draft.

      >> *From:*DiME [mailto:[email-masked]] *On Behalf Of
      *ext

      >> [email-masked]<mailto:[email-masked]> <mailto:[email-masked]><mailto:[email-masked]> *Subject:* Re:
      [Dime]

      >> The default plan is to go with option 1 in the -02 draft,
      as that

      >> If there are strong objections to this then I will update
      the -02

      >> draft to reflect all three report types.

      >> I plan to make these updates Wednesday morning, Dallas,
      Texas

      >> time.

      >> Either way I do not expect we will have agreed to wording
      on the

      meeting.

      >> I wasn't able to find them posted yet.

      >> My reading of emails prior to the London meeting is
      different from

      >> We were still discussing the need for
      Realm-Routed-Request

      >> Can you please summarize the technical reasons that led
      to the

      >> London agreement.

      >> E-mail discussions prior to London have clearly directed
      towards a

      >> *From:*DiME [mailto:[email-masked]] *On Behalf Of
      *ext

      >> [email-masked]<mailto:[email-masked]> <mailto:[email-masked]><mailto:[email-masked]> *Subject:*
      [Dime] Resolution

      >> Ben and I took the action item to discuss the need for
      the

      >> - Host -- Impacting requests with a Destination-Host AVP
      matching

      >> - Realm -- Impacting 100% of the requests with a
      Destination-Realm

      >> The action Ben and I took was to come back with an
      opinion on

      >> My summary of the discussion is that we recommend to NOT
      include

      >> We still have some concerns with the granularity of
      control

      >> There is also need for text describing the interaction
      between

      >> host and the realm reports.  I don't expect we will have
      consensus

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

>> pas etre diffuses,
      exploites ou copies sans autorisation. Si vous

      > avez recu ce message par erreur, veuillez le signaler a
      l'expediteur

---

From: Steve Donovan <[email-masked]>
Date: Wed, 26 Mar 2014 09:30:45 -0500

Lionel,

Please see comments inline.

Regards,

Steve

On 3/26/14 8:15 AM, [email-masked] wrote:
> - Only a Realm report (based on the definition from the meeting)
> matches the message -- In this case the Realm report MUST be used to
> determine if the message is throttled.
> - Only a Host report matches the message -- In this case the Host
> report MUST be used to determine if the message is throttled.
> I'm ok at the moment with this wording, but I don't think we've
> thought through the implications of prioritizing Host reports over
> Realm reports when both apply.  As such, this is open to change in a
> future version of the draft.
>
> */[LM] OK/*
>
>
SRD> Just to be 100% clear on the first bullet above.  This, I believe,
is where we have confusion and disagreement on this topic.

My proposal is that the Realm report effects 100% of messages that
contain a Realm AVP that matches the Realm report.

The other definition is that the report effects only messages that match
the Realm in the report AND do not have a Destination-Host AVP. 

These are very different definitions and is why it is important to
define what is meant by Realm reports.
> SRD> If we go with your proposal above then there is no name change
> but rather a change in the definition of Realm report.
>
> */[LM] don't think that the current definition needs to be changed.
> However the behavior of the reacting node should be clarified when
> both Host and Realm report type are applicable to a single message./*
>
>
SRD> See above.  Plus, the -01 draft contains BOTH definitions, so it
needs to be updated.
> If we go with three reports then we also need to change the name of
> the existing Realm report to RRR and redefine Realm to match the above
> logic.
>
> */[LM] let's play with only two for now./*
>
> */ /*
>
> > 
>
>       > The need for realm-based type that would apply to any request
>
>       (even
>
>       > challenged and not retained. Ben was supposed to lock you in
>
>       a room
>
>       > and to convince you that this last report type was not
>
>       needed.
>
> This is NOT my recollection of the decision and is NOT what is
> reflected in the minutes.  This is also NOT what you say above.
>
> needed to be retained. Ben suggested that if a node sent a Realm
> report, it needed to be an absolute authority for the realm. Dave did
> not agree that agents needed to be authoritative and felt that clients
> should be able to make their own decisions on conflicting realm
> reports, which Lionel disagreed with. Maria Cruz agreed with both
> proposals because it would be deployment dependent. Steve said that
> the draft should provide guidance that a sender of the realm report
> should be an authority and that realm reports should not contradict.
> It should provide guidance on what the client should do if does
> receive different realm reports. Ben pointed out that, in the case
> where a realm was sending overload reports, individual servers could
> send Reductions of 0% in their reports to provide more information to
> clients.
>
>
> ACTION: Ben and Steve to discuss Realm-Routed-Request and come up with
> a proposal on whether to remove or to incorporate.
>
> */[LM] ok/*
>       > Steve Donovan <[email-masked]>
> <mailto:[email-masked]> a écrit :
>
>       >
>
>       > Host report - Applies when the destination-host AVP is
>
>       present in
>
>       > the request. Realm-Routed-Request (RRR) - Applies when there
>
>       is no
>
>       > destination-host AVP in the request. Realm - Applies to 100%
>
>       of
>
>       > These are the definitions used in our discussions in London
>
>       and in
>
>       >> /Host applies when Destination_host is present, and then
>
>       it takes
>
>       >> precedence over Realm. If both are present, only Host is
>
>       applied./
>
>       >>
>
>       >> Whatever the name of the realm report type, is there an
>
>       agreement
>
>       >> on the description given above by Maria Cruz and
>
>       discussed in
>
>       >> London?
>
>       >>
>
>       >>
>
>       >>
>
>       >> Regards,
>
>       >>
>
>       >>
>
>       >>
>
>       >> Lionel
>
>       >>
>
>       >>
>
>       >>
>
>       >> Cruz Bartolome *Envoyé :* mardi 25 mars 2014 16:21 *À :*
>
>       Wiehe,
>
>       [email-masked] <mailto:[email-masked]> *Objet
>
>       >> :* Re: [Dime] Resolution on action to discuss the need
>
>       for
>
>       >> Realm-Routed-Reports
>
>       >>
>
>       >>
>
>       >>
>
>       >> Dear all,
>
>       >>
>
>       >>
>
>       >>
>
>       >> Ulrich (NSN - DE/Munich) *Sent:* martes, 25 de marzo de
>
>       2014 16:15
>
> <mailto:[email-masked]> *Subject:* Re:
>
>       [Dime]
>
>       >> Resolution on action to discuss the need for
>
>       Realm-Routed-Reports
>
>       >>
>
>       >>
>
>       >>
>
>       >> Steve,
>
>       >>
>
>       >> Tuesday, March 25, 2014 2:49 PM *To:* Wiehe, Ulrich (NSN
>
>       -
>
>       >> DE/Munich); [email-masked] <mailto:[email-masked]>
> <mailto:[email-masked]> <mailto:[email-masked]>
>
>       *Subject:* Re:
>
>       >> #23 status: - Agreement to change the name of existing
>
>       realm
>
>       >> <Ulrich>this includes agreement to keep the (newly
>
>       called)
>
>       >> realm-routed-reports</Ulrich> - Discussions were
>
>       ongoing as to the
>
>       >> #55 status: - Agreement on adding Realm reports based on
>
>       the
>
>       >> definition that realm reports apply to all traffic sent
>
>       to the
>
>       >> realm.
>
>       >>
>
>       >> <Ulrich>This is what I'm missing. The issue has
>
>       been very briefly
>
>       >> discussed under #34 without conclusion. There was no
>
>       discussion
>
>       >> under #55</Ulrich>
>
>       >>
>
>       >>
>
>       >> - Limited discussion on the interaction between the new
>
>       realm
>
>       >> #23 status: - Tentative agreement in London meeting to
>
>       remove RRR
>
>       >> reports.
>
>       >>
>
>       >> <Ulrich>What was the technical
>
>       argument?</Ulrich>
>
>       >>
>
>       >>
>
>       >> - Ben expressed the strongest concern with this plan. 
>
>       Steve and
>
>       >> Ben took action to discuss and come back with a
>
>       recommendation.
>
>       >>
>
>       >> #55 status: - No change
>
>       >>
>
>       >> Summary: - Tentative consensus reached to move forward
>
>       with two
>
>       >> definition. <Ulrich>What was the technical
>
>       argument?</Ulrich>
>
>       >>
>
>       >>
>
>       >> Current status:
>
>       >>
>
>       >> #23 status: - Change the name to RRR - Whether or not to
>
>       remove
>
>       >> RRR and revisit later or keep RRR and revisit later is an
>
>       open
>
>       >> issue.
>
>       >>
>
>       >> #55 status: - My opinion is that we have at least rough
>
>       consensus
>
>       >> on the need to support realm reports.  Others might have
>
>       a
>
>       >> different opinion.
>
>       >>
>
>       >> <Ulrich> There was no comment posted to issue #55,
>
>       also no
>
>       >> proposed solution, so I cannot see where the consensus
>
>       came
>
>       >> from</Ulrich>
>
>       >>
>
>       >>
>
>       >>
>
>       >> 1) Support host and RRR reports 2) Support host and Realm
>
>       reports
>
>       >> -- This was the tentative plan coming out of the London
>
>       meeting
>
>       >>
>
>       >> < Ulrich> There is not even an issue number
>
>       identifying problems
>
>       >> On 3/25/14 6:44 AM, Wiehe, Ulrich (NSN - DE/Munich)
>
>       wrote:
>
>       >>
>
>       >> Steve,
>
>       >>
>
>       >> DE/Munich); [email-masked] <mailto:[email-masked]>
> <mailto:[email-masked]> <mailto:[email-masked]>
>
>       *Subject:* Re:
>
>       >> I did not include option three because we had moved past
>
>       that
>
>       >> option in our discussions, both on the list (I thought),
>
>       and in
>
>       >> the meeting.
>
>       >>
>
>       >> I believe that we had come to rough consensus on the need
>
>       for a
>
>       >> realm report and the only remaining issue was whether we
>
>       also
>
>       >> At this point, the only option is to leave all of the
>
>       issues
>
>       >> related to the report types open and attempt to resolve
>
>       them in
>
>       >> the -03 draft.
>
>       >>
>
>       >> Steve
>
>       >>
>
>       >> On 3/24/14 11:13 AM, Wiehe, Ulrich (NSN - DE/Munich)
>
>       wrote:
>
>       >>
>
>       >> Steve,
>
>       >>
>
>       >>
>
>       >>
>
>       >> I do not agree.
>
>       >>
>
>       >>
>
>       >>
>
>       >> of report type 1 (this has been called relam report but
>
>       people
>
>       >> argued it should better be called realm routed request
>
>       report).
>
>       >>
>
>       >>
>
>       >>
>
>       >> realm-no-matter-whether-destination-host-is
>
>       present-or-not report
>
>       >> Steve Donovan *Sent:* Monday, March 24, 2014 2:57 PM
>
>       *To:*
>
>       >> [email-masked] <mailto:[email-masked]> <mailto:[email-masked]>
> <mailto:[email-masked]> *Subject:* Re:
>
>       [Dime]
>
>       >> Resolution on action to discuss the need for
>
>       Realm-Routed-Reports
>
>       >>
>
>       >>
>
>       >>
>
>       >> Ulrich, All,
>
>       >>
>
>       >> 1) Support Host and Realm as proposed below, removing RRR
>
>       reports.
>
>       >> was the proposal that came out of the meeting in London. 
>
>       RRR
>
>       >> reports can be added back in if and when we are convinced
>
>       of the
>
>       >> need.
>
>       >>
>
>       >> interaction between the report types when a reacting node
>
>       has
>
>       >> multiple report types, all of which apply to individual
>
>       requests.
>
>       >> Jouni, Lionel, what is the status of the minutes for the
>
>       meeting?
>
>       >>
>
>       >> yours.  I believe we had come to the conclusion that we
>
>       needed
>
>       >> host and realm (with the definition of realm as outlined
>
>       below).
>
>       >> On 3/21/14 10:09 AM, Wiehe, Ulrich (NSN - DE/Munich)
>
>       wrote:
>
>       >>
>
>       >> Steve,
>
>       >>
>
>       >>
>
>       >>
>
>       >> report type that requests throttling of realm routed
>
>       request
>
>       >> messages (i.e. not containing a destination host) rather
>
>       than a
>
>       >> report type that requests throttling of messages routed
>
>       towards a
>
>       >> realm (no matter whether they contain a destination host
>
>       or not).
>
>       >>
>
>       >>
>
>       >>
>
>       >>
>
>       >> Ulrich
>
>       >>
>
>       >>
>
>       >>
>
>       >> Steve Donovan *Sent:* Friday, March 21, 2014 3:33 PM
>
>       *To:*
>
>       >> [email-masked] <mailto:[email-masked]> <mailto:[email-masked]>
> <mailto:[email-masked]> *Subject:*
>
>       [Dime] Resolution
>
>       >> As you may recall, the consensus coming out of the DIME
>
>       WG meeting
>
>       >> determined from the Origin-Host AVP of the answer message
>
>       carrying
>
>       >> the overload report).
>
>       >>
>
>       >> AVP matching the realm in the overload report (with the
>
>       realm
>
>       >> implicitly determine from the Origin-Realm of the answer
>
>       message
>
>       >> RRR reports in the current version of the base DOIC
>
>       draft.
>
>       >>
>
>       >> enabled by having just the two report types but the
>
>       analysis of
>
>       >> whether RRR reports are still needed can occur
>
>       independent of the
>
>       >> base DOIC draft.  If there is a determination that RRRs
>
>       are needed
>
>       >> in time to include in the base draft then it can be
>
>       considered at
>
>       >> that time.
>
>       >>
>
>       >> - Resolution to issue #23 is to remove RRR reports from
>
>       the
>
>       >> document. - Resolution to issue #55 is to add Realm
>
>       reports
>
>       >> (actually to redefine them per the above definition). -
>
>       Resolution
>
>       >> to issue #57 is that it no longer applies (as it deals
>
>       with RRRs).
>
>       >>
>
>       >> on this wording prior to the -02 draft being submitted. 
>
>       To this
>
>       >> end, I'll open a new issue to deal with the need for
>
>       wording on
>
>       >> the interaction.
>
>       >>
>
>       >> Regards,
>
>       >>
>
>       >> Steve
>
>       >>
>
>       >>
>
>       >>
>
>       >>
>
>       >>
>
>       >> [email-masked] <mailto:[email-masked]> <mailto:[email-masked]>
> <mailto:[email-masked]>
>
>       >>
>
> <https://www.ietf.org/mailman/listinfo/dime>
>
>       >>
>
>       >>
>
>       >>
>
>       >>
>
>       >>
>
>       >>
>
>       >>
>
>       >>
>
>       >> 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.
>
>       >
>
>       >
>
> > pas etre diffuses, exploites ou
>
>       copies sans autorisation. Si vous
>
>       > electroniques etant susceptibles d'alteration, Orange decline
>
>       toute
>
>       > responsabilite si ce message a ete altere, deforme ou
>
>       falsifie.
>
>       > Merci.
>
>       >
>
>       > 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: <[email-masked]>
Date: Wed, 26 Mar 2014 15:21:13 +0000

I confirm that we agree:
Realm: for all the messages towards a given relam (with or without destination)
Host: for all the messages towards a given diestination-host
Realm + Host: only host apply when the given destination host is in the message.

Lionel

De : Steve Donovan [mailto:[email-masked]]
Envoyé : mercredi 26 mars 2014 15:31
À : MORAND Lionel IMT/OLN; Maria Cruz Bartolome; Wiehe, Ulrich (NSN - DE/Munich); [email-masked]
Objet : Re: [Dime] Resolution on action to discuss the need for Realm-Routed-Reports

Lionel,

Regards,

Steve
On 3/26/14 8:15 AM, [email-masked]<mailto:[email-masked]> wrote:
When determining if a request should be throttled, there are three cases:

[LM] OK

SRD> Just to be 100% clear on the first bullet above.  This, I believe, is where we have confusion and disagreement on this topic.

My proposal is that the Realm report effects 100% of messages that contain a Realm AVP that matches the Realm report.

The other definition is that the report effects only messages that match the Realm in the report AND do not have a Destination-Host AVP.

These are very different definitions and is why it is important to define what is meant by Realm reports.

      issue as

SRD> See above.  Plus, the -01 draft contains BOTH definitions, so it needs to be updated.

      (even

      a room

      needed.

[LM] ok

      the

      present in

      is no

      of

      and in

      we are

      it takes

      applied./

      this is the

      agreement

      discussed in

      Maria

      Wiehe,

      for

      *Wiehe,

      2014 16:15

      [Dime]

      Realm-Routed-Reports

      -

      the

      realm

      called)

      ongoing as to the

      reports in addition

      the

      to the

      been very briefly

      discussion

      realm

      remove RRR

      argument?</Ulrich>

      Steve and

      recommendation.

      with two

      argument?</Ulrich>

      remove

      open

      consensus

      a

      also no

      came

      reports

      meeting

      identifying problems

      wrote:

      synch

      that

      and in

      for a

      also

      issues

      them in

      wrote:

      support

      people

      report).

      (or as a

      present-or-not report

      I have

      inline

      option 3) is

      *ext

      *To:*

      [Dime]

      Realm-Routed-Reports

      reports.

      as that

      RRR

      of the

      the -02

      Texas

      on the

      has

      requests.

      meeting.

      meeting?

      different from

      needed

      below).

      Realm-Routed-Request

      wrote:

      to the

      towards a

      request

      than a

      towards a

      or not).

      *ext

      *To:*

      [Dime] Resolution

      the

      WG meeting

      matching

      carrying

      Destination-Realm

      realm

      message

      opinion on

      include

      draft.

      control

      analysis of

      independent of the

      are needed

      considered at

      the

      reports

      Resolution

      with RRRs).

      between

      consensus

      To this

      wording on

      Les

      Orange

      deforme

      or

      should

      If you

      sender and

      altered,

      modified, changed

      l'expediteur

      toute

      falsifie.

      should not

      have

      delete

      Orange

      or

Thank you.