LISP Canonical Address Format (LCAF)
RFC 8060

Note: This ballot was opened for revision 15 and is now closed.

Deborah Brungard Yes

(Jari Arkko) (was Discuss) No Objection

Comment (2016-10-13 for -17)
No email
send info
Subsections under Section 4 treat some of the fields in different ways. For instance, in most cases the subsections do not indicate anything about the base fields, but for instance Subsection 4.9 does say something about Rsvd1 and Rsvd2:

   Rsvd{1,2,3,4}:  must be set to zero and ignore on receipt.

This text was raised as an issue by Peter as well:

      When there are no RTRs
      supplied, the RTR fields can be omitted and reflected by the LCAF
      length field or an AFI of 0 can be used to indicate zero RTRs
      encoded.

Why are we giving two options? Or is this a be-conservative-what-you-send-but-liberal-in-what-you-accept situation?

(Alia Atlas) No Objection

Ben Campbell No Objection

Comment (2016-10-12 for -17)
No email
send info
Section 4.3 talks about geo coordinates. I think I understand that these coordinates may give the location of a device. Is there any expectation that said device can be associated with a person? The security considerations mention this briefly. Have the working group considered whether the guidance in RFC 6280/BCP 160 is applicable here?

(Benoît Claise) No Objection

Spencer Dawkins No Objection

(Joel Jaeggli) No Objection

Comment (2016-10-12 for -17)
No email
send info
Sarah Banks <sbanks@encrypted.net>

reviewed this document for the opsdir

Suresh Krishnan (was Discuss) No Objection

Comment (2016-10-13 for -17)
No email
send info
Thanks for taking care of my DISCUSS points. I will clear but I note that the COMMENT points below still seem pertinent.

* Can you please clarify why Rsvd2 is reserved for future use but this document already ends up specifying it under "Segmentation"

* I think the reference for AFI is not correct. Shouldn't it be http://www.iana.org/assignments/address-family-numbers/address-family-numbers.xhtml? The current reference leads to a generic IANA page.

* Section 4.8:

Is the explanation for the AFI correct? The source dest lookups don't seem to be multicast addresses.

"When a specific AFI has its own encoding of a multicast address, this field must be either
      a group address or a broadcast address."

Mirja Kühlewind No Objection

Comment (2016-10-13 for -17)
No email
send info
I support Stephen's discuss. It is unclear if and how this information is used and if this is the right channel to transmit the information; further the security considerations are not sufficient and should be more specific regarding the information provided.

Alexey Melnikov (was Discuss) No Objection

Comment (2016-11-16 for -20)
No email
send info
DNS names and URIs need normative references.

AS per discussion with Dino:
Adding an informative reference to use case document(s) in the Introduction Section and examples of URIs and JSON types would help a reader unfamiliar with LCAF to better understand the need for these types.

(Kathleen Moriarty) No Objection

Comment (2016-10-13 for -17)
No email
send info
I support Stephen't discuss.

(Stephen Farrell) (was Discuss) Abstain

Comment (2016-12-01)
No email
send info
Thanks for resolving most of my discuss points. I remain unconvinced
about the wisdom of including section 5, hence my abstain ballot.