> 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:
Thanks for your comments Jari. See responses inline.
> Page 6, Rsvd2 definition: the definition both says "reserved for future
> use"
>> and then says some types actually use it. That sounds like present
> use.
>> And to generically say that it should be sent as zero and ignored, but
> then
>> to give uses (such as Type 2) for it is confusing. I suggest
> rethinking
>> 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 have suggested (and rewritten) that Rsvd2 be sent as 0 and ignored on receipt
throughout.
> I also agree with this comment and believe the text should be corrected:
>
>> Page 6, Length definition: there's mention of a "Reserved" field
> that's
>> included in the minimum length of 8 bytes that are not part of the
> length
>> value. Since there are actually Rsvd1 and Rsvd2 fields in the generic
>> version of the LCAF and sometimes even Rsvd3 and Rsvd4 fields when
> using
>> specific Types, it might be better to spell out which reserved fields
> (Rsvd1
>> and Rsvd2) are meant here rather than giving the field a summary name
> that
>> doesn't actually appear in the format. This is also important because
> any
>> Rsvd3 and Rsvd4 fields are included in the Length field, so using a
> generic
>> "Reserved" description is ambiguous at best.
When the Length field is 0, it means that no more data follows (for the LCAF
encoding), however the first 8 bytes of the LCAF are still included in the
message. So I am trying to discuss the minimum length of the message (which is
8 bytes).
I have fixed the text to refer to Rsvd1 and Rsvd2 instead of “Reserved” since
there is nothing labled “Reserved”.
>
> And this seems like a bug as well:
>
>> Page 13, RTR RLOC Address definition, 4th sentence: The ability to
> determine
>> 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
> Length
>> as 1 IPv6 RTR RLOC.
It is not a bug. The number of addresses encoded can only be determined by
parsing each one. And there is no value to include a count since you can
compute while parsing (since you have to parse the message to retrieve and
store variable length addresses).
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
>
> 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.
I will make consistent that Rsvd1 and Rsvd2 fields are described up front and
Rsvd3/Rsvd4 in the specific type definitions, since they do not appear in all
definitions.
> 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?
Because the message can be truncated (to reduce size of message), or the RTR
field can be encoded with an AFI=0 (which means no RTR address follows).
Dino
_______________________________________________
lisp mailing list
lisp@ietf.org
https://www.ietf.org/mailman/listinfo/lisp
