Re: [Dime] Adam Roach's No Objection on draft-ietf-dime-rfc4006bis-08: (with COMMENT)
Yuval Lifshitz <yuvalif@yahoo.com> Wed, 23 May 2018 09:13 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 0682A126B6E for <dime@ietfa.amsl.com>; Wed, 23 May 2018 02:13:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 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] autolearn=ham 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 nDLq7dmhvMQP for <dime@ietfa.amsl.com>; Wed, 23 May 2018 02:13:41 -0700 (PDT)
Received: from sonic314-22.consmr.mail.ne1.yahoo.com (sonic314-22.consmr.mail.ne1.yahoo.com [66.163.189.148]) (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 0797A124BAC for <dime@ietf.org>; Wed, 23 May 2018 02:13:40 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1527066819; bh=n6mlWN9Fuz5fz8+EEdj5+ilhluvb11mH0wsCUSbacas=; h=Date:From:To:Cc:In-Reply-To:References:Subject:From:Subject; b=oi0qqkb6sLdJRES6D4Q+CiNQCns+5oH7md60k3olmWcLncomf8b0u/lywQLtAAlM2jGY6kpy2/BIaRNvuD5oRvFDmRqePYVTqsKdZ4ghf2j3+lG4v2VAejjUspyYXf7VxIqVtjnghoxbwvda3+9ypsZfZLyVKxe/B13PPa++ft85rPTlmyC2hcQyOKfdQMeiwnqeZ+UXFUGrK2i2D+14c7iYAIteIH3w++TLeaM75WHTm2wa4/3HJcJVTxa8nyp4gxGbBKBd51YxZNahO4D6LqOEE9zaweiAm1a0pFZrz0f7PMM/4X69qYUpIII3ZQfGn4QaR4IubpLNo8+eWyjmDQ==
X-YMail-OSG: fzf9rg4VM1kaqv3xXPLxrKua3ZK7fd2iCMiTDeF4Me05wKVjkXzmAoiIgifQya3 YStd1.GDQx815xdGSAEuedh2xaVgwjyrdeSST4s4YenS7g1hdg.UAn54p_hkW9SCWd6euNNvTYOZ ibEm0txHYMhqD5e_Cw_YQT2BZuCIZYfEgLJmiqt5wG2dqQnQmw5ISYOx5pt30IVBUr5sGo4g0Srr mFy0cvZhZdc6MUILavZAvIOQlbtOExBqzjrO2O1OxBNdVjaqyKXkMDqJClK870NxQSSF3GwaZrkc s0CoUCbFTLh8DFtYuQJ1BUepvYHj3g19Em3UrBmxx1bZ07hVSnnvQQ9SPUJ3ZhDwTlySDCfI.F1a iemqFNvJg5cG5flPNlqUxGwhyQVt2pnDr9mKXjbEmauTIruXIg6SgKL4hr.sHarnO9vak8gne8XK Amcy_LaDYH6CP0CmWhbBNT1pug4FShzinMvvcpvcaT3tbiy7JFQikZOHUiQ4EWoZ.YFM1qTvHX4f 6GHDRhE0i3XL47LgHZLp7UaOLRSvqZC4yBdeaCqOaRLTIey_7qw07jUhSL8A4QFlUoSqzmCxkwX4 BE2iKgiUnqHUMzOe7Qxv61VgIJdUAsPceUIutTruaoAHqbszVYdkKqw2RuYAR3sFIboPSihajMq. qBr1DEqV_ZsnW9cyKjplfK6rmmgAVw7YlfZzgLKc-
Received: from sonic.gate.mail.ne1.yahoo.com by sonic314.consmr.mail.ne1.yahoo.com with HTTP; Wed, 23 May 2018 09:13:39 +0000
Date: Wed, 23 May 2018 09:13:37 +0000
From: Yuval Lifshitz <yuvalif@yahoo.com>
To: The IESG <iesg@ietf.org>, Adam Roach <adam@nostrum.com>
Cc: dime@ietf.org, dime-chairs@ietf.org, draft-ietf-dime-rfc4006bis@ietf.org
Message-ID: <1651457572.4445831.1527066817455@mail.yahoo.com>
In-Reply-To: <152694250133.7844.14290678942315536401.idtracker@ietfa.amsl.com>
References: <152694250133.7844.14290678942315536401.idtracker@ietfa.amsl.com>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_Part_4445830_1015538383.1527066817446"
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/6pNnOanCwISnFeABI1Pd12962Lk>
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: Wed, 23 May 2018 09:13:43 -0000
Hi Adam, thanks for the review. Comments inline On Tuesday, May 22, 2018, 1:41:50 a.m. GMT+3, Adam Roach <adam@nostrum.com> wrote: Adam Roach has entered the following ballot position for draft-ietf-dime-rfc4006bis-08: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-dime-rfc4006bis/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thanks to the authors and other participants who helped with this revision of the credit-control application. Thanks in particular for the addition of an extensive privacy considerations section. I will note that I only reviewed the diffs between this document and RFC 4006. I have a handful of comments. --------------------------------------------------------------------------- General nit: This document uses the term "service specific" as a compound adjective in several places. As a compound adjective, this should be hyphenated (i.e., "service-specific"). [yuval] will fix --------------------------------------------------------------------------- §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 --------------------------------------------------------------------------- §5.1.2: > If independent credit-control of multiple services is used, the > Validity-Time AVP and Final-Unit-Indication AVP or QoS-Final-Unit- > Indication AVP SHOULD be present either in the Multiple-Services- > Credit-Control AVP(s) or at command level as single AVPs. The phrasing here is ambiguous -- it's not clear whether the requirement is: (Validity-Time and Final-Unit-Indication) or QoS-Final-Unit-Indication ... or ... Validity-Time and (Final-Unit-Indication or QoS-Final-Unit-Indication) I suspect it's the latter, in which case I suggest: If independent credit-control of multiple services is used, the Validity-Time AVP, and either the Final-Unit-Indication AVP or the QoS-Final-Unit-Indication AVP, SHOULD be present either in the Multiple-Services- Credit-Control AVP(s) or at command level as single AVPs. [yuval] yes. will fix --------------------------------------------------------------------------- §5.2.1: The alignment of the "Diameter AAA Server" title on Figure 3 has changed from RFC 4006 in a way that looks worse. --------------------------------------------------------------------------- [yuval] will fix §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." --------------------------------------------------------------------------- §8.19 > Note: The values reported in a Used-Service-Unit AVP does not > necessarily have a relation to the grant provided in a Granted- > Service-Unit AVP, e.g., the value in this AVP may exceed the value in > the grant. Nit: "...values reported in a Used-Service-Unit AVP do not..." ^^ (or "...value... does not...") [yuval] will fix --------------------------------------------------------------------------- §8.54: > The User-Equipment-Info-MAC (AVP Code TBD3) is of type OctetString. > The User-Equipment-Info-MAC AVP contains the 48-bit MAC address is > formatted as described in [RFC3580]. Nit: remove "is" after "address". [yuval] will fix --------------------------------------------------------------------------- §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] --------------------------------------------------------------------------- §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? --------------------------------------------------------------------------- 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") --------------------------------------------------------------------------- Appendix B.2: > control server. Therefore, in this example, it is assumed that the > SIP Proxy adds a Record-Route header in the initial SIP INVITE "...a Record-Route header field..." (A SIP header is everything before the first blank line; individual lines within a SIP header are called "header fields") [yuval] ok. will fix _______________________________________________ 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]