Jari Arkko has entered the following ballot position for
draft-ietf-lisp-lcaf-17: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:


Thanks for writing this doc. I plan to recommend its approval, but there
were a couple of things that I think should be fixed for clarity before
issuing the RFC. First, I agree with Peter Yee who did a Gen-ART review
on this document:

> Page 6, Rsvd2 definition: the definition both says "reserved for future
> and then says some types actually use it.  That sounds like present
> And to generically say that it should be sent as zero and ignored, but
> to give uses (such as Type 2)  for it  is confusing.  I suggest
> the wording here.

The type that seems to differ from the "ignore" advice in Section 3 is
Type 14. Perhaps you can reword somehow, or name the Rsvd2 field to
Flags, and let the Subsections define that as "set to 0 and ignore on
receipt". Or something along those lines?

I also agree with this comment and believe the text should be corrected:

> Page 6, Length definition: there's mention of a "Reserved" field
> included in the minimum length of 8 bytes that are not part of the
> value.  Since there are actually Rsvd1 and Rsvd2 fields in the generic
> version of the LCAF and sometimes even Rsvd3 and Rsvd4 fields when
> specific Types, it might be better to spell out which reserved fields
> and Rsvd2) are meant here rather than giving the field a summary name
> doesn't actually appear in the format.  This is also important because
> Rsvd3 and Rsvd4 fields are included in the Length field, so using a
> "Reserved" description is ambiguous at best.

And this seems like a bug as well:

> Page 13, RTR RLOC Address definition, 4th sentence: The ability to
> the number of RTRs encoded by looking at the value of the LCAF length
> doesn't seem feasible.  3 IPv4 RTR RLOCs will produce the same LCAF
> as 1 IPv6 RTR RLOC.


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

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

lisp mailing list

Reply via email to