Re: [Dime] Adam Roach's No Objection on draft-ietf-dime-rfc4006bis-08: (with COMMENT)
Yuval Lifshitz <yuvalif@yahoo.com> Thu, 24 May 2018 05:36 UTC
Return-Path: <yuvalif@yahoo.com>
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AB1E3126FDC for <dime@ietfa.amsl.com>; Wed, 23 May 2018 22:36:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Level:
X-Spam-Status: No, score=-1.998 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yahoo.com
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 KkT9_5m5d6Wz for <dime@ietfa.amsl.com>; Wed, 23 May 2018 22:36:28 -0700 (PDT)
Received: from sonic309-15.consmr.mail.bf2.yahoo.com (sonic309-15.consmr.mail.bf2.yahoo.com [74.6.129.125]) (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 E274D1241FC for <dime@ietf.org>; Wed, 23 May 2018 22:36:26 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1527140186; bh=3+4nELbWUi8NC3HYmXLPkpu+OFc9kg4Lr1DmvuGrjAI=; h=Date:From:To:Cc:In-Reply-To:References:Subject:From:Subject; b=kRwbPQT1PvKnUCBGJWoeoBA2ieJ9DZlSsKK843OdjKfrXTQM1AOgXuU0GKdigdmmddXLM98b2v+471ImZjtrA5afMHc2vDQbXe1fCn5Zs8LPCFU7/BoX1VIGkRGwdfa6D1se/VWTzzCNre/Hcg+pAogVmZ+6Qg5lHzJtPD9iBQ6tF26BH5ADOkA616DyhBRueK7BjV0kHEcMa9uJAscTUl74qd3A+i70C1ggH21FdzEQJ/vSGzigrnicZD+op/Z1+NaOcOj0MBj6DgofL2hToBykTvBWdCNRpFdmMc0Xmv/colZRGNBXmnFsXbUvvqAamVeHIMJEUEQ39ecUKaKFWw==
X-YMail-OSG: 5Dx.X2QVM1lK3t7bplcTZJZcTjh3mkR2QmRkYHZj1YVRM4ztAPQxbWXXExgDXOU dGTOii_dFQSp7.t5eSPEwYP1.mkOLxdRIG0bh8MOiw4mOE5HCrg1g43FnJl42FzpyiX3mXWEa02s p5tJuL_ITbQQecUt3Wt1k3Mj3L4MibkwAutke0FSCzbEs2i8BOoJjLmj7MwxSPD0wqh3VRCOhIZQ .fWGgoxDFLGP6Fhlj6eMyc7PsfjGjOKCBuFQBgLmlMhoPTffQgkrT.2V5B2a1FFNU..st3Zwd.kC G66ppnJ2UCTowBUAzk907fbLvGHDrJ3ZQGqAQYWLwiAUBYooQGtb0FKjmU2xIBqJ.cG9jpK.e1Q_ 5ahk607k6aLrmebg4Fkwx9N.K_F5jZyyqaV9wAlhUNC1TctcCTxNeuinW9afxMKq6kAi6m2EFcjv lBPXvzVboBJBJbYHw2ISktGGJwH4OyoZ6eI6To26QgRWfykuwfmAfIA.CSYke9RCQnZlDUm4cxFL ao3ZpCYmfLiI33.nv0560eme7j_0qu706zwvnXHJK9LJ6BFtEbdLzFyL6cCgqX.mfMwUi1RayHY8 _oH.aL2mltPA20aEpHku684dnZV5pd_iRJfKsH3jPNEo9aO2RcfnIsXG.5ceXSpW_lCo5Ws4MMWr o5w--
Received: from sonic.gate.mail.ne1.yahoo.com by sonic309.consmr.mail.bf2.yahoo.com with HTTP; Thu, 24 May 2018 05:36:26 +0000
Date: Thu, 24 May 2018 05:26:23 +0000
From: Yuval Lifshitz <yuvalif@yahoo.com>
To: Yuval Lifshitz <yuvalif=40yahoo.com@dmarc.ietf.org>, The IESG <iesg@ietf.org>, Adam Roach <adam@nostrum.com>
Cc: dime-chairs@ietf.org, dime@ietf.org, draft-ietf-dime-rfc4006bis@ietf.org
Message-ID: <699526940.4818562.1527139583898@mail.yahoo.com>
In-Reply-To: <78956e34-ef29-7ade-2a3f-08a14164f17b@nostrum.com>
References: <152694250133.7844.14290678942315536401.idtracker@ietfa.amsl.com> <1651457572.4445831.1527066817455@mail.yahoo.com> <78956e34-ef29-7ade-2a3f-08a14164f17b@nostrum.com>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_Part_4818561_1030357329.1527139583891"
X-Mailer: WebService/1.1.11871 YMailNorrin Mozilla/5.0 (X11; Fedora; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/66.0.3359.117 Safari/537.36
Archived-At: <https://mailarchive.ietf.org/arch/msg/dime/mtG6Bq_0ZM9FO8bLiNxAdiCF-9U>
Subject: Re: [Dime] Adam Roach's No Objection on draft-ietf-dime-rfc4006bis-08: (with COMMENT)
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Diameter Maintanence and Extentions Working Group <dime.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dime>, <mailto:dime-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dime/>
List-Post: <mailto:dime@ietf.org>
List-Help: <mailto:dime-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dime>, <mailto:dime-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 24 May 2018 05:36:30 -0000
Will fix the first 3 issues. Regarding IANA, Lionel, didn't we contact them already?Do we still need to add that to the RFC? Yuval On Wednesday, May 23, 2018, 5:37:56 p.m. GMT+3, Adam Roach <adam@nostrum.com> wrote: On 5/23/18 4:13 AM, Yuval Lifshitz wrote: §1.1: This document uses lowercase forms of RFC-2119-defined terms. Please update this section to use the boilerplate from RFC 8174. [yuval] we use them in lowercase, without their normative meaning. Is this an issue? For example: " a commercial agreement must exist between the visited domain and the home domain" is just informational It's not the language use that's an issue. RFC 2119 has been updated, and since you use the lowercase terms, the update is relevant to your document. The fix is to simply replace your existing text with: The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. §5.6.2: > The credit-control > client receives a Credit-Control-Answer or service specific > authorization answer with the Final-Unit-Indication or the QoS-Final- > Unit-Indication AVP and Validity-Time AVPs but no Granted-Service- > Unit AVP. This has the same confusion as above regarding the application of logical combinations. The second half of the statement is of the form "A or B and C but not D," which is pretty ambiguous. It's also a little unclear whether the client receives a Credit-Control-Answer (with A or B and C but not D), or just a Credit-Control-Answer of any description, full stop. [yuval] how about this: " When the credit-control client receives (either at session or service specific level) a Final-Unit-Indication AVP or QoS-Final- Unit-Indication AVP, together with Validity-Time AVP, but without Granted-Service- Unit AVP, it immediately starts the graceful service termination without sending any message to the server." Sounds good to me. Thanks. --------------------------------------------------------------------------- §8.65: > The Redirect-Address-IPAddress AVP (AVP Code TBD14) is of type > Address and defines the IPv4 or IPv6 address of the redirect server > with which the end user is to be connected when the account cannot > cover the service cost. This appears to be underspecified, unless I've missed some specification elsewhere regarding what the client is supposed to do with this IP address. While the other redirection methods (HTTP, SIP) have relatively clear means of contact (they indicate a protocol), the indication of only an IP address with neither protocol nor port doesn't seem to provide enough information for a client to act on. Please either flesh this out in this section, or point to another document that indicates how this IP address is to be used. [yuval] I think this is left unspecifid on purpose. There are many ways to redirect IP addresses (e.g. different tunneling mechanism), don't think we want to list them here?[yuval] If it's an open-ended set of behaviors (or a set of behaviors that is unrealistic to list), then I would expect the document to at least let implementors know that they're not going to find any further guidance in this document or other RFCs. Perhaps add something like: "The interpretation of Redirect-Address-IPAddress by the Diameter Credit-control Client is a matter of local policy." --------------------------------------------------------------------------- §12: When new documents obsolete an RFC that originally registered values with IANA, I'm used to seeing that document also update the IANA registry so that the corresponding entries now point to the new document. You may consider text that instructs IANA to update the existing RFC-4006-registered values so that they point to this document instead of RFC 4006. [yuval] don't know what the process here. but does it need to go into the RFC? Typically, that's how we give instructions to IANA pertaining to document updates, yes. See https://tools.ietf.org/html/draft-ietf-tls-tls13-28#section-11 for an example. --------------------------------------------------------------------------- Appendix B: As a general comment for all of the examples: I'm surprised that none of the examples have been updated to reflect the newly defined capabilities in this document. For example, all the examples in this appendix use Final-Unit-Indication rather than QoS-Final-Unit-Indication. In practice, to show maximally flexible and compatible examples, I would expect that the examples would include both AVPs. This applies to all of the "Extension" AVPs as well. [yuval] the examples are more around the flow and less about the actual content. With respect to flow, there is no difference between the old and new AVPs - and we wanted to minimize unnecessary changes. Only flow that was modified was reflected in a new diagram at the end of section 5.6 ("zero GSU") While I don't agree with the rationale here, this is an editorial comment about a non-normative part of the document, so it's ultimately your decision. /a _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime
- [Dime] Adam Roach's No Objection on draft-ietf-di… Adam Roach
- Re: [Dime] Adam Roach's No Objection on draft-iet… Yuval Lifshitz
- Re: [Dime] Adam Roach's No Objection on draft-iet… Adam Roach
- Re: [Dime] Adam Roach's No Objection on draft-iet… Yuval Lifshitz
- Re: [Dime] Adam Roach's No Objection on draft-iet… Bertz, Lyle T [CTO]