practical subnet sizes smaller than /26, /27, ...
I'm looking for research / surveys on how enterprises and service providers really use subnetting within their networks. In particular, I'm interested in the size of subnets that people are regularly using and I'm interested in both public and private addressed networks (which I'm assuming, perhaps incorrectly, to be different). Note that I'm not looking for best practice or what's possible - I'm interested in what people actually do. Any pointers appreciated. Please respond to me directly - if people are interested, I'll summarize any answers I get and repost to the list. Also, if you think there is a more appropriate place for this question, please let me know. Thanks, John --- Network Appliance Inc. Tel: +1 347 613 2259 230 Park Avenue, Suite 834 Voicemail: +1 408 822 8606 New York, NY 10169 USA ---
Re: filtering active content
At 08:40 AM 25/07/01 -0600, Vernon Schryver wrote: I've read somewhere that they sometimes ignore the 3 character DOS filename or filetype extension and look for magic numbers in the data. I've no way of evaluating that, or at least no inclination. I know that both Explorer and Netscape do exactly this [for web content]. E.g. a filename with .gif can still contain an executable... and therefore a virus. I believe you can find more specific details in the Netscape source code at mozilla.org. John --- Network Appliance Direct / Voicemail: +31 23 567 9615 Scorpius 2 Fax: +31 23 567 9699 NL-2132 LR Hoofddorp Main Office: +31 23 567 9600 ---
Re: Comparison of ICAP and SOAP
Apologies for the delay in responding. I believe that Mark's summary is pretty accurate but I would add one clarification. SOAP encompasses much broader scope that iCAP. SOAP is a whole architecture for messaging; iCAP is a very simplified vectoring protocol. iCAP is a way of getting an object X from A to B. Specifically it does not define how this decision is made - it is simply defines the protocol by which the content is transferred. iCAP shares a lot more functionality with CVP than SOAP. (In fact, the original work for iCAP was titled Simplified HTTP Vectoring Protocol). Rgds, John At 04:15 PM 25/06/01 -0700, Mark Nottingham wrote: In a nutshell: ICAP is a means of encapsulating HTTP inside of HTTP, to allow messages to be 'vectored' from an intermediary to an ICAP server for processing, and then sent on their way. It also defines where those messages may be vectored from the intermediary. I believe that its primary design goal is efficiency, but that's different depending on who you talk to. SOAP can IMHO best be thought of as an XML messaging convention, with some protocol-like attributes (such as the RPC convention). SOAP is designed to be transport-dependant; while its most common use is across HTTP, it can be used with other underlying protocols like SMTP or raw TCP. SOAP is designed to allow targetting of blocks of the XML to be processed by specific intermediaries. Its primary use cases are 'Web Services', i.e., the machine-machine Web, e.g., stock quote services, order queuing, etc. So, SOAP could be used to implement ICAP, but then again so could BEEP. Not too many of the ICAP people are interested in using SOAP, though, as their requirement is to allow 'wire-speed' vectoring and processing, and they find the overhead of XML unacceptable. Cheers, On Mon, Jun 25, 2001 at 04:11:01PM +0800, Wanghong Yuan wrote: HI, All Where can I find some materials or dicussion on ICAP and SOAP? I think both of them address somewhat the content adapation problem in Internet. Thanks. Wanghong Speaking for myself, -- Mark Nottingham, Research Scientist Akamai Technologies (San Mateo, CA USA) --- Network Appliance Direct / Voicemail: +31 23 567 9615 Scorpius 2 Fax: +31 23 567 9699 NL-2132 LR Hoofddorp Main Office: +31 23 567 9600 ---
Re: IETF logistics
Let me give you an example of where this didn't work recently. At San Diego, we had back-to-back meetings of WREC followed by OPES BoF and CDNP BoF. For the most part, there was a very large overlap in the attendance. If you did not forgoe the coffee break and - literally! - run between the rooms, you did not get a seat. If you were silly enough to engage in even a 1 minute conversation and walk slowly, you might not have gotten into the room at all. This is of course further exacerbated by those who do the IETF equivalent of spreading their towels out on the loungers by the pool before going for breakfast... Some folks who had contributed were excluded because the doors had to be closed in order to make the meeting audible. In one case, the door was opened to admit someone who was on the agenda as speaking. I don't believe that any of the solutions offered so far will work because they depend on the good manners of strangers which, frankly, is largely non-existent at IETF meetings. So, my only suggestion is that WG chairs strongly encourage work to be done on the mailing lists, a deference towards non-presentation formats and the strong enforcement of timelines in meetings which is, erm, what we're supposed to encourage anyway... John At 07:35 AM 20/12/00 -0800, Melinda Shore wrote: What happened to the proven and time-honored technique of getting to a meeting early if you want a seat? I know the argument is that we want to hang out in the hallways until the last minute and still get a seat (because we are more "important" than a bunch of the people that did get there early), but still... I think the problem could, in part, be alleviated by physically ejecting from the room people either playing games on their laptops or checking their portfolios. Melinda (and I'm not kidding) - This message was passed through [EMAIL PROTECTED], which is a sublist of [EMAIL PROTECTED] Not all messages are passed. Decisions on what to pass are made solely by Harald Alvestrand. --- Network Appliance Direct / Voicemail: +31 23 567 9615 Kruisweg 799 Fax: +31 23 567 9699 NL-2132 NG Hoofddorp Main Office: +31 23 567 9600 ---
Re: guidance (re: social event politeness)
...and speaking of bad manners, I noticed that there is a resurgence of people talking mobile-phone calls in meetings. I was only there for one day but it happened twice in three meetings. Another annoyance is those who allow it to ring and then cancel the call (presumably using CLI or something). This is not as bad but still pretty disruptive, particularly for the person speaking at the time. Please switch them off. You shouldn't need to be asked. John --- Network Appliance Direct / Voicemail: +31 23 567 9615 Kruisweg 799 Fax: +31 23 567 9699 NL-2132 NG Hoofddorp Main Office: +31 23 567 9600 ---
Re: recommendation against publication of draft-cerpa-necp-02.txt
At 04:45 PM 11/04/00 -0700, Eliot Lear wrote: I wonder if any of the authors has explored the risks of modifying data in flight. How could this be abused by interlopers and evil doers? If I could hack into a router implementing NECP, what damage could I do? Could I start a nasty little JavaScript/Java/Shockwave/... applet in an advertisement? And who would know it was me? Do you mean the authors of NECP? If so, then I'm confused because NECP is not about "modifying data in flight" - it is about load balancing multiple services which sit behind e.g. a single IP address. (i.e. DNS server farms, firewalls, proxies). As I have said repeatedly, "interception proxies" is only one of these applications and by no means the most widely used. Are you confusing this with WCCP (which *only* works with "interception proxies"). Quoth John Martin: [...] Let me be absolutely clear, NECP is about communication between server load-balancers (SLB) and the back-end servers they speak to. Were this so clear in your document my mailbox wouldn't be full of this stuff. The very first sentance says: "This document describes "NECP", a lightweight protocol for signalling between servers and the network elements that forward traffic to them. It is intended for use in a wide variety of server applications, including for origin servers, proxies, and interception proxies." Despite the fact that "interception proxies" are listed last, they are the only service people are talking about. But, you are right in general: if this is how people read the document, we need to fix the document. If it looks like a duck and quacks like a duck, but it's not supposed to be a duck, the IESG ought to point out that it's a turkey by so indicating at the top of the document. Also, I'd like to understand why you're not going experimental, where it would be expected that you'll correct your mistakes. Your choice of "informational" seems unfortunate at best and as disingenuous marketing at worst. I can't tell which. We used "informational" because we saw that this is what was used for HTTP/0.9 with which there are parallels: NECP has existed for some time already in slightly differing implementations and this is a codification of existing practice. There was no magic of deceit intended. If the IESG thinks we should instead go for experimental, I'd be more than happy to pursue that instead and bring this into WREC. However, development is not within the current WREC charter so we are stuck, I think? The fact that you mention interception proxies in the introduction has led to this flame war. Having used the words, you've mentioned none of the risks associated with such services both from the server side and the client side. OK - we can fix that. It is not the goal of NECP to describe "interception proxies" or their deficiencies. There is, however, a working group which has a document aimed at exactly that (amongst other things) - WREC. John --- Network Appliance Direct / Voicemail: +31 23 567 9615 Kruisweg 799 Fax: +31 23 567 9699 NL-2132 NG Hoofddorp Main Office: +31 23 567 9600 ---
Re: recommendation against publication of draft-cerpa-necp-02.txt
At 10:49 AM 13/04/00 -0700, Eliot Lear wrote: Part of the problem here is that a knife may be used as a food utensil or a weapon. Safe handling, however, is always required, and should be documented. Granted. I would add two other comments. I tried to locate the RFC for HTTP/0.9, but the best I could find was a reference to a CERN ftp site for the protocol. Ooops. s/0.9/1.0 - rfc1945. In any case, by the time HTTP got to the IETF it was deployed over a vast number of end stations, and comparisons to it are probably not apt. NECP is a super-set of various load-balancing technologies already deployed at thousands of sites. Finally, rechartering is precisely what you ought to have done, and should do, IMHO. For the record: this is exactly what we are doing. (We were waiting for the two starter documents to be published or at least start their path via the IESG). Rgds, John --- Network Appliance Direct / Voicemail: +31 23 567 9615 Kruisweg 799 Fax: +31 23 567 9699 NL-2132 NG Hoofddorp Main Office: +31 23 567 9600 ---
interception proxies
There has been a lot of discussion about the problems associated with so-called "interception proxies". This discussion is very much within the charter of the WREC WG. In fact, we even have a current draft whose sole purpose is to document such problems. The known problems draft is at: draft-ietf-wrec-known-prob-01.txt This is the first of two very useful documents being produced by WREC; the first, a taxonomy of terminology is available as: draft-ietf-wrec-taxonomy-03.txt; I would suggest you read this first. To join WREC, use the following: mailto:[EMAIL PROTECTED]?Subject=subscribe ...or send a note to [EMAIL PROTECTED] with "subscribe" in the subject. I suggest we move this particular discussion to WREC. Rgds, John --- Network Appliance Direct / Voicemail: +31 23 567 9615 Kruisweg 799 Fax: +31 23 567 9699 NL-2132 NG Hoofddorp Main Office: +31 23 567 9600 ---
Re: prohibiting RFC publication
At 10:39 AM 10/04/00 -0400, Keith Moore wrote: The I-D in question has been referred to an existing IETF WG for review, that assertion was made, but not confirmed by the ADs. is it really true? it seems odd because it really isn't in scope for wrec. Let me jog your memory: At 06:29 PM 30/12/99 +0100, Patrik Fältström wrote: A request has arrived to publish the named document as informational RFC. The IESG wants all documents in this area to explicitely pass the WREC working group, ... I then sought clarification, re-sent the document to WREC (it had been sent before), to determine if there was a conflict - there wasn't. The authors re-submitted it. John --- Network Appliance Direct / Voicemail: +31 23 567 9615 Kruisweg 799 Fax: +31 23 567 9699 NL-2132 NG Hoofddorp Main Office: +31 23 567 9600 ---
