Re: RFC Editor RFP Review Request
Date:Wed, 19 Jul 2006 03:06:10 +0200 From:Henrik Levkowetz [EMAIL PROTECTED] Message-ID: [EMAIL PROTECTED] | Ok. So I'm not sure what you propose here - should we not require | rsync and ftp mirroring capability, or should we ask for it, and not | specify chapter and verse regarding version etc.? I'd certainly be | very unhappy completely abandoning the rsync capability. Today that might be true, but in 6 months, some new mechanism may have blown rsync away completely. What would you think then if the RFC editor refused to provide the new mechanism, because they're required to provide rsync, but don't have the resources to provide both? All that should be required is that the RFCs be available to be fetched via some mechanism - which mechanism doesn't matter, and should not be specified (though given its longevity, mandating FTP as one possibility wouldn't bother me). If the mechanism(s) provided happen not to include rsync, and you believe that rsync availability is important then you can make them available that way (or someone else could). And if the version of rsync provided isn't the one you want, you, or someone, can make them available via some other version. Be reasonable about this stuff, don't put in any specifications that you wouldn't have included 10 years ago, or that aren't very likely to be just as relevant 10 years ahead of now. After that, all that matters is service quality - the RFC editor will need to keep responding to week by week user demands, or some other organisation will replace them. kre ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: RFC Editor RFP Review Request
Ok. So I'm not sure what you propose here - should we not require rsync and ftp mirroring capability, or should we ask for it, and not specify chapter and verse regarding version etc.? I'd certainly be very unhappy completely abandoning the rsync capability. IMO, the SOW should have some wording that requires/implies that information available via web pages must also be provided in a mirror-friendly way. The principle is that that the info can be easily be replicated on mirror servers using standard tools in a way that minimizes data transfer by distinguishing which pages have changed and which have not. Mentioning specific tools, if needed, should be in an e.g. clause, to make clear they are examples but not hard requirements. The actual details would presumably be sorted out be reasonable people on both ends. Thomas ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: San Diego (was RE: Meetings in other regions)
Starting from Europe, San Diego seems to be no harder to reach than any other major US city. The SPF route from Geneva has two hops (e.g. via EWR or JFK). I agree that major hub airports are a little easier to reach, but maybe that's why we can get meeting space more easily in non-hub cities? Brian Burger, Eric wrote: I would offer that it is easier for me to get to London, Paris, or Frankfurt from New Hampshire than it is to get to San Diego. LAX is marginally better. Chicago, Boston, New York, Toronto, Atlanta, and Las Vegas (!) are my easy, one-hop cities. That said, it was fun driving to Montreal :-) -Original Message- From: Marshall Eubanks [mailto:[EMAIL PROTECTED] Sent: Monday, July 17, 2006 8:45 AM To: [EMAIL PROTECTED] Cc: ietf@ietf.org Subject: Re: Meetings in other regions Hello; On Jul 17, 2006, at 8:21 AM, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: John C Klensin wrote: It also means such things as: * picking places within those countries or regions that have good airports with easy (and multiple) international connections. Even San Diego is a little marginal in that regard. Based on experience in the last year or so, I'd suggest that Cape Town and Marrakech (suggested in another posting) should be utterly disqualified (although J-berg and Casablanca are more plausible on this dimension). Some data about San Diego: Today, the flight information page on San Diego International Airport web site shows a couple of flights to/from Mexico and a couple to/from Canada -- all the others are within US. When meeting in North America, I would strongly prefer cities that have several direct flight connections from both Europe and Asia. Of the recent IETF meeting places, San Diego is the only one that clearly fails this criteria... so why are we going there again? Even direct flights within the US can be hard to find. Depending on where you are coming from, and when you purchase your tickets, you may find it faster / cheaper / better to fly to LAX or Long Beach and drive down to San Diego. (LAX - San Diego is ~ 200 km, and LAX is basically on the San Diego Freeway.) I did this for the one San Diego IETF. If you do that, be aware that there is a permanent immigration checkpoint on the San Diego freeway Northbound, which can cause backups returning. Regards Marshall Best regards, Pasi ___ 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 ___ 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: Response to the Appeal by [...]
Speaking only for myself, I have always read the words Further recourse is available... at the beginning of section 6.5.3 of RFC 2026 to mean that an appeal to the ISOC Board can only follow rejection of an appeal by both the IESG and IAB. I think this is essentially right. That is, it makes no sense to appeal to ISOC that the process itself was unfair and has failed to produce a proper result, if there wasn't first an appeal on actual substance that didn't result in the appropriate outcome. But, technically, I would not expect the appeal to the IESG/IAB and the one to the ISOC to be exactly the same. In the former case, the appeal is presumably on actual decisions and actions made in WGs, by the IESG, etc. In the latter case, the argument is much more about the process itself (and how it failed to protect the rights of all parties in a fair and open Internet Standards Process as indicated in 2026) and is less focussed on the details that led to the original appeal. Thomas ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Minutes and jabber logs
Folks interested in the topic of minutes may want to go find a copy of (the expired) draft-meyer-agendas-and-minutes-00.txt And if they think this is a good direction to go, encourage the authors to update the document and push it forward through the system. Thomas ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: San Diego (was RE: Meetings in other regions)
Brian E Carpenter wrote: Starting from Europe, San Diego seems to be no harder to reach than any other major US city. The SPF route from Geneva has two hops (e.g. via EWR or JFK). I agree that major hub airports are a little easier to reach, but maybe that's why we can get meeting space more easily in non-hub cities? Meeting space is gotten more easily at hub cities when planning is done farther in advance. If a non-hub venue offers dramatic net price savings, fabulous facilities, or some other strong justification, it makes sense to go there. Otherwise, a non-hum city forces virtually the entire set of attendees to: 1. Experience an extra flight, each way, with its attendant inconveniences and risks (higher risk of lost luggage, missed connections, etc.) 2. Pay higher air fares, since secondary venues do not have the airline competition that major hubs do. 3. Experience a higher risk of losing access completely, because of that lack of airline competition... The primary airline to the non-hub might go on strike, for example, as (nearly) happened to us in Minneapolis one time. 4. More generally, secondary venues have less total airline seating capacity and the concentration of our 1200-1400 attendees flying in and out close together usually has a noticeable impact on their flights. d/ ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Meetings in other regions
Let me relate my *EXPERIENCE* with some interim meetings (lemonade). [I suppose data is the closest we have to 'working code.'] Meeting held in Dallas: 9 participants. Meeting held in Vancouver: 10 participants. Meeting held in London: 14 participants. Meeting held in Beijing: 21 participants. Worst Internet connectivity: London. Best Internet connectivity: tied between Vancouver and Beijing. Small nit-pick, on trying to generalize from your data: 1. Since we know that The London metropolitan area has excellent Internet connectivity and bandwidth, the problems you experienced must have been due to the particular meeting site and not the region. 2. For a region that is not obviously able to give excellent service, the key is the commitment by local staff (and government) to make sure it is excellent. They cannot do anything about the lack of fat pipes to the outside world, but they can do quite a bit about fat pipes within the venue and their reliability. 3. Within the constraints of that basic connectivity to the outside world, most major cities are now able to deliver excellent service... given the commitment to do so. d/ ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: LA - San Diego transportation (Was: Re: Meetings in other regions)
Clint Chaplin wrote: One data point: IEEE 802 is in San Diego this week, and I've met at least one attendee who flew through LAX to get here; that is, he took LAX - SAN as his last leg. the flight is so short, one can feel guilty taking it. however the effort to rent a car from an airport, drive through Southern California traffic, and then either have the car sit for a week or try to dump it upon arrival, all make taking that short flight a reasonable choice. d/ ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: RFC Editor RFP Review Request
I use ftp all the time to access the RFCs. I use direct web URLs all the time to access the RFCs. I *occasionally* use rfc-editor.org's web interface. I agree with Henrik. Tony Hansen [EMAIL PROTECTED] Henrik Levkowetz wrote: It may be that the level of detail specification should be less than what it is now, overall; but with the current specification level I felt it is a clear omission to not specify *any* access to the documents except through a search facility. I feel that direct ftp/http/rsync access is actually more important than the search facility specified in the proposed SOW, which is why I commented on this. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: San Diego (was RE: Meetings in other regions)
Dave, A few points: If a non-hub venue offers dramatic net price savings, fabulous facilities, or some other strong justification, it makes sense to go there. Otherwise, a non-hum city forces virtually the entire set of attendees to: 1. Experience an extra flight, each way, with its attendant inconveniences and risks (higher risk of lost luggage, missed connections, etc.) This is a something of a fair point, but if we were to limit our conferences to hub cities when in the U.S., that would mean San Francisco, LA, Denver, Chicago, Minneapolis, Atlanta, Washington D.C, and maybe Boston. There's a trade off. My absolute favorite location for an IETF these many years was Santa Fe. It was beautiful. Aside from the conference there was art, scenery, and history, including Bandelier National Monument and the Sandia Mountains. Santa Fe required most of us to change planes, land in Albuquerque, and then drive for an hour or so. In as much as our size permits us to visit such locales, it's a nice change of pace. And honestly I think we all get along a little better when we can see and do some fun things together outside of work. 2. Pay higher air fares, since secondary venues do not have the airline competition that major hubs do. This is not necessarily true. Sometimes airfares are actually CHEAPER for those spoke cities. For instance, I have seen airfares to San Diego that are cheaper than those to Los Angeles. It's counter-intuitive and demonstrates that one really has to be some sort of a clairvoyant to understand airfares, but there it is. My recollection is that the Savvy Traveler and the Wall St. Journal have reported on this phenomenon. 3. Experience a higher risk of losing access completely, because of that lack of airline competition... The primary airline to the non-hub might go on strike, for example, as (nearly) happened to us in Minneapolis one time. Minneapolis *is* a hub for Northwest. 4. More generally, secondary venues have less total airline seating capacity and the concentration of our 1200-1400 attendees flying in and out close together usually has a noticeable impact on their flights. This is unlikely to be a problem, because we're merely the next 1200-1400 attendees that fly in, and in an area like San Diego we're one of several conferences that will go on at the same time, I'm sure. What's more, the next 1200-1400 will begin to fly in as we depart. So the capacity is probably there. Eliot ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: San Diego (was RE: Meetings in other regions)
Dave, Actually, airline hubs increase the risk of depending on a single airline, since most hubs (at least in the US) are dominated by a single airline, such as Northwest in Minneapolisand Detroit, US Airways in Philly and Pittsburgh, American in Dallas, Delta in Altanta and Salt Lake City, America West in Phoenix, United in Denver, and so on. Chicago is one of the few major US airports that is a dual hub (American and United). And yes, Minneapolis is a hub. Cheers, Andy -- On 7/19/06, Dave Crocker [EMAIL PROTECTED] wrote: Brian E Carpenter wrote: Starting from Europe, San Diego seems to be no harder to reach than any other major US city. The SPF route from Geneva has two hops (e.g. via EWR or JFK). I agree that major hub airports are a little easier to reach, but maybe that's why we can get meeting space more easily in non-hub cities?Meeting space is gotten more easily at hub cities when planning is done fartherin advance.If a non-hub venue offers dramatic net price savings, fabulous facilities, orsome other strong justification, it makes sense to go there. Otherwise, a non-hum city forces virtually the entire set of attendees to:1. Experience an extraflight, each way, with its attendant inconveniences andrisks (higher risk of lost luggage, missed connections, etc.) 2. Pay higher air fares, since secondary venues do not have the airlinecompetition that major hubs do.3. Experience a higher risk of losing access completely, because of that lack ofairline competition... The primary airline to the non-hub might go on strike, for example, as (nearly) happened to us in Minneapolis one time.4. More generally, secondary venues have less total airline seating capacity andthe concentration of our 1200-1400 attendees flying in and out close together usually has a noticeable impact on their flights.d/___Ietf mailing listIetf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Meetings in other regions
On Wed Jul 19 14:53:59 2006, Dave Crocker wrote: 1. Since we know that The London metropolitan area has excellent Internet connectivity and bandwidth, the problems you experienced must have been due to the particular meeting site and not the region. Indeed. The meeting site had confused Full Internet Access with Braindead HTTP proxy web access. I can't remember if the proxy supported CONNECT or not. The bandwidth itself was fine and fast, I believe. I certainly couldn't recommend the venue for the IETF. Of course, being good little Lemonade folk, many of us continued on GPRS et al quite happily, which was really quite fitting. I seem to remember that at one point, Randall Gellens was actually providing the entire room with unblemished, albeit slow, internet access over his mobile. In some respects, it focused discussions beneficially, by forcing us into using the kinds of connectivity and network we were trying to address. It was one of the first times I'd intensively used my own MUA over that kind of bandwidth for anything more than quick mailchecks and testing, so I recall it with almost nostalgic pleasure. Dave. -- Dave Cridland - mailto:[EMAIL PROTECTED] - xmpp:[EMAIL PROTECTED] - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/ - http://dave.cridland.net/ Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: LA - San Diego transportation (Was: Re: Meetings in other regions)
Dave Crocker wrote: Clint Chaplin wrote: One data point: IEEE 802 is in San Diego this week, and I've met at least one attendee who flew through LAX to get here; that is, he took LAX - SAN as his last leg. the flight is so short, one can feel guilty taking it. however the effort to rent a car from an airport, drive through Southern California traffic, and then either have the car sit for a week or try to dump it upon arrival, all make taking that short flight a reasonable choice. Or go through SFO. Given the fixed time costs of getting a plane in the air at all, the time difference between SFO and LAX are probably negligible. Of course one must make certain that SFO's runways are both open... Mike ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: LA - San Diego transportation (Was: Re: Meetings in other regions)
I did this the last time we where in San Diego. The only thing to be concerned about is at least United operated small planes with not to good frequency (at least then) and tends to fill up on Saturday afternoon and Sunday morning (I noticed). Then going from International to domestic at LAX turned out to be a small adventure but I think that was a unique experience I would be happy to tell in a bar..:) - kurtis - On 19 jul 2006, at 00.29, Clint Chaplin wrote: One data point: IEEE 802 is in San Diego this week, and I've met at least one attendee who flew through LAX to get here; that is, he took LAX - SAN as his last leg. On 7/18/06, Doug Barton [EMAIL PROTECTED] wrote: [ Disclaimer, I grew up in San Diego and now live in the LA area, so I have biases in both directions. :) ] [EMAIL PROTECTED] wrote: (BTW, how much would a taxi from LAX to San Diego cost? And would you expect taxis willing to do it?) It's 120+ miles from LAX to the Sheraton San Diego, so a taxi isn't practical. However, there are various ground transportation services that ply that route, so if there is sufficient interest I wouldn't mind looking into it and posting the results. I would say that the suggestion already offered of the train from LA's Union Station to San Diego is a good one. The city of Los Angeles recently introduced a low cost shuttle between the station and the airport, and the train station in San Diego is just a few miles away from the Sheraton. My mother takes the train up from San Diego when she comes to visit her granddaughter (I am of course a second consideration), and has very good things to say about it. The train spends a good deal of its time within view of the coast, so you get a fairly scenic ride as well. All that said, they do have commuter flights between LAX and SAN, so a connecting flight is not as absurd as it sounds. hth, Doug -- If you're never wrong, you're not trying hard enough ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf -- Clint (JOATMON) Chaplin Wireless Security Technologist Wireless Standards Manager ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: RFC Editor RFP Review Request
Hi Thomas, on 2006-07-19 14:33 Thomas Narten said the following: IMO, the SOW should have some wording that requires/implies that information available via web pages must also be provided in a mirror-friendly way. The principle is that that the info can be easily be replicated on mirror servers using standard tools in a way that minimizes data transfer by distinguishing which pages have changed and which have not. Mentioning specific tools, if needed, should be in an e.g. clause, to make clear they are examples but not hard requirements. The actual details would presumably be sorted out be reasonable people on both ends. That would work for me. Henrik signature.asc Description: OpenPGP digital signature ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: San Diego (was RE: Meetings in other regions)
Eliot Lear wrote: Minneapolis *is* a hub for Northwest. 4. More generally, secondary venues have less total airline seating capacity and the concentration of our 1200-1400 attendees flying in and out close together usually has a noticeable impact on their flights. This is unlikely to be a problem, because we're merely the next 1200-1400 attendees that fly in, and in an area like San Diego we're one of several conferences that will go on at the same time, I'm sure. What's more, the next 1200-1400 will begin to fly in as we depart. So the capacity is probably there. Sand Diego is the busiest single runway commercial airport in the United states. it handles approximately 40,000 passenger arrivals/departures per day with about 300 commercial flights arriving per day. 1/3 of all flights are southwest which is the part that doesn't really help folks connecting internationally. If the entire IETF were to fly in Lindberg field on the same day that would be approximately 5% of the seats. I would suspect that more people than that fly in to visit seaworld on a given day. Eliot ___ 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: San Diego (was RE: Meetings in other regions)
On 19-jul-2006, at 15:45, Dave Crocker wrote: I agree that major hub airports are a little easier to reach, but maybe that's why we can get meeting space more easily in non-hub cities? If a non-hub venue offers dramatic net price savings, fabulous facilities, or some other strong justification, it makes sense to go there. Otherwise, a non-hum city forces virtually the entire set of attendees to: 1. Experience an extra flight, each way, with its attendant inconveniences and risks (higher risk of lost luggage, missed connections, etc.) 2. Pay higher air fares, since secondary venues do not have the airline competition that major hubs do. I certainly don't fly as much as the next IETF-er, but in my experience, direct flights are almost always more expensive than indirect ones. Obviously a direct flight is much more convenient, but some indirect ones are actually pretty good while others are terrible and some direct flights are also pretty bad. Based on my experience past few years I would be happy to change planes again in Iceland (and probably in any other Schengen country where you only go through immigration when entering the Schengen zone initially) but not in the US if I can avoid it because either you have to build in ridiculous amounts of extra time or you run the risk of missing a connection because of the lines at immigration, especially at large airports such as JFK and LAX. As a rule, smaller is better, upto a point. This seems to go for the planes too, those 747 air-dinosaurs aren't very convenient, particularly with (un)boarding. Another issue is ground transportation. I guess most people don't mind using a taxi, but having to stand in line for one isn't exactly what I need after an intercontinental flight... All in all, San Diego seems like a pretty bad choice for a meeting place: it's even hard to get to from inside the US, and it's as far as you can get from Europe without leaving the continental US. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: LA - San Diego transportation (Was: Re: Meetings in other regions)
Dave Crocker wrote: Clint Chaplin wrote: One data point: IEEE 802 is in San Diego this week, and I've met at least one attendee who flew through LAX to get here; that is, he took LAX - SAN as his last leg. the flight is so short, one can feel guilty taking it. however the effort to rent a car from an airport, drive through Southern California traffic, and then either have the car sit for a week or try to dump it upon arrival, all make taking that short flight a reasonable choice. First, I want to clarify my original mail. I meant that if you live in LA, it doesn' pay to fly to San Diego. It's way faster and cheaper to drive your own car there instead of flying. Second, remember that the San Diego location is not close to very many good dining and drinking spots, so having a car at the next IETF will be useful. Third, renting a car in LA and driving is a really bad idea (instead of getting a free connecting flight) unless you want to visit LA or the area between LA and San Diego while you at the next IETF. (Trust me, if you have never been to Laguna Beach, go there if you want to see what SoCal is really like.) d/ Andy ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: San Diego (was RE: Meetings in other regions)
On 7/19/06 1:47 PM, Iljitsch van Beijnum [EMAIL PROTECTED] wrote: All in all, San Diego seems like a pretty bad choice for a meeting place: it's even hard to get to from inside the US, and it's as far as you can get from Europe without leaving the continental US. I'm not crazy about it either, but not because it's difficult to get to. Accessibility is a question of travel facilities, and there are very nice places in the US that are a heck of a lot harder to get to than San Diego, even on the east coast. I live in one of those places on the US east coast, and there are very few places I can get to in Europe or Asia or even Canada without having to change planes at least twice. So, in terms of reachability San Diego isn't that bad. My disagreement with San Diego is that the meeting facilities there have been consistently lousy. Melinda ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: LA - San Diego transportation (Was: Re: Meetings in other regions)
The limitation on lack of eating and drinking places near the venue is because of the choice of the particular hotel. IEEE is in the Hyatt on the waterfront, and Old Town is well within walking distace, with lots of restaurant choices. On 7/19/06, Andy Bierman [EMAIL PROTECTED] wrote: Dave Crocker wrote: Clint Chaplin wrote: One data point: IEEE 802 is in San Diego this week, and I've met at least one attendee who flew through LAX to get here; that is, he took LAX - SAN as his last leg. the flight is so short, one can feel guilty taking it. however the effort to rent a car from an airport, drive through Southern California traffic, and then either have the car sit for a week or try to dump it upon arrival, all make taking that short flight a reasonable choice. First, I want to clarify my original mail. I meant that if you live in LA, it doesn' pay to fly to San Diego. It's way faster and cheaper to drive your own car there instead of flying. Second, remember that the San Diego location is not close to very many good dining and drinking spots, so having a car at the next IETF will be useful. Third, renting a car in LA and driving is a really bad idea (instead of getting a free connecting flight) unless you want to visit LA or the area between LA and San Diego while you at the next IETF. (Trust me, if you have never been to Laguna Beach, go there if you want to see what SoCal is really like.) d/ Andy ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf -- Clint (JOATMON) Chaplin Wireless Security Technologist Wireless Standards Manager ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: San Diego (was RE: Meetings in other regions)
Another data point; San Diego is hosting Comic-Con this weekend: they're expecting on the order of 100,000 attendees. On 7/19/06, Eliot Lear [EMAIL PROTECTED] wrote: Dave, A few points: If a non-hub venue offers dramatic net price savings, fabulous facilities, or some other strong justification, it makes sense to go there. Otherwise, a non-hum city forces virtually the entire set of attendees to: 1. Experience an extra flight, each way, with its attendant inconveniences and risks (higher risk of lost luggage, missed connections, etc.) This is a something of a fair point, but if we were to limit our conferences to hub cities when in the U.S., that would mean San Francisco, LA, Denver, Chicago, Minneapolis, Atlanta, Washington D.C, and maybe Boston. There's a trade off. My absolute favorite location for an IETF these many years was Santa Fe. It was beautiful. Aside from the conference there was art, scenery, and history, including Bandelier National Monument and the Sandia Mountains. Santa Fe required most of us to change planes, land in Albuquerque, and then drive for an hour or so. In as much as our size permits us to visit such locales, it's a nice change of pace. And honestly I think we all get along a little better when we can see and do some fun things together outside of work. 2. Pay higher air fares, since secondary venues do not have the airline competition that major hubs do. This is not necessarily true. Sometimes airfares are actually CHEAPER for those spoke cities. For instance, I have seen airfares to San Diego that are cheaper than those to Los Angeles. It's counter-intuitive and demonstrates that one really has to be some sort of a clairvoyant to understand airfares, but there it is. My recollection is that the Savvy Traveler and the Wall St. Journal have reported on this phenomenon. 3. Experience a higher risk of losing access completely, because of that lack of airline competition... The primary airline to the non-hub might go on strike, for example, as (nearly) happened to us in Minneapolis one time. Minneapolis *is* a hub for Northwest. 4. More generally, secondary venues have less total airline seating capacity and the concentration of our 1200-1400 attendees flying in and out close together usually has a noticeable impact on their flights. This is unlikely to be a problem, because we're merely the next 1200-1400 attendees that fly in, and in an area like San Diego we're one of several conferences that will go on at the same time, I'm sure. What's more, the next 1200-1400 will begin to fly in as we depart. So the capacity is probably there. Eliot ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf -- Clint (JOATMON) Chaplin Wireless Security Technologist Wireless Standards Manager ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Response to the Appeal by [...]
This is my understanding. However this rises a problem in cases like RFC 3683. Because in this case (this what the IESG claims) the delay for appealing the RFC 3863 text is over. This is why I spoke of RFC 3863 application, the same as there is usually a text and a running code. In a BCP organising the Internet standard process the running code can only come afterward. This is why I did not appeal against the RFC 3683 but against the way it was applied (underlining that possible bias would be discussed separately). Being the first one subject to the RFC 3863 running code, however the appeal delay against the text is over, the appeal delay against the way the running code works had just started. jfc At 15:02 19/07/2006, Thomas Narten wrote: Speaking only for myself, I have always read the words Further recourse is available... at the beginning of section 6.5.3 of RFC 2026 to mean that an appeal to the ISOC Board can only follow rejection of an appeal by both the IESG and IAB. I think this is essentially right. That is, it makes no sense to appeal to ISOC that the process itself was unfair and has failed to produce a proper result, if there wasn't first an appeal on actual substance that didn't result in the appropriate outcome. But, technically, I would not expect the appeal to the IESG/IAB and the one to the ISOC to be exactly the same. In the former case, the appeal is presumably on actual decisions and actions made in WGs, by the IESG, etc. In the latter case, the argument is much more about the process itself (and how it failed to protect the rights of all parties in a fair and open Internet Standards Process as indicated in 2026) and is less focussed on the details that led to the original appeal. Thomas ___ 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
tsv-area mailing list
Hi, in response to the first TSVAREA meeting in Montreal, we have set up a corresponding area-wide mailing list. The purpose of the TSVAREA meeting (and the associated mailing list) is to inform about and discuss important issues, developments and work within the transport area. The area meeting is exist primarily for information spreading, but also to take the pulse of the community. In contrast to TSVWG it is not intended to produce any documents that are published. Document work is performed in the respectively chartered WGs. To post to this list, send your email to: [EMAIL PROTECTED] General information about the mailing list is at: https://www1.ietf.org/mailman/listinfo/tsv-area Lars (for Magnus Lars) -- Lars Eggert NEC Network Laboratories smime.p7s Description: S/MIME cryptographic signature ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: Meetings in other regions
Point 2 is exactly my point. Places which should have the best connectivity (tons of international interconnect and PSTN connectivity) can still be defeated by stupid firewall tricks and no host with international PSTN conference services. Conversely, places that North Americans might consider third tier often have considerably better connectivity than one would expect. -Original Message- From: Dave Crocker [mailto:[EMAIL PROTECTED] Sent: Wednesday, July 19, 2006 9:54 AM To: Burger, Eric Cc: ietf@ietf.org Subject: Re: Meetings in other regions Let me relate my *EXPERIENCE* with some interim meetings (lemonade). [I suppose data is the closest we have to 'working code.'] Meeting held in Dallas: 9 participants. Meeting held in Vancouver: 10 participants. Meeting held in London: 14 participants. Meeting held in Beijing: 21 participants. Worst Internet connectivity: London. Best Internet connectivity: tied between Vancouver and Beijing. Small nit-pick, on trying to generalize from your data: 1. Since we know that The London metropolitan area has excellent Internet connectivity and bandwidth, the problems you experienced must have been due to the particular meeting site and not the region. 2. For a region that is not obviously able to give excellent service, the key is the commitment by local staff (and government) to make sure it is excellent. They cannot do anything about the lack of fat pipes to the outside world, but they can do quite a bit about fat pipes within the venue and their reliability. 3. Within the constraints of that basic connectivity to the outside world, most major cities are now able to deliver excellent service... given the commitment to do so. d/ ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Document Action: 'Registration of media type audio/mobile-xmf' to Informational RFC
The IESG has approved the following document: - 'Registration of media type audio/mobile-xmf ' draft-kosonen-mobile-xmf-mediatype-01.txt as an Informational RFC This document has been reviewed in the IETF but is not the product of an IETF Working Group. The IESG contact person is Ted Hardie. A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-kosonen-mobile-xmf-mediatype-01.txt Technical Summary The MIDI Manufacturers Association (MMA) and the Association of Music Electronics industry (AMEI) have produced the Mobile XMF standard [1]. The Mobile XMF standard has been developed particularly for mobile MIDI [7] applications. Mobile XMF is a very compact media type providing high quality synthetic audio content for music downloading and messaging applications that require MIME registration. Working Group Summary This document is an individual submission. Protocol Quality Ietf-types reviewed this document. Note to RFC Editor OLD prl is a string (inside double quotation marks ) containing the playback resources included in all Content Description MetaDataItems of the Mobile XMF file. The string contains two digit hexadecimal numbers representing data bytes from the Content Description Meta Data. The same resource is listed only once. A playback resource contains two parts: a prefix and data. prl is encoded in two-digit hex numbers concatenated in a US-ASCII string. Example: If the file includes Playback Resource Lists such as [00h 01h 00h 02h] and [00h 01h 00h 03h], the corresponding prl is 000100020003 containing playback resources 01, 02, and 03 with the prefix 00. NEW prl contains the playback resources included in all Content Description MetaDataItems of the Mobile XMF file. prl contains two- digit hexadecimal numbers representing data bytes from the Content Description Meta Data. The same resource is listed only once. A playback resource contains two parts: a prefix and data. prl is a sequence of two-digit hexadecimal numbers encoded in US-ASCII. Thus, prl has an even number of hexadecimal digits. Example: If the file includes Playback Resource Lists such as [00h 01h 00h 02h] and [00h 01h 00h 03h], the corresponding prl is 000100020003 containing playback resources 01, 02, and 03 each with the prefix 00. OLD minimum-pr is a string containing the Maximum Instantaneous Resource (MIR) values from the first row of all MIR Count Tables corresponding to the playback resources listed in prl. Only the largest value from the values of the same resource is chosen. minimum-prl is encoded in two-digit hex numbers concatenated in a US-ASCII string. minimum-pr requires the use of prl and the values in minimum-pr must be in the same order as the resources in prl. minimum-pr is the most important of minimum-pr and total-pr, because it defines the minimum playback requirements. Example: If the file includes first rows of MIR Count Tables such as [02h 00h] and [01h 01h] corresponding to the above Playback Resource Lists, the corresponding minimum-pr is 020001. (02 is the largest of 2 and 1, 00 is the largest of 0, and 01 is the largest of 1.) NEW minimum-pr contains the Maximum Instantaneous Resource (MIR) values from the first row of all MIR Count Tables corresponding to the playback resources listed in prl. Only the largest value from the values of the same resource is chosen. minimum-prl is a sequence of two-digit hexadecimal numbers encoded in US-ASCII. Thus, minimum-prl has an even number of hexadecimal digits. minimum-pr requires the use of prl and the values in minimum-pr must be in the same order as the resources in prl. minimum-pr is the most important of minimum-pr and total-pr, because it defines the minimum playback requirements. Example: If the file includes first rows of MIR Count Tables such as [02h 00h] and [01h 01h] corresponding to the above Playback Resource Lists, the corresponding minimum-pr is 020001. (02 is the largest of 2 and 1, 00 is the largest of 0, and 01 is the largest of 1.) OLD total-pr is a string containing the MIR values from the last row of all MIR Count Tables corresponding to the playback resources listed in prl. Only the largest value from the values of the same resource is chosen. total-pr is encoded in two-digit hex numbers concatenated in a US-ASCII string. total-pr requires the use of prl and the values in total-pr must be in the same order as the resources in prl. Example: If the file includes last rows of MIR Count Tables such as [05h 02h] and [06h 01h] corresponding to the above Playback Resource Lists, the corresponding total-pr is 060201. (06 is the largest of 5 and 6, 02 is the largest of 2, and 01 is the largest of 1.) NEW total-pr contains the MIR values from the last row of all MIR Count Tables corresponding to the playback resources listed in prl. Only the largest value from the values of the same resource is chosen. total-pr is a sequence of
Last Call: 'Document Shepherding From Working Group Last Call to IESG Approval' to Informational RFC (draft-ietf-proto-wgchair-doc-shepherding)
The IESG has received a request from an individual submitter to consider the following document: - 'Document Shepherding From Working Group Last Call to IESG Approval ' draft-ietf-proto-wgchair-doc-shepherding-07.txt as an Informational RFC The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send any comments to the iesg@ietf.org or ietf@ietf.org mailing lists by 2006-08-16. The file can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-proto-wgchair-doc-shepherding-07. txt ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce
RFC 4568 on Session Description Protocol (SDP) Security Descriptions for Media Streams
A new Request for Comments is now available in online RFC libraries. RFC 4568 Title: Session Description Protocol (SDP) Security Descriptions for Media Streams Author: F. Andreasen, M. Baugher, D. Wing Status: Standards Track Date: July 2006 Mailbox:[EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED] Pages: 44 Characters: 107881 Updates/Obsoletes/SeeAlso: None I-D Tag:draft-ietf-mmusic-sdescriptions-12.txt URL:http://www.rfc-editor.org/rfc/rfc4568.txt This document defines a Session Description Protocol (SDP) cryptographic attribute for unicast media streams. The attribute describes a cryptographic key and other parameters that serve to configure security for a unicast media stream in either a single message or a roundtrip exchange. The attribute can be used with a variety of SDP media transports, and this document defines how to use it for the Secure Real-time Transport Protocol (SRTP) unicast media streams. The SDP crypto attribute requires the services of a data security protocol to secure the SDP message. [STANDARDS TRACK] This document is a product of the Multiparty Multimedia Session Control Working Group of the IETF. This is now a Proposed Standard Protocol. STANDARDS TRACK: This document specifies an Internet standards track protocol for the Internet community,and requests discussion and suggestions for improvements.Please refer to the current edition of the Internet Official Protocol Standards (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF list and the RFC-DIST list. Requests to be added to or deleted from the IETF distribution list should be sent to [EMAIL PROTECTED] Requests to be added to or deleted from the RFC-DIST distribution list should be sent to [EMAIL PROTECTED] Details on obtaining RFCs via FTP or EMAIL may be obtained by sending an EMAIL message to [EMAIL PROTECTED] with the message body help: ways_to_get_rfcs. For example: To: [EMAIL PROTECTED] Subject: getting rfcs help: ways_to_get_rfcs Requests for special distribution should be addressed to either the author of the RFC in question, or to [EMAIL PROTECTED] Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. Submissions for Requests for Comments should be sent to [EMAIL PROTECTED] Please consult RFC 2223, Instructions to RFC Authors, for further information. Joyce K. Reynolds and Sandy Ginoza USC/Information Sciences Institute ... ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce
RFC 4536 on The application/smil and application/smil+xml Media Types
A new Request for Comments is now available in online RFC libraries. RFC 4536 Title: The application/smil and application/smil+xml Media Types Author: P. Hoschka Status: Informational Date: July 2006 Mailbox:[EMAIL PROTECTED] Pages: 8 Characters: 13747 Updates/Obsoletes/SeeAlso: None I-D Tag:draft-hoschka-smil-media-type-13.txt URL:http://www.rfc-editor.org/rfc/rfc4536.txt This document specifies the media type for versions 1.0, 2.0, and 2.1 of the Synchronized Multimedia Integration Language (SMIL 1.0, SMIL 2.0, SMIL 2.1). SMIL allows integration of a set of independent multimedia objects into a synchronized multimedia presentation. This memo provides information for the Internet community. INFORMATIONAL: This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited. This announcement is sent to the IETF list and the RFC-DIST list. Requests to be added to or deleted from the IETF distribution list should be sent to [EMAIL PROTECTED] Requests to be added to or deleted from the RFC-DIST distribution list should be sent to [EMAIL PROTECTED] Details on obtaining RFCs via FTP or EMAIL may be obtained by sending an EMAIL message to [EMAIL PROTECTED] with the message body help: ways_to_get_rfcs. For example: To: [EMAIL PROTECTED] Subject: getting rfcs help: ways_to_get_rfcs Requests for special distribution should be addressed to either the author of the RFC in question, or to [EMAIL PROTECTED] Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. Submissions for Requests for Comments should be sent to [EMAIL PROTECTED] Please consult RFC 2223, Instructions to RFC Authors, for further information. Joyce K. Reynolds and Sandy Ginoza USC/Information Sciences Institute ... ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce
RFC 4569 on Internet Assigned Number Authority (IANA) Registration of the Message Media Feature Tag
A new Request for Comments is now available in online RFC libraries. RFC 4569 Title: Internet Assigned Number Authority (IANA) Registration of the Message Media Feature Tag Author: G. Camarillo Status: Informational Date: July 2006 Mailbox:[EMAIL PROTECTED] Pages: 4 Characters: 6920 Updates/Obsoletes/SeeAlso: None I-D Tag:draft-ietf-sipping-message-tag-00.txt URL:http://www.rfc-editor.org/rfc/rfc4569.txt This document registers with the IANA a new media feature tag associated with the 'message' media type. This media feature tag indicates that a particular device supports 'message' as a streaming media type. Media feature tags can be used to route calls to devices that support certain features. This memo provides information for the Internet community. This document is a product of the Session Initiation Proposal Investigation Working Group of the IETF. INFORMATIONAL: This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited. This announcement is sent to the IETF list and the RFC-DIST list. Requests to be added to or deleted from the IETF distribution list should be sent to [EMAIL PROTECTED] Requests to be added to or deleted from the RFC-DIST distribution list should be sent to [EMAIL PROTECTED] Details on obtaining RFCs via FTP or EMAIL may be obtained by sending an EMAIL message to [EMAIL PROTECTED] with the message body help: ways_to_get_rfcs. For example: To: [EMAIL PROTECTED] Subject: getting rfcs help: ways_to_get_rfcs Requests for special distribution should be addressed to either the author of the RFC in question, or to [EMAIL PROTECTED] Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. Submissions for Requests for Comments should be sent to [EMAIL PROTECTED] Please consult RFC 2223, Instructions to RFC Authors, for further information. Joyce K. Reynolds and Sandy Ginoza USC/Information Sciences Institute ... ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce
RFC 4566 on SDP: Session Description Protocol
A new Request for Comments is now available in online RFC libraries. RFC 4566 Title: SDP: Session Description Protocol Author: M. Handley, V. Jacobson, C. Perkins Status: Standards Track Date: July 2006 Mailbox:[EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED] Pages: 49 Characters: 108820 Obsoletes: RFC2327, RFC3266 See-Also: I-D Tag:draft-ietf-mmusic-sdp-new-26.txt URL:http://www.rfc-editor.org/rfc/rfc4566.txt This memo defines the Session Description Protocol (SDP). SDP is intended for describing multimedia sessions for the purposes of session announcement, session invitation, and other forms of multimedia session initiation. [STANDARDS TRACK] This document is a product of the Multiparty Multimedia Session Control Working Group of the IETF. This is now a Proposed Standard Protocol. STANDARDS TRACK: This document specifies an Internet standards track protocol for the Internet community,and requests discussion and suggestions for improvements.Please refer to the current edition of the Internet Official Protocol Standards (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF list and the RFC-DIST list. Requests to be added to or deleted from the IETF distribution list should be sent to [EMAIL PROTECTED] Requests to be added to or deleted from the RFC-DIST distribution list should be sent to [EMAIL PROTECTED] Details on obtaining RFCs via FTP or EMAIL may be obtained by sending an EMAIL message to [EMAIL PROTECTED] with the message body help: ways_to_get_rfcs. For example: To: [EMAIL PROTECTED] Subject: getting rfcs help: ways_to_get_rfcs Requests for special distribution should be addressed to either the author of the RFC in question, or to [EMAIL PROTECTED] Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. Submissions for Requests for Comments should be sent to [EMAIL PROTECTED] Please consult RFC 2223, Instructions to RFC Authors, for further information. Joyce K. Reynolds and Sandy Ginoza USC/Information Sciences Institute ... ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce
RFC 4573 on MIME Type Registration for RTP Payload Format for H.224
A new Request for Comments is now available in online RFC libraries. RFC 4573 Title: MIME Type Registration for RTP Payload Format for H.224 Author: R. Even, A. Lochbaum Status: Standards Track Date: July 2006 Mailbox:[EMAIL PROTECTED], [EMAIL PROTECTED] Pages: 7 Characters: 13587 Updates/Obsoletes/SeeAlso: None I-D Tag:draft-ietf-avt-mime-h224-05.txt URL:http://www.rfc-editor.org/rfc/rfc4573.txt In conversational video applications, far-end camera control protocol is used by participants to control the remote camera. The protocol that is commonly used is ITU H.281 over H.224. The document registers the H224 media type. It defines the syntax and the semantics of the Session Description Protocol (SDP) parameters needed to support far-end camera control protocol using H.224. [STANDARDS TRACK] This document is a product of the Audio/Video Transport Working Group of the IETF. This is now a Proposed Standard Protocol. STANDARDS TRACK: This document specifies an Internet standards track protocol for the Internet community,and requests discussion and suggestions for improvements.Please refer to the current edition of the Internet Official Protocol Standards (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF list and the RFC-DIST list. Requests to be added to or deleted from the IETF distribution list should be sent to [EMAIL PROTECTED] Requests to be added to or deleted from the RFC-DIST distribution list should be sent to [EMAIL PROTECTED] Details on obtaining RFCs via FTP or EMAIL may be obtained by sending an EMAIL message to [EMAIL PROTECTED] with the message body help: ways_to_get_rfcs. For example: To: [EMAIL PROTECTED] Subject: getting rfcs help: ways_to_get_rfcs Requests for special distribution should be addressed to either the author of the RFC in question, or to [EMAIL PROTECTED] Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. Submissions for Requests for Comments should be sent to [EMAIL PROTECTED] Please consult RFC 2223, Instructions to RFC Authors, for further information. Joyce K. Reynolds and Sandy Ginoza USC/Information Sciences Institute ... ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce
RFC 4571 on Framing Real-time Transport Protocol (RTP) and RTP Control Protocol (RTCP) Packets over Connection-Oriented Transport
A new Request for Comments is now available in online RFC libraries. RFC 4571 Title: Framing Real-time Transport Protocol (RTP) and RTP Control Protocol (RTCP) Packets over Connection-Oriented Transport Author: J. Lazzaro Status: Standards Track Date: July 2006 Mailbox:[EMAIL PROTECTED] Pages: 9 Characters: 18751 Updates/Obsoletes/SeeAlso: None I-D Tag:draft-ietf-avt-rtp-framing-contrans-06.txt URL:http://www.rfc-editor.org/rfc/rfc4571.txt This memo defines a method for framing Real-time Transport Protocol (RTP) and RTP Control Protocol (RTCP) packets onto connection-oriented transport (such as TCP). The memo also defines how session descriptions may specify RTP streams that use the framing method. [STANDARDS TRACK] This document is a product of the Audio/Video Transport Working Group of the IETF. This is now a Proposed Standard Protocol. STANDARDS TRACK: This document specifies an Internet standards track protocol for the Internet community,and requests discussion and suggestions for improvements.Please refer to the current edition of the Internet Official Protocol Standards (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF list and the RFC-DIST list. Requests to be added to or deleted from the IETF distribution list should be sent to [EMAIL PROTECTED] Requests to be added to or deleted from the RFC-DIST distribution list should be sent to [EMAIL PROTECTED] Details on obtaining RFCs via FTP or EMAIL may be obtained by sending an EMAIL message to [EMAIL PROTECTED] with the message body help: ways_to_get_rfcs. For example: To: [EMAIL PROTECTED] Subject: getting rfcs help: ways_to_get_rfcs Requests for special distribution should be addressed to either the author of the RFC in question, or to [EMAIL PROTECTED] Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. Submissions for Requests for Comments should be sent to [EMAIL PROTECTED] Please consult RFC 2223, Instructions to RFC Authors, for further information. Joyce K. Reynolds and Sandy Ginoza USC/Information Sciences Institute ... ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce
RFC 4586 on Extended RTP Profile for Real-time Transport Control Protocol (RTCP)-Based Feedback: Results of the Timing Rule Simulations
A new Request for Comments is now available in online RFC libraries. RFC 4586 Title: Extended RTP Profile for Real-time Transport Control Protocol (RTCP)-Based Feedback: Results of the Timing Rule Simulations Author: C. Burmeister, R. Hakenberg, A. Miyazaki, J. Ott, N. Sato, S. Fukunaga Status: Informational Date: July 2006 Mailbox:[EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED] Pages: 28 Characters: 66759 Updates/Obsoletes/SeeAlso: None I-D Tag:draft-burmeister-avt-rtcp-feedback-sim-06.txt URL:http://www.rfc-editor.org/rfc/rfc4586.txt This document describes the results achieved when simulating the timing rules of the Extended RTP Profile for Real-time Transport Control Protocol (RTCP)-Based Feedback, denoted AVPF. Unicast and multicast topologies are considered as well as several protocol and environment configurations. The results show that the timing rules result in better performance regarding feedback delay and still preserve the well-accepted RTP rules regarding allowed bit rates for control traffic. This memo provides information for the Internet community. This document is a product of the Audio/Video Transport Working Group of the IETF. INFORMATIONAL: This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited. This announcement is sent to the IETF list and the RFC-DIST list. Requests to be added to or deleted from the IETF distribution list should be sent to [EMAIL PROTECTED] Requests to be added to or deleted from the RFC-DIST distribution list should be sent to [EMAIL PROTECTED] Details on obtaining RFCs via FTP or EMAIL may be obtained by sending an EMAIL message to [EMAIL PROTECTED] with the message body help: ways_to_get_rfcs. For example: To: [EMAIL PROTECTED] Subject: getting rfcs help: ways_to_get_rfcs Requests for special distribution should be addressed to either the author of the RFC in question, or to [EMAIL PROTECTED] Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. Submissions for Requests for Comments should be sent to [EMAIL PROTECTED] Please consult RFC 2223, Instructions to RFC Authors, for further information. Joyce K. Reynolds and Sandy Ginoza USC/Information Sciences Institute ... ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce
