Hi, On 10 September 2013 21:43, Sander Steffann <san...@steffann.nl> wrote:
> Hi, > > > Speaking personally, I have some concerns about this. > > > > I think my concerns can be lumped into two related categories. Bother > are about interoperability. > > > > Firstly, I find the registration of LCAFs without any explanation of how > or why they would be used to be awkward. > > I have implemented some Python code that tries to use LCAFs, and I can > only say that it is very difficult as an implementer to deal with LCAFs. > Often I have no idea where I can expect which LCAF type. The RFCs don't > give enough guidance here in my opinion. > > The specs allow way too much. As an implementer I don't want to be > surprised because some other implementation suddenly decides to use LCAF > type 3 to add the ASN to the address. Not to mention that an LCAF address > can contain another LCAF address. So should all implementations now support > type-2 LCAF address within type-3 LCAF addresses in case some > implementation decides to add both an instance-id and an ASN? And will that > be encoded as type-2 in type-3 or as type-3 in type-2? What about when > someone decides to add type-5 Geo information to the mix? Should all > implementations support all possible combinations? > > This will make it much too hard to write a good implementation. > First, I must say that I strongly share with this view regarding implementation. I have faced the very same concerns while dealing with LCAFs on the code, specially with nested LCAFs. Regarding the JSON LCAF, I think we all agree that a LCAF format must have a companion document describing its usage. However I believe this does not apply (at least directly) to the JSON format. The idea of this format is to be not constrained by any specification to allow total freedom on its usage. It has been said that this format will be mostly used for experimentation or in intra-domain deployments. Since in these cases there is no interoperation between entities beyond the ones involved in the experiment or the domain, there is no need for a standard. These entities will agree on how to use the format. What should be provided by LISP manufacturers/implementors is an interface to program the LISP device to use and understand the concrete JSON LCAF usage. I think this interface is out of scope of LISP WG. In any case, if the WG feels that there is a need to standardize the JSON LCAF usage, I believe this should be done per use-case. Either a document covering different use-cases in just one place (as the LCAF document does with LCAF formats) or different documents covering different use-cases. Alberto
_______________________________________________ lisp mailing list lisp@ietf.org https://www.ietf.org/mailman/listinfo/lisp
