Re: MP3 audio streaming for IETF 62
On Sun, 2005-03-06 at 19:43 -0800, Joel Jaeggli wrote: I look forward to more opportunities for multicast evangelism in the future. I think I can speak for Hans, Lucy, myself and the rest of the crew at the UO when I say we still believe that multicast holds out the promise of an empowering, subversive technology for data delivery whose time will come. Bringing the power to the people(tm) is really the way to go. When people can use it then they might start using it and demanding it from their ISP's. When they don't know it exists or cannot use it because there is nobody providing it at all, they will never figure out how much fun it is and the possibilities it can give them. m6bone is doing a good job at this, getting more people connected though is the next step. I sincerely hope that ISP's would start offering multicast connectivity. They could do it in one go together with IPv6 connectivity. There are a few ISP's doing this as a trial/experimental service. This allows their tech folks to play with it while not demanding too much time from them when it breaks... just my two rapfen... ;) Greets, Jeroen signature.asc Description: This is a digitally signed message part ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: MP3 audio streaming for IETF 62
I have always believed this sort of technology is driven by domestic use and the missing component is 'always-on' Internet to the home (as opposed to paying per minute of usage). This started to appear around me (UK) in 2004; give it another two years to gain market penetration and this technology will be viable Tom Petch - Original Message - From: Jeroen Massar [EMAIL PROTECTED] To: Joel Jaeggli [EMAIL PROTECTED] Cc: ietf@ietf.org Sent: Monday, March 07, 2005 9:33 AM Subject: Re: MP3 audio streaming for IETF 62 ___ 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
Contact for network problems at IETF62?
Much gnashing of teeth in Salon D this morning. DHCP failing for v4, IPv6 connectivity coming and goping Seems everyone in the room is affected. (So we didn't get a jabber scribe for mboned ;) -- Tim ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Contact for network problems at IETF62?
Much gnashing of teeth in Salon D this morning. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
IETF62 Network and Terminal Room Information
Network and Terminal Room Information IETF 62 ? Minneapolis, MN Terminal Room -- The Terminal Room is located in Marquette and Hennepin on the second floor of the Minneapolis Hilton and is open 24 hours a day beginning at 4pm on Sunday March 6th and ending at 12 noon on Friday March 11th. A help desk is being provided and will be manned from 8:00 AM to 8:00 PM every day. The room itself consists of approximately 120 seats providing wired 10/100/1000 Ethernet access and 110v North American power ports. There are also two duplex printers available. Please note that this terminal room has, in fact, no terminals, PCs or other user-accessible machines. It is simply a place to get power and wired Internet access. When using the Ethernet connections in the Terminal Room, IPv4 addressing is provided via DHCP. Please use Dynamic Autoconfiguration for IPv6. Unlike the wireless networks, IP multicast is enabled for the terminal room network. Network Basics - The IETF 62 network connects to the Internet via a metropolitan gigabit Ethernet link with a backup 54-megabit wireless link. The entire event is addressed out of the 130.129.0.0/16 block for IPv4 and 2001:468:19ff::/48 for IPv6. IPv4 multicast and IPv6 are being provided from Abilene/I2. Wireless An 802.11 a/b/g wireless network is being provided liberally in the Minneapolis Hilton. The areas being specifically covered are the meeting rooms and hallways in the conference area, the executive lounge, the lobby, and the bar area. To use this network, associate with the beaconed SSID of ietf62. IPv4 addressing is provided via DHCP. For IPv6 and IPv4 combined services, associate with the open but un-beaconed SSID ietf62-ipv6 . IPv6 clients should use Dynamic Autoconfiguration. Due to bandwidth concerns IP multicast is not available on this network. For those interested in a bit more link-layer security, a 128-bit WEP enabled SSID is available. It must be manually configured, as there is no beacon for this network, The SSID is ietf62-wep and the WEP key is wepisinsecure (Hex: 7765706973696e736563757265) For substantially better link-layer security, we are providing dynamic WEP keying using 802.1X. It also must be manually configured because there is no beacon. Note that is dynamic WEP, not TKIP or WPA. To use 802.1X: 1. Associate to SSID: ietf62-dot1x 2. Use PEAP/MSCHAPv2, TTLS/PAP, TTLS/CHAP, TLS 3. Do Not Verify Server Cert and we wont verify yours :) 4. UserName and/or Realm can be anything, as well as outer tunnel identity for TTLS. ex. [EMAIL PROTECTED] 5. Password must be ietf62 The proper operation of the wireless network requires the assistance of all users. One of the most significant issues with wireless performance in past IETF meetings has been wireless clients automatically, or accidentally initiating ad-hoc networks that act as the official IETF wireless network, causing other users to associate with false IETF wireless networks. Therefore, please disable your client's ability to create an ad-hoc network and as well as the ability to automatically join an ad-hoc network. If you are using Windows XP or Mac OS X 10.3 to manage your wireless client, the instructions to disable creation of ad-hoc networks are listed below. If you are using other systems, please do what ever your particular wireless client management system requires to turn off ad-hoc networks. Instructions for Mac OS X -- Open System Preferences - Network - Airport and un-check the box for Allow this computer to create networks. Instructions for Windows XP - Open Properties - wireless networks - advanced and then select access point (infrastructure) networks only and unselect automatically connect to non-preferred networks. Printing -- Two printers are located in the Terminal Room and are available to all IETF users. The printers themselves are HP LaserJet 4200Ns which are Postscript capable and have the duplex option installed. The printers are accessible via IPP, LPD, and Windows Printing (via samba). IPP - URI ipp://lpd.ietf62.ietf.org/printer cups - browsing enabled and should be discovered automatically Mac - under Printer Setup Utility use IETF_62_Terminal_Room under shared printers Windows users - In an IE window type in \\lpd\terminal_room_printers A warning/error message may pop-up saying the server does not have the correct printer driver installed, just hit OK. Next an Add Printer Wizard dialogue box will appear, you need to select two things: In the left window (Manufacturer) select 'HP'. Then in the right hand window (Printers), scroll down and select 'HP LaserJet 4200N', then hit 'Ok'. o You may see the status of the printer say something like 'Access denied, unable to connect' just ignore this, it should work fine. o You may need to disable your VPN connection(s).
Re: Contact for network problems at IETF62?
Gentlepeople, Yes, we are aware of issues on the wireless side of the net this morning and are actively working on it. Sorry for the hassle. As for a general address to send network problems, please send to [EMAIL PROTECTED] That's the mailing list for everyone involved in building and running the network. - Jim On Mar 7, 2005, at 9:16 AM, Tim Chown wrote: Much gnashing of teeth in Salon D this morning. DHCP failing for v4, IPv6 connectivity coming and goping Seems everyone in the room is affected. (So we didn't get a jabber scribe for mboned ;) -- Tim ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Contact for network problems at IETF62?
Same in salon A as well. I think the outage was at least the third floor, but it seems to be OK now. Andy - At 3/7/2005 03:16 PM +, Tim Chown wrote: Much gnashing of teeth in Salon D this morning. DHCP failing for v4, IPv6 connectivity coming and goping Seems everyone in the room is affected. (So we didn't get a jabber scribe for mboned ;) -- Tim ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Need for an Agenda Cutoff date?
Hi, all, With agendas appearing ever later - including last night, the issue of cutoff dates should be revisited. If reading the drafts to be discussed is NOT an issue, then the I-D cutoff dates should be dropped. If reading the drafts IS an issue, then, by correlary, there should be a corresponding cutoff date for agendas - e.g., 1 week after the last cutoff I-D date. Jjust as I-Ds that pass the cutoffs are not published for this IETF, WGs that fail to meet that deadline should be CANCELLED. Consider this a proposal, or at least a request. Joe signature.asc Description: OpenPGP digital signature ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
[Russ Housley] MD5 and SHA-1 Status
---BeginMessage--- Two significant announcements have been made in the past month. MIME-Version: 1.0 First, at the RSA Conference last month, an attack against SHA-1 was announced. See http://www.schneier.com/blog/archives/2005/02/sha1_broken.html for a summary of the announcement. The attack, if it is every written up, published, and verified, is a 2^69 work factor. SHA-1 was designed to have a 2^80 work factor, so this is a significant reduction, but we have time to figure out the best course of action. Second, Lenstra et al announced a method for the construction of pairs of valid X.509 certificates in which the to be signed parts form a collision for the MD5 hash function. As a result the issuer signatures in the certificates will be the same when the issuer uses MD5 as its hash function. See http://eprint.iacr.org/2005/067 This work builds on an attack on MD5 that was announced about a year ago. Several working groups depend on one-way hash functions. Yet, we do not think that this topic should consume huge amounts of time in every one of these working groups. Therefore, we will be discussing this topic at SAAG on Thursday. While it is clear that this topic will require some IETF action, it is not yet a crisis. That is, we can walk to a solution, there is no need to run. If you are interested in this topic, please join the SAAG discussion on Thursday. IETF Security Area Directors, Russ Housley Sam Hartman ---End Message--- ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
request for stable meeting noc address
(bcc'ing the secretariat to generate a trouble ticket) I'd like to request a stable (from meeting to meeting) email address and web page for network operations at IETF meetings. Thanks, --aaron ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Need for an Agenda Cutoff date?
It seems the cutoff is more often a driver to get updates written, and 00 drafts kicked off. One alternative is to review other means to encourage timely and regular draft updates? This might help distribute the load through the year rather than into three hectic chokepoints. Tim On Mon, Mar 07, 2005 at 08:03:16AM -0800, Joe Touch wrote: Hi, all, With agendas appearing ever later - including last night, the issue of cutoff dates should be revisited. If reading the drafts to be discussed is NOT an issue, then the I-D cutoff dates should be dropped. If reading the drafts IS an issue, then, by correlary, there should be a corresponding cutoff date for agendas - e.g., 1 week after the last cutoff I-D date. Jjust as I-Ds that pass the cutoffs are not published for this IETF, WGs that fail to meet that deadline should be CANCELLED. Consider this a proposal, or at least a request. Joe ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf -- Tim ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
jabber working?
Can someone else double check jabber? - i am having issues connecting to any of the morning sesssions. cheers, jamal ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: jabber working?
Yup, there's some chatter in the hallway room right now - mostly people checking their connections. Andy - At 3/7/2005 11:26 AM -0500, jamal wrote: Can someone else double check jabber? - i am having issues connecting to any of the morning sesssions. cheers, jamal ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: WG+BOF chatrooms
On Wed, Mar 02, 2005 at 09:18:09PM -0800, Aaron Falk wrote: Peter Saint-Andre wrote: FYI, I have just set up chatrooms at ietf.xmpp.org for all the BOFs which are currently listed on the IETF 62 agenda page: Peter- Many thanks! Can you confirm that users will be able to set the Subject: in the chatrooms? On teleconferences I've found that very useful to keep track of the topic. I imagine it makes the jabber logs more useful. In the past, I've found that when I tried to set/change the subject line I received an authorization error. I fixed that earlier today, so all of the rooms should now allow subject changes. Peter ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Need for an Agenda Cutoff date?
Joe Touch wrote: Hi, all, With agendas appearing ever later - including last night, the issue of cutoff dates should be revisited. If reading the drafts to be discussed is NOT an issue, then the I-D cutoff dates should be dropped. If reading the drafts IS an issue, then, by correlary, there should be a corresponding cutoff date for agendas - e.g., 1 week after the last cutoff I-D date. Jjust as I-Ds that pass the cutoffs are not published for this IETF, WGs that fail to meet that deadline should be CANCELLED. Consider this a proposal, or at least a request. +1 Julian (still wondering whether there'll be a WebDAV WG meeting -- neither is an agenda available, nor was there any announcement on the WG's mailing list) -- green/bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Need for an Agenda Cutoff date?
Joe, There is an agenda cutoff that WG chairs are supposed to respect. This time it was: The agenda for the Working Group is due by Monday, February 28 at 12:00 ET (17:00 GMT). But there were many late agendas and there was a glitch in the process of posting them. For BOFs, the formal BOF proposal must include an agenda, and that was due this time on February 21. We need to try and follow our own rules next time. Brian Joe Touch wrote: Hi, all, With agendas appearing ever later - including last night, the issue of cutoff dates should be revisited. If reading the drafts to be discussed is NOT an issue, then the I-D cutoff dates should be dropped. If reading the drafts IS an issue, then, by correlary, there should be a corresponding cutoff date for agendas - e.g., 1 week after the last cutoff I-D date. Jjust as I-Ds that pass the cutoffs are not published for this IETF, WGs that fail to meet that deadline should be CANCELLED. Consider this a proposal, or at least a request. Joe ___ 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: Need for an Agenda Cutoff date?
Brian E Carpenter wrote: Joe, There is an agenda cutoff that WG chairs are supposed to respect. This time it was: The agenda for the Working Group is due by Monday, February 28 at 12:00 ET (17:00 GMT). But there were many late agendas and there was a glitch in the process of posting them. For BOFs, the formal BOF proposal must include an agenda, and that was due this time on February 21. We need to try and follow our own rules next time. What we have, IMO, is a deadline, but not a cutoff - as in miss the date and you don't get to hold your WG. Joe Brian Joe Touch wrote: Hi, all, With agendas appearing ever later - including last night, the issue of cutoff dates should be revisited. If reading the drafts to be discussed is NOT an issue, then the I-D cutoff dates should be dropped. If reading the drafts IS an issue, then, by correlary, there should be a corresponding cutoff date for agendas - e.g., 1 week after the last cutoff I-D date. Jjust as I-Ds that pass the cutoffs are not published for this IETF, WGs that fail to meet that deadline should be CANCELLED. Consider this a proposal, or at least a request. Joe ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf signature.asc Description: OpenPGP digital signature ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Need for an Agenda Cutoff date?
Brian E Carpenter wrote: Joe, There is an agenda cutoff that WG chairs are supposed to respect. This time it was: The agenda for the Working Group is due by Monday, February 28 at 12:00 ET (17:00 GMT). But there were many late agendas and there was a glitch in the process of posting them. Guilty (IPoIB WG Chair here) - now solution space For BOFs, the formal BOF proposal must include an agenda, and that was due this time on February 21. We need to try and follow our own rules next time. Time to get Hard about this - if WG agendas aren't published by the cutoff date - the WG doesn't meet. Anyone I've ever talked to says good meeting practice includes publishing an agenda - if there isn't enough interest in publishing an agenda, there isn't enough interest in attending a meeting. If a WG is scheduled to meet on the cutoff date and there isn't an agenda published on the cutoff - a message goes to the WG chair (and maybe to the WG as well) with a warning and if they don't get an agenda to the IETF in 24 hours... CANCEL THE MEETING Brian - is this going to be your first contribution to the IETF as the incoming chair ? Bill (who would have had his meeting cancelled today with these rules - but this is the right thing to do) Brian Joe Touch wrote: Hi, all, With agendas appearing ever later - including last night, the issue of cutoff dates should be revisited. If reading the drafts to be discussed is NOT an issue, then the I-D cutoff dates should be dropped. If reading the drafts IS an issue, then, by correlary, there should be a corresponding cutoff date for agendas - e.g., 1 week after the last cutoff I-D date. Jjust as I-Ds that pass the cutoffs are not published for this IETF, WGs that fail to meet that deadline should be CANCELLED. Consider this a proposal, or at least a request. Joe ___ 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
IETF62 Wireless Network Update
Gentlepeople, We just wanted to give everyone an update on the state of the wireless network here at the Hilton. As most people noticed, we had severe problems involving APs going away starting right around 9am when the first meetings began. We identified and worked around the problem and the APs have been up and reasonably solid since mid-morning. However, despite the APs staying up, we continued to see problems, particularly on the 3rd floor. Common symptoms were: - Long delays before receiving DHCP responses - Long first hop round trip times - Loss on the first hop (in the wireless domain) - Receiving a DHCP address, but still not having the ability to contact the default router Moving forward, we've made several configuration changes which should help matters, and we believe that most of the problems have been resolved. Please (gently) let us know if you're still seeing major problems. The 2.4G band (802.11b/g) is still pretty congested and has some inherent issues in a situation like IETF meetings, so if you have the option to use 802.11a, we'd suggest you do so. As always, any trouble reports or questions can be directed at [EMAIL PROTECTED] Again, our apologies for the frustration and annoyance this is causing. Believe us, we want to get this to work just as much, if not more, than you all do! - Jim ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: IETF62 Wireless Network Update
Jim, Thank you for the update. Best wishes on tomorrow :-) Spencer - Original Message - From: Jim Martin [EMAIL PROTECTED] To: ietf@ietf.org Sent: Monday, March 07, 2005 6:33 PM Subject: IETF62 Wireless Network Update Gentlepeople, We just wanted to give everyone an update on the state of the wireless network here at the Hilton. As most people noticed, we had severe problems involving APs going away starting right around 9am when the first meetings began. We identified and worked around the problem and the APs have been up and reasonably solid since mid-morning. However, despite the APs staying up, we continued to see problems, particularly on the 3rd floor. Common symptoms were: - Long delays before receiving DHCP responses - Long first hop round trip times - Loss on the first hop (in the wireless domain) - Receiving a DHCP address, but still not having the ability to contact the default router Moving forward, we've made several configuration changes which should help matters, and we believe that most of the problems have been resolved. Please (gently) let us know if you're still seeing major problems. The 2.4G band (802.11b/g) is still pretty congested and has some inherent issues in a situation like IETF meetings, so if you have the option to use 802.11a, we'd suggest you do so. As always, any trouble reports or questions can be directed at [EMAIL PROTECTED] Again, our apologies for the frustration and annoyance this is causing. Believe us, we want to get this to work just as much, if not more, than you all do! - Jim ___ 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
draft filenames (Was Re: MARID back from the grave?)
Date: 2005-02-25 22:14
From: Dave Crocker [EMAIL PROTECTED]
in terms of naming, I think syntactically it reduces to:
I-D-Name= draft- owner - category = title - version
owner = author-name / ietf
; who retains change control
author-name = { last name of first author }
category= working-group / topic
working-group = { IETF working group }
topic = { term under which I-D topic fits}
title = { text specific to this I-D, to describe it }
No, because ABNF quoted strings denote case-insensitive matching,
whereas draft filenames are prohibited from containing upper-case
letters. So you would need something like %x64.72.61.66.74
instead of draft, %x69.65.74.66 instead of ietf, and comments
about the upper-case prohibition regarding author names, etc.
Also, I believe that the = in the first line is a typo.
With the proposed restriction of characters to lower-case letters,
digits, and hyphen, there would probably have to be additional
commentary regarding author names (some of which contain accented
letters or use non-Latin scripts), topics, and titles.
Finally, version needs to be defined, e.g.:
version= 2DIGIT ; starting with 00
___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf
62nd IETF - Pocket Agenda
We have received an insert for the pocket agenda that corrects the missing sessions on Thursday afternoon and Friday. Please stop by the IETF registration desk to pick the insert up that can then be stapled into your currently pocket agenda. Please do not discard your currently copy of the pocket agenda. Sorry for the inconvenience. ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce
Protocol Action: 'Removing a Restriction on the use of MPLS Explicit NULL' to Proposed Standard
The IESG has approved the following document: - 'Removing a Restriction on the use of MPLS Explicit NULL ' draft-ietf-mpls-explicit-null-02.txt as a Proposed Standard This document is the product of the Multiprotocol Label Switching Working Group. The IESG contact persons are Alex Zinin and Bill Fenner. Technical Summary The label stack encoding for MPLS (Multi-protocol Label Switching) defines a reserved label value known as IPv4 Explicit NULL and a reserved label value known as IPv6 Explicit NULL. Previously, these labels were only legal when they occurred at the bottom of the MPLS label stack. This restriction is now removed, so that these label values may legally occur anywhere in the stack. Working Group Summary The Working Group had a consensus on advancing this document. Protocol Quality The Document has been reviewed for the IESG by Alex Zinin. The document has been reviewed by the RTG area directorate (Danny McPherson). ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce
Protocol Action: 'An Extensible Markup Language (XML) Configuration Access Protocol (XCAP) Usage for Manipulating Presence Document Contents' to Proposed Standard
The IESG has approved the following document: - 'An Extensible Markup Language (XML) Configuration Access Protocol (XCAP) Usage for Manipulating Presence Document Contents ' draft-ietf-simple-xcap-pidf-manipulation-usage-02.txt as a Proposed Standard This document is the product of the SIP for Instant Messaging and Presence Leveraging Extensions Working Group. The IESG contact persons are Ted Hardie and Scott Hollenbeck. Technical Summary This document describes a usage of the Extensible Markup Language (XML) Configuration Access Protocol (XCAP) for manipulating the contents of Presence Information Data Format (PIDF) based presence document. It is intended to be used in Session Initiation Protocol (SIP) based presence systems, where the Event State Compositor can use the XCAP-manipulated presence document as one of the inputs on which it builds the overall presence state for the presentity. Working Group Summary The working group came to consensus on this document. There were revisions suggested during IETF Last Call, and this version reflects changes made in response to those suggestions. Protocol Quality This document was reviewed for the IESG by Ted Hardie. ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce
Document Action: 'RSVP Security Properties' to Informational RFC
The IESG has approved the following document: - 'RSVP Security Properties ' draft-ietf-nsis-rsvp-sec-properties-06.txt as an Informational RFC This document is the product of the Next Steps in Signaling Working Group. The IESG contact persons are Allison Mankin and Jon Peterson. ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce
Protocol Action: 'The wais URI Scheme' to Historic
The IESG has approved the following document: - 'The wais URI Scheme ' draft-hoffman-wais-uri-03.txt as a Historic 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. Technical Summary The wais URI scheme was originally defined in RFC 1738. This draft is part of a larger effort to provide scheme definitions for those schemes originally definedin RFC 1738, so that RFC 1738 may be marked obsolete. This scheme is being marked historic at the same time, based on its limited use in the Internet. Working Group Summary This document was reviewed by the URI mailing list and it and the general efforthave reasonable community support. Protocol Quality This document was reviewed for the IESG by Ted Hardie. ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce
Protocol Action: 'The prospero URI Scheme' to Historic
The IESG has approved the following document: - 'The prospero URI Scheme ' draft-hoffman-prospero-uri-03.txt as a Historic 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. Technical Summary The prospero URI scheme was originally defined in RFC 1738. This draft is part of a larger effort to provide scheme definitions for those schemes originally defined in RFC 1738, so that RFC 1738 may be marked obsolete. This scheme is being marked historic at the same time, based on its limited use in the Internet. Working Group Summary The draft was discussed on the uri mailing list, and both this draft and the general effort have reasonable community support. Protocol Quality This document was reviewed for the IESG by Ted Hardie. ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce
AMENDED: List of accepted nominations for IETF appointment to ISOC BoT
[My original announcement uncovered a glitch in communications in obtaining acceptance from one of the nominations we received for this position. I've amended the list for completeness, below.-- LLD] The procedure used by the Internet Architecture Board to select an individual toserve a three year term as a Trustee of the Internet Society is documented in RFC3677. The individuals who have accepted a nomination to be a candidate in this process are: - Fred Baker - Scott Bradner - John Klensin - Jordi Palet Martinez - Marshall Rose Comments on these candidates may be submitted to the IAB until the 18th March. The IAB will make a selection by March 25, 2005, and pass this selection to theInternet Engineering Steering Group for confirmation. ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce
