Ballot for draft-ietf-lisp-lcaf
Yes
No Objection
Abstain
Note: This ballot was opened for revision 15 and is now closed.
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.
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?
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?
Sarah Banks <sbanks@encrypted.net> reviewed this document for the opsdir
I support Stephen't discuss.
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.
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."
Thanks for resolving most of my discuss points. I remain unconvinced about the wisdom of including section 5, hence my abstain ballot.