Re: [Hipsec] Spencer Dawkins' No Objection on draft-ietf-hip-native-nat-traversal-28: (with COMMENT)

[Mirja Kuehlewind <[e-mail]>]

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.

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 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.

Mirja



> On 19. Feb 2020, at 21:52, Miika Komu <miika.komu=[e-mail]> 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 
>