Re: IETF63 wireless
On Sun, Mar 13, 2005 at 01:47:05PM -0800, Ole Jacobsen wrote: Simply saying that a network which is built by volunteers (or by anyone else for that matter) MUST be reliable is just naive. It's a bit like saying operating systems and other software must be bug free. Keep in mind that the people who spend their time doing this have lots of experience, but they, and by extension we the IETF, learn new lessons every time. That can't be a bad thing. Given each IETF has 1200-ish delegates, paying $500US, there is $600K dollars to hand for IETF. How about removing some of those ghastly fattening breakfast/break pastries and replacing them with the more basic breads that always disappear first in the morning, and using the savings towards wireless? :) [Getting a healthy breakfast/snack in the IETF corridors is a separate thread...:] The wireless is something we will have a growing dependency on; there were many sessions that had no jabber log due to the failing network, nor could attendees in the room see comments from remote participants/friends. Tim ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: IETF63 wireless
On Sun, Mar 13, 2005 at 05:02:00PM -0500, John C Klensin wrote: It is precisely the style of thinking, and not the specifics, that I was trying to suggest and illustrate. Indeed; there seems to be some 'smart' Alcatel software that is doing some ARP/DHCP trickery (at least the APs are Alcatel, so the favourite for the s/w is the same vendor...). Note that my problem all week was getting dis-associated from WLAN a few times each hour, then seeing a long, if not indefinite, wait to get a v4 address once re-associated. And when I was associated RTTs to the default router of commonly 1000ms. We have had many IETFs with more attendees that have had excellent WLAN. We need to understand why - documenting past experience - good or bad - has to only be helpful. Tim ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: IETF63 wireless
Tim, I was trying to say that: - Wireless 802.11 is an emerging technology (read not fully cooked yet) - Wireless 802.11 is a wireless (read radio) technology subject to complex patterns of interference and station interactions (station includes both basestations and clients) So, it is not clear that throwing extra money at the problem would help, unless we use it to redesign hotels and convention centers, creating a series of carefully interconnected Faraday Cages. Remember that each and every location has its own set of radio characteristics. PS: I suspect the food will not be a problem in Paris. I've never managed to find bad food there outside of those American restaurants :-) Ole Ole J. Jacobsen Editor and Publisher, The Internet Protocol Journal Academic Research and Technology Initiatives, Cisco Systems Tel: +1 408-527-8972 GSM: +1 415-370-4628 E-mail: [EMAIL PROTECTED] URL: http://www.cisco.com/ipj On Mon, 14 Mar 2005, Tim Chown wrote: On Sun, Mar 13, 2005 at 01:47:05PM -0800, Ole Jacobsen wrote: Simply saying that a network which is built by volunteers (or by anyone else for that matter) MUST be reliable is just naive. It's a bit like saying operating systems and other software must be bug free. Keep in mind that the people who spend their time doing this have lots of experience, but they, and by extension we the IETF, learn new lessons every time. That can't be a bad thing. Given each IETF has 1200-ish delegates, paying $500US, there is $600K dollars to hand for IETF. How about removing some of those ghastly fattening breakfast/break pastries and replacing them with the more basic breads that always disappear first in the morning, and using the savings towards wireless? :) [Getting a healthy breakfast/snack in the IETF corridors is a separate thread...:] The wireless is something we will have a growing dependency on; there were many sessions that had no jabber log due to the failing network, nor could attendees in the room see comments from remote participants/friends. Tim ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: RFC - 2229 / Dictionary Server Protocol
Baker Fred wrote: I have some bed-time reading for you Thanks, excl. the new 3978/3979 I had read these texts. Looking again into 2026 I'm still not sure how Gaurav could handle this if the authors don't answer. And if the inventors of IsNot also invented dict he might need a lawyer _before_ publishing any I-D. Bye, Frank ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Introduction to ATP
Here ATP stands for Asymmetric Transport Protocol (somewhat for historical reason), not Appletalk Transaction Protocol. Welcome to http://atp.ebloggy.com/ to add comment. Known problems: Lack of references section; Lack of elliptic curve parameter definition; and much more:) Briefly: ATP aims to provide mobility and multi-home support in transport layer. But why not patching TCP, extending SCTP, or exploiting HIP? The answer is that when taking account of syndicate effect, it is more efficient to use ATP. Patching TCP software to support mobility and multi-home is not difficult. But widely deploying the new TCP implementation may be an enduring work. SCTP supports multi-home, and it is quite easy to extend it to support mobility. But as SCTP is already quite heavy weighted, and its congestion control mechanism arguably suffers same trouble as TCP, it is difficulty to persuade mass users to accept SCTP. HIP decouples identity and locator role of IP address by adding a new layer. It is quite exquisite. But unfortunately to add a new layer is to add a new, non-trivial trouble of reliability. The name of Asymmetric Transport Protocol is somewhat historical. ATP takes advantages of asymmetric cryptography (and asymmetry of communication). It is designed to be an alternate of transport layer protocols, alongside of TCP and UDP [RFC768]. ATP aims to ² Decouple locator and identity role of network layer address by keep it from taking part in transport layer identity and/or address. ² Support mobility ² Support multi-home ² Facilitate high performance parallel communication ² Facilitate high efficiency transactional communication ² Provide transport encryption service ² Provide some QoS service ² Keep simple ATP supports mobility and multi-home by decoupling locator and identity role of network layer address with connection key. There are three connection modes in ATP: fast-mode, normal mode and encrypted transport mode. In the host environment, each ATP connection is uniquely associated with a 64-bit connection key. In the context of each normal mode ATP connection, there is a shared secret. The shared secret is established in Elliptic Curve Diffie-Hellman [ECC] key agreement process when the connection is set up. ATP endpoint seals every ATP packet with Integrity/Identity Check Code (ICC). In normal mode ICC is calculated by applying HMAC-SHA1 [RFC2104] [RFC3174] on the ATP packet header with the shared secret as the key. As far as only the connected peers know both the connection key and the shared secret, integrity of the ATP packet header and identity of the ATP packet source are secured by ICC. In fast mode, ATP endpoints do not establish a shared secret, and agree on the connection key only. The 64-bit connection key solely acts the identity check role. ICC is a CCITT-CRC-16 code [CRC] that weakly protects packet integrity. In encrypted transport mode ATP endpoints use AES-IV-SHA1-80 algorithm to protect privacy of the payload, integrity of the full packet, and identity of the packet source. AES-IV-SHA1-80 algorithm is integration of AES [FIPS-197] and SHA1-80 [RFC3174]. AES encryption key is installed by the upper layer application (ULA), or derived from the shared secret on request of ULA; 64-bit initial vector is the low-order 64-bit part of the result of applying SHA1-80 on the ATP packet header. High-order 16 bits are exploited for preliminary integrity check. Encrypted transport mode is not only a feature of mobility and multi-home but a simple and useful feature of security as well. Mobility support is further reinforced by the feature of re-locating via courier. ATP supports high performance, high efficiency parallel and/or transactional communication with connection clone and auto-reconnect features. ATP also features First-In-First-Deplete traffic class, in addition to traditional best-effort traffic class. ATP DOES NOT provide reliable multicast support, nor does it do full-fledged congestion control. However, ATP does have cooperative congestion control feature. We assume that ² Mobility context is L4-comfortable. That is, frequency of IP address change is limited so that the IP addresses of two endpoints remain stable as long as they are negotiating a connection. ² Ownership of upper layer application over connection key is secure. ² Upper Layer Application is willing and able to defense against man-in-the-middle attack. ² Acceptable information asymmetry. One participant in communication, the responder, is willing to and able to make the other participant, the initiator, know the rendezvous key, but not necessarily vice versa. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Why?
Michel Py wrote: Terry Gray wrote: Keith, Quick note from the peanut gallery: I believe your vision is only achievable if the address allocation policies for v6 are such that every man/woman/child and enterprise can obtain an ample amount of provider-independent v6 space (or some number of address bits that the enterprise can *own*). If people feel like they are held hostage to others for the operation of their internal enterprise (or home!) networks, you can take it to the bank that v6 NAT will become just as pervasive and entrenched as v4 NAT is. This is precisely why I have stated earlier that v6 NAT is unavoidable: 'every man/woman/child and enterprise can obtain an ample amount of provider-independent v6 space' Catch is we don't know how to make this scalable. We have tried for 10 years and we still don't. Well, we could continue to rehearse these arguments for a while longer. (Don't want to insult anybody, but I haven't seen anything in this thread that I haven't seen many times before, including the absence of scalable routing for PI space.) Alternatively, people could contribute constructively to relevant IETF activities - behave, which is trying to codify NAT behavior such that NAT would become easier to deal with when we *have* to deal with it - v6ops, and specifically draft-vandevelde-v6ops-nap-01.txt*, which is trying to show how to deploy IPv6 without any need for NAT - shim6, which will define how to solve at least one of the problems in this area *truth in advertising: I am a co-author of this draft. Brian ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: RFC - 2229 / Dictionary Server Protocol
Looking again into 2026 I'm still not sure how Gaurav could handle this if the authors don't answer. And if From 2229 (C) statement: quote However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. /quote I think the authors have given permissions to modify it so that it can be updated for developing Internet standards -- which, IMO, gives me permissions - without requiring an explicit one from the authors - to go ahead. the inventors of IsNot also invented dict he might need a lawyer _before_ publishing any I-D. Bye, Frank Can I create my own Dict-Serv protocol? As a matter of fact, I thought about DictServ protocol sitting on my laptop and doing some work... after doing a lot work, it just came to my mind to see if anything exists. RFC was the last thing on my mind and the first response from Google. I was looking to SOAP-implementations and that's why you'd also see a mention of XML in the response formats. Or instead... I'd then go to W3C and ask for a standard SOAP-data-exchange-format for dictionary. However, it will be in SOAP (over HTTP to start with). -- Cheers, Gaurav Vaish http://www.mastergaurav.org http://mastergaurav.blogspot.com ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
What? No PPT or wireless? [Re: IETF63 wireless]
Keith Moore wrote: ... actually I haven't attended an IETF meeting in the past several years where I didn't get the impression that we'd be much more effective at getting work done _without_ wireless access. large rooms that are full of people sitting down typing on laptops and not paying attention to what is being said are not conducive to getting work done - even among the people who are paying attention. it further exacerbates the phenomenon where meetings consist of highly scripted presentations rather than discussion time. most people don't pay attention to the presentations because the information content is so low, so they use their laptops to keep them occupied. if we could get rid of wireless and powerpoint, we'd be much better off. Personal opinion: disagree. Wireless is immensely useful to grab a document, check something on another SDO's web site, and - yes - for instant messaging (e.g. we need you in here right now). And some people simply have to multitask in order to be able to attend IETF meetings in the first place. The jabber scribing has become very important for remote participants - this time we even had one Area Director who was partcipating actively by jabber (and audio streaming). The wireless glitches that interrupted jabber were a real problem this time. As for presentations, the fact that they vary in quality can't be blamed on PPT. It should be blamed on the presenters, perhaps. Brian ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: RFC - 2229 / Dictionary Server Protocol
Or instead... I'd then go to W3C and ask for a standard And I just forgot how costly it is to be a member of W3C :D -- Cheers, Gaurav Vaish http://www.mastergaurav.org http://mastergaurav.blogspot.com ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: What? No PPT or wireless? [Re: IETF63 wireless]
On Mon, 14 Mar 2005, Brian E Carpenter wrote: Keith Moore wrote: ... if we could get rid of wireless and powerpoint, we'd be much better off. meetings in the first place. The jabber scribing has become very important for remote participants - this time we even had one Area The IETF Meeting crew should look at supplying an additional 3 ethernet and power drops per room, labelled 'chair', 'presenter' and '(jabber) scribe' with the expectation that they be used accordingly. These functions, IMHO, are too important to leave to the possible failures/overloads of the wireless or laptop battery life. ( Actually, I'm surprised that these are either not there or are not advertised already; it really reduces the number of complaints about 'the wireless failed in the middle of my presentation' ) -- Bruce CampbellRIPE Systems/Network Engineer NCC www.ripe.net - PGP562C8B1B ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: What? No PPT or wireless? [Re: IETF63 wireless]
The IETF Meeting crew should look at supplying an additional 3 ethernet and power drops per room, labelled 'chair', 'presenter' and '(jabber) scribe' with the expectation that they be used accordingly. These functions, IMHO, are too important to leave to the possible failures/overloads of the wireless or laptop battery life. Power has, in my experience, always been available to the chair presenter, but I agree that Ethernet drops as a backstop against wireless problems is a good idea. Stewart ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: [e2e] Introduction to ATP
Jason Gao wrote: Here ATP stands for Asymmetric Transport Protocol (somewhat for historical reason), not Appletalk Transaction Protocol. Welcome to http://atp.ebloggy.com/ to add comment. Is there a paper on it? The web page and your email don't have details. -- Lars Eggert NEC Network Laboratories smime.p7s Description: S/MIME Cryptographic Signature ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: FW: Why?
inline Tom Petch From: Kevin Loch [EMAIL PROTECTED] Cc: nanog@merit.edu; ietf@ietf.org Sent: Friday, March 11, 2005 10:09 PM Subject: Re: FW: Why? As you know, the value of a network is roughly proportional to the square of the participants. The value of a network can depend on what is on it, not how many or who. One useful (http/ftp/...) server can make a network worth accessing, worth paying for. Even if there was noone else on this Internet, even if I never wanted to e-mail anyone or anything, there are servers worth paying to access. I saw the Internet explode in the 1990s because of web servers, not because n**2 people could now talk to each other, so I think this a general point.. By contrast, IPv6, like 3G mobile, has nothing worth getting access to; they are just bits of technology with no applications worth accessing. Have a look at models of the adoption of technology. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: What? No PPT or wireless? [Re: IETF63 wireless]
if we could get rid of wireless and powerpoint, we'd be much better off. Personal opinion: disagree. Wireless is immensely useful to grab a document, check something on another SDO's web site, and - yes - for instant messaging (e.g. we need you in here right now). And some people simply have to multitask in order to be able to attend IETF meetings in the first place. The jabber scribing has become very important for remote participants - this time we even had one Area Director who was partcipating actively by jabber (and audio streaming). The wireless glitches that interrupted jabber were a real problem this time. yes, yes, and yes. but in many meetings it's hard to escape the impression that most of the people in the room aren't really paying more than say 10% of their attention to the meeting. As for presentations, the fact that they vary in quality can't be blamed on PPT. It should be blamed on the presenters, perhaps. not on PPT as opposed to any of the other similar tools that exist for that purpose. but there's something about that medium that seems to encourage poor presentations - slides consisting of a small amount of text (because of the low resolution of the medium) rather than drawings (because it's easier to type in text on a keyboard than it is to draw drawings with a mouse or trackpad). even with the old-style transparencies you could get more readable information on a page, and you could draw on them in real time. and yet even this is beside the point. maybe this is age setting in, but it seems to me we used to get a lot more work done when we used our meetings primarily for discussion rather than scheduling presentations for most or all of the meeting time. these days some IETF WG meetings remind me of Apple's 1984 commercial...except that there's nobody to throw a hammer through the screen. one benefit of our somewhat reduced attendance should be that we can get more work done by reverting to a more effective meeting style. (or maybe our reduced attendance can be attributed to a widespread realization that we're not getting much work done in these meetings?) Keith ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: RFC - 2229 / Dictionary Server Protocol
Date: 2005-03-14 04:24 From: Frank Ellermann [EMAIL PROTECTED] Looking again into 2026 I'm still not sure how Gaurav could handle this if the authors don't answer. Anybody can write an Internet-Draft (getting IETF community consensus is another matter). In the case of a revision of a document created by others, it would be appropriate to acknowledge the contribution of the original authors in a Contributors or Acknowledgments section. Regarding mechanics of an update, if one is at all familiar with troff/nroff/groff, see RFC 2223 and draft-lilly-using-troff (update expected imminently). Cutting and pasting from the original RFC (ignore boilerplate and TOC) or editing a copy of the original to remove boilerplate and TOC and to add directives should take no more than 45 minutes for a novice, less than half that for an experienced person. Then come the difficult parts: the EBNF in the original has to be converted (manually) to ABNF you'll need a good understanding of the intent of the original EBNF and a working knowledge of RFC 2234 as amended by errata (http://www.rfc-editor.org/cgi-bin/errata.pl) references need to be updated (see the rfc-ref.txt document made available by the RFC Editor) and checked against the referring text -- references are supposed to be categorized as either normative or informative, so a decision needs to be made for each reference. You'll want to update the reference to RFC 1122 to 2119 (normative), for example. desired changes can be made (keep track of what is changed; the question will be asked -- put a list of changes in an Appendix to head off the question); make absolutely sure to pay careful attention to backwards compatibility (generation of new URIs should not be such that an existing (2229-based) parser will break or cause illegal content to be handed to some other protocol (in that respect, the mailto draft is the wrong document to use as a reference)) don't forget to include a suggestion for a discussion mailing list in the Abstract Then it gets easy again: format the document to generate text with up-to-date boilerplate, TOC, and references check with Henrik Levkowetz' idnits program, and revise until there are no nits (http://ietf.levkowetz.com/tools/idnits/) submit the formatted and checked text as an Internet-Draft as described in the guidelines (see http://www.ietf.org/ID.html) subscribe to the I-D-announce mailing list: when the draft is announced, notify the discussion mailing list (if the Secretariat didn't copy that list in the announcement) after a suitable discussion period (min. two weeks), revise the draft according to comments from the discussion and repeat to produce the next draft version when the draft is stable (no additional comments during discussion), ask the appropriate Area Director(s) (Applications Area, in this case) to submit the draft to the IESG for approval as an (Informational or Proposed Standard) RFC subscribe to the IETF-announce mailing list; if the IESG approves, a Last Call will be issued on the draft, with discussion taking place on the IETF discussion (that's this list) or IESG mailing lists -- Last Call for an individual submission runs a minimum of four weeks if there are substantive comments during Last Call, revise the draft again and repeat the cycle if/when the draft is stable and passes Last Call with no serious objections, the IESG may approve it as an RFC; then you work with the RFC Editor to generate a published RFC (should be quick and painless if you use groff and macros as mentioned above); there is a final (nominally) 48-hour author review where you're supposed to carefully review the document to ensure that everything is the way you want it if the IESG decided to publish as a Proposed Standard, you can then set about collecting information to proceed to Draft Standard (minimum of two independent and fully interoperable implementations need to be documented). ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re:Why?
This may be interesting if you want to take a look at models of adoption of technology. http://www.ist-ipv6.org/modules.php?op=modloadname=Newsfile=articlesid=62 9 Regards, Jordi De: Tom Petch [EMAIL PROTECTED] Responder a: Tom Petch [EMAIL PROTECTED] Fecha: Mon, 14 Mar 2005 10:46:40 +0100 Para: Kevin Loch [EMAIL PROTECTED] CC: ietf@ietf.org ietf@ietf.org Asunto: Re: FW: Why? inline Tom Petch From: Kevin Loch [EMAIL PROTECTED] Cc: nanog@merit.edu; ietf@ietf.org Sent: Friday, March 11, 2005 10:09 PM Subject: Re: FW: Why? As you know, the value of a network is roughly proportional to the square of the participants. The value of a network can depend on what is on it, not how many or who. One useful (http/ftp/...) server can make a network worth accessing, worth paying for. Even if there was noone else on this Internet, even if I never wanted to e-mail anyone or anything, there are servers worth paying to access. I saw the Internet explode in the 1990s because of web servers, not because n**2 people could now talk to each other, so I think this a general point.. By contrast, IPv6, like 3G mobile, has nothing worth getting access to; they are just bits of technology with no applications worth accessing. Have a look at models of the adoption of technology. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: What? No PPT or wireless? [Re: IETF63 wireless]
As for presentations, the fact that they vary in quality can't be blamed on PPT. It should be blamed on the presenters, perhaps. Brian Edward Tufte makes a very convincing case that in the case of powerpoint, the medium certainly influences the message: Summary of Tufte's views in Wired: http://www.wired.com/wired/archive/11.09/ppt2.html At a minimum, a presentation format should do no harm. Yet the PowerPoint style routinely disrupts, dominates, and trivializes content. Thus PowerPoint presentations too often resemble a school play - very loud, very slow, and very simple. Tufte's own site: http://www.edwardtufte.com/tufte/powerpoint (Worth checking out for the cartoon). Next slide please ... Regards, Carl ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: What? No PPT or wireless? [Re: IETF63 wireless]
On Mar 14 2005, at 14:07 Uhr, Keith Moore wrote: we used to get a lot more work done when we used our meetings primarily for discussion rather than scheduling presentations for most or all of the meeting time. Yes. WG chairs planning WG meetings, take note. But then, one difference is that a lot more stuff happens outside the WG meetings (e.g., on the mailing list) than ten years ago. People don't convene in one place to do original work but to decide on the fate of work that has been done elsewhere. Also, the things being worked on are simply way more complex than ten years ago. (The best WG meeting I ever attended was one where Tony Li hammered out most of the IP-over-firewire details in one session by asking the attending firewire experts all the right questions in one sitting. I'm still wowed for life. But you can't do this for something as complex as VPLS.) All that would explain a tendency to mainly do progress reports. This does not (fully) explain why we don't discuss things as much any more, however. Right now, if you need significant discussion in a WG, it seems you have to schedule an interim. Gruesse, Carsten ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: What? No PPT or wireless? [Re: IETF63 wireless]
On Monday, March 14, 2005, at 08:34 AM, Carl Malamud wrote: Edward Tufte makes a very convincing case that in the case of powerpoint, the medium certainly influences the message: The NY Times ran an article on PowerPoint and the deterioration of public speaking a few years ago, before Tufte started pointing out the problem, and the article had a photoshopped photograph of Martin Luther King standing in front of a projected slide. The slide heading was I Have a Dream, and the body of the slide was The dream consists of: and a bulleted list of items. However, while slides do tend to lead to a presentation-type meeting format, I think there are other factors substantially contributing to that, as well. Melinda ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: RFC - 2229 / Dictionary Server Protocol
I would add that the first step in such an effort should probably be to contact the appropriate IETF Area Directors for guidance and for the names of other people who might be interested in helping. This looks like Applications Area material to me. See http://www.ietf.org/html.charters/wg-dir.html#Applications%20Area Brian - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Brian E Carpenter IETF Chair Distinguished Engineer, Internet Standards Technology, IBM Bruce Lilly wrote: Date: 2005-03-14 04:24 From: Frank Ellermann [EMAIL PROTECTED] Looking again into 2026 I'm still not sure how Gaurav could handle this if the authors don't answer. Anybody can write an Internet-Draft (getting IETF community consensus is another matter). In the case of a revision of a document created by others, it would be appropriate to acknowledge the contribution of the original authors in a Contributors or Acknowledgments section. Regarding mechanics of an update, if one is at all familiar with troff/nroff/groff, see RFC 2223 and draft-lilly-using-troff (update expected imminently). Cutting and pasting from the original RFC (ignore boilerplate and TOC) or editing a copy of the original to remove boilerplate and TOC and to add directives should take no more than 45 minutes for a novice, less than half that for an experienced person. Then come the difficult parts: the EBNF in the original has to be converted (manually) to ABNF you'll need a good understanding of the intent of the original EBNF and a working knowledge of RFC 2234 as amended by errata (http://www.rfc-editor.org/cgi-bin/errata.pl) references need to be updated (see the rfc-ref.txt document made available by the RFC Editor) and checked against the referring text -- references are supposed to be categorized as either normative or informative, so a decision needs to be made for each reference. You'll want to update the reference to RFC 1122 to 2119 (normative), for example. desired changes can be made (keep track of what is changed; the question will be asked -- put a list of changes in an Appendix to head off the question); make absolutely sure to pay careful attention to backwards compatibility (generation of new URIs should not be such that an existing (2229-based) parser will break or cause illegal content to be handed to some other protocol (in that respect, the mailto draft is the wrong document to use as a reference)) don't forget to include a suggestion for a discussion mailing list in the Abstract Then it gets easy again: format the document to generate text with up-to-date boilerplate, TOC, and references check with Henrik Levkowetz' idnits program, and revise until there are no nits (http://ietf.levkowetz.com/tools/idnits/) submit the formatted and checked text as an Internet-Draft as described in the guidelines (see http://www.ietf.org/ID.html) subscribe to the I-D-announce mailing list: when the draft is announced, notify the discussion mailing list (if the Secretariat didn't copy that list in the announcement) after a suitable discussion period (min. two weeks), revise the draft according to comments from the discussion and repeat to produce the next draft version when the draft is stable (no additional comments during discussion), ask the appropriate Area Director(s) (Applications Area, in this case) to submit the draft to the IESG for approval as an (Informational or Proposed Standard) RFC subscribe to the IETF-announce mailing list; if the IESG approves, a Last Call will be issued on the draft, with discussion taking place on the IETF discussion (that's this list) or IESG mailing lists -- Last Call for an individual submission runs a minimum of four weeks if there are substantive comments during Last Call, revise the draft again and repeat the cycle if/when the draft is stable and passes Last Call with no serious objections, the IESG may approve it as an RFC; then you work with the RFC Editor to generate a published RFC (should be quick and painless if you use groff and macros as mentioned above); there is a final (nominally) 48-hour author review where you're supposed to carefully review the document to ensure that everything is the way you want it if the IESG decided to publish as a Proposed Standard, you can then set about collecting information to proceed to Draft Standard (minimum of two independent and fully interoperable implementations need to be documented). ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: What? No PPT or wireless? [Re: IETF63 wireless]
On Mon, 14 Mar 2005 08:07:05 -0500 Keith Moore moore@cs.utk.edu wrote: if we could get rid of wireless and powerpoint, we'd be much better off. Personal opinion: disagree. Wireless is immensely useful to grab a document, check something on another SDO's web site, and - yes - for instant messaging (e.g. we need you in here right now). And some people simply have to multitask in order to be able to attend IETF meetings in the first place. The jabber scribing has become very important for remote participants - this time we even had one Area Director who was partcipating actively by jabber (and audio streaming). The wireless glitches that interrupted jabber were a real problem this time. yes, yes, and yes. but in many meetings it's hard to escape the impression that most of the people in the room aren't really paying more than say 10% of their attention to the meeting. As for presentations, the fact that they vary in quality can't be blamed on PPT. It should be blamed on the presenters, perhaps. not on PPT as opposed to any of the other similar tools that exist for that purpose. but there's something about that medium that seems to encourage poor presentations - slides consisting of a small amount of text (because of the low resolution of the medium) rather than drawings (because it's easier to type in text on a keyboard than it is to draw drawings with a mouse or trackpad). even with the old-style transparencies you could get more readable information on a page, and you could draw on them in real time. Edward Tufte has some useful things to say about power point (alas, not free). http://www.edwardtufte.com/tufte/powerpoint http://www.wired.com/wired/archive/11.09/ppt2.html I personally think that it may be appropriate that most people are not paying attention much of the time. In some WG, you may only really care about 1 or 2 drafts, and not at all about the details of the editorial progress of some other draft. It seems to me that the best discussion happens when there is a review of some open issue; maybe that could be promoted as invited reviews by the chairs and given slots in the schedule. Of course the real work of any meeting happens in the corridor... Regards Marshall Eubanks and yet even this is beside the point. maybe this is age setting in, but it seems to me we used to get a lot more work done when we used our meetings primarily for discussion rather than scheduling presentations for most or all of the meeting time. these days some IETF WG meetings remind me of Apple's 1984 commercial...except that there's nobody to throw a hammer through the screen. one benefit of our somewhat reduced attendance should be that we can get more work done by reverting to a more effective meeting style. (or maybe our reduced attendance can be attributed to a widespread realization that we're not getting much work done in these meetings?) Keith ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: What? No PPT or wireless? [Re: IETF63 wireless]
I personally think that it may be appropriate that most people are not paying attention much of the time. In some WG, you may only really care about 1 or 2 drafts, and not at all about the details of the editorial progress of some other draft. Whenever I see a presentation about the editorial progress of some draft, I find myself wondering - does _anybody_ here need to be watching this? If someone has typed in this summary in PPT, couldn't it as easily be posted to the WG mailing list, or placed in the appendix of the I-D? Face to face time seems better used for interaction. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: IETF63 wireless
On Mon, 2005-03-14 at 03:10, Tim Chown wrote: Indeed; there seems to be some 'smart' Alcatel software that is doing some ARP/DHCP trickery (at least the APs are Alcatel, so the favourite for the s/w is the same vendor...). Note that my problem all week was getting dis-associated from WLAN a few times each hour, then seeing a long, if not indefinite, wait to get a v4 address once re-associated. And when I was associated RTTs to the default router of commonly 1000ms. Somehow I think that a few of the recommendations from the old IETF Meeting Network Infrastructure Lore document (as archived at http://www.ietf.org/meetings/draft-ymbk-termroom.txt) need to be remembered: 2.1 LAN Separation ... There MUST NOT be firewalls, NATs, or other end-to-end breakage between the public LAN(s) and the global internet. Assuming claims about what the 802.11 infrastructure was doing are correct, this provision was ignored and bad things happened. Stateful DHCP lease tracking was clearly causing more trouble than it's worth to the IETF network. 3.13 Advanced Technology While it is tempting for a host/vendor to show off fancy technology at an IETF, this audience runs and uses the most arcane assortment of services, and is a very poor place to find out that your fancy new switch breaks when someone tries to run IPv42 through it. Run a simple production network. If one must run a technology demo, isolate it onto a separate network segment so that it is unable to interfere with the production network. And maybe we need a new entry in: 3.14 Failed Technology Two attempts have been made to use ATM LAN Emulation, aka LANE, as the primary backbone protocol connecting all ethernet switches and routers at IETF meetings. Both attempts were disasters. Some have asserted that IETF traffic patterns are unusually unsuited to LANE. You MUST NOT try to use LANE. For the next couple of meetings, for 802.11b service we should go back to using conventional AP's connected via a conventional switched ethernet to a conventional dhcp server/relay and a conventional router or three. This, at least, would allow the folks running the network to reboot any and all components without forcing clients to reinitialize/rerun DHCP/etc. - Bill ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: What? No PPT or wireless? [Re: IETF63 wireless]
On Mon, 14 Mar 2005, Keith Moore wrote: Whenever I see a presentation about the editorial progress of some draft, I find myself wondering - does _anybody_ here need to be watching this? If someone has typed in this summary in PPT, couldn't it as easily be posted to the WG mailing list, or placed in the appendix of the I-D? Face to face time seems better used for interaction. From the top of my head, there are at least three kinds of presentations I see frequently at the IETFs: a) about 5 slides (or less) of background for the work, some major points, and maybe what has changed, on the last slide soliciting for input on certain specific topics, b) presentations where the document editor goes through all the open issues in the document (typically sent to the list beforehand, but no comments there), trying to use face-to-face time for discussion and gaining consensus on these items c) longer presentations which often result in focus getting lost. Do you see other kinds? Do you feel (at least) a) and b) are good use of our time? In any case, what I've seen in a dozen or two IETF presentations I made during the last year or so that people don't usually jump up and start discussing, unless you have a contentious topic or phrase the questions really well (in a contentiuous manner)? Or maybe it's just my bad presentations.. Maybe the audience is also not what it once used to be.. :) -- Pekka Savola You each name yourselves king, yet the Netcore Oykingdom bleeds. Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: What? No PPT or wireless? [Re: IETF63 wireless]
On Mon, 2005-03-14 at 06:26, Bruce Campbell wrote: The IETF Meeting crew should look at supplying an additional 3 ethernet and power drops per room, labelled 'chair', 'presenter' and '(jabber) scribe' with the expectation that they be used accordingly. Power was most assuredly not a problem at this IETF; the seating areas were amply provisioned. And since I've been a WG chair, with perhaps one exception, power at the chair's table has pretty much always been available. But, yes, two or three network drops at the front of the room would help in the event that the wireless network melts down. - Bill ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: What? No PPT or wireless? [Re: IETF63 wireless]
From the top of my head, there are at least three kinds of presentations I see frequently at the IETFs: a) about 5 slides (or less) of background for the work, some major points, and maybe what has changed, on the last slide soliciting for input on certain specific topics, b) presentations where the document editor goes through all the open issues in the document (typically sent to the list beforehand, but no comments there), trying to use face-to-face time for discussion and gaining consensus on these items c) longer presentations which often result in focus getting lost. Do you see other kinds? Do you feel (at least) a) and b) are good use of our time? I see a lot of those in category c), fewer in categories a) and b). I do feel that a) and b) are reasonable ways to use meeting time. In any case, what I've seen in a dozen or two IETF presentations I made during the last year or so that people don't usually jump up and start discussing, unless you have a contentious topic or phrase the questions really well (in a contentiuous manner)? Or maybe it's just my bad presentations.. There's something about the medium. Not just the use of PPT, but the setting ... a room with theater seating and the projection screen the most prominent feature. There is always something on the screen even if the information content is low. Some low-level noise from air conditioning or whatever. It all seems to encourage people to sit down, shut up, and watch the screen rather than to engage in dialogue. When the speaker speaks for more than a few minutes without any interaction with other attendees, that reinforces the one-way nature of the meeting. The need for those on the floor to use a microphone (not just in large rooms and multicast rooms now, but in _every_ room) further discourages interaction. (aren't there microphones these days that can pick up what is being said without being held next to the speaker's mouth?) ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: FW: Why?
inline. Tony Hain wrote: Joel M. Halpern wrote: This discussion seems to take as a premise the view that if we define applications only on IPv6, even though they could be defined on IPv4, that this will give people a reason to use IPv6. It also seems to take as a premise that if we don't define ways to work around NATs, people won't use the applications with NATs. I suffer from no such disillusions as those are not the premise for the initial note, though without having the background in the original note it is easy to see why someone might come to that conclusion. My assumption is that the market will not ignore the opportunity to develop NAT traversal technologies. That does not equate to a need for the IETF to waste valuable resources standardizing hacks that attempt to mask previous hacks. In particular the IAB needs to be looking forward and helping the application community understand that there are approaches today that allow them to ignore the nonsense that has grown in the network by using IPv6 tunneling as a NAT traversal tool. This approach completely avoids the need for complex and error prone ALGs. I agree that ALGs are not the answer, and I believe the reasons for that are treated in: http://www.ietf.org/internet-drafts/draft-iab-nat-traversal-considerations-00.txt As I mentioned during the plenary, the document above makes a case that the right answer in many situations are vpn-ish technologies that include v6 tunnels. However, different applications have different needs, and there are real differences between the various vpn-ish solutions (TURN, STUN, teredo, etc.) that are driving their development and adoption. For VoIP, where the nat traversal issue has been especially painful, the increase in voice latency, packet loss, and substantial cost increase of relaying traffic through the tunnel servers, has driven people to solutions like STUN. Thus, I cannot agree that there only needs to be a single solution here. That said, I agree that the IAB nat traversal consideration document lacks adequate consideration of how evolution plays into this, and I'll endeavor to improve the document on that front. Another concern I have is that, in an IPv6-only world, even if you eliminate NAT, there will still be firewalls, and those firewalls will frequently have the property that they block traffic coming from the outside to a particular IP/port on the inside unless an outbound packet has been generated from the inside from that IP/port. This means that IP addresses are not globally reachable. You'd still need most of the same solutions we have on the table today to deal with this problem. Indeed, in the VoIP space, I believe you'd need pretty much everything, excepting you'd be able to remove a single attribute from a few of the protocols (STUN and TURN in particular), which tell the endpoint its address on the other side of the NAT. The endpoint knows its address, but all of the protocol machinery is still needed to rendezvous with the other participant in the call. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Director, Service Provider VoIP Architecture Parsippany, NJ 07054-2711 Cisco Systems [EMAIL PROTECTED] FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: What? No PPT or wireless? [Re: IETF63 wireless]
Melinda Shore wrote: However, while slides do tend to lead to a presentation-type meeting format, I think there are other factors substantially contributing to that, as well. Yes. Another factor is the ratio of work items to meeting time. If there are 5-6 or even more items per a two-hour slot there isn't really that much time left for each one... and there's some constant overhead in every presentation to bring in the context. Chairs taking care of all status things in their document status report, minimizing unnecessary non-controversial things in presentations, etc. help this of course. Interim meetings, private meetings within a draft author group, etc. can help to increase the amount of available discussion time. So does cutting unneccessary work items, but that can be hard in a large group that is developing widely used technology with a lot of demand for new functions. And Pekka Savola wrote: a) about 5 slides (or less) of background for the work, some major points, and maybe what has changed, on the last slide soliciting for input on certain specific topics, b) presentations where the document editor goes through all the open issues in the document (typically sent to the list beforehand, but no comments there), trying to use face-to-face time for discussion and gaining consensus on these items These are good use of meeting time. Note that type b) presentations range from listing minor issues to major architectural questions. c) longer presentations which often result in focus getting lost. I did not quite see what the difference between c) and others were, except that c) was longer and the focus got lost. I'm not sure longer is necessarily bad, particularly if the issues in question are central to the WG. In my experience the main indicators of successful discussion are that it (1) there's some controversy or problem left so that it makes sense to have a presentation about it, and (2) the presenter and other participants have done enough preparation so that they have a reasonable chance of making progress on the issue. In any case, what I've seen in a dozen or two IETF presentations I made during the last year or so that people don't usually jump up and start discussing, unless you have a contentious topic or phrase the questions really well (in a contentiuous manner)? Or maybe it's just my bad presentations.. I have sensed this too. Not sure why. --Jari ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re:Why?
Regarding the firewalls and IPv6, I agree with your comment, but also there are some other reasons why that's bad, see: draft-vives-v6ops-ipv6-security-ps-03.txt and draft-palet-v6ops-ipv6security-02.txt Regards, Jordi De: Jonathan Rosenberg [EMAIL PROTECTED] Responder a: [EMAIL PROTECTED] Fecha: Mon, 14 Mar 2005 10:34:51 -0500 Para: Tony Hain [EMAIL PROTECTED] CC: ietf@ietf.org ietf@ietf.org Asunto: Re: FW: Why? inline. Tony Hain wrote: Joel M. Halpern wrote: This discussion seems to take as a premise the view that if we define applications only on IPv6, even though they could be defined on IPv4, that this will give people a reason to use IPv6. It also seems to take as a premise that if we don't define ways to work around NATs, people won't use the applications with NATs. I suffer from no such disillusions as those are not the premise for the initial note, though without having the background in the original note it is easy to see why someone might come to that conclusion. My assumption is that the market will not ignore the opportunity to develop NAT traversal technologies. That does not equate to a need for the IETF to waste valuable resources standardizing hacks that attempt to mask previous hacks. In particular the IAB needs to be looking forward and helping the application community understand that there are approaches today that allow them to ignore the nonsense that has grown in the network by using IPv6 tunneling as a NAT traversal tool. This approach completely avoids the need for complex and error prone ALGs. I agree that ALGs are not the answer, and I believe the reasons for that are treated in: http://www.ietf.org/internet-drafts/draft-iab-nat-traversal-considerations-00. txt As I mentioned during the plenary, the document above makes a case that the right answer in many situations are vpn-ish technologies that include v6 tunnels. However, different applications have different needs, and there are real differences between the various vpn-ish solutions (TURN, STUN, teredo, etc.) that are driving their development and adoption. For VoIP, where the nat traversal issue has been especially painful, the increase in voice latency, packet loss, and substantial cost increase of relaying traffic through the tunnel servers, has driven people to solutions like STUN. Thus, I cannot agree that there only needs to be a single solution here. That said, I agree that the IAB nat traversal consideration document lacks adequate consideration of how evolution plays into this, and I'll endeavor to improve the document on that front. Another concern I have is that, in an IPv6-only world, even if you eliminate NAT, there will still be firewalls, and those firewalls will frequently have the property that they block traffic coming from the outside to a particular IP/port on the inside unless an outbound packet has been generated from the inside from that IP/port. This means that IP addresses are not globally reachable. You'd still need most of the same solutions we have on the table today to deal with this problem. Indeed, in the VoIP space, I believe you'd need pretty much everything, excepting you'd be able to remove a single attribute from a few of the protocols (STUN and TURN in particular), which tell the endpoint its address on the other side of the NAT. The endpoint knows its address, but all of the protocol machinery is still needed to rendezvous with the other participant in the call. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Director, Service Provider VoIP Architecture Parsippany, NJ 07054-2711 Cisco Systems [EMAIL PROTECTED] FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: RFC - 2229 / Dictionary Server Protocol
Wooaah! Great to see your mail, Rik. [EMAIL PROTECTED] mailing list. This is the mailing list for the Another great to see. I wasn't able to find mail from you dated prior to yesterday (maybe the spam filters got it). Yikes. And there's something to hate the spam filters. ;-) composed of characters from the UCS character set [ISO10644] using the It seems I missed this point. It means, I have to implement one thing less. RFC 2229 also explains how to add experimental extensions to the I'm not sure what you mean by experimental extensions. They are extensions -- I'll forward my original mail to you once again. But I don't want to take them as experimental but want to take them forward to production. [EMAIL PROTECTED], then you'll probably get a lot of feedback regarding Thanks. I will start a discussion on the mailing list. -- Cheers, Gaurav Vaish http://www.mastergaurav.org http://mastergaurav.blogspot.com ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
for your amusement
follow on to the Boeing presentation at the IAB Plenary: http://www.vrvs.org/Announcements/Plane/VRVS_in_the_air.html Lucy E. Lynch Academic User Services Computing CenterUniversity of Oregon llynch @darkwing.uoregon.edu (541) 346-1774 ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: idea for spam protection
At 9:22 AM -0500 3/13/05, Bruce Lilly wrote: Date: 2005-03-12 11:18 From: Bill Sommerfeld [EMAIL PROTECTED] where's that Final Ultimate Solution to the Spam Problem scorecard? You're probably thinking of http://www.rhyolite.com/anti-spam/you-might-be.html great list. but just because there is no final ultimate technical solution, doesn't mean that (a) governmental/legal solutions are viable or (b) that nothing can be done to ameliorate the situation. the list conspicuously doesn't mention understanding the spam industry and particularly its money-flow. this is kinda like trying to eradicate a disease without really understanding its biology or food-sources; you might succeed, but it's probably more luck than science. we 'merely' have to tip the tables so that spam is mostly unprofitable, after all (presuming that spammers are not in it for altruism). -- David Singer Apple Computer/QuickTime ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: What? No PPT or wireless? [Re: IETF63 wireless]
if we could get rid of wireless and powerpoint, we'd be much better off. Personal opinion: disagree. Wireless is immensely useful to grab a document, check something on another SDO's web site, and - yes - for instant messaging (e.g. we need you in here right now). And some people simply have to multitask in order to be able to attend IETF meetings in the first place. The jabber scribing has become very important for remote participants - this time we even had one Area Director who was partcipating actively by jabber (and audio streaming). The wireless glitches that interrupted jabber were a real problem this time. yes, yes, and yes. but in many meetings it's hard to escape the impression that most of the people in the room aren't really paying more than say 10% of their attention to the meeting. I completely agree with this assessment, having made it and gotten angry about it myself. However, I recall reaching this conclusion at the first IETF I attended - St. Louis, circa 1990. Recall the state of laptops at the time - wireless connectivity didn't enter into it. The reality is that a fair number of the people who attend our meetings do not participate in any meaningful way. It was true 15 years ago and it is true now. The distaction of choice may have changed, but that's about it. And IMO the benefits of wireless connectivity to thhose who do participate are well worth it. maybe this is age setting in, but it seems to me we used to get a lot more work done when we used our meetings primarily for discussion rather than scheduling presentations for most or all of the meeting time. these days some IETF WG meetings remind me of Apple's 1984 commercial...except that there's nobody to throw a hammer through the screen. The only significant change I've noticed over time is that since the dot-bust we no longer seem to attact nearly as many lookee loos. For a while there you had a room where the majority of the overly large audience clearly didn't have a clue what was being discussed, irrespective of whether or not they were actually paying attention to what's going on. The past two meetings I've been to (San Diego and Minneapolis) have to some extent gotten us back to the way things used to be. But excluding the tourists of the recent past I don't see any significant change in the amount of attention people are paying to things. one benefit of our somewhat reduced attendance should be that we can get more work done by reverting to a more effective meeting style. (or maybe our reduced attendance can be attributed to a widespread realization that we're not getting much work done in these meetings?) There was a big change in the overall tone of the meeting this time. But it had to do with the audio streaming and the need for everyone to use a microphone. This plus the absence of microphones on stands created a flow control problem we're unaccustomed to. There were quite a few occasions where I noticed someone start to say something, consider the microphone issue, and simply give up. Of course it is impossible to know whether any of the comments they might otherwise have made would actually have been useful, but the fact remains it has changed the scope of participation materially. Someone in another message suggested that better microphone technology is the answer. Speaking as a someone with a fair amount of experience in this area, there are effective solutions (for the smaller rooms at least) but they tend to be expensive. Less expensive solutions are possible, but they tend to require manual adjustment. The ability for people to participate remotely was incredibly useful, however, and it isn't something I would want to lose. I would therefore suggest that: (1) We continue to stream all the sessions. (2) One or two (depending on the room size) microphone stands be added to the standard setup. This should avoid wasting time fumbling for the wireless mic. (3) We experiment with micing the entire room in one or two of the smaller meeting rooms the next time around. Ned ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: for your amusement
Lucy, congratulations, but First intercontinental videoconference from the air; hmm. Some of us have done this before (using iChat, no less). Gruesse, Carsten ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: IETF63 wireless
On Sun, 13 Mar 2005, Dave Crocker wrote: This is about a mindset and an organizational approach that does not leave those volunteers out on a limb with fragile equipment, or insufficient resources. It is about our approaching this as a utility service and ensuring that that is what is delivered. So, how much are you(ietf attendees in general) willing to pay over and above the current cost of the meeting fee for the wireless service you want? Every time. In case it isn't clear, I think Dave and I are in violent agreement. yup. d/ --- Dave Crocker Brandenburg InternetWorking +1.408.246.8253 dcrocker a t ... WE'VE MOVED to: www.bbiw.net ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf -- -- Joel Jaeggli Unix Consulting [EMAIL PROTECTED] GPG Key Fingerprint: 5C6E 0104 BAF0 40B0 5BD3 C38B F000 35AB B67F 56B2 ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: IETF63 wireless
I believe that the concept that meeting registration fees must cover all IETF suport costs is, a best, an historical statement (and not even correct in that context). With the changes with the IASA activity I believe we have the opportunity to get this right, rather than muddling around attempting to do something on the cheap every time that works sometimes and clearly does not work other times (such as last week). The IETF should state clearly what it needs to get its work done. Yes, its likely that ISOC will need to contribute more than it has done so historically to meet this objective of supporting financially what is required by the IETF to get the work done. But that's what ISOC has already done when it stood up and said we are prepared to support the IETF to get its work done. So perhaps the real question is what is required to be able to set up a reliable and working network 3 times a year that meets the connectivity needs of IETF attendees, and work onward from there, rather than a somewhat orthogonal discussion about breakfast menus! regards, Geoff ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: for your amusement
On Mon, 14 Mar 2005 09:22:53 -0800 (PST) Lucy E. Lynch [EMAIL PROTECTED] wrote: follow on to the Boeing presentation at the IAB Plenary: http://www.vrvs.org/Announcements/Plane/VRVS_in_the_air.html Lucy E. Lynch Academic User Services Computing Center University of Oregon llynch @darkwing.uoregon.edu (541) 346-1774 ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf Apple did this a while ago - note that they didn't claim priority : from June, 2004 http://www.apple.com/hotnews/articles/2004/06/ichat_at_35k/ ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: IETF63 wireless
On Mon, 14 Mar 2005 09:54:35 -0800 (PST), Joel Jaeggli wrote: So, how much are you(ietf attendees in general) willing to pay over and above the current cost of the meeting fee for the wireless service you want? it would, in fact, be really nice to be presented with a concrete proposal, for assured service, that carried a firm price. by rights, however, this should divide at least between captial costs, management costs, and staff costs. The reason is that the first is amortized over some number of years, the second probably is real, hard money for hiring professionals, and i bet the last is dandy to use volunteers for. d/ --- Dave Crocker Brandenburg InternetWorking +1.408.246.8253 dcrocker a t ... WE'VE MOVED to: www.bbiw.net ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: for your amusement
Carsten Bormann wrote: Lucy, congratulations, but First intercontinental videoconference from the air; hmm. Some of us have done this before (using iChat, no less). Well, I've read my emails at 9.6kbps 2-3 years ago, even replied to some, while above Atlantic. I must not have been the first doing this either... What is the advertised bandwidth of the link between aircraft and the rest? Is it like 2Mbps? Alex signature.asc Description: OpenPGP digital signature ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: IETF63 wireless
Bill Sommerfeld wrote: Stateful DHCP lease tracking was clearly causing more trouble than it's worth to the IETF network. Ya' know, I'd be happy if I received a static IP address with my meeting registration confirmation. I'd even be happy to supply my wireless MAC address... --aaron ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: What? No PPT or wireless? [Re: IETF63 wireless]
Carsten Bormann wrote: (The best WG meeting I ever attended was one where Tony Li hammered out most of the IP-over-firewire details in one session by asking the attending firewire experts all the right questions in one sitting. I'm still wowed for life. But you can't do this for something as complex as VPLS.) Carsten- You've given an example for something that I've been wanting to articulate. WG chairs have *lot* of influence over how productive a meeting is. It takes thought and preparation to decide what the best use of the wg time should be. I've seen a tendency for wgchairs to make agendas = list of drafts in development. A better practice would be to start the hard questions that need to be discussed (to take advantage of the face time) and back into background reading from there. I think the emphasis on tourists, surfing, and powerpoint is a red herring. --aaron ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: FW: Why?
On 10:46 14/03/2005, Tom Petch said: As you know, the value of a network is roughly proportional to the square of the participants. The value of a network can depend on what is on it, not how many or who. One useful (http/ftp/...) server can make a network worth accessing, worth paying for. Even if there was noone else on this Internet, even if I never wanted to e-mail anyone or anything, there are servers worth paying to access. Tom, The formula I use is value = Sigma (users) Sigma (externets) (n.log(n) - µ.n**2) where externets are the links between the members of a class (IN, CHAOS in the Internet) and the group of hosts accessible to a class (partly supported in the Internet through views). It can be reduced to value = n.log(n)-µ.n**2. Steve Crocker documented a good mathematical analysis of the n.log(n) part, simple thinking makes obvious (see below) and reality proves for 30 years. However, the µ.n**2 correction is the key element to understand a real network evolution, and to accompany its development. This because a network permits access to a decreasing number of pertinent value added peoples/information (when you got a good answer you have less better answers available - this is a logarithmic degression) while there are as many people hiding them than others - the Metcalf law applies, negatively. Reeds' law (2**n) is a theoretical formula for the Angels - you need everyone to be of interest and eternity to fully take advantage from it: when you consider we are in a polylogue area (to speak to many though many) it becomes the big bang formula. µ is the noise/confusion/pertinence hiding factor. when µ = log (n) / n we reach the state where the is no more value for the users and the externet interest decreases. Managing a network is reducing the relative value of the µ factor. But this becomes more difficult as n grows. I saw the Internet explode in the 1990s because of web servers, not because n**2 people could now talk to each other, so I think this a general point.. Yes. The web externet grown. But users understood it as an example of what the Internet made possible. Realizing it, was just a commercial dazibao they partly lost interest (no real decrease the µ factor) while their number in increasing reduced the value, hence the blunt decrease in the Internet value. New applications and stabilization reduced µ, but spam now is increasing the µ factor to a critical level. The solution is to find new externets to reboost the network. Multilingualism may provide 7260 of them. National risk containment and intelligence protection permit to motivate people for 192 of them. Proximity networks for cities, probably 10.000 of them or more. SNHN (small network, small networks) permits to consider billions of externets. Each of them with a higher local value, because of a smaller number of users and probably of a lower µ factor (better adequation). Unfortunately, languages are not quoted by IAB RFC 3869, the RFC 3066 issue and IDNs do not help multilingualims based development, the global vision and the disinterest in WGIG do not help nation/local interest support by IETF, lack of market feed-backs in the Internet standard process leaves SNHN without real support. The need is for a generalized IPv6 support (and IP permanent ISP independent number for every man/woman/kid, organization and service, and for all their endbox interfaces, sites, applications) through a transition from the current NRO IPv4/IPv6 deployment, to a worldwide salability. By contrast, IPv6, like 3G mobile, has nothing worth getting access to; they are just bits of technology with no applications worth accessing. Oh! yes, there is one: you and me. A stable global network opens the world to the world. The IPv6 IPv4 extension has no problem in supporting it if adequately supported. Have a look at models of the adoption of technology. Here is where is the problem. IETF - and it is its job - looks for new services, technologies, management rules and procedures to accompany the convergence of IPv4 into a fully deployed IPv6 (but its job is not that deployment). The problem is that the current routing oriented allocation system is an initial deployment approach. We need now a stabilized fully scalable management directory based allocation approach. But this will not be carried in one day: we need a transition between them two. This is why a support coopetition rather than a competition between NRO (RIRs) and a meant to everyone intergoverned new IP allocation system, to foster cost decrease, better quality and innovation. Obviously ICANN failed seeing that. I hope the WSIS will come with a solution by the end of the year. But again, this has nothing to do with IPv6, it has to do in reducing the real digital divide which is between those who have a permanent ISP independent IP address and those who have not. jfc ___ Ietf mailing list
Re: RFC - 2229 / Dictionary Server Protocol
probably be to contact the appropriate IETF Area Directors for guidance and for the names of other people who might be Thanks, Brian for the pointer. However, since I first visited the URL yesterday, I am confused as to which one to join. The closest that I could think of is ediint. Is that a correct deduction? I would directly get in touch with Ted / Scott, as you suggest. -- Cheers, Gaurav Vaish http://www.mastergaurav.org http://mastergaurav.blogspot.com ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Why?
From: Keith Moore moore@cs.utk.edu yeah, it *is* easier to deploy first and then later make incremental modifications for scalability - if you like NAT. You do have to build upgrade paths into the architecture if you want it to last ... Making an architecture last is all about .. creating interfaces for the rest of the system that can be stable across drastic changes in technology. But that's exactly what support of multiple addresses is - the key architectural feature needed to make large-scale multi-homing work (within the existing routing/entity-naming architecture, i.e. the one that IPv6 shares with IPv4). I.e. it's the thing we need to have in the architecture to allow the upgrade path you mention. In thinking about this whole point of acceptance of the use of multiple addresses, I came upon an interesting way to look at it all. It starts with the supposition that it seems likely that one way people will do multi-homing is to use a NAT box, and thereby restrict the knowledge of the multiple different addresses (i.e. location-dependent routing-names) to the border of their system. However, another way to look at this is to say that what they really want is to configure their machines with only one identifier, one which is (mostly) location-indepedent, and therefore serves mostly to identify them. They are quite happy to then have those machines depend on another device, at the edge of their network, to provide the location-dependent routing-names for their machines. At an architectural level, this is obviously basically the same as saying that one configures machines with identities, and the machines pick up their routing-names from devices within their network, which provide this data. (This was pretty much exactly Mo O'Dell's enhancement on Dave Clark's basic 8+8 idea.) So why people were and are so resistant to doing the latter is a more than a little puzzling to me, because they are clearly happy to do effectively exactly the same thing when a NAT box is involved. Noel ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: [e2e] Introduction to ATP
Sorry, there isn't any paper on it yet. I think I should write a paper in a few weeks. Anyway, it is just a paper design with many open issues, such as quantitive comparison with TCP, SCTP and so on. -- : Lars Eggert [mailto:[EMAIL PROTECTED] : 2005314 19:55 : Jason Gao : [EMAIL PROTECTED]; ietf@ietf.org : Re: [e2e] Introduction to ATP Jason Gao wrote: Here ATP stands for Asymmetric Transport Protocol (somewhat for historical reason), not Appletalk Transaction Protocol. Welcome to http://atp.ebloggy.com/ to add comment. Is there a paper on it? The web page and your email don't have details. -- Lars Eggert NEC Network Laboratories ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: FW: Why?
Jonathan Rosenberg wrote: ... I agree that ALGs are not the answer, and I believe the reasons for that are treated in: http://www.ietf.org/internet-drafts/draft-iab-nat-traversal- considerations-00.txt I have a fundamental problem with an IAB document that implies NAT provides a firewall. The artifact of lack of state is exploited to prevent inbound connections, but that has nothing to do with a policy rich firewall, and even less to do with anything resembling 'security'. As I said in an earlier post, the entire focus of this document is the wrong direction for the IAB. It should be focused on simplifying application operation, so there should be no NAT in the title. The IAB should be looking at how applications can avoid worrying about the convolution in the network, not focusing on how to navigate it. It is also broken in that it focuses on Client/Server application models, which are generally less of an issue for applications in a NAT environment. Peer-to-peer applications have more trouble with mangled headers so the second thing to do (after changing the title focus) is to rework this so that P2P issues are up front. As I mentioned during the plenary, the document above makes a case that the right answer in many situations are vpn-ish technologies that include v6 tunnels. However, different applications have different needs, and there are real differences between the various vpn-ish solutions (TURN, STUN, teredo, etc.) that are driving their development and adoption. For VoIP, where the nat traversal issue has been especially painful, the increase in voice latency, packet loss, and substantial cost increase of relaying traffic through the tunnel servers, has driven people to solutions like STUN. Thus, I cannot agree that there only needs to be a single solution here. You appear to be too focused on the weeds to notice the path forward. Yes many of the IPv6 transition technologies have the same issues as the NAT traversal technologies in IPv4 (in many cases they do exactly the same thing but with different encapsulated packets). That said if the applications community doesn't get the point that they can leave all that crap behind when native IPv6 is available to them then they will never move. If the applications community doesn't do their part we will always be stuck with the garbage in the network. That said, I agree that the IAB nat traversal consideration document lacks adequate consideration of how evolution plays into this, and I'll endeavor to improve the document on that front. I will try to send text, but I am buried for the next couple of months. Another concern I have is that, in an IPv6-only world, even if you eliminate NAT, there will still be firewalls, and those firewalls will frequently have the property that they block traffic coming from the outside to a particular IP/port on the inside unless an outbound packet has been generated from the inside from that IP/port. There is work going on outside the IETF to deal with this issue. There is no point in wasting years arguing when progress can be made in the real world. This means that IP addresses are not globally reachable. You'd still need most of the same solutions we have on the table today to deal with this problem. Not necessarily. Indeed, in the VoIP space, I believe you'd need pretty much everything, excepting you'd be able to remove a single attribute from a few of the protocols (STUN and TURN in particular), which tell the endpoint its address on the other side of the NAT. The endpoint knows its address, but all of the protocol machinery is still needed to rendezvous with the other participant in the call. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Director, Service Provider VoIP Architecture Parsippany, NJ 07054-2711 Cisco Systems [EMAIL PROTECTED] FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: FW: Why?
Hi Tony, I have not been followign this thread at all. But, I did happen to look at this e-mail and decided to respond. Please see my comments below. Thanks. regards, suresh --- Tony Hain [EMAIL PROTECTED] wrote: Jonathan Rosenberg wrote: ... I agree that ALGs are not the answer, and I believe the reasons for that are treated in: http://www.ietf.org/internet-drafts/draft-iab-nat-traversal- considerations-00.txt I have a fundamental problem with an IAB document that implies NAT provides a firewall. The artifact of lack of state is exploited to prevent inbound [suresh] Why is it a problem with what Jonathan said in the IAB document? It is true that traditinal NATs do inherently provide a limited firewall functionality. Jonathan did not say that NAT function implies full Firewall functionality. Also, what exactly do you mean by the comment about lack of state being exploited to prevent inbound connections? Many firewalls are stateful and so are NATs. Who is exploiting lack of state in what? connections, but that has nothing to do with a policy rich firewall, and even less to do with anything resembling 'security'. [suresh] Agree with your comment about firewalls being policy rich. The comment about security in the draft relates just to the filtering of inbound connections. Given that, why is it OK to say that a firewall secures an organization by not permitting inbound connections, but not OK to draw the same conclusion about a NAT? As I said in an earlier post, the entire focus of this document is the wrong direction for the IAB. It should be focused on simplifying application operation, so there should be no NAT in the title. The IAB should be looking at how applications can avoid worrying about the convolution in the network, not focusing on how to navigate it. [suresh] This sounds like some kind of an unwritten rule, or something. Why is it wrong for the IAB to address real-life problems involving NATs? A tremendous amount of work has been ongoing in the IETF lately concerning how applications should traverse NATs. A new IPsec standard has emerged to deal with NAT traversal. I think, it makes sense that the IAB recognizes that and makes a statement about NAT traversal for the apps. That is not to say that application designers should not design for the V6 networks. It is also broken in that it focuses on Client/Server application models, which are generally less of an issue for applications in a NAT environment. Peer-to-peer applications have more trouble with mangled headers so the second thing to do (after changing the title focus) is to rework this so that P2P issues are up front. [suresh] The focus is principaly on the P2P applications in the draft, from what I can tell. As I mentioned during the plenary, the document above makes a case that the right answer in many situations are vpn-ish technologies that include v6 tunnels. However, different applications have different needs, and there are real differences between the various vpn-ish solutions (TURN, STUN, teredo, etc.) that are driving their development and adoption. For VoIP, where the nat traversal issue has been especially painful, the increase in voice latency, packet loss, and substantial cost increase of relaying traffic through the tunnel servers, has driven people to solutions like STUN. Thus, I cannot agree that there only needs to be a single solution here. You appear to be too focused on the weeds to notice the path forward. Yes many of the IPv6 transition technologies have the same issues as the NAT traversal technologies in IPv4 (in many cases they do exactly the same thing but with different encapsulated packets). That said if the applications community doesn't get the point that they can leave all that crap behind when native IPv6 is available to them then they will never move. If the applications community doesn't do their part we will always be stuck with the garbage in the network. [suresh] It sounds like you are suggesting that the IAB should advocate the mantra that application desginers shoudl jettison the issue of NAT traversal and simply write apps that work with v6 only. Why do you believe the application designers will heed that? Application desginers cannot afford to ignore the current deployment. After all, they want their apps to be deployed. That said, I agree that the IAB nat traversal consideration document lacks adequate consideration of how evolution plays into this, and I'll endeavor to improve the document on that front. I will try to send text, but I am buried for the next couple of months. [suresh] That sounds good. Another concern I have is that, in an IPv6-only world, even if you eliminate NAT, there will still be firewalls, and those firewalls will frequently have the property that they block traffic coming from the outside to a particular IP/port on the inside unless an outbound packet has
RE: Why?
Noel Chiappa wrote: However, another way to look at this is to say that what they really want is to configure their machines with only one identifier, one which is (mostly) location-independent, and therefore serves mostly to identify them. They are quite happy to then have those machines depend on another device, at the edge of their network, to provide the location-dependent routing-names for their machines. This is exactly what MHAP does, but there is a catch too: the complexity reduction at the host level requires extra infrastructure and/or complexity for the ID/LOC mapping that becomes a show-stopper and barely offsets the benefits of the added simplicity at the host level. The complexity issue is not eliminated, simply moved from one realm to the other and this is not enough to cut it. This is pretty much the issue with all solutions so far: in terms of simplicity (or complexity) what the solution puts in one pocket it steals from the other one and the overall complexity is not reduced. Michel. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: FW: Why?
Pyda Srisuresh wrote: [suresh] Why is it a problem with what Jonathan said in the IAB document? It is true that traditinal NATs do inherently provide a limited firewall functionality. Jonathan did not say that NAT function implies full Firewall functionality. Also, what exactly do you mean by the comment about lack of state being exploited to prevent inbound connections? Many firewalls are stateful and so are NATs. Who is exploiting lack of state in what? Lack of state is what is being marketed as a firewall function. As soon as any node behind the nat establishes state there is no firewall for the opened path. If addressing behind the nat changes while the state persists the new node with the mapped address is unexpectedly exposed. connections, but that has nothing to do with a policy rich firewall, and even less to do with anything resembling 'security'. [suresh] Agree with your comment about firewalls being policy rich. The comment about security in the draft relates just to the filtering of inbound connections. Given that, why is it OK to say that a firewall secures an organization by not permitting inbound connections, but not OK to draw the same conclusion about a NAT? No, because a firewall may in fact permit inbound connections according to policy. A nat may also be pre-mapped to a specific node to allow inbound connections. It is wrong to imply that a nat is any kind of firewall or security mechanism because it is neither. It is simply an impediment to applications that under some circumstances allows utility. [suresh] This sounds like some kind of an unwritten rule, or something. Why is it wrong for the IAB to address real-life problems involving NATs? A tremendous amount of work has been ongoing in the IETF lately concerning how applications should traverse NATs. 'A tremendous amount of work' is the fundamental point of my complaint. We are wasting valuable resources patching a hack. It is marginally acceptable for the IESG to deal with this, but the IAB should be looking forward and charting the course, not focusing on the weeds. In any case there is no need for new standardization work involving nats, they are a dead end, we know they are a dead end, yet because they present intellectual challenges people want to focus on them. Get over it and move on. A new IPsec standard has emerged to deal with NAT traversal. I think, it makes sense that the IAB recognizes that and makes a statement about NAT traversal for the apps. That is not to say that application designers should not design for the V6 networks. And how much further would we all have been if the effort that was wasted on that had been focused on simplifying the application environment by getting rid of nat? ... [suresh] The focus is principaly on the P2P applications in the draft, from what I can tell. I just browsed through it, but the entirety of section 2 lays out the model and it is clearly client/server. Section 3 talks about the techniques for nat traversal and 4 is deployment issues. So where is the P2P model? I will have to spend more time on it, but it is not jumping out. [suresh] It sounds like you are suggesting that the IAB should advocate the mantra that application desginers shoudl jettison the issue of NAT traversal and simply write apps that work with v6 only. Why do you believe the application designers will heed that? Application desginers cannot afford to ignore the current deployment. After all, they want their apps to be deployed. Their apps will be easier to deploy and maintain by using the IPv6 tunneling approaches to traverse nat. They don't need to wait, and for those that are targeted at the Windows environment all they need to do is turn on the existing IPv6 stack in XP as the app is installed. The whole point of automated tunneling is to remove the ISPs from being deployment blockers. Applications MUST work or else there is no 'demand' for ISPs to deploy the service. NAT traversal for an IPv4 app is complex and requires a significant amount of operational effort to maintain, so everyone is better off moving to IPv6 because the transition technologies go away where the nat traversal components only persist and get more complex. ... [suresh] VOIP appls go through the same kind of paylod processing in firewalls as do NATs with ALG support for the application. In many implementations, firewall and NAT share the same ALG for protocol monitoring and application processing. This will be interesting when the VoIP apps start encrypting end to end. SRTP is just as opaque to those ALGs as IPsec, so either route will mean a change to traditional firewalls and policies. Tony ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: RFC - 2229 / Dictionary Server Protocol
Anybody can write an Internet-Draft (getting IETF community consensus is another matter). In the case of a revision of a document created Hi Bruce, Great exhaustive mail. Thanks a ton. And I know, now, that it's going to be a little tedious job. I have forgotten troff -- not worked on it for last 6yrs now, but remember some parameters. :-) After ID writing, you gave me another tough task - two independent and fully interoperable implementation. Hooh! btw, can I have these two implementations - in two different languages / platforms? ;-) -- Cheers, Gaurav Vaish http://www.mastergaurav.org http://mastergaurav.blogspot.com ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: FW: Why?
On Mon, Mar 14, 2005 at 04:09:18PM +0100, JFC (Jefsey) Morfin wrote: The solution is to find new externets to reboost the network. The Internet started as an overlay network over the telephony networks. It has been tremendously successful for various reasons and it is now even seeking to replace the telephony networks. Nowadays, we see a bunch of overlay networks running over the Internet. These overlays are developing fast (much like the Internet many years ago) and they provide services end users seem to be interested in and which they are willing to deploy. I think it is important to realize that the IETF's mission in the networking world has changed and much of the real innovative networking work appreciated by the end users is to a large extend happening outside of the IETF. /js -- Juergen Schoenwaelder International University Bremen http://www.eecs.iu-bremen.de/ P.O. Box 750 561, 28725 Bremen, Germany ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Protocol Action: 'Fibre Channel Management MIB' to Proposed Standard
The IESG has approved the following document: - 'Fibre Channel Management MIB ' draft-ietf-ips-fcmgmt-mib-06.txt as a Proposed Standard This document is the product of the IP Storage Working Group. The IESG contact persons are Allison Mankin and Jon Peterson. Technical Summary This document describes managed objects for information related to Fibre Channel. It also establishes an IANA registry for Fibre Channel Port Types. Working Group Summary This MIB is a complete re-start of the Fibre Channel MIB, independent of the one begun in the concluded IPFC WG. During chartering of the IPS WG, experts on Fibre Channel, the chairs, the Fibre Channel IPS coordinators, OPS and Transport ADs, and others supported restarting this MIB in the new WG. Protocol Quality The document was reviewed by Mike MacFaden of the MIB Doctors, Bert Wijnen, and Allison Mankin for the IESG. Expert Reviewer Appointment by the IESG The IESG appoints Roger Cummings, [EMAIL PROTECTED], for the Fibre Channel Port Types Expert Reviewer role defined in this document. ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce
Document Action: 'Hypertext Transfer Protocol (HTTP) Digest Authentication Using Authentication and Key Agreement (AKA) Version-2' to Informational RFC
The IESG has approved the following document: - 'Hypertext Transfer Protocol (HTTP) Digest Authentication Using Authentication and Key Agreement (AKA) Version-2 ' draft-torvinen-http-digest-aka-v2-02.txt as an Informational RFC This document has been reviewed in the IETF but is not the product of an IETF Working Group. The IESG contact person is Allison Mankin. RFC Editor Note Abstract OLD: HTTP Digest as specified in [4] is known to be vulnerable to man-in-the-middle attacks if the client fails to authenticate the server in TLS, or if the same passwords are used for authentication in some other context without TLS. This is a general problem that exist not just with HTTP Digest but also with other IETF protocols that use tunneled authentication. This document specifies version 2 of the HTTP Digest AKA algorithm [6]. This algorithm can be implemented in a way that it is resistant to the man-in-the-middle attack. NEW: HTTP Digest as specified in RFC 2617 is known to be vulnerable to man-in-the-middle attacks if the client fails to authenticate the server in TLS, or if the same passwords are used for authentication in some other context without TLS. This is a general problem that exist not just with HTTP Digest but also with other IETF protocols that use tunneled authentication. This document specifies version 2 of the HTTP Digest AKA algorithm (RFC 3310). This algorithm can be implemented in a way that it is resistant to the man-in-the-middle attack. ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce
Last Call: 'The Codecs Parameter for Bucket Media Types' to Proposed Standard
The IESG has received a request from an individual submitter to consider the following document: - 'The Codecs Parameter for Bucket Media Types ' draft-gellens-mime-bucket-03.txt as a Proposed Standard Although this document is a submission to the IETF from an individual it received review in the AVT working group and the IETF-types mailing list. The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send any comments to the iesg@ietf.org or ietf@ietf.org mailing lists by 2005-04-11. The file can be obtained via http://www.ietf.org/internet-drafts/draft-gellens-mime-bucket-03.txt ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce
