ietf@ietf.org

At 04:30 PM 10/15/2007, Joel Jaeggli wrote: Daniel Senie wrote: > At 01:29 PM 10/15/2007, John Leslie wrote: > >> Hallam-Baker, Phillip <[EMAIL PROTECTED]> wrote: >> > >> > Whether your objective is to reduce carbon emissions because of >> > gl

ietf@ietf.org

At 01:29 PM 10/15/2007, John Leslie wrote: Hallam-Baker, Phillip <[EMAIL PROTECTED]> wrote: > > Whether your objective is to reduce carbon emissions because of > global warming concerns or reduce dependence on fossil fuels that are > increasingly in short supply, there is a real incentive to red

Re: IETF solution for pairing cellular hosts

At 03:25 PM 9/25/2007, Pars Mutaf wrote: On 9/25/07, Daniel Senie <<mailto:[EMAIL PROTECTED]>[EMAIL PROTECTED]> wrote: At 03:02 PM 9/25/2007, Pars Mutaf wrote: On 9/25/07, Pars Mutaf <<mailto:[EMAIL PROTECTED]>[EMAIL PROTECTED]> wrote: Hello, On 25 Sep 2007 16:

Re: IETF solution for pairing cellular hosts

At 03:02 PM 9/25/2007, Pars Mutaf wrote: On 9/25/07, Pars Mutaf <[EMAIL PROTECTED]> wrote: Hello, On 25 Sep 2007 16:33:32 -, John Levine < [EMAIL PROTECTED]> wrote: >1. The querier user types the target user's "human name" (as if he w

Re: I-D ACTION:draft-wilson-class-e-00.txt

At 07:38 AM 8/9/2007, Marshall Eubanks wrote: On Aug 8, 2007, at 4:22 PM, David Conrad wrote: Hi, On Aug 8, 2007, at 10:18 AM, Hallam-Baker, Phillip wrote: Which widespread IPv4 stacks? I think it might be easier to identify stacks that don't disallow 240/4. I don't actually know of any

Re: IETF65 hotel location

At 12:25 PM 1/30/2006, John Levine wrote: >So, in the context of a location that may be considered isolated, I >think it might be useful to consider this an experiment, and judge >the reaction of the community after the meeting towards this >variable. A reasonable question, but it probably needs

Re: IETF Meeting Venue Selection Criteria

At 11:58 AM 10/14/2005, Avri Doria wrote: Hi, I think there needs to be some mention of requirements such as: - MUST NOT be held in a country whose visa requirements are so stringent as to make it impossible or even extremely difficult for some participant to attend. - MUST NOT be held in a c

Re: ISMS working group

At 08:44 AM 9/12/2005, Margaret Wasserman wrote: Hi Eliot, At 9:44 AM +0200 9/12/05, Eliot Lear wrote: Actually, depending on how the solution is developed it certainly CAN help the problem with the manager being outside a NAT. But we are now being somewhat loose with terms, so let me be more

RE: ISMS working group

At 02:41 PM 9/8/2005, Nelson, David wrote: Let's assume, for the sake of discussion, that SNMP must always work across Firewalls and NATs. The original objection to the proposed charter was that it did not include support for "Call Home" functionality. I can see how Call Home would solve the NA

Re: ISMS working group and charter problems

At 09:14 AM 9/8/2005, Juergen Quittek wrote: --On 9/7/2005 6:49 PM -0400 Sam Hartman wrote: "Fleischman," == Fleischman, Eric <[EMAIL PROTECTED]> writes: Fleischman,> I believe that network management is too important a Fleischman,> functionality to be designed such that it can only b

RE: ISMS working group and charter problems

