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

[Spencer Dawkins at IETF <[e-mail]>]

Hi, Mirja, and Magnus,

On Wed, Feb 26, 2020 at 11:23 AM Mirja Kuehlewind <[e-mail]>
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=
> [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
> >
>
>