Shepherd writeup

> 1. Summary
> Who is the document shepherd?

Simon Perreault <>

> Who is the responsible Area Director?

Spencer Dawkins

> Explain briefly what the intent of the document is (the document's
> abstract is usually good for this), and why the working group has
> chosen the requested publication type (BCP, Proposed Standard,
> Internet Standard, Informational, Experimental, or Historic).

This specification defines an ORIGIN attribute for STUN that can be used
in similar ways to the HTTP header field of the same name.  WebRTC
browsers utilizing STUN and TURN would include this attribute which
would provide servers with additional information about the STUN and
TURN requests they receive.

In particular, this draft solves the common problem of running
"multi-tenant" STUN/TURN servers. For example, WebRTC applications
running on different domains with different user databases can use the
same STUN/TURN server when the ORIGIN attribute is supplied by clients.

> 2. Review and Consensus
> Explain how actively the document was reviewed and discussed, by the
> working group and external parties, and explain in a general sense how
> much of the interested community is behind the document. Explain
> anything notable about the discussion of the document.

The draft has been reviewed and discussed by the whole working group.
The WebRTC community demonstrated interest too. This is a pretty
consensual document.

The harder technical issue had to do with the fact that the attribute's
value can grow quite large and could make STUN packets exceed MTU.

Client and server open-source implementations have been made available
("Chromeo" and "Coturn"). This shepherd expects to see more
implementations by the WebRTC community shortly.

> 3. Intellectual Property
> Confirm that each author has stated that their direct, personal
> knowledge of any IPR related to this document has already been
> disclosed, in conformance with BCPs 78 and 79. Explain briefly the
> working group discussion about any IPR disclosures regarding this
> document, and summarize the outcome.


> 4. Other Points
> Note any downward references (see RFC 3967) and whether they appear in
> the DOWNREF Registry
> (, as
> these need to be announced during Last Call.

There are no downrefs.

> Check the IANA Considerations for clarity and against the checklist
> below. Note any registrations that require expert review, and say
> what's been done to have them reviewed before last call. Note any new
> registries that are created by this document and briefly describe the
> working group's discussion that led to the selection of the allocation
> procedures and policies (see RFC 5226) that were selected for them. If
> any new registries require expert review for future allocations,
> provide any public guidance that the IESG would find useful in
> selecting the designated experts (private comments may be sent to the
> Area Director separately).

All checked. A new IANA record requires expert review (Dan Wing).

> Explain anything else that the IESG might need to know when reviewing
> this document. If there is significant discontent with the document or
> the process, which might result in appeals to the IESG or especially
> bad feelings in the working group, explain this in a separate email
> message to the responsible Area Director.

That's all!