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

[Steve Donovan <[e-mail]>]

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]
> *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
>
>  
>