Re: [abfab] charter take 3

[Leif Johansson <[e-mail]>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


Thanks for the review, Dave. You made some good points.

<snip>

>> The working group may consider other alternative technology for these
>> three roles in the architecture but any change in direction in this
>> respect requires rechartering of the working group.
> 
> I typically dislike references to hypothetical futures and especially to
> things that might be considered but which will require rechartering.
> 
> In this case, however, I think it defines a high barrier for replacing
> the technical components and it hits the reader in the face with how
> much effort it will take to climb the barrier.  So, I like it.
> 

I think you and Sam will have to slug it out on this topic. He wants to
cut it. I'm iffy. You want to keep it but also cut it. Maybe somebody
else has yet another approach :-)

<snip>

>> The working group may not change EAP (beyond the development of EAP
>> mechanisms), RADIUS or Diameter without establishing consensus with
>> the appropriate community within the IETF.
>>
>> The working group will use the following documents as a starting
>> point for its work:
>>
>> - - draft-howlett-eap-gss-00,
>> - - draft-howlett-radius-saml-attr-00
>> - - draft-hartman-gss-eap-naming-00
> 
> I'm pretty sure these are more than "starting points". That's a pretty
> vague term and I think you folks intend something more specific and that
> it means significant constraints on the changes to these specification
> that are considered permissible.

They are (imho) starting-points within the constraints of the
technology choices which have been outlined in the charter so I
think it is appropriate to say "starting point" in this case and
given that one has read the charter and the drafts I believe the
meaning is clear:  that given the roles of SAML, EAP and AAA
these three documents are starting points for each part of the
solution.

> 
> These are the base specifications.  What are the criteria for making
> changes to them?
> 

Normal IETF WG consensus, but we really can't keep repeating that.

	Cheers Leif
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAkxlknsACgkQ8Jx8FtbMZndl/wCfeGmrZbqxBTYmzKeMPf0sbkLw
3ooAoIWnfwAHCqN8Cb/UiXvYOdfeUyaa
=/Q+O
-----END PGP SIGNATURE-----