RTP Header Extension for the RTP Control Protocol (RTCP) Source Description Items
draft-ietf-avtext-sdes-hdr-ext-07

Note: This ballot was opened for revision 05 and is now closed.

(Ben Campbell) Yes

Alissa Cooper Yes

Comment (2016-05-02 for -06)
No email
send info
I too was confused about why MID was not being registered here, but then saw that it is being registered in draft-ietf-mmusic-sdp-bundle-negotiation. I think the text in Section 3 should make this more clear.

I also gather that in some previous version of this draft it may have been registering both, and so there is language in 5.2 and 5.3 ("Initial assignments," "SDES Items") indicating that multiple things are being registered. I think these should be made singular.

(Jari Arkko) No Objection

(Alia Atlas) No Objection

Deborah Brungard No Objection

(Benoît Claise) No Objection

Comment (2016-05-03 for -06)
No email
send info
Editorial

OLD:
First, some requirements language and terminology are defined. The following section motivates why this header extension is sometimes required or at least provides a significant improvement compared to waiting for regular RTCP packet transmissions of the information.

NEW:
First, some requirements language and terminology are defined. The section 3 motivates why this header extension is sometimes required or at least provides a significant improvement compared to waiting for regular RTCP packet transmissions of the information.

(Stephen Farrell) (was Discuss) No Objection

Comment (2016-06-10)
No email
send info
Thanks for handling my DISCUSS point.

--- OLD COMMENTS below, I didn't check 'em

- So this one confused me for a bit but I was thinking
about RFC4568 - shame about that acronym collision;-)
It'd have helped this reader to say that this is not
about sending keys in header fields:-) But I'm probably
not the intended reader, so it's fine that you didn't.

- I wonder if confidentiality protection of these header
fields is likely? Is that more or less likely to be
deployed than some security for RTCP? If there's a
significant difference then I think that ought be called
out. Just pointing at rfc6904 doesn't seem entirely
sufficient to me if nobody ever does it. 

- Has someone done an analysis of the privacy
implications of moving values from one context (RTCP) to
another (RTP) over the range of likely deployments? Note:
I'm not asserting that there is a significant privacy
exposure here, I don't know if there is or not. So I'm
just asking if folks have thought about that and e.g.
whether or not some data exposed in this header field
could allow easier re-identification or correlation or
some similar and possibly subtle privacy issue.

(Joel Jaeggli) No Objection

Comment (2016-05-04 for -06)
No email
send info
think these were addressed by 06

I have reviewed this document (draft-ietf-avtext-sdes-hdr-ext-05) as part of the
Operational directorate's  ongoing effort to review all IETF documents being
processed by the IESG.  These comments were written with the intent of improving
the operational aspects of the IETF drafts. Comments that are not addressed in
last call may be included in AD reviews during the IESG review.  Document editors
and WG chairs should treat these comments just like any other last call comments. 

I am not an expert on the details of RTP thus treat my comments are not really on the technical side of the document. I found the document fine and have no concerns with it.

The IDnits comments can be ignored. They are to be fixed by RFC editor when the
RFC numbers are known.

I have few minor comments:

o Line 180 at the beginning of the paragraph starts “That document also..” Since this is the start of the new paragraph I would recommend setting up the context and explicitly say what “that document” is.

o Line 304 "extension word aligned, thus in total 36 bytes.” seems to assume a word is 32 bits. Due historical reasons to avoid confusion I would explicitly state that a 32 bit alignment is what ‘word aligned’ means.

o Line 458 "shall be applied, i.e. discard items that can be determined to be”
           ^^^^^^ although it is not strictly required but I would use the familiar uppercase format here and probably also use more typical MUST here..

- Jouni
_______________________________________________
OPS-DIR mailing list
OPS-DIR@ietf.org
https://www.ietf.org/mailman/listinfo/ops-dir

(Suresh Krishnan) No Objection

(Mirja Kühlewind) No Objection

Comment (2016-04-26 for -05)
No email
send info
This is a very clear and well written doc. Thanks. Two minor comments:

1) The calculation for the number of transmission N seems slightly over-complicated: "N is selected so that the header extension target delivery probability reaches 1-P^N, where P is the probability of packet loss." Does a new participant already know the loss probably e.g. at the time of joining? Is it correct that if it is assumed to be p=0 that one will send the extension header only once? Should there be a minimum...?

2) Should this doc also register MID?

(Terry Manderson) No Objection

(Alexey Melnikov) No Objection

Comment (2016-04-30 for -06)
No email
send info
The first mention of UTF-8 needs a reference.

I am agreeing with Mirja about registering MID, as the document argues that it would be a good idea.

(Kathleen Moriarty) No Objection

Alvaro Retana No Objection