Re: non-solution
On Wed, 23 Jun 2004, Iljitsch van Beijnum wrote: On 23-jun-04, at 3:54, Ed Gerck wrote: Of course, I still believe that insisting in only using the email for communications and screaming bloody murder when it does not work for some reason, at some time, is very un-Internet. If you want only a single path, you have to live with the resulting single point of failure. Allowing web-based messages in addition to email is a simple and cost-effective way to provide redundancy and reduce the importance of problems such as reported by Anderson. The IETF has used email as its primary method of conducting its business for almost 20 years. The IETF is also in charge of all the relevant standards. So if email doesn't work, I think the IETF should fix it rather than come up with ad-hoc additional communication mechanisms that have more than enough problems of their own. I am in agreement that the mailing list mechanism should not be tampered with... it works, so don't break it. The addition of realtime facilities like irc could potentially augment the process, as long as the dialogs were archived for public consumption. Creating such a new channel only gives people with unreasonable email habits (such as rejecting replies to list messages without saying why) positive feedback so email becomes even less reliable. ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf sleekfreak pirate broadcast http://sleekfreak.ath.cx:81/ ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
Is the IANA a function performed by ICANN ?
My understanding was that IANA is a neutral, independent, technical authority, everyone using the TCP/IP technology could trust, independently from any operational, political, national, commercial consideration which are the areas of ICANN, and of other bodies (such as GAC, MINC, ITU, ISOC, UN, etc.). Also, that as the custodian of the references necessary to use the IETF IP, it was part of the IETF IPR protection system. I understand that it predated the creation of ICANN, of ISOC, of IETF and even (under the name of NIC) of the DNS. I am therefore surprised and (IANAL) I am not sure about the implications of the following IANA definition, in a document ICANN is to publish on Monday : the Internet Assigned Numbers Authority (IANA) is a function performed by ICANN. http://www.iana.org/procedures/delegation-data.html ICANN's position within the intergovernance is under UN study, subject to possible political negotiations or intergovernmental agreements (cf. the ongoing WSIS Prepcom meeting in Hammamet). ICANN is only under contract for three years with the USG. RIRs only entered into an MoU with ICANN on the grounds that it may not be still here in two years. The majority of ccTLDs are not interested in joining ICANN's ccNSO. I do not understand how this fits with the necessity of a perpetual, stable, not controverted, consensually accepted, trusted technical standard parameters repository? Or do I read the definition wrong? jfc ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
Re: Is the IANA a function performed by ICANN ?
On Fri, 25 Jun 2004 22:05:36 +0200, JFC (Jefsey) Morfin [EMAIL PROTECTED] said: the Internet Assigned Numbers Authority (IANA) is a function performed by ICANN. http://www.iana.org/procedures/delegation-data.html grounds that it may not be still here in two years. The majority of ccTLDs are not interested in joining ICANN's ccNSO. I do not understand how this IANA and the ccNSO/ccTLD are two different beasts. ccNSO and company keep track of what NS records are authoritative for what zones. IANA keeps track of things like the fact that HTTP is port 80, and which DHCP options use what numbers, and the like. pgpSc3nToMxtK.pgp Description: PGP signature ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
Re: Is the IANA a function performed by ICANN ?
At 22:39 25/06/04, [EMAIL PROTECTED] wrote: IANA and the ccNSO/ccTLD are two different beasts. hmmm. They seem now to be both ICANN stuff. This is the point. ccNSO and company keep track of what NS records are authoritative for what zones. Happily not (most of the ccTLD would not like it !!!). This is a IANA job. At least until Monday. Then it seems it will be an ICANN job, under IANA trade name. IANA keeps track of things like the fact that HTTP is port 80, and which DHCP options use what numbers, and the like. We agree. And this Internet Assigned Numbers Authority (IANA) is a function performed by ICANN. Is IETF OK with that? I understood that the functions of the IANA were _currently_ supported under contract by ICANN. I have no position on this. I just want to understand where IANA fits in the intergovernance. I quoted ccTLDs and RIRs because they both expressed concerns about ICANN still being around three years from now. There is the same feeling among the @large left-overs. If ICANN closed I would not cry. But if it closed the global NIC, a contingency plan would be necessary. Other countries will certainly initiate such a plan. It is to be supposed they will mirror ICANN numbers for a while, but they may also introduce their additional ones for many reasons (testing [cf. ICP-3], national needs, etc. ). OK with me as long as they first intergovern a conflict resolution system and eventually the resulting distributed global NIC they will form. jfc ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
Re: Is the IANA a function performed by ICANN ?
On Fri, 25 Jun 2004, JFC (Jefsey) Morfin wrote: My understanding was that IANA is a neutral, independent, technical authority the Internet Assigned Numbers Authority (IANA) is a function performed by ICANN. There is a significant lack of clarity in these matters. ICANN has a number of legal arrangements with the US Dept of Commerce and its subagencies. The most relevant to IANA is a sole-source purchase order that comes from the National Atmospheric and Oceanic Administration (a sub-agency of the DoC) under which NOAA is purchasing an essentially undefined thing called the IANA function and ICANN is providing that thing for zero dollars. Usually in a purchase order the flow of deliverables runs towards the purchasor. In this case nothing particularly tangible flows towards the NOAA, but there does seem to be a rather cloudy delegation of authority from NOAA to ICANN. In addition there is the oft-asked and never answered question of whether NOAA (or NTIA, another sub-agency of the Dept of Commerce) has such authority to delegate in the first place. (The GAO did examine that question and found the authority to be lacking.) In any event, what commeth via purchase order can goeth via the lapse of that purchase order. Unless there is some unwritten accord, ICANN has no guarantee that it will continue to be able to act as the uncompeted, sole-source provider of the IANA function. The IANA function as practiced by ICANN appears to have at several distinct parts: 1) The operation of the L root server. I have never heard one bad word about ICANN's performance with respect to the L server As far as I can tell, the hands on those knobs are very competent. 2) The assignment and recordation of protocol numbers. This is the classical Numbers Czar function. Again, this seems to be competently handled, although I have heard complaints that processing of number assignments is taking too long. And I have had my own concern that this function is really something that more properly belongs under the IETF's umbrella. 3) ccTLD assignment authority. This is the controversial function. This is a job that requires IANA to decide who gets to act as the internet presence of each sovereign nation (that is, each sovereign nation except the US - US dealt with the .us TLD outside of ICANN and despite ICANN.) Yes, there are competing theories of whether a ccTLD is a direct aspect of sovreignty or is merely a database key that happens to be isomorphic with, but not dependent upon, the existance of soverign states. My own sense is that the latter theory is not flying well among the collective governments of the world. ICANN does not keep time cards, or at least it didn't when I last checked. And there is a great intermingling of tasks among the ICANN/IANA staff. These two aspects combine to make it very difficult to assign a quantitiative cost or level-of-effort number to IANA as a whole and much less to the distinct IANA tasks. However, by observation it appears that the bulk of the cost, and trouble, of IANA is in item #3. I have had concern that ICANN, or rather IANA, is being used as a pawn by political factions in a number of countries. ICANN's redelegations are often based on fairly thin bodies of evidence and are supported often by some rather questionable assertions (e.g. a letter relinquishing a ccTLD that was on an otherwise blank sheet of paper without letterhead and over the unverified signature of someone claiming to be the long lost contact.) During my term I never felt that ICANN or IANA had the staff expertise to be able to swim in those shark infested waters. However, my sense is that with the advent of current president and other staff changes that ICANN, oops, IANA, is perhaps better equipped for this now than it was 18 months ago. But the question is still present: Might not the question of who is the most rightful operator of a ccTLD be better handled by existing organizations that are much more sophisticated in matters pertaining to who is the rightful sovereign power of a nation? --karl-- ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
Re: Is the IANA a function performed by ICANN ?
see RFC 2860 Scott ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
RFC 3802 on Toll Quality Voice - 32 kbit/s Adaptive Differential Pulse Code Modulation (ADPCM) MIME Sub-type Registration
A new Request for Comments is now available in online RFC libraries. RFC 3802 Title: Toll Quality Voice - 32 kbit/s Adaptive Differential Pulse Code Modulation (ADPCM) MIME Sub-type Registration Author(s): G. Vaudreuil, G. Parsons Status: Standards Track Date: June 2004 Mailbox:[EMAIL PROTECTED], [EMAIL PROTECTED] Pages: 7 Characters: 11686 Obsoletes: 2422 I-D Tag:draft-ietf-vpim-vpimv2r2-32k-03.txt URL:ftp://ftp.rfc-editor.org/in-notes/rfc3802.txt This document describes the registration of the MIME sub-type audio/32KADPCM Adaptive Differential Pulse Code Modulation for toll quality audio. This audio encoding is defined by the ITU-T in Recommendation G.726. This document is a product of the Voice Profile for Internet Mail Working Group of the IETF. This is now a Draft Standard Protocol. 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.echo 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 ... Below is the data which will enable a MIME compliant Mail Reader implementation to automatically retrieve the ASCII version of the RFCs. ftp://ftp.isi.edu/in-notes/rfc3802.txt ___ IETF-Announce mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf-announce
WG Action: RECHARTER: Multiprotocol Label Switching (mpls)
The charter of the Multiprotocol Label Switching (mpls) working group in the Routing Area of the IETF has been updated. For additional information, please contact the Area Directors or the working group Chairs. Multiprotocol Label Switching (mpls) Current Status: Active Working Group Chair(s): George Swallow [EMAIL PROTECTED] Loa Andersson [EMAIL PROTECTED] Routing Area Director(s): Bill Fenner [EMAIL PROTECTED] Alex Zinin [EMAIL PROTECTED] Routing Area Advisor: Alex Zinin [EMAIL PROTECTED] Mailing Lists: General Discussion: [EMAIL PROTECTED] To Subscribe: [EMAIL PROTECTED] In Body: subscribe (unsubscribe) Archive: http://cell.onecall.net/cell-relay/archives/mpls/mpls.index.html Description of Working Group: The MPLS working group is responsible for standardizing a base technology for using label switching and for the implementation of label-switched paths over various packet based link-level technologies, such as Packet-over-Sonet, Frame Relay, ATM, and LAN technologies (e.g. all forms of Ethernet, Token Ring, etc.). This includes procedures and protocols for the distribution of labels between routers and encapsulation. The working group is also responsible for specifying the necessary MIBs for the functionality specified in the base MPLS technology. The first generation of the MPLS standards are largely complete, and the current WG work items are: - procedures and protocols for multicast protocol extensions for point-to-multipoint TE, including soft-preemption - Define requirements and mechanisms for MPLS OAM - Define an overall OAM framework for MPLS applications - MPLS-specific aspects of traffic engineering for multi-areas/multi-AS in cooperation with the CCAMP WG - Determine (with CCAMP) what procedures are appropriate for evaluating proposals to extend the MPLS and GMPLS protocols, and document these - Document current implementation practices for MPLS load sharing The Working Group chairs tracking of the working group documents can be viewed at http://www.tla-group.com/~mpls/mpls-wg-docs.htm Goals and Milestones: Done Submit documents from original MPLS effort to IESG Done Framework for IP multicast over label-switched paths ready for advancement. Done LDP fault tolerance specification ready for advancement to Proposed Standard Done Submit Definitions of Managed Objects for MultoiProtocol Label Switching, Label Distribution Protocol (LDP) to the IESG for publication as Proposed Standards Done Specification for MPLS-specific recovery ready for advancement. Done Submit Multiprotocol Label Switching (MPLS) Forward Equivalency Class-To-Next Hop Label Forwarding Entry Management Information Base to the IESG for publication as Proposed Standards Done Submit Multiprotocol Label Switching (MPLS) Label Switching Router (LSR), Management Information Base to the IESG for publication as Proposed Standards Done Submit Multiprotocol Label Switching (MPLS) Management Overview to the IESG for publication as Proposed Standards Done Submit Definitions of Textual Conventions for Multiprotocol Label Switching (MPLS) Management to the IESG for publication as Proposed Standards Done Submit Multiprotocol Label Switching (MPLS) Traffic Engineering Management Information Base to the IESG for publication as Proposed Standards Done Submit the Traffic Engineering Link MIB to the IESG for as a Proposed Standard Done Submit a specification on Encapsulations to carry MPLS over IP and GRE to the IESG for as a Proposed Standard Nov 03 Together with CCAMP complete and establish the (G)MPLS change process Apr 04 Advance MPLS Architecture and MPLS encapsulation to Draft Standard Apr 04 Submit a specification on Soft Pre-emption of LSP Tunnels to the IESG for publication as a Proposed Standard Apr 04 Submit specification on LSR Self Test to the IESG for publication as a Proposed Standard Jul 04 Submit specification on LSP Ping to the IESG for publication as a Proposed Standard Jul 04 Submit a document defining the scope, requirements, and issues to resolve for setup of P2MP TE LSPs (MPLS and GMPLS) Aug 04 Submit an OAM Framework Document to the IESG for publication as an Informational RFC Oct 04 Advance 'Extension to RSVP for LSP Tunnels' to Draft Standard Nov 04 Submit document(s) specifying protocol extensions, enhancements and mechanisms for setup of P2MP TE LSPs Nov 04 Submit a BCP on MPLS load sharing to the IESG ___ IETF-Announce mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf-announce
Document Action: 'Protocol Independent Multicast - Dense Mode (PIM-DM): Protocol Specification (Revised)' to Experimental RFC
The IESG has approved the following document: - 'Protocol Independent Multicast - Dense Mode (PIM-DM): Protocol Specification (Revised) ' draft-ietf-pim-dm-new-v2-05.txt as an Experimental RFC This document is the product of the Protocol Independent Multicast Working Group. The IESG contact persons are Alex Zinin and Bill Fenner. Technical Summary This document specifies Protocol Independent Multicast - Dense Mode (PIM-DM). PIM-DM is a multicast routing protocol that uses the underlying unicast routing information base to flood multicast datagrams to all multicast routers. Prune messages are used to prevent future messages from propagating to routers with no group membership information. Working Group Summary The WG has a consensus on this document. Protocol Quality The document has been reviewed for the IESG by Alex Zinin. RFC Editor Note: Section 7.3, 2nd paragraph, 1st sentence: OLD: To use IPSec, the administrator of a PIM network configures each PIM router with one or more Security Associations and associated Security Parameters Indices that are used by senders to sign PIM protocol ^ messages and are used by receivers to authenticate received PIM protocol messages. NEW: To use IPSec, the administrator of a PIM network configures each PIM router with one or more Security Associations and associated Security Parameters Indices that are used by senders to authenticate PIM protocol messages and are used by receivers to authenticate received PIM protocol messages. ___ IETF-Announce mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf-announce
