Skip to main content

Shepherd writeup
rfc6455-17

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.
Back