Subject: Re: [avtext] Taxonomy

From: "Gonzalo Salgueiro (gsalguei)" <[email-masked]>
Date: Fri, 18 Oct 2013 22:40:27 +0000

Colin -

The -03 version of the document has been posted and is available here:

Draft:  http://tools.ietf.org/html/draft-lennox-raiarea-rtp-grouping-taxonomy-03
Diffs:    http://www.ietf.org/rfcdiff?url2=draft-lennox-raiarea-rtp-grouping-taxonomy-03

Your comments should all be addressed, except for this editorial one:

I find it difficult to read in places, due to the excessive use of sub-section numbering.  The might would be easier to read if the 4th level headings were removed, and replaced by prose.

So far we've done this for the 3.3.4.x sub-sections only. While your comment is perfectly valid and one we'll happily attend to in the future, the thought was to wait for the document structure to be more stable.  The past two versions have been major overhauls, so the authors prefer to wait for it to be less in flux before attempting to subsume these 4th level sub-sections.  Hope that is ok.

Cheers,

Gonzalo

On Sep 22, 2013, at 11:58 AM, Colin Perkins <[email-masked]<mailto:[email-masked]>> wrote:

Hi Magnus,

On 20 Sep 2013, at 07:27, Magnus Westerlund <[email-masked]<mailto:[email-masked]>> wrote:
I just wanted to comment on what have and have not been addressed in the
new version of the taxonomy draft. Me and Bo forgot about this email
until after we had done our submission, sorry about that.

No problem; the new draft looks to address many of my concerns.

A comment on the latest version: I find it difficult to read in places, due to the excessive use of sub-section numbering.  The might would be easier to read if the 4th level headings were removed, and replaced by prose.

On 2013-07-19 22:34, Colin Perkins wrote:
On 16 Jul 2013, at 15:53, <[email-masked]<mailto:[email-masked]>> wrote:
(As AVTEXT WG cochair)

The latest version of the taxonomy draft has been submitted

https://datatracker.ietf.org/doc/draft-lennox-raiarea-rtp-grouping-taxonomy/

This document was allocated to AVTEXT by dispatch, and we have
created a milestone for it in AVTEXT.

This draft is not yet a working group document.

We do expect to spend some significant time discussing the contents
in the AVTEXT meeting in Berlin, so please start raising your
issues on the AVTEXT list.

This looks like a very useful document, that will hopefully avoid
some confusion in future. Some brief comments:

- Section 2.4.2 incorrectly expands RTCP as "Real-time Transport
Control Protocol", and should be "RTP Control Protocol".

Not addressed, but I have entered it into the source so that it will be
addressed in the next version.

Okay.

- Section 2.6.2, 2nd bullet: it might be useful to explain that
multiple RTP sessions can only be multiplexed over a single transport
flow if some sort of shim is included in the packets to distinguish
the sessions (the referenced
draft-westerlund-avtcore-transport-multiplexing describes why this
has to be the case in detail, but I think the high-level point is
important to cover in this draft too). I also think the term "session
multiplexing" is unclear about what is multiplexed, and would prefer
it not be used.

This has been substantially rewritten and split appart. And I agree that
Session multiplexing is not a good term and the new document discusses
both RTP Session based separation of RTP Packet Streams and Multiple RTP
sessions over one Media Transport. See section 3.3.4.2 and 3.4.

The new version is better. I would suggest that Sections 3.3.4.1 and 3.3.4.2 should also mention how the streams can be explicitly related (i.e., using a common RTCP CNAME, or other means).

- Section 2.9.1: I'm not sure an m= line description the
configuration required to decode a media stream. It might be better
to say the combination of an m= line, the associated payload format
mapping in the associated a=rtpmap: lines, and the payload format
parameters in a=fmtp: lines define the configuration required to
decode a media stream. Just the m= line is only sufficient for the
trivial static payload types.

Also this has ceased to exist in the form you protested.

- Section 2.10: what's the relationship between a "participant" and
an "end point"?

In most cases a one to one as the end point is this addressable entity
for the media chain and the participant is what is addressable on the
signaling plane. However, this is not always true if we take SIP forking
or other cases where a signalling entity has multiple points of
presence. This will need to be better explored and the place to do it is
likely in the Section 4 rewrite. This section is intended to cover how
the RTP session, transport topologies and signaling interact to cause
difficult situations.

Decomposed endpoints would be another, presumably.

- Section 2.11.2: I'm not sure an RTCP CNAME can identify a
participant in an RTP multimedia session; the RTCP CNAME describes a
synchronisation context, but a participant can generate multiple
unsynchronised media streams.

This is now Section 2.2.4.2, however the question remains.

I think I agree that Participant is likely to go to far in the bindings,
however CNAME clearly has an overload functionality of being both an end
point identifier and a synchronization context. I think the
synchronization context is the one that must prevail and the end point
usage discontinued.

Agree.

For the next version I have removed this bullet. Discussion of
identification is likely needed but likely in a better context. I think
this do applies for exploration in the Section 4 rewrite.

That makes sense.

- Section 3.1.1: note that RTP uses NTP-format timestamps, but
doesn't require the clock be synchronised to NTP. This section can be
mis-read as requiring the use of NTP, rather than just the timestamp
format of NTP.

Section 3.1.1.1. now says:

 RFC3550 [RFC3550] describes Inter-media synchronization between RTP
 Sessions based on RTCP CNAME, RTP and Network Time Protocol (NTP)
 [RFC5905] formatted timestamps of a reference clock.

Better, although an explicit statement that the NTP-format timestamps don't need to be NTP synchronised would still be useful. Also, it might help to reference the clksrc draft?

--
Colin Perkins
http://csperkins.org/

_______________________________________________
avtext mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/avtext