-15 posted. Thanks a lot Stig!

Dino

> On Sep 19, 2016, at 4:07 PM, Stig Venaas <s...@venaas.com> wrote:
> 
> 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