Re: [Dime] [dime] #54: OC-Report-Type as mandatory AVP
<lionel.morand@orange.com> Wed, 26 March 2014 08:31 UTC
Return-Path: <lionel.morand@orange.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 086E91A0138 for <dime@ietfa.amsl.com>; Wed, 26 Mar 2014 01:31:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level:
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham
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 b1lb2BekWj6S for <dime@ietfa.amsl.com>; Wed, 26 Mar 2014 01:31:42 -0700 (PDT)
Received: from relais-inet.francetelecom.com (relais-ias244.francetelecom.com [80.12.204.244]) by ietfa.amsl.com (Postfix) with ESMTP id 511111A0121 for <dime@ietf.org>; Wed, 26 Mar 2014 01:31:41 -0700 (PDT)
Received: from omfeda05.si.francetelecom.fr (unknown [xx.xx.xx.198]) by omfeda14.si.francetelecom.fr (ESMTP service) with ESMTP id 3573C2AC6DB; Wed, 26 Mar 2014 09:31:37 +0100 (CET)
Received: from Exchangemail-eme1.itn.ftgroup (unknown [10.114.1.186]) by omfeda05.si.francetelecom.fr (ESMTP service) with ESMTP id 0F6A718006E; Wed, 26 Mar 2014 09:31:37 +0100 (CET)
Received: from PEXCVZYM13.corporate.adroot.infra.ftgroup ([fe80::cc7e:e40b:42ef:164e]) by PEXCVZYH01.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.03.0174.001; Wed, 26 Mar 2014 09:31:36 +0100
From: lionel.morand@orange.com
To: "Shishufeng (Susan)" <susan.shishufeng@huawei.com>, Steve Donovan <srdonovan@usdonovans.com>, Jouni Korhonen <jouni.nospam@gmail.com>
Thread-Topic: [Dime] [dime] #54: OC-Report-Type as mandatory AVP
Thread-Index: AQHPRXfTKav1Yd2xqUyLNClmxsrsL5rvj0+AgACNVgCAATdcAIAAXpSAgAEFQACAADq1WP//8oSAgAAC1ICAABOaIP///JUAgAAWOoA=
Date: Wed, 26 Mar 2014 08:31:35 +0000
Message-ID: <11539_1395822697_53329069_11539_6077_1_6B7134B31289DC4FAF731D844122B36E51C523@PEXCVZYM13.corporate.adroot.infra.ftgroup>
References: <075.72da31b401c033905a4fb81d09a8b4aa@trac.tools.ietf.org> <7077_1392216348_52FB891B_7077_4146_1_6B7134B31289DC4FAF731D844122B36E49E1A4@PEXCVZYM13.corporate.adroot.infra.ftgroup> <E194C2E18676714DACA9C3A2516265D2026649A3@FR712WXCHMBA11.zeu.alcatel-lucent.com> <EE7D3FEB-CD2A-45D9-9700-5CCA118D9A14@gmail.com> <546C1F19-2B53-4054-9C26-DDE6D0DF3C9F@nostrum.com> <087A34937E64E74E848732CFF8354B92097840F1@ESESSMB101.ericsson.se> <FC3C0F25-F8BE-4B4B-AF30-4CF2029A2520@gmail.com> <53287893.5020203@usdonovans.com> <087A34937E64E74E848732CFF8354B920979DDA2@ESESSMB101.ericsson.se> <53288284.5040606@usdonovans.com> <A7A9CDB7-9D90-458B-8C24-F0BFF52F897C@gmail.com> <26C84DFD55BC3040A45BF70926E55F2587C3D80D@SZXEMA512-MBX.china.huawei.com> <53302446.9080700@usdonovans.com> <26C84DFD55BC3040A45BF70926E55F2587C3DE93@SZXEMA512-MBX.china.huawei.com> <533178CD.9030707@usdonovans.com>, <26C84DFD55BC3040A45BF70926E55F2587C3E4C3@SZXEMA512-MBX.china.huawei.com> <11673_1395816227_53327723_11673_1919_1_4wjyrmeak04xst2onmes7ybh.1395816218573@email.android.com> <26C84DFD55BC3040A45BF70926E55F2587C3E57B@SZXEMA512-MBX.china.huawei.com> <26C84DFD55BC3040A45BF70926E55F2587C3E5AD@SZXEMA512-MBX.china.huawei.com> <1369_1395819319_53328337_1369_10404_1_6B7134B31289DC4FAF731D844122B36E51C25A@PEXCVZYM13.corporate.adroot.infra.ftgroup> <26C84DFD55BC3040A45BF70926E55F2587C3E671@SZXEMA512-MBX.china.huawei.com>
In-Reply-To: <26C84DFD55BC3040A45BF70926E55F2587C3E671@SZXEMA512-MBX.china.huawei.com>
Accept-Language: fr-FR, en-US
Content-Language: fr-FR
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.197.38.2]
Content-Type: multipart/alternative; boundary="_000_6B7134B31289DC4FAF731D844122B36E51C523PEXCVZYM13corpora_"
MIME-Version: 1.0
X-PMX-Version: 6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2014.3.25.173915
Archived-At: http://mailarchive.ietf.org/arch/msg/dime/buhIskIVUMyy4kJMkDppzxkizhE
Cc: "dime@ietf.org" <dime@ietf.org>
Subject: Re: [Dime] [dime] #54: OC-Report-Type as mandatory AVP
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: Wed, 26 Mar 2014 08:31:52 -0000
Hi Susan, Except your point of view that I respect, I haven't read anyone saying that they cannot accept to rely on a required AVP. And it is not yet confirmed that the AVP will be useless for 3GPP application. S6a does not represent the whole use cases in 3GPP and at least two operators think that they will use the concept of Realm-based report in their own network. And even from your side, I understand that you consider useless in some cases this AVP but you don't really challenge the fact that the presence of this AVP in any report would cause an issue. Based on this status, my preferred approach is the one proposed below. Now, if there is strong concern about this AVP we can revert this decision but: 1/ there is no reason not to accept this working assumption 2/ moving back this AVP from required to optional will not fundamentally impact the solution. Regards, Lionel De : Shishufeng (Susan) [mailto:susan.shishufeng@huawei.com] Envoyé : mercredi 26 mars 2014 09:04 À : MORAND Lionel IMT/OLN; Steve Donovan; Jouni Korhonen Cc : dime@ietf.org; Benoit Claise Objet : RE: [Dime] [dime] #54: OC-Report-Type as mandatory AVP Hello Lionel, Thanks for your reply. It is clear that majority companies involved in the discussion prefer to not have this AVP as mandatory. And Steve is ok with it as it is, and thus everyone is ok with it as optional. I'm wondering why you choose another way forward, and don't take opinion from majority companies into account, which is strange for me. We talked much about it, and in some major cases, this AVP is useless. If needed, anyway an optional AVP has to be present, I don't see any problem with it. We did a lot like this in 3GPP spec. I don't understand how in this case it shall be mandatory if you also agree that it is not needed in some cases. Best Regards, Susan From: lionel.morand@orange.com [mailto:lionel.morand@orange.com] Sent: Wednesday, March 26, 2014 3:35 PM To: Shishufeng (Susan); Steve Donovan; Jouni Korhonen Cc: dime@ietf.org; Benoit Claise Subject: RE: [Dime] [dime] #54: OC-Report-Type as mandatory AVP Hi Susan, I do care about comments from other but we need to move on. My decision is based on the following: from a technical point of view, there is no issue if we define this AVP as required. From a protocol aspect, it is cleaner as a report ALWAYS applies to a given type. Default value was considered as sub-optimal by Jouni, Ben, Steve, Maria Cruz (who has triggered this issue) and myself. Now, about the process, a 100% is not required to move forward. As it is not possible to get consensus on this issue, I use my prerogative to pick one solution, the one that seems to be the best solution at this stage, to be able to close the discussion at this stage and produce the draft that we need. After, it is always possible to challenge again the content of the draft if there is still concern. Benoit, the Area Director, is copied. It is not a putsch. Just administrative way agreed within IETF to be able to move forward a WG draft, which is the ultimate goal of everyone I think. Regards, Lionel. De : Shishufeng (Susan) [mailto:susan.shishufeng@huawei.com] Envoyé : mercredi 26 mars 2014 08:06 À : Shishufeng (Susan); MORAND Lionel IMT/OLN; Steve Donovan; Jouni Korhonen Cc : dime@ietf.org<mailto:dime@ietf.org> Objet : RE: [Dime] [dime] #54: OC-Report-Type as mandatory AVP Hello Lionel, Further clarification: I don't agree with this, not ok to everyone as you said. Best Regards, Susan From: Shishufeng (Susan) [mailto:susan.shishufeng@huawei.com] Sent: Wednesday, March 26, 2014 2:56 PM To: lionel.morand@orange.com<mailto:lionel.morand@orange.com>; Steve Donovan; Jouni Korhonen Cc: dime@ietf.org<mailto:dime@ietf.org> Subject: Re: [Dime] [dime] #54: OC-Report-Type as mandatory AVP Hello Lionel, I don't understand it. Please clarify if you care about other people's comments. Best Regards, Susan From: lionel.morand@orange.com<mailto:lionel.morand@orange.com> [mailto:lionel.morand@orange.com] Sent: Wednesday, March 26, 2014 2:44 PM To: Steve Donovan; Jouni Korhonen; Shishufeng (Susan) Cc: dime@ietf.org<mailto:dime@ietf.org> Subject: Re: [Dime] [dime] #54: OC-Report-Type as mandatory AVP As chair and temporary doc shepherd, Please stop this thread for now. As mandatory/required is ok for everyone (even if useless in certain case), let use it for now. Lionel "Shishufeng (Susan)" <susan.shishufeng@huawei.com<mailto:susan.shishufeng@huawei.com>> a écrit : Hello Steve, Thanks for clarifying the IETF procedure. I'm not familiar with it, while I know the draft is mainly for 3GPP use, that's why we 3GPP delegates are deeply involved in this specific discussion. If most of 3GPP people think it is not so needed I couldn't understand why it shall be mandatory. >From technical point of view, in the case realm based report type is not needed, nothing wrong without this AVP, and even better and cleaner. And you ever said you have preference but ok with either way forward, i.e., make it mandatory or optional. Then let's move on with the draft as it is on this point, if you agree. Best Regards, Susan From: Steve Donovan [mailto:srdonovan@usdonovans.com] Sent: Tuesday, March 25, 2014 8:39 PM To: Shishufeng (Susan); Jouni Korhonen Cc: dime@ietf.org<mailto:dime@ietf.org> Subject: Re: [Dime] [dime] #54: OC-Report-Type as mandatory AVP Susan, We have not been following a process of determining consensus based on a majority of companies expressing a preference. It is also the case that, in the IETF, companies do not contribute, individuals contribute. In addition, if we did take a "vote" on this one, I'm not sure which side would actually have a majority. We might need to change our process to speed things up, but right now we have been striving for true consensus where everyone agrees. Note that this doesn't mean everyone agrees with the technical reasoning behind the decision. There have been many cases where agreement is reached because it was more important to get something finished then to win a technical argument. If we can't start moving a little faster then we will likely need to change to rough consensus, where the measure is that most everyone agrees. However, in the IETF, even this is not a voting process. If things are close to 50-50 in opinions then the correct process is to continue to discuss the technical merits of each alternative until rough consensus is reached. Regards, Steve On 3/25/14, 2:00 AM, Shishufeng (Susan) wrote: Hi Steve, As I know, majority companies expressed preference to keep the AVP as optional and keep the texts as they are. You have preference to have it explicitly but ok with either way. That's how I assumed we reached consensus. Best Regards, Susan From: Steve Donovan [mailto:srdonovan@usdonovans.com] Sent: Monday, March 24, 2014 8:26 PM To: Shishufeng (Susan); Jouni Korhonen Cc: dime@ietf.org<mailto:dime@ietf.org> Subject: Re: [Dime] [dime] #54: OC-Report-Type as mandatory AVP Susan, We are in the middle of the discussion and have not yet reached consensus. I agree with Jouni on making it explicit. Either way, we should try to make a decision quickly. Steve On 3/23/14 10:59 PM, Shishufeng (Susan) wrote: Hello Jouni, I assume we had a lot of discussion on this and reached consensus to keep it as it is in the draft. Best Regards, Susan -----Original Message----- From: Jouni Korhonen [mailto:jouni.nospam@gmail.com] Sent: Saturday, March 22, 2014 10:38 AM To: Steve Donovan Cc: dime@ietf.org<mailto:dime@ietf.org> Subject: Re: [Dime] [dime] #54: OC-Report-Type as mandatory AVP Lets have it explicit then. Use '<' and '>' to make the position fixed. - Jouni On Mar 19, 2014, at 1:29 AM, Steve Donovan <srdonovan@usdonovans.com><mailto:srdonovan@usdonovans.com> wrote: I'm ok with either direction but generally lean toward being explicit. Do we have other opinions? Steve On 3/18/14 12:16 PM, Maria Cruz Bartolome wrote: Hello, I think the agreement tendency is the contrary: OC-Report-Type is not required, while default value is Host. i.e. it will remain as it is now in the draft. This may be of some advantage for some applications that may only use Host, as long as they may never generate Realm reports. If there is consensus on this, I will go with this. Best regards /MCruz From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Steve Donovan Sent: martes, 18 de marzo de 2014 17:47 To: dime@ietf.org<mailto:dime@ietf.org> Subject: Re: [Dime] [dime] #54: OC-Report-Type as mandatory AVP All, Do we have consensus that the OC-Report-Type AVP is required? If so then one change would be as indicated in the syntax definition proposed by Lionel. We would also remove wording on the default value. Jouni, How do we indicate a fixed position for an AVP? I presonally don't see this as critical but we can add this requirement if there is consensus. Regards, Steve On 2/28/14 10:27 AM, Jouni Korhonen wrote: Hi, How having the AVP could be less error prone if it has a default value and the receiver knows exactly how to proceed when the AVP is not present? If a node does not include it when it should, the implementation is broken. Wouldn't a broken node be able to put wrong report type into the AVP even if the AVP is mandatory? Anyway, if it is my statement keeping issue #54 still open, consider it resolved from my side. I am OK making the OC-Report-Type AVP as required/mandatory AVP. Should we also consider it having a fixed position just after the OC-Sequence-Number AVP as well since it is going to in every OC-OLR? - Jouni On Feb 21, 2014, at 11:47 AM, Maria Cruz Bartolome <maria.cruz.bartolome@ericsson.com><mailto:maria.cruz.bartolome@ericsson.com> wrote: Hello all, I understand JJ point of view, but I still tend to prefer to make it mandatory, since I think this is less error-prone, since the only node that knows the requested Report-Type is the reporting, if for any reason a reporting is omitting it (since it is optional), it will be always interpreted as HOST, but this type may be wrong. I think DEFAULT values should never be error-prone, but used in "general cases", as a simplification, like e.g. a default for the Validity-Duration. Default Validity-Duration will never be an "error", it could be not the best value (compared with another value perfectly tuned to reporting node overload situation) but never the use of a Default value should lead to an erroneous behavior. Best regards /MCruz -----Original Message----- From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Ben Campbell Sent: viernes, 14 de febrero de 2014 23:13 To: Jouni Korhonen Cc: dime@ietf.org<mailto:dime@ietf.org> Subject: Re: [Dime] [dime] #54: OC-Report-Type as mandatory AVP I actually prefer making it mandatory. The cost of adding it is trivial--even more so for a reporting node that only supports the default. The value of having it is less opportunity for interop errors. On Feb 13, 2014, at 6:05 AM, Jouni Korhonen <jouni.nospam@gmail.com><mailto:jouni.nospam@gmail.com> wrote: Agree that it is a small optimization, which I put there because at the beginning there seemed to be a lot of worry on every extra AVP ;-) I prefer having the AVP optional but with a default value just like it is now. We have the same for the reduction percentage and the validity time as well. - Jouni On Feb 13, 2014, at 10:55 AM, "TROTTIN, JEAN-JACQUES (JEAN-JACQUES)" <jean-jacques.trottin@alcatel-lucent.com><mailto:jean-jacques.trottin@alcatel-lucent.com> wrote: Hi Mcruz The current description indicates that when not present the OLR is of type Host, which was fine for me and keeps my preference. We may have deployments where Realm OLR is not used, or where statistically the HOST type is the most frequent, so to have the grouped OLR-AVP containing a minimum of AVPs minimizes parsing. I agree it is a small optimization. Best regards JJacques -----Message d'origine----- De : DiME [mailto:dime-bounces@ietf.org] De la part de lionel.morand@orange.com<mailto:lionel.morand@orange.com> Envoyé : mercredi 12 février 2014 15:46 À : dime@ietf.org<mailto:dime@ietf.org>; maria.cruz.bartolome@ericsson.com<mailto:maria.cruz.bartolome@ericsson.com> Objet : Re: [Dime] [dime] #54: OC-Report-Type as mandatory AVP Hi Maria Cruz, I'm assuming that you mean "required" instead of "mandatory", right? So instead of: OC-OLR ::= < AVP Header: TBD2 > < OC-Sequence-Number > [ OC-Report-Type ] [ OC-Reduction-Percentage ] [ OC-Validity-Duration ] * [ AVP ] You would prefer: OC-OLR ::= < AVP Header: TBD2 > < OC-Sequence-Number > { OC-Report-Type } [ OC-Reduction-Percentage ] [ OC-Validity-Duration ] * [ AVP ] And I'm fine with this proposal. Cheers, Lionel -----Message d'origine----- De : DiME [mailto:dime-bounces@ietf.org] De la part de dime issue tracker Envoyé : mercredi 12 février 2014 15:26 À : maria.cruz.bartolome@ericsson.com<mailto:maria.cruz.bartolome@ericsson.com> Cc : dime@ietf.org<mailto:dime@ietf.org> Objet : [Dime] [dime] #54: OC-Report-Type as mandatory AVP #54: OC-Report-Type as mandatory AVP Now in chapter 4.6: The default value of the OC-Report-Type AVP is 0 (i.e. the host report). This AVP is always required, right? Then, I think it is more precise that we define this AVP as mandatory. -- -----------------------------------------------+--------------------- -----------------------------------------------+--- -----------------------------------------------+--- Reporter: maria.cruz.bartolome@ericsson.com<mailto:maria.cruz.bartolome@ericsson.com> | Owner: MCruz Type: defect | Bartolomé Priority: major | Status: new Component: draft-docdt-dime-ovli | Milestone: Severity: Active WG Document | Version: 1.0 | Keywords: -----------------------------------------------+--------------------- -----------------------------------------------+--- -----------------------------------------------+--- Ticket URL: <http://trac.tools.ietf.org/wg/dime/trac/ticket/54><http://trac.tools.ietf.org/wg/dime/trac/ticket/54> dime <http://tools.ietf.org/wg/dime/><http://tools.ietf.org/wg/dime/> _______________________________________________ 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. _______________________________________________ DiME mailing list DiME@ietf.org<mailto:DiME@ietf.org> https://www.ietf.org/mailman/listinfo/dime _______________________________________________ DiME mailing list DiME@ietf.org<mailto:DiME@ietf.org> https://www.ietf.org/mailman/listinfo/dime _______________________________________________ DiME mailing list DiME@ietf.org<mailto:DiME@ietf.org> https://www.ietf.org/mailman/listinfo/dime _______________________________________________ DiME mailing list DiME@ietf.org<mailto:DiME@ietf.org> https://www.ietf.org/mailman/listinfo/dime _______________________________________________ DiME mailing list DiME@ietf.org<mailto:DiME@ietf.org> https://www.ietf.org/mailman/listinfo/dime _______________________________________________ DiME mailing list DiME@ietf.org<mailto:DiME@ietf.org> https://www.ietf.org/mailman/listinfo/dime _______________________________________________ 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. _________________________________________________________________________________________________________________________ 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] [dime] #54: OC-Report-Type as mandatory AVP dime issue tracker
- Re: [Dime] [dime] #54: OC-Report-Type as mandator… lionel.morand
- Re: [Dime] [dime] #54: OC-Report-Type as mandator… TROTTIN, JEAN-JACQUES (JEAN-JACQUES)
- Re: [Dime] [dime] #54: OC-Report-Type as mandator… Jouni Korhonen
- Re: [Dime] [dime] #54: OC-Report-Type as mandator… Steve Donovan
- Re: [Dime] [dime] #54: OC-Report-Type as mandator… Ben Campbell
- Re: [Dime] [dime] #54: OC-Report-Type as mandator… Maria Cruz Bartolome
- Re: [Dime] [dime] #54: OC-Report-Type as mandator… Jouni Korhonen
- Re: [Dime] [dime] #54: OC-Report-Type as mandator… Jouni Korhonen
- Re: [Dime] [dime] #54: OC-Report-Type as mandator… Steve Donovan
- Re: [Dime] [dime] #54: OC-Report-Type as mandator… Maria Cruz Bartolome
- Re: [Dime] [dime] #54: OC-Report-Type as mandator… Steve Donovan
- Re: [Dime] [dime] #54: OC-Report-Type as mandator… Jouni Korhonen
- Re: [Dime] [dime] #54: OC-Report-Type as mandator… Shishufeng (Susan)
- Re: [Dime] [dime] #54: OC-Report-Type as mandator… Shishufeng (Susan)
- Re: [Dime] [dime] #54: OC-Report-Type as mandator… Steve Donovan
- Re: [Dime] [dime] #54: OC-Report-Type as mandator… TROTTIN, JEAN-JACQUES (JEAN-JACQUES)
- Re: [Dime] [dime] #54: OC-Report-Type as mandator… Wiehe, Ulrich (NSN - DE/Munich)
- Re: [Dime] [dime] #54: OC-Report-Type as mandator… lionel.morand
- Re: [Dime] [dime] #54: OC-Report-Type as mandator… Steve Donovan
- Re: [Dime] [dime] #54: OC-Report-Type as mandator… Shishufeng (Susan)
- Re: [Dime] [dime] #54: OC-Report-Type as mandator… Shishufeng (Susan)
- Re: [Dime] [dime] #54: OC-Report-Type as mandator… Steve Donovan
- Re: [Dime] [dime] #54: OC-Report-Type as mandator… Shishufeng (Susan)
- Re: [Dime] [dime] #54: OC-Report-Type as mandator… lionel.morand
- Re: [Dime] [dime] #54: OC-Report-Type as mandator… Shishufeng (Susan)
- Re: [Dime] [dime] #54: OC-Report-Type as mandator… Shishufeng (Susan)
- Re: [Dime] [dime] #54: OC-Report-Type as mandator… lionel.morand
- Re: [Dime] [dime] #54: OC-Report-Type as mandator… Shishufeng (Susan)
- Re: [Dime] [dime] #54: OC-Report-Type as mandator… lionel.morand
- Re: [Dime] [dime] #54: OC-Report-Type as mandator… Shishufeng (Susan)
- Re: [Dime] [dime] #54: OC-Report-Type as mandator… lionel.morand
- Re: [Dime] [dime] #54: OC-Report-Type as mandator… TROTTIN, JEAN-JACQUES (JEAN-JACQUES)
- Re: [Dime] [dime] #54: OC-Report-Type as mandator… Maria Cruz Bartolome
- Re: [Dime] [dime] #54: OC-Report-Type as mandator… Steve Donovan
- Re: [Dime] [dime] #54: OC-Report-Type as mandator… Shishufeng (Susan)
- Re: [Dime] [dime] #54: OC-Report-Type as mandator… lionel.morand
- Re: [Dime] [dime] #54: OC-Report-Type as mandator… Shishufeng (Susan)
- Re: [Dime] [dime] #54: OC-Report-Type as mandator… lionel.morand
- Re: [Dime] [dime] #54: OC-Report-Type as mandator… lionel.morand
- Re: [Dime] [dime] #54: OC-Report-Type as mandator… Shishufeng (Susan)
- Re: [Dime] [dime] #54: OC-Report-Type as mandator… Shishufeng (Susan)
- Re: [Dime] [dime] #54: OC-Report-Type as mandator… lionel.morand
- Re: [Dime] [dime] #54: OC-Report-Type as mandator… Wiehe, Ulrich (NSN - DE/Munich)
- Re: [Dime] [dime] #54: OC-Report-Type as mandator… TROTTIN, JEAN-JACQUES (JEAN-JACQUES)
- Re: [Dime] [dime] #54: OC-Report-Type as mandator… TROTTIN, JEAN-JACQUES (JEAN-JACQUES)
- [Dime] Large messages on list? David Mitton
- Re: [Dime] [dime] #54: OC-Report-Type as mandator… Benoit Claise
- Re: [Dime] [dime] #54 (draft-ietf-dime-ovli): OC-… dime issue tracker
- Re: [Dime] [dime] #54 (draft-ietf-dime-ovli): OC-… dime issue tracker