[tram] Review of draft-ietf-tram-turnbis-13.txt (was Re: I-D Action: draft-ietf-tram-turnbis-12.txt)

Hi Tiru,

Most of my comments have been addressed with this update.

There are still a few issues raised by idnits, two of which are errors.

== start idnits ===

   Checking nits according to https://www.ietf.org/id-info/checklist :

----------------------------------------------------------------------------

   ** The abstract seems to contain references ([RFC6156], [RFC5766]),
      which it shouldn't.  Please replace those with straight textual
      mentions of the documents in question.

   -- The document has examples using IPv4 documentation addresses
      according to RFC6890, but does not use any IPv6 documentation
      addresses.  Maybe there should be IPv6 examples, too?

   -- The draft header indicates that this document obsoletes RFC6156,
      but th abstract doesn't seem to directly say this.  It does mention
      RFC6156 though, so this could be OK.

   Checking references for intended status: Proposed Standard

----------------------------------------------------------------------------

      (See RFCs 3967 and 4897 for information about using normative
      references to lower-maturity documents in RFCs)

   == Missing Reference: '0x4001' is mentioned on line 662, but not
      defined

   ** Obsolete normative reference: RFC 6555 (Obsoleted by RFC 8305)

== end idnits ===

Based on the above.

* The RFC mentions in the abstract should not be links. Please remove
   the xref tags and replace with simple textual references. From the
   look of stunbis, which doesn't use xref tags, the HTML doc system
   appears to turn them into hyperlinks anyway, which is weird.
   Nevertheless, doing it the way you did generates an error from idnits
   and errors should really be corrected.

* I think the point about IPv6 documentation addresses is just because
   something about the formatting is causing it not to matching against
   the small number of them in section 19.4. That said, IPv6
   documentation addresses are in the range 2001:DB8::/32, you have a
   couple 2001:DB9::/32 addresses that should be changed I think.

* There is still one instance of [0x4001] which can be replaced with
   (0x4001).

* Replace the informative reference to RFC6555 with a reference to
   RFC8305.

The rest of my comments are just a small number of follow-ups on other 
items that weren't fixed from my previous comments.

* My earlier comment suggested added an explanation of why EVEN-PORT is
   not allowed with ADDITIONAL-ADDRESS-FAMILY to section 4. Your response
   was that this should not be moved to section 4. My primary point was
   that the related section (now 7.1) doesn't explain the reason for this
   restriction. Whether in section 4 or section 7.1, I do still think it
   would be good to state why EVEN-PORT MUST NOT be combined with
   ADDITIONAL-ADDRESS-FAMILY.

* I'm still confused about the 5-tuple uniqueness requirement. The old
   text stated that "... the 5-tuple MUST be unique across all
   allocations, ..." In your response, you state "With the dual
   allocation, the 5-tuple no longer unqiuely identifies an allocation."
   and also "5-tuple will either identify a single or dual allocation."
   These two statements appear to contradict each other. I believe that a
   5-tuple MUST be unique across all allocations, where an allocation in
   this context could be either a single or dual allocation.

* Regarding this text in section 16.6: "The REQUESTED-ADDRESS-TYPE
   attribute MAY only be present in Allocate requests." Although this
   text was copied directly from RFC6156, it was already incorrect there
   (it's REQUESTED-ADDRESS-FAMILY and I think it intends "SHALL" or
   "MUST", not "MAY"). That said, this I-D changes the usage such that
   this attribute is now allowed in a Refresh request. Considering that
   the only usages for this attribute are clearly described above, I
   think it's OK to just remove the sentence altogether. Perhaps the
   first sentence in this section could be changed to further clarify:

     This attribute is used in Allocate and Refresh requests to specify
     the address type requested by the client.

* Regarding this text in section 16.12: "The ADDRESS-ERROR-CODE
   attribute MAY only be present in Allocate responses." See my previous
   comment about "MAY" vs "SHALL"/"MUST". I still don't think this
   normative text is required in an attribute description. Most of the
   others don't have it.

Pleae let me know if you have any questions about the above, and also
when you will be able to target addressing the remaining open items.

Thanks,
--Brandon

