W3C home > Mailing lists > Public > public-ietf-w3c@w3.org > October 2011

Re: strawman document: W3C/IETF mutual review mechanics

From: Peter Saint-Andre <stpeter@stpeter.im>
Date: Mon, 17 Oct 2011 13:16:32 -0600
Message-ID: <4E9C7F10.7070303@stpeter.im>
To: Thomas Roessler <tlr@w3.org>
CC: public-ietf-w3c@w3.org, Mark Nottingham <mnot@mnot.net>, Salvatore Loreto <salvatore.loreto@ericsson.com>, Gabriel Montenegro <Gabriel.Montenegro@microsoft.com>, Arthur Barstow <art.barstow@nokia.com>
On 10/16/11 9:14 AM, Thomas Roessler wrote:
> On behalf of Mark Nottingham and myself, here's a strawman of what guidance about mutual review mechanics between W3C and IETF could look like.
> This is intended to capture a mix of current practice and some immediate lessons from the collaboration around hybi / websockets.  The document does not propose any process changes on either side.  Changes to specifications that happen beyond Proposed Standard are explicitly out of scope for this document, since we don't have recent experience.
> Possible destinations for this document may include a wiki page, or an individual informational i-d.
> Comments and input most welcome!
> Regards,
> --
> Thomas Roessler, W3C  <tlr@w3.org>  (@roessler)
> Strawman
> W3C/IETF mutual review expectations
> Mark Nottingham <mnot@mnot.net> 
> Thomas Roessler <tlr@w3.org>
> 2011-10-16
> 0. Introduction
> Occasionally, W3C and IETF produce specifications in close
> cooperation, sometimes marked by a significant formal dependency
> beween the specifications. A recent example is the websockets protocol
> and API specifications produced by the IETF hybi and W3C web
> applications working groups.
> W3C and IETF have similar, but not identical processes; some stages
> have identical names ("Last Call" in paritcular), but come with
> different expectations.
> The processes referred to in this document are documented in:
> - RFC 2026, The Internet Standards Process, as updated
>   http://tools.ietf.org//html/rfc2026
> - RFC 2418, IETF Working Group Guidelines and Procedures
>   http://tools.ietf.org/html/rfc2418
> - W3C Process Document
>   http://www.w3.org/2005/10/Process-20051014/
> 1. Goals and Scope
> The goal of this document is to establish mutual review expectations
> and responsibilities for W3C and IETF specifications with close
> dependencies. The scope of this document is limited to the phases of
> the IETF process leading up to publication of a document as Proposed
> Standard, ad to the phases of the W3C process leading up to
> publication of a document as Candidate Recommendation, or as Proposed
> Recommendation if the Candidate Recommendation step is skipped.
> Both of these process steps correspond to publication of a document
> for initial implementation.  In both cases, WGs may decide to further
> iterate documents (possibly returning to Last Call and Candidate
> Recommendation several times), or to make certain changes as a result
> of implementation experience that are incorporated as a document
> proceeds further along the standards track.  Where that is the case,
> groups should fail in favor of mutual review and transparency.
> 2. Context: The W3C/IETF liaison relationship
> Working groups on both the W3C and IETF side have WG chairs who are
> responsible for managing the day-to-day operation of the group.
> The liaison relationship between the IETF and the W3C is managed by
> the IAB and the W3C staff, respectively. Traditionally, the IAB
> assigns one or several individuals from the IETF community as IETF
> liaisons to the W3C, and one or several W3C staff members serve as the
> W3C's liaisons to the IETF. The relationship mostly operates through
> regular telephone conferences (typically in the run-up to major
> meetings), e-mail discussions on the public-ietf-w3c@w3.org mailing
> list, and through attendance of major meetings. Formal liaison
> statements are used under exceptional circumstances.
> The liaison telephone conferences are attended by the assigned
> liaisons from both sides. The IETF Application Area Directors and the
> W3C Director have standing invitations to join the liaison meetings.
> IAB members may join the meetings.

In practice, people other than the IETF Application Area Directors can
attend these teleconferences. Recently, Area Directors for RAI and
security have joined given wider cooperation of late between the W3C and
IETF (web application security, RTC web, etc.).

