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

[Steve Donovan <[e-mail]>]

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
>
> Then there can be a ticket about other ways to understand the  realm
>  report
>
>  
>
> Best regards
>
>  
>
> JJacques
>
>  
>
>  
>
> *De :*DiME [mailto:[e-mail]] *De la part de*
> [e-mail]
> *Envoyé :* mercredi 26 mars 2014 07:35
> *À :* Maria Cruz Bartolome; Wiehe, Ulrich (NSN - DE/Munich);
> [e-mail]; Steve Donovan
> *Objet :* Re: [Dime] Resolution on action to discuss the need for
> Realm-Routed-Reports
>
>  
>
> 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 <[e-mail] <mailto:[e-mail]>> a écrit :
>  
>
> 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, [e-mail]
> <mailto:[e-mail]> wrote:
>
>     Hi Maria Cruz, All,
>
>      
>
>     In the previous mail, you 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./
>
>      
>
>     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:[e-mail]] *De la part de* Maria
>     Cruz Bartolome
>     *Envoyé :* mardi 25 mars 2014 16:21
>     *À :* Wiehe, Ulrich (NSN - DE/Munich); ext Steve Donovan;
>     [e-mail] <mailto:[e-mail]>
>     *Objet :* Re: [Dime] Resolution on action to discuss the need for
>     Realm-Routed-Reports
>
>      
>
>     Dear all,
>
>      
>
>     I support option 1 a well
>
>     Cheers
>
>     /MCruz
>
>      
>
>     *From:*DiME [mailto:[e-mail]] *On Behalf Of *Wiehe,
>     Ulrich (NSN - DE/Munich)
>     *Sent:* martes, 25 de marzo de 2014 16:15
>     *To:* ext Steve Donovan; [e-mail] <mailto:[e-mail]>
>     *Subject:* Re: [Dime] Resolution on action to discuss the need for
>     Realm-Routed-Reports
>
>      
>
>     Steve,
>
>     Thank you for this summary.
>
>     Please see inline.
>
>      
>
>     Ulrich
>
>      
>
>     *From:*ext Steve Donovan [mailto:[e-mail]]
>     *Sent:* Tuesday, March 25, 2014 2:49 PM
>     *To:* Wiehe, Ulrich (NSN - DE/Munich); [e-mail]
>     <mailto:[e-mail]>
>     *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.
>
>     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).
>
>     <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:
>       - 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>
>
>
>        3) Support host, RRR and Realm reports
>
>     <Ulrich> I support option 1</Ulrich>
>
>
>     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)
>
>          
>
>         Can you please summarize the status of #23 and #55.
>
>          
>
>         Ulrich
>
>          
>
>          
>
>         *From:*ext Steve Donovan [mailto:[e-mail]]
>         *Sent:* Monday, March 24, 2014 7:38 PM
>         *To:* Wiehe, Ulrich (NSN - DE/Munich); [e-mail]
>         <mailto:[e-mail]>
>         *Subject:* Re: [Dime] Resolution on action to discuss the need
>         for Realm-Routed-Reports
>
>          
>
>         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:
>
>             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:[e-mail]] *On Behalf Of
>             *ext Steve Donovan
>             *Sent:* Monday, March 24, 2014 2:57 PM
>             *To:* [e-mail] <mailto:[e-mail]>
>             *Subject:* Re: [Dime] Resolution on action to discuss the
>             need for Realm-Routed-Reports
>
>              
>
>             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:
>
>                 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:
>
>                     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:[e-mail]] *On
>                     Behalf Of *ext Steve Donovan
>                     *Sent:* Friday, March 21, 2014 3:33 PM
>                     *To:* [e-mail] <mailto:[e-mail]>
>                     *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.
>
>                     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
>
>
>
>
>                 _______________________________________________
>
>                 DiME mailing list
>
>                 [e-mail] <mailto:[e-mail]>
>
>                 https://www.ietf.org/mailman/listinfo/dime
>
>              
>
>          
>
>      
>
>     _________________________________________________________________________________________________________________________
>
>      
>
>     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.
>
>
> _______________________________________________
> DiME mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dime