Re: Guidance needed on well known ports
Hallam-Baker, Phillip wrote: The whole idea of fixed ports is broken. ... The Internet has a signalling layer, the DNS. Applications should use it. The SRV record provides an infinitely extensible mechanism for advertising ports. And with what port would I reach this magical DNS that would provide the SRV record for the DNS itself? Fixed ports do not work behind NAT. Anyone who wants to deploy IPv6 would be well advised to pay careful attention to that restriction. SRV ports work just fine behind a NAT. Except that many NATs also intercept DNS requests and redirect them to their own servers, for their own purposes, which can interfere with SRV records (by design). The only thing that works fine behind a NAT is what the NAT vendor wants to work fine. Everything else is up for grabs. Joe ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: RFC Publication - Patent-Free Declarations ... -- Market of Protocols -- Free Protocols Foundation
On Sat, 18 Mar 2006 07:14:52 -0800, Dave Crocker [EMAIL PROTECTED] said: Dave Mohsen BANAN wrote: we propose... Dave Besides yourself, who is the we? Among others, Richard M. Stallman has served as a director of the Free Protocols Foundation (FPF) and has reviewed and endorsed various FPF initiatives. ...Mohsen ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Complaints Against The IESG and The RFC-Editor About Publication of RFC-2188 (ESRO)
On Sun, 19 Mar 2006 04:56:57 +0100, Harald Alvestrand [EMAIL PROTECTED] said: Harald Mohsen BANAN wrote: Complaints Against The IESG and The RFC-Editor About Publication of RFC-2188 (ESRO) Harald The IESG pointed some of the issues out to the RFC Editor, who handled Harald the communication with the author; that was the procedure at that time. Harald Nevertheless, the RFC Editor felt that the document was worthy of Harald publication, and published anyway. As the written record clearly shows, this is factually incorrect. In the case of RFC-2188 the RFC Editor was no more than an IESG puppet. Publication was held up for more than 7 months, until finally Scott Bradner (Transport Area Director at the IESG) made it happen -- emphatically *not* the RFC Editor. Scott can step in, if he wishes. Full communication records are available at: http://www.esro.org/communicationRecord/rfc2188Publication/maillist.html And then there is the communication record of what happened when the IESG invited us to put ESRO on the standards track. http://www.esro.org/noStdTrack/main.html Harald The IESG note put on this document says: In general, I consider the garbage that IESG puts in non-IETF RFCs as a badge of honor for the author. For example, the negative IESG note in the original HTTP specs and the success of HTTP demonstrated IESG's attitude and its eventual relevance. Harald In this case [RFC-2524], too, the RFC Harald Editor exercised the RFC Editor's Harald independent judgment and published the Harald document. Had it not been for my very public RFC-2188 complaint, I do not believe RFC-2524 would have been published at all. Please note the time of my complaint and of the RFC-2524 publication. How many other non-IETF RFCs have ever been published by the RFC Editor in the face of IESG opposition? I believe the answer is very few if not zero. If I am wrong, I ask the RFC Editor/IESG to correct the record. Please name the RFCs. Harald This was eight years ago. ... Lack of true independence of the RFC Editor was the issue then, and it is the issue now. ...Mohsen ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Complaints Against The IESG and The RFC-Editor About Publication of RFC-2188 (ESRO)
On Sun, 19 Mar 2006 04:56:57 +0100, Harald Alvestrand [EMAIL PROTECTED] said: On Sat, 18 Mar 2006 21:10:10 -0800, Dave Crocker [EMAIL PROTECTED] said: Harald What's the point of reposting this message now? Dave Seems like there ought to be a statute of limitations. In response to both of you: the point of referring to eight-year old history is not to disinter the corpse of the past. The point is that this history is directly relevent to a current discussion thread. I believe I made the point of reposting clear in the following header: Mohsen [ This is a repost from 6 Nov 1998. Mohsen In particular the section on: Mohsen o Separate The RFC Publication Service from the IETF/IESG/IAB. Mohsen is relevant to the current: MohsenSTRAW PROPOSAL RFC Editor charter Mohsen thread. ] ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Complaints Against The IESG and The RFC-Editor About Publication of RFC-2188 (ESRO)
On Sun Mar 19 09:46:30 2006, Mohsen BANAN wrote: For example, the negative IESG note in the original HTTP specs and the success of HTTP demonstrated IESG's attitude and its eventual relevance. For the crowd watching who were curious, but not curious enough to bother looking, RFC1945 (HTTP/1.0), which of course is NOT the original HTTP spec at all, carries the note: The IESG has concerns about this protocol, and expects this document to be replaced relatively soon by a standards track document. RFC2068, HTTP/1.1, was published a little over half a year later, which would appear to be relatively soon. Something appears to be wrong with your DNS, so reading your webpages is somewhat impractical. FWIW, I reviewed EMSD a little while ago, to see whether there was anything worth raising for Lemonade, and decided that the IESG note on that still stands, except more so, as various problems they noted have become more important as time has passed. [For the crowd, EMSD is a wireless replacement for the Submission protocol, but does not support anything but ASCII, has no authentication, and insists on using its own message format in ASN.1] But back to your argument, which appears to be that if the RFC editor function were utterly independent from the IAB/IETF/IESG, your protocols would have been published without those notes, and without the review those notes required. Which part is the problem, the review, or the note attached to the document? Dave. -- You see things; and you say Why? But I dream things that never were; and I say Why not? - George Bernard Shaw ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Complaints Against The IESG and The RFC-Editor About Publication of RFC-2188 (ESRO)
Harald The IESG pointed some of the issues out to the RFC Editor, who handled Harald the communication with the author; that was the procedure at that time. Harald Nevertheless, the RFC Editor felt that the document was worthy of Harald publication, and published anyway. As the written record clearly shows, this is factually incorrect. In the case of RFC-2188 the RFC Editor was no more than an IESG puppet. Publication was held up for more than 7 months, until finally Scott Bradner (Transport Area Director at the IESG) made it happen -- emphatically *not* the RFC Editor. Scott can step in, if he wishes. I will go on record to say that I was the IESG member who did the most to discourage publication of your document as an RFC. Contrary to your perception of things, the RFC Editor published it over my strong objections, and also insisted on diluting the IESG note that was originally written for that document. I don't recall the reasons for the delay other than the high workload of IESG (we were reviewing dozens of documents per week, the fact that IESG discussed things in conference calls every two weeks, and there were several iterations of back-and-forth with the RFC Editor regarding your document. It is my recollection that your document was handled much more quickly than working group documents -- because unlike WG documents which proceeded normally though the IESG's queue (and for which the speed of processing was sensitive to IESG's workload), the RFC Editor had a policy of giving IESG a limited amount of time to comment on independent submissions that had the perverse side-effect of giving priority to those submissions. It was and still is my opinion that RFC 2188 was not suitable for publication as an RFC, as it is poorly designed and has numerous technical flaws. To have published this document IMHO dilutes the quality of the RFC series and may confer an undeserved appearance of acceptance on ESRO. Perhaps more importantly, the discussion about this document wasted a colossal amount of time that could have been put to much better use reviewing working group output (on the part of the IESG) and editing better quality documents (on the part of the RFC Editor). As Harald points out, this was eight years ago, and the process has changed significantly since that time. Also, I'm no longer on the IESG and don't expect to ever be on the IESG again. Life is too short. Since all of the circumstances and nearly all of the people have changed since this incident, I don't see how it's relevant now. Keith ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
great 1972 documentary video on the Arpanet
Found this link via Boing Boing. I think it is very appropriate, considering the 20th aniversary of the IETF. http://video.google.com/videoplay?docid=-742634319032463 John ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: I-D ACTION:draft-alvestrand-ipod-00.txt
Hi, I also like this suggestion. Not much to add, I agree with Frank's comments. The third paragraph of section 2.2 seems to have missing something around the last sentence.. On Tue, 21 Feb 2006, Frank Ellermann wrote: [EMAIL PROTECTED] wrote: Title : IETF Process and Operations Documents Author(s) : H. Alvestrand Filename: draft-alvestrand-ipod-00.txt Yes, I like this, admin and procedural stuff as new series, not mixed with more technical BCPs or informational RfCs. It goes even further saying that IPODs are no RfCs at all, but ordinary Web pages (in formats defined by an IPOD). I don't see why new formats are strictly necessary, a text I-D translated to HTML by http://tools.ietf.org/html is typically fine, it offers links and up to 100 versions, e.g. http://tools.ietf.org/html/draft-alvestrand-ipod The IPOD acronym is a bit odd, how about CAP (current administrative procedures) ? Bye, Frank ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf -- 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: Unofficial Meeting of Scalable Small Group Multicast(SSGM) for IRTF
Hello all The room name is Sapphire in Hilton Anatole. It is located 1st floor of the Tower. We will put a poster on the message board. For tele-conf. We prepare our bridge and polycom for remote a participants. Mail ug at xcast.jp_NOSPAM yoneda.takahiro at jp.panasonic.com_NOSPAM for bridge information. -- ug Aaron Falk wrote: === Call for participants === Unofficial Meeting of Scalable Small Group Multicast(SSGM) for IRTF http://www.net.itc.nagoya-u.ac.jp/SSGM/ Date : March 19, 2006 (20:00--23:00) Place: Room TBD , Hilton Anatole (Same hotel of IETF 65th), Dallas TX, USA http://www.ietf.org/meetings/IETF-65.html Room will be announced on the MLs and the message board. IP Multicast has proved useful in transmitting information such as voice and video to large groups. It has been used to broadcast IETF Working Group meetings to remote participants and will provide a suitable foundation for broadcasting TV programs across the Internet. On the other hand, IP multicast is not well suited to small groups. As the Internet Architecture Board stated in RFC 2902, Providing for many groups of small conferences ... scales badly given the current multicast model. The ability to efficiently support small groups will be important for VoIP conference calls, for videoconferencing and for multi-media e-meetings and as a result several alternative approaches have emerged for the problem of small group communications. These include. * ALM ([ESM],[YOID],[NICE],[ALMI],[TAG],[DTO],[CAN],[BAYEUX]) * Overlay Multicast([SCX],[OVERCAST],[RMX],[MSN],[OMNI],[AKAMAI], [IBEAM]) * XCAST ([XCID],[XCUG],[XCP],[GXC],[XMIP],[XCBCP]) These make it easy for end-users to start using multi-party communications since they use a datagram distribution layer that is based on ordinary unicast routing. As these alternative approaches have appeared relatively recently, issues remain to be worked out. These issues are discussed in several research papers ([TAON], [SROU], [CMP], [ITOL], [PAA], [EEA]) and include: * Long latency * Selfish routing and bandwidth consumption * Slow routing convergence * Routing instability * Difficulties in deployment and maintenance * Inefficient tree topology Using these technologies as the basis for group communication without solving these problems would cause serious conflicts between carriers and users concerned with bandwidth usage similar to traffic load of popular file sharing systems like Kazaa, Napster, Winny and Bittorrerant. The purpose of the ad hoc meeting is 1. share the results of the various research groups. 2. identify the set of problems that remain to be addressed 3. get rough consensus on the direction and next steps that should be taken to address the problem of small group communication. We expect that the results of this meeting will be reported to the IRTF chair and shared within the IETF/IRTF as well as in the broader academic and engineering community to accelerate the development of novel and useful mechanisms for small group communications. * Agenda 20:00 - 20:05 - Agenda Bash * 20:05 - 21:25 (15 min each) 1. Overlay Multicast and SSGM (Prof. Mark Pullen, GMU) 2. Application Layer Multicast and SSGM (Prof. Bobby Bhattacharjee UMD) 3. XCAST and SSGM (Yuji Imai, WIDE Project) 4. Selfish Routing Implications (Prof. Lili Qiu, UT Austin) 5. Problem statements (Prof. Yoichi Shinoda, JAIST/WIDE Project * 21:30 - 23:00 Draft charter Presentation General Discussion * Invited Observers - Prof. Kevin Almeroth, UCSB Multicast Expert - Prof. Henning Schulzrinne, Columbia SIP, RTP - Aaron Falk, IRTF chair/ISI -- Yuji IMAI (WIDE Project) John Buford (Panasonic) Rick Boivie (IBM) Bobby Bhattacharjee(UMD) - [to be confirmed] Reference [2902] S. Deering, S. Hares, C. Perkins, R. Perlman, Overview of the 1998 IAB Routing Workshop, RFC2902, August 2000. [ESM] Y.-H. Chu, S. G. Rao, and H. Zhang. A case for end system multicast. In Proceedings of ACM Sigmetrics, June 2000. [YOID] P. Francis. Yoid: Extending the Multicast Internet Architecture. White papar, http://www.aciri.org/yoid/ [NICE] S. Banerjee, C. Kommareddy, and B. Bhattacharjee. Scalable application layer multicast. In Proceedings of ACM SIGCOMM, Aug. 2002. [ALMI] D. Pendarakis, S. Shi, D. Verma, and M. Waldvogel. ALMI: An application level multicast infrastructure. In Proceedings of the 3rd USENIX Symposium on Internet Technologies and Systems, Mar. 2001. [TAG] M. Kwon and S. Fahmy. Topology aware overlay networks for group communication. In Proceedings of NOSSDAV, May 2002 [DTO] J. Liebeherr, M. Nahas, and W. Si. Application-layer multicasting with delaunay triangulation overlays. IEEE Journal on Selected Areas in Communications, 20(8):1472?1488, Oct. 2002. [CAN] S. Ratnasamy,
Re: Appeal of AD Decision to uphold Atompub ban
Robert, Scott and Paul, is there any chance you could sit down and try to work this out? I read Robert's two messages to the working group list and I do find them fairly hard to follow. They don't explain why he's angry at a specific organization or what the supposed process failure is. If he had explicitly explained that there were conformance tests that were not motivated by the document in his messages, they would have been more useful. If he had given examples of specific tests that were incorrect, it would have been even more useful. It seems that in this instance, a specific discussion of where the line is drawn would be more useful than being so formal about this. If Paul and Robert can agree on a line and Paul believes that Robert will be able to follow that line, then perhaps the suspension could be lifted. Remember suspensions are a tool to improve efficiency of orking groups, not punishments to punish people for bad behavior. Even if Paul is not comfortable enough to lift the suspension, I bet all parties involved would be in a better position if both Paul and Robert had explicit understanding of what was acceptable and what is not. --Sam ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Appeal of AD Decision to uphold Atompub ban
On 3/19/06, Sam Hartman [EMAIL PROTECTED] wrote: is there any chance you could sit down and try to work this out? No, the WG is out of control. That's easy to observe, no matter where one places the blame. If he had explicitly explained that there were conformance tests that were not motivated by the document in his messages, they would have been more useful. If he had given examples of specific tests that were incorrect, it would have been even more useful. There were 10 or 20 tests in the suite, and I didn't bother to go through each of them and explain. However, I did show that the possible errors in the test suite were mostly bogus. http://www.imc.org/atom-protocol/mail-archive/msg04682.html I was then told that there would have to be a discussion, and that the test suite consituted an implementation that showed evidence of interop problem. I've always thought that WG discussions should take the form My application has problem X, and I want to to fix it with solution Y. In fact, atompub has a rather formal process in place that requires WG members do exactly that. Remember suspensions are a tool to improve efficiency of working groups, not punishments to punish people for bad behavior. If efficiency is the concern, I'm not the person to ban. The WG has steamrolled my objections twice, only to adopt my individual draft a few months later (though they don't admit that). It looks like they're headed for a third time. That should only take three or four months, maybe five or six, if it's decided that another individual is threatening in some way. -- Robert Sayre ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: STRAW PROPOSAL RFC Editor charter
Harald Alvestrand wrote: Ran, RJ Atkinson wrote: There was an understanding then that the RFC Editor's role extends far beyond just publishing IETF-sponsored documents. I am concerned that this is not being acknowledged now. I would feel a lot better if there were more public acknowledgement that the RFC Editor's role extends far beyond the IETF-sponsored documents. It may have been true in 1993. At the moment, the part of the RFC Editor's role that extends beyond the IETF-sponsored documents is a small fraction (5%?) of the RFC Editor's output, and, I suspect, an even smaller fraction of the motivation for people and organizations to sponsor the RFC Editor; *all* of the funding for the RFC Editor comes through ISOC. At this moment, the RFC Editor is a function controlled, for better or worse, by the IETF. The IETF may choose to use the RFC process for other purposes than publishing IETF documents (and I think it should). But I do not believe that the concept of an RFC Editor that is independent of the IETF is a sustainable model at this time. Harald, The point is that the past IESG practice which has driven out those who would submit individual submissions, resulting in the current ratios, MUST NOT become the guide for what SHOULD happen going forward. The RFC editor role needs to be extricated from the overbearing IESG and returned to its independent role. Doing otherwise further fragments the community which will only lead to its downfall. Tony ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Complaints Against The IESG and The RFC-Editor About Publication of RFC-2188 (ESRO)
I too agree with Mohsen's comments, overall. What Mohsen points out as true eight years ago continues to be true even now. Not a lot changed, IMHO. I believe, it had gotten worse. IESG continues to wield enormous influence over the independent submissions sent to the RFC editor. The RFC editor needs to be independent. regards, suresh --- Mohsen BANAN [EMAIL PROTECTED] wrote: On Sun, 19 Mar 2006 04:56:57 +0100, Harald Alvestrand [EMAIL PROTECTED] said: On Sat, 18 Mar 2006 21:10:10 -0800, Dave Crocker [EMAIL PROTECTED] said: Harald What's the point of reposting this message now? Dave Seems like there ought to be a statute of limitations. In response to both of you: the point of referring to eight-year old history is not to disinter the corpse of the past. The point is that this history is directly relevent to a current discussion thread. I believe I made the point of reposting clear in the following header: Mohsen [ This is a repost from 6 Nov 1998. Mohsen In particular the section on: Mohsen o Separate The RFC Publication Service from the IETF/IESG/IAB. Mohsen is relevant to the current: MohsenSTRAW PROPOSAL RFC Editor charter Mohsen thread. ] ___ 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: Complaints Against The IESG and The RFC-Editor About Publication of RFC-2188 (ESRO)
On Sun, 19 Mar 2006 09:42:50 -0800 (PST), Pyda Srisuresh [EMAIL PROTECTED] wrote: I too agree with Mohsen's comments, overall. What Mohsen points out as true eight years ago continues to be true even now. Not a lot changed, IMHO. I believe, it had gotten worse. IESG continues to wield enormous influence over the independent submissions sent to the RFC editor. The RFC editor needs to be independent. Why? There are plenty of other publication venues. --Steven M. Bellovin, http://www.cs.columbia.edu/~smb ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Complaints Against The IESG and The RFC-Editor About Publication of RFC-2188 (ESRO)
Right, that is the foced outcome of the current practice. Without an independent channel, people find other avenues outside the IETF to get their work done. regards, suresh --- Steven M. Bellovin [EMAIL PROTECTED] wrote: On Sun, 19 Mar 2006 09:42:50 -0800 (PST), Pyda Srisuresh [EMAIL PROTECTED] wrote: I too agree with Mohsen's comments, overall. What Mohsen points out as true eight years ago continues to be true even now. Not a lot changed, IMHO. I believe, it had gotten worse. IESG continues to wield enormous influence over the independent submissions sent to the RFC editor. The RFC editor needs to be independent. Why? There are plenty of other publication venues. --Steven M. Bellovin, http://www.cs.columbia.edu/~smb ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
jabber
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Has jabber moved from ietf.xmpp.org? - -- ] ON HUMILITY: to err is human. To moo, bovine. | firewalls [ ] Michael Richardson,Xelerance Corporation, Ottawa, ON|net architect[ ] [EMAIL PROTECTED] http://www.sandelman.ottawa.on.ca/mcr/ |device driver[ ] panic(Just another Debian GNU/Linux using, kernel hacking, security guy); [ -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) Comment: Finger me for keys iQEVAwUBRB2XnICLcPvd0N1lAQI6+Af/eCOEqL6ZIbVDPU55wI9B3oefcFgJFnK8 u+NBsqpL3fCE92ujJuefJQxWcbQbnKQvze1FLykBCi5V9vX5jSAtOqagfI4zIgn6 ha1wVVLoNEcQu3EzBpcA17rxhZWnl+ZV/+tdM6u1DBZDWnhvwlBBiJEW2a0pYUig bMTZhJe2naMQuVQ8dbhHI7EJ4+DvfgEiI4+OVnO079iXGJULjnS+goVUadMlHnEK Bn9/3Iqu90bwRB6VBDrKPw/hs26rovyr73RIcwcXTz/+zqWYx31qbuiMifMz+kEZ +5QGNolqQkuPKk6nXMwwewOtgLnl4Jqc4gwtcxeP42ClwhR50H/oXA== =Y2lj -END PGP SIGNATURE- ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: jabber
On Sun, 19 Mar 2006, Michael Richardson wrote: --[PinePGP]--[begin]-- Has jabber moved from ietf.xmpp.org? yes - see: http://www.ietf.org/meetings/text_conf.html rooms.jabber.ietf.org -- ] ON HUMILITY: to err is human. To moo, bovine. | firewalls [ ] Michael Richardson,Xelerance Corporation, Ottawa, ON|net architect[ ] [EMAIL PROTECTED] http://www.sandelman.ottawa.on.ca/mcr/ |device driver[ ] panic(Just another Debian GNU/Linux using, kernel hacking, security guy); [ --[PinePGP]--- gpg: Signature made Sun 19 Mar 2006 09:40:44 AM PST using RSA key ID DDD0DD65 gpg: Can't check signature: public key not found PinePGP: Encryption backend encountered error. --[PinePGP][end]-- -- 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: Appeal of AD Decision to uphold Atompub ban
On 3/19/06, Paul Hoffman [EMAIL PROTECTED] wrote: There is a long-standing effort outside the WG that includes conformance tests. Their first inclusion of conformance tests for the current draft had many errors, as Rob pointed out. The errors were extensive to indicate that either the editor of the draft hasn't read the draft, or the tests were put there intentionally. I'm not sure which is worse. He has not tried to change the document based on his bogus tests, and would certainly be shot down (without Rob's vitrol) if he did. Actually, in the past, the editors have included several normative requirements with consulting the WG, and then insisted they were grounds for discussion. See a pattern here? It seems that in this instance, a specific discussion of where the line is drawn would be more useful than being so formal about this. The line is drawn when the attacks become personal. ... imputing absurd motives on them... Wouldn't it be easier if we started with some set of requirements/use cases instead of inventing them on-the-fly to club alternative proposals? http://www.imc.org/atom-protocol/mail-archive/msg03355.html There's your problem, and there's proof that I'm not the only one that feels this way. -- Robert Sayre ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Complaints Against The IESG and The RFC-Editor About Publication of RFC-2188 (ESRO)
On Sun, 19 Mar 2006 10:17:13 -0800 (PST), Pyda Srisuresh [EMAIL PROTECTED] wrote: Right, that is the foced outcome of the current practice. Without an independent channel, people find other avenues outside the IETF to get their work done. More precisely, to publish their work. My question is why this is bad for anyone except those who want the RFC label on their work. Put another way, the real question is what RFC means. Given the confusion that already exists in the market (We implement RFC 1149!), I'd rather there were more IETF controls on what bears that label. I'm not saying it should be completely an IETF publishing venue (though frankly, I wouldn't mind it at all if the IETF could trademark RFC), but I do think that avoiding gratuitous confusion is a good idea. --Steven M. Bellovin, http://www.cs.columbia.edu/~smb ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: STRAW PROPOSAL RFC Editor charter
Hi Tony, The point is that the past IESG practice which has driven out those who would submit individual submissions, resulting in the current ratios, MUST NOT become the guide for what SHOULD happen going forward. Actually, RFC 3932 already makes it quite clear what the role of the IETF and the IESG is in the individual submissions process. My understanding is that this makes the IESG much less in charge of what the individual submissions say than what the situation was before. Basically, there's only a check for conflict between the submission and IETF work. And obviously, non-IETF documents get a note which clearly explains that the document is not an output of the IETF. So, I would actually expect the situation has improved since the publication of RFC 3932. The rules seems clear and fair to me. Tony, if you have had bad experiences, have they been before or after RFC 3932? --Jari ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Complaints Against The IESG and The RFC-Editor About Publication of RFC-2188 (ESRO)
On Sun, 19 Mar 2006 11:23:45 +, Dave Cridland [EMAIL PROTECTED] said: Dave On Sun Mar 19 09:46:30 2006, Mohsen BANAN wrote: For example, the negative IESG note in the original HTTP specs and the success of HTTP demonstrated IESG's attitude and its eventual relevance. Dave For the crowd watching who were curious, but not curious enough to Dave bother looking, RFC1945 (HTTP/1.0), which of course is NOT the Dave original HTTP spec at all, carries the note: DaveThe IESG has concerns about this protocol, and expects this document Daveto be replaced relatively soon by a standards track document. Dave RFC2068, HTTP/1.1, was published a little over half a year later, Dave which would appear to be relatively soon. The primary author of Informational RFC1945 with the negative IESG note is Tim Berners-Lee. He then pulled out of the IETF/IESG and formed W3C. Why do you think that happened? And where is IETF/IESG with W3C now? In my opinion what started with the Informational RFC1945 is the most significant advancement since formation of IETF/IESG/IAB/... Almost always innovation comes from outside of committees. Dave But back to your argument, which appears to be that if the RFC editor Dave function were utterly independent from the IAB/IETF/IESG, your Dave protocols would have been published without those notes, and without Dave the review those notes required. Which part is the problem, the Dave review, or the note attached to the document? None of those. My concern is not my own RFCs. I got them published despite of the IETF/IESG opposition. The IESG note is a badge of honor similar to Tim Berners-Lee's. The perspective that the world needs the IESG note to be able to judge the merits of a protocol is at best comical. The scope and purpose of the IESG note should be limited to relevance and overlap with current or planned IETF work. An independent RFC Editor should enforce this and put the IESG in its place. That is what the then BCP -- RFC-2026 -- said. Of course, things work differently in a cult. I suspect that lots of direct independent RFC submissions are being censored by the IESG. The community is being fragmented. And the trend appears to be for the situation to only be getting worse. Again, all of this is in the context of: STRAW PROPOSAL RFC Editor charter where the key topics are: - Independence of RFC Publication Service - Relationship of IETF/IESG/IAB with the RFC Publication Service - Use of the RFC Publication Service by the Internet Community Tony gets it: On Sun, 19 Mar 2006 09:28:17 -0800, Tony Hain [EMAIL PROTECTED] said: Tony The point is that the past IESG practice which has driven out those who Tony would submit individual submissions, resulting in the current ratios, MUST Tony NOT become the guide for what SHOULD happen going forward. The RFC editor Tony role needs to be extricated from the overbearing IESG and returned to its Tony independent role. Doing otherwise further fragments the community which will Tony only lead to its downfall. From my perspective, based on past performance, the IETF/IESG/IAB can not be trusted to control the RFC Publication Service. ...Mohsen ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Complaints Against The IESG and The RFC-Editor About Publication of RFC-2188 (ESRO)
Dave RFC2068, HTTP/1.1, was published a little over half a year later, Dave which would appear to be relatively soon. The primary author of Informational RFC1945 with the negative IESG note is Tim Berners-Lee. He then pulled out of the IETF/IESG and formed W3C. Why do you think that happened? Because he had specific ideas he wanted to pursue, and wanted staff to work on them. That required a different model than the IETF. Pulled out is an exaggeration, however. W3C has sent people to IETF meetings ever since it was founded. And where is IETF/IESG with W3C now? Cooperating quite well and respecting each others' areas of competence, I think. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Forced move - IETF 65 NOC
All - Due to major flooding in NOC (yes, that's right, IN the NOC) we will be taking a short outage in order to move to higher (dryer) ground. The network will be down while we move shop. Our dns/dhcp will be coming down at 2:45 and will be down at least half an hour. If you have a lease, you may not notice an interruption, but new leases will have to wait. -- 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
veni vidi exi
Dear Mr. Chair, I never hidden I am involved in cultural policy. Actually, I represent a group of specialised colleagues. >From EU Governments, EU Parliament, and International Organisations. We came here after reading a suggestion of Mr. Morfin. We wanted to know about this IETF he talked about. On the spot. Dr. Lessig says the Internet Constitution is in the code. Mr. Morfin says it means it is in the Internet standards. He asked us to read RFC 3935, 3869, 3774. (We known the US positions and Communications code). We wanted to know how the IETF influences us. How it writes and decides our constitution. What is its real ethic, its real values, its real allegiances. How it works. If it can be used. And if so, by who? How? We wanted to evaluate the IETF lingual proposition. Its capacity to address the needs of our cultures. Its impact on our industries. Its interest in our laws. Its capacity to evolve and innovate. Also, its possible bias. We verified Linguasphere was blocked. We verified that en-EU was denied. We verified the importance of the Unicode consortium. We understand what is internationalization. We understand the IDNA and the Langtags issues. For that we are called Mr. Morfin. Still minutes ago in a Mr. Alvestrand's ad hominem. He should be banned for, would he not be the Chair. Now, we take it as an honour. We can now leave the IETF. We learned why technical intelligence is useful. I will ask someone to lurk for me. IETF is important to the users and to those who defend them. And I loved the cat and mice game. Mr. Halvestrand is correct. My name is not Eduardo Mendez. When the IANA list is activated I may join it openly. As long as it uses an alias, I think I can do the same. Actually, I think I had to. We could not come in official capacity. We have not to take position. But we were on the verge to, before we came. By ignorance. We thank all of you for what we learned. I think Mr. Morfin is right: the IETF must be defended. Against some of its Members (plural) too. He thinks you can do it. I hope he is right. Eduardo Mendez ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: Guidance needed on well known ports
From: Joe Touch [mailto:[EMAIL PROTECTED] And with what port would I reach this magical DNS that would provide the SRV record for the DNS itself? You use fixed ports for the bootstrap process and only for the bootstrap process. Fixed ports do not work behind NAT. Anyone who wants to deploy IPv6 would be well advised to pay careful attention to that restriction. SRV ports work just fine behind a NAT. Except that many NATs also intercept DNS requests and redirect them to their own servers, for their own purposes, which can interfere with SRV records (by design). People who do this are rarely trying to break things. T The only thing that works fine behind a NAT is what the NAT vendor wants to work fine. Everything else is up for grabs. The NAT vendors would like their systems to work as well as possible. If there had been less hostility to the idea and less determination to ensure IPv4 actually broke thus forcing deployment of IPv6 this could have worked. smime.p7s Description: S/MIME cryptographic signature ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Guidance needed on well known ports
On Sat, 2006-03-18 at 09:38 -0800, Eliot Lear wrote: This therefore leads to two questions for the community: 1. Are well known ports archaic? If so, can we request that the IANA do away with the distinction? 2. If they are not archaic, under what circumstances should they be allocated? new protocols can not rely on the security the priveleged ports provide, but there are still many such protocols in use (e.g. LPD, port 515), and so the distinction is useful for administrators configuring userspace' access to ports on workstations. The problem is this cuts both way. The privileged port concept has some marginal utility on multiuser systems where you don't Joe-random-user to grab some port for a well known service. OTOH, this forces servers running on those ports to have privileges (usually in the form of running as root) for some period of time. The need to operate with privileges complicates server design, may impose difficult constraints on activities like configuration reloads, and may lead to remote vulnerabilities. So, for a production server with no local users, the privileged port restriction can do much more harm than good. And finally, we have plenty of protocols that make just as much sense on multiuser systems as they do on a production server with no local users. So it is impossible to get this right. The solution is to abandon the coarse grained root-access-to-low-ports security model entirely in favor of some form of finer grained access control. In the meantime, I'm with Harald: Flip a coin and be done with it. Ned ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Complaints Against The IESG and The RFC-Editor About Publication of RFC-2188 (ESRO)
Keith, You have totally confused ESRO with EMSD. RFC-2188 is different from RFC-2524. 1) RFC-2188 (ESRO) As far as I know the RFC-2188 complaint had nothing to do with you. Everything is fully documented. We are talking about historic facts, not opinions. IESG did not object to publication of ESRO (RFC-2188). I declined IESG's invitation to put ESRO on standards track. That was my choice. The problem was that it took 7 months. 2) RFC-2524 (EMSD) You lost. I managed to convince the RFC Editor of the merits of publication. I used the RFC-2188 complaint to strengthen the RFC Editor's independence. There has never been any formal complaints related to RFC-2524. The only part of the IESG note that can be considered to have any aspect of legitimacy is: -- In the near future, the IESG may charter a working group to define an Internet standards-track protocol for efficient transmission of electronic mail messages, which will be highly compatible with existing Internet mail protocols, and which wil be suitable for operation over the global Internet, including both wireless and wired -- links. And that was in 1999. I am curious to know what happened. In the mean time of course there has been the proprietary and patent full BlackBerry. Our real enemy are proprietary patented protocols. It would be hard to argue that existence of the WhiteBerry concept has done any harm. http://www.freeprotocols.org/operationWhiteberry/index.html Back to the topic at hand: Keith ... I don't see how it's relevant now. Again, all of this is in the context of: STRAW PROPOSAL RFC Editor charter where the key topics are: - Independence of RFC Publication Service - Relationship of IETF/IESG/IAB with the RFC Publication Service - Use of the RFC Publication Service by the Internet Community Tony gets it: On Sun, 19 Mar 2006 09:28:17 -0800, Tony Hain [EMAIL PROTECTED] said: Tony The point is that the past IESG practice which has driven out those who Tony would submit individual submissions, resulting in the current ratios, MUST Tony NOT become the guide for what SHOULD happen going forward. The RFC editor Tony role needs to be extricated from the overbearing IESG and returned to its Tony independent role. Doing otherwise further fragments the community which will Tony only lead to its downfall. From my perspective, based on past performance, the IETF/IESG/IAB can not be trusted to control the RFC Publication Service. ... Mohsen On Sun, 19 Mar 2006 08:08:10 -0500, Keith Moore moore@cs.utk.edu said: Harald The IESG pointed some of the issues out to the RFC Editor, who handled Harald the communication with the author; that was the procedure at that time. Harald Nevertheless, the RFC Editor felt that the document was worthy of Harald publication, and published anyway. As the written record clearly shows, this is factually incorrect. In the case of RFC-2188 the RFC Editor was no more than an IESG puppet. Publication was held up for more than 7 months, until finally Scott Bradner (Transport Area Director at the IESG) made it happen -- emphatically *not* the RFC Editor. Scott can step in, if he wishes. Keith I will go on record to say that I was the IESG member who did the most Keith to discourage publication of your document as an RFC. Contrary to Keith your perception of things, the RFC Editor published it over my strong Keith objections, and also insisted on diluting the IESG note that was Keith originally written for that document. I don't recall the reasons for Keith the delay other than the high workload of IESG (we were reviewing Keith dozens of documents per week, the fact that IESG discussed things in Keith conference calls every two weeks, and there were several iterations of Keith back-and-forth with the RFC Editor regarding your document. It is my Keith recollection that your document was handled much more quickly than Keith working group documents -- because unlike WG documents which proceeded Keith normally though the IESG's queue (and for which the speed of Keith processing was sensitive to IESG's workload), the RFC Editor had a Keith policy of giving IESG a limited amount of time to comment on Keith independent submissions that had the perverse side-effect of giving Keith priority to those submissions. Keith It was and still is my opinion that RFC 2188 was not suitable for Keith publication as an RFC, as it is poorly designed and has numerous Keith technical flaws. To have published this document IMHO dilutes the Keith quality of the RFC series and may confer an undeserved appearance of Keith acceptance on ESRO. Perhaps more importantly, the discussion about Keith this document wasted a colossal amount of time that could have been Keith put to much better use reviewing working group output (on the part of Keith the IESG) and editing better quality
Re: veni vidi exi
Eduardo, I'll take the word of anyone Eduardo Mendez wrote: Dear Mr. Chair, I never hidden I am involved in cultural policy. Actually, I represent a group of specialised colleagues. From EU Governments, EU Parliament, and International Organisations. Name them, if you can. If they exist, they may wonder who's claiming to represent them. We can now leave the IETF. We learned why technical intelligence is useful. I will ask someone to lurk for me. IETF is important to the users and to those who defend them. And I loved the cat and mice game. I didn't. Waste of time and resources. Mr. Halvestrand is correct. My name is not Eduardo Mendez. Good to know. When the IANA list is activated I may join it openly. As long as it uses an alias, I think I can do the same. Actually, I think I had to. Nonsense. Eduardo, if there is one person I know who is willing to say that he knows who you are, and that you are a different person from Jefsey Morfin, I'll stop thinking you're a Jefsey sock puppet. Until then... by their fruits shall you know them. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Noc 65 move
done - we should be back in business! -- 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: Complaints Against The IESG and The RFC-Editor About Publication of RFC-2188 (ESRO)
Dave Crocker wrote: This was eight years ago. The IESG that the complaint was made against was: Seems like there ought to be a statute of limitations. In the IETF process, that's two months. I presume that anybody who found the RFC 3932 (BCP 92) procedures unsatisfactory would have complained in 2004 when it was approved. Brian ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: veni vidi exi
Harald Alvestrand wrote: Eduardo, if there is one person I know who is willing to say that he knows who you are, and that you are a different person from Jefsey Morfin, I'll stop thinking you're a Jefsey sock puppet. What difference does it make? King Harald from Norway, no other member of IETF has spoken so much about censoring or banning people who believe different from your point of view. I hope it will not hurt too very much when you wake up one day and find you cannot communicate any longer because you are using an outdated character set and the root-servers you use have gone offline. Until then... by their fruits shall you know them. Just google for postings from King Harald Alvestrand Apropos If you think Eduardo Mendez, Joe Baptista, Jefsey Morphin and me are one person: Look at my and Karins homepge. My french is horrible with quebecois accent. My castellano is mixed with both itlian and french. And I dont speak portuguese yet. Maybe I shall learn. -- Peter and Karin Dambier The Public-Root Consortium Graeffstrasse 14 D-64646 Heppenheim +49(6252)671-788 (Telekom) +49(179)108-3978 (O2 Genion) +49(6252)750-308 (VoIP: sipgate.de) mail: [EMAIL PROTECTED] mail: [EMAIL PROTECTED] http://iason.site.voila.fr/ https://sourceforge.net/projects/iason/ ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Guidance needed on well known ports
Regardless of what the community consensus is on: 1. Are well known ports archaic? I want to comment that on this: If so, can we request that the IANA do away with the distinction? The IETF decides, and the IANA will then be responsible for implementing the decision. Brian ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: veni vidi exi
Dear all, Before this heats up too much, could all you, please, relax your tone and avoid what it can be considered personal attacks. Thanks in advance for your diligence. IETF Sergeant-at-arms De: Peter Dambier [EMAIL PROTECTED] Organización: Peter and Karin Dambier Responder a: [EMAIL PROTECTED] Fecha: Sun, 19 Mar 2006 23:22:55 +0100 Para: ietf@ietf.org ietf@ietf.org Asunto: Re: veni vidi exi Harald Alvestrand wrote: Eduardo, if there is one person I know who is willing to say that he knows who you are, and that you are a different person from Jefsey Morfin, I'll stop thinking you're a Jefsey sock puppet. What difference does it make? King Harald from Norway, no other member of IETF has spoken so much about censoring or banning people who believe different from your point of view. I hope it will not hurt too very much when you wake up one day and find you cannot communicate any longer because you are using an outdated character set and the root-servers you use have gone offline. Until then... by their fruits shall you know them. Just google for postings from King Harald Alvestrand Apropos If you think Eduardo Mendez, Joe Baptista, Jefsey Morphin and me are one person: Look at my and Karins homepge. My french is horrible with quebecois accent. My castellano is mixed with both itlian and french. And I dont speak portuguese yet. Maybe I shall learn. -- Peter and Karin Dambier The Public-Root Consortium Graeffstrasse 14 D-64646 Heppenheim +49(6252)671-788 (Telekom) +49(179)108-3978 (O2 Genion) +49(6252)750-308 (VoIP: sipgate.de) mail: [EMAIL PROTECTED] mail: [EMAIL PROTECTED] http://iason.site.voila.fr/ https://sourceforge.net/projects/iason/ ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf ** The IPv6 Portal: http://www.ipv6tf.org Barcelona 2005 Global IPv6 Summit Slides available at: http://www.ipv6-es.com This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Complaints Against The IESG and The RFC-Editor About Publication of RFC-2188 (ESRO)
You have totally confused ESRO with EMSD. RFC-2188 is different from RFC-2524. I stand corrected. Tony gets it: Tony The point is that the past IESG practice which has driven out those who Tony would submit individual submissions, resulting in the current ratios, MUST Tony NOT become the guide for what SHOULD happen going forward. The RFC editor Tony role needs to be extricated from the overbearing IESG and returned to its Tony independent role. Doing otherwise further fragments the community which will Tony only lead to its downfall. I strongly disagree with Tony that the IESG has been overbearing. From my perspective IESG has been too permissive. But perhaps this is beside the point. I believe that we need to have high standards for RFC publication - not just for working group documents or standards track documents but for all documents that are labeled RFCs. In order for that to happen, _someone_ has to do a thorough technical review of those documents, and that _someone_ has to be willing and empowered to reject documents that don't cut it. There are advantages to having IESG do that review (e.g. uniformity, lower cost) and advantages to having another party do that review (e.g. spreading the workload). I don't have a strong opinion about who does the review of non-standards-track, non-working-group documents, as long as the review is done and the document series is held to high standards. I will however caution against the assumption that IESG is inherently overbearing and a separate review function is inherently more reasonable. No matter who does the review there will always be the potential for capriciousness on the part of the reviewer. Similarly, no matter who does the review there will always be those who will insist that IETF lend its imprimatur to their flaky designs or poorly written documents, and who will consume valuable resources trying to degrade the RFC series. IMHO, it is vitally important that we avoid wasting either volunteer energy or money on such foolishness. Keith ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Complaints Against The IESG and The RFC-Editor About Publication of RFC-2188 (ESRO)
On Sun Mar 19 20:59:46 2006, Mohsen BANAN wrote: The only part of the IESG note that can be considered to have any aspect of legitimacy is: I say again, I examined RFC2524 is some detail, both because it was prior art in an area that was under heavy discussion at the time in Lemonade, and because you'd suggested it be a reference in the Lemonade Profile Bis draft, and concluded that the IESG note was correct in all its points, save that I cannot claim to have enough experience to look at ESRO in detail. Do you object to: a) The censorship of RFCs based on technical merit? (In other words, would you prefer to be able to publish any technical document, no matter how bad?) b) That the IESG is providing the technical review needed by the RFC Editor to ensure the RFC series maintains quality? c) That the RFC Editor chooses to publish the IESG's review, on occasion, in the actual document? As to your free protocol foundation and whiteberry projects, I'd never heard of either until you brought them up. That's certainly causing no harm. If they were popular projects pulling useful input away from the IETF and Lemonade respectively, I'd classify that as harm. Dave. -- You see things; and you say Why? But I dream things that never were; and I say Why not? - George Bernard Shaw ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Complaints Against The IESG and The RFC-Editor About Publication of RFC-2188 (ESRO)
I will however caution against the assumption that IESG is inherently overbearing and a separate review function is inherently more reasonable. No matter who does the review there will always be the potential for capriciousness on the part of the reviewer. It seems to me that while many prefer IESG review some believe it may not always be fair and balanced. So if I can make a suggestion, it would be good while defaulting to IESG review to also specify that submitter may challenge their review results and/or request an independent review from another source. So it would be good if we had some other organization or specified procedure on how RFC-Editor can request review from somebody other then IESG or some other then IETF-related body. Also it seems that not specifying how long review should take allows to delay document indefinitely, which is a form of rejection without officially saying so - so maximum time that review can take should be specified (say 6 months) and if results are not made available to author and RFC-Editor by end of this time, RFC-Editor default choice should be to publish as-is without any IESG note. -- William Leibzon Elan Networks [EMAIL PROTECTED] ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Complaints Against The IESG and The RFC-Editor About Publication of RFC-2188 (ESRO)
On Sun, 19 Mar 2006, Dave Cridland wrote: If they were popular projects pulling useful input away from the IETF and Lemonade respectively, I'd classify that as harm. Why? Harm to who and in what way? -- William Leibzon Elan Networks [EMAIL PROTECTED] ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Complaints Against The IESG and The RFC-Editor About Publication of RFC-2188 (ESRO)
I will however caution against the assumption that IESG is inherently overbearing and a separate review function is inherently more reasonable. No matter who does the review there will always be the potential for capriciousness on the part of the reviewer. It seems to me that while many prefer IESG review some believe it may not always be fair and balanced. Again, this will be true no matter who does the review. So if I can make a suggestion, it would be good while defaulting to IESG review to also specify that submitter may challenge their review results and/or request an independent review from another source. That sounds like an appeals process to me. It's not at all clear to me that we can afford the resources to give the privilege of appeal to mere individuals. Also it seems that not specifying how long review should take allows to delay document indefinitely That's a bit like saying that an SMTP server should not be able to delay mail indefinitely no matter how much SPAM it gets. There are a near-infinite number of simians with keyboards, while IETF review resources are (and always will be) finite and precious. So no matter who does the review for individual submissions, I think that it's perfectly reasonable for that reviewer to be able to say Sorry, we receive too many invididual submissions to review them all, and yours doesn't pass the smell test. You may wish to seek publication through other channels. This is no different than any other publisher. IETF is not a vanity press. Keith ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
IETF65 Network Status
The IETF65 network is deployed and operational. We are supporting IPv4 and IPv6. There is wireless running throughout the hotel (ssid is ietf65). The wireless supports IEEE 802.11a and 802.11b. You can find detailed information about the network on the IETF 65 website: http://www.ietf65.org This site also includes information on the meeting, social, tips and tools for using the wireless, noc, local information on Dallas (the Dallasinfo wiki including restaurants and other local info), ham radio (under meeting info), and more. If you encounter any network problem please open a ticket at: http://noc.ietf65.org/trac Regards, Bob (for the IETF65 NOC team) ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Complaints Against The IESG and The RFC-Editor About Publication of RFC-2188 (ESRO)
On Sun, 19 Mar 2006, Keith Moore wrote: I will however caution against the assumption that IESG is inherently overbearing and a separate review function is inherently more reasonable. No matter who does the review there will always be the potential for capriciousness on the part of the reviewer. It seems to me that while many prefer IESG review some believe it may not always be fair and balanced. Again, this will be true no matter who does the review. True. But if you want to make RFC-Editor a separate function from IETF/IESG you must allow it choices on who would do a review So if I can make a suggestion, it would be good while defaulting to IESG review to also specify that submitter may challenge their review results and/or request an independent review from another source. That sounds like an appeals process to me. Both appeals process and process where submitter if he thinks IETF is not fair in its reviews can request independent review in the first place (though IESG would still need to provide its review as to if there are any conflicts and may choose to provide additional technical review as additional input as well). The point being that technical reviews do not have to come exclusively from IESG and that rfc-editor should have access to multiple inputs deciding if publication is appropriate. It's not at all clear to me that we can afford the resources to give the privilege of appeal to mere individuals. Excuse me? What do you think IETF is or do you really prefer to see it officially turn into IVTF? Also it seems that not specifying how long review should take allows to delay document indefinitely That's a bit like saying that an SMTP server should not be able to delay mail indefinitely no matter how much SPAM it gets. It should not. If server is loaded with processing existing email, it should not delay processing longer and longer internally but directly start answering with 400 error. To turn this analogy (which I don't think is very good in the first place) to publication process - RFC editor can say that its overloaded and will not accept submissions in the first place, but if it accepted submission - there should be finite time in which it should be delayed within IESG review stage. There are a near-infinite number of simians with keyboards, while IETF review resources are (and always will be) finite and precious. So no matter who does the review for individual submissions, I think that it's perfectly reasonable for that reviewer to be able to say Sorry, we receive too many invididual submissions to review them all, and yours doesn't pass the smell test. No smell tests please just because you're overworked and don't have time for substantial review. Either all submissions are rejected due to load or none. RFC-Editor can report to ISOC and IETF if it begins to experience too high a load with individual reviews and request additional funding or input to improve its process to deal with this. However if I understand current situation, the individual publications requests directly to RFC Editor have not been anything close to serious issue and its IETF's own documents that require IESG review that put greatest stress on IESG workload and delays in RFC publication. You may wish to seek publication through other channels. This is no different than any other publisher. IETF is not a vanity press. The question here is about RFC Editor and its process. Original function of RFCs after all was to document internet protocols and how to use them to allow others to know what each protocol is about from common easily searchable source. IETF on the other hand is organization responsible with engineering standards for certain internet functions - that means it goes quite a bit further then just publication or approval of documents but actually is engaged in group effort to engineer the service/protocol where the need for such functionality exists. -- William Leibzon Elan Networks [EMAIL PROTECTED] ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Complaints Against The IESG and The RFC-Editor About Publication of RFC-2188 (ESRO)
It's not at all clear to me that we can afford the resources to give the privilege of appeal to mere individuals. Excuse me? What do you think IETF is or do you really prefer to see it officially turn into IVTF? IETF is, or should be, an engineering organization. Not a vanity press. IETF exists to benefit the entire Internet community, rather than authors wanting recognition or vendors wanting endorsement for their products. It's more important for IETF to produce good engineering than it is for anyone to be able to exhaust IETF's resources trying to get his or her way. Also it seems that not specifying how long review should take allows to delay document indefinitely That's a bit like saying that an SMTP server should not be able to delay mail indefinitely no matter how much SPAM it gets. It should not. If server is loaded with processing existing email, it should not delay processing longer and longer internally but directly start answering with 400 error. To turn this analogy (which I don't think is very good in the first place) to publication process - RFC editor can say that its overloaded and will not accept submissions in the first place, but if it accepted submission - there should be finite time in which it should be delayed within IESG review stage. SMTP servers can bounce with 400 errors also. There are a near-infinite number of simians with keyboards, while IETF review resources are (and always will be) finite and precious. So no matter who does the review for individual submissions, I think that it's perfectly reasonable for that reviewer to be able to say Sorry, we receive too many invididual submissions to review them all, and yours doesn't pass the smell test. No smell tests please just because you're overworked and don't have time for substantial review. Either all submissions are rejected due to load or none. Strongly disagree. When we reject a document we generally expect the reviewer to supply good reasons for rejecting and to explain what would make the document more deserving of publication. It's relatively easy to competently sift potential wheat from chaff. It's much harder to do full reviews where you explain what's wrong and how to fix it, and get into iterative negotiation with the author. RFC-Editor can report to ISOC and IETF if it begins to experience too high a load with individual reviews and request additional funding or input to improve its process to deal with this. I believe flow control is needed at every point in the system. However if I understand current situation, the individual publications requests directly to RFC Editor have not been anything close to serious issue if working with the Internet for 20 years has taught me anything, it's that any hole that exists will someday be exploited, and soon after that, will be exploited massively. You may wish to seek publication through other channels. This is no different than any other publisher. IETF is not a vanity press. The question here is about RFC Editor and its process. Original function of RFCs after all was to document internet protocols and how to use them to allow others to know what each protocol is about from common easily searchable source. most things evolve over time, including RFCs and IETF. either that or they become extinct. Keith ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Complaints Against The IESG and The RFC-Editor About Publication of RFC-2188 (ESRO)
At 02:44 20/03/2006, Keith Moore wrote: It's not at all clear to me that we can afford the resources to give the privilege of appeal to mere individuals. Excuse me? What do you think IETF is or do you really prefer to see it officially turn into IVTF? IETF is, or should be, an engineering organization. Not a vanity press. IETF exists to benefit the entire Internet community, rather than authors wanting recognition or vendors wanting endorsement for their products. Sorry. This was before RFC 3935. The IETF exists to infuence people on the way to design use and manage the Internet. And this is worth gold. It's more important for IETF to produce good engineering than it is for anyone to be able to exhaust IETF's resources trying to get his or her way. Agreed. The problem is the IANA. A key registry is worth gold too. Good engineering or not, some interests want to go through. jfc ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Guidance needed on well known ports
Hallam-Baker, Phillip wrote: From: Joe Touch [mailto:[EMAIL PROTECTED] And with what port would I reach this magical DNS that would provide the SRV record for the DNS itself? You use fixed ports for the bootstrap process and only for the bootstrap process. Which means that the DNS port needs to be well-known or fixed in advance. Some other issues to be considered: - this change would make the DNS required for proper Internet operation, whereas it is currently optional (i.e., only for finding the IP address).] - hosts may run services but not have control over their own DNS entry (or SRV records) - firewalling based on ports would no longer be useful (one could argue it should not be, but that's a different issue) Fixed ports do not work behind NAT. Anyone who wants to deploy IPv6 would be well advised to pay careful attention to that restriction. SRV ports work just fine behind a NAT. Except that many NATs also intercept DNS requests and redirect them to their own servers, for their own purposes, which can interfere with SRV records (by design). People who do this are rarely trying to break things. They don't *try* to break things, but then tend to. ;-) As to 'by design', they're not so much trying to break as to 'help' (usually for their own purposes). Joe ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Protocol Action: 'A One-way Active Measurement Protocol (OWAMP)' to Proposed Standard
The IESG has approved the following document: - 'A One-way Active Measurement Protocol (OWAMP) ' draft-ietf-ippm-owdp-16.txt as a Proposed Standard This document is the product of the IP Performance Metrics Working Group. The IESG contact persons are Allison Mankin and Jon Peterson. A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ippm-owdp-16.txt Technical Summary With growing availability of good time sources to network nodes, it becomes increasingly possible to measure one-way IP performance metrics with high precision. To do so in an interoperable manner, a common protocol for such measurements is required. The One-Way Active Measurement Protocol (OWAMP) can measure one-way delay, as well as other unidirectional characteristics, such as one-way loss. This document is an implementation of the requirements draft (RFC 3763) published earlier. Working Group Summary The working group extensively worked on requirements for this protocol (which were approved by the IESG in 2004 and published as RFC 3763), and in general, developed this protocol for about three years, with a great deal of participation and discussion from experience. The decision to advance had strong working group support. There were no IETF Last Call comments. Protocol Quality Three implementations of the protocol exist, a forth h site has indicated that they will implement this. This protocol sits on top of IPPM metrics (RFC2330, 2678-2681). The group of users of these metrics have all expressed interest in this protocol. The security section of RFC3763 took a long time to complete. In order to make sure that this document met the security requirements set for in that document, a security review has been done by Sam Weiler. His comments have been incorporated. The Responsible Area Director also reviewed the document against RFC 3763, and the shepherding Chair, Henk Uijterwaal, reviewed the detailed security support. There was extensive work with one of the Security Area Directors, Russ Housley, to ensure that the security protocols were valid. Henk Uitjerwaal has shepherded this specification. Notes to the RFC Editor [a final issue of the Security review] Section 3.1, Connection Setup OLD: In unauthenticated mode, KeyID, Token, and Client-IV are unused. Otherwise, KeyID is a UTF-8 string, up to 80 octets in length (if the string is shorter, it is padded with zero octets), that tells the server which shared secret the client wishes to use to authenticate or encrypt, while Token is the concatenation of a 16-octet challenge and a 16-octet Session-key, encrypted using the AES (Advanced Encryption Standard) [AES] in Cipher Block Chaining (CBC). Encryption MUST be performed using an Initialization Vector (IV) of zero and a key derived from the shared secret associated with KeyID. (Both the server and the client use the same mappings from KeyIDs to shared secrets. The server, being prepared to conduct sessions with more than one client, uses KeyIDs to choose the appropriate secret key; a client would typically have different secret keys for different servers. The situation is analogous to that with passwords.) NEW: In unauthenticated mode, KeyID, Token, and Client-IV are unused. Otherwise, KeyID is a UTF-8 string, up to 80 octets in length (if the string is shorter, it is padded with zero octets), that tells the server which shared secret the client wishes to use to authenticate or encrypt, while Token is the concatenation of a 16-octet challenge, a 16-octet Session-key used for encryption, and a 32-octet HMAC-SHA1 Session-key used for authentication. The token itself is encrypted using the AES (Advanced Encryption Standard) [AES] in Cipher Block Chaining (CBC). Encryption MUST be performed using an Initialization Vector (IV) of zero and a key derived from the shared secret associated with KeyID. (Both the server and the client use the same mappings from KeyIDs to shared secrets. The server, being prepared to conduct sessions with more than one client, uses KeyIDs to choose the appropriate secret key; a client would typically have different secret keys for different servers. The situation is analogous to that with passwords.) OLD: The shared secret is a passphrase; it MUST not contain newlines. The secret key is derived from the passphrase using a password-based key derivation function PBKDF2 (PKCS #5) [RFC2898]. The PBKDF2 function requires several parameters: the PRF is HMAC-SHA1 [RFC2104]; the salt and count are as transmitted by the server. Session-key and Client-IV are generated randomly by the client. Session-key MUST be generated with sufficient entropy not to reduce the security of the underlying cipher [RFC4086]. NEW: The shared secret is a passphrase; it MUST not contain newlines. The secret key is derived from the passphrase
