Re: [Anima] Moving forward with draft-ietf-anima-autonomic-control-plane

[Benjamin Kaduk <[e-mail]>]

Hi Éric,

On Mon, Jun 22, 2020 at 10:43:00AM +0000, Eric Vyncke (evyncke) wrote:
> As the shepherding AD for this document, I am happy to see recent technical discussions on this document. OTOH, I do not observe any convergence to remove the pending DISCUSS.
> 
> 
> 
> The 2nd IETF Last Call was completed 2 months ago in April 2020. Joel Halpern did the review for routing directorate and found a couple of issues (zone-ID, loopback definition) and it seems that there is now an agreement within the community for updated the text.
> 
> 
> 
> In order to progress the document, a revised I-D is needed to fix Ben’s DISCUSS points:
> 
> - Use of rfc822Name rather than otherName: the ‘easy’ fix is indeed to use otherName (even with the section 6.1.2 justifications)

Russ has been helping reach out to more of the PKIX community; one
suggestion that came up so far is to consider defining a dedicated URI
scheme and using a uniformResourceIdentifier SAN -- did the WG consider
that in the initial discussions?

> - “MTI cryptographic mechanisms are under-specified” that should not be controversial and easy to fix

Toerless has been doing an incredible job reaching out to the IPsec
community and getting this text nailed down.  There are still a couple
points still under discussion but I'm confident that we will have something
good here (and IIRC the TLS stuff has already been polished).

> - Clarification about the RPL root

I'm pretty sure this is already done -- note that my latest ballot position
is only for the -19, so I think I just didn't update it yet.

> 
> 
> Unsure whether Eric Rescola’s DISCUSS are still applicable (as they were on -16); but, this would be a plus to fix these points.

Indeed.  I expect the current SEC ADs to review those when the document
comes up on a telechat again.

> 
> 
> I understand that the authors have worked on this for 6 years and may be bored but I would love to see this I-D going forward. Again, as many others I fail to see the reason of using rfc822Name and the fix would be to use otherName.

I do not want to put words in anyone's mouth, but my understanding is that
the "obvious alternatives" to otherName are believed to suffer from strong
deployment difficulties, whether one attempts to use an existing
(commercial, or so-called "public" CA) or COTS CA software to run one's own
CA.  (There is some question as to whether the "public CA" route is
advisable at all, given the legal agreements and policy documents
surrounding such CAs and whether issuing certificates intended for ACP use
is compatible with those policy documents.  Sean's review alluded to some
of these topics, and if you manage to catch Ryan Sleevi when he has time,
he can talk about them at length.)

-Ben

> 
> 
> May I also suggest to the authors to add new co-authors in order to have ‘fresh blood’ and energy ?
> 
> 
> 
> Regards
> 
> 
> 
> -éric
> 
> 
> 
> 
> 
>