Skip to main content

Shepherd writeup
draft-ietf-tram-alpn

> 1. Summary
> 
> Who is the document shepherd?

Simon Perreault <sperreault@jive.com>

> 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 document defines two APLN labels for two usages of STUN over (D)TLS: NAT
discovery and TURN.

> 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 was initially thought to be a "slam dunk" but the working group ended
up arguing over the granularity of ALPN labels: did we need just one label for
all of STUN or one label for each STUN usage? Once the WG selected the second
option, it argued over the necessity of a generic "STUN" label for future and
unknown usages, rejecting that idea in the end.

Many TRAM regulars participated in the discussion. Martin Thompson in particular
provided much (D)TLS and ALPN expertise. The consensus is solid and represents
the whole working group.

No specific implementation was mentioned on the list, but this shepherd expects
that WebRTC stacks and TURN servers will implement this draft quickly.

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

Confirmed.

> 4. Other Points
> 
> Note any downward references (see RFC 3967) and whether they appear in the
> DOWNREF Registry
> (http://trac.tools.ietf.org/group/iesg/trac/wiki/DownrefRegistry), as these
> need to be announced during Last Call.

There are no downward references.

> Check the IANA Considerations for clarity and against the checklist below.

Checked. No problem identified.

> Note any registrations that require expert review, and say what's been done to
> have them reviewed before last call.

There are two additions to the "Application Layer Protocol Negotiation (ALPN) 
Protocol IDs" registry, which is Expert Review Required. They have not been 
sent to the designated expert reviewer yet, but can be handled during normal IANA 
Evaluation.

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

This document does not create any new IANA registry.

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