DOCUMENT SHEPHERD WRITE-UP FROM SALVATORE LORETO
(1.a) Who is the Document Shepherd for this document? Has the
Document Shepherd personally reviewed this version of the
document and, in particular, does he or she believe this
version is ready for forwarding to the IESG for publication?
Salvatore Loreto is the document Shepherd. He has reviewed the last version
(13) of the document, and believes is ready for publication.
(1.b) Has the document had adequate review both from key WG members
and from key non-WG members? Does the Document Shepherd have
any concerns about the depth or breadth of the reviews that
have been performed?
The document has received significant review during its tenure in the
HyBi WG.
The 07 version received a TSV Directorate review by Magnus Westerlund.
The 07 version of the document underwent a WG Last Call in April 2011.
The comments received from the TSV Directorate review and WGLC have
been addressed in versions 08, 09 and 12 of the draft.
The 09 version received a review from the responsible area director,
whose comments were substantially addressed in version 10.
The 10 version of the document underwent a IETF Last Call in July 2011.
Lisa Dusseault was selected as the Application Review Team reviewer for version 10
of the draft; her comments and suggestions have been addressed in versions 11, 12 of the draft.
Richard Barnes was selected as Gen-ART reviewer for version 10
of the draft; his comments and suggestions have been addressed in versions 11, 12 of the draft.
Kathleen Moriarty was selected as Sec-dir reviewer for version 10 of the draft;
her comments were in line with the ones from Richard Barnes.
The document has also received a lot of review from the HTTP community
(e.g. Mark Nottingham, Roy Fielding, Henrik Frystyk Nielsen, Julian
Reschke and others) and, most importantly, by the W3C which has already
done an official round of comments and whose concerns with respect to
the API hooks have been addressed.
The document has received a particularly intense review from the web
security community (Eric Rescorla, Adam Barth, etc.), and, as a result,
the protocol underwent a major revision in early 2011.
(1.c) Does the Document Shepherd have concerns that the document
needs more review from a particular or broader perspective,
e.g., security, operational complexity, someone familiar with
AAA, internationalization or XML?
The Shepherd does not have such concerns. As mentioned in the previous
question, the document has already received a detailed review from TSV
Directorate; moreover the security community has had very active WG
members contributing to solve the issue related to possible attacks to
HTTP proxies that do not implement correctly the HTTP Upgrade mechanism.
It is also important to mention that whereas the initial preliminary
version of websocket (the draft-hixie-thewebsokcetprotocol-76 adopted
as baseline for the WG item: -00) had been tentatively included in
browsers, and then taken out due the security concerns (briefly mentioned
above), this is being reversed indicating increasing trust in the
solution (e.g. Firefox inclusion of websocket, based on 07, in its latest
version of that software).
(1.d) Does the Document Shepherd have any specific concerns or
issues with this document that the Responsible Area Director
and/or the IESG should be aware of? For example, perhaps he
or she is uncomfortable with certain parts of the document, or
has concerns whether there really is a need for it. In any
event, if the WG has discussed those issues and has indicated
that it still wishes to advance the document, detail those
concerns here. Has an IPR disclosure related to this document
been filed? If so, please include a reference to the
disclosure and summarize the WG discussion and conclusion on
this issue.
The shepherd has no such concerns. The shepherd is not aware of any
IPR assertions associated with this document.
(1.e) How solid is the WG consensus behind this document? Does it
represent the strong concurrence of a few individuals, with
others being silent, or does the WG as a whole understand and
agree with it?
The document represents agreement across a broad range of participants
in the HyBi Working Group.
(1.f) Has anyone threatened an appeal or otherwise indicated extreme
discontent? If so, please summarise the areas of conflict in
separate email messages to the Responsible Area Director. (It
should be in a separate email because this questionnaire is
entered into the ID Tracker.)
No appeal has been threatened, nor has extreme discontent been expressed.
However it is worth mentioning that the discussion has been extremely
contentious up to the month of December 2010/January 2011, when there was
some indication that due the lack of a valid way out some participants
might have been considering the possibility of leaving the IETF process
altogether.
The consensus around masking as a solution to the security concerns
raised at the end of 2010, although not everybody's favorite, was the
point around which the major parties agreed they could live with, and
the process began moving forward again.
Since then, the process has been more normal for an IETF WG, in that
not everyone agrees with the declared consensus points, but at least
there has been a forward movement on a regular basis.
(1.g) Has the Document Shepherd personally verified that the
document satisfies all ID nits? (See the Internet-Drafts
Checklist and http://tools.ietf.org/tools/idnits/).
Boilerplate checks are
not enough; this check needs to be thorough. Has the document
met all formal review criteria it needs to, such as the MIB
Doctor, media type and URI type reviews?
Here are the ID Nits per
http://tools.ietf.org/idnits?url=http://tools.ietf.org/id/draft-ietf-hybi-thewebsocketprotocol-13.txt
The nits are just that, nits that can be fixed in the next version (which
we will have as a result of reviews provided during IESG review).
The two nits on
1) downrefs to informational are:
RFC2818: HTTP over TLS. Should be easy to obtain an exception for
this very common reference, even if it is informational.
However this RFC is in the downref registry:
http://trac.tools.ietf.org/group/iesg/trac/wiki/DownrefRegistry
2) Obsolete normative reference:
RFC 3490 (Obsoleted by RFC 5890, RFC 5891)
The list of nits is below.
tmp/draft-ietf-hybi-thewebsocketprotocol-13.txt:
Checking boilerplate required by RFC 5378 and the IETF Trust (see
http://trustee.ietf.org/license-info):
----------------------------------------------------------------------------
No issues found here.
Checking nits according to http://www.ietf.org/id-info/1id-guidelines.txt:
----------------------------------------------------------------------------
No issues found here.
Checking nits according to http://www.ietf.org/id-info/checklist :
----------------------------------------------------------------------------
No issues found here.
Miscellaneous warnings:
----------------------------------------------------------------------------
No issues found here.
Checking references for intended status: Proposed Standard
----------------------------------------------------------------------------
(See RFCs 3967 and 4897 for information about using normative references
to lower-maturity documents in RFCs)
** Downref: Normative reference to an Informational RFC: RFC 2818
** Obsolete normative reference: RFC 3490 (Obsoleted by RFC 5890, RFC 5891)
Summary: 2 errors (**), 0 warnings (==), 0 comments (--).
Run idnits with the --verbose option for more detailed information about
the items above.
--------------------------------------------------------------------------------
(1.h) Has the document split its references into normative and
informative?
Yes.
Are there normative references to documents that
are not ready for advancement or are otherwise in an unclear
state?
There is normative reference to draft-ietf-websec-origin, which is
now in Working Group Last Call in the WEBSEC WG.
If such normative references exist, what is the
strategy for their completion? Are there normative references
that are downward references, as described in [RFC3967]? If
so, list these downward references to support the Area
Director in the Last Call procedure for them [RFC3967].
See above.
(1.i) Has the Document Shepherd verified that the document IANA
consideration section exists and is consistent with the body
of the document?
Yes.
If the document specifies protocol
extensions, are reservations requested in appropriate IANA
registries?
Yes.
Are the IANA registries clearly identified?
Yes.
If the document creates a new registry, does it define the
proposed initial contents of the registry and an allocation
procedure for future registrations?
Yes.
Does it suggest a
reasonable name for the new registry? See [RFC5226].
Yes.
If the
document describes an Expert Review process has Shepherd
conferred with the Responsible Area Director so that the IESG
can appoint the needed Expert during the IESG Evaluation?
None required.
(1.j) Has the Document Shepherd verified that sections of the
document that are written in a formal language, such as XML
code, BNF rules, MIB definitions, etc., validate correctly in
an automated checker?
Yes.
(1.k) The IESG approval announcement includes a Document
Announcement Write-Up. Please provide such a Document
Announcement Write-Up? Recent examples can be found in the
"Action" announcements for approved documents. The approval
announcement contains the following sections:
Technical Summary
The Abstract of the draft contains a good technical Summary, so it is copied
below
Abstract
The WebSocket protocol enables two-way communication between a client
running untrusted code running in a controlled environment to a
remote host that has opted-in to communications from that code. The
security model used for this is the Origin-based security model
commonly used by Web browsers. The protocol consists of an opening
handshake followed by basic message framing, layered over TCP. The
goal of this technology is to provide a mechanism for browser-based
applications that need two-way communication with servers that does
not rely on opening multiple HTTP connections (e.g. using
XMLHttpRequest or <iframe>s and long polling).
Working Group Summary
The discussion within HyBi WG was extremely contentious up to the month
of December 2010/January 2011, when there was some indication that due
the lack of a valid way out some participants might have been considering
the possibility of leaving the IETF process altogether. The consensus
around masking as a solution to the security concerns raised at the end
of 2010, although not everybody's favorite, was the point around which
the major parties agreed they could live with, and the process began
moving forward again. Since then, the process has been more normal for
an IETF WG, in that not everyone agrees with the declared consensus
points, but at least there has been a forward movement on a regular basis.
Document Quality
Are there existing implementations of the protocol? Have a
significant number of vendors indicated their plan to
implement the specification?
There are already several implementations of the protocol on different
WebServers (e.g. Glassfish, Jetty, Apache) a library implementation (e.g.,
libwebsocket) and from the client side Firefox6 already includes the
protocol in its last version, Google has announced to include it in a
future version of Chrome Browser and Microsoft has released an
implementation based on 07 on its HTML5 labs site.
Are there any reviewers that
merit special mention as having done a thorough review,
e.g., one that resulted in important changes or a
conclusion that the document had no substantive issues?
If there was a MIB Doctor, Media Type or other expert review,
what was its course (briefly)? In the case of a Media Type
review, on what date was the request posted?
The 07 version received a TSV Directorate review by Magnus Westerlund.
Lisa Dusseault, Richard Barnes and Kathleen Moriarty have reviewed the 10th
version of the draft.