On Tue, Apr 21, 2015 at 1:55 AM, Jari Arkko <jari.arkko@xxxxxxxxx> 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@xxxxxxx> 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.
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@xxxxxxx Mobile:
+1 (978) 394-7754
> ----------------------------------------------------
>
>
> _______________________________________________
> Gen-art mailing list
> Gen-art@xxxxxxxx
> https://www.ietf.org/mailman/listinfo/gen-art