Subject: Re: [Gen-art] [tram] Genart telechat review of draft-ietf-tram-stunbis-16

From: Marc Petit-Huguenin <[email-masked]>
Date: Thu, 3 May 2018 16:32:30 -0700

On 04/16/2018 02:49 PM, Marc Petit-Huguenin wrote:
> Thanks again for the review.  Comments inline.
> 
> On 03/30/2018 04:45 AM, Dale Worley wrote:
>> Reviewer: Dale Worley
>> Review result: Ready with Nits
>>
>> I am the assigned Gen-ART reviewer for this draft.  The General Area
>> Review Team (Gen-ART) reviews all IETF documents being processed by
>> the IESG for the IETF Chair.  Please wait for direction from your
>> document shepherd or AD before posting a new version of the draft.
>>
>> For more information, please see the FAQ at
>> <https://wiki.tools.ietf.org/area/gen/wiki/GenArtfaq>.
>>
>> Document:  draft-ietf-tram-stunbis-16
>> Reviewer:  Dale R. Worley
>> Review Date:  2018-03-29
>> IETF LC End Date:  2018-02-20
>> IESG Telechat date:  2018-04-19
>>
>> Summary:
>>
>>        This draft is basically ready for publication, but has nits
>>        that should be fixed before publication.
>>
>> The only interesting item concerns section 17.1, where the assignment
>> of meanings to bits in the "security feature set" value is different
>> from the assignment in -16.  This is either non-upward-compatible with
>> -16, or there is an error in either -16 or -17.
>>
>> ----------------------------------------------------------------------
>>
>> There is an issue that shows up in several places:  The NAT may
>> forward the request using an IP family that is different from the IP
>> family that it received the request using.  This means that the
>> "source IP family of the request" may depend on whether one is
>> speaking of the client or the server.  The draft is cognizant of this,
>> and mentions its consequences in sections 6.3.3 and 12.  But this also
>> has consequences for ALTERNATE-SERVER:  Section 14.15 says "The IP
>> address family MUST be identical to that of the source IP address of
>> the request." even though that family might not be usable by the
>> client.  The draft doesn't seem to explicitly say that this comes from
>> address-switching by the NAT.  It would help if there was a
>> higher-level discussion of this matter, pointing to the various
>> consequences.
> 
> I still do not have text about that but, as this is blocking this response since 2 weeks now, I am releasing it as is and will come back to that after I process the other reviews that accumulated during my time traveling around Europe.
> 

Because we believe that this is a problem that will become more and more frequent, we decided to fix it, at least for new implementations.

Please have a look at -17 and let us know what you think of it.

Thanks.

---

From: [email-masked] (Dale R. Worley)
Date: Thu, 03 May 2018 21:32:35 -0400

Marc Petit-Huguenin <[email-masked]> writes:
> Because we believe that this is a problem that will become more and
> more frequent, we decided to fix it, at least for new implementations.
>

It looks like you've handled the problem of a NAT that changes the
address family of the request as well as can be done.

You've clarified the question of how the security feature bits are
assigned, although I note that -16 and -17 assign the bits differently
than versions -7 through -15 do.

That completes all of the significant issues from my review of -16.

And there are some nits:

6.2.1.  Sending over UDP or DTLS-over-UDP

   SHOULD be greater or equal than 500 ms.

s/equal than/equal to/.

6.2.3.  Sending over TLS-over-TCP or DTLS-over-UDP

   To do that, it follows the
   identification procedures defined in [RFC6125], with a certificate
   containing an identifier of type DNS-ID or CN-ID, eventually with
   wildcards, but not of type SRV-ID or URI-ID.

The meaning of "eventually" here is not clear.

14.  STUN Attributes

   The
   padding bits MUST be set to zero on sending and must be ignored by
   the receiver.

I assume the latter "must" is supposed to be "MUST".

14.13.  UNKNOWN-ATTRIBUTES

   Note:  In [RFC3489], this field was padded to 32 by duplicating the
      last attribute.  In this version of the specification, thPetriNet
      m --> PetriNet m --> e normal padding rules for attributes are
      used instead.

I assume that "thPetriNet m --> PetriNet m --> e" is intended to be
"the".

Appendix C.  Release notes

Section C.8 has the same contents as section C.9, but section C.9 has
the same title as section C.10.  (Although section C will be removed
before publication, so it's not important.)

Dale

---

From: Marc Petit-Huguenin <[email-masked]>
Date: Mon, 14 May 2018 13:23:22 -0700

Thank you.  See inline.

>    SHOULD be greater or equal than 500 ms.

Applied.

> The meaning of "eventually" here is not clear.

Rephrased as:

   [...]
   containing an identifier of type DNS-ID or CN-ID, eventually with a
   wildcard character as leftmost label, but not of type SRV-ID or URI-
   [...]

> I assume the latter "must" is supposed to be "MUST".

Fixed.

> I assume that "thPetriNet m --> PetriNet m --> e" is intended to be

Fixed.

> before publication, so it's not important.)

Fixed.

-- 
Marc Petit-Huguenin
Email: [email-masked]
Blog: https://marc.petit-huguenin.org
Profile: https://www.linkedin.com/in/petithug

---

From: [email-masked] (Dale R. Worley)
Date: Mon, 14 May 2018 22:18:00 -0400

>    wildcard character as leftmost label, but not of type SRV-ID or URI-

I have some doubt about the use of "eventually" here.  As I use it,
"eventually" means that the thing will happen at some unspecified time
in the future.  Wiktionary gives this meaning also.  But I looked
"eventually" up in my paper dictionary, and it also has the meaning
"dependent on circumstance; contingent".

In this context, I do not see how the meaning about unspecified future
time works.  But perhaps you mean that having a wildcard character as
leftmost label is contingent?  That meaning works.  But in that case, I
would find "optionally" to be clearer.  (And Google Translate says that
"éventuellement" can be translated into English as either "eventually"
or "optionally", although it provides "facultativement" as the first
translation into French of "optionally".)

You may wish to consult the RFC Editor about this.

Dale

---

From: Marc Petit-Huguenin <[email-masked]>
Date: Tue, 15 May 2018 03:13:45 -0700

> You may wish to consult the RFC Editor about this.

No, you are right, I was using "eventually" incorrectly all this time.  I changed "eventually" to "optionally" in my copy.

Thanks.

---

From: Marc Petit-Huguenin <[email-masked]>
Date: Mon, 14 May 2018 13:23:22 -0700

Thank you.  See inline.

Applied.

Rephrased as:

   [...]

Fixed.

Fixed.

Fixed.