The changes look good.
On Mon, Sep 19, 2016 at 8:54 AM, Dino Farinacci <farina...@gmail.com> wrote:
>> On Sep 9, 2016, at 4:15 PM, Stig Venaas <s...@venaas.com> wrote:
>>>> In section 3 we have this paragraph:
>>>> The Address Family AFI definitions from [AFI] only allocate code-
>>>> points for the AFI value itself. The length of the address or entity
>>>> that follows is not defined and is implied based on conventional
>>>> experience. Where the LISP protocol uses LISP Canonical Addresses
>>>> specifically, the address length definitions will be in this
>>>> specification and take precedent over any other specification.
>>>> I'm not sure what conventional experience means. Please try to find a
>>> Well like I said above, the AFI values defined in the AFI document are just
>>> type values and there is no length defined. So “conventional wisdom” means
>>> that if a spec says an AFI value 1 is IPv4, we know what follows is 4
>>> bytes. Ditto for IPv6, MAC addresses, etc.
>> In theory there should be standards/documents specifying this for each
>> of the address types, and maybe could write that people should see the
>> respective standards or something. I don't know if this exists for all
>> the types though.
> It does not. But how about I promise you that when there is a new use-case
> for a specific AFI, we’ll make sure that the AFI and its length are defined
> in that use-case document.
> Like I said, we have this for AFI=17 already. So I have already set an
>>> better way to say it. Regarding the last sentence, what if a you want
>>>> to define new LCAF encodings in the future? Is it good to say that this
>>>> specification takes precedent over any other?
>>> LCAF encodings and definitions do not change the length of an AFI encoded
>>> address. So I am not sure what you mean.
>> The last sentence says "Where the LISP protocol uses LISP Canonical
>> Addresses specifically, the address length definitions will be in this
>> specification and take precedent over any other specification.". What
>> if you in the future would like to write a separate specification that
>> defines additional LISP Canonical address formats?
> Okay, I have clarified that new LCAFs that are defined in other documents
> will specify length and formatting definitions.
>>> In section 3 we have this paragraph:
>>>> Length: this 16-bit field is in units of bytes and covers all of the
>>>> LISP Canonical Address payload, starting and including the byte
>>>> after the Length field. So any LCAF encoded address will have a
>>>> minimum length of 8 bytes when the Length field is 0. The 8 bytes
>>>> include the AFI, Flags, Type, Reserved, and Length fields. When
>>>> the AFI is not next to encoded address in a control message, then
>>>> the encoded address will have a minimum length of 6 bytes when the
>>>> Length field is 0. The 6 bytes include the Flags, Type, Reserved,
>>>> and Length fields.
>>>> Can you phrase this differently? First it says that any LCAF encoded
>>> No not really. It is precise up to the sentence “When the AFI is not ..”.
>>>> address has a minimum length of 8, but then it goes on to say how it
>>>> sometimes is only 6. I understand what you're trying to say, but there
>>>> may be a better way of stating it.
>>> This special case is for some LISP control-messages where the AFI is
>>> another place in the message but the address is somewhere else. Rather than
>>> have the AFI appear twice, the LCAF length needs to be different.
>>> The length field always includes the entire contiguous set of LCAF bytes
>>> including type, flags, length field, etc.
>>> The language is precise and accurate. Let me know how you think stating
>>> what I did in this comment response can be put in without writing a lot of
>>> text about a special case.
>> The problem I see is that first you write "So any LCAF encoded address
>> will have a minimum length of 8 bytes when the Length field is 0." and
>> then you write "then the encoded address will have a minimum length of
>> 6 bytes when the Length field is 0." I understand what you mean, but I
>> feel this is a bit confusing.
>> Maybe you could say something like:
>> When including the AFI, an LCAF encoded address will have a minimum
>> length of 8 bytes when the Length field is 0. Or start by saying that
>> the minimal length is 6, and then say that it will then be 8 when the
>> AFI is included.
> Changed to add your suggestion. Thanks.
>>>> Section 4.10
>>>> In this section there are several examples of using the AFI List Type,
>>>> but I miss a general definition. It appears that there can be a variable
>>>> number of AFIs in the list. Any number > 0? It might be useful to have
>>> Yes, a variable number.
>> How about adding a few lines of text to 4.10 saying that you can have
>> a variable number etc., explaining briefly what the general format is.
>> And then say that what follows are examples?
>> Section 4.10.3
>>>> Isn't it unusual to include the 0 termination? Since you know the
>>>> length it is not really needed. When parsing one will need to check
>>>> the length either way, what should one do it the string accidentally
>>>> is not 0-terminated?
>>> Well the AFI definition in [AFI] doesn’t say how to terminate the string.
>>> But the length field will imply it. However, I wrote the
>>> “distinguished-name” draft to specify when AFI=17 is used (not only in a
>>> LCAF but by itself), how to terminate the string. I could include that
>>> reference, but that draft is not a working group document.
>>> So please advise.
>> Currently it says:
>> Length value n: length in bytes AFI=17 field and the null-terminated
>> ASCII string (the last byte of 0 is included).
>> It might make sense to 0 terminate the DN in some cases, but at least
>> here we know the string length from the value of n, so I think it
>> would be better to drop it here. And as I mentioned, you cannot rely
>> on the 0 for parsing, to be on the safe side you would use n anyway.
> You want to terminate the string in all cases. Because there are cases where
> AFI=17 is not used inside an LCAF encoding. And where there is no length to
> convey the string length. And the Distinguished-Name use-case Internet Draft
> specs this for both LCAF and non-LCAF applications.
>>>> Section 7
>>>> It looks like the table in the IANA considerations doesn't include all
>>>> the types defined in this document.
>>> That was done intentionally. The ones that are experimental are not in this
>>> section 7 list because there is no use-case document for it yet. Maybe the
>>> chairs can explain this better than me.
>> I think it's still useful. If someone sees the type used, they can
>> look it up in the registry. It also helps avoid that someone perhaps
>> tries to reuse one of these types in new documents. If you really want
>> to use one of the code points for something else in the future, a new
>> document could always update the registry.
> Did Luigi’s response satisfy your comment?
>> BTW, it also makes me wonder if it is worth reserving any LCAF types
>> for experiments.
> The space is large enough for FCFS.
> See new version enclosed. Let me know when I can post it if you like the
> Thanks again,
lisp mailing list