> 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.


lisp mailing list

Reply via email to