+1 to Eran and David's comments. Let's not get distracted when we are close to finalizing. I suggest revising the charter once we are done with 2.0 unless there is a process reason for revising the charter to complete 2.0.
-- Dick On 2011-04-28, at 12:22 PM, David Recordon wrote: > I agree with Eran as well that the focus should be on finalizing 2.0 > and then future work can occur in new working groups. We're so close! > I keep telling people throughout the industry that the spec hasn't > changed technically in months but they keep asking when it's going to > be a final RFC. > > > On Thu, Apr 28, 2011 at 10:11 AM, Thomas Hardjono <[email protected]> wrote: >> Folks, Eran, >> >> My apologies for jumping ahead to far. I misunderstood Blaine's email. I >> took the words "Revised Charter" to mean "Re-charter". >> >> And usually when a WG says "re-charter", it means a big overhaul (which is >> why I mentioned Profiles, etc. etc.). >> >> This is not the case here. I believe what we are doing today is a just a >> charter "clarification", "firm-up" or "clean-up". >> >> So please ignore my posting :) >> >> Thanks. >> >> /thomas/ >> >> >> __________________________________________ >> >>> -----Original Message----- >>> From: Eran Hammer-Lahav [mailto:[email protected]] >>> Sent: Thursday, April 28, 2011 12:48 PM >>> To: Thomas Hardjono; Blaine Cook; [email protected]; oauth- >>> [email protected] >>> Subject: RE: [OAUTH-WG] Revised Charter >>> >>> -1 on all of these. >>> >>>> -----Original Message----- >>>> From: [email protected] [mailto:[email protected]] On >>> Behalf >>>> Of Thomas Hardjono >>>> Sent: Thursday, April 28, 2011 7:20 AM >>>> To: Blaine Cook; [email protected]; [email protected] >>>> Subject: Re: [OAUTH-WG] Revised Charter >>>> >>>> Thanks Blaine, >>>> >>>> This is a good start. I have two suggestions and one request for an >>>> additional >>>> paragraph/bullet: >>>> >>>> (a) Openness to future items: >>>> >>>> I would like to see language that is more open (ready) to accept >>>> future items (ie. those on the horizon and those unforeseen). >>>> >>>> For example, the Kerberos WG has just completed its re-charter >>>> recently and had to address this same notion of limit/openness to >>>> future items. The language that was finally chosen reflects this >>>> openness, I think. Here are two >>>> examples: >>>> >>>> "Prepare and advance one or more standards-track specifications >>> which...." >>>> (does XYZ). >>>> >>>> "Prepare, review, and advance standards-track and informational >>>> specifications that..." (that does XYZ) >>> >>> This defeats the purpose of a charter, which is meant to clearly define >>> what the working group is scoped to do. I would like to see a charter >>> as narrow as possible to help us focus on getting 2.0 done. >>> >>>> >>>> (b) Date for re-charter completion: >>>> >>>> Should you perhaps add a date for the completion of the re- >>> chartering. >>>> Say March 2012 (to coincide with the March IETF). Otherwise >>>> re-chartering may drag on for sometime -- which is known to happen in >>>> the IETF :-) >>> >>> I have serious doubts about the need for this WG to continue. I for one >>> am going to push for closing this WG as soon as the list of >>> deliverables are complete. If there is new work, it belongs in a new >>> WG. >>> >>>> (c) Profiles of OAUTH2.0: >>>> >>>> I know that some folks want to use OAUTH2.0 as is (just the one >>> spec), >>>> but other folks (including myself) see the need to build additional >>>> features on top the single OAUTH2.0 spec to make OAUTH2.0 work in >>> other scenarios. >>>> For lack of a better term, I use the term "profile" (to mean clearly >>>> defined additions and narrowings of aspects listed in the main >>> OAUTH2.0 spec). >>>> >>>> As such, I would like request the addition of the following paragraph >>>> to the new charter: >>>> >>>> Prepare, review, and advance standards-track and informational >>>> specifications that define profiles of OAUTH2.0 for usage within >>>> certain well- defined environments. These profiles are adjunct to the >>>> OAUTH2.0 specification, and add optional capabilities to those >>> already >>>> defined in the >>>> OAUTH2.0 main specification. >>> >>> This is just a distraction. If you can demonstrate sufficient interest, >>> you should have no problem creating a new WG at the conclusion of this >>> one, or just submit and individual submission, which is probably the >>> only practical way to go with most of these extensions (given the lack >>> or implementation experience and small number of people interested in >>> them). >>> >>> >>> EHL >> >> _______________________________________________ >> OAuth mailing list >> [email protected] >> https://www.ietf.org/mailman/listinfo/oauth >> > _______________________________________________ > OAuth mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/oauth _______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
