Re: An Internet Draft as reference material
From: Harald Alvestrand [EMAIL PROTECTED] Subject: Re: An Internet Draft as reference material Date: Wed, 20 Sep 2000 14:30:13 +0200 At 14:34 20/09/2000 +0900, Lee, Jiwoong wrote: Dear all What do you think about "de facto" that many technical documents are currently using Internet Drafts as referece material? I've seen next two cases: 1. An Internet Draft refers to another Internet Draft. Common. It means that if the reference is normative, the I-D cannot be published as an RFC before the other. If both refer normatively to each other, they must be published at the same time. (If the reference is not normative, the draft name is replaced by "work in progress" when the RFC is published. Then, sometimes, the draft is lost...) 2. A book refers to another Internet Draft. Stupid, but nothing the IETF can do about it. In electronic books, the Right Thing would be to include all drafts cited as appendixes; in paper books, this might add too much to printing costs. For most of the time it is just plain stupid, however, there are material wich is published in ID form but later down the line is being dropped but still form the fundament for design decissions made in IDs making it all the way to RFCs. Now, if you are going to write a book and want to discuss this backdrop and give a fuller picture then you will have to refer to these IDs. This is really a problem which the IETF has aswell, since this material is not available it is not as easy for a newcommer to get the full picture as those involved in the process has. For instance IPv6 has this problem. When you are in the process, you should feel that it is the Right Thing to drop this old material, but the question is if it is really the Right Thing in the long run. Some of these IDs should really be considered as being published as Informational RFCs for the purpose of giving the background material. I'm not sure of the next case. Any body observed this? 3. An RFC refers to an Internet Draft. Never (except as "work in progress", as noted above - and then the draft is not mentioned by filename). This is a case where having this old background material could be valuble to have. Note, certainly will not all IDs be of interest, but some of them do represent knowledge which should be considered worthy of keeping. IMHO this is a problem, but it is not apparent for everyone being "in" the process, but some is aware of this... Cheers, Magnus
Re: An Internet Draft as reference material
From: Bob Braden [EMAIL PROTECTED] Subject: Re: An Internet Draft as reference material Date: Wed, 20 Sep 2000 15:34:50 GMT The RFC series has long been THE archival series for the Internet. To avoid Internet Drafts becoming another archival series, thus creating great confusion, the IETF has chosen to make Internet Draft ephemeral, timing out after 6 months. Indeed, that is why they are called DRAFTS. The intent is that when good useful information and ideas are published in Internet Drafts, they should become Informational RFCs if they merit preservation and referencing. A Working Group sometimes accumulates a froth of subsidiary drafts with information that is worth preserving, but ancilliary to the primary standards-track work of the group. The chairs should take steps to turn these into Informational RFCs. This was the case for the RSVP working group, for example; I know of at least once such "left-over" I-D that should have been published as Informational. It did not happen because the working group chairs were tired; however, it was their failure in this case. I expect that similar cases exist in other working groups. It is precisely this mechanism that I am refering to and I was trying to point out that it is being less used than what is possibly wise to do. Naturally we should not overuse it either, since that would create an flood of RFCs (and we now count less and less days between each new series of 100 RFCs) and this is also not a good thing. The concentration on getting new protocol specs out there tends to have us forget these longer term issues. As a thread of IDs is being terminated without having it progressing up the standard track, it should be done with the question "Are we really sure there is nothing in this work not worthy of an Informational RFC?". Used correctly it could help to provide some of the missing pieces of the pussel. It is not a full state dump we are doing, rather trying to save some fundamental intermediate states which helps in restoration of history. When IPv6 is going to be replaced, how many people will recall all the background for the decissions made (good or bad, we don't know all of them yeat)? How many will have the healt to even participate? I think we have reason to consider how to deal with these issues and improve the state-saving. Just look at the efforts to bring early (pre-RFC700) RFCs online. So, lets ponder some over these issues and see if there is not something we can do to improve the state of things. Cheers, Magnus
Re: Addresses and ports and taxes -- oh my!
From: Dennis Glatting [EMAIL PROTECTED] Subject: Addresses and ports and taxes -- oh my! Date: Thu, 3 Aug 2000 05:32:04 -0700 (PDT) I've been thinking about the issue of ARIN fees from last night's plenary and arrived at two philosophical questions. I run my business out of my home and my DSL link is an important part of my business. About six months ago my ISP started charging me a $20/mo. fee for my /27 because "ARIN is now charging us." I am unhappy about this fee but I understand its motivation -- conversation of IP space, though I believe fees do not really effect the true wasters of this space and the fee, or as it is called in some circles, a tax, is probably misguided. Nonetheless, with IPv6, I naively hoped, until last night, the conservation of space issues would go away, and thus the fees. Big duh! If we look at today's marketing hype and think forward a bit there is a thrust to "Internet enable" appliances, such as dryers, ovens, and stereos. Assuming ARIN fees persist, my first philosophical question is whether any consumer of these appliances MUST periodically (e.g., monthly) drop coins in the ARIN fountain? Thinking laterally, the reserved port space (1024) is tight. Using the same IP space conversation logic, should fees be charged to conserve port space? If so, my second philosophiocal question is what is our role, as protocol designers and IETF volunteers, in creating, what is slowly becoming, an Internet consumption taxation model? Imagine for a moment the effect of a fee against the allocation or use of port 80 or 443, maybe even port 25 or 53. Well, who would pay for allocating a new service? It does not matter if it is 10 or 10 servers offering something on an allocated port. It is allocated. There is also no good way to get ports back, since how can you assure that there is no longer traffic on some port. Neither the servers or the clients can be in a sufficient way charged for the usage of a well-known port in order to acheive the same pressure as you can do with (real) IP numbers. ISPs can naturally charge you for open up traffic to and/or from a certain port, but that does not give the knowledge that you would require. If someone is running some acient protocol in his/her network using some well known port and would not be communicating it to the outside world, it would still make this port occupied without any money changing hands. Sadly enought I don't think money is the way to solve conservation of port space, we have to rely on good engineering decissions, and boy, does we know that these are not reliable ;) Port numbers are as they are and to some degree we have run into a couple of scaling issues with them. As allways, set a limit and we will (eventually) outrun it. Now, back to the elevators and their prime numbers! (Interesting Elevator Task Force) Cheers, Magnus
Re: Anycast and related frobs
From: Tripp Lilley [EMAIL PROTECTED] Subject: Anycast and related frobs Date: Mon, 26 Jun 2000 07:43:03 + (/etc/localtime) Tripp, I throw myself upon the humble mercy of the gods that I might not make a fool of myself (again) in front of the IETF. Nevertheless, here goes... As I understand it, a goal of IPv6 Anycast is to provide implicit connectivity to the "nearest" netwise instance of a given member of a group of service providers. Now, granted, this is based on an "address", not an address / port tuple, so it's more like a group of machines, than service providers, right? What work has been done to provide a "nearest service" type of implicit addressing? From what I gather, SLP is for service *discovery*, but what I'm really on about is not "what services are available", but "where can I find *this* service, closest to me?" At the 46th IETF in Washington there was a Anycast BOF, chaired by Steve Deering. In there where a few presentations on diffrent aspects of anycast. Then, when the question was raised to the floor on weither there was a need to form a anycast group few hands where raised. The conclusion was that the real need of Anycast was limited (i.e. DNS, PIM RPs and possibly a few other services) and that no specific architecture where needed. Whatever needed was allready there or few trimmings where required. For instance was UUNETs usage of Anycast for PIM Rendez-vous Points presented. They used a trick which seems to be accepted as the only thing really required to acheive the anycast service. They uses an unicast IP address which they set common for all the RPs that so require, then they insert this IP address into the normal unicast routing and the routing will find the "best" path. While it migth be a bit confusing that it is actually diffrent physical positions this is really not diffrent than having a multihomed box having access to widely separated network segments. Mr. Ohta presented the usage of Anycast in DNS root server handling over multiple ASs. The GIA proposal was a proposal for a complete anycast architecture according to the ideas as presented with IPv6. Anyway, you check these presentations and the report from the meeting in case you have not yeat done so. So, there is even some form of Anycast support in IPv4. I am sure that Mr. Deering, Mr. Alvestrand and Mr. Ohta can contribute further on this issue if so required. Cheers, Magnus
Re: IP over MIME (was Re: WAP Is A Trap -- Reject WAP)
From: Patrik Fältström [EMAIL PROTECTED] Subject: Re: IP over MIME (was Re: WAP Is A Trap -- Reject WAP) Date: Thu, 22 Jun 2000 14:02:56 +0200 At 13.37 +0200 00-06-22, Magnus Danielson wrote: 1926 An Experimental Encapsulation of IP Datagrams on Top of ATM. J. Eriksson. April 1996. (Format: TXT=2969 bytes) (Status: INFORMATIONAL) I still havent found a working implementation of this. Any references? Did the channel selection ever get automated? I know that Peter Deutch at then Bunyip was working on a slightly different, but similar, proposal which was to run IP over a string. I guess that if he is on this list, he can explain. I know of succesfull lab tests with running MPEG video over strings, for short distances you can reach several megabits. The downside is that the distance damping is great so it is not a solution for the last mile, it is more a solution for the last meter or so. The benefit of this technology is that you can hear the traffic load over the string as a side consequence of the transmission mode. A good string has considerable more bandwidth than free air transmissions. The good point about building networks over strings is that the medium naturally causes the distance to be short so that the distance between the boxes becomes smaller. This naturally brings down the feasable number of boxes and the protocols can be simplified since you no longer have as sever scaling problems. Excess bandwidth through the wire may cause heating, so one has to select a string of suitable material or else it will convert itself to a fire wire. Cheers, Magnus
Re: IP over MIME (was Re: WAP Is A Trap -- Reject WAP)
From: John Stracke [EMAIL PROTECTED] Subject: Re: IP over MIME (was Re: WAP Is A Trap -- Reject WAP) Date: Thu, 22 Jun 2000 09:03:12 -0400 Bill Manning wrote: And the draft on IP over seismic waves is due any day now. Security Considerations: since the most effective way to generate seismic waves is with a nuclear device, users of this protocol can expect to be secured by their governments for a very long time. This sounds like a protocol which would not run popular in California or else they will communicate themselfs of the US west coast. Also, isn't the long range devices under international non-spread agreements? Some implementations is certainly under strict legal control due to their technology. Will the draft cover the usage of Modified Time Interval Encoding (MTIE)? Cheers, Magnus
Re: WAP Is A Trap -- Reject WAP
From: Masataka Ohta [EMAIL PROTECTED] Subject: Re: WAP Is A Trap -- Reject WAP Date: Wed, 21 Jun 0 5:42:32 JST Phil; IP over NAT is, in no way, end-to-end. WAP and IP over NAT are equally bad. I think you're overstating your case. Yes, IP over NAT is bad, but it's nowhere near as bad as WAP. If you think so, don't say "end-to-end". If you want, it is still possible to "reconstruct" a true end-to-end IP service by tunneling it through a NAT with something vaguely resembling mobile IP. You can have IP over HTTP, IP over XML or IP over WAP equally easily. With IP over MIME you could even establish an IP connection over a mail gateway, firewall bypassing... Hmm the same goes for http proxies. The problem, however, is that the reconstruction point is an intelligent gateway which violates the end to end principle. Havent we learned to love and hate these breaking of layering? You can put basically anything over anything else when it comes to just moving bits around. While doing this we get the additional benefits of increased propagation delay, increased overhead, often complexer solutions and a new bag of problems in the interworking area. Lovely. We can feed a lot of research and engineer mouths this way. Now, while NAT and WAP both intend to solve some problems, they provide ground for new problems which naturally require new solutions. We should really ask weither some of these problems really should be solved within that scope or not. If IP over WAP is a bag of worms, maybe one should bypass WAP alltogether. Where we know that neither ATM, IP or NAT solves all the problems neither will WAP. It is not really what you could do as what you should do. Naturally there is allways politically and technical preferences which prohibits some solutions. Cheers, Magnus
Re: IP over MIME (was Re: WAP Is A Trap -- Reject WAP)
From: "Donald E. Eastlake 3rd" [EMAIL PROTECTED] Subject: IP over MIME (was Re: WAP Is A Trap -- Reject WAP) Date: Wed, 21 Jun 2000 07:31:06 -0400 See ftp://ftp.ietf.org//internet-drafts/draft-eastlake-ip-mime-03.txt. For once people could spend some time reading the security considerations. Cheers, Magnus
Re: THe Value Of Following Standards... (was Re: VIRUS WARNING)
From: [EMAIL PROTECTED] Subject: THe Value Of Following Standards... (was Re: VIRUS WARNING) Date: Thu, 04 May 2000 10:46:33 -0400 On Thu, 04 May 2000 09:27:19 EDT, Scot Mc Pherson [EMAIL PROTECTED] said: The is an e-mail virus going around. The subject of the e-mail is ILOVEYOU...I suggest you delete it the moment you receive it. Somebody didn't read RFC2046, section 2, where it talks about text/plain being *TEXT*, and application/* being *application data*. So if your e-mail software is opening it and feeding it to Visual Basic just because it's tagged .vbs even though it's a text/plain, you're violating the RFCs. I'm not pointing fingers, but ;) You are missing the point here, this is user friendliness, the user is allowed to do whatever he/she wants, even in others equipment with others data. ;) It does make box managment so much easier ;) Cheers, Magnus
Re: recommendation against publication of draft-cerpa-necp-02.txt
From: Vernon Schryver [EMAIL PROTECTED] Subject: Re: recommendation against publication of draft-cerpa-necp-02.txt Date: Mon, 10 Apr 2000 10:41:43 -0600 (MDT) From: Jon Crowcroft [EMAIL PROTECTED] ... its the 21st century: f you dont use end2end crypto, then you gotta expect people to optimize their resources to give you the best service money can buy for the least they have to spend. ... That's an interesting idea. People might eventually finally start using end2end crpyto not for privacy or authnetication where they really care about either, but for performance and correctness, to defend against the ISP's who find it cheaper to give you the front page of last week's newspaper instead of today's. Maybe this is a reason for these ISPs to filter such traffic out... Cheers, Magnus
