Subject: [Gen-art] Gen-ART Last Call review of draft-ietf-abfab-usecases-03.txt

From: Suresh Krishnan <[email-masked]>
Date: Mon, 13 Aug 2012 19:59:21 -0400

I am the assigned Gen-ART reviewer for
draft-ietf-abfab-usecases-03.txt

For background on Gen-ART, please see the FAQ at
<http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html>.

Please resolve these comments along with any other Last Call comments
you may receive.

Summary: This draft is ready for publication as an Informational RFC,
but I do have some minor comments that you may like to address.

Minor
=====

* This document references obsolete versions of IMAP and SMTP. Is there
any specific reason for referring to the older versions? If not, I
recommend replacing references to

-> RFC2060 with RFC3501
-> RFC2821 with RFC5321

* Section 3.7

The following text is a bit out of date.

"At present, authentication to these applications will be typically
   configured manually by the user on the device (or on a different
   device connected to that device) but inputting their (usually pre-
   provisioned out-of-band) credentials for that application - one per
   application."

With systems such as IMS that have gotten deployed, at least telco
operator hosted applications can use some form of federated identity
already. I do not have strong feelings about this but I suggest leaving
out operator hosted applications from this characterization.

* Section 3.9

I am not sure I understand the following text

"The utility company may wish to
   grant access only to authorized devices; for example, a consortium of
   utility companies and device manufacturers may certify devices to
   connect to power networks."

What does the word certify mean here? I have always understood it to
mean testing compliance to certain requirements rather than verification
of identity. Can you please clarify?

Thanks
Suresh

_______________________________________________
Gen-art mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/gen-art

---

From: Rhys Smith <[email-masked]>
Date: Wed, 15 Aug 2012 16:05:48 +0100

Hi Suresh,

Thanks for the time you've spent looking through the document.

> recommend replacing references to

Fixed.

> out operator hosted applications from this characterisation.

This use case came directly from some authors involved in operating mobile platforms. I think it's still useful to leave it in there as there are a variety of non-operator hosted applications that may not have such a thing enabled. The text currently says "could be hosted by the telecoms operator, or could be any application or system on the internet" which I think means the point is still valid...

> of identity. Can you please clarify?

In this case it would be exactly as you say - testing compliance to certain requirements. In the case of utility networks, it might mean that a particular device has the "usual" power certifications about how it uses electricity, but also certification around its "smartness" - what identity technologies it supports, what levels of assurance it can comply with around identity assertion, etc.

Hope that helps?

Thanks!
Rhys.

---

From: Suresh Krishnan <[email-masked]>
Date: Fri, 24 Aug 2012 18:55:29 -0400

Hi Rhys,
  Thanks for making the changes. I have some responses to the open issues.

> This use case came directly from some authors involved in operating mobile platforms. I think it's still useful to leave it in there as there are a variety of non-operator hosted applications that…

My point was that this characterization was no longer widely applicable
for the operator hosted applications. I do not have strong feelings
about this. I am fine with leaving the text as is.

> In this case it would be exactly as you say - testing compliance to certain requirements. In the case of utility networks, it might mean that a particular device has the "usual" power certification…

Great. In that case, it would be good to change the word "authorized" to
"certified" as it conveys the meaning accurately.

Thanks
Suresh