Re: [Anima] MACsec as an alternative to L3-tunnels

2019-07-29 Thread Michael Richardson
Toerless Eckert wrote: >> The people in the line behind me did not agree. > Hmm... Don't remember if anyone else stated that there can be one one > keypair. As i said in the other mail, both a single and a douple > keypair solution are possible to build, i just think it would be

Re: [Anima] anima: updated milestones for WG

2019-07-29 Thread Toerless Eckert
Yes. The datatracker entries, actually say this is draft-carpenter-anima-asa-guidelines, somehow that level of detail did not get copied into that appended mail (generated by datatracker), but it will be visible once the milestones are acknowledged by Ignas. We've been using "Lifecycle and

[Anima] anima: updated milestones for WG

2019-07-29 Thread Toerless Eckert
We have updated the milestones for anima on datatracker. Alas, our AD (IGnas has to approve) before they can be seen publically, so i have appended what the system summarized back to me here. This is primarily for adoption after recharter and the submission to IESG are rough estimates from the

Re: [Anima] [core] SID files and IANA

2019-07-29 Thread Michael Richardson
Ivaylo wrote: >> Given that draft-ietf-anima-constrained-voucher is past WGLC, I {mcr: it's not past WGLC} >> personally don't see any problem to add it to the initial SID range >> allocations (sec 6.3.3) with a new range (as IANA is not responsible >> for the mega range that

[Anima] Milestones changed for anima WG

2019-07-29 Thread IETF Secretariat
Changed milestone "Submit bootstrap a trust infrastructure solution to IESG (Standards Track)", resolved as "Done", added draft-ietf-anima-bootstrapping-keyinfra to milestone. Changed milestone "recharter to refocus scope, or close", set due date to August 2019 from November 2018. URL:

Re: [Anima] MACsec as an alternative to L3-tunnels

2019-07-29 Thread Toerless Eckert
On Fri, Jul 26, 2019 at 07:33:41PM -0400, Michael Richardson wrote: > > Toerless Eckert wrote: > > First of all, there is obviously an ability to filter out packets > > NOT to encrypt. Otherwise you would have a lot of problems negotiating > > the encryption keys. To the best of