Subject: [tram] [IANA #806090] RE: Last Call: <draft-ietf-tram-turn-third-party-authz-07.txt> (Session Traversal Utilities for NAT (STUN) Extension for Third Party Authorization) to Proposed Standard

From: "Pearl Liang via RT" <[email-masked]>
Date: Wed, 28 Jan 2015 21:32:17 +0000

On Wed Jan 28 04:51:06 2015, [email-masked] wrote:
> > -----Original Message-----
> > From: Pearl Liang via RT [mailto:[email-masked]]
> > Sent: Wednesday, January 28, 2015 5:07 AM
> > Cc: [email-masked]; tram-
> > [email-masked]; [email-masked]
> > Subject: [IANA #804968] Last Call: <draft-ietf-tram-turn-third-party-
> > authz-
> > 07.txt> (Session Traversal Utilities for NAT (STUN) Extension for
> > Third Party
> > Authorization) to Proposed Standard
> >
> > (BEGIN IANA LAST CALL COMMENTS)
> >
> > IESG/Authors/WG Chairs:
> >
> > IANA has reviewed draft-ietf-tram-turn-third-party-authz-07  Authors
> > should
> > review the comments and/or questions below.  Please report any
> > inaccuracies and respond to any questions as soon as possible.
> >
> > IANA has questions about some of the IANA actions requested in the
> > IANA
> > Considerations section of this document.
> >
> > We received the following comments/questions from the IANA's
> > reviewer:
> >
> > IANA understands that, upon approval of this document, there is a
> > single
> > action which IANA must complete.
> >
> > In the STUN Attributes subregistry of the Session Traversal Utilities
> > for NAT
> > (STUN) Parameters registry located at:
> >
> > http://www.iana.org/assignments/stun-parameters/
> >
> > two new STUN attributes are to be registered as follows:
> >
> > Value: [ TBD-at-registration ]
> > Name: THIRD-PARTY-AUTHORIZATION
> > Reference: [ RFC-to-be ]
> >
> > Value: [ TBD-at-registration ]
> > Name: ACCESS-TOKEN
> > Reference: [ RFC-to-be ]
> >
> > Question: which range or ranges in the STUN Attributes registry the
> > above
> > two new
> > attributes should be registered?   The registry defines the following
> > ranges:
> >
> > Range         Registration Procedures         Note
> > 0x0000-0x3FFF IETF Review     comprehension-required range
> > 0x4000-0x7FFF Designated Expert       comprehension-required range
> > 0x8000-0xBFFF IETF Review     comprehension-optional range
> > 0xC000-0xFFFF Designated Expert       comprehension-optional range
> >
> > It appears that section 6 defines the new attributes to be in two
> > different
> > ranges, comprehension-optional and comprehension-required.  Is that
> >   correct?
> 
> Yes.
> 
> > If so, please either add the ranges in the IC section or add a
> > pointer
> > to section 6 in the IC section.
> 
> NEW (IC section):
> 
> [Paragraphs below in braces should be removed by the RFC Editor upon
> publication]
> 
> [The THIRD-PARTY-AUTHORIZATION attribute requires that IANA allocate a
> value in
> the "STUN attributes Registry" from the comprehension-optional range
> (0x8000-0xFFFF)]
> 

As described above, the range 0x8000-0xFFFF has two different registration rules 
as defined by RFC5389.  Which one of the following the new STUN attribute
should be registered:

0x8000-0xBFFF	IETF Review	comprehension-optional range
0xC000-0xFFFF	Designated Expert	comprehension-optional range

?

Should it be in 0x8000-0xBFFF?  

Thanks,
~pl

> This document defines the THIRD-PARTY-AUTHORIZATION STUN attribute,
> described
> in Section 6.  IANA has allocated the comprehension-optional
> codepoint TBD for this attribute.
> 
> [The ACCESS-TOKEN attribute requires that IANA allocate a value
> in the "STUN attributes Registry" from the comprehension-required
> range (0x0000-0x3FFF)]
> 
> This document defines the ACCESS-TOKEN STUN attribute, described
> in Section 6.  IANA has allocated the comprehension-required
> codepoint TBD for this attribute.
> 
> -Tiru
> 
> >
> > Further, if a new attribute is in the comprehension-optional range,
> > the
> > authors need to define which of the comprehension-optional ranges,
> > 0x8000-0xBFFF or 0xC000-0xFFFF, the new attribute should be
> > registered.
> > So, if the authors pick "0x8000-0xBFFF" of the comprehension-optional
> > range, IETF Review registration rule will be used.  The IC section
> > has no clear
> > texts about these.
> >
> >
> > IANA understands that this is the only action that needs to be
> > completed
> > upon approval of this document.
> >
> > Note:  The actions requested in this document will not be completed
> > until the
> > document has been approved for publication as an RFC. This message is
> > only
> > to confirm what actions will be performed.
> >
> >
> > Thanks,
> >
> > Pearl Liang
> > ICANN
> >
> > (END IANA LAST CALL COMMENTS)
> >
> > On Wed Jan 21 20:03:33 2015, [email-masked] wrote:
> > >
> > > The IESG has received a request from the TURN Revised and
> > > Modernized
> > > WG
> > > (tram) to consider the following document:
> > > - 'Session Traversal Utilities for NAT (STUN) Extension for Third
> > > Party
> > >    Authorization'
> > >   <draft-ietf-tram-turn-third-party-authz-07.txt> as Proposed
> > > Standard
> > >
> > > The IESG plans to make a decision in the next few weeks, and
> > > solicits
> > > final comments on this action. Please send substantive comments to
> > > the
> > > [email-masked] mailing lists by 2015-02-04. Exceptionally, comments
> > > may
> > > be
> > > sent to [email-masked] instead. In either case, please retain the
> > > beginning of the Subject line to allow automated sorting.
> > >
> > > Abstract
> > >
> > >
> > > This document proposes the use of OAuth to obtain and validate
> > > ephemeral tokens that can be used for Session Traversal Utilities
> > > for
> > > NAT (STUN) authentication.  The usage of ephemeral tokens ensure
> > > that
> > > access to a STUN server can be controlled even if the tokens are
> > > compromised.
> > >
> > >
> > >
> > >
> > > The file can be obtained via
> > > http://datatracker.ietf.org/doc/draft-ietf-tram-turn-third-party-
> > > authz/
> > >
> > > IESG discussion can be tracked via
> > > http://datatracker.ietf.org/doc/draft-ietf-tram-turn-third-party-
> > > authz/ballot/
> > >
> > >
> > > No IPR declarations have been submitted directly on this I-D.
>

---

From: "Pearl Liang via RT" <[email-masked]>
Date: Thu, 29 Jan 2015 03:30:49 +0000

On Thu Jan 29 02:39:56 2015, [email-masked] wrote:
> > From: Pearl Liang via RT [mailto:[email-masked]]
> > Sent: Thursday, January 29, 2015 3:02 AM
> > Cc: [email-masked]; draft-ietf-tram-turn-third-party-
> > [email-masked];
> > [email-masked]; [email-masked]; [email-masked]
> > Subject: [IANA #806090] RE: Last Call: <draft-ietf-tram-turn-third-
> > party-authz-
> > > > should review the comments and/or questions below.  Please report
> > > > any inaccuracies and respond to any questions as soon as
> > > > possible.
> > > >
> > > > IANA Considerations section of this document.
> > > >
> > > > single action which IANA must complete.
> > > >
> > > > In the STUN Attributes subregistry of the Session Traversal
> > > > Utilities for NAT
> > > > above two new
> > > > different ranges, comprehension-optional and comprehension-
> > > > required.
> > > > Is that
> > > >   correct?
> > >
> > > Yes.
> > >
> > > > pointer to section 6 in the IC section.
> > >
> > > NEW (IC section):
> > >
> > > value in the "STUN attributes Registry" from the
> > > comprehension-optional range (0x8000-0xFFFF)]
> > >
> >
> > As described above, the range 0x8000-0xFFFF has two different
> > registration
> > rules as defined by RFC5389.  Which one of the following the new STUN
> > attribute should be registered:
> >
> Yes, updated IC section and published revision to address the comment.
> 

Great.  Then IETF Review applies.  Please update the IC section in the next version
to include the texts we discussed.

Thanks,
~pl

> > > described in Section 6.  IANA has allocated the comprehension-
> > > optional
> > > [The ACCESS-TOKEN attribute requires that IANA allocate a value in
> > > the
> > > "STUN attributes Registry" from the comprehension-required range
> > > (0x0000-0x3FFF)]
> > >
> > > This document defines the ACCESS-TOKEN STUN attribute, described in
> > > Section 6.  IANA has allocated the comprehension-required codepoint
> > > TBD for this attribute.
> > >
> > > -Tiru
> > >
> > > >
> > > > the authors need to define which of the comprehension-optional
> > > > ranges, 0x8000-0xBFFF or 0xC000-0xFFFF, the new attribute should
> > > > be
> > > > registered.
> > > > So, if the authors pick "0x8000-0xBFFF" of the
> > > > comprehension-optional range, IETF Review registration rule will
> > > > be
> > > > used.  The IC section has no clear texts about these.
> > > >
> > > >
> > > > completed upon approval of this document.
> > > >
> > > > until the document has been approved for publication as an RFC.
> > > > This
> > > > message is only to confirm what actions will be performed.
> > > >
> > > >
> > > > Thanks,
> > > >
> > > > Pearl Liang
> > > > ICANN
> > > >
> > > > > Modernized WG
> > > > > solicits final comments on this action. Please send substantive
> > > > > comments to the [email-masked] mailing lists by 2015-02-04.
> > > > > Exceptionally, comments may be sent to [email-masked] instead.
> > > > > In
> > > > > either case, please retain the beginning of the Subject line to
> > > > > allow automated sorting.
> > > > >
> > > > > Abstract
> > > > >
> > > > >
> > > > > for NAT (STUN) authentication.  The usage of ephemeral tokens
> > > > > ensure that access to a STUN server can be controlled even if
> > > > > the
> > > > > tokens are compromised.
> > > > >
> > > > >
> > > > >
> > > > >

---

From: "Pearl Liang via RT" <[email-masked]>
Date: Fri, 30 Jan 2015 17:02:30 +0000

On Thu Jan 29 05:01:50 2015, [email-masked] wrote:
> > Sent: Thursday, January 29, 2015 9:01 AM
> > Cc: Tirumaleswar Reddy (tireddy); [email-masked]; draft-ietf-tram-
> > turn-third-
> > [email-masked]; [email-masked]; tram-
> > [email-masked];
> > [email-masked]
> > > > [email-masked]; [email-masked]; [email-masked];
> > > > [email-masked]
> > > > > > 07.txt> (Session Traversal Utilities for NAT (STUN) Extension
> > > > > > for Third Party
> > > > > > should review the comments and/or questions below.  Please
> > > > > > report any inaccuracies and respond to any questions as soon
> > > > > > as
> > > > > > possible.
> > > > > >
> > > > > > IANA has questions about some of the IANA actions requested
> > > > > > in
> > > > > > the IANA Considerations section of this document.
> > > > > >
> > > > > > IANA understands that, upon approval of this document, there
> > > > > > is
> > > > > > a single action which IANA must complete.
> > > > > >
> > > > > > Question: which range or ranges in the STUN Attributes
> > > > > > registry
> > > > > > the above two new
> > > > > > It appears that section 6 defines the new attributes to be in
> > > > > > two different ranges, comprehension-optional and
> > > > > > comprehension-
> > > > > > required.
> > > > > > Is that
> > > > > >   correct?
> > > > >
> > > > > Yes.
> > > > >
> > > > > [Paragraphs below in braces should be removed by the RFC Editor
> > > > > upon publication]
> > > > >
> > > > > [The THIRD-PARTY-AUTHORIZATION attribute requires that IANA
> > > > > allocate a value in the "STUN attributes Registry" from the
> > Great.  Then IETF Review applies.  Please update the IC section in
> > the next
> > version
> Revision https://tools.ietf.org/html/draft-ietf-tram-turn-third-party-
> authz-08 includes the text discussed.
> 

This version looks okay.

Thanks,
~pl

> Cheers,
> > > > > in