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

From: Alissa Cooper <[email-masked]>
Date: Sat, 5 Mar 2016 22:44:22 +0000

I have reviewed this draft in preparation for IETF LC. I have a couple of questions and comments that should be resolved before IETF LC, and some nits.

Comments/questions:

= General =

“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.” 

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

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.

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? 

= Section 2 =

s/a Secure/Secure/

= Section 3 =

s/between session/between a session/

= Section 4 =

s/This is not a digital rights management mechanism./The mechanism specified in this document is not a digital rights management mechanism./

Cute, but suggest deleting this as it seems superfluous: "In other cases, effects might not be temporally localized:
   transmitted smells could linger for a period after communications
   cease.”

= Section 6.3 =

Is there a reason this reference is listed this way?

---

From: Martin Thomson <[email-masked]>
Date: Fri, 18 Mar 2016 13:53:10 +1100

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.

> “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 webr…

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.

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

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

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

Actually saying what is meant using words.

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

---

From: Alissa Cooper <[email-masked]>
Date: Wed, 23 Mar 2016 13:31:48 -0700

These changes look good to me. Will issue IETF LC when you submit the -03.

Thanks,
Alissa

> On Mar 17, 2016, at 7:53 PM, Martin Thomson <[email-masked]> wrote:
>