Glen Zorn [mailto://g...@net-zen.net] writes:
...
My apologies, I was mistakingly believing that the previous
discussions
on this topic had lead to the adoption of Route-Record AVPs in
answers.
I'm not at all sure that you were mistaken about that, but no such
decision
has been
On Oct 14, 2010, at 4:47 PM, Joel Jaeggli wrote:
On 10/11/10 7:40 AM, Rémi Després wrote:
Le 9 oct. 2010 à 02:50, Fred Baker a écrit :
That's not limited to Germany. Would that dtag.de would use 172.16/12
rather than 10/8 or 192.168/16, as the latter two seem to find their way
into so
Le 15 oct. 2010 à 01:47, Joel Jaeggli a écrit :
On 10/11/10 7:40 AM, Rémi Després wrote:
Le 9 oct. 2010 à 02:50, Fred Baker a écrit :
That's not limited to Germany. Would that dtag.de would use 172.16/12
rather than 10/8 or 192.168/16, as the latter two seem to find their way
into so
On 10/11/2010 04:40 PM, Rémi Després wrote:
Le 9 oct. 2010 à 02:50, Fred Baker a écrit :
Having the same prefix on each side of the residential NAT could be a real
pain...
With my understanding of how NATs work, I don't see why.
Could you elaborate?
Admin pain.
Many unixes today let you
Remi Respres wrote:
I acknowledge that NAT444 does not use two levels of private
networks, which makes me not sure what your point is.
(AFAIK, some mobile phones include NAT44s, and work on mobile
networks that assign 10.x.y.z addresses).
I'm afraid the mobile phone with an external IP
Le 15 oct. 2010 à 10:29, Masataka Ohta a écrit :
Remi Respres wrote:
Problems can occur with some CPEs that don't comply with RFC 5382,
RFC5382 is, by no means, a deployed standard.
Not even a standard-track document (but nevertheless useful to comply with).
Beside, assuming that ISPS
Hi,
Huh? Hardly anyone support IPv6 these days.
Sony KDL40*X70* internet-enabled LED-LCD-TV, 2010, IPv4-only (bought 7/2010)
My TV is bought 2009 and doesn't have any internet at all. And I don't
care (much). It's a TV. Of all my gadgets, the TV is on my lowest
priority for getting an
Remi Respres wrote:
RFC5382 is, by no means, a deployed standard.
Not even a standard-track document (but nevertheless useful to
comply with).
A BCP is a standard document of IETF, which has little influence
over NAT.
Beside, assuming that ISPS assign 10/8 IPv4 addresses, the only
Stefan Winter wrote:
What capabilities there are available on the internet backbone
or what could be enabled on newer operating systems by sophisticated
end users doesn't matter much, if most of the internet-enabled
end user equipment, that is being sold to consumers, is still IPv4-only.
My two cents. Having implemented both models in Blink client (Blink is a free
download if someone cares and wants to experiment with both MSRP models), I can
comment that I do not like the acm model. The relay model is simply better,
cleaner and more secure.
Adrian
On Oct 14, 2010, at 3:27
Both of them
--
Adrian
On Oct 14, 2010, at 17:58, Ben Campbell b...@estacado.net wrote:
Hi Adrian,
Are you referring to the COMEDIA support in msrp-acm, the session matching
change in msrp-sessmatch, or both?
Thanks!
Ben.
On Oct 14, 2010, at 5:26 PM, Adrian Georgescu wrote:
Hi,
I am going to send this draft back to the SIMPLE WG so that they discuss
these issues. Once the WG reaches (rough) consensus on what to do, I
will be issuing a second IETF LC so that everybody is on the same page.
Cheers,
Gonzalo
On 14/10/2010 11:27 PM, Cullen Jennings wrote:
The new
The IESG has approved the following document:
- 'Authorization for NSIS Signaling Layer Protocols '
draft-ietf-nsis-nslp-auth-07.txt as an Experimental RFC
This document is the product of the Next Steps in Signaling Working Group.
The IESG contact person is Lars Eggert.
A URL of this
13 matches
Mail list logo
