From nobody Mon Jan 4 13:14:46 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 562D71ABD38 for ; Mon, 4 Jan 2016 13:14:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] 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 oDQYSRC9Q9Sx for ; Mon, 4 Jan 2016 13:14:43 -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 56F2E1ABD36 for ; Mon, 4 Jan 2016 13:14:43 -0800 (PST) Received: from mutabilis-2.local (pool-96-226-213-187.dllstx.fios.verizon.net [96.226.213.187]) (authenticated bits=0) by nostrum.com (8.15.2/8.14.9) with ESMTPSA id u04LEgnB064611 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Mon, 4 Jan 2016 15:14:42 -0600 (CST) (envelope-from mahoney@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host pool-96-226-213-187.dllstx.fios.verizon.net [96.226.213.187] claimed to be mutabilis-2.local To: lionel.morand@orange.com, "dime@ietf.org" , srdonovan@usdonovans.com References: <18555_1450866365_567A76BD_18555_7990_1_6B7134B31289DC4FAF731D844122B36E01D93ACB@OPEXCLILM43.corporate.adroot.infra.ftgroup> From: "A. Jean Mahoney" Message-ID: <568AE0C1.9080600@nostrum.com> Date: Mon, 4 Jan 2016 15:14:41 -0600 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:38.0) Gecko/20100101 Thunderbird/38.5.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 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, 04 Jan 2016 21:14:45 -0000 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. 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. 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. 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 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 > From nobody Wed Jan 13 12:23:12 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 93C171B31F8; Wed, 13 Jan 2016 12:23:09 -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.12.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160113202309.27606.22361.idtracker@ietfa.amsl.com> Date: Wed, 13 Jan 2016 12:23:09 -0800 Archived-At: Cc: dime@ietf.org Subject: [Dime] I-D Action: draft-ietf-dime-e2e-sec-req-04.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: Wed, 13 Jan 2016 20:23:10 -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 AVP Level Security End-to-End Security: Scenarios and Requirements Authors : Hannes Tschofenig Jouni Korhonen Glen Zorn Kervin Pillay Filename : draft-ietf-dime-e2e-sec-req-04.txt Pages : 9 Date : 2016-01-13 Abstract: This specification discusses requirements for providing Diameter security at the level of individual Attribute-Value Pairs. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-dime-e2e-sec-req/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-dime-e2e-sec-req-04 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-dime-e2e-sec-req-04 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 carlos.fangmeier@gmail.com Fri Jan 15 04:27:42 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 49F0B1B2C16 for ; Fri, 15 Jan 2016 04:27:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.6 X-Spam-Level: X-Spam-Status: No, score=-0.6 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, 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 ghMt1DWhF6Zi for ; Fri, 15 Jan 2016 04:27:41 -0800 (PST) Received: from mail-qk0-x22e.google.com (mail-qk0-x22e.google.com [IPv6:2607:f8b0:400d:c09::22e]) (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 185951B2C15 for ; Fri, 15 Jan 2016 04:27:41 -0800 (PST) Received: by mail-qk0-x22e.google.com with SMTP id q19so261766388qke.3 for ; Fri, 15 Jan 2016 04:27:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=ulXNiCCzQDERmRdHWYt/8gdqeM3sJTRuakpCYc+dyMY=; b=QeIUEqde9aSDJii5oER/DzMxT+eAxia+erQH9avhEs4NdPFhv48vD1GPVCjTmo30xa dEc3BFcI6xtJLuedF4OCq+LQhn9KuxzJ5gpeHE2uGxI1sSLKpm1o6X4QfMV7POhxaeQo Q2c0fBarZ9K2Qf/yZwbBXJ6FQGrryBfSoKopFsKMXuXGOsUhJUxLQAVWOizFKqICiWzq 2i/5eVCCCnIrW6g1pTMEdtEoH85c3MkwyqQmV8mCILI5HDcQc9m5iaCPQyFvAKlJtCkq O1vEbh3qzt1xEvQD5kYCowW5WwY75NyQvBFXU207pbGxkUdgpmQOGbzWH5Y9Eq8b2Nfn K8wA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:date:message-id:subject:from:to :content-type; bh=ulXNiCCzQDERmRdHWYt/8gdqeM3sJTRuakpCYc+dyMY=; b=bsQpg/GhkmZ7OzKiKeOlZKQC7xDT8ovNE0Y5ZjKG3GhaMRUSkJgI40El5OUBJiCycQ YdWevKF9V3PNrGv4jYrhpxJNX5Qf++jVuqERb2yzAoQB0uNa409+zDMfGrBp2B23RgQi 3WbyhL65+b7K/gzTPEAOC5tPqCf0uOoAN/+oXY1XCPXhE+FkFDStSggLmHP9iU+HKW53 WSWqo1Vak51GgNS2clWxPLLD4AmgbLw8ZFj3AzZIDYWzwPz8WMKN69pHhBwtUD5+5HGs 8TZqzftqw5LAcC/pHdyXeJ9QGQLykGdIMJsVkv+fHrf/9WXReGb/ud+qCozDIweDKBtS WGpA== X-Gm-Message-State: ALoCoQkq5LbljXdVI0R19/nKkgfQ8J5xOUg9GnS2Y8fnAsBsD4QmC1k5wFbasnaXCZB7a13OX8XPUnbC6aY1f5XReXQE3eULGg== MIME-Version: 1.0 X-Received: by 10.55.71.135 with SMTP id u129mr13028773qka.26.1452860860273; Fri, 15 Jan 2016 04:27:40 -0800 (PST) Received: by 10.55.53.14 with HTTP; Fri, 15 Jan 2016 04:27:40 -0800 (PST) Date: Fri, 15 Jan 2016 09:27:40 -0300 Message-ID: From: Carlos Fangmeier To: dime@ietf.org Content-Type: text/plain; charset=UTF-8 Archived-At: X-Mailman-Approved-At: Fri, 15 Jan 2016 06:17:54 -0800 Subject: [Dime] Enumerated Type 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, 15 Jan 2016 12:29:04 -0000 Hi everyone In my work I implemented a diameter serializer/des-serializer from/to a human readable json-like data structure. It is based on a dynamic engine, capable of reading the message structure direct from the ABNF command code specifictaion. During the coding I realized that the diameter abnf grammar do not consider a way to define the associated tags (human readable) for each posbile value of a enumerated type. With a light modification to the grammar it is possible to achieve it, and it gave the capability to my serializer to validate and translate the value from/to the human readable form. Is this functionality beyond the scope of the diameter specification, or is there a reason for not including it? Thanks for your comments. Carlos Fangmeier From nobody Wed Jan 27 09:19:53 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 9AB8A1ACE81 for ; Wed, 27 Jan 2016 09:19:52 -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 DYHZLVyOIT0M for ; Wed, 27 Jan 2016 09:19:51 -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 01B811ACE7F for ; Wed, 27 Jan 2016 09:19:50 -0800 (PST) Received: from cpe-97-99-50-102.tx.res.rr.com ([97.99.50.102]:52618 helo=Steves-MacBook-Air.local) by biz131.inmotionhosting.com with esmtpsa (TLSv1.2:RC4-SHA:128) (Exim 4.85) (envelope-from ) id 1aOTkw-0047pG-UP; Wed, 27 Jan 2016 09:19:48 -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> From: Steve Donovan Message-ID: <56A8FC32.8020209@usdonovans.com> Date: Wed, 27 Jan 2016 11:19:46 -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: <568AE0C1.9080600@nostrum.com> Content-Type: text/plain; charset=windows-1252; 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: 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, 27 Jan 2016 17:19:52 -0000 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." > > 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. > > 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. > > 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 >> From nobody Wed Jan 27 09:29:40 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 741AF1ACE90 for ; Wed, 27 Jan 2016 09:29:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.58 X-Spam-Level: * X-Spam-Status: No, score=1.58 tagged_above=-999 required=5 tests=[BAYES_50=0.8, 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 J_IR1q-HL9P5 for ; Wed, 27 Jan 2016 09:29:35 -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 98F4E1ACE6B for ; Wed, 27 Jan 2016 09:29:35 -0800 (PST) Received: from cpe-97-99-50-102.tx.res.rr.com ([97.99.50.102]:52675 helo=Steves-MacBook-Air.local) by biz131.inmotionhosting.com with esmtpsa (TLSv1.2:RC4-SHA:128) (Exim 4.85) (envelope-from ) id 1aOTuO-004G0C-KR for dime@ietf.org; Wed, 27 Jan 2016 09:29:35 -0800 To: dime@ietf.org References: <18555_1450866365_567A76BD_18555_7990_1_6B7134B31289DC4FAF731D844122B36E01D93ACB@OPEXCLILM43.corporate.adroot.infra.ftgroup> From: Steve Donovan Message-ID: <56A8FE7B.3030206@usdonovans.com> Date: Wed, 27 Jan 2016 11:29:31 -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: Content-Type: multipart/alternative; boundary="------------090000090503080803060305" 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] late comments Re: 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, 27 Jan 2016 17:29:38 -0000 This is a multi-part message in MIME format. --------------090000090503080803060305 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Janet, Thanks for the review. See my comments inline. Regards, Steve On 12/30/15 1:26 PM, Janet P Gunn wrote: > A couple of late comments- > > I thought I had commented on this before (in the first draft), but > maybe it got lost. > > In sec 5.1 it says: > > The United States Wireless Priority Services (WPS) and Government > Emergency Telecommunications Service (GETS) are examples of systems > designed to address these first responder needs. > > But this is not accurate. GETS and WPS are used by the First > Responder “Command/Management”, but NOT by the First Responder “Rank > and File”. > > The web pages for WPS ( > http://www.dhs.gov/wireless-priority-service-wps) and GETS ( > _http://www.dhs.gov/government-emergency-telecommunications-service-gets_) > say that typical users are “responsible for the command and control > functions critical to management of and response to national security > and emergency situations, particularly during the first 24 to 72 hours > following an event.” > > So the Fire Chief might use WPS/GETS to call the local hospital (or > an individual firefighter), or the hospital administrator might use > WPS/GETS to call the State Health Department (or an individual > doctor), but individual firefighters would not use WPS/GETS to call > each other. > > You might want to contact the ECRIT working group for examples of > priority systems that DO support the front-line firefighters, etc. > > My suggestion for rewording the paragraph is > > The United States Wireless Priority Services (WPS) and Government > Emergency Telecommunications Service (GETS) are examples of systems > designed to address the command and control aspects of these first > responder needs. > SRD> Change made. > --- > > For section 5.2 Emergency Call Related Signaling, I would also suggest > that you coordinate with ECRIT for appropriate wording. In the “911” > world, the bottleneck (scarce resource) is the people to answer the > phone. Sometimes it is counterproductive to improve the probability > of success earlier in the call path, as it makes the congestion at the > PSAP itself worse. > SRD> We can pass this by ECRIT but this isn't just about making the calls setup faster, it is about helping to ensure that it is successful in the first place, especially in the face of an overloaded network. > --- > > Security > I am not a security expert, but I expect the security section needs to > be beefed up. As it says in RFC4412: > > > Any resource priority mechanism can be abused to obtain resources and > thus deny service to other users. An adversary may be able to take > over a particular PSTN gateway, cause additional congestion during > emergencies affecting the PSTN, or deny service to legitimate users. > In SIP end systems, such as IP phones, this mechanism could > inappropriately terminate existing sessions and calls. > > Thus, while the indication itself does not have to provide separate > authentication, SIP requests containing this header are very likely > to have higher authentication requirements than those without. > > I would expect similar verbiage would be appropriate for Diameter. > SRD> Agreed, I'll proposed a beefed up security section. > --- > > Editorial nit > In the introduction, I think that this sentence > “As such, all requests are treated the same meaning that all > requests have the same probability of being throttled.” > Would read better with a comma > “As such, all requests are treated the same, meaning that all > requests have the same probability of being throttled.” SRD> Agreed. > > > Happy New Year everyone, > > Janet > > > This electronic message transmission contains information from CSRA > that may be attorney-client privileged, proprietary or confidential. > The information in this message is intended only for use by the > individual(s) to whom it is addressed. If you believe you have > received this message in error, please contact me immediately and be > aware that any use, disclosure, copying or distribution of the > contents of this message is strictly prohibited. NOTE: Regardless of > content, this email shall not operate to bind CSRA to any order or > other contract unless pursuant to explicit written agreement or > government initiative expressly permitting the use of email for such > purpose. > > > > From: > To: "dime@ietf.org" > Date: 12/23/2015 05:26 AM > Subject: [Dime] Start of the WGLC on draft-ietf-dime-drmp-02 > Sent by: "DiME" > ------------------------------------------------------------------------ > > > > 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 > > > > > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime --------------090000090503080803060305 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit Janet,

Thanks for the review.

See my comments inline.

Regards,

Steve

On 12/30/15 1:26 PM, Janet P Gunn wrote:
A couple of late comments-

I thought I had commented on this before (in the first draft), but maybe it got lost.

In sec 5.1 it says:

   The United States Wireless Priority Services (WPS) and Government
   Emergency Telecommunications Service (GETS) are examples of systems
   designed to address these first responder needs.

But this is not accurate.  GETS and WPS are used by the First Responder “Command/Management”, but NOT by the First Responder “Rank and File”.

The web pages for WPS  ( http://www.dhs.gov/wireless-priority-service-wps ) and GETS ( http://www.dhs.gov/government-emergency-telecommunications-service-gets ) say that typical users are “responsible for the command and control functions critical to management of and response to national security and emergency situations, particularly during the first 24 to 72 hours following an event.”

So the Fire  Chief might use WPS/GETS to call the local hospital (or an individual firefighter), or the hospital administrator might use WPS/GETS to call the State Health Department (or an individual doctor), but individual  firefighters would not use WPS/GETS to call each other.

You might want to contact the ECRIT working group for examples of priority systems that DO support the front-line  firefighters, etc.

My suggestion for rewording the paragraph is

   The United States Wireless Priority Services (WPS) and Government
   Emergency Telecommunications Service (GETS) are examples of systems
   designed to address the command and control aspects of these first
   responder needs.

SRD> Change made.
---

For section 5.2 Emergency Call Related Signaling, I would also suggest that you coordinate with ECRIT for appropriate wording.  In the “911” world, the bottleneck (scarce resource) is the people to answer the phone.  Sometimes it is counterproductive to improve the probability of success earlier in the call path, as it makes the congestion at the PSAP itself worse.

SRD> We can pass this by ECRIT but this isn't just about making the calls setup faster, it is about helping to ensure that it is successful in the first place, especially in the face of an overloaded network.
---

Security
I am not a security expert, but I expect the security section needs to be beefed up.  As it says in  RFC4412:


   Any resource priority mechanism can be abused to obtain resources and
   thus deny service to other users.  An adversary may be able to take
   over a particular PSTN gateway, cause additional congestion during
   emergencies affecting the PSTN, or deny service to legitimate users.
   In SIP end systems, such as IP phones, this mechanism could
   inappropriately terminate existing sessions and calls.

   Thus, while the indication itself does not have to provide separate
   authentication, SIP requests containing this header are very likely
   to have higher authentication requirements than those without.

I would expect similar verbiage would be appropriate for Diameter.

SRD> Agreed, I'll proposed a beefed up security section.
---

Editorial nit
 In the introduction, I think that this sentence
   “As such, all requests are treated the same meaning that all requests have the same probability of being  throttled.”
Would read better with a comma
   “As such, all requests are treated the same, meaning that all requests have the same probability of being  throttled.”
SRD> Agreed.


Happy New Year everyone,

Janet


This electronic message transmission contains information from CSRA that may be attorney-client privileged, proprietary or confidential. The information in this message is intended only for use by the individual(s) to whom it is addressed. If you believe you have received this message in error, please contact me immediately and be aware that any use, disclosure, copying or distribution of the contents of this message is strictly prohibited. NOTE: Regardless of content, this email shall not operate to bind CSRA to any order or other contract unless pursuant to explicit written agreement or government initiative expressly permitting the use of email for such purpose.



From:        <lionel.morand@orange.com>
To:        "dime@ietf.org" <dime@ietf.org>
Date:        12/23/2015 05:26 AM
Subject:        [Dime] Start of the WGLC on draft-ietf-dime-drmp-02
Sent by:        "DiME" <dime-bounces@ietf.org>



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  <http://www.ietf.org/ipr/file-disclosure>.

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
 



_______________________________________________
DiME mailing list
DiME@ietf.org
https://www.ietf.org/mailman/listinfo/dime

--------------090000090503080803060305-- From nobody Wed Jan 27 09:34:54 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 F3C6C1ACEDB for ; Wed, 27 Jan 2016 09:34:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 3dk3VSEtHhHc for ; Wed, 27 Jan 2016 09:34:50 -0800 (PST) Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F0F911ACED1 for ; Wed, 27 Jan 2016 09:34:49 -0800 (PST) Received: from omfedm08.si.francetelecom.fr (unknown [xx.xx.xx.4]) by omfedm13.si.francetelecom.fr (ESMTP service) with ESMTP id 4470D324769; Wed, 27 Jan 2016 18:34:48 +0100 (CET) Received: from Exchangemail-eme2.itn.ftgroup (unknown [10.114.31.72]) by omfedm08.si.francetelecom.fr (ESMTP service) with ESMTP id 2474923805C; Wed, 27 Jan 2016 18:34:48 +0100 (CET) Received: from OPEXCLILM43.corporate.adroot.infra.ftgroup ([fe80::ec23:902:c31f:731c]) by OPEXCLILMA3.corporate.adroot.infra.ftgroup ([fe80::60a9:abc3:86e6:2541%19]) with mapi id 14.03.0279.002; Wed, 27 Jan 2016 18:34:47 +0100 From: To: Steve Donovan , "A. Jean Mahoney" , "dime@ietf.org" Thread-Topic: [Dime] Start of the WGLC on draft-ietf-dime-drmp-02 Thread-Index: AdE9bEbx1NqYzGIyRLmltZgFdBSuTwJwERCABHx/jwAAAmKmIA== Date: Wed, 27 Jan 2016 17:34:47 +0000 Message-ID: <10248_1453916088_56A8FFB8_10248_54_1_6B7134B31289DC4FAF731D844122B36E01DBD108@OPEXCLILM43.corporate.adroot.infra.ftgroup> References: <18555_1450866365_567A76BD_18555_7990_1_6B7134B31289DC4FAF731D844122B36E01D93ACB@OPEXCLILM43.corporate.adroot.infra.ftgroup> <568AE0C1.9080600@nostrum.com> <56A8FC32.8020209@usdonovans.com> In-Reply-To: <56A8FC32.8020209@usdonovans.com> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.1] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 6.2.1.2478543, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2015.12.9.132716 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, 27 Jan 2016 17:34:53 -0000 Hi Steve, 1 comment and 1 question below. Regards, Lionel -----Message d'origine----- De=A0: Steve Donovan [mailto:srdonovan@usdonovans.com]=20 Envoy=E9=A0: mercredi 27 janvier 2016 18:20 =C0=A0: A. Jean Mahoney; MORAND Lionel IMT/OLN; dime@ietf.org Objet=A0: 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=20 > that someone in ecrit should take a look at it, and with Lionel's=20 > 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=20 > is app-specific. Maybe add some words here and in Section 8 to that=20 > 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". > > Section 8: > > Section 6 talks about nodes saving priority information found in the=20 > request's DRMP AVP with the transaction state, and then checking it if=20 > the AVP is absent in the Diameter answer. This info should be captured=20 > 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 i= t 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? > > 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. > > 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=20 >> 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=20 >> comments by 2016-01-20. >> >> As this WGLC is initiated during the Xmas/end-of-year break, the WGLC=20 >> period is extended to 4 weeks. For reviewer of the document, don't=20 >> forget to state if you are fine with the document even if there is no=20 >> comment. It is important for evaluating the quality of the document=20 >> and gauge the WG consensus. >> >> In addition, following the strategy for promoting compliance with the=20 >> IPR disclosure rules (RFC6702), the chairs would like to check=20 >> whether there are claims of Intellectual Property Rights (IPR) on the=20 >> document that need to be disclosed. Therefore, the following=20 >> questions are addressed to the WG and Especially Authors and=20 >> Contributors of the draft: >> >> * Are you personally aware of any IPR that applies to=20 >> draft-ietf-dime-drmp-02? If so, has this IPR been disclosed in=20 >> compliance with IETF IPR rules? (See RFCs 3979, 4879, 3669, and 5378=20 >> for more details.) >> >> * If you are a document author or listed contributor on this=20 >> document, please reply to this email message regardless of whether or=20 >> not you are personally aware of any relevant IPR. We might not be=20 >> able to advance this document to the next stage until we have=20 >> received a reply from each author and listed contributor. >> >> * If you are on the DIME WG email list but are not an author or=20 >> listed contributor for this document, you are reminded of your=20 >> opportunity for a voluntary IPR disclosure under BCP 79. Please do=20 >> not reply unless you want to make such a voluntary disclosure. >> >> Online tools for filing IPR disclosures can be found at=20 >> . >> >> Regards, >> >> Lionel and Jouni >> >> _____________________________________________________________________ >> ____________________________________________________ >> >> >> Ce message et ses pieces jointes peuvent contenir des informations=20 >> confidentielles ou privilegiees et ne doivent donc pas etre diffuses,=20 >> exploites ou copies sans autorisation. Si vous avez recu ce message=20 >> par erreur, veuillez le signaler a l'expediteur et le detruire ainsi=20 >> que les pieces jointes. Les messages electroniques etant susceptibles=20 >> d'alteration, Orange decline toute responsabilite si ce message a ete=20 >> altere, deforme ou falsifie. Merci. >> >> This message and its attachments may contain confidential or=20 >> privileged information that may be protected by law; they should not=20 >> be distributed, used or copied without authorisation. If you have=20 >> received this email in error, please notify the sender and delete=20 >> this message and its attachments. As emails may be altered, Orange is=20 >> not liable for messages that have been modified, changed or=20 >> falsified. Thank you. >> >> _______________________________________________ DiME mailing list=20 >> DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime >> ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles 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 el= ectroniques 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 inf= ormation 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 dele= te 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 Wed Jan 27 09:56:59 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 7C76D1ACEA7 for ; Wed, 27 Jan 2016 09:56:58 -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 1OpqiEIpcCCd for ; Wed, 27 Jan 2016 09:56:56 -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 B61CB1AD2DF for ; Wed, 27 Jan 2016 09:56:56 -0800 (PST) Received: from cpe-97-99-50-102.tx.res.rr.com ([97.99.50.102]:52877 helo=Steves-MacBook-Air.local) by biz131.inmotionhosting.com with esmtpsa (TLSv1.2:RC4-SHA:128) (Exim 4.85) (envelope-from ) id 1aOUKs-000Fi5-FD; Wed, 27 Jan 2016 09:56:56 -0800 To: lionel.morand@orange.com, "A. Jean Mahoney" , "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> From: Steve Donovan Message-ID: <56A904E5.4040405@usdonovans.com> Date: Wed, 27 Jan 2016 11:56:53 -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: <10248_1453916088_56A8FFB8_10248_54_1_6B7134B31289DC4FAF731D844122B36E01DBD108@OPEXCLILM43.corporate.adroot.infra.ftgroup> 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: Wed, 27 Jan 2016 17:56:58 -0000 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? > >> 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. > >> 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. >> 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. > From nobody Wed Jan 27 10:28:12 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 C18C41B2A9F for ; Wed, 27 Jan 2016 10:28:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RP_MATCHES_RCVD=-0.001, 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 uFR8quwnNcA0 for ; Wed, 27 Jan 2016 10:28:09 -0800 (PST) Received: from relais-inet.orange.com (relais-nor34.orange.com [80.12.70.34]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5C5FE1B2A99 for ; Wed, 27 Jan 2016 10:28:01 -0800 (PST) Received: from opfednr02.francetelecom.fr (unknown [xx.xx.xx.66]) by opfednr21.francetelecom.fr (ESMTP service) with ESMTP id 97FADC027A; Wed, 27 Jan 2016 19:27:59 +0100 (CET) Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.24]) by opfednr02.francetelecom.fr (ESMTP service) with ESMTP id 6F464120055; Wed, 27 Jan 2016 19:27:59 +0100 (CET) Received: from OPEXCLILM43.corporate.adroot.infra.ftgroup ([fe80::ec23:902:c31f:731c]) by OPEXCLILM7D.corporate.adroot.infra.ftgroup ([fe80::9044:c5ee:4dd2:4f16%19]) with mapi id 14.03.0279.002; Wed, 27 Jan 2016 19:27:59 +0100 From: To: Steve Donovan , "A. Jean Mahoney" , "dime@ietf.org" Thread-Topic: [Dime] Start of the WGLC on draft-ietf-dime-drmp-02 Thread-Index: AdE9bEbx1NqYzGIyRLmltZgFdBSuTwJwERCABHx/jwAAAmKmIP//90mA///nOdA= Date: Wed, 27 Jan 2016 18:27:58 +0000 Message-ID: <6309_1453919279_56A90C2F_6309_7518_1_6B7134B31289DC4FAF731D844122B36E01DBD22A@OPEXCLILM43.corporate.adroot.infra.ftgroup> 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> In-Reply-To: <56A904E5.4040405@usdonovans.com> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.1] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 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, 27 Jan 2016 18:28:11 -0000 Steve, See below. Lionel -----Message d'origine----- De=A0: Steve Donovan [mailto:srdonovan@usdonovans.com]=20 Envoy=E9=A0: mercredi 27 janvier 2016 18:57 =C0=A0: MORAND Lionel IMT/OLN; A. Jean Mahoney; dime@ietf.org Objet=A0: 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=E9 : mercredi= =20 > 27 janvier 2016 18:20 =C0 : A. Jean Mahoney; MORAND Lionel IMT/OLN;=20 > dime@ietf.org Objet : Re: [Dime] Start of the WGLC on=20 > 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=20 >> that someone in ecrit should take a look at it, and with Lionel's=20 >> 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=20 >> is app-specific. Maybe add some words here and in Section 8 to that=20 >> 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. > >> Section 8: >> >> Section 6 talks about nodes saving priority information found in the=20 >> request's DRMP AVP with the transaction state, and then checking it=20 >> if the AVP is absent in the Diameter answer. This info should be=20 >> 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 an= d no related normative behaviour. Could you explain why you are reluctant t= o say that the priority value indicated in the request is saved? SRD> Section 6 is non normative and, as such, only an example.=20 Specifying this in the normative section would eliminate other methods of d= etermining the value received in the request. For instance, a stateless ag= ent might choose to include the value in a Proxy-Info AVP. [LM] Good point. Could be good to indicate both options in your example. > >> 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. >> 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=20 >>> 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=20 >>> comments by 2016-01-20. >>> >>> As this WGLC is initiated during the Xmas/end-of-year break, the=20 >>> WGLC period is extended to 4 weeks. For reviewer of the document,=20 >>> don't forget to state if you are fine with the document even if=20 >>> there is no comment. It is important for evaluating the quality of=20 >>> the document and gauge the WG consensus. >>> >>> In addition, following the strategy for promoting compliance with=20 >>> the IPR disclosure rules (RFC6702), the chairs would like to check=20 >>> whether there are claims of Intellectual Property Rights (IPR) on=20 >>> the document that need to be disclosed. Therefore, the following=20 >>> questions are addressed to the WG and Especially Authors and=20 >>> Contributors of the draft: >>> >>> * Are you personally aware of any IPR that applies to=20 >>> draft-ietf-dime-drmp-02? If so, has this IPR been disclosed in=20 >>> compliance with IETF IPR rules? (See RFCs 3979, 4879, 3669, and=20 >>> 5378 for more details.) >>> >>> * If you are a document author or listed contributor on this=20 >>> document, please reply to this email message regardless of whether=20 >>> or not you are personally aware of any relevant IPR. We might not=20 >>> be able to advance this document to the next stage until we have=20 >>> received a reply from each author and listed contributor. >>> >>> * If you are on the DIME WG email list but are not an author or=20 >>> listed contributor for this document, you are reminded of your=20 >>> opportunity for a voluntary IPR disclosure under BCP 79. Please do=20 >>> not reply unless you want to make such a voluntary disclosure. >>> >>> Online tools for filing IPR disclosures can be found at=20 >>> . >>> >>> Regards, >>> >>> Lionel and Jouni >>> >>> ____________________________________________________________________ >>> _ ____________________________________________________ >>> >>> >>> Ce message et ses pieces jointes peuvent contenir des informations=20 >>> confidentielles ou privilegiees et ne doivent donc pas etre=20 >>> diffuses, exploites ou copies sans autorisation. Si vous avez recu=20 >>> ce message par erreur, veuillez le signaler a l'expediteur et le=20 >>> detruire ainsi que les pieces jointes. Les messages electroniques=20 >>> etant susceptibles d'alteration, Orange decline toute responsabilite=20 >>> si ce message a ete altere, deforme ou falsifie. Merci. >>> >>> This message and its attachments may contain confidential or=20 >>> privileged information that may be protected by law; they should not=20 >>> be distributed, used or copied without authorisation. If you have=20 >>> received this email in error, please notify the sender and delete=20 >>> this message and its attachments. As emails may be altered, Orange=20 >>> is not liable for messages that have been modified, changed or=20 >>> falsified. Thank you. >>> >>> _______________________________________________ DiME mailing list=20 >>> DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime >>> > > ______________________________________________________________________ > ___________________________________________________ > > Ce message et ses pieces jointes peuvent contenir des informations=20 > confidentielles ou privilegiees et ne doivent donc pas etre diffuses,=20 > exploites ou copies sans autorisation. Si vous avez recu ce message=20 > par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que = les pieces jointes. Les messages electroniques etant susceptibles d'alterat= ion, Orange decline toute responsabilite si ce message a ete altere, deform= e ou falsifie. Merci. > > This message and its attachments may contain confidential or=20 > privileged information that may be protected by law; they should not be d= istributed, used or copied without authorisation. > If you have received this email in error, please notify the sender and de= lete this message and its attachments. > As emails may be altered, Orange is not liable for messages that have bee= n modified, changed or falsified. > Thank you. > ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles 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 el= ectroniques 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 inf= ormation 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 dele= te 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 Wed Jan 27 12:35:57 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 D98E91A90D8 for ; Wed, 27 Jan 2016 12:35:55 -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 3neAjsQHKpjX for ; Wed, 27 Jan 2016 12:35:53 -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 4CCF11A9101 for ; Wed, 27 Jan 2016 12:35:53 -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 u0RKZqVk094425 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Wed, 27 Jan 2016 14:35:52 -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: lionel.morand@orange.com, Steve Donovan , "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> From: "A. Jean Mahoney" Message-ID: <56A92A28.1090905@nostrum.com> Date: Wed, 27 Jan 2016 14:35:52 -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: <6309_1453919279_56A90C2F_6309_7518_1_6B7134B31289DC4FAF731D844122B36E01DBD22A@OPEXCLILM43.corporate.adroot.infra.ftgroup> 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: Wed, 27 Jan 2016 20:35:56 -0000 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. >> >>> 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. >> >>> 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. >