No need to look for a blue-sheet. Automatically generated by MeetEcho (we hope). Ca. 38…42 attendees.



Update on ACP

Toerless presenting.

Sheng: What will the process be since there are not enough AD positions at the moment?
Eric Vyncke (responible AD for this document): Explained the IESG review process. Should hopefully go fairly smoothly in the next round of IESG ballots, but don’t expect any change for another week.

Update on ASA guidelines

Laurent presenting
WG authors want to ask for WG adoption.

Toerless: How much review was received?
Laurent: Some discussion and reviews, but no formal opposition. Could benefit for more reviews.

Toerless: Ask who has read the document: Sheng
Toerless: I encourage more reviews of the document before doing an adoption call.

Sheng: I believe that this document is useful on how we extend Anima and use the Anima tools.

Toerless: Do you think that prototyping work would help, or is this at a more abstract layer?
Laurent: The guidelines are quite pragmatic. Could be a link with implementation or POC. This could be a direction to follow.

Support of asynchronous enrollment in BRSKI

Steffen presenting

Toerless: What is the benefit of changing the name? Is this just a beauty contest.
Steffen: ???
Eliot: The discovery mechanism is needed. There is not a single way to do these enrollment functions. (2) Need to think about how these functions might be routed on the server implementation. May not be a right answer. May want to go to more than one route endpoint. As the draft progresses, a bit more prototyping is necessary to check that the right things happen. Making a late name change is probably not appropriate without leaving aliases.
Toerless: Could we write a small document to update BRSKI after we have a BRSKI RFC. Could take to the list.
Steffen: That would be fine to me.
Toerless: Wouldn’t want to make this document to update BRSKI.

Steffen: Take this that discovery should be part of this document, but renaming should be a separate document.

Toerless: ??? Some question about update ???
Rob: There is some freedom on how “update” can be interpreted, but could change during IESG review.

Michael: Most of this document would come under the category of extends, but the discussion on renaming means amends.
Toerless: The question is what does update mean.
Michael: No known answer, not even the IESG knows.

Toerless: It is great that the document has a real change log.

Toerless note: A big webserver may pass URLs to different sub-processes based on URL prefix, e.g.: a different EST vs. BRSKI server. This becomes a lot easier when /brski is a separate prefix from /est.

TODO: Authors pls. propose small update to BRSKI draft with the renaming of /est to /brski, Toerless will help.


Michael presenting

Toerless: Want to ask about naming? Is the first registrar the manufacturer?
Michael: In the cloud somewhere. Not in the home network and not ???. May share database with MASA, but it is not the MASA.
Toerless: Cloud is too nebulous.
Michael: I think that manufacturer would be too confusing.
Sheng: Have another problem with the term cloud. How do you find the cloud registrar. Still looks like magic.
Michael: To answer how to find it. It is compiled into the source code.
Sheng: ??? Another security issue, don’t know if DNS resolver is secure. Could redirect to an untrusted registrar.
Michael: Over HTTPS
Sheng: Not the answer to security. Secures the channel, but could be redirected to a fake registrar.
Michael: Right, but the TLS connection will fail. Either device will try again and reach, or continuously fail and the device would be returned to the manufacturer.
Sheng: May agree with your last point, but this should be noted in the document.
Eliot: To answer question about cloud. Agree cloud is a bit of a buzzword. But often there are complexities that are introduced by using more than one element. ???
Michael: Sure. Think there is some benefit from just saying that it is something out there.
Steffen: You state that the address would be provided at compile time. Makes it fixed to the vendor of the device. Should it be configurable?
Michael: Since the device has never been configured before, need to get to the trust anchor. If after it has been configured, you want to change it, that is fine. But don’t see any point other than the manufacturer having this built in, otherwise I don’t see any point. E.g. if you have access to configure DHCP then you probably have the knowledge of being able to configured the home registrar.

