Review of draft-ietf-bfcpbis-sdp-ws-uri-07

Joel Halpern <jmh@joelhalpern.com> Fri, 23 December 2016 23:15 UTC

Return-Path: <jmh@joelhalpern.com>
X-Original-To: ietf@ietf.org
Delivered-To: ietf@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 0CBC4129588; Fri, 23 Dec 2016 15:15:32 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Joel Halpern <jmh@joelhalpern.com>
To: <gen-art@ietf.org>
Subject: Review of draft-ietf-bfcpbis-sdp-ws-uri-07
X-Test-IDTracker: no
X-IETF-IDTracker: 6.40.3
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <148253493203.16856.4857620752315294427.idtracker@ietfa.amsl.com>
Date: Fri, 23 Dec 2016 15:15:32 -0800
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf/wLtEQhi73eciGWlWnZb5uHi4LSY>
Cc: bfcpbis@ietf.org, ietf@ietf.org, draft-ietf-bfcpbis-sdp-ws-uri.all@ietf.org
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.17
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ietf/>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 23 Dec 2016 23:15:32 -0000

Reviewer: Joel Halpern
Review result: Ready with Nits

I am the assigned Gen-ART reviewer for this draft. The General Area
Review Team (Gen-ART) reviews all IETF documents being processed
by the IESG for the IETF Chair.  Please treat these comments just
like any other last call comments.

For more information, please see the FAQ at

<https://trac.ietf.org/trac/gen/wiki/GenArtfaq>.

Document: draft-ietf-bfcpbis-sdp-ws-uri-??
Reviewer: Joel Halpern
Review Date: 2016-12-23
IETF LC End Date: 2017-01-12
IESG Telechat date: 2017-01-19

Summary: This document is ready for publication as a Proposed Standard
RFC.  I have a few minor comments that should be considered s they may
improve future understanding of the document.

Major issues: None

Minor issues:
    In reading section 4.2 and 4.3, I believe I can guess at certain
intended behaviors, but it is not as clearly stated as I think is
desirable.  There is also one odd statement in section 4.3

    Taking the odd statement first, the text in section 4.3 refers the
active answerer "towards
   the IP address and port of the offerer".  But when WebSockets is
used, one does not connect to the IP address and port, but to the URI
specified.

    I believe that the intent in 4.2 and 4.3 is that whichever side
will be "passive" is required to provide an a=ws-uri or a=wss-uri so
that the other side can establish the connection to the URI.  But
section 4.2 does not say that.  And the text in section4.3 that talks
about providing the URI in the a= does not qualify whether it is
required with active, passive, or both.  

Nits/editorial comments:  N/A