Skip to main content

LISP Canonical Address Format (LCAF)
draft-ietf-lisp-lcaf-22

Yes

(Deborah Brungard)

No Objection

(Alia Atlas)
(Benoît Claise)
(Spencer Dawkins)

Abstain


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

Deborah Brungard Former IESG member
Yes
Yes (for -15) Unknown

                            
Alexey Melnikov Former IESG member
(was Discuss) No Objection
No Objection (2016-11-16 for -20) Unknown
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.
Alia Atlas Former IESG member
No Objection
No Objection (for -17) Unknown

                            
Ben Campbell Former IESG member
No Objection
No Objection (2016-10-12 for -17) Unknown
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 Former IESG member
No Objection
No Objection (for -16) Unknown

                            
Jari Arkko Former IESG member
(was Discuss) No Objection
No Objection (2016-10-13 for -17) Unknown
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?
Joel Jaeggli Former IESG member
No Objection
No Objection (2016-10-12 for -17) Unknown
Sarah Banks <sbanks@encrypted.net>

reviewed this document for the opsdir
Kathleen Moriarty Former IESG member
No Objection
No Objection (2016-10-13 for -17) Unknown
I support Stephen't discuss.
Mirja Kühlewind Former IESG member
No Objection
No Objection (2016-10-13 for -17) Unknown
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.
Spencer Dawkins Former IESG member
No Objection
No Objection (for -17) Unknown

                            
Suresh Krishnan Former IESG member
(was Discuss) No Objection
No Objection (2016-10-13 for -17) Unknown
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."
Stephen Farrell Former IESG member
(was Discuss) Abstain
Abstain (2016-12-01) Unknown
Thanks for resolving most of my discuss points. I remain unconvinced
about the wisdom of including section 5, hence my abstain ballot.