Toerless: Any solution is allowed as long as it doesn’t break the security requirements and we can’t think of any other solution.
Steffen: Probably could do with a better name. ???
Steffen: Machine composed out of several components each one needs to get enrolled
Toerless: Maybe you have found the loophole. Perhaps saying that you if you have physical access to the device you could create another chain of trust.
Sandeep Rao: Considering a fintech problem (e.g. rolling out a lot swipe machines).
Michael: Clarify that this is customers and bank.
Sandeep: We have swipe machine vendors that send machines to the merchants. Merchants get the machine. Device is hardcoded to go back to the supplier. Can the supplier redrect (e.g. by range of ids) to my registrar.
Michael: Yes, this is exactly the point. Can use the serial numbers, with knowledge about where they have been sold, to redirect to the correct place. Problem with VOIP is that often credentials are provided in the clear. Really want to ???
Sandeep: Can we discuss with you and Eliot offline? ??? missed the last bit ???
Russ: What is the next step?
Michael: The question is do the WG want to adopt it?
Toerless: Get into audio queue and raise hands if you have read the doc.
Result: Looks like 5+ folks.
Toerless: We can’t really do a hum for adoption, so will take this to the list.

star-consideration document structure

Michael presenting

Toerless: Are you including development into operation?
Michael: Not talking about how you engineer. Talking about why you might want to put them into one platform. E.g. how do I deal with my database. Do we want to be hte same device that talks to the MASA. Some discussion about ACP connect.
Toerless: The things that you explained, not sure whether everyone would think that these are part of operations, or engineering.
Michael: ??? would refer to this document to explain ???

Toerless: Late on time, perhaps we can just ask who has read.
Who has read the register considerations draft? Looks to be 3-4.
Who has read the second document? Looks to be 3.
Toerless: Please can everyone else take a look at these documents?

Eliot: Something that came up in last call for BRSKI. Need to consider about how ownership transfer works over time.
Michael: If you can resell something …

Toerless: You resell things.

Rob Wilton: OPS IoT work / onboarding - considering WG in the OPS area, might include MUD work - send email out about this, where some of this belongs. Toerless: What is IoT ? Rob: you know it when you see it.

overflow - l2-friend-acp/lldp

Michael presenting

Toerless: understand what you want to do, but didn’t understand why you want to do this.
Michael: STP isn’t turned on in this network, but need to deal with forwarding loops. E.g. will links be redundant, but need ACP enabled. Please is to do it all inband with ACP.
Toerless: Restating: Want to enable ACP on L2 networks but some ports would be blocked by STP
Michale: No the issue is that STP is off, and you have forwarding loops. Don’t really want spanning truee, but someone more sophisticated.

Toerless: Want to under switches that don’t use STP. Enterprise switches often would come up with STP enabled. Hence we need to understand how these devices normally behave.
Michael: If you take two unmanaged switches and plug them together, they fail.
Toerless: Of course, but ???
Michael: They do run something like WRT.
Toerless: Any of those that don’t run spanning tree.

Russ: There is a conversation in IEEE 802 coordinate space regarding LLDP v2. Timing may be really good to get your requirements heard. Suggest that you formulate your question. I’ll be happy to faciliate the discussion.
Michael: Thanks, that would be good.

Open Mic

Note: This might have been after the meeting … and perhaps not part of the formal minutes.
Andre Bondi: I’m a performance specialist. Has there been any thought about how much could be done in parallel.
Toerless: Might want to talk to Michael, or take it to the list.
Andre: So that would be in all the RFCs?
Toerless: No, that would be in the draft.

AI for chairs

To be worked on after IETF108 on mailing list
1.Ask for adoption interest for ASA guidelines, ask for those who have read document, then if/when we have critical mass, ask for adoption

  1. Toerless to review brski-ae

  2. From Michael Richardson: Ask for interest in design-team for draft-richardson-anima-voucher-delegation

  3. AI - ask for who has read the document: Steffen Fries Russ Housley, Eliot Lear, Hendrik Brockhaus Sheng Jian. Ask for adoption on the list.

Registrar considerations: Eliot Lear, Wei Pan Steffen, same three folks. TODO list to read for toerless.