Hi,

On 02/16/2016 04:22 PM, Ari Keränen wrote:
Thank you for the review Tom! Please see below.

On 12/02/2016 11:54 PM, Tom Henderson wrote:
Gonzalo and all,

My understanding is that the WG reached consensus several years ago
that the standards-track NAT traversal variant would be the native
NAT traversal and not the RFC5770-based ICE/STUN/TURN version.

I reviewed the above draft and noticed that it still contains
normative references to RFC5770 (pointers to material found only in
RFC5770) throughout, and contains RFC5770 as a normative reference
in Section 8.1.  It seems to me that the WG ought to produce a
specification that can stand alone from RFC5770, because as it
stands now, it seems to me that someone implementing it would need
to consult both drafts and may be uncertain about what is still
applicable from RFC5770.  For example, is the UDP-ENCAPSULATION
mode still valid?

Indeed this variant is the standards-track solution, but I think it
makes sense to not obsolete the RFC5770. For example, in some scenario
the STUN based solution could be better than native HIP based. And also
the UDP-ENCAPSULATION mode should be still valid.

the draft does not replace RFC5770, but offers a parallel/independent way to implement NAT traversal. UDP-ENCAPSULATION mode is still valid.

ICE (RFC 5245) is also still listed as normative but it seems to me
that it should also be informative in this draft.

The details of e.g., how ICE checklists are used are defined in RFC5245
so I think it needs to be normative.

You're right, and new ICE (rfc5245bis) is now normative.

I think it would be appropriate to just reference 5770 in the
Introduction, stating that this specification replaces RFC 5770
with a different mechanism than ICE/STUN/TURN, and then try to
avoid referencing 5770 from then on.

Avoiding RFC 5770 altogether would require lots of editorial work with
this draft for a questionable amount of benefit, so I think it's better
if we simply have it as normative reference. The maturity level of 5770
(experimental) is an issue, but I think it is possible - and makes sense
- to make an exception here.

The draft has been improved radically from the viewpoint of readability and it is more independent from RFC5770. The old draft is somehow more mature in the sense that it has been implemented and successfully interoperated. However, it is based on the old ICE specification that is going to be deprecated this year.

Attachment: smime.p7s
Description: S/MIME Cryptographic Signature

_______________________________________________
Hipsec mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/hipsec

Reply via email to