On 02/09/2018 02:44 AM, Konda, Tirumaleswar Reddy wrote:
> Hi Brandon,
> 
> Thanks for the detailed review. I have updated the draft to address most of the comments, please see the attached doc for responses to some of comments and nits.
> 
> Cheers,
> -Tiru
> 
>> -----Original Message-----
>> From: Brandon Williams [mailto:brandon.williams@akamai.com]
>> Sent: Sunday, November 12, 2017 11:34 PM
>> To: Konda, Tirumaleswar Reddy
>> <TirumaleswarReddy_Konda@McAfee.com>; tram@ietf.org
>> Cc: draft-ietf-tram-turnbis@ietf.org
>> Subject: Re: [tram] I-D Action: draft-ietf-tram-turnbis-12.txt
>>
>> Hi Tiru,
>>
>> I just finished a comprehensive review of the cumulative diffs against
>> RFC5766. See attached (let me know if you prefer me to resend as e-mail
>> body for list purposes).
>>
>> You indicate that you addressed Marc's dual allocation related comments,
>> but this draft doesn't address his comprehensive review comments, right?
>>
>> Please let me know a target for addressing the rest of his comments and
>> mine so I can try to stay on top of the shepherding work for the draft.
>>
>> Thanks,
>> --Brandon
>> ________________________________________
>> From: Konda, Tirumaleswar Reddy
>> <TirumaleswarReddy_Konda@McAfee.com>
>> Sent: Monday, October 23, 2017 2:48 AM
>> To: tram@ietf.org
>> Subject: Re: [tram] I-D Action: draft-ietf-tram-turnbis-12.txt
>>
>> This revision addresses comments from Brandon and dual allocation related
>> comments from Mark.
>>
>> -Tiru
>>
>>> -----Original Message-----
>>> From: tram [mailto:tram-bounces@ietf.org] On Behalf Of internet-
>>> drafts@ietf.org
>>> Sent: Monday, October 23, 2017 12:14 PM
>>> To: i-d-announce@ietf.org
>>> Cc: tram@ietf.org
>>> Subject: [tram] I-D Action: draft-ietf-tram-turnbis-12.txt
>>>
>>>
>>> A New Internet-Draft is available from the on-line Internet-Drafts
>> directories.
>>> This draft is a work item of the TURN Revised and Modernized WG of the
>>> IETF.
>>>
>>>          Title           : Traversal Using Relays around NAT (TURN): Relay Extensions
>>> to Session Traversal Utilities for NAT (STUN)
>>>          Authors         : Tirumaleswar Reddy
>>>                            Alan Johnston
>>>                            Philip Matthews
>>>                            Jonathan Rosenberg
>>>        Filename        : draft-ietf-tram-turnbis-12.txt
>>>        Pages           : 83
>>>        Date            : 2017-10-22
>>>
>>> Abstract:
>>>     If a host is located behind a NAT, then in certain situations it can
>>>     be impossible for that host to communicate directly with other hosts
>>>     (peers).  In these situations, it is necessary for the host to use
>>>     the services of an intermediate node that acts as a communication
>>>     relay.  This specification defines a protocol, called TURN (Traversal
>>>     Using Relays around NAT), that allows the host to control the
>>>     operation of the relay and to exchange packets with its peers using
>>>     the relay.  TURN differs from some other relay control protocols in
>>>     that it allows a client to communicate with multiple peers using a
>>>     single relay address.
>>>
>>>     The TURN protocol was designed to be used as part of the ICE
>>>     (Interactive Connectivity Establishment) approach to NAT traversal,
>>>     though it also can be used without ICE.
>>>
>>>     This document obsoletes [RFC5766] and [RFC6156].
>>>
>>>
>>> The IETF datatracker status page for this draft is:
>>> https://datatracker.ietf.org/doc/draft-ietf-tram-turnbis/
>>>
>>> There are also htmlized versions available at:
>>> https://tools.ietf.org/html/draft-ietf-tram-turnbis-12
>>> https://datatracker.ietf.org/doc/html/draft-ietf-tram-turnbis-12
>>>
>>> A diff from the previous version is available at:
>>> https://www.ietf.org/rfcdiff?url2=draft-ietf-tram-turnbis-12
>>>
>>>
>>> Please note that it may take a couple of minutes from the time of
>>> submission until the htmlized version and diff are available at tools.ietf.org.
>>>
>>> Internet-Drafts are also available by anonymous FTP at:
>>> ftp://ftp.ietf.org/internet-drafts/
>>>
>>> _______________________________________________
>>> tram mailing list
>>> tram@ietf.org
>>> https://www.ietf.org/mailman/listinfo/tram
>>
>> _______________________________________________
>> tram mailing list
>> tram@ietf.org
>> https://www.ietf.org/mailman/listinfo/tram
>>
>>
>> --
>> Brandon Williams; Chief Architect
>> Cloud Networking; Akamai Technologies Inc.
>>
>>
>> _______________________________________________
>> tram mailing list
>> tram@ietf.org
>> https://www.ietf.org/mailman/listinfo/tram