From nobody Mon Feb 1 07:24:20 2016 Return-Path: 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 65A691ACDE8 for ; Mon, 1 Feb 2016 07:24:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.778 X-Spam-Level: X-Spam-Status: No, score=0.778 tagged_above=-999 required=5 tests=[BAYES_20=-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 e2VRpngWAnmJ for ; Mon, 1 Feb 2016 07:24:17 -0800 (PST) Received: from biz131.inmotionhosting.com (biz131.inmotionhosting.com [173.247.247.250]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9793D1ACDE5 for ; Mon, 1 Feb 2016 07:24:15 -0800 (PST) Received: from cpe-97-99-50-102.tx.res.rr.com ([97.99.50.102]:56818 helo=Steves-MacBook-Air.local) by biz131.inmotionhosting.com with esmtpsa (TLSv1.2:RC4-SHA:128) (Exim 4.85) (envelope-from ) id 1aQGKn-003tOR-Eh; Mon, 01 Feb 2016 07:24:15 -0800 To: "A. Jean Mahoney" , lionel.morand@orange.com, "dime@ietf.org" References: <18555_1450866365_567A76BD_18555_7990_1_6B7134B31289DC4FAF731D844122B36E01D93ACB@OPEXCLILM43.corporate.adroot.infra.ftgroup> <568AE0C1.9080600@nostrum.com> <56A8FC32.8020209@usdonovans.com> <10248_1453916088_56A8FFB8_10248_54_1_6B7134B31289DC4FAF731D844122B36E01DBD108@OPEXCLILM43.corporate.adroot.infra.ftgroup> <56A904E5.4040405@usdonovans.com> <6309_1453919279_56A90C2F_6309_7518_1_6B7134B31289DC4FAF731D844122B36E01DBD22A@OPEXCLILM43.corporate.adroot.infra.ftgroup> <56A92A28.1090905@nostrum.com> From: Steve Donovan Message-ID: <56AF7899.60509@usdonovans.com> Date: Mon, 1 Feb 2016 09:24:09 -0600 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: <56A92A28.1090905@nostrum.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit X-OutGoing-Spam-Status: No, score=-1.0 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: Subject: Re: [Dime] Start of the WGLC on draft-ietf-dime-drmp-02 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Feb 2016 15:24:19 -0000 On 1/27/16 2:35 PM, A. Jean Mahoney wrote: > Hi Steve and Lionel, > > On 1/27/16 12:27 PM, lionel.morand@orange.com wrote: >> Steve, >> >> See below. >> >> Lionel >> >> -----Message d'origine----- De : Steve Donovan >> [mailto:srdonovan@usdonovans.com] Envoyé : mercredi 27 janvier 2016 >> 18:57 À : MORAND Lionel IMT/OLN; A. Jean Mahoney; dime@ietf.org Objet >> : Re: [Dime] Start of the WGLC on draft-ietf-dime-drmp-02 >> >> >> >> On 1/27/16 11:34 AM, lionel.morand@orange.com wrote: >>> Hi Steve, >>> >>> 1 comment and 1 question below. >>> >>> Regards, >>> >>> Lionel >>> >>> -----Message d'origine----- De : Steve Donovan >>> [mailto:srdonovan@usdonovans.com] Envoyé : mercredi 27 janvier 2016 >>> 18:20 À : A. Jean Mahoney; MORAND Lionel IMT/OLN; dime@ietf.org >>> Objet : Re: [Dime] Start of the WGLC on draft-ietf-dime-drmp-02 >>> >>> Jean, >>> >>> Thanks for the review. See my comments below. >>> >>> Regards, >>> >>> Steve >>> >>> On 1/4/16 3:14 PM, A. Jean Mahoney wrote: >>>> Hi all, >>>> >>>> I'm good with the document, although I agree with Janet's >>>> feedback that someone in ecrit should take a look at it, and with >>>> Lionel's feedback on the security section. >>> SRD> I'll be addressing these comments in a separate email. >>>> >>>> Section 6, number 4: >>>> >>>> I assume the sender's decision to change the priority for the >>>> answer is app-specific. Maybe add some words here and in Section >>>> 8 to that effect. >>> SRD> I added the following to the end of the paragraph: "The >>> priority included by the answer sender is application specific." >>> [LM] I think that the comment is about the "decision" and not the >>> "value". >> SRD2> Yes, but the decision to be made it about the value. Do you >> have a suggestion for alternate wording? >> >> [LM] I think that the first decision is to include a prioriity value >> in the answer... even if it is the same value. But I may be wrong. >> > [ajm] Hmm, section 8 implies that the DRMP AVP is included in the > answer only when the answer sender modifies the priority: > > Diameter endpoints MAY include the DRMP AVP in answer messages. This > is done when the priority for the answer message needs to have a > different priority than the priority carried in the request message. > > How about the following for the end of section 6, number 4? > > The answer sender also has the option of modifying priority > information and including it in the answer message. The sender's > behavior with regard to priority modification is application- > specific. > SRD> Change made. > >>> >>>> Section 8: >>>> >>>> Section 6 talks about nodes saving priority information found in >>>> the request's DRMP AVP with the transaction state, and then >>>> checking it if the AVP is absent in the Diameter answer. This >>>> info should be captured in this section also. >>> SRD> The normative behavior is captured in this paragraph: >>> >>> When determining the priority to apply to answer messages, >>> Diameter nodes MUST use the priority indicated in the DRMP AVP >>> carried in the answer message, if it exists. Otherwise, the >>> Diameter node MUST use the priority indicated in the DRMP AVP of >>> the associated request message. >>> >>> Section 6 talks about one way to implement this. I'm hesitant to >>> include it as normative behavior. As such, I added the following >>> note: >>> >>> Note: One method to determine what priority to apply to an answer >>> when there is no DRMP AVP in the answer message is to save the >>> priority included in the request message in state associated with >>> the Diameter transaction. >>> >>> [LM] It is curious to see an expected behaviour described in >>> section 6 and no related normative behaviour. Could you explain why >>> you are reluctant to say that the priority value indicated in the >>> request is saved? >> SRD> Section 6 is non normative and, as such, only an example. >> Specifying this in the normative section would eliminate other >> methods of determining the value received in the request. For >> instance, a stateless agent might choose to include the value in a >> Proxy-Info AVP. >> >> [LM] Good point. Could be good to indicate both options in your >> example. >> > > [ajm] A note in section 8 would be helpful. It doesn't have to be > normative. SRD> I've replaced the relevent sentence in section 6 with the following: "The agent also saves the transaction priority in the transaction state, either as locally managed state or using the Proxy-Info mechanism defined in RFC6733. " I've also changed the note in section 8 to the following: Note: One method to determine what priority to apply to an answer when there is no DRMP AVP in the answer message is to save the priority included in the request message in state associated with the Diameter transaction. Another is to use the Proxy-Info mechanism defined in RFC6733. > >>> >>>> Nits: >>>> >>>> Section 5, 1st paragraph: s/discussed/discusses >>>> >>>> Section 5.1, 4th paragraph: s/job/jobs >>>> >>>> Section 5.4, 5th paragraph: s/command-code/command code >>>> >>>> Section 6, number 6: s/transaction/transaction state >>> I re-worded to the following: >>> >>> "...By default the handler of the answer message uses the priority >>> saved in the transaction's state. > > [ajm] ok > > Thanks! > > Jean > >>>> Section 7: Add a period to end of paragraph >>>> >>>> Section 11: s/Diamter/Diameter >>>> >>>> Happy New Year! >>>> >>>> Jean >>>> >>>> >>>> On 12/23/15 4:26 AM, lionel.morand@orange.com wrote: >>>>> As agreed during the Dime session at IETF94, a Working Group >>>>> Last Call is asked on the following document: >>>>> >>>>> https://tools.ietf.org/html/draft-ietf-dime-drmp-02 >>>>> >>>>> Please respond to this email to support the document and/or >>>>> send comments by 2016-01-20. >>>>> >>>>> As this WGLC is initiated during the Xmas/end-of-year break, >>>>> the WGLC period is extended to 4 weeks. For reviewer of the >>>>> document, don't forget to state if you are fine with the >>>>> document even if there is no comment. It is important for >>>>> evaluating the quality of the document and gauge the WG >>>>> consensus. >>>>> >>>>> In addition, following the strategy for promoting compliance >>>>> with the IPR disclosure rules (RFC6702), the chairs would like >>>>> to check whether there are claims of Intellectual Property >>>>> Rights (IPR) on the document that need to be disclosed. >>>>> Therefore, the following questions are addressed to the WG and >>>>> Especially Authors and Contributors of the draft: >>>>> >>>>> * Are you personally aware of any IPR that applies to >>>>> draft-ietf-dime-drmp-02? If so, has this IPR been disclosed in >>>>> compliance with IETF IPR rules? (See RFCs 3979, 4879, 3669, >>>>> and 5378 for more details.) >>>>> >>>>> * If you are a document author or listed contributor on this >>>>> document, please reply to this email message regardless of >>>>> whether or not you are personally aware of any relevant IPR. >>>>> We might not be able to advance this document to the next stage >>>>> until we have received a reply from each author and listed >>>>> contributor. >>>>> >>>>> * If you are on the DIME WG email list but are not an author >>>>> or listed contributor for this document, you are reminded of >>>>> your opportunity for a voluntary IPR disclosure under BCP 79. >>>>> Please do not reply unless you want to make such a voluntary >>>>> disclosure. >>>>> >>>>> Online tools for filing IPR disclosures can be found at >>>>> . >>>>> >>>>> Regards, >>>>> >>>>> Lionel and Jouni >>>>> >>>>> ____________________________________________________________________ >>>>> >>>>> > _ ____________________________________________________ >>>>> >>>>> >>>>> 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 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. >> From nobody Mon Feb 1 08:30:16 2016 Return-Path: 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 CD7DC1B3228 for ; Mon, 1 Feb 2016 08:30:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.579 X-Spam-Level: * X-Spam-Status: No, score=1.579 tagged_above=-999 required=5 tests=[BAYES_50=0.8, 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 JF3UryG5ZEEr for ; Mon, 1 Feb 2016 08:30:13 -0800 (PST) Received: from biz131.inmotionhosting.com (biz131.inmotionhosting.com [173.247.247.250]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AFE2B1B321F for ; Mon, 1 Feb 2016 08:30:13 -0800 (PST) Received: from cpe-97-99-50-102.tx.res.rr.com ([97.99.50.102]:58451 helo=Steves-MacBook-Air.local) by biz131.inmotionhosting.com with esmtpsa (TLSv1.2:RC4-SHA:128) (Exim 4.85) (envelope-from ) id 1aQHMf-000Glu-DB for dime@ietf.org; Mon, 01 Feb 2016 08:30:13 -0800 To: "dime@ietf.org" From: Steve Donovan Message-ID: <56AF8811.5030106@usdonovans.com> Date: Mon, 1 Feb 2016 10:30:09 -0600 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-OutGoing-Spam-Status: No, score=-1.0 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: Subject: [Dime] Proposed security section for DRMP X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Feb 2016 16:30:15 -0000 All, Here's the proposed security section for DRMP. It is based heavily on Ben's words in the Diameter Overload RFC. Regards, Steve ----- 11. Security Considerations DRMP gives Diameter nodes the ability to influence which requests are are throttled during overload scenarios. Improper use of the DRMP mechanism could result in the malicious Diameter node gaining preferential treatment, by reducing the probability of its requests being throttled, over other Diameter nodes. This would be achieved by the malicious node inserting artificially high priority values. Diameter does not include features to provide end-to-end authentication, integrity protection, or confidentiality. This opens the possibility that agents in the path of a request could modify the DRMP AVP to reflect a priority different than that asserted by the sender of the request. 11.1. Potential Threat Modes The Diameter protocol involves transactions in the form of requests and answers exchanged between clients and servers. These clients and servers may be peers, that is, they may share a direct transport (e.g., TCP or SCTP) connection, or the messages may traverse one or more intermediaries, known as Diameter Agents. Diameter nodes use TLS, DTLS, or IPsec to authenticate peers, and to provide confidentiality and integrity protection of traffic between peers. Nodes can make authorization decisions based on the peer identities authenticated at the transport layer. When agents are involved, this presents an effectively transitive trust model. That is, a Diameter client or server can authorize an agent for certain actions, but it must trust that agent to make appropriate authorization decisions about its peers, and so on. Since confidentiality and integrity protection occurs at the transport layer, agents can read, and perhaps modify, any part of a Diameter message, including the DRMP AVP. There are several ways an attacker might attempt to exploit the DRMP mechanism. A malicious or compromised Diameter node might insert invalid priority values resulting in either preferential treatment, Donovan Expires July 4, 2016 [Page 13] Internet-Draft DOIC January 2016 resulting from higher values, or degraded treatment resulting from lower values, for that node. A similar attack involves a malicious or compromised Diameter agent changing the priority value resulting in the sending Diameter node getting either preferential or degraded service. The DRMP mechanism can be used to aid in overload throttling decisions. When this is the case then the above attacks are limited in scope to when one or more Diameter nodes are in an overloaded state. The DRMP mechanism can also be used to influence the order in which Diameter messages are handled by Diamter nodes. The above attacks have a potentially greater impact in this scenario as the priority indication impacts the handling of all requests at all times, independent of the overload status of Diameter nodes in the Diameter network. 11.2. Denial of Service Attacks The DRMP mechanism does not open direct denial of service attack vectors. Rather, it introduces a mechanism where a node can gain unwarranted preferential treatment. It also introduces a mechanism where a node can get degrated service in the scenario where a rogue agent changes the priority value included in messages. 11.3. End-to End-Security Issues The lack of end-to-end integrity features makes it difficult to establish trust in DRMP AVPs received from non-adjacent nodes. Any agents in the message path may insert or modify DRMP AVPs. Nodes must trust that their adjacent peers perform proper checks on overload reports from their peers, and so on, creating a transitive- trust requirement extending for potentially long chains of nodes. Network operators must determine if this transitive trust requirement is acceptable for their deployments. Nodes supporting DRMP MUST give operators the ability to select which peers are trusted to deliver DRMP AVPs, and whether they are trusted to forward the DRMP AVPs from non-adjacent nodes. Diameter nodes MUST strip DRMP AVPs from messages received from peers that are not trusted for DRMP purposes. It is expected that work on end-to-end Diameter security might make it easier to establish trust in non-adjacent nodes for DRMP purposes. Readers should be reminded, however, that the DRMP mechanism allows Diameter agents to modify AVPs in existing messages that are originated by other nodes. If end-to-end security is enabled, there is a risk that such modification could violate integrity protection. Donovan Expires July 4, 2016 [Page 14] Internet-Draft DOIC January 2016 The details of using any future Diameter end-to-end security mechanism with DRMP will require careful consideration, and are beyond the scope of this document. From nobody Mon Feb 1 12:59:28 2016 Return-Path: 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 9F70F1B36AE for ; Mon, 1 Feb 2016 12:59:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-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 Pq3qZB7ruSPm for ; Mon, 1 Feb 2016 12:59:24 -0800 (PST) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E2BAE1B36B1 for ; Mon, 1 Feb 2016 12:59:23 -0800 (PST) Received: from mutabilis-2.local (pool-173-57-158-165.dllstx.fios.verizon.net [173.57.158.165]) (authenticated bits=0) by nostrum.com (8.15.2/8.14.9) with ESMTPSA id u11KxM0L039054 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Mon, 1 Feb 2016 14:59:23 -0600 (CST) (envelope-from mahoney@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host pool-173-57-158-165.dllstx.fios.verizon.net [173.57.158.165] claimed to be mutabilis-2.local To: Steve Donovan , lionel.morand@orange.com, "dime@ietf.org" References: <18555_1450866365_567A76BD_18555_7990_1_6B7134B31289DC4FAF731D844122B36E01D93ACB@OPEXCLILM43.corporate.adroot.infra.ftgroup> <568AE0C1.9080600@nostrum.com> <56A8FC32.8020209@usdonovans.com> <10248_1453916088_56A8FFB8_10248_54_1_6B7134B31289DC4FAF731D844122B36E01DBD108@OPEXCLILM43.corporate.adroot.infra.ftgroup> <56A904E5.4040405@usdonovans.com> <6309_1453919279_56A90C2F_6309_7518_1_6B7134B31289DC4FAF731D844122B36E01DBD22A@OPEXCLILM43.corporate.adroot.infra.ftgroup> <56A92A28.1090905@nostrum.com> <56AF7899.60509@usdonovans.com> From: "A. Jean Mahoney" Message-ID: <56AFC72A.8000605@nostrum.com> Date: Mon, 1 Feb 2016 14:59:22 -0600 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: <56AF7899.60509@usdonovans.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [Dime] Start of the WGLC on draft-ietf-dime-drmp-02 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Feb 2016 20:59:26 -0000 Thanks for the changes! Jean On 2/1/16 9:24 AM, Steve Donovan wrote: > > > On 1/27/16 2:35 PM, A. Jean Mahoney wrote: >> Hi Steve and Lionel, >> >> On 1/27/16 12:27 PM, lionel.morand@orange.com wrote: >>> Steve, >>> >>> See below. >>> >>> Lionel >>> >>> -----Message d'origine----- De : Steve Donovan >>> [mailto:srdonovan@usdonovans.com] Envoyé : mercredi 27 janvier 2016 >>> 18:57 À : MORAND Lionel IMT/OLN; A. Jean Mahoney; dime@ietf.org Objet >>> : Re: [Dime] Start of the WGLC on draft-ietf-dime-drmp-02 >>> >>> >>> >>> On 1/27/16 11:34 AM, lionel.morand@orange.com wrote: >>>> Hi Steve, >>>> >>>> 1 comment and 1 question below. >>>> >>>> Regards, >>>> >>>> Lionel >>>> >>>> -----Message d'origine----- De : Steve Donovan >>>> [mailto:srdonovan@usdonovans.com] Envoyé : mercredi 27 janvier 2016 >>>> 18:20 À : A. Jean Mahoney; MORAND Lionel IMT/OLN; dime@ietf.org >>>> Objet : Re: [Dime] Start of the WGLC on draft-ietf-dime-drmp-02 >>>> >>>> Jean, >>>> >>>> Thanks for the review. See my comments below. >>>> >>>> Regards, >>>> >>>> Steve >>>> >>>> On 1/4/16 3:14 PM, A. Jean Mahoney wrote: >>>>> Hi all, >>>>> >>>>> I'm good with the document, although I agree with Janet's >>>>> feedback that someone in ecrit should take a look at it, and with >>>>> Lionel's feedback on the security section. >>>> SRD> I'll be addressing these comments in a separate email. >>>>> >>>>> Section 6, number 4: >>>>> >>>>> I assume the sender's decision to change the priority for the >>>>> answer is app-specific. Maybe add some words here and in Section >>>>> 8 to that effect. >>>> SRD> I added the following to the end of the paragraph: "The >>>> priority included by the answer sender is application specific." >>>> [LM] I think that the comment is about the "decision" and not the >>>> "value". >>> SRD2> Yes, but the decision to be made it about the value. Do you >>> have a suggestion for alternate wording? >>> >>> [LM] I think that the first decision is to include a prioriity value >>> in the answer... even if it is the same value. But I may be wrong. >>> >> [ajm] Hmm, section 8 implies that the DRMP AVP is included in the >> answer only when the answer sender modifies the priority: >> >> Diameter endpoints MAY include the DRMP AVP in answer messages. This >> is done when the priority for the answer message needs to have a >> different priority than the priority carried in the request message. >> >> How about the following for the end of section 6, number 4? >> >> The answer sender also has the option of modifying priority >> information and including it in the answer message. The sender's >> behavior with regard to priority modification is application- >> specific. >> > SRD> Change made. >> >>>> >>>>> Section 8: >>>>> >>>>> Section 6 talks about nodes saving priority information found in >>>>> the request's DRMP AVP with the transaction state, and then >>>>> checking it if the AVP is absent in the Diameter answer. This >>>>> info should be captured in this section also. >>>> SRD> The normative behavior is captured in this paragraph: >>>> >>>> When determining the priority to apply to answer messages, >>>> Diameter nodes MUST use the priority indicated in the DRMP AVP >>>> carried in the answer message, if it exists. Otherwise, the >>>> Diameter node MUST use the priority indicated in the DRMP AVP of >>>> the associated request message. >>>> >>>> Section 6 talks about one way to implement this. I'm hesitant to >>>> include it as normative behavior. As such, I added the following >>>> note: >>>> >>>> Note: One method to determine what priority to apply to an answer >>>> when there is no DRMP AVP in the answer message is to save the >>>> priority included in the request message in state associated with >>>> the Diameter transaction. >>>> >>>> [LM] It is curious to see an expected behaviour described in >>>> section 6 and no related normative behaviour. Could you explain why >>>> you are reluctant to say that the priority value indicated in the >>>> request is saved? >>> SRD> Section 6 is non normative and, as such, only an example. >>> Specifying this in the normative section would eliminate other >>> methods of determining the value received in the request. For >>> instance, a stateless agent might choose to include the value in a >>> Proxy-Info AVP. >>> >>> [LM] Good point. Could be good to indicate both options in your >>> example. >>> >> >> [ajm] A note in section 8 would be helpful. It doesn't have to be >> normative. > SRD> I've replaced the relevent sentence in section 6 with the > following: "The agent also saves the transaction > priority in the transaction state, either as locally managed > state or using the > Proxy-Info mechanism defined in RFC6733. " > > I've also changed the note in section 8 to the following: > > Note: One method to determine what priority to apply to an answer when > there is no > DRMP AVP in the answer message is to save the priority included > in the request message > in state associated with the Diameter transaction. Another is > to use the > Proxy-Info mechanism defined in RFC6733. > >> >>>> >>>>> Nits: >>>>> >>>>> Section 5, 1st paragraph: s/discussed/discusses >>>>> >>>>> Section 5.1, 4th paragraph: s/job/jobs >>>>> >>>>> Section 5.4, 5th paragraph: s/command-code/command code >>>>> >>>>> Section 6, number 6: s/transaction/transaction state >>>> I re-worded to the following: >>>> >>>> "...By default the handler of the answer message uses the priority >>>> saved in the transaction's state. >> >> [ajm] ok >> >> Thanks! >> >> Jean >> >>>>> Section 7: Add a period to end of paragraph >>>>> >>>>> Section 11: s/Diamter/Diameter >>>>> >>>>> Happy New Year! >>>>> >>>>> Jean >>>>> >>>>> >>>>> On 12/23/15 4:26 AM, lionel.morand@orange.com wrote: >>>>>> As agreed during the Dime session at IETF94, a Working Group >>>>>> Last Call is asked on the following document: >>>>>> >>>>>> https://tools.ietf.org/html/draft-ietf-dime-drmp-02 >>>>>> >>>>>> Please respond to this email to support the document and/or >>>>>> send comments by 2016-01-20. >>>>>> >>>>>> As this WGLC is initiated during the Xmas/end-of-year break, >>>>>> the WGLC period is extended to 4 weeks. For reviewer of the >>>>>> document, don't forget to state if you are fine with the >>>>>> document even if there is no comment. It is important for >>>>>> evaluating the quality of the document and gauge the WG >>>>>> consensus. >>>>>> >>>>>> In addition, following the strategy for promoting compliance >>>>>> with the IPR disclosure rules (RFC6702), the chairs would like >>>>>> to check whether there are claims of Intellectual Property >>>>>> Rights (IPR) on the document that need to be disclosed. >>>>>> Therefore, the following questions are addressed to the WG and >>>>>> Especially Authors and Contributors of the draft: >>>>>> >>>>>> * Are you personally aware of any IPR that applies to >>>>>> draft-ietf-dime-drmp-02? If so, has this IPR been disclosed in >>>>>> compliance with IETF IPR rules? (See RFCs 3979, 4879, 3669, >>>>>> and 5378 for more details.) >>>>>> >>>>>> * If you are a document author or listed contributor on this >>>>>> document, please reply to this email message regardless of >>>>>> whether or not you are personally aware of any relevant IPR. >>>>>> We might not be able to advance this document to the next stage >>>>>> until we have received a reply from each author and listed >>>>>> contributor. >>>>>> >>>>>> * If you are on the DIME WG email list but are not an author >>>>>> or listed contributor for this document, you are reminded of >>>>>> your opportunity for a voluntary IPR disclosure under BCP 79. >>>>>> Please do not reply unless you want to make such a voluntary >>>>>> disclosure. >>>>>> >>>>>> Online tools for filing IPR disclosures can be found at >>>>>> . >>>>>> >>>>>> Regards, >>>>>> >>>>>> Lionel and Jouni >>>>>> >>>>>> ____________________________________________________________________ >>>>>> >>>>>> >> _ ____________________________________________________ >>>>>> >>>>>> >>>>>> 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 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. >>> > From nobody Tue Feb 2 07:29:38 2016 Return-Path: X-Original-To: dime@ietf.org Delivered-To: dime@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id B40561B2C49; Tue, 2 Feb 2016 07:29:35 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.13.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160202152935.6319.66645.idtracker@ietfa.amsl.com> Date: Tue, 02 Feb 2016 07:29:35 -0800 Archived-At: Cc: dime@ietf.org Subject: [Dime] I-D Action: draft-ietf-dime-drmp-03.txt X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Feb 2016 15:29:35 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Diameter Maintenance and Extensions Working Group of the IETF. Title : Diameter Routing Message Priority Author : Steve Donovan Filename : draft-ietf-dime-drmp-03.txt Pages : 16 Date : 2016-02-02 Abstract: When making routing and resource allocation decisions, Diameter nodes currently have no generic mechanism to determine the relative priority of Diameter messages. This document addresses this by defining a mechanism to allow Diameter endpoints to indicate the relative priority of Diameter transactions. With this information Diameter nodes can factor that priority into routing, resource allocation and overload abatement decisions. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-dime-drmp/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-dime-drmp-03 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-dime-drmp-03 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Fri Feb 5 10:56:08 2016 Return-Path: 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 0BDA01A87CE for ; Fri, 5 Feb 2016 10:55:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.903 X-Spam-Level: X-Spam-Status: No, score=-101.903 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] 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 1EU0rj7v5Rnr for ; Fri, 5 Feb 2016 10:55:00 -0800 (PST) Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1900:3001:11::31]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 958E61A87CD for ; Fri, 5 Feb 2016 10:55:00 -0800 (PST) Received: by rfc-editor.org (Postfix, from userid 30) id F3B23180208; Fri, 5 Feb 2016 10:54:40 -0800 (PST) To: vf0213@gmail.com, jari.arkko@ericsson.com, john.loughney@nokia.com, glenzorn@gmail.com, bclaise@cisco.com, joelja@bogus.com, jouni.nospam@gmail.com, lionel.morand@orange.com X-PHP-Originating-Script: 30:errata_mail_lib.php From: RFC Errata System Message-Id: <20160205185440.F3B23180208@rfc-editor.org> Date: Fri, 5 Feb 2016 10:54:40 -0800 (PST) Archived-At: X-Mailman-Approved-At: Fri, 05 Feb 2016 10:56:06 -0800 Cc: rfc-editor@rfc-editor.org, dime@ietf.org Subject: [Dime] [Technical Errata Reported] RFC6733 (4615) X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Feb 2016 18:55:02 -0000 The following errata report has been submitted for RFC6733, "Diameter Base Protocol". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=6733&eid=4615 -------------------------------------- Type: Technical Reported by: Lionel Morand Section: 7.1.5 Original Text ------------- DIAMETER_AVP_UNSUPPORTED 5001 The peer received a message that contained an AVP that is not recognized or supported and was marked with the 'M' (Mandatory) bit. A Diameter message with this error MUST contain one or more Failed-AVP AVPs containing the AVPs that caused the failure. Corrected Text -------------- DIAMETER_AVP_UNSUPPORTED 5001 The peer received a message that contained an AVP that is not recognized or supported and was marked with the 'M' (Mandatory) bit. A Diameter message with this error MUST contain one Failed-AVP AVP containing the AVPs that caused the failure. Notes ----- The RFC6733 has clarified that only one instance of Failed-AVP AVP can be present in the command answer. One Failed-AVP AVP is enough because this AVP is defined as Grouped AVP that can contain multiple AVPs. In the present case, each of the nested AVPs in the Failed-AVP AVP are the AVPs that caused the failure. Instructions: ------------- This erratum is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party (IESG) can log in to change the status and edit the report, if necessary. -------------------------------------- RFC6733 (draft-ietf-dime-rfc3588bis-33) -------------------------------------- Title : Diameter Base Protocol Publication Date : October 2012 Author(s) : V. Fajardo, Ed., J. Arkko, J. Loughney, G. Zorn, Ed. Category : PROPOSED STANDARD Source : Diameter Maintenance and Extensions Area : Operations and Management Stream : IETF Verifying Party : IESG From nobody Fri Feb 5 13:48:36 2016 Return-Path: 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 5EF1B1B2D02 for ; Fri, 5 Feb 2016 13:48:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-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 OLSN8WQRmtE8 for ; Fri, 5 Feb 2016 13:48:33 -0800 (PST) Received: from mail-pf0-x22a.google.com (mail-pf0-x22a.google.com [IPv6:2607:f8b0:400e:c00::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0BC401AC438 for ; Fri, 5 Feb 2016 13:48:33 -0800 (PST) Received: by mail-pf0-x22a.google.com with SMTP id n128so74720097pfn.3 for ; Fri, 05 Feb 2016 13:48:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to:content-type:content-transfer-encoding; bh=K4amtTi6jWtc/nLiCoxIeQoTvxfDu1MD+BvSjFf1Jgs=; b=MOcqVnAYFh2x7KnpxoZh9CEUiVt6W3zR+xf76rkkuXL9u5TVNMhcbc+X8s4Q+EG515 ViOrPitkQgE7Pukk8ML7L3dcVHVw0mVmvraKcPxREAihWUTP9WovMGw/e0YDsUUxejgC SVfTrC5IrTbrC6wABberbLXMutrnBKA4/Xms1e4ucUdbFLlCYxPffkIMOSmcj+WPGGmD l1T+RF+SNpX9oCaNnspR/BKi5LcYHb0LVbKXoNtJxGYSpZydEfgCceY836KUIEBHYuRq s7fNG32wVfRUFnDDd7a5dcyjUPGzcn34Ef5GuSTeNaadoVvUc6qsBd1BFrDxod8wes1D 0Vbw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:cc:from:message-id:date :user-agent:mime-version:in-reply-to:content-type :content-transfer-encoding; bh=K4amtTi6jWtc/nLiCoxIeQoTvxfDu1MD+BvSjFf1Jgs=; b=KKbVSzrlRaRdJNcuReVn1l/vhP0cFlvszhWvC3eP0DybAE1qzkilViGigEqCDRJMuj oCOOelVc13bo112QhmYzLyD+5vXw5X+SBlS75uRbkqfXV8LBW7DuukQh3t1ElVXoY6qn jl1+vP0xm7Vtg49ZU0e0dZ3Qf7PksCcHUjKsJqKF8bWSkTgRplEKawXh+3nCGKzrKqnk T/zKEd9FrmIL/PbzUhcSJ0mXZlXNUi9ZgPq2g7EIPCrPbdt3ei4MAONlBtSD/IxOqJh6 Nkq/gZzjxomuGMQeUuvi9LcB06RNad5Hqgney2SQ5dbjtFy9gZiVFWSVRczEFI4B2vh8 50WQ== X-Gm-Message-State: AG10YOSomtHNN1IgtRAm5WNa6P3Xsz/iT66ykxBDYT5uIezXIfOTxa72yqz7vt4b9HFhXQ== X-Received: by 10.98.18.15 with SMTP id a15mr23298670pfj.145.1454708912669; Fri, 05 Feb 2016 13:48:32 -0800 (PST) Received: from [10.16.86.70] ([216.31.219.19]) by smtp.googlemail.com with ESMTPSA id l14sm26560259pfb.73.2016.02.05.13.48.30 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 05 Feb 2016 13:48:32 -0800 (PST) To: RFC Errata System , vf0213@gmail.com, jari.arkko@ericsson.com, john.loughney@nokia.com, glenzorn@gmail.com, bclaise@cisco.com, joelja@bogus.com, lionel.morand@orange.com References: <20160205185440.F3B23180208@rfc-editor.org> From: Jouni Korhonen Message-ID: <56B518AC.8010104@gmail.com> Date: Fri, 5 Feb 2016 13:48:28 -0800 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: <20160205185440.F3B23180208@rfc-editor.org> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: dime@ietf.org Subject: Re: [Dime] [Technical Errata Reported] RFC6733 (4615) X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Feb 2016 21:48:35 -0000 I think this errata is correct. - Jouni 2/5/2016, 10:54 AM, RFC Errata System kirjoitti: > The following errata report has been submitted for RFC6733, > "Diameter Base Protocol". > > -------------------------------------- > You may review the report below and at: > http://www.rfc-editor.org/errata_search.php?rfc=6733&eid=4615 > > -------------------------------------- > Type: Technical > Reported by: Lionel Morand > > Section: 7.1.5 > > Original Text > ------------- > DIAMETER_AVP_UNSUPPORTED 5001 > > The peer received a message that contained an AVP that is not > recognized or supported and was marked with the 'M' (Mandatory) > bit. A Diameter message with this error MUST contain one or more > Failed-AVP AVPs containing the AVPs that caused the failure. > > Corrected Text > -------------- > DIAMETER_AVP_UNSUPPORTED 5001 > > The peer received a message that contained an AVP that is not > recognized or supported and was marked with the 'M' (Mandatory) > bit. A Diameter message with this error MUST contain one > Failed-AVP AVP containing the AVPs that caused the failure. > > Notes > ----- > The RFC6733 has clarified that only one instance of Failed-AVP AVP can be present in the command answer. One Failed-AVP AVP is enough because this AVP is defined as Grouped AVP that can contain multiple AVPs. In the present case, each of the nested AVPs in the Failed-AVP AVP are the AVPs that caused the failure. > > Instructions: > ------------- > This erratum is currently posted as "Reported". If necessary, please > use "Reply All" to discuss whether it should be verified or > rejected. When a decision is reached, the verifying party (IESG) > can log in to change the status and edit the report, if necessary. > > -------------------------------------- > RFC6733 (draft-ietf-dime-rfc3588bis-33) > -------------------------------------- > Title : Diameter Base Protocol > Publication Date : October 2012 > Author(s) : V. Fajardo, Ed., J. Arkko, J. Loughney, G. Zorn, Ed. > Category : PROPOSED STANDARD > Source : Diameter Maintenance and Extensions > Area : Operations and Management > Stream : IETF > Verifying Party : IESG > From nobody Thu Feb 18 08:28:56 2016 Return-Path: X-Original-To: dime@ietf.org Delivered-To: dime@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id EF3FF1B2F14; Thu, 18 Feb 2016 08:28:46 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "\"IETF Meeting Session Request Tool\"" To: X-Test-IDTracker: no X-IETF-IDTracker: 6.14.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160218162846.29053.82797.idtracker@ietfa.amsl.com> Date: Thu, 18 Feb 2016 08:28:46 -0800 Archived-At: Cc: dime-chairs@ietf.org, dime@ietf.org, jounikor@gmail.com Subject: [Dime] dime - New Meeting Session Request for IETF 95 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Feb 2016 16:28:47 -0000 A new meeting session request has just been submitted by Jouni Korhonen, a Chair of the dime working group. --------------------------------------------------------- Working Group Name: Diameter Maintenance and Extensions Area Name: Operations and Management Area Session Requester: Jouni Korhonen Number of Sessions: 1 Length of Session(s): 2 Hours Number of Attendees: 35 Conflicts to Avoid: First Priority: stir abfab v6ops 6man oauth radext dmm mif detnet Special Requests: --------------------------------------------------------- From nobody Wed Feb 24 09:46:26 2016 Return-Path: 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 55AA91A1AFB for ; Wed, 24 Feb 2016 09:46:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.121 X-Spam-Level: X-Spam-Status: No, score=-1.121 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 t18RIfcv8tdA for ; Wed, 24 Feb 2016 09:46:23 -0800 (PST) Received: from biz131.inmotionhosting.com (biz131.inmotionhosting.com [173.247.247.250]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 207421B3582 for ; Wed, 24 Feb 2016 09:46:23 -0800 (PST) Received: from [195.235.52.97] (port=58459 helo=Steves-MacBook-Air.local) by biz131.inmotionhosting.com with esmtpsa (TLSv1.2:DHE-RSA-AES256-SHA:256) (Exim 4.86) (envelope-from ) id 1aYdW0-0027k3-Nh for dime@ietf.org; Wed, 24 Feb 2016 09:46:22 -0800 To: dime@ietf.org References: <18555_1450866365_567A76BD_18555_7990_1_6B7134B31289DC4FAF731D844122B36E01D93ACB@OPEXCLILM43.corporate.adroot.infra.ftgroup> From: Steve Donovan Message-ID: <56CDEC6B.2050400@usdonovans.com> Date: Wed, 24 Feb 2016 18:46:19 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 In-Reply-To: <18555_1450866365_567A76BD_18555_7990_1_6B7134B31289DC4FAF731D844122B36E01D93ACB@OPEXCLILM43.corporate.adroot.infra.ftgroup> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-OutGoing-Spam-Status: No, score=-2.1 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 X-Authenticated-Sender: biz131.inmotionhosting.com: srdonovan@usdonovans.com Archived-At: Subject: Re: [Dime] Start of the WGLC on draft-ietf-dime-drmp-02 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Feb 2016 17:46:24 -0000 In reply to the IPR questions below, I know of no IPR that applies to the DRMP draft. Regards, Steve On 12/23/15 11:26 AM, lionel.morand@orange.com wrote: > As agreed during the Dime session at IETF94, a Working Group Last Call is asked on the following document: > > https://tools.ietf.org/html/draft-ietf-dime-drmp-02 > > Please respond to this email to support the document and/or send comments by 2016-01-20. > > As this WGLC is initiated during the Xmas/end-of-year break, the WGLC period is extended to 4 weeks. > For reviewer of the document, don't forget to state if you are fine with the document even if there is no comment. It is important for evaluating the quality of the document and gauge the WG consensus. > > In addition, following the strategy for promoting compliance with the IPR disclosure rules (RFC6702), the chairs would like to check whether there are claims of Intellectual Property Rights (IPR) on the document that need to be disclosed. Therefore, the following questions are addressed to the WG and Especially Authors and Contributors of the draft: > > * Are you personally aware of any IPR that applies to draft-ietf-dime-drmp-02? If so, has this IPR been disclosed in compliance with IETF IPR rules? (See RFCs 3979, 4879, 3669, and 5378 for more details.) > > * If you are a document author or listed contributor on this document, please reply to this email message regardless of whether or not you are personally aware of any relevant IPR. We might not be able to advance this document to the next stage until we have received a reply from each author and listed contributor. > > * If you are on the DIME WG email list but are not an author or listed contributor for this document, you are reminded of your opportunity for a voluntary IPR disclosure under BCP 79. Please do not reply unless you want to make such a voluntary disclosure. > > Online tools for filing IPR disclosures can be found at . > > Regards, > > Lionel and Jouni > > _________________________________________________________________________________________________________________________ > > 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 > https://www.ietf.org/mailman/listinfo/dime