RTP Control Protocol (RTCP) Extensions for Single-Source Multicast Sessions with Unicast Feedback
draft-ietf-avt-rtcpssm-19

[Ballot discuss]
Updated as per revision 19:

In Section 7.1.8:

Address: 4 octets (IPv4), 16 octets (IPv6), or n octets (DNS name)
  The address to which receivers send feedback reports.  For IPv4
  and IPv6 fixed-length address fields are used.  A DNS name is an
  arbitrary length string that is padded with null bytes to the
  next 32 bit boundary.  The string MAY contain IDNA domain names
  and MUST be UTF-8 encoded [11].

I am really confused here: this is either transporting binary IPv4/IPv6 addresses or a DNS name?

[Ballot comment]
Section 4.2., paragraph 11:
>    (PLI55) and the config string contains the hexadecimal represenation

  Nit: s/represenation/representation/


Section 6., paragraph 1:
>    confideniality of the media streams is achieved by encryption.

  Nit: s/confideniality/confidentiality/

[Ballot discuss]
This is a discuss-discuss, intended to stimulate discussion on the telechat.  If the discussion
persuades me these changes are inapropriate for an extensions draft, I will move to comment
on the call.  The authors are requested to consider the issues raised in either case...

This document updates RFC 3640, and largely depends upon 3640 for its security
considerations.  RFC 4855 imposed new requirements for payload registration, including
a number of issues in the security considerations section (e.g., identifying whether there is
active content, opportunities for steganography, and issues arising from compression
techniques).

I would like the authors to review the requireemnts in 4855 and ensure that all are
addressed in either 3640 or 4855.  Is this an appropriate request?

[Ballot comment]
A couple of details about the report aggregation in section 7.2.1 are unclear to me.

* I don't see a schedule of reporting prescribed for method (a).  If the schedule is left to the discretion of the Distribution Source, it should be stated explicitly

* In method (b), does the distribution source use just the most recent value received from each receive (as in method a) or does it use all received values in the summarization window?

[Ballot discuss]
I've skimmed the document and found 2 issues:

In Section 7.1.1:


Timestamp: 64 bits
  Indicates the wallclock time when this report was sent.
  Wallclock time (absolute date and time) is represented using the
  timestamp format of the Network Time Protocol (NTP), which is in
  seconds relative to 0h UTC on 1 January 1900 [4].    The

The normative reference [4] is defined as:
[4] B. Quinn, R. Finlayson, "SDP Source-Filters", RFC 4570, July
    2006.

which looks wrong to me.

  wallclock time MAY (but need not) be NTP-synchronized but it MUST
  provide a consistent behavior in the advancement if time (similar
  to NTP).  The full resolution NTP timestamp is used which is a
  64-bit unsigned fixed-point number with the integer part in the
  first 32 bits and the fractional part in the last 32 bits.  This
  format is similar to RTCP sender reports (section 6.4.1 of [1]).
  The timestamp value is used to enable detection of duplicate
  packets, reordering and to provide a chronological profile of the
  feedback reports.


In Section 7.1.8:

Address: 4 octets (IPv4), 16 octets (IPv6), or n octets (DNS name)
  The address to which receivers send feedback reports.  For IPv4
  and IPv6 fixed-length address fields are used.  A DNS name is an
  arbitrary length string that is padded with null bytes to the
  next 32 bit boundary.  The string MUST be UTF-8 encoded [11].

I am really confused here: this is either transporting binary IPv4/IPv6 addresses or a DNS name?

Also, why is this UTF-8 encoded? Does this mean that IDNA domain names
are allowed? If yes, the document should say so. If not, use of US-ASCII is enough for DNS names.

IANA questions/comments:

- in Action 2 the document specifies what to do with value 3 but
does not specify what to do with value 9. Is value 9 generally
available for assignment?

Note to author: Control Packet Type 208 has already been assigned
to another protocol.

Action 1:

