|
As David Nelson notes, it is the responsibility of the authors of a document to revise their document in response to comments submitted RADEXT WG participants. The minutes and the issues list (available at http://www.drizzle.com/~aboba/RADEXT ) describe in considerable detail the issues that have been raised with the document. These concerns range from the basic (insufficient articulation of the usage scenarios) to the specific (compatibility with RADIUS Design Guidelines). Revision of a document in response to WG comments is required prior to adoption as a WG work item for two reasons: 1. It demonstrates acceptance on the part of the authors in conforming to the processes and procedures of the IETF which require "rough consensus" for WG work products. 2. It demonstrates the interest of the authors to actually complete the work. At the RADEXT WG interim, we had a suggestion from David Miles for moving forward which both addresses the concerns relating to context (by discussion of specific scenarios of interest to the Broadband Forum) as well as addressing review comments (by limiting the focus to attributes whose conformance to Design Guidelines is not in dispute). Given the positive response at the Virtual Interim, we are now attempting to determine whether there is consensus for moving forward. Past experience has shown that breaking off a piece of the problem in this way has the potential to enable rapid progress. At the RADEXT WG Virtual Interim, specific next steps were presented, which included submission of a revised draft along the lines that David Miles has suggested. Preparation of such a revised draft is not gated by this consensus call. > Wojciech Dec writes... > > > I disagree with the consensus statement below. > > Noted. > > > As stated repeatedly on the thread, the pursuit of this > > draft has been a wild goose chase since the beginning and > > until further clarification is given, including actually > > answering to the draft authors, there is nothing which > > indicates that the statement below is not a continuation > > of this goose chase. The questions posed were clear and > > included a clarification of the intended way forward. > > To wit, on October 23, 2009 you wrote: > > We're currently planning on a two draft approach, > pretty much reverting to the state prior to the > "merged draft", along with changes to rid of any > datatype issues (fingers crossed) and additional > explanatory text. Before we proceed on this path, > which to some may seem to be yet another goose chase, > could you confirm that this is also your expectation? > > The process for advancing work in the RADEXT WG does not include any a > priori guarantees that any particular draft revision will garner sufficient > support of the WG members to be adopted as a WG Work Item. It seems like > that's the assurance you're seeking, however. > > There have been repeated comments on the list about the design of the > attributes in the -01 draft, including comments about the use of tagging. > You have previously responded that the current format falls within the > blanket provisions of the string data type and that there are precedents for > such usage in other RFCs. Thus, your query of October 23 was the first > indication that you might be willing to modify the design of those > attributes to meet with WG approval. > > The way the process works is that you submit a revised draft that addresses > the comments received on the list, and then the WG reviews the new draft > against the accumulated comments. If at that point in time there is > significant interest in adopting the draft as a WG Work Item, the draft can > move forward. I'll remind you that when counting WG members that are > interested in a given draft, and are willing to review and comment upon the > draft, the chairs don’t count the authors. The chairs need to see that > there are sufficient non-author WG members interested in the work to ensure > *independent* review. > > In the absence of a new draft, another WG member, David Miles, proposed > another way forward for a subset of the work in the "merged draft". The > current consensus call on the WG mailing list is to determine if the > consensus of the list matches the consensus of the WG at the Interim > Meeting. That's always the way these things are done in the IETF, consensus > must be validated on the list. > > > > -- > to unsubscribe send a message to radiusext-request@ops.ietf.org with > the word 'unsubscribe' in a single line as the message text body. > archive: <http://psg.com/lists/radiusext/> |