Hi! Please see below.
> On 16. Jul 2019, at 19:01, Michael Richardson <[email protected]> wrote: > > > {I almost hit the 'n'ext key on this email when I read you had No > Objection... I wonder if the DT should link the comments in the DT > to the thread that results} No problem. I guess the discusses are more important to figure out first anyway. > > Mirja Kühlewind via Datatracker <[email protected]> wrote: >> I agree with Alissa's discuss that the conclusion of section 10(.3) >> should be to recommend a manual configuration mode. Also with respect > > okay. > >> to section 10.2: if ownership is "enforced" by the manufacturer, there >> should also probably be a way for the buyer to check if ownership was >> transferred by the saler during the re-sale process. > > So you are asking for an additional API from the JRC to the MASA. > It would need to include something like: > > a) a POST from selling-JRC to MASA to ask MASA for if a resale would be > granted. > This could result in some statement that the seller could show to the > buyer that would validate that the transaction can occur. > b) a POST from selling-JRC to MASA to indicate to whom the sale was made, > this would have to include some reference to the buyer. > c) a GET from the selling-JRc and also buyer-JRC that would ask who > the current owners is supposed to be. > > (c) could in theory be done with the auditlog, provided that the (b) process > installed the buyer as an authorized entity that could query the auditlog. > It would probably be better to have the MASA do the thinking here, rather > than the JRC. > > I can imagine creating such APIs. There probably needs to be some > buyer-JRC/seller-JRC APIs, or at least conventions. This could easily become > a rathole attracting all sorts of online sales API. Were this to be added to > this document, or to an extension document, I'd want to have significant > involvement from some people who build financial/sales systems, or at least > From the operations divisions of some buyers (operators) and sellers > (vendors). I was mostly thinking about discussing this case in the text, rather than add a specific mechanism. E.g. you could say c) is an option that can be used right away and a more dedicated interface could be considered in future. > >> Two other small comments on more load related points: > >> 1) sec 4.1: "Connection attempts SHOULD be run in parallel to avoid >> head of queue problems wherein an attacker running a fake proxy or >> registrar could perform protocol actions intentionally slowly. The >> pledge SHOULD continue to listen to for additional GRASP M_FLOOD >> messages during the connection attempts." One minor comment: Maybe >> also say explicitly, while running in parallel, one should not send all >> initial messages at exactly the same time but pace them out (e.g. one >> every 3 secs) to avoid network overload when initial connectivity is >> very constraint. > > I take your point. > In the ANIMA ACP situation, please think about the situation as being a > multiport BFR with three+ 100G fiber connections to other cities. Or, one or > more ports plugged into some (unmanaged or probably outsourced) L2 fabric that > has multiple other ACP devices on it. I guess that doesn’t map to the IoT case that is also discussed in the doc. However, this is a usual safety measure we are building in all protocols (expect there is a good reason to do otherwise), e.g. also for routing protocols, because you never know for sure how future deployment scenarios will look like. > >> 2) sec 4.3: " It must be sufficiently low that the aggregate amount of >> periodic M_FLOODs from all EST servers causes negligible traffic across >> the ACP." I know this is a little bit a blurry requirement but I would >> still like to see a MUST here. Or maybe give an upper bound for the >> maximum frequency, e.g. MUST NOT send more than once per minute...? Not >> sure it there is a reasonable value here. > > I'm hesistant to write anything specific here. There are two reasons. > One is that we really don't have any experience running ACPs yet, or how much > bandwidth will typically be available, and we also don't know how many JRCs > a typical operator might deploy. > > The second reason is that I think that this should really be dealt with in: > https://datatracker.ietf.org/doc/draft-ietf-anima-autonomic-control-plane/ > (or mabe https://datatracker.ietf.org/doc/draft-ietf-anima-grasp/) > > ACP section 6.1.4.1 defines an M_FLOOD for the SRV.est. This is not > necessarily the JRC, btw, as certificate renewal might be performed by > a different system than enrollment. It does say: > > The M_FLOOD message MUST be sent periodically. The default SHOULD be > 60 seconds, the value SHOULD be operator configurable but SHOULD be > not smaller than 60 seconds. The frequency of sending MUST be such > that the aggregate amount of periodic M_FLOODs from all flooding > sources cause only negligible traffic across the ACP. > > I will copy this text. That would be good! Thanks! Mirja > > -- > ] Never tell me the odds! | ipv6 mesh networks [ > ] Michael Richardson, Sandelman Software Works | IoT architect [ > ] [email protected] http://www.sandelman.ca/ | ruby on rails > [ > > > -- > Michael Richardson <[email protected]>, Sandelman Software Works > -= IPv6 IoT consulting =- > > > _______________________________________________ Anima mailing list [email protected] https://www.ietf.org/mailman/listinfo/anima
