First bit of IP Addresses
Hi, I am not clear in basics of ip address format, why we are not using the first bit as 0 to define new class of addresses, may this double the available IPs, Regards, __ Get personalized email addresses from Yahoo! Mail - only $35 a year! http://personal.mail.yahoo.com/
First bit of IP Addresses
Hi, I am not clear in basics of ip address format, why we are not using the first bit as 0 to define new class of addresses, may this double the available IPs, Regards, __ Get personalized email addresses from Yahoo! Mail - only $35 a year! http://personal.mail.yahoo.com/
Re: First bit of IP Addresses
Anshul Jain wrote: I am not clear in basics of ip address format, why we are not using the first bit as 0 to define new class of addresses, may this double the available IPs, Hmmm... and why not call this new class of addresses "Class A"? In the classful world: bit 1 = 0 - Class A bits 1,2 = 10 - Class B bits 1,2,3 = 110- Class C bits 1,2,3,4 = 1110 - Class D (Multicast) etc. James
STD-2 is obsolete
Joe Touch wrote: It is a paradox to begin one standard by selectively omitting current standards (e.g., RFC1122). I believe that that is called "making progress". Cited from section 4.20 of RFC-1336: "I think three factors contribute to the success of the Internet: 1) public documentation of the protocols, 2) free (or cheap) software for the popular machines, and 3) vendor independence." Thus, it is not "end-to-end-purity" or because the existence of any organization. Speaking of keeping standards, I am wondering why STD-2 is still RFC-1700, although the current version is kept by IANA at http://www.iana.org/numbers.htm . regards, -- Rahmat M. Samik-Ibrahim - VLSM-TJT - http://rms46.vlsm.org - Good bye hegemony - http://sapi.vlsm.org/DLL/linuxrouter
NATs and peer-to-peer (was Re: [midcom]...)
It was ... peer-to-peer things that made the Internet popular. Yes. Before there was the web (back in the days of HOSTS.TXT and ftp clients on so few platforms that one's best efforts to convert carriage returns were often foiled), email-based file servers were popular, and they still are. Asyncronous messaging of files is why Internet messages, which support sevral methods of in-line file transfer, are dominant and will continue to be. Based upon some data on "web ready cell phones" being used primarily to send text messages The advantage of such messaging is not that it is text, but that it is asyncronous. Anyone who is interested in obtaining asyncronous audio file messaging on cellular telephones might ask Laurence Lundblade at Qualcomm -- mailto:[EMAIL PROTECTED] -- about which models of the QCP phone line will be capable of supporting it, etc. The last I heard there was some question as to whether the manufactuer would include a routine for data transfer from the voice memo buffer to the seperate CPU address space used for the PalmOS Eudora program. Qualcomm's highest-level management have advocated this for years, it turns out (and I have it on good authority that is why there is a vocodec built in to Eudora); I wonder if they realize that those goals are again being thwarted by some overseas programmer goofing off instead of writing code for an already-existing API. Cheers, James
Re: [midcom] WG scope/deliverables
On Thu, 01 Feb 2001 05:34:31 +0100, Sean Doran said: "Hm, now let's see, a router on the 'outside' just sent back this odd ICMP message. Whatever should I do with it?" may not be so Given the unauthenticated nature of ICMP, this should give you pause. I *already* get *enough* headaches with routers and NATs and trying to do PMTU Discovery throught them. -- Valdis Kletnieks Operating Systems Analyst Virginia Tech PGP signature
head hurting [was Re: [midcom] WG scope/deliverables
Well, I don't think this is about midcom any more but something here made my head hurt... Ed Gerck wrote: ... You miss at least one other possibility. If it is possible to develop an addressing scheme that works in a heterogeneous network, then we can have point-to-point functionality across system borders er, that is what the Internet concept was invented for by Pouzin, Cerf and Kahn in the early 1970's. The references are in RFC 1958. That addressing scheme is called IP; the problem is that 32 bits are no longer enough. .and do not require a homogeneous address space to do so. at some level you must have an unambiguous namespace. If 10.1.1.1 is used in two different places there must be a way of distinguishing them. Unfortunately, today we do this without the benefit of an explicit namespace - the distinction is implicit in the instantaneous state of NAT automata, i.e. the internal state of all NATs is an extension to the IPv4 address space. Thus when 10.1.1.1 is behind a NAT that has loaned it address 9.1.1.1, its implicit address is 9.1.1.1+10.1.1.1. That's an unambiguous address space; it's just implicit. (NAPT, multiple NAT or NAT-PT make it a bit more complex, but don't change what I'm saying in principle - the implicit address just gets longer.) A rendez-vous service for NATted peers would have to construct an identifier explicitly, and it might as well be this implicit one. Brian
Re: STD-2 is obsolete
Brian E Carpenter wrote: Joe Touch wrote: ... Speaking of keeping standards, I am wondering why STD-2 is still RFC-1700, although the current version is kept by IANA at http://www.iana.org/numbers.htm . Very good question. I'll be glad to raise the issue with IANA; at least 1700 and STD-2 should be obsoleted in their current form. afaik nothing in 1700 has been rescinded, so it isn't obsolete; it's simply updated by http://www.iana.org/numbers.htm I was using the term 'obsolete' as in 'obsoleted by', as used in other standards that have been updated by subsequent RFCs. IANA can't change the status of an STD - that's an IESG action. If you think this matters, I would raise it with the latter. Agreed. I was expecting that IANA would initiate taking the action with the IESG, not that they would supercede it. Joe
Re: [midcom] WG scope/deliverables
from some of the discussion, esp. yesterday, i had thoughts of deriving an anti-NAT polemic and posting it. i planned on mentioning all of the other brain-dead, obsolete technologies "we" (IP) had in the past ignored, and how we had triumphed while they had died off. i was thinking of things like IBM mainframes, BSC, SDLC, and ultimately got around to thinking of things "in our community" such as UUCP over asynch (mostly) phone lines, etc. but as i thought of it, i realized that what "we" successfully ignored in the past were things that had little use (the ISO acronym popped up in my mind). things that were heavily used, we somehow brought into the fold and, in some sense, stepped on their shoulders on our way to "the world of greater connectivity". the examples are numerous, and happened in different ways. "we" invented ways of interconnecting (at least at the level of e-mail, the killer app of the 80s) with IBM mainframes, VMS boxes, etc. we ran IP over BSC and SDLC. we invented MX records, as well as bizarre addressing formats (!%.etc.), to interconnect between the SMTP world and the UUCP world. i guess if i think anything about all that, it is that if NATs are ubiquitous, we should figure out how to deal with them. and, that (hopefully), we will achieve the "greater interconnectivity" on top of, and to some extent in spite of NATs. cheers, Greg Minshall
Re: [midcom] WG scope/deliverables
[recipient list trimmed] i guess if i think anything about all that, it is that if NATs are ubiquitous, we should figure out how to deal with them. perhaps. but I note that for many of the examples you quoted, "dealing with them" was not nearly as nice as "not having to deal with them". for instance, having email gateways was clearly better than not having any way to exchange mail between Internet/DECnets/BITNET/uucp/CSnet/etc. at the same time, email gateways never worked as well as we would have liked. they often required users to know arcane details about addressing in foreign email systems and how the addressing from different email systems were combined (things like "ATLAS::BITNET%\"USER@NODE\""@xxx.yyy were entirely too common), they introduced many additional kinds of failure which were difficult to diagnose, non-delivery reports from foreign systems were unreliable (either going to the wrong place or not being able to be returned to the sender) and hard to decipher, and return addresses were often trashed so that replies didn't work. Even the simple question "what is your email address?" was not simple to answer - the answer depended on context, and many users honestly didn't know the answer for anything beyond a very local (to them) context. Many users couldn't give their email addresses to others. I'll also note that email gateways were once ubiquitous, but now are much less common. we do need NATs in IPv4 to work around the address space shortage as well as to allow connectivity for networks using private address space which cannot easily be renumbered, just as we once needed mail gateways. but just like mail gateways, they don't have to stay around forever, and NAT use will also decline when better alternatives are available. Keith (who wrote email gateways in a past life)
Re: STD-2 is obsolete
Joe Touch wrote: ... Speaking of keeping standards, I am wondering why STD-2 is still RFC-1700, although the current version is kept by IANA at http://www.iana.org/numbers.htm . Very good question. I'll be glad to raise the issue with IANA; at least 1700 and STD-2 should be obsoleted in their current form. afaik nothing in 1700 has been rescinded, so it isn't obsolete; it's simply updated by http://www.iana.org/numbers.htm IANA can't change the status of an STD - that's an IESG action. If you think this matters, I would raise it with the latter. Brian
Re: [midcom] WG scope/deliverables
Dave Cheriton's TRIAD is an example of such a proposal. Hilarie Dave Crocker [EMAIL PROTECTED] 02/01/01 11:05AM At 03:05 PM 1/31/2001 -0800, Ed Gerck wrote: You miss at least one other possibility. If it is possible to develop an addressing scheme that works in a heterogeneous network, then we can have point-to-point functionality across system borders and do not require a homogeneous address space to do so. There is roughly 30 years of experience in this realm that suggests otherwise. The difference between theory and practise is practise. If you wish to formulate a detailed technical specification, and subject it to community review and testing, perhaps you will indeed show show us an approach that will work. Until then, your suggestion is just an untested theory. d/ ___ midcom mailing list [EMAIL PROTECTED] http://www.ietf.org/mailman/listinfo/midcom
Re: [midcom] WG scope/deliverables
On Thu, 2001.02.01, Hilarie Orman wrote: Dave Cheriton's TRIAD is an example of such a proposal. Hilarie Dave Crocker [EMAIL PROTECTED] 02/01/01 11:05AM At 03:05 PM 1/31/2001 -0800, Ed Gerck wrote: You miss at least one other possibility. If it is possible to develop an addressing scheme that works in a heterogeneous network, then we can have point-to-point functionality across system borders and do not require a homogeneous address space to do so. Nimrod, not Triad - fails heterogeneity. -p.
Re: Mail sent to midcom (fwd)
Although it is true that RFC2418 does not explicitly permit the "review" of messages submitted to elists from non-subscribers, it is in fact an accepted practice on IETF elists. So much so that the IESG has published a statement regarding the policy and procedures of such practices: http://www.ietf.org/IESG/STATEMENTS/moderated-lists.txt Speaking for myself, I wish that all IETF elists could and would adopt the practice of reviewing all non-subscriber submissions for at least obvious irrelevance. If someone has the time it would be nice to have a more careful review to ensure messages are on-topic as described by a Working Group's charter, but that is certainly not required. The first would go a long way towards eliminating spam on IETF elists. Just to be clear, I'm making a distinction between moderation and review to reject obvious irrelevance. In that context, I agree with you that the phrasing in the notification message you received could be improved, but I think it's an unfair leap from "reviewing messages" to "midcom is not open" without even asking what the actual policy and practice is and confirming whether or not the AD and IESG are aware of it. Melinda's note makes it clear, at least to me, that the policy is consistent with the spirit of RFC2418 and the IESG statement indicated above. Speaking as Co-Chair of this working group, unless you have a specific request for a change to RFC2418 or the IESG statement, I don't see any basis for continued discussion of this point on the poised elist. If you object to how the midcom elist is operating you need to take that up with the midcom-admin and the relevant AD. Jim co-Chair of the POISSON Working Group IETF mailing lists are intended for OPEN discussion; the benefits (cross-pollination between lists, lack of inhibition about stating your opinions) are widely recognised as outweighing widely-accepted drawbacks (e.g. Peter Lewis advertising every forum everywhere he can think of, allisat going on yet another hallucinogen-induced trip down memory lane). midcom is not open. midcom should not be part of the IETF, much less a working group. No, I don't care that having a moderator-in-the-middle filtering everything is in the spirit of the midcom charter and must be for my own good. I _really_ don't like the concept of an IETF-approved poster to a mailing list on an IETF-run server. We can do our own filtering, if we choose to, and we don't need the IETF to do it for us. Moderator approval of individual posters is outside the spirit of RFC2418, and would require AD and IESG approval. What are we coming to? L. [EMAIL PROTECTED]PGPhttp://www.ee.surrey.ac.uk/Personal/L.Wood/ -- Forwarded message -- Date: Thu, 1 Feb 2001 11:00:40 -0500 (EST) From: [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: Mail sent to midcom Your mail to 'midcom' with the subject: Re: [midcom] WG scope/deliverables Is being held until the list moderator can review it for approval. The reason it is being held: Only approved posters may post without moderator approval. Either the message will get posted to the list, or you will receive notification of the moderator's decision.
Re: Mail sent to midcom (fwd)
There's another subtlety here - lists that filter mail from non-subscribers penalize folks who use subaddressing for incoming list mail, since they don't post from the same address at which they are subscribed. Ideally, lists should not consider subaddresses when comparing a contributor's address against the list of subscribers. Failing that, it's helpful if a subscriber can get his "From" address registered as one for which there is special permission to post. Your suggestion to "not consider subaddresses" is impractical at best, and illegal regardless. On the contrary, it's clearly practical as I have running code in bulk_mailer that does this (which will be in the next release). Nor is it illegal. Since there are no standards regarding list filtering, there are no standards that prohibit lists from doing filtering using fuzzy matching rather than exact matching on an address. My guess is that most lists that filter on source address are already taking liberties when comparing addresses - they're doing case-insensitive comparisons of the local-part when according to the standards the local-part is allowed to be case-sensitive. It doesn't take rocket science for the list to seperately compare the domain of an email address and the portions of the local-parts up to but not including any of the separators commonly used: ( + - / . = # ) hosting the elist. Even if it did you're suggesting the elist server should peek or otherwise parse the localpart of an non-local email address and that is wrong. Guess we'd better put a stop to those case-insensitive comparisons, then. The only practical solution is, as you propose, that the elist needs to have a separate list of addresses approved to submit messages. Actually I've demonstrated that there is another practical solution, one which is unlikely to penalize those using subaddresses at all. Keith
Re: Mail sent to midcom (fwd)
"Keith" == Keith Moore [EMAIL PROTECTED] writes: Keith On the contrary, it's clearly practical as I have running code in Keith bulk_mailer that does this (which will be in the next release). Keith Nor is it illegal. Since there are no standards regarding list filtering, The only practical solution is, as you propose, that the elist needs to have a separate list of addresses approved to submit messages. Keith Actually I've demonstrated that there is another practical solution, one Keith which is unlikely to penalize those using subaddresses at all. Frankly, both are useful and they are complementary. I run many lists. They are now all restrict_post, but I always make a corresponding -nomail list. Both are managed by majordomo, but -nomail has defunct aliases. [EMAIL PROTECTED] is like this, and receives daily posts from people reporting problems. I have a script that subscribes them to the -nomail list, and then reposts their message. People who post once usually post a second time. It's a lot less hassle than spamming several hundred people, and then dealing with the "why is that spam there..." etc. If this is too strong medecine for the IETF, then a system of "+censored" lists would help. :!mcr!:| Solidum Systems Corporation, http://www.solidum.com Michael Richardson |For a better connected world,where data flows fastertm Personal: http://www.sandelman.ottawa.on.ca/People/Michael_Richardson/Bio.html mailto:[EMAIL PROTECTED] mailto:[EMAIL PROTECTED]
Re: Mail sent to midcom (fwd)
I believe most IETF WG mailing lists restrict automatic posting to those subscribed and a list of other from addresses. As a practical matter, in this age of spam, that is considered "open" and, if not in place, is commonly demanded by a consensus of the WG. Every WG is a little different and I believe these sorts of policies should be determined on a WG by WG basis by the WG chair, the WG consensus, and the AD. From: Lloyd Wood [EMAIL PROTECTED] Date: Thu, 1 Feb 2001 21:48:13 + (GMT) Reply-To: [EMAIL PROTECTED] To: James M Galvin [EMAIL PROTECTED] cc: [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], Scott Bradner [EMAIL PROTECTED], Allison Mankin [EMAIL PROTECTED] In-Reply-To: [EMAIL PROTECTED] Message-ID: [EMAIL PROTECTED] On Thu, 1 Feb 2001, James M Galvin wrote: Although it is true that RFC2418 does not explicitly permit the "review" of messages submitted to elists from non-subscribers, correct. It doesn't explicitly prohibit it either. it is in fact an accepted practice on IETF elists. (or elitists, as they perhaps should be known?) I like to request a public list of those lists. It would be interesting to spot any patterns in the data. I don't think there is and don't see why there would be a centralized list of specific WG mailing list policies. Both the TRADE and XMLDSIG WG's, which I chair and co-chair respectively, block most non-subscriber posting. I consider this to be consistent with RFC 2418 and in both cases the policies were installed early in the WG existence after numerous complaints by WG members about spam. So much so that the IESG has published a statement regarding the policy and procedures of such practices: http://www.ietf.org/IESG/STATEMENTS/moderated-lists.txt Note the use in that statement of the terms 'might be needed', 'persistent' and 'excessive'. midcom's list policy clearly does not fall within that scope (a single email from me to midcom is neither persistent nor excessive). I interpret moderation to be the human review and approval of all messages that get to the list. Any WG that permits unrestricted posting after you subscribe is not moderated. Speaking for myself, I wish that all IETF elists could and would adopt the practice of reviewing all non-subscriber submissions for at least obvious irrelevance. The IESG statement does not cover that. RFC2418 does not cover that. Just to be clear, I'm making a distinction between moderation and review to reject obvious irrelevance. irrelevance and its obviousness is in the eye of the beholder. I would be extremely worried if messages were suppressed because e.g. a WG chair had deemed a matter to be settled and would not permit further discussion because further discussion is irrelevant (thinking of e.g. recent heated EF technical debate on diffserv). As long as WG chairs are trusted to determine WG consensus, I don't see why they can't determine if a message is obviously irrelevant to the tasks for which a WG was created. I'm not claiming a WG chair would never make a mistake but their decision are subject to review. Anyway since those who subscribe can post whatever they want, judgement usually doesn't enter the picture. That's where this is heading. In that context, I agree with you that the phrasing in the notification message you received could be improved, but I think it's an unfair leap from "reviewing messages" to "midcom is not open" without even asking what the actual policy and practice is and confirming whether or not the AD and IESG are aware of it. Just to be clear: midcom's policy falls outside stated IESG policy, and we've agreed that it is not permitted by RFC2418. As far as I can see, midcom's policy is unrelated to the IESG policy, which covers manual moderation of all posting. Nor do I see any agreement that it is not permitted by RFC 2418. It depends on what "open" means. The definition of words changes with circumstances. In the country or the early Internet, an open house might have no lock or guard and a host might, as many did, have a "guest" account with no password. In the middle of Manhattan or the modern Internet, open means you have locks and guards and you usually check out people who haven't gone through a procedure to get on an access list. midcom is reviewing messages, based on email address and then content. midcom is not open. There's a direct causal relationship between those two statements. I believe your definition of open differs from mine. Melinda's note makes it clear, at least to me, that the policy is consistent with the spirit of RFC2418 see your first sentence... In which he said that such a policy was not explicitly permitted in 2418 which is not at all saying that it is prohibited. and the IESG statement indicated above. which it isn't. Speaking as Co-Chair of this working group, unless you have a specific request for a change to RFC2418 or the IESG statement, I'd like a statement
Re: Mail sent to midcom (fwd)
I believe most IETF WG mailing lists restrict automatic posting to those subscribed and a list of other from addresses. I have the opposite belief. I've been using subaddresses for several years (so I wasn't posting from the same address at which I was receiving list mail) and most of the lists in which I've participated did not restrict such postings. It's only very recently that I've seen a significant problem. Keith
Re: Mail sent to midcom (fwd)
I run many lists. They are now all restrict_post, but I always make a corresponding -nomail list. Both are managed by majordomo, but -nomail has defunct aliases. [EMAIL PROTECTED] is like this, and receives daily posts from people reporting problems. if the list is set up right, people don't have to report such problems. the suspect messages go to the moderator; the moderator either approves them or not based on whether they're on topic for the list. if they are, the moderator can add the poster's address to the list of those who can post withut moderation. adding support for recognizing subaddresses just optimizes this process - the moderator doesn't have to deal with quite so many messages, and the posters who are using subaddresses don't have even their first message delayed. the system works fine either with our without the optimization. but it would be nice if mailing lists weren't hostile to those using subaddresses. Ketih
