Application Bridging for Federated Access Beyond Web (ABFAB) Use Cases
draft-ietf-abfab-usecases-05

Note: This ballot was opened for revision 04 and is now closed.

(Sean Turner; former steering group member) Yes

In section 3 maybe we could remove the marketing paragraph because it's not really relevant why somebody might use the cloud - the fact is they do so this is not needed:

   The main benefits of cloud computing are that it offers on-demand
   services with pay per-use removing the need for users/organizations
   to build and maintain their own hardware or infrastructure, and that
   it allows for the dynamic scaling of resources required for solving
   specific tasks.

(Stephen Farrell; former steering group member) Yes

(Adrian Farrel; former steering group member) No Objection

(Barry Leiba; former steering group member) No Objection

Nit:
-- Section 3.1 --

Lots of editorial stuff, but it'll all be sorted by the RFC Editor.  One nit that might not be is this one:

   o  Common application software such as email, shared storage,
      business applications such as Customer Relationship Management
      (CRM) or scientific applications ("Software as a Service", or
      Saas).

The last letter of "SaaS" needs to be capitalized.

(Benoît Claise; former steering group member) No Objection

I support the publication of this draft. 


   Adding federated authentication to IPP [RFC3229] (and other relevant
   protocols) would enable this kind of remote printing service without
   the administrative overhead of credentialing these visitors (who, of
   course, may well one time visitors to the organisation). 

Are you sure it's the right RFC?


Regarding the next two comments, take them or leave them, up to the WG authors/chairs/AD


1. There are multiple sentences that speak about the ABFAB architecture and specifications.

-  The goal of this document is to document a selection
   of the wide variety of these contexts whose user experience could be
   improved through the use of technologies based on the ABFAB
   architecture and specifications.

-   This document enumerates some of these use cases,
   describing how technologies based on the the ABFAB architecture
   [I-D.lear-abfab-arch] and specifications could be used.

-  This document enumerates some of these use cases,
   describing how technologies based on the the ABFAB architecture
   [I-D.lear-abfab-arch] and specifications could be used.

-  ABFAB could help in this context as its specifications would enable
   federated authentication for a variety of non-web protocols, ...

-  The use of ABFAB technologies in this case would enable both the
   front or back end attribute exchange required to provide subject
   attributes.  

-  etc...

You chose to have a use cases RFC before the architecture RFC. That's your choice, and that's fine!
However, it would be nice to explain in one paragraph (potentially with a figure) how you envision the architecture:
    organization A,
    organization B,
    a user who authenticates in the org A and needs to access the information in org B
    a RADIUS connection from org. A to org B. with SAML content within the RADIUS data.
I had to dig outside of the draft to find this information, but it helped me tremendously to start to understand the technology challenges behind the use cases.
In 5 years from now, which RFC should a new newcomer read first to start understanding what the WG does? Is it this one or the architecture? 

2.  A sentence or two regarding the relationship with the ABFAB and SCIM use cases (in this document or in a different subsequent document, not sure)
As far as I can tell:
    SCIM: pre-provisioning identity management across domains
    ABFAB: Single Sign On across domains

(Brian Haberman; former steering group member) No Objection

(Gonzalo Camarillo; former steering group member) No Objection

(Martin Stiemerling; former steering group member) No Objection

(Pete Resnick; former steering group member) No Objection

(Ralph Droms; former steering group member) No Objection

(Robert Sparks; former steering group member) No Objection

(Ron Bonica; former steering group member) No Objection

(Russ Housley; former steering group member) No Objection

(Stewart Bryant; former steering group member) No Objection

(Wesley Eddy; former steering group member) No Objection