Protocol Action: 'Protocol Independent Multicast - Sparse Mode (PIM-SM): Protocol Specification (Revised)' to Proposed Standard
The IESG has approved the following documents: - 'Protocol Independent Multicast - Sparse Mode (PIM-SM): Protocol Specification (Revised) ' draft-ietf-pim-sm-v2-new-12.txt as a Proposed Standard - 'PIM Sparse-Mode IETF Proposed Standard Requirements Analysis ' draft-ietf-pim-proposed-req-02.txt as an Informational RFC These documents are products of the Protocol Independent Multicast Working Group. The IESG contact persons are Alex Zinin and Bill Fenner. A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-pim-sm-v2-new-12.txt Technical Summary This document specifies Protocol Independent Multicast - Sparse Mode (PIM-SM). PIM-SM is a multicast routing protocol that can use the underlying unicast routing information base or a separate multicast-capable routing information base. It builds unidirectional shared trees rooted at a Rendezvous Point (RP) per group, and optionally creates shortest-path trees per source. Working Group Summary The WG had concensus on progressing this specification. Protocol Quality Alex Zinin reviewed this specification for the IESG. There exist multiple interoperable implementations of the specification. ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce
Protocol Action: 'The Key ID Information Type for the General Extension Payload in MIKEY' to Proposed Standard
The IESG has approved the following document: - 'The Key ID Information Type for the General Extension Payload in MIKEY ' draft-ietf-msec-newtype-keyid-05.txt as a Proposed Standard This document is the product of the Multicast Security Working Group. The IESG contact persons are Russ Housley and Sam Hartman. A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-msec-newtype-keyid-05.txt Technical Summary This document supports a requirement from the 3GPP MBMS architecture. It defines a new type within the General Extension Payload of MIKEY (which is specified in RFC 3830) to support a sub-payload to specify the Key ID type. Working Group Summary The MSEC WG reached consensus without significant discussion or debate. The document is fairly simple, yet it meets the 3GPP requirement. Protocol Quality A minor extension (a new sub-payload type definition) to MIKEY is specified. We are not aware of any implementations. However, an existing MIKEY implementation could add support for this sub-payload with little effort. This document was reviewed by Russ Housley for the IESG. Note to IANA and RFC Editor There is a typo in the IANA conciserations. It is in a sentence that will be deleted prior to publication, so it is not worth a lot of effort to correct, but we do want to be clear. The first paragraph should read as follows: Please add the following to the IANA registry at http://www.iana.org/assignments/mikey-payloads (To be removed after IANA processing). ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce
Protocol Action: 'Cable Device Management Information Base for Data-Over-Cable Service Interface Specification Compliant Cable Modems and Cable Modem Termination Systems' to Proposed Standard
The IESG has approved the following document: - 'Cable Device Management Information Base for Data-Over-Cable Service Interface Specification Compliant Cable Modems and Cable Modem Termination Systems ' draft-ietf-ipcdn-device-mibv2-11.txt as a Proposed Standard This document obsoletes RFC2669. This document is the product of the IP over Cable Data Network Working Group. The IESG contact persons are Bert Wijnen and David Kessens. A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipcdn-device-mibv2-11.txt Technical Summary This document is a revision of the standards track RFC 2669. This document obsoletes RFC 2669. This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it defines a basic set of managed objects for SNMP- based management of DOCSIS-compliant Cable Modems and Cable Modem Termination Systems. Working Group Summary The Working Group has consensus to publish this document as a Proposed Standard. IETF Last Call comments (to rev 10) have been addressed in revision 11. Protocol Quality The MIB module has been reviewed by Randy Presuhn. The overall quality with respect to DOCSIS functionality has been reviewed by Greg White and Eduardo Cardona. This document has been reviewed for the IESG by Bert Wijnen. Note to RFC Editor - Pls change first para of abstract (The table of contents has a ptr to sect 5.1, so that cover the changes from 2669). OLD: This memo is a revision of the standards track RFC 2669. Please see Revision Descriptions below for a description of changes. This document obsoletes RFC 2669. NEW: This memo is a revision of the standards track RFC 2669 and so it obsoletes RFC 2669. - In the abstract, pls also expand the acronym DOCSIS and IPCDN DOCSIS - Data Over Cable Interface Specification. IPCDN - IP over Cable Data Network. ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce
Protocol Action: 'Real-Time Facsimile (T.38) - audio/t38 MIME Sub-type Registration' to Historic
The IESG has approved the following document: - 'Real-Time Facsimile (T.38) - audio/t38 MIME Sub-type Registration ' draft-jones-avt-audio-t38-05.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 Allison Mankin. A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-jones-avt-audio-t38-05.txt This document was Last Called as Proposed Standard in the past, but review by the Audio Video Transport Working Group and the IESG led to concern that the format not become a precedent for future media types. The specification should be published and available for registration, and the media-type should be registered, but only because these are required for a very specific application within ITU SG 16's T.38's real-time fax support. This application is described in the document as a legacy. The Historic designation does not imply that the legacy application should not be operative with this specification and registration to support it, but only that there not be *future* designs, non-legacies, based on this precedent. The media type was sent for review on the ietf-types list recently, referencing RFC 3550 and RFC 4288 (the new media type registration rules) and no issues were raised. ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce
Protocol Action: 'MIME type registration for RTP Payload format for H.224' to Proposed Standard
The IESG has approved the following document: - 'MIME type registration for RTP Payload format for H.224 ' draft-ietf-avt-mime-h224-05.txt as a Proposed Standard This document is the product of the Audio/Video Transport Working Group. The IESG contact person is Allison Mankin. A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-avt-mime-h224-05.txt-05.txt Technical Summary This memo specifies the Media Type (application/H224) used in for example SDP to negotiate the usage of ITU H.224. H.224 includes a far end camera control protocol which is of primary interest for usage by H.224. Procedures for negotiating both uni- and bi-directional sessions in SDP Offer/Answer are specified. Working Group Summary There is consensus in the WG to publish this document. Protocol Quality This document was reviewed the AVT WG. Key revisions clarified the applicability to be primarily H.224, because this does not support far-end camera control in arbitrary Internet environments. The media type was sent for review to the ietf-types list in message: http://www.alvestrand.no/pipermail/ietf-types/2006-February/001653.html and raised no issues. Magnus Westerlund is the WG Chair shepherd. Allison Mankin is the Responsible Area Director. Note to the RFC Editor Abstract Replace the interesting word conversional with conversational ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce
Document Action: 'SDP Descriptors for FLUTE' to Experimental RFC
The IESG has approved the following document: - 'SDP Descriptors for FLUTE ' draft-mehta-rmt-flute-sdp-05.txt as an Experimental RFC This document has been reviewed in the IETF but is not the product of an IETF Working Group. The IESG contact person is Allison Mankin. A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-mehta-rmt-flute-sdp-05.txt This specification was not chartered by either the MMUSIC or RMT working groups because it fits between both, and being an Experimental document, like any reliable multicast document in the Transport Area, it was deemed that it could be worked on most effectively by having targeted reviews by SDP and RMT experts coordinated by the area director. The reviewers were Joerg Ott (MMUSIC Co-Chair), Lorenzo Vicisano (RMT Chair), and Magnus Westerlund (AVT Co-Chair). ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce
Document Action: 'The Intrusion Detection Message Exchange Format' to Experimental RFC
The IESG has approved the following document: - 'The Intrusion Detection Message Exchange Format ' draft-ietf-idwg-idmef-xml-16.txt as an Experimental RFC This document is the product of the Intrusion Detection Exchange Format Working Group. The IESG contact persons are Sam Hartman and Russ Housley. A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-idwg-idmef-xml-16.txt Technical Summary Different elements of intrusion detection systems (IDS) need to communicate with each other. This document defines a standard data model, and implements it as an XML DTD. Working Group Summary There were no major issues during the original approval of this document. However the working group lost momentum addressing IESG comments. By the time the document was next reviewed there was not enough of a working group to form an informed consensus. So this document is being advanced as an experimental submission rather than proposed standard. Protocol Quality This document was reviewed for the IESG by Steve Bellovin. IESG Note The content of this RFC was at one time considered by the IETF, but the working group concluded before this work was approved as a standards-track protocol. This RFC is not a candidate for any level of Internet Standard. The IETF disclaims any knowledge of the fitness of this RFC for any purpose and in particular notes that the decision to publish is not based on complete IETF review for such things as security, congestion control, or inappropriate interaction with deployed protocols. The IESG has chosen to publish this document in order to document the work as it was when the working group concluded and to encourage experimentation and development of the technology. Readers of this RFC should exercise caution in evaluating its value for implementation and deployment. ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce
Last Call: 'Encapsulation Methods for Transport of PPP/HDLC Over MPLS Networks' to Proposed Standard
The IESG has received a request from the Pseudo Wire Emulation Edge to Edge WG to consider the following document: - 'Encapsulation Methods for Transport of PPP/HDLC Over MPLS Networks ' draft-ietf-pwe3-hdlc-ppp-encap-mpls-08.txt as a Proposed Standard 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-04-06. The file can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-pwe3-hdlc-ppp-encap-mpls-08.txt ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce
Last Call: 'Management Information Base for the Session Initiation Protocol (SIP)' to Proposed Standard
The IESG has received a request from the Session Initiation Protocol WG to consider the following document: - 'Management Information Base for the Session Initiation Protocol (SIP) ' draft-ietf-sip-mib-10.txt as a Proposed Standard 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-04-06. The file can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-sip-mib-10.txt ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce
Protocol Action: 'NETCONF Configuration Protocol' to Proposed Standard
The IESG has approved the following documents: - 'NETCONF Configuration Protocol ' draft-ietf-netconf-prot-12.txt as a Proposed Standard - 'Using the NETCONF Configuration Protocol over Secure Shell (SSH) ' draft-ietf-netconf-ssh-06.txt as a Proposed Standard These documents are products of the Network Configuration Working Group. The IESG contact persons are Bert Wijnen and David Kessens. A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-netconf-prot-12.txt Technical Summary NETCONF Configuration Protocol The NETCONF configuration protocol defined in this document provides mechanisms to install, manipulate, and delete the configuration of network devices. It uses an Extensible Markup Language (XML) based data encoding for the configuration data as well as the protocol messages. The NETCONF protocol operations are realized on top of a simple Remote Procedure Call (RPC) layer. Using the NETCONF Configuration Protocol over Secure Shell (SSH) This document describes a method for invoking and running the NETCONF configuration protocol within a Secure Shell (SSH) session as an SSH subsystem. Note: The WG could not decide on a single transport mapping for NETCONF, because different types of programmers want to use the protocol. Therefore, NETCONF defines three transport mappings: SSH, BEEP, and SOAP, where SSH is the mandatory-to-implement protocol. Working Group Summary The NETCONF Working Group has consensus to publish these documents as a Proposed Standard. Protocol Quality It is likely that there are several implementations of these documents in various stages of completion at this time. Several major equipment vendors have indicated interest in supporting this document, and some non-commercial implementations are also expected. An interoperability event (just prior to Paris IETF) was held in which 4 implementations participated and feedback was considered in revisions of these documents. Bert Wijnen reviewed these documents for the IESG. Note to RFC Editor I appologize for the pretty extensive changes, but this was the only way to get this document approved before I am stepping down as AD (thanks, Bert) Please make the following changes: -- for the draft-ietf-netconf-ssh-06.txt document -- - In section 3, page 3 (last line) and 4: OLD: SSHv1. Running NETCONF as an SSH subsystem avoids the need for the script to recognize shell prompts or skip over extraneous information, such as a system message that is sent at shell start-up. However, if a subsystem cannot be used, it should be possible for a client to skip over any system messages that are sent at shell start-up by searching for a NETCONF hello element. Note that this may not avoid problems if system messages are recieved later in the session. NEW: SSHv1. Running NETCONF as an SSH subsystem avoids the need for the script to recognize shell prompts or skip over extraneous information, such as a system message that is sent at shell start-up. However, even when a subsystem is used, some extraneous messages may be printed by the user's start-up scripts. Implementations MUST skip over these messages by searching for an 'xml' start directive, which MUST be followed by a hello element in the 'NETCONF' namespace. - In section 5, page 6, line 4 in 1st para: OLD: ...and terminate the SSH session. NEW: ...and close the SSH session channel. - in the draft-ietf-netconf-prot-12.txt document -- Page 16: OLD: The following rpc-reply illustrates the case of returning multiple rpc-error elements. NEW: The following rpc-reply illustrates the case of returning multiple rpc-error elements. Note that the data models used in the examples in this section use the name element to distinguish between multiple instances of the interface element. On page 34: OLD: If the NETCONF peer supports the :xpath capability (Section 8.9), the value xpath may be used to indicate that the filter element contains an XPath expression. NEW: If the NETCONF peer supports the :xpath capability (Section 8.9), the value xpath may be used to indicate that the select attribute on the filter element contains an XPath expression. Page 39, bottom: OLD: Example: Set the MTU to 1500 on an interface named Ethernet0/0 in the running configuration: NEW: Example: The edit-config examples in this section utilize a simple data model, in which multiple instances of the 'interface' element may be present, and an instance is distinguished by the 'name' element within each 'interface' element. Set the MTU to 1500 on an interface named Ethernet0/0 in the running configuration: On page 50: OLD: If the NETCONF peer
Protocol Action: 'Using the Network Configuration Protocol (NETCONF) Over the Simple Object Access Protocol (SOAP)' to Proposed Standard
The IESG has approved the following document: - 'Using the Network Configuration Protocol (NETCONF) Over the Simple Object Access Protocol (SOAP) ' draft-ietf-netconf-soap-08.txt as a Proposed Standard This document is the product of the Network Configuration Working Group. The IESG contact persons are Bert Wijnen and David Kessens. A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-netconf-soap-08.txt Technical Summary The Network Configuration Protocol (NETCONF) is applicable to a wide range of devices in a variety of environments. The emergence of Web Services gives one such environment, and is presently characterized by the use of the Simple Object Access Protocol (SOAP). NETCONF finds many benefits in this environment: from the re-use of existing standards, to ease of software development, to integration with deployed systems. Herein, we describe SOAP over HTTP and SOAP over BEEP bindings for NETCONF. Working Group Summary The NETCONF Working Group has consensus to publish this document as a Proposed Standard. Protocol Quality It is likely that there are several implementations of this document in various stages of completion at this time. Several major equipment vendors have indicated interest in supporting this document, and some non-commercial implementations are also expected. Bert Wijnen reviewed this document for the IESG. Note to RFC Editor In the IAN Considerations section, please change: OLD: The IANA is requested to assign TCP ports for NETCONF for SOAP over HTTP and SOAP over BEEP. NEW: The IANA is requested to assign a TCP port for NETCONF over SOAP over BEEP, and a TCP port for NETCONF over SOAP over HTTPS. IANA Note -Original Message- From: Andy Bierman [mailto:[EMAIL PROTECTED] Sent: Thursday, March 23, 2006 14:58 To: Bert Wijnen Cc: [EMAIL PROTECTED]; Sam Hartman (E-mail) Subject: Port requests for draft-ietf-netconf-soap-08.txt Hi, Please assign a port number 1024 for the NETCONF protocol over the Simple Object Access protocol, run over the Blocks Extensible Exchange protocol (netconf-soap-beep). Please assign a port number 1024 for the NETCONF protocol over the Simple Object Access protocol, run over the HTTPS protocol (netconf-soap-https). There will be an RFC Editor note added to this document to replace the first sentence of section 5. OLD: The IANA is requested to assign TCP ports for NETCONF for SOAP over HTTP and SOAP over BEEP. NEW: The IANA is requested to assign a TCP port for NETCONF over SOAP over BEEP, and a TCP port for NETCONF over SOAP over HTTPS. thanks, Andy ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce
Protocol Action: 'DHCPv6 Relay Agent Subscriber-ID Option' to Proposed Standard
The IESG has approved the following document: - 'DHCPv6 Relay Agent Subscriber-ID Option ' draft-ietf-dhc-dhcpv6-subid-01.txt as a Proposed Standard This document is the product of the Dynamic Host Configuration Working Group. The IESG contact persons are Margaret Wasserman and Mark Townsley. A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dhc-dhcpv6-subid-01.txt Technical Summary This memo defines a new Relay Agent Subscriber-ID option for the Dynamic Host Configuration Protocol for IPv6 (DHCPv6). The option allows a DHCPv6 relay agent to associate a stable Subscriber-ID with DHCPv6 client messages in a way that is independent of the client and of the underlying physical network infrastructure.mary Working Group Summary This document is the work of the DHC WG. The WG has consensus to publish this document as a Proposed Standard. Protocol Quality This document was reviewed for the IESG by Margaret Wasserman. Note to RFC Editor DROP: 2. Requirements Terminology The key words MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL in this document are to be interpreted as described in [2]. --- DROP: Reference [2] to RFC 2119. --- OLD (in Section 3): However, as the DHCPv4 Subscriber-ID suboption [4] specifies NVT ASCII [5] encoded data, in environments where both DHCPv4 [6] and DHCPv6 are being used, it MAY be beneficial to use that encoding. NEW: However, as the DHCPv4 Subscriber-ID suboption [4] specifies NVT ASCII [5] encoded data, in environments where both DHCPv4 [6] and DHCPv6 are being used, it may be beneficial to use that encoding. ^^^ --- OLD (in Section 4): DHCPv6 relay agents MAY be configured to include a Subscriber-ID option in relayed (RELAY-FORW) DHCPv6 messages. How the subscriber-id is assigned and the mechanisms used to configure it are outside the scope of this memo. NEW: DHCPv6 relay agents may be configured to include a Subscriber-ID ^^^ option in relayed (RELAY-FORW) DHCPv6 messages. How the subscriber-id is assigned and the mechanisms used to configure it are outside the scope of this memo. --- OLD (in Section 5): This option provides additional information to the DHCPv6 server. The DHCPv6 server MAY use this information, if available, in addition to other relay agent option data, other options included in the NEW: This option provides additional information to the DHCPv6 server. The DHCPv6 server may use this information, if available, in addition ^^^ to other relay agent option data, other options included in the ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce
Document Action: 'DHCP Options for the Intel Preboot eXecution Environment (PXE)' to Informational RFC
The IESG has approved the following document: - 'DHCP Options for the Intel Preboot eXecution Environment (PXE) ' draft-ietf-dhc-pxe-options-03.txt as an Informational RFC This document is the product of the Dynamic Host Configuration Working Group. The IESG contact persons are Margaret Wasserman and Mark Townsley. A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dhc-pxe-options-03.txt Technical Summary We define DHCP options being used by PXE and EFI clients to uniquely identify booting client machines and their pre-OS runtime environment so the DHCP and/or PXE boot server can return the correct OS bootstrap image (or pre-boot application) name and server to the client. Working Group Summary This document is a work item of the DHC WG. Protocol Quality This document was reviewed for the IESG by Margaret Wasserman. ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce
Protocol Action: 'Cryptographically Generated Addresses (CGA) Extension Field Format' to Proposed Standard
The IESG has approved the following document: - 'Cryptographically Generated Addresses (CGA) Extension Field Format ' draft-bagnulo-cga-ext-02.txt as a Proposed Standard This document has been reviewed in the IETF but is not the product of an IETF Working Group. The IESG contact person is Margaret Wasserman. A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-bagnulo-cga-ext-02.txt Technical Summary This document defines a Type-Length-Value format for Cryptographically Generated Address (CGA) Extensions. Working Group Summary This document is an individual submission. It was reviewed by the IPSEC WG in parellel with IETF Last Call. Protocol Quality This document was reviewed for the IESG by Margaret Wasserman. ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce
Protocol Action: 'Resolution of FQDN Conflicts among DHCP Clients' to Proposed Standard
The IESG has approved the following documents: - 'A DNS RR for Encoding DHCP Information (DHCID RR) ' draft-ietf-dnsext-dhcid-rr-13.txt as a Proposed Standard - 'The DHCP Client FQDN Option ' draft-ietf-dhc-fqdn-option-13.txt as a Proposed Standard - 'Resolution of FQDN Conflicts among DHCP Clients ' draft-ietf-dhc-ddns-resolution-12.txt as a Proposed Standard - 'The DHCPv6 Client FQDN Option ' draft-ietf-dhc-dhcpv6-fqdn-05.txt as a Proposed Standard These documents are products of the Dynamic Host Configuration Working Group. The IESG contact persons are Margaret Wasserman and Mark Townsley. A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dhc-ddns-resolution-12.txt Technical Summary These four documents jointly specify how fully qualified domain names (FQDNs) are handled in DHCP, how the mapping between FQDNs and DHCP-assigned addresses are registered in the DNS, and how conflicts are resolved when multiple DHCP servers or clients attempt to register the same FQDN. In particular: draft-ietf-dhc-ddns-resolution-10.txt: Defines a mechanism to resolve conflicts when multiple DHCP clients or servers try to register the same FQDN in the DNS. draft-ietf-dnsext-dhcid-rr-10.txt: Defines and RR type for use with the DDNS resolution mechanism in the previous document. draft-ietf-dhc-fqdn-option-11.txt: Defines the FQDN option for DHCP(v4). draft-ietf-dhc-dhcpv6-fqdn-03.txt: Defines the FQDN option for DHCPv6. Working Group Summary These documents are the work output of the DNSEXT and DHC WGs. There was consensus in both groups to publish these documents as Proposed Standards. Protocol Quality These documents have been reviewed for the IESG by Margaret Wasserman. ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce
Protocol Action: 'PWE3 Fragmentation and Reassembly' to Proposed Standard
The IESG has approved the following document: - 'PWE3 Fragmentation and Reassembly ' draft-ietf-pwe3-fragmentation-10.txt as a Proposed Standard This document is the product of the Pseudo Wire Emulation Edge to Edge Working Group. The IESG contact persons are Margaret Wasserman and Mark Townsley. A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-pwe3-fragmentation-10.txt Technical Summary This document defines a generalized method of performing fragmentation for use by Pseudo Wire Emulation Edge to Edge (PWE3) protocols and services. Working Group Summary This document is a work item of the PWE3 WG. Protocol Quality This document was reviewed for the IESG by Margaret Wasserman. Note to RFC Editor Please replace: A PE's native service processing (NSP) MAY choose to fragment a packet before allowing it to enter a PW. For example, if an IP packet arrives from a CE with an MTU which will yield a PW packet which is greater than the PSN MTU, the PE NSP may perform IP fragmentation on the packet, also replicating the L2 header for the IP fragments. This effectively creates two (or more) packets, each carrying an IP fragment preceded by an L2 header, for transport individually across the PW. The receiving PE is unaware that the originating host did not perform the IP fragmentation, and as such does not treat the PW packets in any special way. This ultimately has the affect of placing the burden of fragmentation on the PE NSP, and reassembly on the IP destination host. With: In some cases, a PE may be able to fragment an IP version 4 (IPv4) [RFC791] packet before it enters a PW. For example, if the PE can fragment and forward IPv4 packets with the DF bit clear in a manner that is identical to an IPv4 router, it may fragment packets arriving from a CE, forwarding the IPv4 fragments with associated framing for that attachment circuit (AC) over the PW.Architecturally, the IPv4 fragmentation happens before reaching the PW, presenting multiple frames to the PW to forward in the normal manner for that PWType. Thus, this method is entirely transparent to the PW encapsulation and to the remote end of the PW itself. Packet fragments are ultimately reassembled on the destination IPv4 host in the normal way. IPv6 packets are not to be fragmented in this manner. There are 4 ASCII pictograms that need modifying in the following sections. Thetechnical sense is exactly the same, these versions simply depict more context graphically: Section 5.3: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |M|H|0|0|0|0|Length | 0| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | MRU | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Section 5.4 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |M|H|0|0|0|0|Length | 0| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | MRRU | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Section 5.5 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |M|H|0|0|0|0|Length | 0| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |x|S|B|E|x|x|x|x| Sequence Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Section 5.6 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |M|H|0|0|0|0|Length | 0| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |T|L|x|x|S|x|O|P|B|E|x|x| Ver | Length (opt) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce
Document Action: 'Extension to Sockets API for Mobile IPv6' to Informational RFC
The IESG has approved the following document: - 'Extension to Sockets API for Mobile IPv6 ' draft-ietf-mip6-mipext-advapi-07.txt as an Informational RFC This document is the product of the Mobility for IPv6 Working Group. The IESG contact persons are Margaret Wasserman and Mark Townsley. A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mip6-mipext-advapi-07.txt Technical Summary This document describes data structures and API support for Mobile IPv6 as an extension to Advanced Socket API for IPv6. Mobility Support in IPv6 introduces mobility protocol header for IPv6. It is expected that future Mobile IPv6 applications and implementations may need to access Mobility binding messages and Return Routability messages for diagnostic, packet accounting and local policy setting purposes. In order to provide portability for Mobile IP applications that use sockets under IPv6, standardization is needed for the Mobile IPv6 specific APIs. This document provides mechanism for API access to retrieve and set information for Mobility Header messages, Home Address destination options and type 2 Routing header extension headers. It discusses the common data structures and definitions that might be used by advanced Mobile IPv6 socket applications. Working Group Summary This document is a work item of the MIP6 WG. Protocol Quality This document was updated based on AD review comments from Thomas Narten. This document was reviewed for the IESG by Margaret Wasserman. RFC Editor Note OLD: 4. Common Structures and Definitions In this section, the structures are specified in a way so that they maximize the probability that the compiler-layout of data structures are identical to the packet formats on the wire. However, ANSI-C provides few guarantees about the size and alignment of data structures. Thus, depending on the implementation of a compiler, there is a slim chance that in certain systems, the compiled layout of the following data structures may not match the packet formats defined in RFC 3775 [2]. The structure definitions below are examples of contents or the fields that match with the wired packet format in most Operating Systems. Depending on the compiler used as well as the host byte order, the layout of the structures might need to be different in some cases. But as long as they provide the same fields as below we can ensure application portability when using this API. The constants and structures shown below are in network byte order, so an application needs to perform the appropriate byte order conversion (ntohs(), etc) when necessary. NEW: 4. Common Structures and Definitions In this section, the structures are specified in a way so that they maximize the probability that the compiler-layout of data structures are identical to the packet formats on the wire. However, ANSI-C provides few guarantees about the size and alignment of data structures. The assumption is that the Advanced Socket API [1] will pass up the actual packet content (the wire format) in the buffer and in the ancillary data objects. Thus if an implementor has to handle a system where the ANSI-C compiler does not and can not lay out these structures to match the wire formats in RFC 3775 [2], the structures defined by this API can not be supported on such a system. The constants and structures shown below are in network byte order, so an application needs to perform the appropriate byte order conversion (ntohs(), etc) when necessary. ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce
Protocol Action: 'Using the NETCONF Protocol over Blocks Extensible Exchange Protocol (BEEP)' to Proposed Standard
The IESG has approved the following document: - 'Using the NETCONF Protocol over Blocks Extensible Exchange Protocol (BEEP) ' draft-ietf-netconf-beep-10.txt as a Proposed Standard This document is the product of the Network Configuration Working Group. The IESG contact persons are Bert Wijnen and David Kessens. A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-netconf-beep-10.txt Technical Summary This document specifies an transport protocol mapping for the NETCONF protocol over the Blocks Extensible Exchange Protocol (BEEP). Working Group Summary The NETCONF Working Group has consensus to publish this document as a Proposed Standard. Protocol Quality It is likely that there are several implementations of this document in various stages of completion at this time. Several major equipment vendors have indicated interest in supporting this document, and some non-commercial implementations are also expected. The WG would like to thank Marshall Rose for his assistance with portions of this document. Bert Wijnen has reviewed this document for the IESG IANA Note -Original Message- From: Andy Bierman [mailto:[EMAIL PROTECTED] Sent: Thursday, March 23, 2006 14:45 To: Bert Wijnen Cc: [EMAIL PROTECTED] Subject: Port request for draft-ietf-netconf-beep-10.txt Hi, Please assign a port number 1024 for the NETCONF protocol over the Blocks Extensible Exchange protocol, as specified in section 4 of this document. thanks, Andy ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce
Protocol Action: 'IP over InfiniBand: Connected Mode' to Proposed Standard
The IESG has approved the following document: - 'IP over InfiniBand: Connected Mode ' draft-ietf-ipoib-connected-mode-03.txt as a Proposed Standard This document is the product of the IP over InfiniBand Working Group. The IESG contact persons are Margaret Wasserman and Mark Townsley. A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipoib-connected-mode-03.txt Technical Summary This document describes transmission of IPv4/IPv6 packets and address resolution over the connected modes of InfiniBand. Working Group Summary This document is a work item of the IPOIB WG. Protocol Quality This document was reviewed for the IESG by Margaret Wasserman. ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce
Protocol Action: 'DHCPv6 Relay Agent Remote ID Option' to Proposed Standard
The IESG has approved the following document: - 'DHCPv6 Relay Agent Remote ID Option ' draft-ietf-dhc-dhcpv6-remoteid-01.txt as a Proposed Standard This document is the product of the Dynamic Host Configuration Working Group. The IESG contact persons are Margaret Wasserman and Mark Townsley. A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dhc-dhcpv6-remoteid-01.txt Technical Summary This memo defines a new Relay Agent Remote-ID option for the Dynamic Host Configuration Protocol for IPv6 (DHCPv6). This option is the DHCPv6 equivalent for the Dynamic Host Configuration Protocol for IPv4 (DHCPv4) Relay Agent Option's Remote-ID suboption as specified in RFC 3046. Working Group Summary This document is the work of the DHC WG. The WG has consensus to publish this draft as a Proposed Standard. Protocol Quality This document was reviewed for the IESG by Margaret Wasserman. Note to RFC Editor In section 3: OLD: This option MAY be added by DHCPv6 relay agents which terminate switched or permanent circuits and have mechanisms to identify the remote host end of the circuit. NEW: This option may be added by DHCPv6 relay agents which terminate ^^^ switched or permanent circuits and have mechanisms to identify the remote host end of the circuit. OLD: The remote-id field MAY be used to encode, for instance: NEW: The remote-id field may be used to encode, for instance: ^^^ OLD: Each vendor MUST assure that the remote-id is unique for their enterprise-number, as the octet sequence of enterprise-number followed by remote-id MUST be globally unique. One way to achieve uniqueness might be to include the relay agent's DUID [1] in the remote-id. NEW: Each vendor must assure that the remote-id is unique for their enterprise-number, as the octet sequence of enterprise-number followed by remote-id must be globally unique. One way to achieve uniqueness might be to include the relay agent's DUID [1] in the remote-id. In Section 4: OLD: DHCPv6 relay agents MAY be configured to include a Remote-ID option in relayed (RELAY-FORW) DHCPv6 messages. NEW: DHCPv6 relay agents may be configured to include a Remote-ID option ^^^ in relayed (RELAY-FORW) DHCPv6 messages. In Section 5: OLD: This option provides additional information to the DHCPv6 server. The DHCPv6 server, if it is configured to support this option, MAY use this information to select parameters specific to particular users, hosts, or subscriber modems. The combined enterprise-number and remote-id SHOULD be considered an opaque value, with policies based on exact string match only; that is, the remote-id field SHOULD NOT be internally parsed by the server. NEW: This option provides additional information to the DHCPv6 server. The DHCPv6 server, if it is configured to support this option, may ^^^ use this information to select parameters specific to particular users, hosts, or subscriber modems. The combined enterprise-number and remote-id SHOULD be considered an opaque value, with policies based on exact string match only; that is, the remote-id field SHOULD NOT be internally parsed by the server. ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce
Protocol Action: 'The Role of Wildcards in the Domain Name System' to Proposed Standard
The IESG has approved the following document: - 'The Role of Wildcards in the Domain Name System ' draft-ietf-dnsext-wcard-clarify-11.txt as a Proposed Standard This document is the product of the DNS Extensions Working Group. The IESG contact persons are Margaret Wasserman and Mark Townsley. A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dnsext-wcard-clarify-11.txt Technical Summary This is an update to the wildcard definition of RFC 1034. The interaction with wildcards and CNAME is changed, an error condition removed, and the words defining some concepts central to wildcards are changed. The overall goal is not to change wildcards, but to refine the definition of RFC 1034. Working Group Summary This document is a work item of the DNSEXT WG. The WG has consensus to publish this document as a Proposed Standard. Protocol Quality This document was reviewed for the IESG by Margaret Wasserman. ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce
Last Call: 'Update to DirectoryString Processing in the Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile' to Proposed Standard
The IESG has received a request from the Public-Key Infrastructure (X.509) WG to consider the following document: - 'Update to DirectoryString Processing in the Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile ' draft-ietf-pkix-cert-utf8-02.txt as a Proposed Standard 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-04-12. The file can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-pkix-cert-utf8-02.txt ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce
Document Action: 'JavaScript Object Notation (JSON)' to Informational RFC
The IESG has approved the following document: - 'JavaScript Object Notation (JSON) ' draft-crockford-jsonorg-json-04.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 Scott Hollenbeck. A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-crockford-jsonorg-json-04.txt Technical Summary JavaScript Object Notation (JSON) is a light-weight, text-based, language-independent, data interchange format. It was derived from the ECMAScript Programming Language Standard. JSON defines a small set of formatting rules for the portable representation of structured data. This document describes the JSON format and includes a media type registration template. Working Group Summary This document is the work of an individual submitter. It was subjected to MIME-types review, but it is has not been reviewed by an IETF working group. MIME-type review comments have been incorporated into the document. Protocol Quality Scott Hollenbeck has reviewed this document for the IESG. The document includes a no derivative works clause. Note to RFC Editor Please change the title of the document. OLD: JavaScript Object Notation (JSON) NEW: The application/json Media Type for JavaScript Object Notation (JSON) Section 6, OLD: Type name: text NEW: Type name: application ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce
Protocol Action: 'Remote Network Monitoring MIB Extensions for Switch Networks Version 1.0' to Draft Standard
The IESG has approved the following document: - 'Remote Network Monitoring MIB Extensions for Switch Networks Version 1.0 ' RFC 2613 as a Draft Standard This document is the product of the Remote Network Monitoring Working Group. The IESG contact persons are Bert Wijnen and David Kessens. A URL of this RFC is: http://www.ietf.org/rfc/rfc2613.txt Technical Summary This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets. In particular, it defines objects for managing remote network monitoring devices in switched networks environments. Working Group Summary The RMONMIB WG has consensus to publish this document as a Draft Standard. Protocol Quality This document has been reviewed by the RMONMIB WG and implemented by several vendors in network switching equipment. Bert Wijnen has reviewed this document for the IESG. Implementation Report can be accessed at http://www.ietf.org/IESG/Implementations/RFC2613-Implementation.txt NOTE: this document was IETF Last Called back in 2003. That IETF Last Call uncovered thatr this document has a normative depency on RFC2021 which was at PS. RFC2021 has been obsoleted by a new revision, which has been approved as DS. This doc is now in RFC-Editor queue: http://www.rfc-editor.org/queue.html#draft-ietf-rmonmib-rmon2-v2 Since the previous IETF Last Call was so long ago, this new IETF Last Call is intended to make everyone aware that the doc is again on the IESG agenda. IANA Note No actions are needed by IANA. ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce
Protocol Action: 'Encapsulation Methods for Transport of Frame Relay Over MPLS Networks' to Proposed Standard
The IESG has approved the following document: - 'Encapsulation Methods for Transport of Frame Relay Over MPLS Networks ' draft-ietf-pwe3-frame-relay-07.txt as a Proposed Standard This document is the product of the Pseudo Wire Emulation Edge to Edge Working Group. The IESG contact persons are Mark Townsley and Margaret Wasserman. A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-pwe3-frame-relay-07.txt Technical Summary This draft describes how a Frame Relay Pseudowire (PW) is used to carry Frame Relay packets over an MPLS network. This enables service providers to offer emulated Frame Relay services over existing MPLS networks. This document specifies the encapsulation of Frame Relay packets within a pseudo wire. Working Group Summary This work has been thoroughly analysed by the working group and there is consensus for the design. Protocol Quality There are many implementations of this protocol, and it is in operational service. Note to RFC Editor (1) Please replace in section 7.2 information field with bit/byte stuffing, frame relay header removed, and FCS removed. with: information field with the following components removed: bit/byte stuffing, frame relay header, and FCS. (2) Please add an informational reference to RFC 3032 at the end of the first sentence below (and an associated bibliographic listing in the references section). 7.7. MPLS Shim EXP Bit Values If it is desired to carry Quality of Service information, the Quality of Service information SHOULD be represented in the EXP field of the PW MPLS label. If more than one MPLS label is imposed by the ingress LSR, the EXP field of any labels higher in the stack SHOULD also carry the same value. ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce
Protocol Action: 'The AES-CMAC-PRF-128 Algorithm for the Internet Key Exchange Protocol (IKE)' to Proposed Standard
The IESG has approved the following document: - 'The AES-CMAC-PRF-128 Algorithm for the Internet Key Exchange Protocol (IKE) ' draft-songlee-aes-cmac-prf-128-03.txt as a Proposed Standard This document has been reviewed in the IETF but is not the product of an IETF Working Group. The IESG contact person is Russ Housley. A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-songlee-aes-cmac-prf-128-03.txt Technical Summary Some implementations of IP Security (IPsec) may want to use a pseudo- random function (PRF) derived from the Advanced Encryption Standard (AES). This document describes such an algorithm, called AES-CMAC- PRF-128. Working Group Summary This document is an individual submission. It is not affiliated with any IETF Working Group. Protocol Quality AES-CMAC-PRF-128 is one of several choices for the IPsec PRF that can Be negotiated using IKEv1 or IKEv2. We believe that AES-CMAC has been implemented by at least INTEL, Runcom and SAMSUNG, and we believe that other vendors are developing AES-CMAC for their IEEE 802.16e products. This document was reviewed by Russ Housley for the IESG. ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce
Document Action: 'A Roadmap for TCP Specification Documents' to Informational RFC
The IESG has approved the following document: - 'A Roadmap for TCP Specification Documents ' draft-ietf-tcpm-tcp-roadmap-06.txt as an Informational RFC This document is the product of the TCP Maintenance and Minor Extensions Working Group. The IESG contact persons are Jon Peterson and Allison Mankin. A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-tcpm-tcp-roadmap-06.txt Technical Summary This document contains a roadmap to the RFCs relating to the Internet's TCP. This roadmap provides a brief summary of the documents defining TCP and various TCP extensions that have accumulated in the RFC series. This serves as a guide and quick reference for both TCP implementers and other parties who desire information contained in the TCP-related RFCs. Working Group Summary The advancement of this document is supported by the TCPM WG. Protocol Quality This protocol was reviewed for the IESG by Mark Allman and Jon Peterson Note to RFC Editor OLD: (from section 3.1) Since TCP traditionally (in the absence of ECN) uses losses to infer congestion, there is a rather intimate coupling between congestion control and loss recovery mechanisms. NEW: TCP traditionally treats lost packets as indicating congestion-related loss, and cannot distinguish between congestion-related loss and loss due to transmission errors. Even when ECN is in use, there is a rather intimate coupling between congestion control and loss recovery mechanisms. === OLD: (from section 3.3) A draft that is currently in the RFC Editor's queue for publication [tcpmd5app] deprecates TCP MD5 for use outside BGP. NEW: RFC 4278 deprecates the use of TCP MD5 outside BGP [RFC4278]. Please change [tcpmd5app] to reference RFC 4278. === OLD: (from section 6.4) RFC 2452 S: IP Version 6 Management Information Base for the Transmission Control Protocol (December 1998) This document [RFC2452] augments RFC 2012 by adding an IPv6- specific connection table. The rest of 2012 holds for any IP version. NEW: RFC 2452 S: IP Version 6 Management Information Base for the Transmission Control Protocol (December 1998) This document [RFC2452] augments RFC 2012 by adding an IPv6- specific connection table. The rest of 2012 holds for any IP version. RFC 2012 is now obsoleted by RFC 4022. ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce
Last Call: 'TLS User Mapping Extension' to Proposed Standard
The IESG has received a request from an individual submitter to consider the following documents: - 'TLS User Mapping Extension' draft-santesson-tls-ume-04.txt as a Proposed Standard - 'TLS Handshake Message for Supplemental Data' draft-santesson-tls-supp-00.txt as a Proposed Standard The previous Last Call on draft-santesson-tls-ume-03.txt has finished. However, to resolve some comments that were received during the previous Last Call, the document has been updated and draft-santesson-tls-supp-00.txt was written. Due to the significant changes in one area of the document, the IESG is making a second call for comments. This comment period is shorter since the majority of the document is unchanged. 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-04-11. The file can be obtained via http://www.ietf.org/internet-drafts/draft-santesson-tls-ume-04.txt http://www.ietf.org/internet-drafts/draft-santesson-tls-supp-00.txt ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce
Last Call: 'Improving the Robustness of TCP to Non-Congestion Events' to Experimental RFC
The IESG has received a request from the TCP Maintenance and Minor Extensions WG to consider the following document: - 'Improving the Robustness of TCP to Non-Congestion Events ' draft-ietf-tcpm-tcp-dcr-07.txt as an Experimental RFC draft-ietf-tcpm-tcp-dcr-07.txt has been submitted for consideration as an Experimental RFC to enable implementation of and experimentation with the TCP-NCR extensions in limited scenarios, in order to determine their suitability for wider-scale deployment. TCP-NCR should not currently be deployed on a large scale in the Internet. 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-04-14. The file can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-tcpm-tcp-dcr-07.txt ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce
Last Call: 'The Base16, Base32, and Base64 Data Encodings' to Proposed Standard
The IESG has received a request from an individual submitter to consider the following document: - 'The Base16, Base32, and Base64 Data Encodings ' draft-josefsson-rfc3548bis-02.txt as a Proposed Standard 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-05-01. The file can be obtained via http://www.ietf.org/internet-drafts/draft-josefsson-rfc3548bis-02.txt ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce
Document Action: 'Media Type Registrations for Downloadable Sounds for MIDI' to Informational RFC
The IESG has approved the following document: - 'Media Type Registrations for Downloadable Sounds for MIDI ' draft-westerlund-mime-dls-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-westerlund-mime-dls-01.txt Technical Summary The present document seeks to register a media type for Downloadable Sounds (DLS). The DLS format is used to define instruments for widely used wavetable synthesizers. The media type defined here is needed to correctly identify DLS files when they are served over HTTP, included in multi-part documents, or used in other places where media types are used. Working Group Summary This is an individual submission. It was reviewed by the IETF types list and changes were made in response to the feedback received. Protocol Quality The document was reviewed for the IESG by Ted Hardie. The underlying standards for DLS standards are maintained and defined by two organizations, the MIDI Manufacturers Association (MMA) and the Association of the Musical Electronics Industry (AMEI). Note to RFC Editor Section 2, third paragraph:: OLD: For DLS content containing conditional chunks it is stressed that the chunk in question is optional, that is to say a parser does not have to execute the chunk. NEW: A key point is that conditional chunks are optional, that is to say a parser does not have to execute a conditional chunk. Section 3.1: OLD: Security considerations: see the security considerations in section 3 of RFC . NEW: Security considerations: see the security considerations in section 2 of RFC . OLD: Interoperability considerations: This media type is for the consumption by a MIDI player NEW: Interoperability considerations: This media type is for consumption by a MIDI player Section 4: OLD: The references to RFC in the media type registration need to be replaced with the actual RFC number when it is issued. NEW: The references to RFC in the media type registration need to be replaced with the actual RFC number this document receives when it is issued. ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce
Document Action: 'Multicast Source Discovery protocol MIB' to Experimental RFC
The IESG has approved the following document:
- 'Multicast Source Discovery protocol MIB '
draft-ietf-mboned-msdp-mib-01.txt as an Experimental RFC
This document is the product of the MBONE Deployment Working Group.
The IESG contact persons are Dan Romascanu and David Kessens.
A URL of this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-mboned-msdp-mib-01.txt
Technical Summary
This memo defines an experimental portion of the Management Information
Base (MIB) for use with network management protocols in the Internet
community. In particular, it describes managed objects used for
managing Multicast Source Discovery Protocol (MSDP) (RFC 3618) speakers.
Working Group Summary
The WG has consensus to publish this document as an Experimental RFC.
There are existing implementations of this MIB module, which date back
several years, and so usage of IpAddress SYNTAX and DisplayString
in this (experimental) MIB module is a conscious decision and acceptable
at experimental level. The implementations are specific for IPv4 and so
is the MIB module.
Protocol Quality
Quick check with MIB doctors list for this experiment was done.
Bert Wijnen reviewed this document for the IESG.
Note to RFC Editor
- page 6, Section 3:
OLD:
the Source-Active Cache Table, containing the SA cache entries; and
NEW:
the Source-Active (SA) Cache Table, containing the SA cache entries; and
- bottom of page 6, change module name:
OLD:
DRAFT-MSDP-MIB DEFINITIONS ::= BEGIN
NEW:
MSDP-MIB DEFINITIONS ::= BEGIN
- on page 8, in the DESCRIPTION clause of msdpCacheLifetime
OLD:
This object does not measure time per se; instead, it is the
delta from the time at which an SA message is received at
which it should be expired if not refreshed. (i.e., it is
the value of msdpSACacheExpiryTime immediately after
receiving an SA message applying to that row.) As such,
TimeInterval would be a more appropriate SYNTAX; it remains
TimeTicks for backwards compatability.
NEW:
This object does not measure time per se; instead, it is the
delta from the time at which an SA message is received at
which it should be expired if not refreshed. (i.e., it is
the value of msdpSACacheExpiryTime immediately after
receiving an SA message applying to that row.) As such,
TimeInterval would be a more appropriate SYNTAX; it remains
TimeTicks for backwards compatibility.
- on page 9, DESCRIPTION clause of msdpRPAddress
OLD:
The RP address used when sourcing MSDP SA messages. May be
0.0.0.0 on non-RP's.
NEW:
The Rendezvous Point (RP) address used when sourcing MSDP SA
messages. May be 0.0.0.0 on non-RP's.
- On page 10 at the bootom, replace:
OLD:
msdpRequestsStatus OBJECT-TYPE
SYNTAX RowStatus
MAX-ACCESS read-create
NEW:
msdpRequestsStatus OBJECT-TYPE
SYNTAX RowStatus { active(1), destroy(6) }
MAX-ACCESS read-create
- on page 32 at the top, replace:
OLD:
SNMPv1 by itself is not a secure environment. Even if the network
itself is secure (for example by using IPSec), even then, there is no
control as to who on the secure network is allowed to access and GET/SET
(read/change/create/delete) the objects in this MIB.
NEW:
SNMPv1 by itself is not a secure environment. Even if the network
itself is secure (for example by using IPsec), even then, there is no
control as to who on the secure network is allowed to access and GET/SET
(read/change/create/delete) the objects in this MIB.
IANA Note
Since this MIB is for an experimental protocol, it uses an experimental
OID.
Decimal Name Description References
--- --- --
92 MSDP-MIB Multicast Source Discovery MIB [Fenner]
The IANA is requested to change the Reference for this entry to point to
this document.
___
IETF-Announce mailing list
IETF-Announce@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf-announce
Last Call: 'The Tao of IETF - A Novice's Guide to the Internet Engineering Task Force' to Informational RFC
The IESG has received a request from an individual submitter to consider the following document: - 'The Tao of IETF - A Novice's Guide to the Internet Engineering Task Force ' draft-hoffman-taobis-06.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-05-02. The file can be obtained via http://www.ietf.org/internet-drafts/draft-hoffman-taobis-06.txt ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce
Protocol Action: 'The Use of Galois Message Authentication Code (GMAC) in IPsec ESP and AH' to Proposed Standard
The IESG has approved the following document: - 'The Use of Galois Message Authentication Code (GMAC) in IPsec ESP and AH ' draft-mcgrew-aes-gmac-esp-02.txt as a Proposed Standard This document has been reviewed in the IETF but is not the product of an IETF Working Group. The IESG contact person is Russ Housley. A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-mcgrew-aes-gmac-esp-02.txt Technical Summary AES-GMAC-ESP provides an ESP data origin authentication mechanism that is amenable to high speed implementation. Unlike all other ESP authentication mechanisms, it can be parallelized and can avoid pipeline stalls. It is designed so that the incremental cost of implementing it, given an implementation is AES-GCM-ESP (RFC4106), is small. Working Group Summary This draft is not the product of any working group; however, it has been reviewed by the Fibre Channel Security Protocols group in T11, which is considering its adoption. Protocol Quality There is a software prototype implementation of the specification. The document was brought to the attention of the CFRG, which raised no concerns. The document was brought to the attention of the IPsec mail list, which raised no concerns. This document was reviewed by Russ Housley for the IESG. Note to RFC Editor Please delete section 1.1 prior to publication. Please add the following paragraph at the end of Section 3.3 (after figure 3): The use of 32-bit sequence numbers vs. 64-bit extended sequence numbers is determined by the security association (SA) management protocol that is used to create the SA. For IKEv2 [RFC4306] this is negotiated via Transform Type 5, and the default for ESP is to use 64-bit extended sequence numbers in the absence of negotiation (e.g., see Section 2.2.1 of [RFC4303]). ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce
Last Call: 'IKE and IKEv2 Authentication Using ECDSA' to Proposed Standard
The IESG has received a request from an individual submitter to consider the following document: - 'IKE and IKEv2 Authentication Using ECDSA' draft-ietf-ipsec-ike-auth-ecdsa-05.txt as a Proposed Standard 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-05-03. The file can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-ipsec-ike-auth-ecdsa-05.txt Also, this IPR disclosure may be of inerest https://datatracker.ietf.org/public/ipr_detail_show.cgi?ipr_id=695 ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce
Last Call: 'DDP/RDMAP Security' to Proposed Standard
The IESG has received a request from the Remote Direct Data Placement WG to consider the following documents: - 'DDP/RDMAP Security ' draft-ietf-rddp-security-08.txt as a Proposed Standard - 'Applicability of Remote Direct Memory Access Protocol (RDMA) and Direct Data Placement (DDP) ' draft-ietf-rddp-applicability-05.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-04-19. The file can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-rddp-security-08.txt http://www.ietf.org/internet-drafts/draft-ietf-rddp-applicability-05.txt ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce
Last Call: 'IPsec Security Policy Database Configuration MIB' to Proposed Standard
The IESG has received a request from the IP Security Policy WG to consider the following document: - 'IPsec Security Policy Database Configuration MIB ' draft-ietf-ipsp-spd-mib-05.txt as a Proposed Standard 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-04-20. The file can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-ipsp-spd-mib-05.txt ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce
Last Call: 'Number Portability Parameters for the tel URI' to Proposed Standard
The IESG has received a request from the IP Telephony WG to consider the following document: - 'Number Portability Parameters for the tel URI ' draft-ietf-iptel-tel-np-09.txt as a Proposed Standard 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-04-22. The file can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-iptel-tel-np-09.txt ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce
Protocol Action: 'Constrained VPN Route Distribution' to Proposed Standard
The IESG has approved the following document: - 'Constrained VPN Route Distribution ' draft-ietf-l3vpn-rt-constrain-02.txt as a Proposed Standard This document is the product of the Layer 3 Virtual Private Networks Working Group. The IESG contact persons are Mark Townsley and Margaret Wasserman. A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-l3vpn-rt-constrain-02.txt Technical Summary This document addresses scaling issues for VPN routing information maintained atroute reflectors. It extends the RFC2547bis approach using âCooperative Route Filteringâ between router reflectors for support multiple autonomous systems and asymmetric VPN topologies such as hub-and-spoke. The solution uses MP-BGP UPDATE messages to propagate Route Target membership information. Received RouteTarget membership information can then be used to restrict advertisement ofVPN NLRI to peers that have advertised their respective Route Targets, effectively building a route distribution graph. In this model, VPN NLRI routing informationflows in the inverse direction of Route Target membership information. This mechanism is applicable to any BGP NLRI that controls the distribution of routing information based on Route Targets, such as BGP L2VPNs [L2VPN] and VPLS [VPLS]. Working Group Summary There were several detailed issued which were raised when the document was submitted to the WG. Constructive comments led to modifications to the document which addressed the concerns that were raised. Protocol Quality In addition to L3VPN review, this document was reviewed by the IDR WG where it received review comments from Rick Wilder, Chandrashekhar Appanna, and Jeff Haas. Multiple implementations exist. Note to RFC Editor The upper left hand corner of the title page should include: Updates: draft-ietf-l3vpn-rfc2547bis-03 In section 2, please replace proposal with document in the following text: This proposal extends the RFC2547bis [3] ORF work to include support for multiple autonomous systems, and asymmetric VPN topologies such as hub-and-spoke. Also in section 2, please remove the [?] reference, new text is: This mechanism is applicable to any BGP NLRI that controls the distribution of routing information based on Route Targets such as VPLS [9]. Please change the title to: Constrained Route Distribution for BGP/MPLS IP VPNs Please replace the Abstract with: This document defines Multi-Protocol BGP (MP-BGP) procedures that allow BGP speakers to exchange Route Target reachability information. This information can be used to build a route distribution graph in order to limit the propagation of Virtual Private Network (VPN) Network Layer Reachability Information (NLRI) between different autonomous systems or distinct clusters of the same autonomous system. This document updates draft-ietf-l3vpn-rfc2547bis-03. [RFC Editor: please replace this Internet-Draft reference with an RFC number when it is assigned.] Please add a Terminology Section with the following acronyms expanded and defined and the informational reference to RFC4026: This document uses a number of terms and acronyms specific to Provider-Provisioned VPNs, including those specific to L2VPNs, L3VPNs and BGP. Definitions for many of these terms may be found in the VPN terminology document [RFC4026]. This section also includes some brief acronym expansion and terminology to aid the reader. AFI - Address Family Identifier (a BGP address type) BGP - Border Gateway Protocol BGP/MPLS VPN - A Layer 3 VPN implementation based upon BGP and MPLS. CE - Customer Edge (router) iBGP - Internal BGP; i.e., a BGP peering session that connects two routers within an autonomous system L2VPN - Layer 2 Virtual Private Network L3VPN - Layer 3 Virtual Private Network MP-BGP - Multi-Protocol Border Gateway Protocol MPLS - Multi-Protocol Label Switching NLRI - Network Layer Reachability Information ORF - Outbound Route Filtering PE - Provider Edge (router) RT - Route Target (i.e., a BGP extended community that conditions network layer reachability information with VPN membership) SAFI - Subsequence Address Family Identifier (a BGP address sub-type) VPLS - Virtual Private LAN Service VPN - Virtual Private Network Editor: Please include an informational reference to RFC 4026 in the referencessection. Please change the following text in section 6 From: A BGP speaker should generate the minimum set of BGP VPN route updates necessary to transition between the previous and current state of the route distribution graph that is derived from Route Target membership information. To: A BGP speaker should generate the minimum set of BGP VPN route updates (advertisements and/or withdrawls) necessary to transition between the previous and current state of the route distribution graph that is derived from Route Target membership information
Protocol Action: 'BGP-MPLS IP VPN extension for IPv6 VPN' to Proposed Standard
The IESG has approved the following document: - 'BGP-MPLS IP VPN extension for IPv6 VPN ' draft-ietf-l3vpn-bgp-ipv6-07.txt as a Proposed Standard This document is the product of the Layer 3 Virtual Private Networks Working Group. The IESG contact persons are Mark Townsley and Jari Arkko. A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-l3vpn-bgp-ipv6-07.txt Technical Summary This document describes a method by which a Service Provider may use its packet switched backbone to provide Virtual Private Network services for its IPv6 customers. This method reuses, and extends where necessary, the BGP/MPLS IP VPN method [2547bis] for support of IPv6. In particular, this method uses the same peer model as [2547bis], in which the customers' edge routers (CE routers) send their IPv6 routes to the Service Provider's edge routers (PE routers). BGP (Border Gateway Protocol, [BGP, BGP-MP]) is then used by the Service Provider to exchange the routes of a particular IPv6 VPN among the PE routers that are attached to that IPv6 VPN. Eventually, the PE routers distribute, to the CE routers in a particular VPN, the IPv6 routes from other CE routers in that VPN. As with IPv4 VPNs, a key characteristic of this peer model is that the (IPv6) CE routers within an (IPv6) VPN do not peer with each other and there is no overlay visible to the (IPv6) VPN's routing algorithm. A VPN is said to be an IPv6 VPN, when each site of this VPN is IPv6 capable and is natively connected over an IPv6 interface or sub- interface to the SP backbone via a Provider Edge device (PE). A site may be both IPv4-capable and IPv6-capable. The logical interface on which packets arrive at the PE may determine the IP version. Alternatively the same logical interface may be used for both IPv4 and IPv6 in which case a per-packet lookup at the Version field of the IP packet header determines the IP version. This document only concerns itself with handling of the IPv6 packets. As such the inter-working between an IPv4 site and an IPv6 site is outside the scope of this document. In a similar manner to how IPv4 VPN routes are distributed in [2547bis], BGP and its extensions are used to distribute routes from an IPv6 VPN site to all the other PE routers connected to a site of the same IPv6 VPN. PEs use VPN Routing and Forwarding tables (VRFs) to separately maintain the reachability information and forwarding information of each IPv6 VPN. As it is done for IPv4 VPNs [2547bis], we allow each IPv6 VPN to have its own IPv6 address space, which means that a given address may denote different systems in different VPNs. This is achieved via a new address family, the VPN-IPv6 Address Family, in a fashion similar to the VPN-IPv4 address family defined in [2547bis] and which prepends a Route Distinguisher to the IP address. In addition to its operation over MPLS Label Switched Paths (LSPs), the IPv4 BGP/MPLS VPN solution has been extended to allow operation over other tunneling techniques including GRE tunnels, IP-in-IP tunnels [2547-GRE/IP], L2TPv3 tunnels [MPLS-in-L2TPv3] and IPsec- protected tunnels [2547-IPsec]. In a similar manner, this document allows support of an IPv6 VPN service over MPLS LSPs as well as over other tunneling techniques including GRE tunnels, IP-in-IP tunnels, L2TPv3 tunnels and IPsec-protected tunnels. This document allows support for an IPv6 VPN service over an IPv4 backbone as well as over an IPv6 backbone. The IPv6 VPN service supported is identical in both cases. Working Group Summary This document went smoothly through the WG process. Protocol Quality At least two vendors have developed to earlier versions of this draft. Jeffrey Haas and Pedro Marques both commented on the draft as it went through multiple revisions. RFC Editor Note: The document's references to draft-ietf-ipv6-unique-local-addr-09.txt need to be updated; one section refers to Section 10, which no longer exists. I believeit should refer to Section 4.7. Please search and replace on byte replacing it with octet throughout the document. Please remove the reference to [RFC2547bis] in the Abstract. There are citation inconsistencies, please work with the authors to clear theseup. See tracker for reference check tool output. Please add the following clarifying sentence at the end of Section 5: Recommendations and considerations for which of these supported address types should be used in a given IPv6 VPN environments are beyond the scope of this document ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce
Last Call: 'IKEv2 Clarifications and Implementation Guidelines' to Informational RFC (draft-eronen-ipsec-ikev2-clarifications)
The IESG has received a request from an individual submitter to consider the following document: - 'IKEv2 Clarifications and Implementation Guidelines' draft-eronen-ipsec-ikev2-clarifications-08.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-05-03. The file can be obtained via http://www.ietf.org/internet-drafts/draft-eronen-ipsec-ikev2-clarifications-08.t xt ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce
Last Call: 'SIEVE Email Filtering: IMAP flag Extension' to Proposed Standard (draft-ietf-sieve-imapflags)
The IESG has received a request from the Sieve Mail Filtering Language WG to consider the following document: - 'SIEVE Email Filtering: IMAP flag Extension' draft-ietf-sieve-imapflags-04.txt as a Proposed Standard 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-05-04. The file can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-sieve-imapflags-04.txt ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce
Last Call: 'Generalized Multi-Protocol Label Switching (GMPLS) Extensions for Synchronous Optical Network (SONET) and Synchronous Digital Hierarchy (SDH) Control' to Proposed Standard (draft-ietf-c
The IESG has received a request from the Common Control and Measurement Plane WG to consider the following document: - 'Generalized Multi-Protocol Label Switching (GMPLS) Extensions for Synchronous Optical Network (SONET) and Synchronous Digital Hierarchy (SDH) Control ' draft-ietf-ccamp-rfc3946bis-01.txt as a Proposed Standard 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-05-04. The file can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-ccamp-rfc3946bis-01.txt ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce
Last Call: 'Link Management Protocol (LMP) Management Information Base (MIB)' to Proposed Standard (draft-ietf-ccamp-rfc4327bis)
The IESG has received a request from the Common Control and Measurement Plane WG to consider the following document: - 'Link Management Protocol (LMP) Management Information Base (MIB) ' draft-ietf-ccamp-rfc4327bis-01.txt as a Proposed Standard 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-05-09. The file can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-ccamp-rfc4327bis-01.txt ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce
Last Call: 'Calendaring Extensions to WebDAV (CalDAV)' to Proposed Standard (draft-dusseault-caldav)
The IESG has received a request from an individual submitter to consider the following document: - 'Calendaring Extensions to WebDAV (CalDAV) ' draft-dusseault-caldav-12.txt as a Proposed Standard 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-05-24. The file can be obtained via http://www.ietf.org/internet-drafts/draft-dusseault-caldav-12.txt ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce
Document Action: 'Generic Threats to Routing Protocols' to Informational RFC
The IESG has approved the following document: - 'Generic Threats to Routing Protocols ' draft-ietf-rpsec-routing-threats-07.txt as an Informational RFC This document is the product of the Routing Protocol Security Requirements Working Group. The IESG contact persons are Bill Fenner and Ross Callon. A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-rpsec-routing-threats-07.txt Technical Summary Routing protocols are subject to attacks that can harm individual users or network operations as a whole. This document provides a description and a summary of generic threats that affect routing protocols in general. This work describes threats, including threat sources and capabilities, threat actions, and threat consequences as well as a breakdown of routing functions that might be separately attacked. Working Group Summary Version -06 was approved in May, 2004. When it was realized that version had some flaws, it was pulled from the RFC Editor's queue and updated. The updated version passed Working Group Last Call in February, 2005. Protocol Quality Alex Zinin reviewed this document for the initial approval. Bill Fenner reviewed the updated version. ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce
Document Action: 'A URN Namespace for the Latvian National Government Integration Project' to Informational RFC
The IESG has approved the following document:
- 'A URN Namespace for the Latvian National Government Integration Project '
draft-kornijenko-ivis-urn-00.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-kornijenko-ivis-urn-00.txt
Technical Summary
This document registers the IVIS URN namespace.
Working Group Summary
This document is not the product of a working group, but it was reviewed
by the urn-nid mailing list as required by RFC 3406.
Protocol Quality
This document was reviewed for the IESG by Ted Hardie
Note to RFC Editor
1)-
OLD:
Obsoletes: RFC 3383 02 February 2006
NEW:
Category: Formal 02 February 2006
2)-
OLD:
2.4 Declaration of structure:
The Namespace Specific String (NSS) of all URNs assigned by the
IVIS will have the following hierarchical structure:
NEW:
2.4 Declaration of structure:
The Namespace Specific String (NSS) of all URNs assigned by
the IVIS will have the following hierarchical structure
(syntax according to [RFC 2141]):
3)-
OLD:
ResID - suffix ::= upper | lower | number | other
{an ID generated by IVIS subsystem and that is unique within
this subsystem}
NEW:
ResID - suffix ::= 1*(upper | lower | number | other)
{an ID generated by IVIS subsystem and that is unique within
this subsystem}
4)-
OLD:
IVIS Org ID::= number{ subsystem ID from IVIS database}
NEW:
IVIS Org ID::= 1*number{ subsystem ID from IVIS database}
5)-
OLD:
A URN Namespace for the Latvian National Government Integration Project
NEW:
A Uniform Resource Name (URN) Formal Namespace
for the Latvian National Government Integration Project
6)-
NEW SECTION:
5. IANA Considerations
This document includes a URN NID registration for IVIS for entry in
the IANA registry of URN NIDs (see [RFC 2434] for more
information).
7)-
OLD:
IVIS requested.
NEW:
IVIS requested according to [RFC 3406].
8)-
OLD:
3. Example
The following examples are not guaranteed to be real. They are provided
for pedagogical reasons only:
URN:IVIS:11:DOC-METADATA
URN:IVIS:12:NDR1021365
NEW:
3. Example
The following examples are not to be real. They are provided
for pedagogical reasons only:
URN:IVIS:00:DOC-METADATA
URN:IVIS:00:NDR1021365
9)-
OLD:
2.11 Conformance with URN syntax:
IVIS schema URN fully conforms to RFC2141 syntax except that symbols '
un : were
excluded from other.
NEW:
2.11 Conformance with URN syntax:
IVIS schema URN fully conforms to [RFC 2141] syntax except that symbols '
and : were excluded from other.
10)-
OLD:
2.3 Declared registrant of the namespace:
Name: Jurijs Kornijenko
Title: software architect
Affiliation: Mag.sc.ing.
Address: Tallinas - 51, Riga, LV-1012
Phone: +371 7082635
Email: [EMAIL PROTECTED]
NEW:
2.3 Declared registrant of the namespace:
Organization: The Secretariat of the Special Assignments Minister
for Electronic Government Affairs
Name: Jurijs Kornijenko
Title: software architect
Address: Tallinas - 51, Riga, LV-1012
Phone: +371 7082635
Email: mailto:[EMAIL PROTECTED][EMAIL PROTECTED]
11)-
OLD:
8. Author's Addresses
Name:Jurijs Kornijenko
Address: Tallinas - 51, Riga, LV-1012
Phone: +371 7082635
Email:[EMAIL PROTECTED]
NEW:
8. Author's Addresses
Organization: The Secretariat of the Special Assignments Minister
for Electronic Government Affairs
Name: Jurijs Kornijenko
Title: software architect
Address: Tallinas - 51, Riga, LV-1012
Phone: +371 7082635
Email: [EMAIL PROTECTED]
12)-
OLD:
Acknowledgments
The authors acknowledge the thoughtful contributions of Jurijs
Kornijenko to this document.
NEW:
Acknowledgments
Since the specification described in this document is derived from
STD 66, RFC 3986 and RFC 3406, the acknowledgements in those documents
still apply. In addition, the authors wish to acknowledge
Leslie Daigle, Ted Hardie and Dinara Suleymanova for their
suggestions and review.
14)-
OLD:
7.1. Normative References
[1] Daigle, L., van Gulik, D., Iannella, R. and Falstrom P
Last Call: 'IPFIX Protocol Specification' to Proposed Standard (draft-ietf-ipfix-protocol)
The IESG has received a request from the IP Flow Information Export WG to consider the following document: - 'IPFIX Protocol Specification ' draft-ietf-ipfix-protocol-21.txt as a Proposed Standard 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-05-16. The file can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-ipfix-protocol-21.txt ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce
Last Call: 'Architecture for IP Flow Information Export' to Informational RFC (draft-ietf-ipfix-architecture)
The IESG has received a request from the IP Flow Information Export WG to consider the following document: - 'Architecture for IP Flow Information Export ' draft-ietf-ipfix-architecture-10.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-05-18. The file can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-ipfix-architecture-10.txt ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce
Last Call: draft-ietf-msec-mikey-rsa-r'An to Proposed Standard
The IESG has received a request from the Multicast Security WG to consider the following document: - 'An additional mode of key distribution in MIKEY: MIKEY-RSA-R' draft-ietf-msec-mikey-rsa-r-04.txt as a Proposed Standard The document specifies a new MIKEY mode. The main goal of the new mode is to address the one-to-many use case, where the transmitter does not know in advance the certificates of all receivers. None of the existing MIKEY modes covers this case. In the new mode, the recipient initiates the exchange. In response, a key comes from the transmitter of the protected data. The entire exchange takes one round trip. Replay protection is obtained via timestamps, as in other MIKEY modes. The mode can also support unicast, where the usability is roughly the same as existing DH modes. This new mode allows MIKEY the same flexibility and usability as other multicast key management protocols, enabling a single sender to manage keys for a dynamic large group of recipients. The document was discussed several times in MSEC WG meetings and on the MSEC WG mailing list. The authors have SIP, RTP, and MSEC expertise. Several people provided reviews, and at least two of them were comprehensive. There were no objections to publishing this document as a standards-track RFC. The protocol is specified in sufficient detail to allow independent implementations. There are no known implementations, but implementing MIKEY-RSA-R mode, given a MIKEY-RSA mode implementation is fairly straightforward. 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-05-19. The file can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-msec-mikey-rsa-r-04.txt ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce
Last Call: 'Transport Layer Security (TLS) Authorization Extensions' to Proposed Standard (draft-housley-tls-authz-extns)
The IESG has received a request from an individual submitter to consider the following document: - 'Transport Layer Security (TLS) Authorization Extensions ' draft-housley-tls-authz-extns-04.txt as a Proposed Standard 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-06-02. This document specifies authorization extensions to the Transport Layer Security (TLS) Handshake Protocol. Extensions carried in the client and server hello messages to confirm that both parties support the desired authorization data types. Then, if supported by both the client and the server, authorization information is exchanged in the supplemental data handshake message. The file can be obtained via http://www.ietf.org/internet-drafts/draft-housley-tls-authz-extns-04.txt ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce
Protocol Action: 'Packet Reordering Metric for IPPM' to Proposed Standard
The IESG has approved the following document: - 'Packet Reordering Metric for IPPM ' draft-ietf-ippm-reordering-13.txt as a Proposed Standard This document is the product of the IP Performance Metrics Working Group. The IESG contact persons are Lars Eggert and Magnus Westerlund. A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ippm-reordering-13.txt Technical Summary This memo defines metrics to evaluate if a network has maintained packet order on a packet-by-packet basis. It provides motivations for the new metrics and discusses the measurement issues, including the context information required for all metrics. The memo first defines a reordered singleton, and then uses it as the basis for sample metrics to quantify the extent of reordering in several useful dimensions for network characterization or receiver design. Additional metrics quantify the frequency of reordering and the distance between separate occurrences. It then defines a metric oriented toward assessing reordering effects on TCP. Working Group Summary The concepts behind the draft have been discussed since 2001, resulting in a number of individual submission drafts which were merged into this draft. This draft has been discussed for several years, it has been stable for about a year now. Reviews were done by a number of key people in the group. Protocol Quality PROTO shepherd: Henk Uijterwaal ([EMAIL PROTECTED]) Lars Eggert reviewed this spec for the IESG. The main comment during IETF LC was a completely revised IANA considerations section. Version -13 has addressed the concerns raised during the IESG review. Note to RFC Editor Need to replace RFC with the number this RFC receives upon publication. Section 2, first paragraph: replace reference to RFC2640 to RFC2460 OLD: Ordered arrival is a property found in packets that transit their path, where the packet sequence number increases with each new arrival and there are no backward steps. The Internet Protocol [RFC791] [RFC2640] has no mechanisms to assure either packet NEW: Ordered arrival is a property found in packets that transit their path, where the packet sequence number increases with each new arrival and there are no backward steps. The Internet Protocol [RFC791] [RFC2460] has no mechanisms to assure either packet ^^^ ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce
Protocol Action: 'Internationalized Resource Identifiers (IRIs) and Uniform Resource Identifiers (URIs) for the Extensible Messaging and Presence Protocol (XMPP)' to Proposed Standard
The IESG has approved the following document: - 'Internationalized Resource Identifiers (IRIs) and Uniform Resource Identifiers (URIs) for the Extensible Messaging and Presence Protocol (XMPP) ' draft-saintandre-xmpp-iri-04.txt as a Proposed Standard 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-saintandre-xmpp-iri-04.txt Technical Summary This document defines the use of Internationalized Resource Identifiers (IRIs) and Uniform Resource Identifiers (URIs) in identifying or interacting with entities that can communicate via the Extensible Messaging and Presence Protocol (XMPP). Working Group Summary This is an individual submission. It was discussed on the working group mailing list of the former XMPP working group and on the URI-review mailing list. Earlier versions of this document were also reviewed and discussed on the URI mailing list, and substantial revisions took place in response to feedback. Protocol Quality This draft was reviewed for the IESG by Ted Hardie. The original document shepherd for this document was Scott Hollenbeck. ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce
Protocol Action: 'TLS User Mapping Extension' to Proposed Standard
The IESG has approved the following documents: - 'TLS Handshake Message for Supplemental Data ' draft-santesson-tls-supp-02.txt as a Proposed Standard - 'TLS User Mapping Extension ' draft-santesson-tls-ume-07.txt as a Proposed Standard These documents have been reviewed in the IETF but are not the products of an IETF Working Group. The IESG contact person is Russ Housley. A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-santesson-tls-ume-07.txt Technical Summary The TLS User Mapping extension enables a client to send a name hint to a server during a TLS handshake, enabling the server to locate necessary authentication credentials, such as X.509 certificates, for the claimed user. This aims to solve two issues: 1) To enable use of legacy PKI implementations where existing certificates lack a name that unambiguously maps to the user account at the server. 2) Allow a user to use the same certificate to authenticate to multiple accounts, while still being able to specify which account the user intends to employ for a particular TLS session. In the case of allowing legacy PKI, the user mapping hint provide information that can be used by the server to retrieve any necessary data, including certificates, to authenticate the user. The proposed TLS protocol extensions allow additional user mapping hint types to be defined in the future. The basic hint type allows either a UPN (Universal Principal Name) or a DNS hint to be sent to the server. The UPN hint enables authentication to a Microsoft domain account using existing PKI deployments. Without this TLS protocol extension, the client certificate must contain a UPN name in the form of the Microsoft UPN otherName in the Subject Alternative Name extension. Working Group Summary This document is an individual submission. However, the draft was announced to the TLS WG, and it was presented at the TLS WG session during IETF 64 in Vancouver. Comments received from WG participants were addressed. After resolving these comments, no further objections were raised. Protocol Quality This TLS protocol extension is being implemented by Microsoft in Windows Vista. It is expected to be used by enterprise customers with PKI deployments. In fact, the development of this TLS protocol extension is a direct result of requirements raised from the user community. This document was reviewed by Russ Housley for the IESG. Note to RFC Editor Please update the end of the 3rd paragraph of Section 1 in draft-santesson-tls-ume: OLD: The TLS extension in combination with the defined hint type provide a significant improvement to this situation as it allows a single certificate to be mapped to one or more accounts of the user and does not require the certificate to contain a UPN. NEW: The TLS extension in combination with the defined hint type provide a significant improvement to this situation as it allows a single certificate to be mapped to one or more accounts of the user and does not require the certificate to contain a proprietary UPN. ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce
Last Call: 'Requirements for IETF Technical Publication Service' to Informational RFC (draft-mankin-pub-req)
The IESG has received a request from an individual submitter to consider the following document: - 'Requirements for IETF Technical Publication Service ' draft-mankin-pub-req-08.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-06-06. The file can be obtained via http://www.ietf.org/internet-drafts/draft-mankin-pub-req-08.txt ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce
Last Call: 'Sieve Email Filtering -- Subaddress Extension' to Proposed Standard (draft-ietf-sieve-rfc3598bis)
The IESG has received a request from the Sieve Mail Filtering Language WG to consider the following document: - 'Sieve Email Filtering -- Subaddress Extension ' draft-ietf-sieve-rfc3598bis-04.txt as a Proposed Standard 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-05-23. The file can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-sieve-rfc3598bis-04.txt ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce
Last Call: 'NAT Behavioral Requirements for Unicast UDP' to BCP (draft-ietf-behave-nat-udp)
The IESG has received a request from the Behavior Engineering for Hindrance Avoidance WG to consider the following document: - 'NAT Behavioral Requirements for Unicast UDP ' draft-ietf-behave-nat-udp-06.txt as a BCP 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-05-23. The file can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-behave-nat-udp-06.txt ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce
Last Call: 'ISDN subaddress encoding type for tel URI' to Informational RFC (draft-munakata-iptel-isub-type)
The IESG has received a request from an individual submitter to consider the following document: - 'ISDN subaddress encoding type for tel URI ' draft-munakata-iptel-isub-type-01.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-06-06. The file can be obtained via http://www.ietf.org/internet-drafts/draft-munakata-iptel-isub-type-01.txt ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce
Last Call: 'RTP Payload Format for E-AC-3 Audio' to Proposed Standard (draft-ietf-avt-rtp-eac3)
The IESG has received a request from the Audio/Video Transport WG to consider the following document: - 'RTP Payload Format for E-AC-3 Audio ' draft-ietf-avt-rtp-eac3-01.txt as a Proposed Standard 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-05-23. The file can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-avt-rtp-eac3-01.txt ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce
Last Call: 'TCP-Friendly Multicast Congestion Control (TFMCC): Protocol Specification' to Experimental RFC (draft-ietf-rmt-bb-tfmcc)
The IESG has received a request from the Reliable Multicast Transport WG to consider the following document: - 'TCP-Friendly Multicast Congestion Control (TFMCC): Protocol Specification ' draft-ietf-rmt-bb-tfmcc-07.txt as an Experimental 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-05-24. The file can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-rmt-bb-tfmcc-07.txt ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce
Document Action: 'Evaluation of existing Routing Protocols against ASON routing requirements' to Informational RFC
The IESG has approved the following document: - 'Evaluation of existing Routing Protocols against ASON routing requirements ' draft-ietf-ccamp-gmpls-ason-routing-eval-03.txt as an Informational RFC This document is the product of the Common Control and Measurement Plane Working Group. The IESG contact persons are Ross Callon and Bill Fenner. A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-ason-routing-eval-03.txt Technical Summary This is an informational document that could be thought of as serving a liaision function, since it discusses how IETF routing protocols (particularly OSPF and IS-IS) can support the ASON work that is being done in the ITU. Working Group Summary No dissent. Protocol Quality Ross Callon has reviewed this for the IESG. Also reviewed by Deborah Brungard at Ross's request. Document has a good set of authors across CCAMP, IGP WGs, ITU-T and OSPF. Also reviewed closely by ITU-T SG15 (with liaisons exchanged). ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce
Document Action: 'Design of the MOBIKE Protocol' to Informational RFC
The IESG has approved the following document: - 'Design of the MOBIKE Protocol ' draft-ietf-mobike-design-08.txt as an Informational RFC This document is the product of the IKEv2 Mobility and Multihoming Working Group. The IESG contact persons are Russ Housley and Sam Hartman. A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mobike-design-08.txt Technical Summary The MOBIKE WG considered many different protocols and protocol fragments before it chose the final protocol. This document lists the most interesting choices faced by the MOBIKE WG, with some justification for the choices that were made. Working Group Summary The MOBIKE WG had no objections to this document being published. Protocol Quality It is not a protocol; it is a discussion of design choices. This document was reviewed by Russ Housley for the IESG. ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce
Document Action: 'A URN Namespace for ASD Specification 1000D' to Informational RFC
The IESG has approved the following document: - 'A URN Namespace for ASD Specification 1000D ' draft-rushing-s1000d-urn-00.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-rushing-s1000d-urn-00.txt Technical Summary Specification 1000D (S1000D) is an international specification for the procurement and production of technical publications. The current issue of the specification has been jointly produced by the Aerospace and Defence Industries Association of Europe (ASD. Previously AECMA, European Association of Aerospace Industries) and the Aerospace Industries Association of America (AIA). This document describes a Uniform Resource Name (URN) namespace for naming persistent resources defined by ASD Specification 1000D. Working Group Summary This document is the work of an individual submitter. It was reviewed by the URN-NID list as required in RFC 3406. Protocol Quality This 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: 'Link Management Protocol (LMP) Management Information Base (MIB)' to Proposed Standard
The IESG has approved the following document: - 'Link Management Protocol (LMP) Management Information Base (MIB) ' draft-ietf-ccamp-rfc4327bis-01.txt as a Proposed Standard This document is the product of the Common Control and Measurement Plane Working Group. The IESG contact persons are Bill Fenner and Ross Callon. A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ccamp-rfc4327bis-01.txt Technical Summary This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects for modeling the Link Management Protocol (LMP). It updates RFC 4327 to correct incorrect numerical values for the values of the TruthValue TC. These numbers were all in text such as DESCRIPTIONs or examples; the MIB itself is unchanged from the one in RFC 4327. Working Group Summary The Working Group has consensus to publish this document as an RFC at Proposed Standard level. Protocol Quality This document was reviewed for the IESG by Bill Fenner. ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce
Document Action: 'ECP Groups For IKE and IKEv2' to Informational RFC
The IESG has approved the following document: - 'ECP Groups For IKE and IKEv2 ' draft-ietf-ipsec-ike-ecp-groups-02.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 Russ Housley. A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipsec-ike-ecp-groups-02.txt Technical Summary This document describes three new elliptic curve groups for use in the Internet Key Exchange (IKE) and Internet Key Exchange version 2 (IKEv2) protocols in addition to previously defined groups. Specifically, the new elliptic curve groups are based on modular arithmetic rather than binary arithmetic. These new elliptic groups are defined to align IKE and IKEv2 with other elliptic cure cryptography (ECC) implementations and standards, particularly NIST standards. In addition, the curves defined here can provide more efficient implementation than previously defined ECC groups. Working Group Summary This document is an individual submission, although it was very briefly discussed on the IPsec mail list. Protocol Quality This document was reviewed by Russ Housley for the IESG. ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce
Last Call: 'Atom Threading Extensions' to Proposed Standard (draft-snell-atompub-feed-thread)
The IESG has received a request from an individual submitter to consider the following document: - 'Atom Threading Extensions ' draft-snell-atompub-feed-thread-10.txt as a Proposed Standard 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-06-12. The file can be obtained via http://www.ietf.org/internet-drafts/draft-snell-atompub-feed-thread-10.txt ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce
Last Call: 'GigaBeam High-Speed Radio Link Encryption' to Informational RFC (draft-housley-gigabeam-radio-link-encrypt)
The IESG has received a request from an individual submitter to consider the following document: - 'GigaBeam High-Speed Radio Link Encryption ' draft-housley-gigabeam-radio-link-encrypt-00.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-06-12. This document has already received review on the ipsec mailing list, and the author expects to make changes to address this review: http://www1.ietf.org/mail-archive/web/ipsec/current/msg02065.html The file can be obtained via http://www.ietf.org/internet-drafts/draft-housley-gigabeam-radio-link-encrypt-00.txt ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce
Protocol Action: 'MIB for Fibre-Channel's Fabric Shortest Path First Protocol' to Proposed Standard
The IESG has approved the following document: - 'MIB for Fibre-Channel's Fabric Shortest Path First Protocol ' draft-ietf-imss-fc-fspf-mib-03.txt as a Proposed Standard This document is the product of the Internet and Management Support for Storage Working Group. The IESG contact persons are Dan Romascanu and David Kessens. A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-imss-fc-fspf-mib-03.txt Technical Summary This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects for information related to the Fibre Channel network's Fabric Shortest Path First (FSPF) routing protocol. Working Group Summary This document was reviewed in the IMSS WG and in Technical Committee T11 (the official Fibre Channel standards body). T11 voted to recommend a prior version of this document to the IETF. Protocol Quality The protocol has been reviewed for the imss WG by Keith McCloghrie and for the Operations and Management Area by Bert Wijnen. Note to RFC Editor The following modificatione need to be introduced by the RFC Editor: 1) [FC-FAM-MIB] became [RFC4439] 2) [FC-RTM-MIB] included in the list of Normative References is not referenced in the text. Please take it out 3) Section 3, create sub-section 3.1 Replace OLD: 3. Short Overview of Fibre Channel With NEW: 3. Short Overview of Fibre Channel 3.1 Introduction 4) Section 3, create sub-section 3.2 Replace OLD: FSPF has four major components: a) A Hello protocol, used to establish connectivity with a ... With NEW: 3.2 FSPF Protocol FSPF has four major components: a) A Hello protocol, used to establish connectivity with a ... 5) Section 3, create sub-section 3.3 Replace OLD: The latest standard for an interconnecting Fabric containing multiple Fabric Switch elements is [FC-SW-4] (which replaces the previous ... With NEW: 3.3 Virtual Fabrics The latest standard for an interconnecting Fabric containing multiple Fabric Switch elements is [FC-SW-4] (which replaces the previous ... 6) Append to Section 1 the following paragraph: NEW: The key words MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL in this document are to be interpreted as described in RFC 2119. 7) Add to Normative References the Following [RFC2119] Bradner, S., Key words for use in RFCs to Indicate Requirement Levels, BCP 14, RFC 2119, March 1997. IANA Note IANA is requested to make a MIB OID assignment for the T11-FC-FSPF- MIB module under the appropriate subtree. ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce
Protocol Action: 'Definitions of Managed Objects for Asymmetric Digital Subscriber Line 2 (ADSL2)' to Proposed Standard
The IESG has approved the following document: - 'Definitions of Managed Objects for Asymmetric Digital Subscriber Line 2 (ADSL2) ' draft-ietf-adslmib-adsl2-07.txt as a Proposed Standard This document is the product of the ADSL MIB Working Group. The IESG contact persons are Dan Romascanu and David Kessens. A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-adslmib-adsl2-05.txt Technical Summary This document defines a Management Information Base (MIB) module for use with network management protocols in the Internet community. In particular, it describes objects used for managing parameters of the Asymmetric Digital Subscriber Line family of interface types, especially including ADSL, ADSL2, and ADSL2+. Working Group Summary The WG process was smooth and quick. There were two minor controversies raised: 1. A desire to break out the textual conventions into a separate document. This was resolved by using Bert's solution to define the textual conventions within one document using a separate MIB with the understanding that if it becomes necessary to break them out into a separate document later, we will still have that option. All involved agreed to this. 2. A desire was voiced to expand and extend the document to cover VDSL2 (a closely related but critically different technology). It was agreed that if there was a desire to support VDSL2, the differences between the technologies were such that VDSL2 would require a different document. All involved agreed to this. Protocol Quality The document was reviewed for the IESG by Bert Wijnen. No information is available about implementations Note to RFC Editor The RFC Editror is kindly asked to make the following changes: 1. OLD: adsl2TCMIB MODULE-IDENTITY LAST-UPDATED 20060425Z - April 25, 2006 NEW: adsl2TCMIB MODULE-IDENTITY LAST-UPDATED 20060425Z -- April 25, 2006 OLD: adsl2MIB MODULE-IDENTITY LAST-UPDATED 20060425Z - April 25, 2006 NEW: adsl2MIB MODULE-IDENTITY LAST-UPDATED 20060425Z -- April 25, 2006 2. in the Overview Section: OLD: The MIB module is located in the MIB tree under MIB 2 transmission, as discussed in the MIB-2 Integration (RFC 2863 [RFC2863]) section of this document. NEW: The MIB module is located in the MIB tree under MIB 2 transmission, as discussed in the IANA Considerations section of this document. 3. In Section 2.9 OLD: The ability to generate the SNMP notifications coldStart/WarmStart (per [RFC3418]), which are per agent (e.g., per Digital Subscriber Line Access Multiplexer, or DSLAM, in such a device), and linkUp/ linkDown (per [RFC2863]), which are per interface (i.e., ADSL/ADSL2 or ADSL2+ line) is required. NEW: The ability to generate the SNMP notifications coldStart/WarmStart (per [RFC3418]), which are per agent (e.g., per Digital Subscriber Line Access Multiplexer, or DSLAM, in such a device), and linkUp/ linkDown (per [RFC2863]), which are per interface (i.e., ADSL/ADSL2 or ADSL2+ line) is REQUIRED. 4. in Section 4 OLD: A management application intended to manage ADSL links (e.g., G.992.1) with this MIB module MUST be modified to adapt itself to certain differences between RFC 2662 [RFC2662] and this MIB module, including the following aspects NEW: A management application intended to manage ADSL links (e.g., G.992.1) with this MIB module must be modified to adapt itself to certain differences between RFC 2662 [RFC2662] and this MIB module, including the following aspects IANA Note The ADSL2-LINE-MIB module requires the allocation of a single object identifierfor its MODULE-IDENTITY. The IANA should allocate this object identifier in the transmission subtree. The ADSL2-LINE-MIB module uses the ifType value for Asymmetric Digital Subscriber Loop Version 2, to distinguish between ADSL lines that are managed with the RFC2662 management model and ADSL/ADSL2 and ADSL2+ lines managed with the model defined in this document. The value 230 has already been allocated by IANA for this purpose. ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce
Protocol Action: 'Fibre-Channel Routing Information MIB' to Proposed Standard
The IESG has approved the following document: - 'Fibre-Channel Routing Information MIB ' draft-ietf-imss-fc-rtm-mib-04.txt as a Proposed Standard This document is the product of the Internet and Management Support for Storage Working Group. The IESG contact persons are Dan Romascanu and David Kessens. A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-imss-fc-rtm-mib-04.txt Technical Summary This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects for information related to routing within a Fibre Channel fabric which is independent of the usage of a particular routing protocol. Working Group Summary This document was reviewed in the IMSS WG and in Technical Committee T11 (the official Fibre Channel standards body). T11 voted to recommend a prior version of this document to the IETF. Protocol Quality The protocol has been reviewed for the imss WG by Keith McCloghrie and for the Operations and Management Area by Bert Wijnen. Note to RFC Editor Please make the following changes: 1) Append to Section 1 the following paragraph: NEW: The key words MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL in this document are to be interpreted as described in RFC 2119. 2) Add to Normative References the Following [RFC2119] Bradner, S., Key words for use in RFCs to Indicate Requirement Levels, BCP 14, RFC 2119, March 1997. 3) In Section 12: OLD: It is recommended that implementors consider the security features as provided by the SNMPv3 framework (see [RFC3410], section 8), including full support for the SNMPv3 cryptographic mechanisms (for authentication and privacy). Further, deployment of SNMP versions prior to SNMPv3 is NOT recommended. Instead, it is recommended to deploy SNMPv3 and to enable cryptographic security. NEW: It is RECOMMENDED that implementors consider the security features as provided by the SNMPv3 framework (see [RFC3410], section 8), including full support for the SNMPv3 cryptographic mechanisms (for authentication and privacy). Further, deployment of SNMP versions prior to SNMPv3 is NOT RECOMMENDED. Instead, it is RECOMMENDED to deploy SNMPv3 and to enable cryptographic security. 4) Section 3, create sub-section 3.1 Replace OLD: 3. Short Overview of Fibre Channel With NEW: 3. Short Overview of Fibre Channel 3.1 Introduction 5) Section 3, create sub-section 3.2 Replace OLD: The routing of frames within the Fabric is normally based on the standard routing protocol, called the Fabric Shortest Path First ... With NEW: 3.2 Routing Protocols The routing of frames within the Fabric is normally based on the standard routing protocol, called the Fabric Shortest Path First ... 6) Section 3, create sub-section 3.3 Replace OLD: The latest standard for an interconnecting Fabric containing multiple Fabric Switch elements is [FC-SW-4] (which replaces the previous ... With NEW: 3.3 Virtual Fabrics The latest standard for an interconnecting Fabric containing multiple Fabric Switch elements is [FC-SW-4] (which replaces the previous ... IANA Note IANA is requested to make an MIB OID assignment for the T11-FC-ROUTE- MIB module under mib-2 ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce
Last Call: 'A Process Experiment in Normative Reference Handling' to Experimental RFC (draft-klensin-norm-ref)
The IESG has received a request from an individual submitter to consider the following document: - 'A Process Experiment in Normative Reference Handling ' draft-klensin-norm-ref-01.txt as an Experimental RFC This is a proposed process experiment under RFC 3933. 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-06-14. The file can be obtained via http://www.ietf.org/internet-drafts/draft-klensin-norm-ref-01.txt ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce
Protocol Action: 'The Base16, Base32, and Base64 Data Encodings' to Proposed Standard
The IESG has approved the following document: - 'The Base16, Base32, and Base64 Data Encodings ' draft-josefsson-rfc3548bis-04.txt as a Proposed Standard 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-josefsson-rfc3548bis-04.txt Technical Summary This document describes the commonly used base 64, base 32, and base 16 encoding schemes. It also discusses the use of line-feeds in encoded data, use of padding in encoded data, use of non-alphabet characters in encoded data, and use of different encoding alphabets. It obsoletes the descriptions in RFC 3548. Working Group Summary This work is the product of an individual submitter. There were significant IETF Last Call comments, and the draft was updated to respond to them. 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
Last Call: 'IETF Process and Operations Documentss' to Experimental RFC (draft-alvestrand-ipod)
The IESG has received a request from an individual submitter to consider the following document: - 'IETF Process and Operations Documentss ' draft-alvestrand-ipod-01.txt as an Experimental RFC This is a proposed process experiment under RFC 3933. 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-06-15. The file can be obtained via http://www.ietf.org/internet-drafts/draft-alvestrand-ipod-01.txt ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce
Last Call: 'IANA Registration for an Enumservice Containing PSTN Signaling Information' to Proposed Standard (draft-ietf-enum-pstn)
The IESG has received a request from the Telephone Number Mapping WG to consider the following document: - 'IANA Registration for an Enumservice Containing PSTN Signaling Information ' draft-ietf-enum-pstn-04.txt as a Proposed Standard 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-06-01. The file can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-enum-pstn-04.txt ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce
Protocol Action: 'RTP Payload Format for ITU-T Rec. H.263 Video' to Proposed Standard
The IESG has approved the following document: - 'RTP Payload Format for ITU-T Rec. H.263 Video ' draft-ietf-avt-rfc2429-bis-09.txt as a Proposed Standard This document is the product of the Audio/Video Transport Working Group. The IESG contact persons are Cullen Jennings and Jon Peterson. A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-avt-rfc2429-bis-09.txt Technical Summary This document describes a scheme to packetize an H.263 video stream for transport using RTP. It also describes the syntax and semantics of the SDP parameters needed to support the H.263 video codec. The draft updates the RTP Payload Format in RFC 2429 and the media type registration in RFC 3555. This is cycling at Proposed Standard, rather than going to Draft, since there are some new optional media type parameters. Working Group Summary This was a straight forward revision of an existing protocol, bringing it up to date with current practice, and adding some optional parameters. There is no controversy surrounding the draft. Protocol Quality The protocol is widely implemented, hence the interest in revising and clarifying the payload format and media type registration. The payload format has been extensively reviewed by Magnus Westerlund; Martin Duerst provided comments during a media type review. PROTO review was done by Colin Perkins. The document had an ietf-types review on November 30 and no issues were raised. ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce
Protocol Action: 'Example media types for use in documentation' to Proposed Standard
The IESG has approved the following document: - 'Example media types for use in documentation ' draft-taylor-types-example-05.txt as a Proposed Standard This document has been reviewed in the IETF but is not the product of an IETF Working Group. The IESG contact person is Magnus Westerlund. A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-taylor-types-example-05.txt Technical Summary This document specifies a new top level media type example and the sub-type /example for all of the media top level types, i.e. application, audio, image, message, model, multipart, text, and video. These type are soley intended to be used in examples in other standards documents in cases when specific media types are not required. Working Group Summary This is not a product of a WG. Protocol Quality This responsible AD for this document was Magnus Westerlund. The document was reviewed by people on the [EMAIL PROTECTED] mailing list. Note to RFC Editor Section 1, 2nd paragraph: OLD: o the 'text/example', 'image/example', 'audio/example', 'video/ example', 'application/example', and 'multipart/example' media subtypes. NEW: o the 'application/example', 'audio/example', 'image/example', 'message/example', 'model/example', 'multipart/example', 'text/example', and 'video/example' media subtypes. ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce
Last Call: 'IANA Considerations for PPP over Ethernet (PPPoE)' to BCP (draft-arberg-pppoe-iana)
The IESG has received a request from an individual submitter to consider the following document: - 'IANA Considerations for PPP over Ethernet (PPPoE) ' draft-arberg-pppoe-iana-01.txt as a BCP 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-06-21. The file can be obtained via http://www.ietf.org/internet-drafts/draft-arberg-pppoe-iana-01.txt ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce
Last Call: 'SMTP Submission Service Extension for Future Message Release' to Proposed Standard (draft-vaudreuil-futuredelivery)
The IESG has received a request from an individual submitter to consider the following document: - 'SMTP Submission Service Extension for Future Message Release ' draft-vaudreuil-futuredelivery-03.txt as a Proposed Standard 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-06-22. The file can be obtained via http://www.ietf.org/internet-drafts/draft-vaudreuil-futuredelivery-03.txt ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce
Last Call: 'RADIUS Attributes for Virtual LAN and Priority Support' to Proposed Standard (draft-ietf-radext-vlan)
The IESG has received a request from the RADIUS EXTensions WG to consider the following document: - 'RADIUS Attributes for Virtual LAN and Priority Support ' draft-ietf-radext-vlan-05.txt as a Proposed Standard 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-06-09. The file can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-radext-vlan-05.txt ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce
Last Call: 'RADIUS Delegated-IPv6-Prefix Attribute' to Proposed Standard (draft-ietf-radext-delegated-prefix)
The IESG has received a request from the RADIUS EXTensions WG to consider the following document: - 'RADIUS Delegated-IPv6-Prefix Attribute ' draft-ietf-radext-delegated-prefix-01.txt as a Proposed Standard 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-06-09. The file can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-radext-delegated-prefix-01.txt ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce
Last Call: 'Considerations on the IPv6 Host density Metric' to Informational RFC (draft-huston-hd-metric)
The IESG has received a request from an individual submitter to consider the following document: - 'Considerations on the IPv6 Host density Metric ' draft-huston-hd-metric-02.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-06-23. The file can be obtained via http://www.ietf.org/internet-drafts/draft-huston-hd-metric-02.txt ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce
Protocol Action: 'Location Types Registry' to Proposed Standard
The IESG has approved the following document: - 'Location Types Registry ' draft-ietf-geopriv-location-types-registry-06.txt as a Proposed Standard This document is the product of the Geographic Location/Privacy Working Group. The IESG contact persons are Ted Hardie and Jon Peterson. A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-geopriv-location-types-registry-06.txt Technical Summary This document creates a registry for location type tokens. We anticipate that the network, through configuration or management protocols, tells a mobile device what kind of location it finds itself in. The device and associated software can then tailor its behavior to the environment. For example, this document defines the terms classroom, place-of-worship and theater. A considerate owner of a cell phone might program the device to switch from ringer to vibrate mode in such environments. Just knowing the geographic location, be it as civic (street address) or geospatial coordinates would generally not allow the device to make a similar decision. Working Group Summary This document represents the consensus of the GEOPRIV working group. There were significant comments during IETF Last Call on the internationalization and extensibility of this mechanism. This version clarifies that the registration is for tokens. Protocol Quality The registry specified by this document has been designed for use by many protocols, including the many GEOPRIV specifications and standards such as RPID. This specification incorporates work from the Global Justice XML work. The PROTO Shepherd for the document is Andy Newton; the specification was reviewed for the IESG by Ted Hardie. Note to RFC Editor OLD: Following the policies outline in RFC 2434 [2], new tokens are assigned after Expert Review by the IETF GEOPRIV working group or its designated successor. The same procedure applies to updates of tokens within the registry and to deleting tokens from the registry. There are no restrictions regarding the update of location-type values in the registry. NEW: Following the policies outline in RFC 2434 [2], new tokens are assigned after Expert Review. The Expert Reviewer will generally consult the IETF GeoPRIV working group mailing list or its designated successor. Updates or deletion of tokens from the registration follow the same procedures. There are not restrictions regarding the update of location-type values in the registry. ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce
Last Call: 'RTP Payload Format for H.263 using RFC2190 to Historic status' to Informational RFC (draft-ietf-avt-rfc2190-to-historic)
The IESG has received a request from the Audio/Video Transport WG to consider the following document: - 'RTP Payload Format for H.263 using RFC2190 to Historic status ' draft-ietf-avt-rfc2190-to-historic-06.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-06-23. The file can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-avt-rfc2190-to-historic-06.txt ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce
Last Call: 'The ENUM Dip Indicator parameter for the tel URI' to Proposed Standard (draft-ietf-iptel-tel-enumdi)
The IESG has received a request from the IP Telephony WG to consider the following document: - 'The ENUM Dip Indicator parameter for the tel URI ' draft-ietf-iptel-tel-enumdi-04.txt as a Proposed Standard 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-06-09. The file can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-iptel-tel-enumdi-04.txt ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce
Last Call: 'RADIUS Auth Server MIB (IPv6)' to Proposed Standard (draft-ietf-radext-rfc2619bis)
The IESG has received a request from the RADIUS EXTensions WG to consider the following document: - 'RADIUS Auth Server MIB (IPv6) ' draft-ietf-radext-rfc2619bis-03.txt as a Proposed Standard 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-06-12. The file can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-radext-rfc2619bis-03.txt ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce
Last Call: 'RADIUS Acct Client MIB (IPv6)' to Informational RFC (draft-ietf-radext-rfc2620bis)
The IESG has received a request from the RADIUS EXTensions WG to consider the following document: - 'RADIUS Acct Client MIB (IPv6) ' draft-ietf-radext-rfc2620bis-03.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-06-12. The file can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-radext-rfc2620bis-03.txt ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce
Last Call: 'Dynamic Authorization Client MIB' to Informational RFC (draft-ietf-radext-dynauth-client-mib)
The IESG has received a request from the RADIUS EXTensions WG to consider the following documents: - 'Dynamic Authorization Server MIB ' draft-ietf-radext-dynauth-server-mib-05.txt as an Informational RFC - 'Dynamic Authorization Client MIB ' draft-ietf-radext-dynauth-client-mib-05.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-06-12. The file can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-radext-dynauth-server-mib-05.txt http://www.ietf.org/internet-drafts/draft-ietf-radext-dynauth-client-mib-05.txt ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce
Last Call: 'RADIUS Auth Client MIB (IPv6)' to Proposed Standard (draft-ietf-radext-rfc2618bis)
The IESG has received a request from the RADIUS EXTensions WG to consider the following document: - 'RADIUS Auth Client MIB (IPv6) ' draft-ietf-radext-rfc2618bis-03.txt as a Proposed Standard 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-06-12. The file can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-radext-rfc2618bis-03.txt ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce
Last Call: 'Administration of the IANA Special Purpose Address Block' to Informational RFC (draft-huston-ipv6-iana-specials)
The IESG has received a request from an individual submitter to consider the following document: - 'Administration of the IANA Special Purpose Address Block ' draft-huston-ipv6-iana-specials-01.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-06-26. The file can be obtained via http://www.ietf.org/internet-drafts/draft-huston-ipv6-iana-specials-01.txt ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce
Protocol Action: 'Encapsulation Methods for Transport of PPP/HDLC Over MPLS Networks' to Proposed Standard
The IESG has approved the following document: - 'Encapsulation Methods for Transport of PPP/HDLC Over MPLS Networks ' draft-ietf-pwe3-hdlc-ppp-encap-mpls-09.txt as a Proposed Standard This document is the product of the Pseudo Wire Emulation Edge to Edge Working Group. The IESG contact persons are Mark Townsley and Jari Arkko. A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-pwe3-hdlc-ppp-encap-mpls-09.txt * Technical Summary This draft describes how a Point to Point Protocol (PPP), or High- Level Data Link Control (HDLC) Protocol Data Units over an MPLS network without terminating the PPP/HDLC protocol. This enables service providers to offer emulated HDLC, or PPP link services over existing MPLS networks. This document specifies the encapsulation of PPP/HDLC Packet Data Units (PDUs) within a PW. * Working Group Summary This work has been thoroughly analysed by the working group and there is consensus for the design. * Protocol Quality There are many implementations of this protocol, and it is in operational service. Note to RFC Editor OLD: It is also recommended that PPP devices MUST NOT negotiate PPP MRUs larger than that of the AC MTU. NEW: It is also RECOMMENDED that the PPP devices be configured to not negotiate PPP MRUs larger that of the AC MTU. ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce
Protocol Action: 'Classless Inter-Domain Routing (CIDR): The Internet Address Assignment and Aggregation Plan' to BCP
The IESG has approved the following document: - 'Classless Inter-Domain Routing (CIDR): The Internet Address Assignment and Aggregation Plan ' draft-ietf-grow-rfc1519bis-04.txt as a BCP This document is the product of the Global Routing Operations Working Group. The IESG contact persons are David Kessens and Dan Romascanu. A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-grow-rfc1519bis-04.txt Technical Summary This memo discusses the strategy for address assignment of the existing 32-bit IPv4 address space with a view toward conserving the address space and limiting the growth rate of global routing state. This document obsoletes the original CIDR spec [RFC1519], with changes made both to clarify the concepts it introduced and, after more than twelve years, to update the Internet community on the results of deploying the technology described. Working Group Summary This document is a product of the grow working group. Protocol Quality This document was reviewed by David Kessens for the IESG. Some IETF Last Call comments were received and the issues that were brought up were promptly addressed. ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce
Last Call: 'RADIUS Acct Server MIB (IPv6)' to Informational RFC (draft-ietf-radext-rfc2621bis)
The IESG has received a request from the RADIUS EXTensions WG to consider the following document: - 'RADIUS Acct Server MIB (IPv6) ' draft-ietf-radext-rfc2621bis-03.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-06-12. The file can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-radext-rfc2621bis-03.txt ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce
Document Action: 'Experimental Procedure for Long Term Suspensions from Mailing Lists' to Experimental RFC
The IESG has approved the following document: - 'Experimental Procedure for Long Term Suspensions from Mailing Lists ' draft-hartman-mailinglist-experiment-03.txt as an Experimental RFC This document has been reviewed in the IETF but is not the product of an IETF Working Group. It falls under RFC 3933 (BCP 93) and it will become an experimental IETF process document for a period of 18 months. The IESG contact person is Brian Carpenter. A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-hartman-mailinglist-experiment-03.txt Technical Summary Proposes additional options for mailing list suspensions. Working Group Summary Comments from the IETF community received during Last Call were integrated in the updated draft. Protocol Quality Reviewed by Brian Carpenter. Note to RFC Editor Please change the title of this document to: Experiment in Long Term Suspensions From IETF Mailing Lists In the following quoted text: director and IESG. However RFC 2418 only applies to working group mailing lists. Please change: only applies to applied only In the following reference: [IESGDISRUPT] IESG Statement on Disruptive Posting, February 2006. Please include the following URL: http://www.ietf.org/IESG/STATEMENTS/statement-disruptive-posting.txt ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce
Document Action: 'The Dynamic Source Routing Protocol for Mobile Ad Hoc Networks (DSR)' to Experimental RFC
The IESG has approved the following document: - 'The Dynamic Source Routing Protocol for Mobile Ad Hoc Networks (DSR) ' draft-ietf-manet-dsr-10.txt as an Experimental RFC This document is the product of the Mobile Ad-hoc Networks Working Group. The IESG contact persons are Bill Fenner and Ross Callon. A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-manet-dsr-10.txt Technical Summary The Dynamic Source Routing protocol (DSR) is a routing protocol designed specifically for use in multi-hop wireless ad hoc networks of mobile nodes. DSR allows the network to be completely self-organizing and self-configuring, without the need for any existing network infrastructure or administration. Working Group Summary The Working Group had consensus to publish the four existing protocols as Experimental, as the first step down the path towards DYMO. Protocol Quality Bill Fenner reviewed the specification for the IESG. Note to RFC Editor Please make the following two changes: OLD (title): The Dynamic Source Routing Protocol for Mobile Ad Hoc Networks (DSR) NEW: The Dynamic Source Routing Protocol for Mobile Ad Hoc Networks (DSR) for IPv4 OLD (near the end of section 1, change are to will be): This document specifies the operation of the DSR protocol for routing unicast IPv4 packets in multi-hop wireless ad hoc networks. Advanced, optional features, such as Quality of Service (QoS) support and efficient multicast routing, and operation of DSR with IPv6 [7], are covered in other documents. NEW: This document specifies the operation of the DSR protocol for routing unicast IPv4 packets in multi-hop wireless ad hoc networks. Advanced, optional features, such as Quality of Service (QoS) support and efficient multicast routing, and operation of DSR with IPv6 [7], will be covered in other documents. IANA Note Please reassign IP Protocol 48 to DSR. David Johnson (the main author of DSR) was able to confirm that this protocol number was originally assigned for a proposal for Mobile IP (Mobile Host Routing Protocol) that was never deployed. Under RFC 2780 section 4.3, this is the IESG Approval of this assignment. ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce
Last Call: 'Graceful Restart Mechanism for BGP' to Proposed Standard (draft-ietf-idr-restart)
The IESG has received a request from the Inter-Domain Routing WG to consider the following document: - 'Graceful Restart Mechanism for BGP ' draft-ietf-idr-restart-11.txt as a Proposed Standard 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-06-13. The file can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-idr-restart-11.txt ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce
Protocol Action: 'Diameter Session Initiation Protocol (SIP) Application' to Proposed Standard
The IESG has approved the following document: - 'Diameter Session Initiation Protocol (SIP) Application ' draft-ietf-aaa-diameter-sip-app-12.txt as a Proposed Standard This document is the product of the Authentication, Authorization and Accounting Working Group. The IESG contact persons are Dan Romascanu and David Kessens. A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-aaa-diameter-sip-app-12.txt Technical Summary This draft proposes Diameter application to allow SIP-based services to be used within a AAA deployment, for authentication of users and authorization of SIP resources usages. The document defines the overall framework for this as well as the Diameter AVPs and Command Codes to be used. Working Group Summary There have been 3 WGLC on the document. Effort was made to align this with the RADIUS Extension for Digest Authentication draft. There is strong WG consensus behind this document, and some WG members have indicated that they are implementing the draft. Protocol Quality This document was reviewed by the working group chairs as well as key Diameter and RADIUS experts. They feel that this document is ready. The document was also reviewed by the SIPPING WG, which produced RFC 3701 - Authentication, Authorization, and Accounting Requirements for the Session Initiation Protocol (SIP). Further, people participating from 3GPP have also reviewed this document. Additionally, this document has participated in the Early Copy-Edit experiment. This document was reviewed for the IESG by Bert Wijnen Note to RFC Editor For your info: revision 08 of this document was reviewed by the RFC-Editor (Alice) as part of the early-copy-editing experiment. ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce
Last Call: 'Operation of Anycast Services' to BCP (draft-ietf-grow-anycast)
The IESG has received a request from the Global Routing Operations WG to consider the following document: - 'Operation of Anycast Services ' draft-ietf-grow-anycast-03.txt as a BCP 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-06-16. The file can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-grow-anycast-03.txt ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce
Protocol Action: 'Provisioning, Autodiscovery, and Signaling in L2VPNs' to Proposed Standard
The IESG has approved the following document: - 'Provisioning, Autodiscovery, and Signaling in L2VPNs ' draft-ietf-l2vpn-signaling-08.txt as a Proposed Standard This document is the product of the Layer 2 Virtual Private Networks Working Group. The IESG contact persons are Mark Townsley and Jari Arkko. A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-l2vpn-signaling-08.txt Technical Summary There are a number of different kinds of Provider Provisioned Layer 2 VPNs (L2VPNs). The different kinds of L2VPN may have different provisioning models, i.e., different models for what information needs to be configured in what entities. Once configured, the provisioning information is distributed by a discovery process. When the discovery process is complete, a signaling protocol is automatically invoked. The signaling protocol sets up the mesh of Pseudowires (PWs) that form the (virtual) backbone of the L2VPN. Any PW signaling protocol needs to have a method which allows each PW endpoint to identify the other; thus a PW signaling protocol will have the notion of an endpoint identifier. The semantics of the endpoint identifiers which the signaling protocol uses for a particular type of L2VPN are determined by the provisioning model. This document specifies a number of L2VPN provisioning models, and further specifies the semantic structure of the endpoint identifiers required by each provisioning model. It discusses the way in which the endpoint identifiers are distributed by the discovery process, especially when the discovery process is based upon the Border Gateway Protocol (BGP). It then specifies how the endpoint identifiers are carried in the two signaling protocols that are used to set up PWs, the Label Distribution Protocol (LDP) and the Layer 2 Tunneling Protocol (L2TPv3). Working Group Summary After WG Last Call, Luca Martini had raised an issue with respect to whether or not there needed to be coordination of AII Types between the l2vpn-signaling draft and the emergent MS-PW work. Luca proposed a solution to this dilemma on the L2VPN WG list: http://www.ietf.org/mail-archive/web/l2vpn/current/msg01121.html A discussion ensued between Bruce, Luca, Chris Metz, Florin, Mustapha, Vach Shane to resolve it. In summary, we have all agreed that l2vpn-signaling is its own application and its use of Type-1 AII's is sufficient for it. In fact, procedures developed in l2vpn-signaling already account for PW routing/stitching signaling as it relates to D-VPLS, (with Type-1 AII's), but do not give one the granularity of routing that MS-PW is aiming for. Another key difference is that l2vpn-signaling is focused on auto-discovery mechanisms for groups of PW's (e.g.: L2VPN's), whereas MS-PW is focused on both routing and signaling invidual PW's (not groups of PW's). In fact, it's not clear that MS-PW will initially be designed to support routing+signaling of groups of PW's, (which is another thing that distinguishes it from l2vpn-signaling). Protocol Quality The protocol is being implemented by at least two vendors. RFC Editor Note: Please add a normative reference for RFC 2119 and a citation to it at the end of section 1. Please replace: 3.3.2.1. BGP-based auto-discovery A framework for BGP-based auto-discovery for a generic L2VPN service is described in [I-D.ietf-l3vpn-bgpvpn-auto], section 3.2. In this section we specify how BGP-based auto-discovery can be used to build VPWS instances. With: 3.3.2.1. BGP-based auto-discovery In this section we specify how BGP can be used to discover the information necessary to build VPWS instances. And replace: A framework for BGP-based auto-discovery for a generic L2VPN service is described in [I-D.ietf-l3vpn-bgpvpn-auto], section 3.2. In this section we specify how BGP-based auto-discovery can be used to build VPLS instances. With: In this section we specify how BGP can be used to discover the information necessary to build a VPLS instance. Also, please remove the bibliographic reference to [I-D.ietf-l3vpn-bgpvpn-auto] in its entirety. ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce
Last Call: 'Matching of Language Tags' to Proposed Standard (draft-ietf-ltru-matching)
The IESG has received a request from the Language Tag Registry Update WG to consider the following document: - 'Matching of Language Tags ' draft-ietf-ltru-matching-14.txt as a Proposed Standard 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-06-19. The file can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-ltru-matching-14.txt ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce
Last Call: 'Matching of Language Tags' to BCP (draft-ietf-ltru-matching)
Note: there was a previous last call request sent for a status of Proposed Standard; this document is, however, intended for BCP. The IESG has received a request from the Language Tag Registry Update WG to consider the following document: - 'Matching of Language Tags ' draft-ietf-ltru-matching-14.txt as a BCP 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-06-20. The file can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-ltru-matching-14.txt ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce
