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

Hi Jari,

Yes, we will make these changes in our next rev.

- Alan -

On Wed, May 13, 2015 at 4:58 AM, Jari Arkko <jari.arkko@piuha.net> wrote:

> 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
> >
>
>