> Other individuals with specific expertise participate at the
> invitation of the liaisons.
> It is appropriate to copy the (archived) public-ietf-w3c@w3.org
> mailing list on relevant communications between IETF and W3C
> participants.  The archives of this list serve to document agreements
> about review time lines, scopes, and issues.
> The W3C/IETF liaison team is generally involved in chartering
> negotiations that require mutual review.  The liaison team keeps an
> online list of WGs to which the coordination expectations in this
> document apply at @@.
> 3. Working Group Coordination
> 3.1 Specification Development before Last Call
> Working Group coordination is expected to be largely informal and on a
> technical level. Where groups have closely related deliverables,
> overlap between working groups and direct collaboration between
> document editors are useful instruments toward ensuring appropriate
> coordination.
> Responsibility for this day-to-day relationship lies with the
> respective Working Group chairs. The formal liaisons are available to
> facilitate introductions and enable chairs to discharge this
> responsibility appropriately.
> 3.2 Moving to Last Call
> Where documents have dependencies that create mutual review
> expectations, Working Groups should align their Last Call time lines.
> In the IETF process, the decision to request IETF Last Call is
> often preceded by a Working Group Last Call; issuing a Working Group
> Last Call is at the discretion of the WG chair.
> In the W3C process, the decision to request W3C Last Call is often
> preceded by a cooling off period during which the WG has no particular
> open issues to work on, but leaves a window for participants to
> perform a final review.
> The goal of this document is to ensure that substantive technical
> cross-review occurs before IETF Last Call or W3C Last Call is
> requested, but at a stage where specifications are stable enough for
> outside review. When exactly that threshold is crossed is at the
> discretion of the WG chairs.
> Therefore, Working Group chairs work with their peers in the other
> organization to ensure that the respective specifications have
> received substantive mutual review before they request W3C and IETF
> Last Call.
> This goal can be achieved by requesting outside review during the
> equivalent of WG Last Call.
> Requests for review are most useful if they include pointers at the
> relevant drafts, set expectations about open issues and stability of
> the documents, and give a time line during which review comments will
> be expected.
> Working Group chairs cannegotiate other mechanisms and specific time
> lines (including joint meetings, joint editors, earlier review
> schedules, ...) that ensure the same goal of mutual review. To ensure
> useful coordination, such negotiations often involve the W3C and IETF
> liaison team, the W3C staff contacts, and the relevant Area Directors
> (or their designees).
> The chosen review mechanism is best documented in a note to
> public-ietf-w3c@w3.org; where a formal exchange of calls for review
> occurs between two groups, that call for review is appropriately
> copied to public-ietf-w3c@w3.org.
> Where mutual review leads to additional technical changes, it is the
> chairs' responsibility to ensure awareness by the other Working Group
> of these technical changes, and to negotiate time lines going forward
> with the assistance of the liaison team.
> 3.3 Last Call and Beyond
> While Working Groups are welcome to exchange technical reviews during
> Last Call, this process is intended to produce a coherent set of
> specifications that permit joint external review prior to entering
> Last Call. Therefore, we expect major last call comments between W3C
> and IETF Working Groups to be a rare occurence that is to be avoided.
> In the W3C process, a W3C Last Call is ended by a Working Group
> requesting transition to Candidate Recommendation (or, in exceptional
> cases, Proposed Recommendation). A precondition to this transition is
> the availability of a disposition of comments that documents how the
> Working Group has taken Last Call comments into account. When changes
> made in response to Last Call comments would invalidate prior review,
> it is common for groups to iterate several Last Call cycles.
> A W3C last call comment period lasts at least three weeks.
> In the IETF process, the IESG takes comments from the IETF community
> for a period of at least two weeks, and can then request changes to
> the document, or further advance the document. (See section 8 of RFC
> 2418.) An IETF last call is not intended to serve as a vehicle for
> substantive comments.

Not that intent always matches reality. ;-)

> Where W3C and IETF documents have significant mutual dependencies,
> W3C and IETF Last Call announcements should be notified to the chairs
> of the respective Working Groups, copying public-ietf-w3c@w3.org.
> The IESG's publication of a document as a Proposed Standard and the
> W3C's publication of a document as Candidate Recommendation (or
> Proposed Recommendation) should be synchronized, and the time line
> planned in advance.
> This planning discussion appropriately occurs on an IETF/W3C liaison
> call that is attended by the relevant Area Directors and Working Group
> chairs.
> It is the responsibility of the Working Group chairs on both sides to
> request this agenda item in a note to the public-ietf-w3c@w3.org
> mailing list, as they plan for Last Call. The W3C and IETF liaisons
> will track these requests, and will ensure that the necessary
> participants attend the requisite liaison calls.

That all looks good. Thanks for writing this strawman.


Peter Saint-Andre
Received on Monday, 17 October 2011 19:17:17 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 19:56:34 UTC