Anima Session I, Monday July 18th, 2 hour session 18:00-20:00 Afternoon Session III, Potsdam II 1. WG Dash - 5 min / Chair slides by co-chairs Sheng reporting on draft status: Need to get more feedback / discussion about bootstrap review onto main anima mailing list to move it to last call. Autonomic Control plane: Milestone planned for september, also need more review feedback for it. Use case drafts - plan not to send them to IESG until we have the other documents stable and ready to send to IETF. Also please provide more feedback for reference model. 2. ANIMA Generic Signaling (Design team) - 30 min by Brian Carpenter, draft-ietf-anima-grasp [Sheng]: Whether GRASP main document could be standalone without API draft? [Brian]: Yes, the main document only states there needs to be API, but doesn't discuss the API in anyway.They are seperate documents. [Toerless]: GRASP can live outside the kernel, we only need privileged user land for flooding and multicast. [Brian]: Yes, I think it's the shared multicast socket that needs kernel privileged.. [Toerless]: We haven't standardize how to discover registar, that might be the biggest gap in current ACP text -> GRASP. [Eliot Lear]: If you don't put the "unused protocols analysis" in the appendix, then you can make a summary, not full analysis, but shorter. [Brian]: I don't have a strong feeling on that. It needs a critical review. No reviews have covered that part. [Toerless]: Can you explain the most simply example where the "Rapid Mode" is highy beneficial? [Brian]: It simply reduces two packets in Sync procedure. [Toerless]: So basically it might be better in IoT environment with counting bits. [Michael Behringer]: I was about to say do we really need that efficiency? (Rapid Mode). But Toerless made a good point in IoT case. [Laurent C.]: 1. Comment on IoT thing: maybe an ASA in the gateway talking for the devices, then no issues anymore for devices. 2. Is there any negotiation of GRASP capabilities? If one doesn't support Rapid Mode, then fail back to normal mode. [Brian]: Rapid Mode is like an attachment in GRASP message, if one doesn't reply with Rapid Mode manner, it implies it doesn't support it. [Terry Manderson]: (Speaking as AD, regarding to some "MAY" keyword usage in current draft) You do have the Appendix very easily used for informational pieces. But I think you need a lit bit more information about that. [Terry Manderson]: If you send the document with MAY, please also include Guidance. Point 49: signaling across two domains: [Michael B.]: (For cross-domain communication issue) It is not that complicated. If you have two domains working together, then you need a common trust anchor. It needs a common CA for cross-signing, but it needs a standized connection such as TLS for that. [Max Pritikin]: I don't think that's quite enough to authorize other domain for certain things. I'd more comfortable to say these things are undefined rather than already defined partially. [Sheng]: It will be fine to say that is an identified future work. [Sheng]: When do you think you close all the open issues? [Brian]: Most them I think can be closed very quickly after discussion with Toerless/Max. The first one (people validate GRASP design and use cases) is the hardest one. [Sheng]: This document is already late as a milestone. WGLC is one of the most efficient way to get reviews. I'd like to close the open issues and send it to WGLC. [Brian]: The first open issue is not under control. The other ones, we can close in a few weeks. 3. ANIMA Auto Bootstrapping (Design team) - 30 min by Max Pritikin, draft-ietf-anima-bootstrapping-keyinfra [Sheng]: (without chair hat on) GRASP for discovery should be "MUST". The WG's ambition is to have one uniform signaling protocol. [Max]: low end device running GRASP stack might not work... [Sheng]: We assume later there will be more ASAs on devices to use the single one protocol [Max]: Maybe GRASP for secure mode; this one (mDNS) for unsecure mode. [Toerless]: mDNS on proxies to bootstrap non-Anima devices; if the client is an Anima device, then "MUST" use GRASP to find proxy. [Michael Richardson]: since we use discovery, then no need for port reservation for proxy or registrar. [Toerless]: Yes, Every discovery protocol needs to be able to discover the port and address. Michael R. and Toerless made some discussion of moving some operational cost from proxy to registrar. Eliot Lear stated that he expected the document Max referenced would be adopted soon. [??From Ericsson]: Have you considered "COSY?" ? CBOR encryption. [Max]: Sorry, I don't know that. [Dan Harkins]: How did the new entity get the MASA server's certifacate? [Max]: The new entity has it from manufacture. [Dan]: So it's the CA cert for manufacturer? [Max]: Yes. Some detailed discussion regarding to domain hash, between Michael R., Eliot Lear, and Max. [Toerless]: Right now in the charter, I don't think we've defined two enrollment devices using GRASP outside the ACP. Maybe in re-chartering. [Laurent]: Regarding to charter, I'm not sure it is explicitly specified GRASP in ACP. I agree it might be an outcome of the WG's work, but disagree it is in the charter. [Toerless]: Maybe I was overstating it is in charter. But it is in framwork how these things interact. [Michael R.]: I'd suggest: if there are addtional attributes required in the pledge certificate, that become known autonomically, that the new member will request a new certificate with the corret new attributes. We should write that into the bootstrap document. [Max]: I like that. [Sheng]: I'm asking you to get more reviewers, and make their comments in the mail list pulicly. 4. AN Reference model - 35 min by Michael Behringer, draft-ietf-anima-reference-model [Michael R.] The naming is exactly the attributes we talked several minuets ago. [Sheng]: The word "Intent" has been over-used a lot. Different people have different meaning of Intent. In Anima, it's good to have specific instance of Intent, not a generic Intent. Or, maybe Anima Intent is a subset of a generic Intent. [Michael B.]: I hope that SUPA defines a framework for Intent, and we grab a subset of it. [Laurent C.] 1.To my knowledge, SUPA is not chartered to do any Intent or Declaritive Policy. 2. In both of the two Intent drafts, we try to make it specific, maybe another terminology such as Goal. 3. Where we start from considering Intent in Anima. E.g., Intent is from operator, or from user? [Michael B.]: I think it's the operator. Because Intent defines a control way how network administrators operate. [John Strassner]: I agree with pretty much everything that Michael said, Laurent said. Except one tiny thing. SUPA is not chartering to do Declaritive Policy, but SUPA model has the abstraction of the facility. [Laurent C.]: The shared adjacency table has any isolation? [Michael B.]: How ASAs access adjacency table is a good question. [Laurent C.]: Let's take it off line. [Brian]: I don't think the ASAs need direct access to the adjacency, except for the infrastructure supported ASAs which arebe special. [Sheng]: You must find a way of avoiding un-converged Intent for IESG. I'll do the Reference Model review. Anima Session II 1. ACP update, by Michael Behringer [Michael R.]: We'll run a seperate instance of GRASP in insecure mode on proxy and nodes try ACP. Some detailed discussion regarding to COAP between Toerless, Sheng, and Max. [Sheng]: co-author make a solution, send it to the mailing list, don't wait for the next meeting. 2. Intent Distribution, by Bing Liu [Michael B.]: we sort of decided against selective distribution [Sheng]: it's not a WG item yet, not in this charter. [Laurent C.]: for Intent Distribution, currently no need for selective flooding; for information distribution, it is a wider scope, depends on the use cases. [Bing] For Intent distribution, I basically agree we might not need selective distribution. For information distribution, I believe selective feature is a useful tool. [Michael B.]: You might want to identify who issued the content, and naildown a specific node. [Max]: if we allow abitrary injection, then content source authorization would be very difficult. [Michael B.]: for conflict handling, just keep the latest Intent. [Bing]: conflict handling most depends on Intent definition. [Laurent]: for information distribution, we need more analysis such as requirement analysis. 3. Coordination Functions, by Laurent C. [Michael R.]: a concrete example of risk failure monitor? [Laurent]: you can monitor in the router, the CPU, memory etc. [Sheng]: are you going to standardize that graph? [Laurent]: it is only one example using grahp theory. [Sheng]: the manifest seems like we need a full list of possible actions and parameters etc. [Toerless]: the manifest doesn't seem imply loops exist. [Laurent]: no, the manifest is just an ASA write down in a file. Conflict is a dedicated function that gather different manifests, parse them, and detect conflict. [Sheng]: still not convinced this is doable. [Laurent]: it's not the end of the story. Some prove points: we made the solution several years ago, with 6 ASAs PoC. [Bing]: for coordination, are there other functions than just conflict handling? [Laurent]: it depends on what we want to do. [Sheng]: you should document the requirements of this function [Laurent]: that's the next presentatino. 4. ASA Lifecycle, by Laurent C. [Michael B.]: what is the stage of the port number used? [Laurent]: two stages, in the install stage and configuration stage. 5. GRASP API, by Brian Carpenter No comments due to very limited timeslot.