Subject: [abfab] AD review of draft-ietf-abfab-use-cases

From: Stephen Farrell <[email-masked]>
Date: Fri, 20 Jul 2012 18:22:08 +0100

Hi all,

I've done my AD review of this - comments are below.

I'm ok to start IETF LC on this now and you can handle
my comments as IETF LC comments, or if you prefer you
can spin another version (once submissions re-open) to
handle them now. I'll wait for the chairs to let me
know whether to start IETF LC or set this to revised
ID needed.

Thanks,
S.

1. In general there are a number of times where this document
seems to be wishful thinking. I think it'd be better if you
reduced it to the more concrete use-cases where implementation is
actually planned and where you can be more authoritative about
how abfab will be beneficial. Sections 3.5 and 3.9 in particular
seem weak to me and the document might be better if they were
deleted - would you really miss them?

2. ID nits says:

  -- Obsolete informational reference (is this intentional?): RFC
     2060 (Obsoleted by RFC 3501)

  -- Obsolete informational reference (is this intentional?): RFC
     2821 (Obsoleted by RFC 5321)

  -- No information found for draft-freeman-plasma-requirements -
     is the name correct?

Looks like these should be updated as noted in the writeup.

3. Please expand CRM on 1st use

4. Maybe move the reference to SSH to the end of 3.1, from the
start of 3.2, or ideally provide a reference to an "abfab-enabled
SSH" if you have one. (And say "secure shell (SSH)" on 1st use.)

5. 2nd last para of 3.3 could do with some references really.

6. The argument in 3.3 that grid admin complexity is really due
to X.509 seems weak to me.  I'd expect you to get comments about
that.  And replacing the entire VO thing would be a large task.
It'd be better if you had a very specific use-case here I think
rather than being so general.

7. Its not clear to me how abfab helps in 3.5 - I think you'd
maybe need to say some more about how that'd work.

8. 3.9: is it "smart object" or "smart device" just using one
marketing term would be better (zero even moreso;-)

9. 3.9 seems quite far-fetched to me. Do you really expect
sensors to use gss-eap?

---

From: Leif Johansson <[email-masked]>
Date: Fri, 20 Jul 2012 20:20:49 +0200

> 9. 3.9 seems quite far-fetched to me. Do you really expect sensors
> to use gss-eap?

I've seen a couple of examples of sensor nets built using wifi
hardware - sensors don't have to be small "toaster-like" objects.

	Cheers Leif

---

From: Stephen Farrell <[email-masked]>
Date: Fri, 20 Jul 2012 20:31:21 +0100

> hardware - sensors don't have to be small "toaster-like" objects.

Sure. I've built a number networks with nodes like that
myself, (e.g. [1] :-) Never needed nor considered anything
like abfab. Ours are v. small networks of course, but I've
also never heard anyone ask for what 3.9 is selling.

But like I said, its a comment that the wg can take or
leave, before or during IETF LC.

S.

[1] http://extremecom2012.ee.ethz.ch/papers/6-extremecom2012-Arkko.pdf

> 
> 	Cheers Leif
> _______________________________________________
> abfab mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/abfab
>

---

From: Leif Johansson <[email-masked]>
Date: Fri, 20 Jul 2012 22:13:32 +0200

On 07/20/2012 09:31 PM, Stephen Farrell wrote:
> Sure. I've built a number networks with nodes like that myself,
> (e.g. [1] :-) Never needed nor considered anything like abfab. Ours
> are v. small networks of course, but I've also never heard anyone
> ask for what 3.9 is selling.
> 
> But like I said, its a comment that the wg can take or leave,
> before or during IETF LC.
> 
> S.
> 
> [1]
> http://extremecom2012.ee.ethz.ch/papers/6-extremecom2012-Arkko.pdf

Good - I misunderstood your comment as saying something else! All good.

	Cheers Leif

---

From: "Klaas Wierenga (kwiereng)" <[email-masked]>
Date: Mon, 23 Jul 2012 08:52:39 +0000

On Jul 20, 2012, at 9:31 PM, Stephen Farrell wrote:

Stephen,

> also never heard anyone ask for what 3.9 is selling.

ehm, I am not sure it is THAT far fetched. I would argue that in large scale sensor networks with sensors of different nature (in terms of processing power, memory, battery consumption etc.) and connecting to untrusted networks you do want an approach that has authentication agility, can operate in an environment with delegated trust and that protects authentication credentials en route…. I can think of different ways to achieve that, but I would not dismiss the abfab approach out of hand….

Klaas

---

From: Stephen Farrell <[email-masked]>
Date: Mon, 23 Jul 2012 11:50:27 +0100

On 07/23/2012 09:52 AM, Klaas Wierenga (kwiereng) wrote:
> ehm, I am not sure it is THAT far fetched. 

Well, even slightly far-fetched isn't really a good
use-case is it?

But whatever;-)

S.

> I would argue that in large scale sensor networks with sensors of
different nature (in terms of processing power, memory, battery
consumption etc.) and connecting to untrusted networks you do want an
approach that has authentication agility, can operate in an environment
with delegated trust and that protects authentication credentials en
route…. I can think of different ways to achieve that, but I would not
dismiss the abfab approach out of hand….