Re: [Gen-art] Gen-ART review of draft-ietf-tram-stun-origin-05

Jari Arkko <jari.arkko@piuha.net> Wed, 13 May 2015 09:59 UTC

Return-Path: <jari.arkko@piuha.net>
X-Original-To: gen-art@ietfa.amsl.com
Delivered-To: gen-art@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8F00A1B29F0; Wed, 13 May 2015 02:59:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.91
X-Spam-Level:
X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
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 Pm5Uj7syGgu4; Wed, 13 May 2015 02:59:03 -0700 (PDT)
Received: from p130.piuha.net (p130.piuha.net [IPv6:2a00:1d50:2::130]) by ietfa.amsl.com (Postfix) with ESMTP id 5AB381B29EC; Wed, 13 May 2015 02:58:44 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id A950C2CC61; Wed, 13 May 2015 12:58:43 +0300 (EEST) (envelope-from jari.arkko@piuha.net)
X-Virus-Scanned: amavisd-new at piuha.net
Received: from p130.piuha.net ([127.0.0.1]) by localhost (p130.piuha.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rOor5Iu1USpU; Wed, 13 May 2015 12:58:41 +0300 (EEST)
Received: from [127.0.0.1] (p130.piuha.net [IPv6:2a00:1d50:2::130]) by p130.piuha.net (Postfix) with ESMTP id 41A3A2CC5A; Wed, 13 May 2015 12:58:40 +0300 (EEST) (envelope-from jari.arkko@piuha.net)
Content-Type: multipart/signed; boundary="Apple-Mail=_5EF3B775-6534-4603-90FE-097C15CEBBE2"; protocol="application/pgp-signature"; micalg=pgp-sha512
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\))
From: Jari Arkko <jari.arkko@piuha.net>
In-Reply-To: <CE03DB3D7B45C245BCA0D24327794936468095@MX104CL02.corp.emc.com>
Date: Wed, 13 May 2015 11:58:38 +0200
Message-Id: <F54E9AAD-9A81-41C4-87F8-8BAFE37248EC@piuha.net>
References: <CE03DB3D7B45C245BCA0D2432779493641B3BE@MX104CL02.corp.emc.com> <EC554156-5C29-440F-ACF8-95008EE481AE@piuha.net> <CAKhHsXFtr7LoS1HDd5YR5fxDbfUugNZ5r_f-P9XAq4O2qVheFA@mail.gmail.com> <CE03DB3D7B45C245BCA0D24327794936468095@MX104CL02.corp.emc.com>
To: "Black, David" <david.black@emc.com>
X-Mailer: Apple Mail (2.1878.6)
Archived-At: <http://mailarchive.ietf.org/arch/msg/gen-art/-5Osg-z1dp7OJQLHef-s5tEZjmE>
Cc: "justin@uberti.name" <justin@uberti.name>, "tram@ietf.org" <tram@ietf.org>, "General Area Review Team \(gen-art@ietf.org\)" <gen-art@ietf.org>, "yoakum@avaya.com" <yoakum@avaya.com>, Alan Johnston <alan.b.johnston@gmail.com>, "ietf@ietf.org" <ietf@ietf.org>
Subject: Re: [Gen-art] Gen-ART review of draft-ietf-tram-stun-origin-05
X-BeenThere: gen-art@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "GEN-ART: General Area Review Team" <gen-art.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/gen-art>, <mailto:gen-art-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/gen-art/>
List-Post: <mailto:gen-art@ietf.org>
List-Help: <mailto:gen-art-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/gen-art>, <mailto:gen-art-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 13 May 2015 09:59:05 -0000

Thanks, all. I will assume the changes will be made in an upcoming revision.

Jari

On 21 Apr 2015, at 17:08, Black, David <david.black@emc.com> wrote:

> Alan,
>  
> This approach seems fine.  Please add an RFC reference for the STUN rules, preferably citing a section # to make the rules easy to find (if you had trouble locating them, it’ll be even harder for other readers ...).
>  
> Thanks,
> --David
>  
> From: Alan Johnston [mailto:alan.b.johnston@gmail.com] 
> Sent: Tuesday, April 21, 2015 7:21 AM
> To: Jari Arkko
> Cc: Black, David; justin@uberti.name; yoakum@avaya.com; General Area Review Team (gen-art@ietf.org); ietf@ietf.org; tram@ietf.org
> Subject: Re: [Gen-art] Gen-ART review of draft-ietf-tram-stun-origin-05
>  
> Hi Jari,
>  
> We unfortunately did not reply to David for his review - our mistake.  See below for our response.
>  
> - Alan -
>  
> On Tue, Apr 21, 2015 at 1:55 AM, Jari Arkko <jari.arkko@piuha.net> wrote:
> Thanks for your review, David. I am trying to determine
> how to deal with this draft in the upcoming IESG telechat.
> Has there been any discussion of the issue you raise?
> Do the authors have a response?
> 
> Jari
> 
> On 21 Mar 2015, at 06:12, Black, David <david.black@emc.com> wrote:
> 
> > I am the assigned Gen-ART reviewer for this draft. For background on
> > Gen-ART, please see the FAQ at
> >
> > <http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.
> >
> > Please resolve these comments along with any other Last Call comments
> > you may receive.
> >
> > Document: draft-ietf-tram-stun-origin-05
> > Reviewer: David L. Black
> > Review Date: March 20, 2015
> > IETF LC End Date: March 17, 2015
> >
> > Summary: This draft is on the right track, but has open issues
> >               described in the review.
> >
> > This draft describes the addition of a web origin attribute to STUN and
> > usage of that attribute in several protocol contexts.  The draft is well-
> > written and easy to read.  I found one minor issue which may be editorial.
> >
> > Major issues: None.
> >
> > Minor issues:
> >
> > Section 2.7 discusses use of multiple STUN origins with Web RTC and
> > concludes by imposing a "MUST" requirement on use of multiple STUN
> > origins with HTTP in general (use first origin, ignore others).  While
> > Web RTC may be the predominant or only current use of STUN and TURN with
> > HTTP, this "MUST" could foreclose the use of STUN origins with other
> > uses of HTTP.  I'm not sure what those possible future uses might be,
> > but at a minimum this draft ought to more tightly scope its discussion
> > of use of STUN origins with HTTP to limit that usage to Web RTC.  If
> > there's a good way for a STUN or TURN server to detect Web RTC usage,
> > requiring STUN and TURN servers to look for Web RTC as the use of
> > HTTP, and only impose this "MUST" requirement if Web RTC is detected
> > would better align that requirement with the discussion in this draft.
>  
> David,
>  
> Apologies for not responding to you earlier earlier.  Since this text was written, we have realized that there are no valid use cases for HTTP, SIP, or XMPP for multiple Origins, and also that the STUN specification says that even if multiples were sent, only the first will be processed.  So we are dropping the MUST that you reference here.  We also plan to change the multiple Origins language in section 2 to say:  
>  
> "Senders SHOULD NOT include multiple ORIGIN attributes in a request since per STUN rules, only the first will be processed and the rest ignored."
>  
> >
> > Nits/editorial comments:
> >
> > idnits 2.13.01 turned up a reference problem:
> >
> >  == Unused Reference: 'RFC7350' is defined on line 490, but no explicit
> >     reference was found in the text
> >
> > That RFC should be cited somewhere.  In addition, there are no RFCs cited
> > or referenced for TLS and DTLS - they should be added (I believe that
> > RFC 5246 and RFC 6347 are appropriate, respectively).
>  
> RFC 7350 is DTLS transport for STUN, so we should reference it in the Security Considerations when we discuss DTLS.
>  
> >
> > Thanks,
> > --David
> > ----------------------------------------------------
> > David L. Black, Distinguished Engineer
> > EMC Corporation, 176 South St., Hopkinton, MA  01748
> > +1 (508) 293-7953             FAX: +1 (508) 293-7786
> > david.black@emc.com        Mobile: +1 (978) 394-7754
> > ----------------------------------------------------
> >
> >
> > _______________________________________________
> > Gen-art mailing list
> > Gen-art@ietf.org
> > https://www.ietf.org/mailman/listinfo/gen-art
>