-15 posted. Thanks a lot Stig! Dino
> On Sep 19, 2016, at 4:07 PM, Stig Venaas <[email protected]> wrote: > > Hi > > The changes look good. > > Stig > > > On Mon, Sep 19, 2016 at 8:54 AM, Dino Farinacci <[email protected]> wrote: >>> On Sep 9, 2016, at 4:15 PM, Stig Venaas <[email protected]> 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 [email protected] https://www.ietf.org/mailman/listinfo/lisp
