Master at: https://notes.ietf.org/notes-ietf-117-anima
IETF117 is a hybrid IETF meeting.
Please familiarize yourself with the new&changed procedures for
participating in-person or remote:
https://www.ietf.org/how/meetings/preparation/
ANIMA will have one 2 hour session,
chaired by Sheng Jiang and Toerless Eckert
09:30 - 11:30 (local time PST, 16:30 - 18:30 UTC) Wednesday Session I,
Room Plaza B
Number of participants on meetecho: 28. In the room: 16.
Toerless: renew the early reviews on BRSKI docs to get green status back
from reviewers.
Toerless: IANA registration for type for JWS voucher.
Toerless: finish (as shepherd) brski-prm issues left open for me to
approve.
Toerless: discuss for BRSKI-AE wrt to RobW MTI question... BRSKI-AE
support alone does not say anything ? always needs some
(mechanism-rfc(eg:lightweight-CMP) plus brski-ae). Also relevant to
variation registry: those two RFC would need to be references for
variation entry line.
Toerless: paul Wuters - clluster (BRSKI-AE will work) against 6125bis
(his review, please bump).
Time: 09:30 - 09:40 (10 minutes)
Presenter: Sheng Jiang (remote), Toerless Eckert (local)
Administrivia, status of drafts
Dan Harkins Note taker - THANK YOU!
Discussion about updating results of early reviews in Datatracker.
Toerless to ask tools-discuss,
and will trigger last-call reviews to get new review status in data
tracker.
Discussion about drafts without slot ask:
draft: draft-ietf-anima-rfc8366bis
AD: Yes, please YANG doctor early review on rfc8366bis.
Toerless will trigger after getting a Shepherd review first (Alex
Clemm).
draft: draft-ietf-anima-constrained-voucher-21 (was -20 at IETF116)
draft: draft-ietf-anima-constrained-join-proxy-14 (was -13 at IETF116 -
no update for IETF117)
Documents in WG last call, waiting for more cycles from co-authors also
on documents with slots. Also common dependencies against rfc8366bis, so
no benefit in releasing them before other docs from the same dependency
cluster are released from WG.
draft-ietf-anima-brski-cloud-06 (was -05 at IETF115 - no update for
IETF116/IETF117)
Document ready to leave WG except for open issue
draft: draft-ietf-anima-network-service-auto-deployment-04 (from
IETF116, no update for IETF117)
Authors are promising update for IETF118
draft: draft-ietf-anima-grasp-distribution-07 (from IETF116, no update
for IETF117)
Toerless provided thorough review before IETF117, authors are
considering next steps for document and will provide WG with update at
IETF118.
draft: draft-ietf-anima-voucher-delegation-02
No Slot: Put into parked state before IETF117 by Toerless.
Re-investigate interest of WG after publication of rfc8366bis. Dead if
there is no interest/time then to work on it.
draft: draft-ietf-anima-brski-ae-05 (was -04 at IETF114)
presenter: David von Oheimb (remote)
WGLC ended April 3rd, editorial changes only to -05
Waiting on discovery discussion, then ready for AD review
Toerless: automated discovery is necessary
draft: draft-ietf-anima-jws-voucher-06 (from IETF116, no update yet)
presenter: Steffen Fries (remote)
Open issues: should not update RFC 8366, get IANA registration for
"voucher-jws+json"
Toerless: is there any early review that would make sense?
Steffen: can't think of one, no reason
Steffen: not sure who is going to get the IANA registration, Michael
maybe
Toerless: IANA reg usually happens after WGLC and WGLC has already
happened
TODO: ask for IANA registration to be done
draft: draft-ietf-anima-brski-prm-09 (TBD) (was 08 at IETF116)
presenter: Steffen Fries (remote)
Slides received
Steffen: Secdir review came back with nits, need to ask for another one?
Toerless: no more YANG in this document, so yangdoctor review not needed
Drafts: draft-ietf-anima-brki-ae, draft-ietf-anima-brski-prm,
draft-ietf-constrained-voucher, ...
Presenter: Toerless Eckert (local)
Pre meeting notes:
Discussion of proposed functionality / text for DNS-SD and GRASP based
discovery for BRSKI variations..
and into which existing or new BRSKI draft to put it.
Variations in parameters need to be discovered, putting all variations
into BRSKI IANA registry.
A variation that is not in announcement implies "default" of the
parameter.
"Reserved" is a placeholder for a variation that is anticipated.
New parameters can be added to registry as needed.
Steffen: we don't have to signal the default parameter, right?
Toerless: ???
Rob: is there a cross list of variations to support, there may be
interoperability problems if many.
Toerless: you're saying you support one or more variations, there's an
MTI for each, so there isn't a combinatorial explosion.
Rob: should be a minimum set of things to support.
Toerless: offering "prm rrm est cmp" would imply arbitrary combinations.
So you should do two different ones if you don't support arbitrary
combinations.
Steffen: is this a normative reference by AE? Delay?
Toerless: should not be an issue by IETF 118.
Steffen: PRM has normative dependency....
Drafts: draft-eckert-anima-services-dns-autoconfig,
draft-eckert-anima-grasp-dnssd
Presenter: Toerless Eckert (local)
Pre meeting notes:
Discuss of feedback from recent reviews, new motivational explanations
in draft version, relationship to BRSKI discovery
Overview of DNS-SD.
Automatically bringing up network services for infrastructure... how to
use GRASP-DNS-SD to discover NOC servers.
Sheng: encourage more work, discussion, and get reviewers. We can
consider adoption.
Draft: draft-yan-anima-BRSKI-CLE-00
presenter: Lei YAN (remote)
Michael: reinventing cose web token. Have you looked into that and the
ACE architecture?
YAN: yes, in BRSKI-CLE the usage of the token is more general than
ACE-OAuth.
Michael: it's not just ACE-OAuth.
YAN: format of token....
Michael: I don't think Anima should reinvent what's out there already
and what you've proposed can be expressed with COSE objects, it's
already been done. There's also an ACE-EST effort you should look at.
Comparing to ACE-OAuth is not a deep enough comparison.
YAN: I will do a deeper comparison in the future.
Steffan: the cryptographic approach is based on certificateless but you
introduced some variations. You should ask CFRG to look into this. Was
there any verification of security on this proposal?
YAN: we plan to propose algorithm to other groups, security proof can be
included in a future version of the draft. We have worked on security
proof.
Steffan: it would be good to talk to CFRG, this is not something that's
only applicable to this.
YAN: we are going to work with CFRG to propose this algorithm.
Toerless: this is crypto with some distinct properties and discussion
with CFRG is important, also make sure this is not something that ACE is
not already working on. If CFRG says "this doesn't make sense" or if ACE
says "we're already doing this" then it would be a big challenge to
overcome.
Time: (5 minutes)
See you in Prague!