Hi all,
Exchanging emails with Ian, regarding RFC8026 to be used to prioritize 464XLAT
together with the other transition mechanisms, he suggested that we also
consider draft-ietf-softwire-map-radius.
So, my question is if it makes sense to the authors to make sure that either
464XLAT is
Hi all,
After a long chat with the authors of RFC8026, we have found an alternative
solution which avoids updating RFC8026 and also avoids requiring a new option
code for 464XLAT, as there is already one that we can use, which is related to
NAT64, so still can use RFC8026 for our original
s the most
convenient one. I'm fine either way.
Thanks!
Regards,
Jordi
-Mensaje original-
De: v6ops en nombre de "Bernie Volz (volz)"
Fecha: miércoles, 13 de junio de 2018, 23:02
Para: JORDI PALET MARTINEZ ,
"dh...@ietf.org" , "softwires@ietf.or
Hi all,
I'm sending this to Sotfwires and DHC WGs, in order to let know and seek
review, but please keep the discussion only in v6ops which is responsible of
this document
https://datatracker.ietf.org/doc/draft-ietf-v6ops-transition-ipv4aas/
Here is the short summary of the reasons for
+1
Saludos,
Jordi
-Mensaje original-
De: Softwires en nombre de Tomek Mrugalski
Responder a:
Fecha: miércoles, 8 de marzo de 2017, 18:15
Para: Ian Farrer
CC: Softwires-wg
was surprised to read that this document, if approved, will update RFC7568.
RFC7568 is about SSL 3.0.
So, my guess is that you meant to update RFC7598?
Just so the authors can update the XML to avoid this error to go on ...
Regards,
Jordi
-Mensaje original-
De: JORDI PALET MARTINEZ
+1
Saludos,
Jordi
-Mensaje original-
De: Softwires en nombre de tianxiang li
Responder a:
Fecha: martes, 28 de febrero de 2017, 14:24
Para: Tomek Mrugalski
CC: Softwires-wg
Hi,
Looking at the need for discovering a tunnel-endpoint for DSLINE, same as
for other softwires protocols, I wonder if we should revive the work
previously done at
http://tools.ietf.org/id/draft-palet-v6ops-tun-auto-disc-03.txt
I see that a DHCP option is being proposed, however, our previous