Daniel Migault <mglt.i...@gmail.com> wrote:
>> It there any reason to wonder if this is a magic choice for
>> compression?
> The selection of the specific values was not based on any particular
> reasons. With LSB compression, the larger the network prefix in the TS,
> the greater the potential for compression. It is relatively
> straightforward to generate the examples, as we have the necessary code
> available. Please feel free to let us know if you would like to see a
> specific example, and we would be happy to provide it. We will provide
> additional examples.
I suggest a few additional examples with some other addresses.
2001:db8.. src/dst, and then some ULAs, and then some fe80::
>> Are there interactions between the outer IP header compression
>> mechanisms listed and RFC7400, or RFC4944? Neither of which is cited.
> There are no interactions in the sense that we do not rely on them. We
> only compress the IP header when operating in tunnel mode, and the
> compressed IP header is the inner IP header. The outer IP header is not
> compressed. RFC 4944 and 7400 can be used to compress the outer header,
> depending on L2.
understood.
>> I think that Valery's comments are probably on, and HCP_UNSUPPORTED
>> surprised me.
> The current version of the draft has replaced HCP_UNSUPPORTED with
> NO_PROPOSAL_CHOSEN, as we did not want this to be a blocking issue. We
> still believe that being able to provide a way for a random device to
> offer a hint could be useful. Conversely, we can also consider having
> such information available out-of-band prior to establishing the
> communication. We are open to the preference of the WG on this matter.
Great!
>> I see the implementation note; has this run on real devices with real
>> radios yet?
> This version of the draft has only been tested according to the SCHC
> (Static Context Header Compression) protocol, which means that the SCHC
> expression of the compression corresponds to our understanding. An
> early implementation of the draft has been developed on Contiki, as
> shown in the following link:
> https://bitbucket.org/sylvain_www/diet-esp-contiki. It has been tested
> on real devices, but the context was IoT. Beyond the Proof of Concept
> (PoC), for diet-esp to be integrated into commercial telecom products,
> it needs to become a standard. This is why we are leading that effort
> ;-)
Thank you for the explanation.
>> The 5-author guideline is exceeded by a bit, what is the plan here?
> We will see with Tero what is the actual maximum number. Though every
> steps of that documents were important, it is likely the authors
> involved in the SCHC version will be prioritized. Other will be added
> in the co-author section.
Five is in the guidelines.
--
Michael Richardson <mcr+i...@sandelman.ca>, Sandelman Software Works
-= IPv6 IoT consulting =- *I*LIKE*TRAINS*
signature.asc
Description: PGP signature
_______________________________________________ IPsec mailing list -- ipsec@ietf.org To unsubscribe send an email to ipsec-le...@ietf.org
