No need to look for a blue-sheet. Automatically generated by MeetEcho (we hope). Ca. 38…42 attendees.
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.
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.
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.
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.
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.
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.
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
Registrar considerations: Eliot Lear, Wei Pan Steffen, same three folks. TODO list to read for toerless.