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.
