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

Steve Donovan <srdonovan@usdonovans.com> Tue, 25 March 2014 20:46 UTC

Return-Path: <srdonovan@usdonovans.com>
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6F2601A0215 for <dime@ietfa.amsl.com>; Tue, 25 Mar 2014 13:46:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.12
X-Spam-Level:
X-Spam-Status: No, score=-1.12 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_NEUTRAL=0.779] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YHO_w3Eeh_Mo for <dime@ietfa.amsl.com>; Tue, 25 Mar 2014 13:46:00 -0700 (PDT)
Received: from biz131.inmotionhosting.com (biz131.inmotionhosting.com [23.235.209.16]) by ietfa.amsl.com (Postfix) with ESMTP id 595B41A0225 for <dime@ietf.org>; Tue, 25 Mar 2014 13:46:00 -0700 (PDT)
Received: from cpe-76-187-100-94.tx.res.rr.com ([76.187.100.94]:59346 helo=SDmac.local) by biz131.inmotionhosting.com with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.82) (envelope-from <srdonovan@usdonovans.com>) id 1WSUPZ-0003et-Hp; Tue, 25 Mar 2014 09:41:20 -0700
Message-ID: <5331B195.9020402@usdonovans.com>
Date: Tue, 25 Mar 2014 11:40:53 -0500
From: Steve Donovan <srdonovan@usdonovans.com>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.4.0
MIME-Version: 1.0
To: lionel.morand@orange.com, Maria Cruz Bartolome <maria.cruz.bartolome@ericsson.com>, "Wiehe, Ulrich (NSN - DE/Munich)" <ulrich.wiehe@nsn.com>, "dime@ietf.org" <dime@ietf.org>
References: <532C4D98.7040303@usdonovans.com> <5BCBA1FC2B7F0B4C9D935572D9000668151C98A7@DEMUMBX014.nsn-intra.net> <532CA99F.4070409@usdonovans.com> <53303991.6060307@usdonovans.com> <5BCBA1FC2B7F0B4C9D935572D9000668151D1E15@DEMUMBX014.nsn-intra.net> <53307B7C.4000200@usdonovans.com> <5BCBA1FC2B7F0B4C9D935572D9000668151D2197@DEMUMBX014.nsn-intra.net> <5331895D.5050500@usdonovans.com> <5BCBA1FC2B7F0B4C9D935572D9000668151D2299@DEMUMBX014.nsn-intra.net> <087A34937E64E74E848732CFF8354B92097A0844@ESESSMB101.ericsson.se> <6076_1395761224_5331A048_6076_6681_1_6B7134B31289DC4FAF731D844122B36E51AC99@PEXCVZYM13.corporate.adroot.infra.ftgroup>
In-Reply-To: <6076_1395761224_5331A048_6076_6681_1_6B7134B31289DC4FAF731D844122B36E51AC99@PEXCVZYM13.corporate.adroot.infra.ftgroup>
Content-Type: multipart/alternative; boundary="------------010206070107030704060206"
X-OutGoing-Spam-Status: No, score=-2.9
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - biz131.inmotionhosting.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - usdonovans.com
X-Get-Message-Sender-Via: biz131.inmotionhosting.com: authenticated_id: srdonovan@usdonovans.com
Archived-At: http://mailarchive.ietf.org/arch/msg/dime/oALznxKvYf26-9Xc2yg45Mt4k-M
Subject: Re: [Dime] Resolution on action to discuss the need for Realm-Routed-Reports
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Diameter Maintanence and Extentions Working Group <dime.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dime>, <mailto:dime-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dime/>
List-Post: <mailto:dime@ietf.org>
List-Help: <mailto:dime-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dime>, <mailto:dime-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 25 Mar 2014 20:46:06 -0000

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, lionel.morand@orange.com 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:dime-bounces@ietf.org] *De la part de* Maria Cruz
> Bartolome
> *Envoyé :* mardi 25 mars 2014 16:21
> *À :* Wiehe, Ulrich (NSN - DE/Munich); ext Steve Donovan; dime@ietf.org
> *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:dime-bounces@ietf.org] *On Behalf Of *Wiehe,
> Ulrich (NSN - DE/Munich)
> *Sent:* martes, 25 de marzo de 2014 16:15
> *To:* ext Steve Donovan; dime@ietf.org
> *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:srdonovan@usdonovans.com]
> *Sent:* Tuesday, March 25, 2014 2:49 PM
> *To:* Wiehe, Ulrich (NSN - DE/Munich); dime@ietf.org
> <mailto:dime@ietf.org>
> *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:srdonovan@usdonovans.com]
>     *Sent:* Monday, March 24, 2014 7:38 PM
>     *To:* Wiehe, Ulrich (NSN - DE/Munich); dime@ietf.org
>     <mailto:dime@ietf.org>
>     *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:dime-bounces@ietf.org] *On Behalf Of *ext
>         Steve Donovan
>         *Sent:* Monday, March 24, 2014 2:57 PM
>         *To:* dime@ietf.org <mailto:dime@ietf.org>
>         *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:dime-bounces@ietf.org] *On Behalf
>                 Of *ext Steve Donovan
>                 *Sent:* Friday, March 21, 2014 3:33 PM
>                 *To:* dime@ietf.org <mailto:dime@ietf.org>
>                 *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
>
>             DiME@ietf.org <mailto:DiME@ietf.org>
>
>             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.