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

[Marc Petit-Huguenin <[e-mail]>]

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.