Subject: [Dime] Adam Roach's No Objection on draft-ietf-dime-rfc4006bis-08: (with COMMENT)

From: Adam Roach <[email-masked]>
Date: Mon, 21 May 2018 15:41:41 -0700

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").

---------------------------------------------------------------------------

§1.1:

This document uses lowercase forms of RFC-2119-defined terms. Please update this
section to use the boilerplate from RFC 8174.

---------------------------------------------------------------------------

§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.

---------------------------------------------------------------------------

§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.

---------------------------------------------------------------------------

§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.

---------------------------------------------------------------------------

§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...")

---------------------------------------------------------------------------

§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".

---------------------------------------------------------------------------

§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.

---------------------------------------------------------------------------

§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.

---------------------------------------------------------------------------

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.

---------------------------------------------------------------------------

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")

---

From: Yuval Lifshitz <[email-masked]>
Date: Wed, 23 May 2018 09:13:37 +0000 (UTC)

Hi Adam, thanks for the review. Comments inline
    On Tuesday, May 22, 2018, 1:41:50 a.m. GMT+3, Adam Roach <[email-masked]> wrote:  

General nit:

[yuval] will fix

§1.1:

[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

... or ...

[yuval] yes. will fix

§5.2.1:

[yuval] will fix

[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

[yuval] will fix

[yuval] will fix

[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:

[yuval] don't know what the process here. but does it need to go into the RFC?

Appendix B:

[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")
---------------------------------------------------------------------------

[yuval] ok. will fix

_______________________________________________
DiME mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dime

---

From: Adam Roach <[email-masked]>
Date: Wed, 23 May 2018 09:37:32 -0500

On 5/23/18 4:13 AM, Yuval Lifshitz wrote:
> /[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 inBCP 14 <https://tools.ietf.org/html/bcp14>  [RFC2119 <https://tools.ietf.org/html/rfc2119>] [RFC8174 <https://tools.ietf.org/html/rfc8174>] when, and only when, they
       appear in all capitals, as shown here.

> /[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.

> /[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."

> /[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.

> /[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

---

From: Yuval Lifshitz <[email-masked]>
Date: Thu, 24 May 2018 05:26:23 +0000 (UTC)

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 <[email-masked]> wrote:  

    §1.1:

  [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:
 
      described in BCP 14 [RFC2119] [RFC8174] when, and only when, they

  
  
  [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."      

  

  

 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:

 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:

 
 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

---

From: "Bertz, Lyle T [CTO]" <[email-masked]>
Date: Thu, 31 May 2018 13:21:25 +0000

One comment below on Section 12.

From: DiME [mailto:[email-masked]] On Behalf Of Adam Roach
Sent: Wednesday, May 23, 2018 9:38 AM
To: Yuval Lifshitz <yuvalif=[email-masked]>; The IESG <[email-masked]>
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: Re: [Dime] Adam Roach's No Objection on draft-ietf-dime-rfc4006bis-08: (with COMMENT)

CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe.

§1.1:

For example: "

      described in BCP 14<https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Fbcp14&data=02%7C01%7Clyle.t.bertz%40sprint.com%7Cd44b81b80dec4ac4ac7b08d5c0bac565%7C4f8bc0acbd784bf5b55f1b31301d9adf%7C0%7C0%7C636626830765743872&sdata=10GY4hpYw2xcYq6DtQzN724YnBL3B2Hwl2nqfCB7kYI%3D&reserved=0> [RFC2119<https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Frfc2119&data=02%7C01%7Clyle.t.bertz%40sprint.com%7Cd44b81b80dec4ac4ac7b08d5c0bac565%7C4f8bc0acbd784bf5b55f1b31301d9adf%7C0%7C0%7C636626830765743872&sdata=BfTHeJlbt0YaXYDpIm%2ByFQCFsDJsy4atMupxkD0IOGg%3D&reserved=0>] [RFC8174<https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Frfc8174&data=02%7C01%7Clyle.t.bertz%40sprint.com%7Cd44b81b80dec4ac4ac7b08d5c0bac565%7C4f8bc0acbd784bf5b55f1b31301d9adf%7C0%7C0%7C636626830765743872&sdata=z6w50FtKIudO%2BhuWQIX%2FNUOWPlLdm8WmxRBEX0pX1bg%3D&reserved=0>] when, and only when, they

[yuval] how about this:
"
When the credit-control

§12:

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<https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Fdraft-ietf-tls-tls13-28%23section-11&data=02%7C01%7Clyle.t.bertz%40sprint.com%7Cd44b81b80dec4ac4ac7b08d5c0bac565%7C4f8bc0acbd784bf5b55f1b31301d9adf%7C0%7C0%7C636626830765743872&sdata=fxNMAZ61TCDKophRaQCN2js03gFjmF38MoPZJtDs3Qc%3D&reserved=0> for an example.

[Lyle] We will update the document. Also, per Ben’s COMMENT regarding Section 12 we should detail our update in this thread.

As a reminder it was
>  Initially, such Expert discussions take place on the AAA
> WG mailing list.
>
> That list appears to be dead, suggesting that this text should be updated. (I also agree with Adam's comments about updating the IANA Considerations.)

This is at the bottom of his ballot thread (https://mailarchive.ietf.org/arch/msg/dime/fFcA41D8FA68yn8GSnVHzpl6MBQ)

Are you okay with use eliminating this text as Benjamin proposed?  Alternatively, we can use the statement “The definition of new values is subject to the Specification Required
   policy [RFC8126].”

Appendix B:

/a

________________________________

This e-mail may contain Sprint proprietary information intended for the sole use of the recipient(s). Any use by others is prohibited. If you are not the intended recipient, please contact the sender and delete all copies of the message.