Re: Nomcom process realities of confidentiality
Nomcom is a group of people randomly selected from among a set of folks whose only qualifications are that they want to be on nomcom and they like traveling to meetings. well, in the planning meeting, i think i suggested that only people who didn't want to be on the nomcom should be eligible, but folks seemed to think this would constitute cruel and unusual punishment. the sad fact is that in the absence of rigorous membership qualifications, identifying folks who have been able to attend recent meetings is the only objective criteria we could find. if we could have switched from meeting attendance to rfc authorship, but then the environmentalists would be upset because there would be 50 or so authors on each rfc, thereby resulting in a larger carbon footprint for ietf activities (printing, bandwidth usage, etc.) /mtr ___ IETF mailing list IETF@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Lets be careful with those XML submissions to the RFC Editor
Another option is that the RFC Editor should be more careful. It really isn't that hard for the RFC Editor to run xml2rfc on the XML file and wdiff it against the draft that is approved by the IESG, and bring noticeable differences to the two parties. agreed. at the risk of stating the obvious: the problem is identical to the one where the authors submit nroff source to the rfc-editor. it's always a good idea to run the toolchain, and then diff the text against the I-D approved by the IESG. if there's a difference, the relevant ADs and authors need to get on the same page. /mtr ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Lets be careful with those XML submissions to the RFC Editor
agreed. at the risk of stating the obvious: the problem is identical to the one where the authors submit nroff source to the rfc-editor. it's always a good idea to run the toolchain, and then diff the text against the I-D approved by the IESG. if there's a difference, the relevant ADs and authors need to get on the same page. And all of this, incidentally, is what the RFC Editor and ADs do... ok, so the current process is adequate, we just need to be a little more careful in following it, right? /mtr ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Problems with xml.resource.org
I'm seeing xml.resource.org timing out today, and it seems consistent on one of the two returned IPv4 addresses I see for it (192.20.225.40). the server broke and is being rebuilt. we'll remove the A RR for that ip address until it's fixed. /mtr ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: XML2RFC submission (was Re: ASCII art)
- Making XML-RFC versions of existing or new RFCs available to the public. many can be found at http://xml.resource.org/public/rfc/xml/ i'm sure that other people have other repositories. /mtr ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Reexamining premises (was Re: UN plans to take over our job!)
For those who do not know the history, are curious, or who might find themselves in the position of advising those who are part of these discussions, Appendix C to Marshall Rose's _The Internet Message: Closing the Book with Electronic Mail_, Prentice-Hall, 1993 makes extremely illuminating and entertaining reading. With a dozen year's hindsight, I'd go so far as to suggest that Marshall's observations about OSI and the process that produced it were too optimistic. all too true! /mtr ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: BOF: SLRRP
On Feb 24, 2005, at 06:55, Michael Thomas wrote: Isn't putting not just one, but _two_ diminutives into a name severely tempting the gods? almost certainly. further, some folks just don't like rfid, so we've got a triple crown going... /mtr ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
BOF: SLRRP
From: [EMAIL PROTECTED] Subject:BOF: SLRRP Date: February 23, 2005 09:07:15 PST To: i-d-announce@ietf.org Cc: [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED] may i draw your attention to the Simple Lightweight RFID Reader Protocol BOF being held at IETF 62? it is tentatively scheduled for tuesday, march 8th, from 1300-1500. in brief: rf transponder readers are getting networked, and are being managed by controllers. this bof shall determine whether the ietf should charter a wg for the purpose of standardizing the management protocol between readers and controllers. a more comprehensive description is at: http://www.ietf.org/ietf/05mar/slrrp.txt thanks! /mtr ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Jabber at ietf60
On Aug 03, 2004, at 09:59, Hadmut Danisch wrote: Does this server allow to register an account? Or which server should I use to do so? for instructions, take a look at: http://xmpp.org/ietf-chat.html ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
REVISED ANNOUNCEMENT Interim MARID Working Group Meeting
An interim meeting of the MARID WG will be held in Campbell, California on May 19-20, 2004. The meeting will start at noon on Wednesday the 19th and continue until early evening on Thursday the 20th. This meeting corresponds to the second milestone of MARID's charter http://www.ietf.org/html.charters/marid-charter.html i.e., May 2004: Interim Meeting. Focus on required semantics for MTA authorization; syntax discussions An agenda will follow shortly on the ietf-mxcomp mailing list (subscription requests to [EMAIL PROTECTED] -- put Subscribe in the body). The logistics for the meeting are: When: May 19 12:00-17:30 (all times us/pacific) May 20 08:30-17:30 Where: Qualcomm / 675 Campbell Technology Parkway / Campbell, CA 95008 Also: 802.11b and lunch will be provided Visitor badges will be required Hotel: Pruneyard Inn / 1995 South Bascom Avenue / Campbell, CA 95008 (other hotels are nearby) Note: If you have special dietary requirements, please contact the co-chairs privately. Campbell is served by three international airports: San Jose, San Francisco, and Oakland. For those unable to attend in person, a simultaneous xmpp chat will take place at [EMAIL PROTECTED] The meeting place is accessible for people with disabilities. The co-chairs express their thanks to Ted Hardie and Qualcomm for hosting this meeting. ___ IETF-Announce mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf-announce
Re: A modest proposal - allow the ID repository to hold xml
I don't know about about you, Paul, but I'm writing my drafts using EMACS and Marshall's tool. That allows for generation of HTML, NROFF, and text. The HTML allows for hyperlinks, which is REALLY nice. and for folks who are of the xslt persusasion, julian's html output is very sweet... /mtr ps: the point being, that there's not just one tool that works with this stuff... pps: oh, and did i mention the every expanding bibliographic libraries already in 2629... the 3gpp reference set is coming up later this week (thanks miguel!)
Re: A modest proposal - allow the ID repository to hold xml
I'm not sure how to address the problem with legacy RFCs. I'll bet we could find volunteers to generate XML equivalents from the existing plain text documents. (We would need an XML tag to indicate which of the plain text or XML documents is considered authoritative.) actually, carl malamud and brad burdick wrote a script back in 99 that had a 20% success rate on the legacy rfcs. the (unofficial) xml versions of those rfcs is available online. steven connor did some work for me after that to produce xml versions of the remaining rfcs which excluded the middle (i.e., just the front matter and references sections got translated). so, it's not as much work as you'd think, but still far more work than i'd like... /mtr
Re: WG Review: Centralized Conferencing (xcon)
An understandable interpretation of my words (especially taken out of the context of the larger point I was trying to make), but not what I intended. That paragraph was intended to convey what I perceived the overall feel of the participants in the BOF to be. Any decisions, of course, will be taken to the working group for consensus. good. sorry for the confusion! /mtr
Re: WG Review: Centralized Conferencing (xcon)
here is your reply to me: the xmpp folks have a workable, deployed solution in the conferencing space. if they decide to take this work to the ietf, then that should also be accorded the same courtesy in being judged on its merits in the context of xmpp. I can understand that you have concerns that XCON may produce something so generally useful that it might get in the way of rubber stamping protocols developed elsewhere. I do not believe that it is in the greater interest of the IETF, though, to intentionally cripple working groups merely to allow for the eventuality of the introduction of competing work. here is your reply to richard ... However, the proposed solutions (all of which I expect to instantly be accepted as working group items in the case that the working group is chartered) demonstrate no such binding. ... accordingly, i think your statement regarding rubber stamping is pointed in the wrong direction... in addition to the controversial wording in the proposed charter, we now have an issue regarding bias on the part of the proposed chairs... /mtr
Re: WG Review: Centralized Conferencing (xcon)
As for Marshall's comments: there is certainly nothing nefarious about having a large body of source work when trying to start a Working Group (I cite XMPP as a recent example). What is important is for folks to focus on the *charter text* and the desired output, rather than make assumptions about the intent of those contributors. and, as has been repeatedly pointed out, the text in the proposed charter is rather poor. we now have four sets of people with entirely different interpretations (some from the SIP camp, some from the XMPP camp, plus the IETF chair). Marshall, if there is something specific that you don't like about the charter as a generic conferencing working group, please propose alternate rewording. that's easy: 1,$s/conferencing/SIP-based conferencing/g /mtr
Re: WG Review: Centralized Conferencing (xcon)
I think the XCON folks were trying to be inclusive in their charter development but frankly I don't think its necessary. The IETF now has three SIP related WG's operating well and producing good work and the scope of the XCON proposal IMHO should be directed at SIP specifically. Its a complex issue, there is a real problem statement and a focused WG could tackle the problem head on and deliver results. This was the direction we took with SIPPING for the specific IM problem and its what we need to do with SIP Conferencing. richard - unfortunately, this isn't what the proposed charter says or intends. i'll repeat what i've said twice before, but i'll use different words: if the sip folks want to have a working group to work on sip-specific conferencing, fine. we can judge the charter on its merits in the context of sip. the xmpp folks have a workable, deployed solution in the conferencing space. if they decide to take this work to the ietf, then that should also be accorded the same courtesy in being judged on its merits in the context of xmpp. the proposed charter (and jon's clarifications) have a considerably larger scope than doing sip-specific conferencing. further, it is disingenuous to say that other perspectives will be considered, because, to paraphrase sinnreich: there is but one god, and it's name is sip. so, as much as i enjoy these little skirmishes, i repeat my call for peace: tailor the proposed charter so that it limits itself to sip-specific conference, and no one outside of the sip community will much care... /mtr
Re: WG Review: Centralized Conferencing (xcon)
jon - sorry for the delay in replying. fundamentally, i think it comes down to accuracy in labelling. if the sip folks want to do conferencing, then they should have a working group to do that. however, the charter for that working group should not imply that the scope of the working group is anything beyond sip. a reasonable person reading the charter would conclude that the scope of the working group is somewhat more generic than sip. if the goal for this working group is to be generic, then the charter is likely unacceptable since it assumes facts not entered into evidence, i.e., it is sip-centric, and there is a fair body of deployed work that manages to do conferencing very well without using that acronym. if that is not the intention, then i suggest that the working group be called something like sipxcon to avoid any confusion. as to whether the working group belongs in apps or tsv, a generic conferencing working group clearly belongs in apps. however, a sip-specific working group can probably comfortably reside in either. /mtr
Re: WG Review: Centralized Conferencing (xcon)
[ resent to general discussion list... ] A new IETF working group has been proposed in the Transport Area. The IESG has not made any determination as yet. The following description was submitted, and is provided for informational purposes only: Centralized Conferencing (xcon) --- Current Status: Proposed Working Group Description of Working Group: ... Initially this combination of protocols will be specified with respect to session setup with SIP. The solutions developed in XCON will not preclude operation with other signaling protocols; however it is anticipated that the use of other protocols would require modifications which are out of scope for this working group. None of the protocols defined by this group will be SIP, although the SIP specific event notification framework will be used. The group will use the high-level requirements and framework already described by documents published by the SIPPING WG. may i inquire as to why this working group is SIP-specific? or more accurately, why does this charter say it isn't SIP-specific, when the contrary is true. for example, in the xmpp commuinity, there's a robust and well-implemented specification for multi-user chat which arguably provides a superset of the proposed xcon work product (cf., http://www.jabber.org/jeps/jep-0045.html) if the proposed working group is going to develop something for SIP, then the charter should say so. if the proposed working group is going to develop something general-purpose, then the charter should reflect reality by requiring an evaluation of existing solutions to this space, as is usual for working groups that are not starting with an existing specification... thanks! /mtr
Re: Response from a former IMPP Chair (Re: Last Call: A Model forPresence and Instant Messaging to Proposed Standard)
WRITTEN IN MY ROLE AS FORMER IMPP CHAIR harold - as indicated in my previous note, here is a reply! although i'm the only address listed on the From: line, that's a limitation of the mail client i'm using. please consider this a note from Marshall and Dave. so, we'll start at the end of your reply, because that's more direct. My conclusions: The working group has suffered from very slow document updates, a bad error in judgment (mine) re charter update, and repeated re-raising of old closed issues (for instance, at Atlanta in November 2002, Dave Crocker could be heard re-raising the issue of the need for loop control, which the group had discussed and decided in December 2000, choosing hopcount as the preferred mechanism in March 2001). However, I find the criticisms raised against the process leading to the forwarding of these documents to the IESG to be very much off target. we confess that we're a bit disappointed with your response. we spent considerable effort laying out a detailed complaint, and even included a table of contents, viz., 1. PROCESS FAILURES 1.1. Lack of participation and constituency 1.2. Out of scope with charter 1.3. Failure to resolve issues raised in the working group 2. TECHNICAL FAILURES 2.1. Confused and conflicting goals 2.2. Incomplete and unclear specifications. but you addressed the least interesting of these. perhaps issue 2.2 can be handled by applying some engineering and editing. yet they weren't, when they were raised in the working group. as things stand, the document is simply not viable on its own. the other issue you addressed is issue 1.3, while we might quibble with your timeline, we think you're missing the big picture, which is bleak. the work has no serious constituency. it cannot perform the task it describes for itself, as a gateway between heterogeneous services. few people created the work. few are interested in using it. in other words, issues 1.1, 1.2, and 2.1 are fatal. they're also essentially un-arguable. (or rather, no one's popped up to argue with us over them and it's been a month, eh?) issue 2.1 tells us that the documents are going to be a failure in theory, and issue 1.1 tells us that the documents are going to be a failure in practice. finally, issue 1.2 tell us that we're not even following our own rules. charters matter. otherwise, why have them? sanctity of the charter is perhaps the single most sacred aspect of the way we do things. we confess, if the work were good, we could look the other way on the process problems. but, let's face it, no one is arguing that we're talking about a quality work product here. in fact, no one is even arguing that the work product is going to see any meaningful use in production. for the life of us, we can't figure out why anyone would want to defend this work... /mtr ps: secondary to the fatal problems with the specification, your note cited other process issues. you claim that a working group meeting was not held due to failures of the document's editor to revise the document between february and november, 2001. presumably you mean the cpim main document, rather than the msgfmt, pidf or datetime documents that were revised during that time. fortunately, your former co-chair's (Un)updated todos note of 14 oct and the cpim document editor's note of 29 oct make clear that the real reasons for not holding a meeting, which has nothing to do with the editor...
Re: Response from a former IMPP Chair (Re: Last Call: A Model forPresence and Instant Messaging to Proposed Standard)
WRITTEN IN MY ROLE AS FORMER IMPP CHAIR Dave and Marshall, ... harald - first, thanks very much for the note. dave and i are having a bit of trouble co-ordinating our post-vienna schedules, so it will probably be a couple of days before we can respond in full to your reply. (but, don't worry... we will!) in the meantime, may i ask a question: it was unclear to me whether your reply was meant as an alternative interpretation of events or an actual rebuttal. if the former, that's fine. if the latter, then there were a large number of things which you just skipped over. should i interpret that as your agreement, or, if not, do you plan on discussing those issues in the future. of course, if you didn't intend to address those issues, that's fine. i'm just trying to figure out your position with respect to the breadth of material we presented. thanks! /mtr
Re: IETF jabber howto pointers please?
Could somebody re-post a pointer to the canonical 'IETF jabber' howto please? the various archived documents seem to be a twisty maze. the archives for sessions I found were for March, nothing current. briefly: login to your jabber as usual you will find conference rooms at ietf.jabber.at try the hallway room first... /mtr
jabber at ietf57
we had some server instability this afternoon... looks like it's resolved now! /mtr
text conferencing at ietf57
Remote Access for the 57th IETF meeting in Vienna: Text Conferencing At each IETF meeting, two of the working group meeting rooms are equipped for video multicast and remote participation. That is, for every IETF meeting slot, two of the working groups can see and hear the meeting. For the 57th IETF, in *addition* to the usual network A/V, text conferencing will be provided for every working group that meets. All of the conference rooms will be hosted on ietf.jabber.at and each is named using the official IETF abbreviation found in the agenda (e.g., apparea, dhc, forces, and so on -- for all the examples that follow, we'll use foobar as the abbreviation). Each conference room also has a 'bot which records everything that gets sent. So, the minute taker can review this information right after the meeting. In addition to the conference rooms for each wg that is meeting, there are three others of general interest: bar, hallway, and plenary. 1. Before the meeting: 1.1. If you want to participate If you don't already have one, get yourself a Jabber client, here are some suggestions: platformsuggestion -- win32 http://exodus.jabberstudio.org 'nixhttp://gabber.sf.net macos http://jabberfox.sf.net When you start the client for the first time, it will eventually ask if you want to register on a public server. Go ahead and do that. If you want to find out more, instead of choosing these defaults, here are pointers to some additional information: list of clients:http://www.jabber.org/user/clientlist.php howto:http://www.jabber.org/user/userguide/ server list:http://www.jabber.org/user/publicservers.php To make sure everything is running ok, do a Join Group Chat with your Jabber client: Group/Room: hallway Server: ietf.jabber.at This conference room is up and running right now (although probably no one will be in it when you connect). 1.2. What the Chair does If you want to make text conferencing available, you'll need to have a volunteer scribe in the meeting room. The scribe will be typing in a running commentary as to what's going on in the room (who's presenting, what question is being asked, etc.) So, why not send an email out on the mailing list now, before the meeting, to ask for volunteers? 2. At the meeting 2.1. What the Chair does When a session starts, the chair asks if someone in the room is willing to act as scribe. If no one volunteers, read no further, we're done! Otherwise, the scribe should do a Join Group Chat with their Jabber client, e.g., Group/Room: foobar Server: ietf.jabber.at 2.2. What the Scribe does The scribe types in a running commentary as to what's going on in the room. For example, if a speaker makes a presentation, the scribe types in the URL for the presentation (more on this in a bit). Simlarly, during question time, a remote participant can type a question into the room and the scribe can pass it on to the speaker. 2.3. What each Presenter does Each presenter should put a copy of their presentation on a web server somewhere, so remote participants can follow along. 2.4. Where to find the conference log http://ietf.jabber.at/logs/ ###
Re: Last Call: A Model for Presence and Instant Messaging toProposed Standard
Given a previous exchange with Marshall on his proposed actions, I'd like to be absolutely clear here on the intent of the message: Is this message your joint response to the Last Call? yes. Is this message an appeal of one or more decisions? no. thanks! /mtr
Re: Text Conferencing for the 56th IETF meeting in San Francisco
Marshall- Is there a way to browse available IETF jabber conferences? yes, but the client you're using may not implement it. in general, what you're looking for is a button/menu-item that says browse. when you select this, on my client, i get a window asking for a server name. if i enter conference.ietf.jabber.com, then i get a list of the conference rooms there. i can then double-click on a room to join, etc... if your client doesn't implement browsing, you can just do a join by clicking on join group chat... and entering: server: conference.ietf.jabber.com room: use the secretariat acronym, e.g., dccp nickname: and away you go. /mtr
Re: Text Conferencing for the 56th IETF meeting in San Francisco
I see. So, it is demo.jabber.com, port 5269? i have no idea...i just type in the domain name and it works. SRV records *do* make diagnostics hard, since I can not confirm that a host is alive with ping yeah, but i guess the question is why? it would be helpful if you could tell me what diagnostic you're seeing when you try to join a room... Marshall i'll ask the ops guys to install an A RR, but you should be Marshall able to join Thank you. *gabber* does not understand the SRV construct is seems. hmmm... i tried gabber by just typing in the domain name, and it worked ok. Also, with gabber, it seems that all the userids' that I've made up are in use already. if someone is already in a conference room with a given nickname, the room won't let a second person in with the same nickname... /mtr
Re: Text Conferencing for the 56th IETF meeting in San Francisco(fwd)
For those interested in text conferencing using standardized protocols, there is a SIMPLE2Jabber gateway running at iptel.org. See http://www.iptel.org/ietf56/ for instructions how to use it. in the interests of world peace, can we avoid making political statements on the ietf-general list... /mtr
Re: jabber note-takers
What is the policy this time? Are chairs encouraged or strongly encouraged to provide note-takers for the conference room? in the absence of a specific request from the iesg, i'd say it's up to the chair. little harm in asking at the beginning of the meeting, right? /mtr
Re: Text Conferencing for the 56th IETF meeting in San Francisco
Marshall conference.ietf.jabber.com This name is still not in DNS... Is it still planned? it got turned on last monday. i'm sitting in three conference rooms now. look for an SRV RR under _jabber._tcp.conference.ietf.jabber.com i'll ask the ops guys to install an A RR, but you should be able to join the conference room just fine without it... /mtr
Re: Financial state of the IETF - to be presented Wednesday
On Wednesday at the IESG plenary, I'm doing a presentation about IETF financials. ... harald - many thanks for making this material available. would it be possible for you to provide just a slight amount of additional material in your presentation, specifically, could we get a breakdown of the following meeting costs: - food - connectivity/terminal room/etc. - other major items it's hard to figure out what to optimize unless we understand the relative sizes of these things. for example, my gut reaction is to say just cancel the food on the theory that people can pay for this themselves, with a very small efficiency hit. in contrast, having everyone arrange their own connectivity would be amusing, but highly inefficient. /mtr
Re: Financial state of the IETF - to be presented Wednesday
harald - many thanks for making this material available. would it be possible for you to provide just a slight amount of additional material in your presentation, specifically, could we get a breakdown of the following meeting costs: - food - connectivity/terminal room/etc. - other major items The 2001 figures are available on the IETF Chair's pages - the 2002 figures aren't that much different. They will be published at the same level of details as soon as the auditors are done with them; I summed these together until they were reasonably legible when printed on a slide thanks! to quote from http://www.ietf.org/u/chair/financials.html : - Food Beverage $862,500 - Audio/Visual$127,337 - Room Rental $190,265 - Other Meeting Exp $1,925 Total IETF Meeting Expenses $1,182,027 ... The cost for food and beverage covers participants' breakfasts, coffe and break food at IETF events. In the US, this is one way in which hotels recover the cost of meeting rooms; in one recent query, the secretariat got a quote on meeting rooms without food for USD 238.000 (at 50% off list price). At a similar meeting where we got the meeting rooms for free, our food and beverages bill was approximately USD 250.000. Outside the US, we are usually charged separately for the meeting rooms and the food. check the notes on the 2001 page - it seems that hotels in the US want to take just about the same amount off us for meeting rooms + food as they would otherwise take for the meeting rooms alone. Bizarre, but that seems to be the case. maybe i'm not following, but it looks like (food + meeting room) / 3 = $350,921 which is still $113K more than getting the meeting rooms only. In the case of a 30-minute break, I think it actually pays for itself in terms of manpower time - the time spent snarfing cookie + coffee and continuing conversation is a lot more productive than the time spent in the queue at Starbuck's, bolting the coffee and then jumping back into the next meeting. OTOH, perhaps people could live from lunch to dinner without cookies??? harald, please, banks takes cash, not goodwill. if we want to say it pays for itself, then someone better start collecting money for the food. i suppose we could say that the meeting rooms are subsidizing the food, but frankly, i'd prefer that we didn't spend the additional $340K/year, and folks who want food can have breakfast at the hotel restaurant and snacks at whatever's available at the lobby level. now maybe we can't get a better deal 'cause the hotels know they have a racket. fine. however, we still fill-up whatever hotel we end up. perhaps we ought to pick one or two hotels to have meetings at and do a multi-year contract. given the sorry state of the economy, seems to me that we ought to be able to find a hotel willing to do a deal. we can even follow casner's lead and book a hotel in silicon valley. the one thing that the 2001 numbers don't tell us is what we're spending on the terminal rooms (since in 2001 they were donated, hoorah!). seems to me that the only thing we should be providing is wifi/10bT and maybe a printer or two. anyone who can't bring a laptop to an ietf meeting is probably doesn't need connectivity anyway... i'm sure wednesday night there will be a spirited discussion... /mtr
Re: movies vs chat logs
the jabber logs were useless, at best s/he is talking about X now with no idea of what was said, how it was justified, what the reactions were, ... note that i am a jabber user, run a jabber server, ... so it is not anti-jabber prejudice. it just seemed not to work in this particular context for this particular use. perhaps it kept folk with insufficient email amused during boring times :-). as someone who was in atlanta, the jabber conferencing allowed me to be in two places at once, and gauge which room(s) i needed to be in... were some logs more useful to you than others? if so, what features of that logging was helpful. since we've got another meeting coming up in a month, now would be a good time for us to start giving advice to folks... /mtr
Re: Dan Bernstein's issues about namedroppers list operation
On Fri, 10 Jan 2003, Thomas Narten wrote: Dan Bernstein has been making repeated claims that Randy is censoring his postings to namedroppers. I took a look at the claims he has made and here is how I see things. Executive summary: I see no evidence that Randy is censoring postings from Dan. It is the case that some of his messages do not appear to have made it out on namedroppers, but it is unclear why this is. [..] It does appear that *some* of the message that Dan has sent to namedroppers have not appeared on the namedroppers mailing list. But it is unclear why that happened. In other words, you see no evidence that Bush _isn't_ censoring postings from Bernstein. when someone develops the technology to prove a negative, let me know, because from there it's just a quick hop, skip, and a jump to building a time-machine. /mtr
Re: naming debates
We like the way ostriches deal with things they do not wish to see ;-)... listen to this very carefully: GET YOUR ENDLESS DNS RANTS OFF OF THE IETF DISCUSSION LIST this has been going on for over a decade and reasonable people have grown tired of it. there is absolutely nothing of technical interest in any of this discussion. it's just a DDOS against thousands of mailboxes. TAKE IT ELSEWHERE if you don't like the list that rick suggested, that's fine. use another, non-technical list. may i humbly ask harold to start dropping folks from ietf-general who continue to post on this topic? we've already had a couple of warning shots on this, so i think it's perfectly reasonable to view persistent offenders as having fallen into the fleming category. let's nuke'em for a year and move on. kind regards, /mtr
Re: the 'hallway' jabber group chat
Are there any plans to keep the conferences (and logger) past the IETF meeting? I was thinking about interim wg meetings and such. good question. i'll look into it. /mtr
Re: the 'hallway' jabber group chat
Is there any way to find list and short desciption of all chatgroups ? If so, it will be easier to announce and find chatgroups. hi. many, though not all, clients, have a jabber browser function that lets you type in a server name (e.g., conference.ietf.jabber.com) and it will give you a drop-down of the rooms there. i've noticed somewhat spotty coverage in the client-side implementation though... in general though, just use the secretariat acronym, e.g., saag. there is also plenary and hallway. /mtr
Re: After 1 day... Re: text conferencing at the 55th IETF meeting in Atlanta
Let me say I really like the text conferencing experiment so far. It's pretty cool to get a chance to have an idea of what's going on in sessions you can't split yourself to attend. thanks. certainly the unexpected result (for me) is that it's really useful for the attendees -- initially, i thought this was primarily going to be a big help for folks who couldn't physically get to the meeting. /mtr
text conferencing at the 55th IETF meeting in Atlanta
Remote Access for the 55th IETF meeting in Atlanta: Text Conferencing At each IETF meeting, two of the working group meeting rooms are equipped for video multicast and remote participation. That is, for every IETF meeting slot, two of the working groups can see and hear the meeting. For the 55th IETF, in *addition* to the usual network A/V, text conferencing will be provided for every working group that meets. All of the conference rooms are hosted on conference.ietf.jabber.com and each is named using the official IETF abbreviation found in the agenda (e.g., apparea, dhc, forces, and so on -- for all the examples that follow, we'll use foobar as the abbreviation). Each conference room also has a 'bot which records everything that gets sent: http://www.jabber.com/chatbot/logs/conference.ietf.jabber.com/foobar/ Enjoy! /mtr
Re: text conferencing at the 55th IETF meeting in Atlanta
In message [EMAIL PROTECTED], Marsha ll Rose writes: Each conference room also has a 'bot which records everything that gets sent: http://www.jabber.com/chatbot/logs/conference.ietf.jabber.com/foobar/ Will you keep those Web pages up for a while? sure. Depending on what is typed, they can be a useful supplement to the work of the scribe. exactly! /mtr
Re: text conferencing at the 55th IETF meeting in Atlanta
Marshall Rose wrote: Each conference room also has a 'bot which records everything that gets sent: Very nice. Can these logs be included in the minutes, or alongside them? that's up to the minute taker. remember that there isn't a moderator in the chatrooms, so it's not really a record, per se. /mtr
Re: Jabber BOF afterthoughts
randy - hi. i'm a little confused about the exchanges this morning, so bear with me. i have no idea if this is an issue here, as i am not in contact with w3c or whomever else. i expect you, pete, etc. will know far better than i if we are nearing hot water here. i am just asking you to please be conscious of the issue. this is a fair point. there is no w3c effort on instant messaging, while soap is certainly a w3c effort, i think most folks would be hard-pressed to find much overlap between it and jabber, other than the fact that they both use xml at different points in their stack. fwiw i have nothing against jabber. some of my best friends jabber :-). i am even trying to get a secure jabber server working (and am hitting problems). i am just concerned about process and precedent. send me a private note explaining the difficulty, and maybe i can help. /mtr
Re: Jabber BOF afterthoughts
[ lots of stuff deleted that was designed to distract... ] But I wish that those proponents of a Jabber WG would understand that some of us in the SIP community have some real concerns about the effect or perceptions in the marketplace that chartering this work in the IETF might have. They are real and probably cloud our thinking ..but simply dismissing them as irrelevant or stupid is not going to help gain consensus on chartering this work. richard - whether simple succeeds or fails will have nothing to do with whether the ietf helps out the jabber folks. each will succeed or fail on their own merits. i am at a loss to understand the extraordinary amount of fear and loathing from the simple camp that i witnessed in the jabber bof. i could be more unkind here, but i'm making an extraordinary effort to be inoffensive. regardless, there are numerous precedents to invalidate your position that we can work on only one. the most obvious is cpim, which explicitly acknowledges the existence of many. however, if you insist that there can be only one, then perhaps the logical thing to do is for the iesg to put eveything on hold while we do a detailed analysis of the technical merits of the various approaches. oh, wait, we already did that, and the result was that we did cpim. go back two paragraphs. for myself, i think that the simple folks would be much better served by focusing on their work product than on political posturing. /mtr
Re: IPR at IETF 54
My druthers would be to have an IETF policy explicitly saying that the first choice is to use unencumbered technology if it can be made to work, second choice is encumbered but royalty-free technology, and last choice is fair and reasonable licence terms (or whatever the equivalent correct legal wording might be for that last). and if one solution is 120% better technically than another, but has a RAND license associated with it? What if it's 170% better? working groups make trade-offs all the time between simplicity, functionality, and so on. licensing is another cost. given the amount of traffic on this topic, it appears that licensing is a very heavy cost. this may provide an answer to your question... /mtr
Re: IPR Re: IETF 54 calendar (fwd)
As I recall, RAND was explicitly selected over RF because there are and will be technologies that are interesting to incorporate in a system-wide standard approach, and forcing RF terms would automatically exclude those. There is enough of a bias in the participants toward RF when available, that explicit language requiring it adds no value and in some cases actually subtracts value from the process of achieving consensus. If what you are asking for is that for every proposal / i-d that shows up in the IETF, the IPR holder is automatically required to provide an RF license, you really don't understand the reason people bother with patents to begin with. tony - i don't find your last paragraph to be particularly helpful. a reasoned argument can be made that patents and community standards are incompatible. a rigorous study of the US patent system indicates that the founders introduced the system in order to serve the public good, by encouraging innovation, by granting limited monopolies on inventions. it is unclear if that system is particularly compatible with community-based approaches such as the IETF where, by definition, the output is not monopolized. with respect to your first paragraph, i note that if technology companies see value in participating in the standards process, then perhaps it is not unreasonable to suggest that the IETF consider only RF stuff, and then let the various IPR stakeholders decide whether the trade-off is worth it... in other words, if someone has some whizbang technology, and if they want the imprimatur of a community such as the IETF, then they can decide for themselves whether to RF it. if not, they are perfectly free to pursue a proprietary market strategy. for myself, i take no position on the merits of the two kinds of licensing; rather, i merely note that the issue is somewhat more subtle than first glance. /mtr
Re: I-D ACTION:draft-etal-ietf-analysis-00.txt
Counting RFCs looks like it's bad the same way that pure LOC counts are bad. err, okay, i guess. however, it may be useful for folks to actually read the draft before making comments... thus far, i've only seen two folks with comments who claim to have actually read the thing. as an author of the draft, i don't think Counting RFCs was a goal, or even something we explicitly did... /mtr
Re: IETF Meetings - High Registration Fees
Joe - since you replied to my note rather than bonney's, i am obliged to reply. Unlike both of you, i am not expressing an opinion on the fees. What i am saying is that neither of you have any data. Let's look at some actual numbers, and we can then have a reasoned discussion... /mtr
Re: IETF Meetings - High Registration Fees
This is something I have discussed with several people and every one seems to agree. The current registration fee of $575 is outrageously high. Even though IETF claims to be an open forum with no membership fee - you need $575*3=$1725 per year for registration fee alone for attending IETF sessions. This is effectively the membership fee for IETF. Sorry - not everyone can plan ten days in advance to get $125 reduction in fee. Just try to run a small consulting business or work for a 20 person start up - you would know what I mean. ... bonney - setting aside, for now, the unstated assumption of your message that meetings are where the real work gets done, perhaps a starting point would be to start by asking what the money gets spent on. maybe 575 is high, maybe it is low, maybe it is just right. looking at a balance sheet would provide a basis for a reasoned discussion as to whether the fees are reasonable, outrageous, or a bargain... /mtr
Re: whither HTTP?
I know some folks are talking about blocks, though that could replace a lot more than HTTP: http://www.bxxp.org i don't think so. i think that http is as entrenched as ip tcp, and is nearly as irreplacable. the problem, i think, a general lack of clarity as to what http is for. i'd say that beep is a generic application protocol framework for connection-oriented, asynchronous interactions. while http is many things to many people, i don't think anyone would s/http/beep/ in the previous sentence. /mtr
