Re: Why people by NATs
As the maintainer of the Linksys Blue Box Router HOWTO, I am quite well aware of this fact. And if my objective were to have exciting adventures in system and network administration, I would have reflashed my Linksys long since. I don't want to have exciting adventures in system and network administration. I want my home network to just freaking *work* so I can concentrate on the problems where my time is most valuable. Hmmm ... I'm quite happy with the stability of my sveasoft code and find that staying up with their latest releases is pretty trivial and keeps my box humming just fine. What I found exciting about being able to reflash my linksys is that I could have a real router (sort of), *not* have to be an expert, and it *works*! No more difficult than clicking on the software update button periodically. Just one user's experience ... your horror stories may vary. Regards, Carl ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
Re: IASA BCP Section 5.3
scott bradner wrote: bert goes on to ask OTOH if ISOC received an unexpected donation for IETF purposes, that should be transferred promptly - does this need to be stated somewhere? I would assume, that if such a donations was indeed for IETF purposes that it would then be earmarked as such or be a designated donation, and so section 5.2 covers that case and moves it directly into the IASA (bank) account. Is that suffiecient, or are you looking for other/more text? see previous posting re a bank account it seems to eb that the concept of a designated donation and earmarking it for the IETF (only) should be enough For me the key word is promptly whether the credit is to an internal ISOC account or to a real bank account, which is a separate issue. My point is to ensure that it's IASA's cash flow that benefits. Brian ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
Re: AdminRest: IASA BCP: do we need dedicated IASA (bank) accounts
Geoff Huston wrote: At 12:15 AM 27/11/2004, Wijnen, Bert (Bert) wrote: In revision draft-ietf-iasa-bcp-00.txt we have text in sections 5 through 5.4 about IASA funding and where the money needs to be kept. Specifically, the current text suggests that there is/are one or more IASA specific bank accounts. Namely: - Sect 5.1 says that meeting revenues go into IASA account. When I wrote that text I meant IASA bank account, so if that is what we (IETF) want, then needs to be made more explicit. - Sect 5.2 says that designated monitary donations go to the IASA account. Again, I meant to write IASA bank account. So need clarification if that is what we (IETF) want. - Sect 5.3 I think (I/we) intended (but is not explicit) to also have the quarterly deposits go into IASA bank account. So again needs clarification if that is what we (IETF) want. - Sect 5.4 talks about reserve fund being kept in reserve for use by IASA. It is not specific how this is done. Current text leaves that up to ISOC to decide/arrange. We have seen a few people raise concern about the above. Concerns that I have seen raised and to which I would like to see the IETF community speak their preference: - should we (IETF) indeed have/request an IASA specific bank account... No, in all cases. I think that an internal account within ISOC's accounting system is necessary and sufficient. Although I am keen that ISOC should not use IETF cash to solve hypothetical future cash flow problems, I think it would be self-inflicted pain to operate legally separate bank accounts. But in the end it's an accounting detail that we probably shouldn't even specify in the BCP. Brian ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
Another document series?
Folks - I've recently been asked to review a number of works in progress related to restructuring and other similar things. Those documents were liberally splattered with references to various IDs (http://www.ietf.org/internet-drafts/draft-ietf-newtrk-cruft-00.txt, http://www.ietf.org/internet-drafts/draft-ietf-newtrk-repurposing-isd-00.txt, http://www.ietf.org/internet-drafts/draft-wasserman-iasa-bcp-01.txt etc). Its unclear that either the work in progress or the cited drafts will ever be published as RFCs. Its also unclear that this (restructuring etc) will be resolved within the 6 month lifetime of any given ID. Its also unclear that we can afford to either have these expire, or continually resubmit them. And finally, we NEED to have this set of documents as permanent archivable documents to maintain the historical record. It seems to me that neither ID status nor RFC status are appropriate for these documents. The ID series is, by design, ephemeral and generally not citeable. The RFC series is stable and citeable, but the lead time for introducing an RFC is somewhat north of 30 days or more. I hate to open Pandora's box, but what I think we need is a citable, stable document series that has a production lead time similar to that of the IDs. I would probably limit this to the non-technical administrivia we've been recently inundated with. *sigh* Mike ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
Re: Another document series?
Michael == Michael StJohns [EMAIL PROTECTED] writes: Michael It seems to me that neither ID status nor RFC status are Michael appropriate for these documents. The ID series is, by Michael design, ephemeral and generally not citeable. The RFC Michael series is stable and citeable, but the lead time for Michael introducing an RFC is somewhat north of 30 days or more. Michael I hate to open Pandora's box, but what I think we need is Michael a citable, stable document series that has a production Michael lead time similar to that of the IDs. I would probably Michael limit this to the non-technical administrivia we've been Michael recently inundated with. Michael *sigh* Please provide some justification. You said that you needed these things but you didn't really say why. I also don't understand how this is any different than work that goes on in a lot of protocol working groups. I'm particularly confused about why we would have documents that we neither want to be long-lived but that we cannot be bothered to resubmit every six months. If we want the document to be long-lived, what is wrong with RFC publication? ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
Re: Another document series?
--On tirsdag, november 30, 2004 12:13:41 -0500 Michael StJohns [EMAIL PROTECTED] wrote: Folks - I've recently been asked to review a number of works in progress related to restructuring and other similar things. Those documents were liberally splattered with references to various IDs (http://www.ietf.org/internet-drafts/draft-ietf-newtrk-cruft-00.txt, http://www.ietf.org/internet-drafts/draft-ietf-newtrk-repurposing-isd-00. txt, http://www.ietf.org/internet-drafts/draft-wasserman-iasa-bcp-01.txt etc). Its unclear that either the work in progress or the cited drafts will ever be published as RFCs. The answer is yes-if-successful, yes-if-consensus, yes-with-namechange for those three particular documents. Not much different from the I-Ds of any given working group. Its also unclear that this (restructuring etc) will be resolved within the 6 month lifetime of any given ID. Its also unclear that we can afford to either have these expire, or continually resubmit them. And finally, we NEED to have this set of documents as permanent archivable documents to maintain the historical record. Query: What purpose do you see the historical record as having? I'm serious - visibility to serious historians, historical sunshine law and armoury for lawyers in court cases are very different things to design for. It seems to me that neither ID status nor RFC status are appropriate for these documents. The ID series is, by design, ephemeral and generally not citeable. The RFC series is stable and citeable, but the lead time for introducing an RFC is somewhat north of 30 days or more. Optimist the current queue time (approval to publication) is closer to 4 months for IETF standards track. The effort at speeding up the IESG approval process has had ripple effects :-( (that's why the RFC Editor's 2006 budget shows a hefty increase, btw...) I hate to open Pandora's box, but what I think we need is a citable, stable document series that has a production lead time similar to that of the IDs. I would probably limit this to the non-technical administrivia we've been recently inundated with. Unfortunately, almost the same arguments can be made for anything that has received serious attention in the I-D series. See the NEWTRK discussion about working group snapshot. Harald ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
Re: Another document series?
At 12:49 PM 11/30/2004, Sam Hartman wrote: Michael == Michael StJohns [EMAIL PROTECTED] writes: Michael It seems to me that neither ID status nor RFC status are Michael appropriate for these documents. The ID series is, by Michael design, ephemeral and generally not citeable. The RFC Michael series is stable and citeable, but the lead time for Michael introducing an RFC is somewhat north of 30 days or more. Michael I hate to open Pandora's box, but what I think we need is Michael a citable, stable document series that has a production Michael lead time similar to that of the IDs. I would probably Michael limit this to the non-technical administrivia we've been Michael recently inundated with. Michael *sigh* Please provide some justification. You said that you needed these things but you didn't really say why. I tend to disagree with you that I didn't say why, but here's some more: Pick any one of a number of the current documents related to restructuring. Do a topological sort on the publication dependencies. (E.g. stable references for RFCs can't be IDs). Now figure out whether this entire set of IDs will make it to RFC status. Further, figure the amount of bureaucratic cruft that will have to happen to bring this set to RFC status with the concomitant allocation of scarce resources. The various restructuring documents that have been published as IDs tend to have a history that's important. RFCs are published at a single point (the end point) in the life of an ID. In this discussion, and in others, its important to know where we started, where we were along the way and where we ended up. Sometimes that's embodied as a single document history, sometimes as a set of revisions to a document, and sometimes as a series of documents with different names, but parented by the same ideas. The ID series can't track this in the manner it needs to be tracked due to its current ephemeral nature. I also don't understand how this is any different than work that goes on in a lot of protocol working groups. Because in the protocol working groups, its the end product that is most important because that's what gets published as the RFC. The IDs CAN be discarded at the end of the process because they become irrelevant. RFCs are edited to a fare-thee-well - IDs are not. We need something stable like an RFC that doesn't require the resource allocation of an RFC to get published. Finally, the documents in the restructuring set are mostly individual or small group efforts, individual opinion rather than a group consensus of a WG. The changes to those documents over time (e.g. the -01 -02 etc) tend not to be changes in meaning, but refinements of the original thesis. Protocol RFCs reflect group consensus and tend to change somewhat drastically from initial idea to final publication. (Broad generalization which tends to be more true than not - there are exceptions). I'm particularly confused about why we would have documents that we neither want to be long-lived but that we cannot be bothered to resubmit every six months. If we want the document to be long-lived, what is wrong with RFC publication? I want document A to be long lived, but I don't want to wait the 4 months (see Harald's note) to have it see the light of day because the discussions on A have to take place now. That assumes that A can be published direct from creation, which isn't the case in the IETF. Instead A has to be published as an ID first, before it can be published as an RFC. Someone else comes along with document B that cites A. B depends heavily on A. And C and D and E. B becomes very important and makes it to the point where we want to turn it into an RFC, in the mean time authors of A, C, D and E have dropped out of the process through sheer fatigue and decline to push their documents to RFC status. Does B get published as an RFC by removing the cites for A, C, D and E or does some overworked volunteer pick up A, C, D and E to edit them? What happens if the various authors decline permission to take these drafts forward? This isn't as much of a problem in the protocol work side of things, but the web of documents so far on the restructuring is much broader than anything I can remember seeing for any of the work products of any of the WGs. ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
Re: Another document series?
Mike, As the other co-author to http://www.ietf.org/internet-drafts/draft-ietf-newtrk-cruft-00.txt, [...]Its unclear that either the work in progress or the cited drafts will ever be published as RFCs. Its also unclear that this (restructuring etc) will be resolved within the 6 month lifetime of any given ID. Its also unclear that we can afford to either have these expire, or continually resubmit them. And finally, we NEED to have this set of documents as permanent archivable documents to maintain the historical record. I think the current cruft draft is best suited only as an I-D. We are right now conducting a cruft experiment. It is quite possible -- in fact darn near certain -- that we will need to update that draft based on the experiences of the old-standards mailing list, making the current draft, well, cruft. Depending on the results of the experiment I think the WG could produce either an update to RFC 2026/3667/ or an informational RFC. Why is this not sufficient? What is it you want to capture? Eliot ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
Re: AdminRest: IASA BCP: do we need dedicated IASA (bank) accounts
Sorry, in this I must disagree. We are in an international situation and we want simple to read for everyone, crystal clear statements in due time by third party. The only certified situation reports we have in case of conflict is a neat banking monthly statement. Another complex issue where an ISOC account would actually _cost_ is currency management as a substantial amount of the IETF resources is probably wasted in USD conversion by non American Members. The IETF banking account should be opened in a country supporting multicurrency accounts to benefit from lowest conversion costs. Why to waste money in converting and keeping euro as dollars? jfc At 16:58 30/11/2004, Brian E Carpenter wrote: Geoff Huston wrote: At 12:15 AM 27/11/2004, Wijnen, Bert (Bert) wrote: In revision draft-ietf-iasa-bcp-00.txt we have text in sections 5 through 5.4 about IASA funding and where the money needs to be kept. Specifically, the current text suggests that there is/are one or more IASA specific bank accounts. Namely: - Sect 5.1 says that meeting revenues go into IASA account. When I wrote that text I meant IASA bank account, so if that is what we (IETF) want, then needs to be made more explicit. - Sect 5.2 says that designated monitary donations go to the IASA account. Again, I meant to write IASA bank account. So need clarification if that is what we (IETF) want. - Sect 5.3 I think (I/we) intended (but is not explicit) to also have the quarterly deposits go into IASA bank account. So again needs clarification if that is what we (IETF) want. - Sect 5.4 talks about reserve fund being kept in reserve for use by IASA. It is not specific how this is done. Current text leaves that up to ISOC to decide/arrange. We have seen a few people raise concern about the above. Concerns that I have seen raised and to which I would like to see the IETF community speak their preference: - should we (IETF) indeed have/request an IASA specific bank account... No, in all cases. I think that an internal account within ISOC's accounting system is necessary and sufficient. Although I am keen that ISOC should not use IETF cash to solve hypothetical future cash flow problems, I think it would be self-inflicted pain to operate legally separate bank accounts. But in the end it's an accounting detail that we probably shouldn't even specify in the BCP. Brian ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
Re: Why people by NATs
Thus spake Iljitsch van Beijnum [EMAIL PROTECTED] Actually in IPv6 you are well-protected against random scanning withough the need for any device in the middle: a /64 subnet is so large, that scanning it is completely infeasible. Now of course someone who knows your address doesn't have to scan, so this protection isn't complete. But for TCP it's entirely trivial to only allow sessions to be set up in one direction. Full stateful firewalling is of course also possible. However, both these options bring back some of the downsides of NAT: in order to make incoming sessions possible, there must be configuration of some sort. IMHO a firewall function, probably stateful, is necessary in nearly all cases. However, this has gotten so mixed up with NAT that many people (even at vendors) don't realize they're different things. With v6 we have the ability to fix this; through some magic function, users should be able to get a PA (at a minimum) subnet behind their local router/modem/whatever and have a decent interface to configure inbound filters, similar to how they can configure evil NAT port-forwarding today. A default filter that rejects packets for services that are generally intended for local use only would probably be good enough for a residential IPv6 router. Other services are either not enabled and/or firewalled in the host anyway, or the user actually wants them to work. (It would be incredible helpful to have all these local-use services in a fixed range of port numbers for easy filtering...) Default filters are a pain, because inevitably they end up blocking something that's useless today but a critical need tomorrow... For instance, my @#%#^ Linksys not only doesn't understand native IPv6 (hello, wake up Cisco!) but it even blocks IP-in-IP packets so I can't use an IPv6 tunnel. At a minimum, vendors should document _everything_ the default filter does and allow the user to disable it if necessary. You don't need to load the gun for them, but if someone wants to shoot themselves in the foot, it's not your duty to prevent them, because they might have a perfectly good reason to. S Stephen Sprunk God does not play dice. --Albert Einstein CCIE #3723 God is an inveterate gambler, and He throws the K5SSSdice at every possible opportunity. --Stephen Hawking ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
Re: Why people by NATs
Thus spake Tim Chown [EMAIL PROTECTED] I didn't say that your mother could do this, but given that some amateurs have already modified the Linksys to do v6 then it would not be difficult for Cisco/Linksys to do so in a short timeframe, if they chose to. The interesting question is why Cisco/Linksys has not done so yet. IMHO, this is the single biggest _logistical_ barrier to IPv6 deployment. As for NAT, then v4+NAT dual-stack IPv6 will be very common. I'd be perfectly happy to run IPv6 on my home network, and let my Linksys do 6-to-4 NAT, real 6to4, IPv6 tunnels, etc. as appropriate. Of course, if my monopoly broadband provider were to wake up and offer native IPv6, I'd want real IPv6 connectivity... S Stephen Sprunk God does not play dice. --Albert Einstein CCIE #3723 God is an inveterate gambler, and He throws the K5SSSdice at every possible opportunity. --Stephen Hawking ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
