Indicating WebSocket Protocol as a Transport in the Session Initiation Protocol (SIP) Common Log Format (CLF)
draft-salgueiro-dispatch-websocket-sipclf-02

-- Section 1 --
The HTTP reference needs to change to RFC 7230.

-- Section 5.1 --
A tiny point: it seems to me that the code snippet would be better in an appendix, referred to from here and from Section 5.2.  It seems an unnecessary distraction here.

-- Section 6 --
The string "draft-ietf-sipcore-sip-websocket" is a vestige, and should now be "RFC 7118".  Better, though, more useful, would be a change such as this:

OLD
   Any security considerations specific to the WebSocket protocol or its
   application as a transport for SIP are detailed in the relevant
   specifications (RFC 6455 [RFC6455] and draft-ietf-sipcore-sip-
   websocket [RFC7118]) and are considered outside the scope of this
   document.
NEW
   Any security considerations specific to the WebSocket protocol or its
   application as a transport for SIP are detailed in the relevant
   specifications (the WebSocket potocol [RFC6455] and SIP over
   WebSockets [RFC7118]) and are considered outside the scope of this
   document.
END

-- Section 7 --
The reference document for the IANA registration shouldn't really be this document, as this document doesn't say much.  The right reference is RFC 7118, where people who want to understand SIP over WebSockets need to go.  Or, if you prefer, you can list both documents ("[RFC_XXXX_], [RFC7118]").

Am I correct that this document doesn't update RFC 6872,  because it only adds a new value for the "Transport Flag" field (as opposed to a new field), and therefore the information model is not updated?

From idnits:

  -- Obsolete informational reference (is this intentional?): RFC 2616
     (Obsoleted by RFC 7230, RFC 7231, RFC 7232, RFC 7233, RFC 7234, RFC 7235)

The document shepherd actually got one bit incorrect: This is simply a registration in a registry that only requires "IETF Review", not "Standards Action", so Informational would be perfectly appropriate for this document. It's never going to advance to Internet Standard, and I see no particular reason to have another Proposed Standard hanging around, so we should just make this Informational (which we can simply do on the call). I'm certainly not willing to hold things up if anyone objects, but it seems like a reasonable thing.

- section 4: Surely this is badly stated: "SIP messages
transported over both a plain and secure WebSocket
connection can be completely and uniquely represented by
appropriately setting these two flag fields." I read that as
saying that two flags can uniquely represent a specific
message.

Rather than providing perl code to unpack base64, you could just reference RFC 3548, which explains how to do it.   Having perl code and uudecode preambles is odd, given that uudecode won't actually decode the text, which is indented.   The perl code will work, since it strips leading spaces and doesn't require the begin and end markers to be at the beginning of the line.