Hi Jeff,
On 06/30/2016 07:08 PM, Jeff Ahrenholz wrote:
Miika,
On 6/30/16, 1:12 AM, "Miika Komu" wrote:
Is it actually a problem for the Responder that two different Initiators
happen to claim different SPIs? The Initiators have different IP
addresses (or at least
On 6/30/16, 9:06 AM, "Miika Komu" wrote:
>> Seems like a good idea. No ESP_TRANSFORM -> no need to establish two-way
>> comms between peers.
>> For example, when performing a registration procedure with a relay server.
>
> The direct path could be, of course, used for
Miika,
> On 6/30/16, 1:12 AM, "Miika Komu" wrote:
>
> Is it actually a problem for the Responder that two different Initiators
> happen to claim different SPIs? The Initiators have different IP
> addresses (or at least UDP ports if they are behind the same NAT).
Hi Miika,
First of all, nice work with all of your changes!
This is a big draft but seems much clearer without the RFC 5770 delta.
Here’s some further comments on your questions...
> * What should do with compatibility with RFC 6078 (HICCUPS)
I think you can omit this, since RFC 6078 is for
Hi Miika,
I was reviewing this section...
> * 4.12.3. Handling Conflicting SPI Values
> * Should the Responder send a notify on SPI collision?
> * Removed text about registering with multiple addresses because I
>think this does not work with HIP (or at least, requires multihoming)
Hi,
high-level changes are as follows:
* The new draft version follows the ice-bis version, so I removed
aggressive nomination
* Clarifications in the subsections in section 4.12. Relaying
Considerations
* Fixed some nits
Open questions:
* What should do with compatibility with RFC