Re: [rtcweb] AD evaluation: draft-ietf-rtcweb-alpn-02

[Martin Thomson <[e-mail]>]

Thanks for the review Alissa,

I've put the changes up here: https://github.com/martinthomson/drafts/pull/30

I realize that you won't get a lot of time to look at this before I
want to push -03, but I thought that I'd offer you the chance at
least.

On 6 March 2016 at 09:44, Alissa Cooper <[e-mail]> wrote:
> “Confidentiality protection” is a fairly general term, but it seems to be used throughout this document to mean something much more specific, i.e., media that is confidential to two peers in a webrtc connection. I think this needs to be clarified in the abstract and Sections 1, 2, and 5 where the more specific meaning is intended. Otherwise this document makes it sound as though data is being sent in the clear when it is not. E.g., in Section 2 this text should be more specific to confidentiality vis a vis the application: "However, data provided over data channels does not receive confidentiality protection.”

Yes, the early sections only implicitly rely on the definition in
Section 3, and that isn't particularly strong.  I've given this a
spin.

> = Section 3 =
>
> "Any entity that forwards
>    content, or records content for later access by entities other than
>    the authenticated peer, SHOULD NOT offer or accept a session with the
>    "c-webrtc" identifier.”
>
> Acknowledging the there are other recommendations in this draft that basically up to the implementation to follow, why is this requirement a SHOULD NOT rather than a MUST NOT?

Made it a MUST.

> Nits:
>
> = Section 1.1 =
>
> Since this document uses RFC 2119 keywords, why does it not include the standard disclaimer recommended by RFC 2119? I think it’s fine to add further words to indicate that the normative requirements are aimed at implementation behavior, but the standard text shouldn’t be omitted.

OK, should that be the post-erratum boilerplate?

> Also, I’m not sure what it means for the document to "fall back on shorthands for establishing interoperability requirements on implementations.” What is the alternative that it is falling back from?

Actually saying what is meant using words.

> = Section 6.3 =
>
> Is there a reason this reference is listed this way?

Blame the tools, which are a mystery to me.  I wanted to cite a
specific section of the HTML5 spec, because finding a specific section
in there is a nightmare.