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
