Re: [MMUSIC] draft-nandakumar-mmusic-proto-iana-registration-00

Paul Kyzivat <pkyzivat@alum.mit.edu> Fri, 14 November 2014 00:10 UTC

Return-Path: <pkyzivat@alum.mit.edu>
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B2CFF1A001D for <mmusic@ietfa.amsl.com>; Thu, 13 Nov 2014 16:10:43 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.235
X-Spam-Level:
X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_SOFTFAIL=0.665] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MfEIMKsH36Tw for <mmusic@ietfa.amsl.com>; Thu, 13 Nov 2014 16:10:42 -0800 (PST)
Received: from resqmta-po-05v.sys.comcast.net (resqmta-po-05v.sys.comcast.net [96.114.154.164]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CE78F1A009E for <mmusic@ietf.org>; Thu, 13 Nov 2014 16:10:35 -0800 (PST)
Received: from resomta-po-13v.sys.comcast.net ([96.114.154.237]) by resqmta-po-05v.sys.comcast.net with comcast id FCAN1p00757bBgG01CAblw; Fri, 14 Nov 2014 00:10:35 +0000
Received: from dhcp-a55a.meeting.ietf.org ([31.133.165.90]) by resomta-po-13v.sys.comcast.net with comcast id FC8S1p00T1xLjbz01C8VCt; Fri, 14 Nov 2014 00:08:33 +0000
Message-ID: <546547FA.2060207@alum.mit.edu>
Date: Thu, 13 Nov 2014 14:08:26 -1000
From: Paul Kyzivat <pkyzivat@alum.mit.edu>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.6.0
MIME-Version: 1.0
To: mmusic@ietf.org
References: <949EF20990823C4C85C18D59AA11AD8B27A2DB@FR712WXCHMBA11.zeu.alcatel-lucent.com>
In-Reply-To: <949EF20990823C4C85C18D59AA11AD8B27A2DB@FR712WXCHMBA11.zeu.alcatel-lucent.com>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1415923835; bh=ksE6U7ktYuwRwNrcOuXcP8sqrY4+72aVphf5zLegIQ4=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=WGFfdas4yEWCNTDTTRBdKjGb4H04Od6p5y3sKNhwei1MSDE+sf9dgGF7kuaMXbZEW kFybhYblZw1dwF+gQKDYwsefIOW1r9NTcPJKp8+T2NTXqDRpNYvN6MXJPC0iilCdl6 o03/JnQ6V7aolBw5P61IBH4Oa2dr2Ge4GXHU9arMyLo6MXbiqQn6s/GBgTLx/owfoK P8jqcYAdPuPigOcYtA3Yx6NtTBpEvTTVia7m8AiK9U6N7JOEyK0Vy+B7c0m6AOAZTj /vx9x+D4OlpHBtS5d5Z+cBNqX6IskrnnbrS+ueWNeXaWNKhJlMCgW9xQDBat7+dlXU JWeGbPOkFTeLQ==
Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/RGodVLu5ZNnerSftFLIw8bvnNhM
Subject: Re: [MMUSIC] draft-nandakumar-mmusic-proto-iana-registration-00
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group <mmusic.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mmusic>, <mailto:mmusic-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/mmusic/>
List-Post: <mailto:mmusic@ietf.org>
List-Help: <mailto:mmusic-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mmusic>, <mailto:mmusic-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 14 Nov 2014 00:10:44 -0000

On 11/13/14 9:36 AM, DRAGE, Keith (Keith) wrote:
> So based on the discussion just taking place in MMUSIC I would make the following two comments:
>
> 1)	In section 3, every item should contain a normative reference to the RFC (or other document) that defines the framing structure that goes with that label.

We are talking about protos of the form A/B/C/D

For each boundary in there (A/B, B/C, C/D) there must exist, somewhere, 
a definition of how the upper layer is packaged within the lower layer. 
This is basic network stack stuff.

In many cases the lower layer has a well defined mechanism for this. In 
some cases (e.g. TCP) it does not. In some cases the upper layer spec 
has a specification for how it is framed over specific lower layers. In 
some cases it may need to be separate. We probably don't want to force 
people to declare the obvious. But may not be clear what is obvious and 
what is not.

	Thanks,
	Paul

> 2)	In section 4, I would prefer to see text that defines exactly the changes that need to be made and to exactly where.
>
> So this is to the "proto" subregistry within "Session Description Protocol (SDP) Parameters" registry.
>
> And essentially for every entry you need to state:
> Type: protoc
> SDP Name: ...
> Reference: ...
>
> Will the reference just be to this draft, or to this draft and the document that also defines the framing.
>
> Regards
>
> Keith
> _______________________________________________
> mmusic mailing list
> mmusic@ietf.org
> https://www.ietf.org/mailman/listinfo/mmusic
>