I would like to note for the record that I do not find the arguments in the applicability statement at all persuasive. They are principally about performance but ICE occurs at setup time (so CPU performance is not much of an issue) and is inherently so, with pacing and RTT the dominant factors (and so the system architecture issues are unpersuasive). As I am no longer an AD, this is just opinion, but were I the AD, I would insist on a strong rationale.
-Ekr On Fri, Feb 21, 2020 at 4:35 AM Eric Vyncke (evyncke) <[email protected]> wrote: > Hi, > > > > The first IESG ballot for the draft-ietf-hip-native-nat-traversal was done > in May 2018 and was blocked by a couple of DISCUSS by the 2018 IESG. The > main issue IMHO was around “why not reusing plain ICE?”; the authors in > discussion with Adam Roach have provided an applicability statement and a > justification on why “plain ICE” does not work efficiently when combined > with HIP + additional text or replies for the remaining DISCUSS & COMMENT.. > > > > The diff are > https://www.ietf.org/rfcdiff?url2=draft-ietf-hip-native-nat-traversal-30&url1=draft-ietf-hip-native-nat-traversal-28 > > > > I have reviewed all COMMENT and DISCUSS from 2 years ago and it appears to > me that they are all addressed (including those from 2018 AD who are no > more AD in 2020 – they are in cc). The changes in the document are minor > and I am confident that neither a WG Last Call not an IETF Last Call is > required. I am therefore placing the document in the next IESG telechat and > opening a new IESG ballot. > > > > Thank you for the authors on their energy to keep the document useful, > > > > Regards, > > > > -éric > > >
_______________________________________________ Hipsec mailing list [email protected] https://www.ietf.org/mailman/listinfo/hipsec
