[apps-discuss] Apps Review of draft-ietf-xrblock-rtcp-xr-burst-gap-discard-10
Eric Burger <eburger@standardstrack.com> Mon, 18 March 2013 14:59 UTC
Return-Path: <eburger@standardstrack.com>
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C518D21F8F2B for <apps-discuss@ietfa.amsl.com>; Mon, 18 Mar 2013 07:59:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -99.713
X-Spam-Level:
X-Spam-Status: No, score=-99.713 tagged_above=-999 required=5 tests=[BAYES_05=-1.11, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o0Bq+GEbZGWq for <apps-discuss@ietfa.amsl.com>; Mon, 18 Mar 2013 07:59:25 -0700 (PDT)
Received: from biz104.inmotionhosting.com (biz104.inmotionhosting.com [173.247.246.244]) by ietfa.amsl.com (Postfix) with ESMTP id 4533A21F8F25 for <apps-discuss@ietf.org>; Mon, 18 Mar 2013 07:59:25 -0700 (PDT)
Received: from 8.sub-70-192-200.myvzw.com ([70.192.200.8]:6143 helo=[10.184.52.190]) by biz104.inmotionhosting.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.80) (envelope-from <eburger@standardstrack.com>) id 1UHbX0-0001Tt-0i; Mon, 18 Mar 2013 07:59:22 -0700
Mime-Version: 1.0 (1.0)
From: Eric Burger <eburger@standardstrack.com>
Content-Type: multipart/alternative; boundary="Apple-Mail-D19D0371-3D99-47E9-B244-413F2990C3E6"
X-Mailer: iPad Mail (10B146)
Message-Id: <AB5F7887-B9BC-44E6-8495-C3165FDD2A65@standardstrack.com>
Date: Mon, 18 Mar 2013 10:59:22 -0400
Content-Transfer-Encoding: 7bit
To: "draft-ietf-xrblock-rtcp-xr-burst-gap-discard@tools.ietf.org" <draft-ietf-xrblock-rtcp-xr-burst-gap-discard@tools.ietf.org>, "xrblock-chairs@tools.ietf.org" <xrblock-chairs@tools.ietf.org>
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - biz104.inmotionhosting.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - standardstrack.com
X-Source:
X-Source-Args:
X-Source-Dir:
Cc: "apps-discuss@ietf.org" <apps-discuss@ietf.org>
Subject: [apps-discuss] Apps Review of draft-ietf-xrblock-rtcp-xr-burst-gap-discard-10
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss>
List-Post: <mailto:apps-discuss@ietf.org>
List-Help: <mailto:apps-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 18 Mar 2013 14:59:25 -0000
In general, this document is ready to go. I have one editorial suggestion. In order to understand this document, I had to read draft-ietf-xrblock-rtcp-xr-discard-11 and draft-ietf-xrblock-rtcp-xr-discard-rle-metrics-05 to figure out where this draft fits into the jitter reporting ecosystem. I get why these are all small, separate drafts. However, I could not easily find an overarching document tying things together. draft-ietf-xrblock-rtcp-xr-discard-rle-metrics-05 does a decent job in the Introduction of describing the relationship between xr-burst-gap-discard and xr-discard. However, that is in the context of why we have a third draft on what on first read looks like the same metrics. The three drafts cover three facets of jitter metrics. What is missing is a roadmap for implementors that does two things. The first is it makes it clear where to go to do what. I can easily imagine an implementor wanting to do jitter measurements, finding just one of these drafts, and think they need to do a proprietary extension because the IETF 'forgot' to include something in the jitter reporting. Another issue is I found myself reading xr-discard and xr-burst-gap-discard in parallel. They made a whole lot more sense reading them that way than one at a time. Moreover, I found I had to read them in parallel to understand xr-burst-gap-discard. Therefore, it would be helpful to either have a separate roadmap document or a paragraph or two in each document referring the reader to the other documents. That way the reader knows they exist, knows there may be a better / more coverage for reporting than a single document implies, and they can find the other documents. I would offer this will improve the readability and ultimate interoperability of the resulting implementations.