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

["Konda, Tirumaleswar Reddy" <[e-mail]>]

> -----Original Message-----
> From: Brandon Williams [mailto:[e-mail]]
> Sent: Thursday, February 22, 2018 1:51 AM
> To: Konda, Tirumaleswar Reddy
> <[e-mail]>; [e-mail]
> Cc: [e-mail]
> Subject: Review of draft-ietf-tram-turnbis-13.txt (was Re: [tram] 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.

Fixed. 

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

Updated 2001:DB9::1 to 2001:DB8:1::1


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

Fixed. 

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

Done. 

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

If EVEN-PORT with R bit set to 1 is allowed, the handling of RESERVATION-TOKEN needs to be changed (two tokens have to 
be returned in the success response). 

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

Agreed, updated text.
NEW:
Both the relayed transport address and the 5-tuple MUST be unique across all allocations, so either one can be used to uniquely identify the allocation, 
and an allocation in this context can either be 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. 

Agreed, removed line.

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

Updated the first line.

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

Removed line.

Cheers,
-Tiru

> 
> 
> 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:[e-mail]]
> >> Sent: Sunday, November 12, 2017 11:34 PM
> >> To: Konda, Tirumaleswar Reddy
> >> <[e-mail]>; [e-mail]
> >> Cc: [e-mail]
> >> 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
> >> <[e-mail]>
> >> Sent: Monday, October 23, 2017 2:48 AM
> >> To: [e-mail]
> >> 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:[e-mail]] On Behalf Of internet-
> >>> [e-mail]
> >>> Sent: Monday, October 23, 2017 12:14 PM
> >>> To: [e-mail]
> >>> Cc: [e-mail]
> >>> 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
> >>> [e-mail]
> >>> https://www.ietf.org/mailman/listinfo/tram
> >>
> >> _______________________________________________
> >> tram mailing list
> >> [e-mail]
> >> https://www.ietf.org/mailman/listinfo/tram
> >>
> >>
> >> --
> >> Brandon Williams; Chief Architect
> >> Cloud Networking; Akamai Technologies Inc.
> >>
> >>
> >> _______________________________________________
> >> tram mailing list
> >> [e-mail]
> >> https://www.ietf.org/mailman/listinfo/tram