[Dime] Alissa Cooper's No Objection on draft-ietf-dime-rfc4006bis-10: (with COMMENT)

Alissa Cooper <alissa@cooperw.in> Mon, 20 August 2018 13:23 UTC

MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Alissa Cooper <alissa@cooperw.in>
To: The IESG <iesg@ietf.org>
Cc: draft-ietf-dime-rfc4006bis@ietf.org, Jouni Korhonen <jouni.nospam@gmail.com>, dime-chairs@ietf.org, jouni.nospam@gmail.com, dime@ietf.org
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <153477142875.23147.7756795074760914915.idtracker@ietfa.amsl.com>
Date: Mon, 20 Aug 2018 06:23:48 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/dime/TTefB-oNFW_RyYoZo8Cdl0oFbvg>
Subject: [Dime] Alissa Cooper's No Objection on draft-ietf-dime-rfc4006bis-10: (with COMMENT)

Alissa Cooper has entered the following ballot position for
draft-ietf-dime-rfc4006bis-10: 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 for addressing my DISCUSS.

Original COMMENT:

= Section 1 =

(1) I know it's a term of art, but the term "next generation wireless networks"
seems a bit out of place in two ways: (1) "wireless" seems more generic than
what is implied (i.e., "cellular," I assume), and (2) is Rel-13 considered
"next generation" still?

(2) "Diameter base protocol" should cite RFC 6733.

= Section 5.1 =

Assuming G-S-U stands for granted service unit, the acronym should be given
upon first use here.

= Section 8.52 =

(1) Why do you need to specify the ability to send either the IMEISV or the
IMEI?

(2)
"If the type of the equipment is one of the
   enumerated types of User-Equipment-Info-Type AVP, then the credit-
   control client SHOULD send the information in the User-Equipment-Info
   AVP, in addition to or instead of the User-Equipment-Info-Extension
   AVP."

Why is this normative recommendation in support of backwards compatibility
different from the one given for the Subscription-Id-Extension AVP in Sec. 8.58?

= Section 15.1 =

"Redirect-Server-Address AVP: the service-provider may embed
        personal information on the subscriber in the URL/I (e.g. to
        create a personalized message)."

This seems like a bad idea that, if it's going to be mentioned, should be
recommended against.

[Dime] Alissa Cooper's No Objection on draft-ietf… Alissa Cooper