> I basically support Alexey's discuss position and Ben's
> comment but with a bit more detail below.
Thanks for your comments Stephen.
> - section 3: I don't see how you can produce a canonical
> order of the LCAF encodings if two can contain e.g. the
> same values other than different URLs, since there is no
> canonical way to order URLs (or JSON structures etc.)
> without a lot more specification.
We want to define an order so if an implementation parses, say Type 4, it can
optimize to know that Types 1-3 will not come after Type 4. We can achieve that
with this text:
[RFC6830] states RLOC records are sorted when encoded in control
messages so the locator-set has consistent order across all xTRs for
a given EID. The sort order is based on sort-key {afi, RLOC-
address}. When an RLOC is LCAF encoded, the sort-key is {afi, LCAF-
Type}. Therefore, when a locator-set has a mix of AFI records and
LCAF records, they are ordered from smallest to largest AFI value.
> - 4.3: I agree with Ben's comment. You ought include some
> text here to the effect that this information can be
> privacy senseitive and to recommend not sending or
> storing it in such cases.
I did that for the next revision.
> - 4.4: there are also potential privacy issues here if
> this could be used to identify traffic that is from one
> specific host behind a NAT. A similar privacy warning
> should be included.
It does not identify any host.
> - 4.7: Sorry, when is key material sent in a message? How
> is that protected? (Key ids are fine, but not key values)
That is documented in the two use-case references.
> - 4.10.2: The same privacy issues apply here as for 4.3
> and 4.4, if the MAC address maps to e.g. a portable
> device carried by a person.
In this case, the MAC address can be a host/person. I put a refernece to the
Security Considersations section that references RFC6280/BCP160.
> - 4.10.3 and all of section 5: What are these for? I
> don't see the sense in defining these if there is no well
> defined way to use them. Any of these might have
> undesirable security and/or privacy characteristics.
We have use-cases for them. And they are being documented in both other working
group and individual contributed drafts.
> - Section 6: There are security considerations. See
> above.
I added text per Ben’s comments.
Thanks,
Dino
_______________________________________________
lisp mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/lisp
