Subject: Re: [abfab] So are we done?

From: Sean Turner <[email-masked]>
Date: Tue, 14 Sep 2010 17:11:55 -0400

I'm going to reorder them before I submit them.  I'm also going to do 
the charter/wg swap.

spt

Leif Johansson wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> On 08/29/2010 03:58 AM, Keith Hazelton wrote:
>> I notice that all other delivery estimates are in chronological order. Should the following:
>>
>> "* A standards-track protocol for carrying SAML messages in RADIUS and
>> Diameter (Dec 2011)"
>>
>> read Dec 2010?
> 
> Yes, somebody already pointed that out and it will go into the published
> version.
> 
> 	Cheers Leif
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.10 (GNU/Linux)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
> 
> iEYEARECAAYFAkx6EcwACgkQ8Jx8FtbMZndN0wCaA6SLNpkL+iRzUkq3QJca7D+1
> xMgAmwZycF/hol04Md9rnv5hMPFYoDWf
> =fJFX
> -----END PGP SIGNATURE-----
> _______________________________________________
> abfab mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/abfab
>

---

From: Sean Turner <[email-masked]>
Date: Tue, 14 Sep 2010 17:19:30 -0400

And I'm switching the date format to be more like others:

Dec 2010 instead of (Dec 2010) at the end.

One final question: Are these dates for submission to the IESG or for 
initial submissions?

spt

---

From: Sean Turner <[email-masked]>
Date: Wed, 15 Sep 2010 07:43:11 -0400

I'm going to tweak a couple of things in the Deliverables and 
Goals/Milestones:

  * First, I split them - most charters I've been seeing do so so I'm 
going with the flow.

  * Second, I think we need to indicate whether each deliverable is 
headed for informational/standards tracks.  4 had no indication. I 
added them in between * * (will remove the * * when I send it in for 
review (tomorrow)).  I assumed that the use cases and architecture 
drafts will be informational and that the drafts that updated existing 
standards track RFCs will, of course, be standards track.

   * Third, added initial submission as WG item and IESG submission 
times. I slid the IESG submission times to the right a bit. If we're 
early great.

Any raging objections to the following tweaks:

Deliverables
------------

1. An *informational* document describing applicable use cases.

2. An *informational* architecture document describing how the 
components of the solution fit together to address the use cases and 
open issues that will require future changes to the architecture.

3. A *standards-track* update to the EAP applicability statement in 
RFC 3748 describing the applicability of EAP to application 
authentication and placing appropriate requirements on this new EAP 
use case.

4. A standards-track solution for using EAP methods to provide 
authentication within the application.

5. A *standards-track* update to the EMSK root key applicability 
statement in RFC 5295.

6. A standards-track description of GSS names and name attributes 
required by the solution.

7. Informational descriptions of usability and user-interface concerns 
related to this work.

8. A standards-track protocol for carrying SAML messages in RADIUS and 
Diameter.

Goals and Milestones
--------------------

Oct 2010   Submit Internet draft describing applicable use cases
            as initial WG item.

Oct 2010   Submit Internet draft describing the architecture as
            initial WG item.

Oct 2010   Submit Internet draft that updates the EAP applicability
            statement as initial WG item.

Oct 2010   Submit Internet draft for using EAP methods to provide
            authentication within the application as initial WG item.

Oct 2010   Submit Internet draft that updates the EMSK root key
            applicability statement as initial WG item.

Oct 2010   Submit Internet draft that describes GSS names and name
            attributes as initial WG item.

Oct 2010   Submit Internet draft for usability and user-interface
            concerns as initial WG item.

Oct 2010   Submit Internet draft for SAML messages in Radius and
            Diameter as an initial WG item.

Mar 2011   Submit Internet draft describing applicable use cases
            to the IESG for consideration.

Mar 2011   Submit Internet draft describing the architecture to the
            IESG for consideration.

Aug 2011   Submit Internet draft that updates the EAP applicability
            statement to the IESG for consideration.

Aug 2011   Submit Internet draft for using EAP methods to provide
            authentication within the application to the IESG for
            consideration.

Nov 2011   Submit Internet draft that updates the EMSK root key
            applicability statement to the IESG for consideration.

Nov 2011   Submit Internet draft that describes GSS names and name
            attributes to the IESG for consideration.

Nov 2011   Submit Internet draft for usability and user-interface
            concerns to the IESG for consideration.

Mar 2012   Submit Internet draft for SAML messages in Radius and
            Diameter to the IESG for consideration.

spt

---

From: Leif Johansson <[email-masked]>
Date: Wed, 15 Sep 2010 13:59:24 +0200

>  * First, I split them - most charters I've been seeing do so so I'm

That was always the intent - I kept them together to keep the thing
short for the discussions.

> headed for informational/standards tracks.  4 had no indication. I added
> them in between * * (will remove the * * when I send it in for review
> (tomorrow)).  I assumed that the use cases and architecture drafts will
> be informational and that the drafts that updated existing standards
> track RFCs will, of course, be standards track.
> 

Sounds good!

For the record I don't have any objections to the deliverables or
timeline.
	
	Cheers Leif

---

From: Klaas Wierenga <[email-masked]>
Date: Wed, 15 Sep 2010 14:35:36 +0200

On 9/15/10 1:59 PM, Leif Johansson wrote:

looks good!

---

From: Sam Hartman <[email-masked]>
Date: Wed, 15 Sep 2010 08:43:14 -0400

Somehow in all these edits, the set of documents that the working group
will produce has been codified in the charter.  That's bad.  The set of
deliverables should be in the charter.  That is' we're delivering an GSS
EAP mechanism.  However, it should not take a recharter if we want to
split that across two documents for some reason.

So, the word document should basically never appear in the deliverables
section.  It's fine for it to appear in milestones.

I mostly agree with your assumptions about track.  I suspect that the
applicability updates may be BCPs--not so much because of strong level
of consensus, but because I don't know how to have an interoperable
applicability statement.  The AS updates definitely cannot be
informational.

-
--Sam