On 05/22/2013 11:48 PM, [email protected] wrote: > 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. > Regards, > Yoshihiro Ohba > > -----Original Message----- > From: [email protected] [mailto:[email protected]] On Behalf Of > Stephen Farrell > Sent: Thursday, May 23, 2013 2:17 AM > To: Sam Hartman > Cc: <[email protected]> > 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: >>>>>>> "Stephen" == Stephen Farrell <[email protected]> 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 protected] >> 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 >> >> > _______________________________________________ > abfab mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/abfab > > > _______________________________________________ abfab mailing list [email protected] https://www.ietf.org/mailman/listinfo/abfab
