Shepherd writeup


  (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 

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

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:

2) Obsolete normative reference: 
RFC 3490 (Obsoleted by RFC 5890, RFC 5891)

The list of nits is below.


  Checking boilerplate required by RFC 5378 and the IETF Trust (see

     No issues found here.

  Checking nits according to

     No issues found here.

  Checking nits according to :

     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 


        Are there normative references to documents that 
        are not ready for advancement or are otherwise in an unclear 

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?


          If the document specifies protocol 
        extensions, are reservations requested in appropriate IANA 


          Are the IANA registries clearly identified?


          If the document creates a new registry, does it define the 
        proposed initial contents of the registry and an allocation 
        procedure for future registrations?


        Does it suggest a 
        reasonable name for the new registry? See [RFC5226].

          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? 


  (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


   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