Hi, On 06/30/2016 08:44 AM, Tom Henderson wrote:
Hi Miika,trying to recap your complete opinion... do you think the UDP-ENCAPSULATION should be MUST and ICE-HIP-UDP SHOULD? And RFC5770 MAY? Or do you think the draft should just deprecate RFC5770?I think that UDP-ENCAPSULATION should be a MUST option because that option is sufficient if the implementation does not have to deal with inbound connections.
Ok. Btw, you mean "Responder" by inbound? I think you're referring to this section:
https://tools.ietf.org/html/draft-ietf-hip-native-nat-traversal-12#section-4.7.2
ICE-HIP-UDP should be a MUST for implementations that wish to support inbound, and I don't think that RFC5770 solutions for inbound should be suggested as options.
Added the following to the NAT Traversal Mode Parameter" section: "Implementations conforming to this specification MUST implement both UDP-ENCAPSULATION and ICE-HIP-UDP modes."
Maybe the use of STUN servers for candidate gathering is fine as a MAY since it doesn't affect HIP interoperability, but otherwise, why suggest to support two parallel implementations for the same function?
A host behind a NAT will need a HIP relay anyway which can provide STUN functionality. The draft currently says:
Gathering of candidates MAY also be performed as specified in Section 4.2 of [RFC5770] if STUN servers are available, or if the host has just a single interface and no TURN or HIP data relay servers are available. Do you want this to be removed or is it ok?
I would be fine with making an allowance for RFC5770 implementations to live on as an option; by this I mean to not overwrite RFC5770 codepoints, etc. but stop short of suggesting it as a MAY in this document.
The draft does not reference RFC5770 as MAY implement. The current draft is completely a parallel to the RFC, and is described in a self-sufficient way.
Btw, RFC5770 is still a normative reference because we are redundantly explaining some parts of the RFC in the draft.I still believe that it would be better if this draft did not depend on reading RFC5770.
It doesn't anymore. RFC5770 is mostly referenced because some parameters are borrowed from there, but are always redundantly described in the draft.
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ Hipsec mailing list [email protected] https://www.ietf.org/mailman/listinfo/hipsec
