Subject: [abfab] AD review of eap-applicability

From: Stephen Farrell <[email-masked]>
Date: Wed, 15 May 2013 23:35:34 +0100

Hiya,

Klaas sent on the publication request and my AD review
is below.

I don't see any show-stoppers here but would like if
the chairs/shepherd/authors/wg would comment before I
request IETF LC. Doesn't need loads of discussion
but I'd like just to know there's nothing here that
the wg didn't consider already.

Thanks,
S.

- Should this update 3748? Current IESG thinking (i.e.
want something else and someone will badger you:-) is
that if a reader of 3748 really ought also read this,
then this should update 3748; if its ok for a reader of
3748 to not have to read this, then this shouldn't update
3748. I'd guess that this should update 3847 but am ok if
you say not. I'd like to just double check that before
IETF LC since someone might want a 2nd LC otherwise.
(Safest is to include it during IETF LC and the updates
thing could always be dropped later.)

- Mentioning the WG name in the abstract is usually wrong
since the WG will go away. Maybe say what abfab does
instead, e.g. like the charter does and say "...usage of
the EAP protocol as part of a federated identity
mechanism for use by Internet protocols not based on
HTML/HTTP, such as for instance IMAP, XMPP, SSH and NFS."
(Same for later mentions of the wg.)

- section 2: 2nd last para, last sentence: what does that
mean? something is funny there

- section 2: last para, 1st sentence: what does "between"
mean there?

- s2, last para: "an channel binding attributes" - do you
mean one or more?  (and fix grammar please)

- s3, 2nd last para: s/part/party/

- s4, RECOMMENDS use of [I-D.ietf-emu-crypto-bind], doesn't
that make it a normative reference?

---

From: Sam Hartman <[email-masked]>
Date: Wed, 15 May 2013 18:47:40 -0400

>>>>> "Stephen" == Stephen Farrell <[email-masked]> writes:

    Stephen> - Should this update 3748? Current IESG thinking (i.e.
    Stephen> want something else and someone will badger you:-) is that
    Stephen> if a reader of 3748 really ought also read this, then this
    Stephen> should update 3748; if its ok for a reader of 3748 to not
    Stephen> have to read this, then this shouldn't update 3748. I'd
    Stephen> guess that this should update 3847 but am ok if you say
    Stephen> not. I'd like to just double check that before IETF LC
    Stephen> since someone might want a 2nd LC otherwise.  (Safest is to
    Stephen> include it during IETF LC and the updates thing could
    Stephen> always be dropped later.)

This was brought up in WGLC.
The conclusion  I recall is that we should update 3748 and the document
would be changed prior to IETF LC:-)

    Stephen> - Mentioning the WG name in the abstract is usually wrong
    Stephen> since the WG will go away. Maybe say what abfab does
    Stephen> instead, e.g. like the charter does and say "...usage of
    Stephen> the EAP protocol as part of a federated identity mechanism
    Stephen> for use by Internet protocols not based on HTML/HTTP, such
    Stephen> as for instance IMAP, XMPP, SSH and NFS."  (Same for later
    Stephen> mentions of the wg.)

I think we're calling the overall architecture ABFAB as well.  so I
think we're mentioning the technology (which is gss-eap, plus a way of
describing naming of attributes, plus SAML rules for RADIUS, plus
potentially things in the future) not the WG.

    Stephen> - s4, RECOMMENDS use of [I-D.ietf-emu-crypto-bind], doesn't
    Stephen> that make it a normative reference?
    Stephen> _______________________________________________ abfab
    Stephen> mailing list [email-masked]
    Stephen> https://www.ietf.org/mailman/listinfo/abfab

Except the emu draft doesn't define a protocol.
It describes a mechanism you  might want to include when designing EAP
methods.

So perhaps recommends using that mechanism when available in EAP
methods or some such.

--Sam

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 22 May 2013 18:17:22 +0100

Folks,

Given Sam's response and that nobody disagreed I think it'd be
best to update the updates thing before IETF LC so I've marked
this as revised I-D needed.

Please yell at me if that's wrong. Even better, shoot out
that revised I-D and I'll start IETF LC.

Thanks,
S.

---

From: <[email-masked]>
Date: Wed, 22 May 2013 22:48:58 +0000

If my understanding is correct we agreed that only section 3 of draft-ietf-abfab-eapapplicability updates the EAP applicability statement in [RFC3748].  

Regards,
Yoshihiro Ohba

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Stephen Farrell
Sent: Thursday, May 23, 2013 2:17 AM
To: Sam Hartman
Cc: <[email-masked]>
Subject: Re: [abfab] AD review of eap-applicability

Folks,

Given Sam's response and that nobody disagreed I think it'd be best to update the updates thing before IETF LC so I've marked this as revised I-D needed.

Please yell at me if that's wrong. Even better, shoot out that revised I-D and I'll start IETF LC.

Thanks,
S.

On 05/15/2013 11:47 PM, Sam Hartman wrote:
> The conclusion  I recall is that we should update 3748 and the 
> document would be changed prior to IETF LC:-)
> 
_______________________________________________
abfab mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/abfab

---

From: Stephen Farrell <[email-masked]>
Date: Thu, 23 May 2013 00:14:44 +0100

> If my understanding is correct we agreed that only section 3 of draft-ietf-abfab-eapapplicability updates the EAP applicability statement in [RFC3748].  

That may be true, but that means that the RFC resulting from this
I-D should have an "updates" relationship with 3748. So we ought
fix that before IETF LC, just in case.

S.

---

From: "Leif Johansson" <[email-masked]>
Date: Thu, 23 May 2013 09:49:57 +0200

> that revised I-D and I'll start IETF LC.

To change to 'updates' - yes.

---

From: Sam Hartman <[email-masked]>
Date: Thu, 23 May 2013 09:41:50 -0400

>>>>>   <[email-masked]> writes:

    > If my understanding is correct we agreed that only section 3 of
    > draft-ietf-abfab-eapapplicability updates the EAP applicability
    > statement in [RFC3748].  Regards, Yoshihiro Ohba

i don't recall a discussion of that point, although it seems reasonably
obvious.
Only section 3 claims to be an EAp applicability statement.

We did discuss the use of 2119 language at various points, but those
changes have been made.

The question here is whether an updates header should be added.