yeah, it *is* easier to deploy first and then later make incremental
modifications for scalability - if you like NAT.
You do have to build upgrade paths into the architecture if you want
it
to last ... Making an architecture last is all about .. creating
interfaces for the rest of the system
Snipping out everything not related to one error I'd like to correct.
On Mar 14, 2005, at 11:00 PM, Tony Hain wrote:
[suresh] VOIP appls go through the same kind of paylod processing in
firewalls
as do NATs with ALG support for the application. In many
implementations,
firewall and NAT share the
I'm not sure they're the same people in both cases. but here's a
litmus test - if there's not a token for any host A that host B can
hand to host C at some arbitrary location in the network and have C
use that token to quickly and reliably establish a connection to A
(modulo access control)
...
Another concern I have is that, in an IPv6-only world, even if you
eliminate NAT, there will still be firewalls, and those firewalls will
frequently have the property that they block traffic coming from the
outside to a particular IP/port on the inside unless an outbound packet
has been
Date: 2005-03-14 08:42
From: Gaurav Vaish [EMAIL PROTECTED]
After ID writing, you gave me another tough task - two independent
and fully interoperable implementation. Hooh!
Note that that applies for the Standards Track, but not for
Informational RFCs.
btw, can I have these two
Another concern I have is that, in an IPv6-only world, even if you
eliminate NAT, there will still be firewalls, and those firewalls
will frequently have the property that they block traffic coming from
the outside to a particular IP/port on the inside unless an outbound
packet has been
Hi Keith,
Then you may be interested in this effort:
draft-vives-v6ops-ipv6-security-ps-03.txt
draft-palet-v6ops-ipv6security-02.txt
Regards,
Jordi
De: Keith Moore moore@cs.utk.edu
Responder a: [EMAIL PROTECTED]
Fecha: Tue, 15 Mar 2005 10:51:13 -0500
Para: Brian E Carpenter [EMAIL
On Tuesday, March 15, 2005, at 09:44 AM, Brian E Carpenter wrote:
I think this is why we chartered MIDCOM in the first place.
Yes, and midcom as currently specified does support firewall attributes.
To get back to the broader questions, when we set out to do midcom and
to address the general
Title: reflections from the trenches of ietf62 wireless
Folks,
After a few days of decompressing, I have been considering
what to say that is helpful without unnecessarily prolonging
this conversation. I have been involved in the delivery of
wireless for six IETF meetings (#s 46,
Title: Re:reflections from the trenches of ietf62 wireless
Hi Karen,
Thanks for your feedback. I was one of those having problems and not reporting it, but I didnt saw any email asking for more feedback after Monday, so I assumed the fixing work was on-going. Actually Id problems to read my
From: Keith Moore moore@cs.utk.edu
when that functionality requires having knowledge that is only
possessed by the network (which is what hosts need to do address
selection)
Rome wasn't built in a day. If you have a solution that requires pieces
A, B and C, saying you can't
From: Tony Hain [EMAIL PROTECTED]
'A tremendous amount of work' is the fundamental point of my
complaint. We are wasting valuable resources patching a hack.
'A tremendous amount of work' is the fundamental point of my complaint
too. We are wasting valuable resources trying to
If you have a solution that requires pieces A, B and C, saying you
can't deploy one unless the others are already deployed is a recipe
for statis.
it's not a matter of what is being said, it's a matter of what is
required for things to work well. or to put it another way, if your
proposed
On Mar 15, 2005, at 9:08, Odonoghue, Karen F CIV B35-Branch wrote:
I distinctly remember
sitting in the health club hot tub at the end of IETF58 swearing
I would never do the wireless again.
well... call me old fashioned - I appreciate those good
folks who go forth and try and give us an
Title: Re:reflections from the trenches of ietf62 wireless
I
would contend that it isn't a planning issue as much as a resource issue.
We had
a mailing list to discuss planning. What we lacked was
resources
including time, equipment, and facilities. This is
always going to be an issue
as
One thing I have heard from the trenches is that the WLAN would be a
lot easier to set up and debug if
- the IETF owned its own base stations
- and these were selected for their functionality for supporting large meetings
with
lots of RFI (i.e., as opposed to having to take whatever the sponsors
As I wrote this it got longer and longer, so the abridged version is:
- We had problems on Monday, but we believed the wlan to
be operational (albeit without IPv6) with a few obscure
problem reports from Tuesday onward. If people were
I mostly had no problems from Tuesday onwards with one
Title: Re:reflections from the trenches of ietf62 wireless
Hi Karen,
For me getting the equipment, or even knowing what equipment with more than one week, is a matter of planning. Making sure that you can make some staging, access the venue earlier, and even more resources is also planning in
I think that the point this thread has got to is one that
the multi6 WG got to a couple of years ago, and has since
moved past: hence the shim6 proposal, which actually tries
to deal with deployed reality (BGP, and applications that treat
addresses as identifiers, for example), admits that some
For me getting the equipment, or even knowing what equipment with more than
one week, is a matter of planning. Making sure that you can make some
staging, access the venue earlier, and even more resources is also planning
in my opinion.
So what you are saying is that the people who are
On Mon 14 Mar 2005 08:50:14 +0530,
Gaurav Vaish [EMAIL PROTECTED] wrote:
Alas but I couldn't find any dict.org community. And the only
contact address that I found in dict.org ftp site was of the original
rfc-2229 authoer - Faith.
http://www.dict.org/links.html tells how to subscribe to
Hi Keith,
Absolutely not, was not my intention at all to suggest that. They do an
excellent work.
If the meetings are planned much more ahead, there will be more resources,
and even probably will not need for volunteers, because will be possible to
find a host.
Even if we don't have a host,
On Tuesday, March 15, 2005, at 10:51 AM, Keith Moore wrote:
What we need is an architecture for multilayered defense that allows
centralized policy specification (which is merged with host policy)
and which is application-aware.
You mean like midcom?
Melinda
What we need is an architecture for multilayered defense that allows
centralized policy specification (which is merged with host policy)
and which is application-aware.
You mean like midcom?
no. for the most part, apps shoudn't have to be aware of the existence
of middleboxes, and there
A new Request for Comments is now available in online RFC libraries.
RFC 4012
Title: Routing Policy Specification Language next
generation (RPSLng)
Author(s): L. Blunk, J. Damas, F. Parent, A. Robachevsky
Status: Standards Track
A new Request for Comments is now available in online RFC libraries.
RFC 4011
Title: Policy Based Management MIB
Author(s): S. Waldbusser, J. Saperia, T. Hongal
Status: Standards Track
Date: March 2005
Mailbox:[EMAIL
A new Request for Comments is now available in online RFC libraries.
RFC 3971
Title: SEcure Neighbor Discovery (SEND)
Author(s): J. Arkko, Ed., J. Kempf, B. Zill, P. Nikander
Status: Standards Track
Date: March 2005
Mailbox:
A new Request for Comments is now available in online RFC libraries.
RFC 4022
Title: Management Information Base
for the Transmission Control Protocol (TCP)
Author(s): R. Raghunarayan, Ed.
Status: Standards Track
Date:
A new Request for Comments is now available in online RFC libraries.
RFC 3972
Title: Cryptographically Generated Addresses (CGA)
Author(s): T. Aura
Status: Standards Track
Date: March 2005
Mailbox:[EMAIL PROTECTED]
The IPSEC KEYing information resource record (ipseckey) WG in the Security Area
has concluded.
The IESG contact persons are Russell Housley and Sam Hartman.
The mailing list will be closed.
___
IETF-Announce mailing list
IETF-Announce@ietf.org
The IESG has approved the following document:
- 'LDAP Schema for UDDIv3 '
draft-bergeson-uddi-ldap-schema-06.txt as an Informational RFC
This document has been reviewed in the IETF but is not the product of an
IETF Working Group.
The IESG contact person is Ted Hardie.
Technical Summary
The IESG has received a request from an individual submitter to consider the
following document:
- 'Media Type Specifications and Registration Procedures '
draft-freed-media-type-reg-02.txt as a BCP
The IESG plans to make a decision in the next few weeks, and solicits
final comments on this
The IESG has received a request from an individual submitter to consider the
following document:
- 'HTTP Header Field Registrations '
draft-nottingham-hdrreg-http-03.txt as an Informational RFC
The IESG plans to make a decision in the next few weeks, and solicits
final comments on this
The IESG has received a request from an individual submitter to consider the
following document:
- 'Scripting Media Types '
draft-hoehrmann-script-types-02.txt as an Informational RFC
The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please
34 matches
Mail list logo