At 06:00 PM 9/6/2005, you wrote: >> The IETF has been doing extensive work on NAT traversal, have a look >> and see if you can reuse some existing mechanism. > All mechanisms used with the possible exception of an additional SNMP > table will be re-used from existing IETF work (mostly SSH with h

Re: ISMS working group and charter problems

At 02:00 PM 9/6/2005, Dave Crocker wrote: Eliot, I need your help to correct for an impending mistake by the ISMS working group in the IETF. Your note is clear and logical, and seems quite compelling. Is there any chance of getting a proponent of the working group's decision to post a de

Re: Name ownership and LLMNR (Re: Last Call: 'Linklocal Multicast Name Resolution...)

At 02:08 PM 9/1/2005, Harald Tveit Alvestrand wrote: --On 1. september 2005 14:14 +0100 Tony Finch <[EMAIL PROTECTED]> wrote: LLMNR allows me to treat names in a different way than mDNS does. If I have a name that I'm certain I own (this box is, with high certainty, the only one in the world

Re: Last Call: 'Email Submission Between Independent Networks' to BCP

I've just reviewed the ongoing arguments about the draft in question and re-read the draft itself. What strikes me is the level of argument over one section that could easily be adjusted. I would recommend adjusting section 5 to say: "The strongest available secure authentication mechanism i

Re: UPDATE - mp3 audio streaming...

At 12:17 PM 3/10/2005, Harald Tveit Alvestrand wrote: --On 10. mars 2005 07:50 -0800 Joel Jaeggli <[EMAIL PROTECTED]> wrote: In our draft you'll see that we're pretty explicit in that our goal is to build a service that is light-weight enough that it can be provided at a very low cost, and acros

Re: Why people by NATs

At 06:00 PM 11/22/2004, Fred Baker wrote: At 12:10 PM 11/22/04 -0800, Chris Palmer wrote: There's another feature of NAT that is desirable that has not yet been mentioned, and which at least some customers may be cognizant of: the fact that NAT is a pretty restrictive firewall. would that it were t

RE: How the IPnG effort was started

At 12:07 PM 11/21/2004, Peter Ford wrote: Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="_=_NextPart_001_01C4CFEC.A4503CD1"   Noel,   You are sorely under-representing the IETF's and your own efforts wrt NATs.    I think of your taxonomic st

RE: T-shirts, and some suggestions for future ietf meetings

At 12:37 PM 8/10/2004, Glen Zorn wrote: ,,, > Frankly, as long as we can have BAR BOFs in the Hotel, the location > of the food doesn't matter. > > Vienna suffered from having meeting space and hotel seperated, and > unclear default "BAR". Orlando had the same problem. Hmm. As I recall, the m

Re: Names of standards-track RFCs

At 12:56 PM 7/14/2004, John Stracke wrote: John C Klensin wrote: The expansion of it as an abbreviation doesn't provide significant information and may, indeed, add to confusion. It also makes it harder to search rfc-index.txt, since names can span line boundaries and abbrevations can't. Now, as

Re: [Ietf] 240.0.0.0/4

At 06:53 PM 4/20/2004, Bob Hinden wrote: Iljitsch, My comfort level would be much higher if by the time that we need the extra address space, we have a fighting chance of actually being able to use it. So I think it would be a good idea to make it very clear that implementations must, in the ab

Re: MBONE access?

At 09:51 PM 3/3/2004, Joel Jaeggli wrote: On Wed, 3 Mar 2004, Ole Jacobsen wrote: > > > > Apart from the "eating our own dogfood" bit ... > > Most other Internet events I attend, or follow remotely, use Real > audio/video, or sometimes Windows Media Player. > > Can anyone tell me if there are any

Re: Death of the Internet - details at 11

We're clearly looking at this issue from VERY different viewpoints. See comments inline. At 07:11 AM 1/30/2004, Randall R. Stewart (home) wrote: Daniel Senie wrote: I really don't see how this fits with routing policy. You appear to make the assumption that a multi-homed site wants

Re: Death of the Internet - details at 11

At 07:43 AM 1/29/2004, Randall R. Stewart (home) wrote: Iljitsch van Beijnum wrote: On 28-jan-04, at 23:47, Randall R. Stewart (home) wrote: - increased overhead compared to TCP Ok lets see. SCTP takes on average 4 more bytes per data packet then TCP. However, if the TCP implementation enables t

Re: IETF58 - Network Status

At 07:38 PM 11/18/2003, Eliot Lear wrote: I have no first-hand information on how much time this costs "So I'll dream up what I think the right number of people should be!" I think part of the blame should go to the access points that kept disappearing. Someone told me this was because the AP tr

RE: rfc1918 impact

At 05:24 PM 10/15/2003, Michel Py wrote: Leif / Iljitsch, >>> It does sound like a recommendation to the effect of "if you are going >>> to use NAT, or construct a NAT box, then an 'inside DNS' mechanism" >>> would be a reasonable idea. And I would assume it would be an even >>> better one if it

Re: NATs are NOT Firewalls

At 01:34 AM 6/19/2003, [EMAIL PROTECTED] wrote: On Thu, 19 Jun 2003 00:55:49 EDT, S Woodside said: > On Wednesday, June 18, 2003, at 06:28 PM, Tomson Eric ((Yahoo.fr)) > wrote: > > > Now, the fact that masking the internal addresses to the external > > world - so that internal hosts can initiate

Re: myth of the great transition (was US Defense Department forma lly adopts IPv6)

At 01:31 AM 6/19/2003, [EMAIL PROTECTED] wrote: On Wed, 18 Jun 2003 22:19:12 PDT, Eric Rescorla said: > You've got it absolutely backwards. The fact that the NAT breaks applications > that I don't want to run anyway is a FEATURE, not a bug. And the fact that NAT breaks things that you DO want t

Re: Engineering to deal with the social problem of spam

At 03:28 PM 6/7/2003, Eric A. Hall wrote: on 6/7/2003 1:40 PM Paul Vixie wrote: > and in this bof, i suggest that gateways to the current system be shat > upon and never again considered. when we move, we'll MOVE. That's not globally-applicable. Probably better to specify the gateway tagging, an

RE: Thinking differently about the site local problem (was: RE: site local addresses (was Re: Fw: Welcome to the InterNAT...))

At 10:18 AM 4/2/2003, Jeroen Massar wrote: Spencer Dawkins wrote: > Hi, Jeroen, > > Are you talking about > ftp://ftp.rfc-editor.org/in-notes/rfc2732.txt (PS)? > > My quick read of this RFC is that it says "don't use IPv6 > literals without enclosing them in brackets", as in > > host

Re: site local addresses (was Re: Fw: Welcome to the InterNAT...)

At 08:40 PM 3/26/2003, David Conrad wrote: Ted, On Wednesday, March 26, 2003, at 05:03 PM, Ted Hardie wrote: If you were using some of an allocated portion as routable addresses and some as unrouted addresses, you might be forced to change the unrouted addresses as a consequences of choos

Re: charging for IETF participation

At 04:33 PM 3/20/2003, David J. Aronson wrote: How about selling IETF-branded swag? Membership cards? Other cheap junk that does nothing but take up space, collect dust, and confer bragging rights as having financially supported the IETF? Maybe even something useful, like yet another canvas t

RE: ECN and ISOC: request for help...

That said, such routers really shouldn't choke on the packets. I would guess it's dropping the packets due to explicit configuration, though. ----- Daniel Senie[EMAIL PROTECTED] Amaranth Networks Inc.http://www.amaranth.com

Re: (ietf54-noc 1802) Re: why we had wireless problems at IETF

ake sense to just spend the money to properly design these networks, even if they're for short duration use. - Daniel Senie[EMAIL PROTECTED] Amaranth Networks Inc.http://www.amaranth.com

Re: TCP Checksum Interoperability

nts, references 1122. Routers generally have to be valid hosts, too. >$ You lose -- 791 says you have to subtract at least 1 from TTL even if. > >damn. should have picked an option case instead. > >L. > ><[EMAIL PROTECTED]>PGP<http://www.ee.surrey.ac.uk/Personal/L.Wood/

Re: [idn] WG last call summary

the harm when IDNs are used with legacy software. Precisely. Dan ----- Daniel Senie[EMAIL PROTECTED] Amaranth Networks Inc.http://www.amaranth.com

Re: IETF Meetings - High Registration Fees

ohama. I am active on mailing lists, contributing to or commenting on drafts, and so forth. It's entirely possible to be an active participant in the IETF without attending meetings. ----- Daniel Senie

Re: trying to reconcile two threads

AT boxes on the market. Of course that eliminates the address-space-shortage argument, so it's more fun to talk about polling the devices, even if impractical at present. - Daniel Senie[EMAIL PROTECTED] Amaranth Networks Inc.http://www.amaranth.com

Re: participation in IETF meetings

ther non-multicast-dependent access - provide for email or IRC feedback channel(s) to each room I have to wonder if the real time aspect appears never to be used because it's not usable. ----- Daniel Senie

Re: bandwidth (and other support) required for multicast

meetings to make it more usable, or make the video available after the fact only. -- - Daniel Senie[EMAIL PROTECTED] Amaranth Networks Inc.http://www.amaranth.com

Re: Number of Firewall/NAT Users

working on a better architecture to deal with replacing NAT. To do so, we'd have to solve the customer needs which are driving folks to NAT, of course. So, in reviewing the video, I saw people generating plenty of heat, but little light. -- --

Re: Number of Firewall/NAT Users

s of NAT, just that I've accepted we have no choice but to deliver solutions as best we can, taking NAT into account. -- - Daniel Senie[EMAIL PROTECTED] Amaranth Networks Inc.http://www.amaranth.com

Re: internet voting -- ICANN, SmartInitiatives, etc.

ere problems will exist. Election software isn't run often, and it's updated as needed for each election. The disk files we stored had the names of the candidates receiving votes in text, not in binary. As a result, if it'd been necessary, the votes could have been hand

Denial of Service by Spamware?

ore annoying. I expect to see spammers appending viruses to their messages as a way to keep them in front of our faces long after the original spam is gone. Just another case of a "feature" which doesn't scale. -- ----

Re: NATs *ARE* evil!

allocated /24 nets which have been out there and aren't in use, and set up an interconnect registry to hand out /27s or /29s and rent them to those who need this type of private interconnect. -- - Daniel Senie[EMAIL PROTECTED] Amaranth Networks Inc.http://www.amaranth.com

Re: 49th-IETF conf room planning

27;s close together. The hotel rooms are relatively cheap (no idea about the cost of the conference spaces, though). IETF would be a really tiny group for Vegas, but it might be a really good fit. -- - Daniel Senie[EMAIL PROTECTED] Amaranth Networks Inc.http://www.amaranth.com

Re: Useable video from meetings - was suggestion

- Original Message - From: Shirley Tseng <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Monday, November 27, 2000 1:50 PM Subject: Useable video from meetings - was suggestion > Hi, > > It sure would be nice for the IETF to offer webcasting of the meetings. The > objective of 'ease o

Usable Video from Meetings (was Re: Suggestion)

d to be spent on food, so spending it on video collection, transmission and redistribution seems like a good idea. > > cheers > >jon -- - Daniel Senie[EMAIL PROTECTED] Amaranth Networks Inc.http://www.amaranth.com

Re: getting IPv6 space without ARIN (Re: PAT )

virtual IPv6 upstream. Yes, they can even charge money for this and if it's not outrageously expensive, folks might even find it useful. The key factors required are that the users have a way to get real addresses allocated properly, and that it be possible to successfully talk to any other IPv6

Re: getting IPv6 space without ARIN (Re: PAT )

, or we'll be stuck with the IPv4 world and layers of NAT/NAPTs forever. Breaking this logjam won't happen at the IETF/IAB/IESG level. It'll happen through the actions of IANA, ARIN/RIPE/APNIC, and it'll happen if a large ISP decides it's the right thing for the Internet com

Re: draft-ietf-nat-protocol-complications-02.txt

fixed set of ports, so it's unrealistic to expect the market will favor it. Sure, it's a harder problem. A good challenge for engineers to solve. -- - Daniel Senie[EMAIL PROTECTED] Amaranth Networks Inc.http://www.amaranth.com

Re: IPv6: Past mistakes repeated?

and overuse them in applications as well, for this analogy to be really workable for the Internet. Users shouldn't care or know about the network's internal addressing. Some of the application issues with NATs spring directly from this issue (e.g. user of X-terminal setting display based on I

Re: recommendation against publication of draft-cerpa-necp-02.txt

owever, is NOT necessarily an option. You'd argue I give up a cable modem for a dialup ISP? I don't think so. Application level security (SSL, TLS, SSH) work fine for my needs and transit the equipment I must use to exist on a cable modem. -- -

Re: Internet SYN Flooding, spoofing attacks

s of attacks. I expect we will have to add a whole suite of techniques to bring the problems under some reasonable level of control. What is unclear is why some think we could or should do nothing in the short term. -- - Daniel Senie[EMAIL PROTECTED] Amaranth Networks Inc.http://www.amaranthnetworks.com

Re: Internet SYN Flooding, spoofing attacks

quot;legitimate use" of source spoofing has not been sufficiently made. Operational reality is such that it's not sustainable. -- - Daniel Senie[EMAIL PROTECTED] Amaranth Networks Inc.http://www.amaranthnetworks.com

Re: Internet SYN Flooding, spoofing attacks

more for the memory buffers, geez I don't know. The memory cost isn't the issue. You're going to pay more for a lot of ASICs to be doing that operation at wire speed. The work to do what you suggest adds considerably more complexity than doing filtering

Re: Internet SYN Flooding, spoofing attacks

eryone needs to do their part. Unfortunately, it may be threats of negligence lawsuits that ultimately motivates some to take heed. -- - Daniel Senie[EMAIL PROTECTED] Amaranth Networks Inc.http://www.amaranthnetworks.com

Re: IP network address assignments/allocations information?

table sizes won't increase because the present generation of hardware can't handle larger routing tables. Are we being a bit short-sighted? -- - Daniel Senie[EMAIL PROTECTED] Amaranth Networks Inc.http://www.amaranthnetworks.com

Re: IP network address assignments/allocations information?

anizations is a /48." But how does one define "end-user customer?" If cable modem and DSL users (perhaps even dialups) do get this much space, I think we'll all be very happy to be able to do without NAT. Until IPv6 service is offered for dialup and cable/DSL, we can just g

Re: IP network address assignments/allocations information?

to manage the new space about the same as IPv4 space. Which is to say I don't expect space to be readily available. -- - Daniel Senie[EMAIL PROTECTED] Amaranth Networks Inc.http://www.amaranthnetworks.com

Re: IP network address assignments/allocations information?

is a very workable solution for the small office and home network, and questionable for larger networks. Sounds like you're saying the same. -- - Daniel Senie[EMAIL PROTECTED] Amaranth Networks Inc.http://www.amaranthnetworks.com

Re: IP network address assignments/allocations information?

include credible, functional NAPT solutions today. Is it ugly? Sure. Is there any chance it'll stop being attractive to the home user? Unlikely. -- ----- Daniel Senie[EMAIL PROTECTED] Amaranth Networks Inc.http://www.amaranthnetworks.com

Re: IP network address assignments/allocations information?

at class A with a big prefix in IPv6 space and perhaps the folks doing private interconnects will help fund the development of IPv6 equipment and updated applications. -- - Daniel Senie[EMAIL PROTECTED] Amaranth Networks Inc.http://www.amaranthnetworks.com

Re: IP network address assignments/allocations information?

y has intersected operational reality. > At 10:44 AM 11/29/1999 -0800, Tony Hain (Exchange) wrote: > > >1) Yes ... We have been forced into a world of NAT where simple > >applications such as Real Player won't work without real-time manual > >intervention at t

HTTP/1.1 Presentation

The information on HTTP/1.1 compliance in the plenary presentation last night was most interesting. I suspect I'm not the only one who is curious if the tools used for the study, or other similar tools, are available. -- - D

VPN Mailing list administrator?

to time. If we need to pay someone to maintain the list server, then let's do it. Having a consistent and reliable system for all of the mailing lists would be a MAJOR step forward for the IETF. -- - Daniel