Hi

The changes look good.

Stig


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 
> example.
>
>>> 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?
>
> Done.
>
>> 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.
>
>> Regards,
>> Stig
>
> See new version enclosed. Let me know when I can post it if you like the 
> changes.
>
> Thanks again,
> Dino
>
>
>
>
>
>
>
>

_______________________________________________
lisp mailing list
lisp@ietf.org
https://www.ietf.org/mailman/listinfo/lisp

Reply via email to