Upon approval of this document, IANA will make the following
assignment in the "RTCP Control Packet types (PT)" registry at
http://www.iana.org/assignments/rtp-parameters

Value Abbrev. Name Reference
-------- --------- --------------------------------- ---------
TBD RSI Receiver Summary Information [RFC-avt-rtcpssm-18]


Action 2:

Upon approval of this document, IANA will create the following
registry at
http://www.iana.org/assignments/rtp-parameters

Registry Name: RSI Sub-Report Block Types
Registration Procedures: First Come First Served
Initial contents of this sub-registry will be:

Value Name Long Name Reference
----- ------- ----------------------------- ---------
0 IPv4 Address IPv4 Feedback Target Address [RFC-avt-rtcpssm-18]
1 IPv6 Address IPv6 Feedback Target Address [RFC-avt-rtcpssm-18]
2 DNS Name DNS Name indicating Feedback Target Address
[RFC-avt-rtcpssm-18]
3 Reserved for Feedback Target Address [RFC-avt-rtcpssm-18]
4 Loss Loss distribution [RFC-avt-rtcpssm-18]
5 Jitter Jitter Distribution [RFC-avt-rtcpssm-18]
6 RTT Round-trip time distribution [RFC-avt-rtcpssm-18]
7 Cumulative loss Cumulative loss distribution [RFC-avt-rtcpssm-18]
8 Collisions SSRC Collision list [RFC-avt-rtcpssm-18]
9 Reserved [RFC-avt-rtcpssm-18]
10 Stats General statistics [RFC-avt-rtcpssm-18]
11 RTCP BW RTCP Bandwidth indication [RFC-avt-rtcpssm-18]
12 Group Info RTCP Group and Average Packet size [RFC-avt-rtcpssm-18]
13-255 Unassigned


Action 3:

Upon approval of this document, IANA will make the following
assignment in the "att-field (media level only)" registry at
http://www.iana.org/assignments/sdp-parameters

Type SDP Name Reference
---- ------------------ ---------
att-field (media level only)
unicast-rtcp [RFC-avt-rtcpssm-18]


We understand the above to be the only IANA Actions for this document.

PROTO Write-up

(1.a) Who is the Document Shepherd for this document? Has the
Document Shepherd personally reviewed this version of the
document and, in particular, does he or she believe this
version is ready for forwarding to the IESG for publication?

Colin Perkins is the document shepherd. He has reviewed this version,
and believes it ready for publication.

(1.b) Has the document had adequate review both from key WG members
and from key non-WG members? Does the Document Shepherd have
any concerns about the depth or breadth of the reviews that
have been performed?

No concerns - the draft has had adequate review.

(1.c) Does the Document Shepherd have concerns that the document
needs more review from a particular or broader perspective,
e.g., security, operational complexity, someone familiar with
AAA, internationalization or XML?

No concerns.

(1.d) Does the Document Shepherd have any specific concerns or
issues with this document that the Responsible Area Director
and/or the IESG should be aware of? For example, perhaps he
or she is uncomfortable with certain parts of the
document, or
has concerns whether there really is a need for it. In any
event, if the WG has discussed those issues and has indicated
that it still wishes to advance the document, detail those
concerns here. Has an IPR disclosure related to this
document
been filed? If so, please include a reference to the
disclosure and summarize the WG discussion and conclusion on
this issue.

No concerns or issues. No IPR disclosure.

(1.e) How solid is the WG consensus behind this document? Does it
represent the strong concurrence of a few individuals, with
others being silent, or does the WG as a whole understand and
agree with it?

There is solid consensus, and interest from the mboned group and SSM
community.

(1.f) Has anyone threatened an appeal or otherwise indicated
extreme
discontent? If so, please summarise the areas of conflict in
separate email messages to the Responsible Area Director.
(It
should be in a separate email because this questionnaire is
entered into the ID Tracker.)

No discontent.

