Hi, Mirja, and Magnus, On Wed, Feb 26, 2020 at 11:23 AM Mirja Kuehlewind <[email protected]> wrote:
> Hi Miika, > > Maybe you already go a reply from Spencer anyway, however, he is not > serving in the AD position anymore, so he might not reply. > Right, and for extra credit, now that a new ballot has been issued, I'm not seeing the ballot threads from any of the ADs, so didn't want to cause confusion and further delay this document. > Thanks for replying to his comments anyway. I think a way to encrypt > candidate address was what Spencer was looking for. So I think his comment > is addressed as well. > I now apologize for using the word "provision" in my ballot - I wasn't talking about "provisioning" in the configuration sense, but about "making accommodations because middleboxes exist". > I also just enter my ballot with “No objection” and I think Magnus > Westerlund, Spencer’s successor, will also enter a ballot position in the > next week. > I see that Adam has asked the question about why XOR is not required, which is close enough to my question that I should DEFINITELY continue to defer to the current ADs! Make good choices. Best to you all, and thanks for finishing this up. Spencer > > Mirja > > > > > On 19. Feb 2020, at 21:52, Miika Komu <miika.komu= > [email protected]> wrote: > > > > Hi Spencer, > > > > thanks for your comments, please see my response below. > > > > ke, 2018-05-09 kello 18:18 -0700, Spencer Dawkins kirjoitti: > >> Spencer Dawkins has entered the following ballot position for > >> draft-ietf-hip-native-nat-traversal-28: No Objection > >> > >> 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'm balloting No Objection, but I'm watching the discussion in Eric's > >> ballot > >> thread about reusing pieces of ICE, and I look forward to some > >> discussion about > >> the provisions being made for middleboxes in this draft - I'm not > >> denying that > >> such things exist, only that it would be best if we understood why > >> middleboxes > >> are needed for this usage. > > > > I am not sure exactly what you mean by middlebox provisioning, but at > > least a couple of things have been clarified in the draft related to > > middleboxes: > > > > * STUN may be used for discovering address candidates; HIP Control > > Servers are recommended > > * The address candidates are encrypted to protect against middlebox > > tampering > > > >
_______________________________________________ Hipsec mailing list [email protected] https://www.ietf.org/mailman/listinfo/hipsec
