Mirja Kuehlewind <[email protected]> wrote: >> 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.
The auditlog can not be used in advance to see if ownership will be
transfered. It's retrospective. So it does not provide a way for the buyer
to check if ownership can/will be transfered. We would still need (b) in
order to notify the MASA of the intent to sell.
If the IETF wants to get into APIs for sales integration, I would be there,
but my feeling is that this is layers above where we normally go. (My
colleague Joseph Potvin hopes to convince us otherwise with with a HotRFC
talk on sunday).
>>> 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.
I have added some text as you suggest, btw.
I am concerned about the "IoT case that is also discussed", as we are trying
hard to not say anything normative about IoT in *this* document, because one
size does not fit all.
--
] Never tell me the odds! | ipv6 mesh networks [
] Michael Richardson, Sandelman Software Works | IoT architect [
] [email protected] http://www.sandelman.ca/ | ruby on rails [
signature.asc
Description: PGP signature
_______________________________________________ Anima mailing list [email protected] https://www.ietf.org/mailman/listinfo/anima