(1.g) Has the Document Shepherd personally verified that the
document satisfies all ID nits? (See
http://www.ietf.org/ID-Checklist.html and
http://tools.ietf.org/tools/idnits/). Boilerplate checks are
not enough; this check needs to be thorough. Has the
document
met all formal review criteria it needs to, such as the MIB
Doctor, media type and URI type reviews?

The idnits tool reports two instances of lines with non-RFC3330-
compliant IPv4 addresses in the draft, but these are in an
informative description of the ASM multicast space, and so are not
problematic.

The idnits tool also reports potential problems with the references,
but these are false positives.

(1.h) Has the document split its references into normative and
informative? Are there normative references to documents
that
are not ready for advancement or are otherwise in an unclear
state? If such normative references exist, what is the
strategy for their completion? Are there normative
references
that are downward references, as described in [RFC3967]? If
so, list these downward references to support the Area
Director in the Last Call procedure for them [RFC3967].

References have been split. These is one normative reference to an
internet draft (reference 12 to draft-ietf-mmusic-sdp-source-
attributes-00.txt which is in good shape for completion in MMUSIC).

(1.i) Has the Document Shepherd verified that the document IANA
consideration section exists and is consistent with the body
of the document? If the document specifies protocol
extensions, are reservations requested in appropriate IANA
registries? Are the IANA registries clearly identified? If
the document creates a new registry, does it define the
proposed initial contents of the registry and an allocation
procedure for future registrations? Does it suggest a
reasonable name for the new registry? See [RFC2434]. If the
document describes an Expert Review process has Shepherd
conferred with the Responsible Area Director so that the IESG
can appoint the needed Expert during the IESG Evaluation?

The IANA considerations exists, is consistent, and appears to be
clearly specified.

(1.j) Has the Document Shepherd verified that sections of the
document that are written in a formal language, such as XML
code, BNF rules, MIB definitions, etc., validate correctly in
an automated checker?

Yes (ABNF in section 10.1).

(1.k) The IESG approval announcement includes a Document
Announcement Write-Up. Please provide such a Document
Announcement Write-Up? Recent examples can be found in the
"Action" announcements for approved documents. The approval
announcement contains the following sections:

Technical Summary
Relevant content can frequently be found in the abstract
and/or introduction of the document. If not, this may be
an indication that there are deficiencies in the abstract
or introduction.

This document specifies an extension to the Real-time Transport
Control Protocol (RTCP) to use unicast feedback to a multicast
sender. The proposed extension is useful for single-source multicast
sessions such as Source-Specific Multicast (SSM) communication where
the traditional model of many-to-many group communication is either
not available or not desired. In addition, it can be applied to any
group that might benefit from a sender-controlled summarized
reporting mechanism.

Working Group Summary
Was there anything in WG process that is worth noting?
For
example, was there controversy about particular points or
were there decisions where the consensus was particularly
rough?

There is interest in this work both with AVT and the MBONED
community,
and solid consensus to publish the draft.

Document Quality
Are there existing implementations of the protocol?
Have a
significant number of vendors indicated their plan to
implement the specification? Are there any reviewers that
merit special mention as having done a thorough review,
e.g., one that resulted in important changes or a
conclusion that the document had no substantive
issues? If
there was a MIB Doctor, Media Type or other expert review,
what was its course (briefly)? In the case of a Media
Type
review, on what date was the request posted?

The draft fills an important gap and is needed to deployed SSM-based
IPTV systems. As a result there is strong interest in seeing it
done,
and implementations are expected.

Personnel
Who is the Document Shepherd for this document? Who is
the
Responsible Area Director?

Colin Perkins is the document shepherd. Cullen Jennings is the
responsible
area director.

Scheduled for submission to IESG Mar 2006 after many delays -
it is blocking the mmusic sdp filter draft in the RFC Editor Queue
and is needed for SSM to work.  Have pushed on this in the past
because SSM is of serious deployment interest in discussions such
as for ALC, and RTP can be there too.