Re: [MMUSIC] I-D Action: draft-ietf-mmusic-rfc4566bis-20.txt

Gunnar Hellström <gunnar.hellstrom@omnitor.se> Thu, 22 June 2017 07:53 UTC

Return-Path: <gunnar.hellstrom@omnitor.se>
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6A3B6128990 for <mmusic@ietfa.amsl.com>; Thu, 22 Jun 2017 00:53:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level:
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=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 fhb-whj-GMeL for <mmusic@ietfa.amsl.com>; Thu, 22 Jun 2017 00:53:47 -0700 (PDT)
Received: from bin-vsp-out-02.atm.binero.net (vsp-unauthed02.binero.net [195.74.38.227]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 697B2128799 for <mmusic@ietf.org>; Thu, 22 Jun 2017 00:53:44 -0700 (PDT)
X-Halon-ID: e6d5c878-571f-11e7-b254-005056917f90
Authorized-sender: gunnar.hellstrom@omnitor.se
Received: from [192.168.2.136] (unknown [77.53.230.196]) by bin-vsp-out-02.atm.binero.net (Halon) with ESMTPSA id e6d5c878-571f-11e7-b254-005056917f90; Thu, 22 Jun 2017 09:53:40 +0200 (CEST)
To: internet-drafts@ietf.org, i-d-announce@ietf.org
References: <149808834030.30646.15372335842482120198@ietfa.amsl.com>
Cc: mmusic@ietf.org
From: =?UTF-8?Q?Gunnar_Hellstr=c3=b6m?= <gunnar.hellstrom@omnitor.se>
Message-ID: <16ef75c9-0169-6dd6-011a-db948df8fdbe@omnitor.se>
Date: Thu, 22 Jun 2017 09:53:34 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0
MIME-Version: 1.0
In-Reply-To: <149808834030.30646.15372335842482120198@ietfa.amsl.com>
Content-Type: multipart/alternative; boundary="------------279A2D86C550181769CCB4EE"
Archived-At: <https://mailarchive.ietf.org/arch/msg/mmusic/EviuQlD8ZTjKHizdduFp-3_m3oE>
Subject: Re: [MMUSIC] I-D Action: draft-ietf-mmusic-rfc4566bis-20.txt
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.22
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: <https://mailarchive.ietf.org/arch/browse/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: Thu, 22 Jun 2017 07:53:49 -0000

Hi Ali,

A couple of observations:


Observation 1: Comments with questions in rtpmap specification.

In section 6.6 rtpmap, there is the following syntax description:

-----------------------------

          rtpmap-value = payload-type SP encoding-name
            "/" clock-rate [ "/" encoding-params ]
          payload-type = zero-based-integer
          encoding-name = token
          clock-rate = integer
            ; do we want to define a limited range for this?
          encoding-params = channels
            ; 4566 is vague about what this can be. RFC4855 seems to be
            ; the authoritative source, and only allows the
            ; value of the media subtype "channels" parameter - the
            ; number of audio channels.
            ; Does anyone think this can be used for something else???
            ; (The implication that multiple parameters might be included
            ; seems a misdirection - additional parameters are
            ; to go into a=fmtp.)
            ; Does anyone have an example of other parameters
            ; using this field?
          channels = integer
            ; Is there any reason to make this less restrictive?
-------------------

The comments look very much as intended to be questions to be resolved before publication.
If there are no answers on the questions, you might want to settle the syntax to the current and delete the comments or change them to explanations.
Or, if you want to keep the questions until the last call, it might be good to collect them in an editors' note, so they are not forgotten.
-------------------------------------------------------------------------------------

Observation 2: Number-of-addresses in multicast addresses

In section 9, syntax description of IP4-multicast and IP6-multicast, there is an unexplained integer parameter at the end. The convention seems to be that parameters get a name indicating its use, and then on another line the parameter syntax is defined. The parameter is the number-of-addresses specified in section 5.7. Therefore I suggest to insert a name "numaddr" in place of the "integer" and explain its syntax in a separate line.

-----------current text----------------------------------
IP4-multicast =         m1 3( "." decimal-uchar )
                         "/" ttl [ "/" integer ]
                         ; IP4 multicast addresses may be in the
                         ; range 224.0.0.0 to 239.255.255.255
                         m1 = ("22" ("4"/"5"/"6"/"7"/"8"/"9")) /
                         ("23" DIGIT )

  IP6-multicast =        IP6-address [ "/" integer ]
                         ; IP6 address starting with FF
-----------proposed new text---------------------
IP4-multicast =         m1 3( "." decimal-uchar )
                         "/" ttl [ "/" numaddr ]
                         ; IP4 multicast addresses may be in the
                         ; range 224.0.0.0 to 239.255.255.255
                         m1 = ("22" ("4"/"5"/"6"/"7"/"8"/"9")) /
                         ("23" DIGIT )

  IP6-multicast =        IP6-address [ "/" numaddr ]
                         ; IP6 address starting with FF

numaddr =	integer
--------------end of change--------------------------



The draft looks good.

Regards
Gunnar
-----------------------------------------
Gunnar Hellström
Omnitor
gunnar.hellstrom@omnitor.se



Den 2017-06-22 kl. 01:39, skrev internet-drafts@ietf.org:
> A New Internet-Draft is available from the on-line Internet-Drafts directories.
> This draft is a work item of the Multiparty Multimedia Session Control of the IETF.
>
>          Title           : SDP: Session Description Protocol
>          Authors         : Mark Handley
>                            Van Jacobson
>                            Colin Perkins
>                            Ali Begen
> 	Filename        : draft-ietf-mmusic-rfc4566bis-20.txt
> 	Pages           : 61
> 	Date            : 2017-06-21
>
> Abstract:
>     This memo defines the Session Description Protocol (SDP).  SDP is
>     intended for describing multimedia sessions for the purposes of
>     session announcement, session invitation, and other forms of
>     multimedia session initiation.  This document obsoletes RFC 4566.
>
>
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-mmusic-rfc4566bis/
>
> There are also htmlized versions available at:
> https://tools.ietf.org/html/draft-ietf-mmusic-rfc4566bis-20
> https://datatracker.ietf.org/doc/html/draft-ietf-mmusic-rfc4566bis-20
>
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?url2=draft-ietf-mmusic-rfc4566bis-20
>
>
> Please note that it may take a couple of minutes from the time of submission
> until the htmlized version and diff are available at tools.ietf.org.
>
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
>
> _______________________________________________
> mmusic mailing list
> mmusic@ietf.org
> https://www.ietf.org/mailman/listinfo/mmusic

--