Subject: [Sipbrandy] WGLC: draft-ietf-sipbrandy-rtpsec-03

From: Gonzalo Camarillo <[email-masked]>
Date: Tue, 12 Dec 2017 15:46:30 +0200

Folks,

I would like to start a WGLC on the following draft. This WGLC will
end on January 12th:

https://datatracker.ietf.org/doc/draft-ietf-sipbrandy-rtpsec/

Thanks,

Gonzalo

---

From: Gonzalo Camarillo <[email-masked]>
Date: Tue, 12 Dec 2017 15:50:12 +0200

Hi,

I have a few initial WGLC comments on this draft. The draft mentions a
few protocols (e.g., SDP) without providing a reference to them. Please,
expand acronyms and add a reference on first use throughout the document.

In section 3.1, "Real-time Protocol" should be something along the
following lines: "RTP (Real-time Transport Protocol) [RFC3550]".

Section 3.1 talks about STIR as the "current target mechanism". I would
remove "current", or rephrase it and talk about the mechanism we
recommend to use instead.

I guess at this point changes in STIR may still trigger modifications in
this draft, right?

Section 4 says:

>  The SIPBRANDY deployment profile of STIR
>  for media confidentiality thus shifts these responsibilities to the
>  endpoints rather than the intermediaries.

I would rephrase it so that the text is more explicit. If intermediaries
MUST NOT provide the verification service, the text should say so.

Section 5 says:

> In [I-D.johnston-dispatch-osrtp], opportunistic approaches considered
> include DTLS-SRTP, security descriptions [RFC4568], and ZRTP
> [RFC6189].
>
>    DTLS-SRTP is the only Standards Track Internet protocol for media
>    security.  For that reason, this specification REQUIRES support for
>    DTLS-SRTP.

But RFC 4568 is also Standards Track:

https://tools.ietf.org/html/rfc4568

Also, REQUIRES does not seem to be an RFC 2119 term.

Cheers,

Gonzalo

---

From: Russ Housley <[email-masked]>
Date: Tue, 12 Dec 2017 17:58:44 -0500

Major:

In Section 4.3, I do not know what is meant by "STIR Profile for media confidentiality".

Minor:

I think the discussion in the first paragraph of Section 3.1 should be slightly expanded to be clear that we are not talking about integrity protection of SDP k= records.  I'd prefer a MUST NOT statement.

In Section 4.1: s/SIP endpoints must acquire/SIP endpoints MUST acquire/

In Section 4.2: 
   s/should be discarded/SHOULD be discarded/
   s/should be generated/SHOULD be generated/

Nits:

The title page and Authors' Addresses section should reflect that Richard Barnes has moved from Mozilla to Cisco.

On the title page, please change my affiliation from "Vigilsec" to "Vigil Security".

In Authors' Addresses section, please change my affiliation from "Vigilsec" to "Vigil Security, LLC".

In Section 3.2: s/proposed by that draft/proposed by that specification/

> On Dec 12, 2017, at 8:46 AM, Gonzalo Camarillo <[email-masked]> wrote:
> 
> Folks,
>