Hi, I am no longer an area director. I leave it to the current area directors to decide how to proceed with the updated version.
Thanks, Ben. > On Feb 19, 2020, at 2:43 PM, Miika Komu <[email protected]> wrote: > > Hi Ben, > > thanks for your comments! My response below. > > ke, 2018-05-09 kello 19:05 -0700, Ben Campbell kirjoitti: >> Ben Campbell has entered the following ballot position for >> draft-ietf-hip-native-nat-traversal-28: Abstain >> >> When responding, please keep the subject line intact and reply to all >> email addresses included in the To and CC lines. (Feel free to cut >> this >> introductory paragraph, however.) >> >> >> Please refer to >> https://www.ietf.org/iesg/statement/discuss-criteria.html >> for more information about IESG DISCUSS and COMMENT positions. >> >> >> The document, along with other ballot positions, can be found here: >> https://datatracker.ietf.org/doc/draft-ietf-hip-native-nat-traversal/ >> >> >> >> ------------------------------------------------------------------- >> --- >> COMMENT: >> ------------------------------------------------------------------- >> --- >> >> I support all points of Ekr's discuss and comment points. I think >> this either >> needs to use ICE mostly as is (maybe with some minor profiling) or it >> needs to >> be self-contained here. I understand the material in appendix B, but >> the >> current mix seems untenable for implementors. Therefore I am >> balloting >> "abstain". I will reconsider that position if there is a substantial >> reorganization. > > the current document has been organized for implementors of RFC5770 in > mind. > >> Substantive Comments: >> >> I share Alissa's question about why this is standard track when the >> previous >> work has been experimental. > > HIP WG decided to move all of its experimental work to standards track. > >> §1, second paragraph: The citation for the version of ICE used by >> "legacy >> ICE-HIP" should be RFC5245, not the bis version. > > thanks, corrected. > >> §2: There are a number of lower-case keywords. Please use the RFC >> 8174 >> boilerplate. > > boilerplate added. Please comment some specific lower-case keyword is > incorrect in your opinion. > >> §4.2: >> - paragraph 5: Is everything in this paragraph from the ICE >> specification? I >> suspect not, but it's hard to tease out what is from ICE and what is >> new >> specification. It would be helpful to reference the ICE bits by >> section number. > > it is either adapted from ICE (by e.g. changing "agent" to "host" or > referencing the ICE spec (by sections). Based on the earlier reviews, > the text has evolved now into the following: > > The rules in section 5.1.1 in [RFC8445] for candidate gathering > are followed here. A number of host candidates (loopback, anycast > and others) should be excluded as described in section 5.1.1.1 of the > ICE specification [RFC8445]. Relayed candidates SHOULD be gathered > in order to guarantee successful NAT traversal, and > implementations SHOULD support this functionality even if it will not > be used in deployments in order to enable it by software > configuration update if needed at some point. Similarly as explained > in section 5.1.1.2 of the ICE specification [RFC8445], if an IPv6- > only host is in a network that utilizes NAT64 [RFC6146] and DNS64 > [RFC6147] technologies, it may also gather IPv4 server- reflexive > and/or relayed candidates from IPv4-only Control or Data Relay > Servers. IPv6-only hosts SHOULD also utilize IPv6 prefix discovery > [RFC7050] to discover the IPv6 prefix used by NAT64 (if any) and > generate server-reflexive candidates for each IPv6-only interface, > accordingly. The NAT64 server-reflexive candidates are prioritized > like IPv4 server-reflexive candidates. > >> - paragraph 6: I'm confused in that I thought the previous text said >> that >> native ICE-HIP does not use STUN. > > you mean paragraph 7? > > Gathering of candidates MAY also be performed by other means than > described in this section. For example, the candidates could be > gathered as specified in Section 4.2 of [RFC5770] if STUN servers > are available, or if the host has just a single interface and no > STUN or Data Relay Server are available. > > Nothing prevents an implementation from gathering candidates via STUN > but the recommended way is HIP control Relay as the "MAY" indicates > here. > >> §6: I am skeptical of the assertion that the security considerations >> for Native >> ICE-HIP are no different than those for Legacy ICE-HIP. > > I have changed this now to a more precise statement: > > Since the control plane protocol and Control Relay Server are > essentially the same (with some minor differences) in this document > as in Legacy ICE-HIP [RFC5770], the same security considerations (in > Section 6.1, Section 6.2, Section 6.3 and Section 6.4,) are still > valid, but are repeated here for the sake of completeness. New > security considerations related to the new Data Relay Server are > discussed in Section 6.5, and considerations related to the new > connectivity check protocol are discussed in Section 6.6 and > Section 6.7 . > >> Editorial Comments: >> >> §1, 2nd paragraph: >> - "responsible of NAT traversal": s/of/to >> - "responsible of end-host": s/of/to > > I changed to "for", I assume that would do the trick as well > >> §4.3: "This section describes the usage of a new non-critical >> parameter type. >> ": Which is? > > It says now: > > This section describes the usage of a non-critical parameter type > called NAT_TRAVERSAL_MODE with a new mode called ICE-HIP-UDP. > >> §4.6, first paragraph: 2nd sentence is hard to parse. > > I reworded this as follows: > > The address of the Control Relay Server MUST NOT be used as a > destination for data plane traffic unless the server supports also Data > Relay Server functionality, and the Client has successfully registered > to use it.
signature.asc
Description: Message signed with OpenPGP
_______________________________________________ Hipsec mailing list [email protected] https://www.ietf.org/mailman/listinfo/hipsec
