Document Action: 'Policy, Authorization and Enforcement Requirements of OPES' to Informational RFC
The IESG has approved the following document: - 'Policy, Authorization and Enforcement Requirements of OPES ' draft-ietf-opes-authorization-03.txt as an Informational RFC This document is the product of the Open Pluggable Edge Services Working Group. The IESG contact persons are Ted Hardie and Scott Hollenbeck. ___ IETF-Announce mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf-announce
Protocol Action: 'Transmission of IPv6 Packets over Fibre Channel' to Proposed Standard
The IESG has approved the following document: - 'Transmission of IPv6 Packets over Fibre Channel ' draft-ietf-imss-ipv6-over-fibre-channel-02.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 Bert Wijnen and David Kessens. Technical Summary This document specifies the way of encapsulating IPv6 packets over Fibre Channel, and the method of forming IPv6 link-local addresses and statelessly autoconfigured addresses on Fibre Channel networks. Working Group Summary The initial WG Last Call resulted in a number (19) of Editorial comments and 2 Technical comments. The technical comments were as follows: - Use of a default large MTU size (65280 octets) for IPv6 over Fibre Channel, which far exceeds the message sizes typically used in the Internet. As a result, an explanation has been added with additional guidance. See section 5. - An inconsistency in the format of the Source/Target Link-layer Address option (used with Neighbor Discovery Protocol). This has been corrected in the 01 revision. - Further changes were made because of IESG review which resulted in revision 02. The working group has consensus to publish revision 02 of this document as a standards track RFC. Protocol Quality This document was reviewed for the IESG by Margaret Wasserman and Bert Wijnen. Additional/explicit review was also requested from the IPv6 Working Group. ___ IETF-Announce mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf-announce
Protocol Action: 'LDAP Cancel Operation' to Proposed Standard
The IESG has approved the following document: - 'LDAP Cancel Operation ' draft-zeilenga-ldap-cancel-11.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. Technical Summary The Lightweight Directory Access Protocol (LDAP) [RFC3377] provides an Abandon operation [RFC2251] which clients may use to cancel other operations. The Abandon operation does not have a response and calls for there to be no response of the abandoned operation. These semantics provide the client with no clear indication of the outcome of the Abandon operation. The LDAP Cancel operation should be used instead of the LDAP Abandon operation when the client needs an indication of the outcome. This operation may be used to cancel both interrogation and update operations. Working Group Summary This is an individual submission, but there are working group documents (e.g. the LDUP working group's LCUP specification) which depend on it. There were no issues raised during Last Call, and the IETF LDAP community seems to be in favor adopting this mechanism as a parallel mechanism to the DAP abandon operation. Protocol Quality This document was reviewed for the IESG by Ted Hardie. ___ IETF-Announce mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf-announce
Document Action: 'OPES Treatment of IAB Considerations' to Informational RFC
The IESG has approved the following document: - 'OPES Treatment of IAB Considerations ' draft-ietf-opes-iab-05.txt as an Informational RFC This document is the product of the Open Pluggable Edge Services Working Group. The IESG contact persons are Ted Hardie and Scott Hollenbeck. Technical Summary The Internet Architecture Board (IAB) documented nine architecture-level considerations for the Open Pluggable Edge Services (OPES) framework. This document describes how OPES addresses those considerations. Working Group Summary This document is a product of the OPES Working Group Protocol Quality Ned Freed reviewed the document for the IESG. ___ IETF-Announce mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf-announce
Protocol Action: 'S/MIME AES Requirement for SIP' to Proposed Standard
The IESG has approved the following document: - 'S/MIME AES Requirement for SIP ' draft-ietf-sip-smime-aes-01.txt as a Proposed Standard This document is the product of the Session Initiation Protocol Working Group. The IESG contact persons are Allison Mankin and Jon Peterson. Technical Summary RFC3261 currently specifies 3DES as the required minimum ciphersuite for implementations of S/MIME in SIP. This document updates the normative guidance of RFC3261 to require the Advanced Encryption Standard (AES) for S/MIME. Working Group Summary The Working Group supported this document. It was adopted immediately on its initial airing. It was gated by progress on S/MIME support. Protocol Quality General S/MIME implementation for SIP has been fairly slow to progress. Some prototype implementations have been tested at the SIP interoperability events, without testing their cryptography to date. The specification was reviewed for the IESG by Allison Mankin and Russ Housley. RFC Editor Notes OLD: S/MIME implementations MUST at a minimum support RSA as a digital signature algorithm, SHA1 as a digest algorithm, and AES as an encryption algorithm (as specified in [4]. For key wrap, S/MIME implementations MUST support the AES Key Wrap Algorithm ([5]). NEW: S/MIME implementations MUST at a minimum support RSA as a digital signature algorithm and SHA1 as a digest algorithm [ xx], and AES as an encryption algorithm (as specified in [yy]). For key transport, S/MIME implementations MUST support RSA key transport as specified in section 4.2.1 of [xx]. RFC Editor, replace [xx] with the citation number of a reference to RFC 3370 added to the Normative References. Replace [yy] with the citation number of a reference to RFC 3565 added to the Normative References. 3370 Cryptographic Message Syntax (CMS) Algorithms. R. Housley. August 2002. 3565 Use of the Advanced Encryption Standard (AES) Encryption Algorithm in Cryptographic Message Syntax (CMS). J. Schaad. July 2003. Abstract OLD: required minimum ciphersuite NEW: mandatory-to-implement ciphersuite Section 4 OLD: Triples-DES NEW: Triple-DES Several places: Adjust line breaks to avoid funny line break placement -- Avoid S/ CRLF MIME ___ IETF-Announce mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf-announce
Document Action: 'Payment API for v1.0 Internet Open Trading Protocol (IOTP)' to Informational RFC
The IESG has approved the following document: - 'Payment API for v1.0 Internet Open Trading Protocol (IOTP) ' draft-ietf-trade-iotp-v1.0-papi-06.txt as an Informational RFC This document is the product of the Internet Open Trading Protocol Working Group. The IESG contact persons are Scott Hollenbeck and Ted Hardie. Technical Summary The Internet Open Trading Protocol provides a data exchange format for trading purposes while integrating existing pure payment protocols seamlessly. This motivates the multiple layered system architecture which consists of at least some generic IOTP application core and multiple specific payment modules. This document addresses a common interface between the IOTP application core and the payment modules, enabling the interoperability between these kinds of modules. Furthermore, such an interface provides the foundations for a plug-in- mechanism in actual implementations of IOTP application cores. Such interfaces exist at the Consumers', the Merchants' and the Payment Handlers' installations connecting the IOTP application core and the payment software components/legacy systems. Working Group Summary This document is a product of the TRADE working group. Protocol Quality Ned Freed reviewed the protocol for the IESG. ___ IETF-Announce mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf-announce
Last Call: 'IRIS - The Internet Registry Information Service (IRIS) Core Protocol' to Proposed Standard
The IESG has received a request from the Cross Registry Information Service Protocol WG to consider the following document: - 'IRIS - The Internet Registry Information Service (IRIS) Core Protocol ' draft-ietf-crisp-iris-core-06.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 [EMAIL PROTECTED] or [EMAIL PROTECTED] mailing lists by 2004-05-07. The file can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-crisp-iris-core-06.txt ___ IETF-Announce mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf-announce
Last Call: 'Redemption Grace Period Mapping for the Extensible Provisioning Protocol' to Proposed Standard
The IESG has received a request from an individual submitter to consider the following document: - 'Redemption Grace Period Mapping for the Extensible Provisioning Protocol ' draft-hollenbeck-epp-rgp-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 [EMAIL PROTECTED] or [EMAIL PROTECTED] mailing lists by 2004-05-21. The file can be obtained via http://www.ietf.org/internet-drafts/draft-hollenbeck-epp-rgp-04.txt ___ IETF-Announce mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf-announce
Last Call: 'Application Aspects of IPv6 Transition' to Informational RFC
The IESG has received a request from the IPv6 Operations WG to consider the following document: - 'Application Aspects of IPv6 Transition ' draft-ietf-v6ops-application-transition-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. The IESG is interested in IETF wide review for this document since it covers other areas than just Operations Management. Please send any comments to the [EMAIL PROTECTED] or [EMAIL PROTECTED] mailing lists by 2004-05-24. The file can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-v6ops-application-transition-02.t xt ___ IETF-Announce mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf-announce
Last Call: 'IRIS - Using the Internet Registry Information Service (IRIS) over the Blocks Extensible Exchange Protocol (BEEP)' to Proposed Standard
The IESG has received a request from the Cross Registry Information Service Protocol WG to consider the following document: - 'IRIS - Using the Internet Registry Information Service (IRIS) over the Blocks Extensible Exchange Protocol (BEEP) ' draft-ietf-crisp-iris-beep-06.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 [EMAIL PROTECTED] or [EMAIL PROTECTED] mailing lists by 2004-05-12. The file can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-crisp-iris-beep-06.txt ___ IETF-Announce mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf-announce
Last Call: 'State Machines for Extensible Authentication Protocol (EAP) Peer and Authenticator' to Informational RFC
The IESG has received a request from the Extensible Authentication Protocol WG to consider the following document: - 'State Machines for Extensible Authentication Protocol (EAP) Peer and Authenticator ' draft-ietf-eap-statemachine-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 [EMAIL PROTECTED] or [EMAIL PROTECTED] mailing lists by 2004-05-13. The file can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-eap-statemachine-03.txt ___ IETF-Announce mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf-announce
Last Call: 'The IESG and RFC Editor documents: Procedures' to BCP
The IESG has received a request from the Internet Engineering Steering Group WG to consider the following document: - 'The IESG and RFC Editor documents: Procedures ' draft-iesg-rfced-documents-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 [EMAIL PROTECTED] or [EMAIL PROTECTED] mailing lists by 2004-05-18. The file can be obtained via http://www.ietf.org/internet-drafts/draft-iesg-rfced-documents-01.txt ___ IETF-Announce mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf-announce
WG Review: Atom Publishing Format and Protocol (atompub)
A new IETF working group has been proposed in the Applications Area. The IESG has not made any determination as yet. The following description was submitted, and is provided for informational purposes only. Please send your comments to the IESG mailing list ([EMAIL PROTECTED]) by May 12th. Atom Publishing Format and Protocol (atompub) = Current Status: Proposed Working Group Description of working group: Atom defines a feed format for representing and a protocol for editing Web resources such as Weblogs, online journals, Wikis, and similar content. The feed format enables syndication; that is, provision of a channel of information by representing multiple resources in a single document. The editing protocol enables agents to interact with resources by nominating a way of using existing Web standards in a pattern. Atom consists of: * A conceptual model of a resource * A concrete syntax for this model * A syndication and archiving format (the Atom feed format) using this syntax * An editing protocol using this syntax The format must be able to represent: * a resource that is a Weblog entry or article (e.g., it has an author, date, identifier, and content) * a feed or channel of entries, with or without enclosed content * a complete archive of all entries in a feed * existing well-formed XML (especially XHTML) content * additional information in an user-extensible manner The editing protocol must enable: * creating, editing, and deleting feed entries * multiple authors for a feed * multiple subjects or categories in a feed * user authentication * adding, editing, and deleting users * setting and getting user preferences * creating, getting and setting related resources such as comments, templates, etc. The working group will use experience gained with RSS (variably used as a name by itself and as an acronym for RDF Site Summary, Rich Site Summary, or Really Simple Syndication) as the basis for a standards-track document specifying the model, syntax, and feed format. The feed format and HTTP will be used as the basis of work on a standards-track document specifying the editing protocol. The goal for the working group is to produce a single feed format and a single editing protocol; the working group will only consider additional formats or additional protocols if those charter changes are approved by the IESG. The working group will also take steps to ensure interoperability, by: * unambiguously identifying required elements in formats * clearly nominating conformance levels for different types of software * providing clear extensibility mechanisms and constraints upon them The Atom protocol will be designed to provide security services for updating and accessing dynamic online resources. The working group will consider current known issues with requirements for remote access, along with the fact that many such resources are constrained by providers who provide the resource owners with little configuration control. The working group's primary focus will be on delivering an interoperable format and corresponding protocol; it is expected that all but the most basic, generic metadata and functions will be accommodated through extensions, rather than in the core documents. Extension development is not included in this charter. The working group will consider the need to either close or to modify the charter and document extensions once the core document set has been approved by the IESG. ___ IETF-Announce mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf-announce
Protocol Action: 'Definitions of Managed Objects for the DS3/E3 Interface Type' to Proposed Standard
The IESG has approved the following document: - 'Definitions of Managed Objects for the DS3/E3 Interface Type ' draft-ietf-atommib-rfc2496bis-06.txt as a Proposed Standard This document is the product of the AToM MIB Working Group. The IESG contact persons are Bert Wijnen and David Kessens. 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 objects used for managing DS3 and E3 interfaces. This document is a companion to the documents that define Managed Objects for the DS0, DS1/E1/DS2/E2 and Synchronous Optical Network/Synchronous Digital Hierarchy (SONET/SDH) Interface Types. This document entirely obsoletes RFC 2496. Working Group Summary There is WG consensus for this document to be published as Proposed Standard RFC. This document needs to stay at Proposed Standard for now because there are currently not enough implementation reports. Protocol Quality This document has been reviewed for the IESG by Mike Heard and Bert Wijnen ___ IETF-Announce mailing list [EMAIL PROTECTED] 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-06.txt as an Informational RFC This document is the product of the Routing Protocol Security Requirements Working Group. The IESG contact persons are Alex Zinin and Bill Fenner. ___ IETF-Announce mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf-announce
Protocol Action: 'MIME Type Registrations for 3GPP Multimedia files' to Proposed Standard
The IESG has approved the following document: - 'MIME Type Registrations for 3GPP Multimedia files ' draft-singer-avt-3gpp-mime-01.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 Allison Mankin. Technical Summary This document specifies the MIME types audio/3gpp and video/3gpp, which are file transport format containers for several types of audio and video data. The third-generation partnership project (3GPP) for third-generation cellular telephony has defined a standard file format to contain audio/visual sequences which may be downloaded to cellular phones [3GPP]. At the time of writing, the 3GPP file format (3GP) can contain H.263 or MPEG-4 video; and AMR Narrow-band or AMR wide-band speech, or AAC audio; and 3GPP timed text. Within the file, there is an intrinsic file-type box, which identifies those specifications to which the file complies, and which players (possibly compliant with only one specification) are permitted by the content author to play file. This identification is through four-letter 'brands', which are required to appear in the files identified by the MIME type defined here. The extension of the formats covered by these MIME types is by 3GPP standards, in a compatible brands lists. The MIME types defined here are needed correctly to identify such files when they are served over HTTP, included in multi-part documents, or used in other places where MIME types are used. Working Group Summary The specification is not an IETF document, but it was reviewed for its handling of multimedia issues by the AVT working group, and its advancement was supported there. A four week Last Call in the IETF resulted in no comments from the IETF. Protocol Quality The specification was reviewed for the IESG by Allison Mankin. A result of the review was to add notes of several risks of this format: The formats covered by audio/3gpp and video/3gpp are extensible, so that while currently none have active content, in future there may be risk from that vector. These file download formats do not have encryption or authentication methods available for them, so the end-user needs to be aware of risks to the content. Data integrity for the formats within the type would seem like a good idea given the clearly noted point about digital rights management usages for the formats within these MIME types: selected metadata fields containing information partly intended to protect the media against unauthorized use or distribution. In this case the intention is that alteration or removal of the data in the field would be treated as an offence under national agreements based World Intellection Property Organization (WIPO) treaties. The specification gives clear notification of each of these risks. RFC Editor Note: In Section 3 MIME Types, add the new text beginning with Ongoing indented underneath none. It is not possible to show the proper format due to the tools used for approval announcement in the tracker system. OLD Optional parameters: none NEW Optional parameters: none Ongoing work related to this registration may introduce new optional parameters. One example area of effort may introduce a parameter that would allow for codecs in use within the MIME type to be asserted and determined without examination of the file. Those with interests in the area should monitor registrations for updates. ___ IETF-Announce mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf-announce
Last Call: 'IPv6 Scoped Address Architecture' to Proposed Standard
The IESG has received a request from the IP Version 6 Working Group WG to consider the following document: - 'IPv6 Scoped Address Architecture ' draft-ietf-ipv6-scoping-arch-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 [EMAIL PROTECTED] or [EMAIL PROTECTED] mailing lists by 2004-06-07. The file can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-ipv6-scoping-arch-01.txt ___ IETF-Announce mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf-announce
Last Call: 'Registration of mail and MIME header fields' to Proposed Standard
The IESG has received a request from an individual submitter to consider the following document: - 'Registration of mail and MIME header fields ' draft-klyne-hdrreg-mail-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 [EMAIL PROTECTED] or [EMAIL PROTECTED] mailing lists by 2004-06-21. The file can be obtained via http://www.ietf.org/internet-drafts/draft-klyne-hdrreg-mail-05.txt ___ IETF-Announce mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf-announce
Last Call: 'Diameter Credit-control Application' to Proposed Standard
The IESG has received a request from the Authentication, Authorization and Accounting WG to consider the following document: - 'Diameter Credit-control Application ' draft-ietf-aaa-diameter-cc-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 [EMAIL PROTECTED] or [EMAIL PROTECTED] mailing lists by 2004-06-15. The file can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-aaa-diameter-cc-05.txt ___ IETF-Announce mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf-announce
Last Call: 'Distance Vector Multicast Routing Protocol' to Proposed Standard
The IESG has received a request from the Inter-Domain Multicast Routing WG to consider the following documents: - 'Distance Vector Multicast Routing Protocol ' draft-ietf-idmr-dvmrp-v3-11.txt as a Proposed Standard - 'Distance Vector Multicast Routing Protocol Applicability Statement ' draft-ietf-idmr-dvmrp-v3-as-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 [EMAIL PROTECTED] or [EMAIL PROTECTED] mailing lists by 2004-06-25. The file can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-idmr-dvmrp-v3-11.txt http://www.ietf.org/internet-drafts/draft-ietf-idmr-dvmrp-v3-as-01.txt ___ IETF-Announce mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf-announce
WG Action: RECHARTER: Extensible Authentication Protocol (eap)
The charter of the Extensible Authentication Protocol (eap) working group in the Internet Area of the IETF has been updated. For additional information, please contact the Area Directors or the working group Chairs. Extensible Authentication Protocol (eap) Current Status: Active Working Group Chair(s): Bernard Aboba [EMAIL PROTECTED] Jari Arkko [EMAIL PROTECTED] Internet Area Director(s): Thomas Narten [EMAIL PROTECTED] Margaret Wasserman [EMAIL PROTECTED] Internet Area Advisor: Margaret Wasserman [EMAIL PROTECTED] Technical Advisor(s): William Arbaugh [EMAIL PROTECTED] Mailing Lists: General Discussion: [EMAIL PROTECTED] To Subscribe: [EMAIL PROTECTED] In Body: subscribe in Subject line Archive: http://mail.frascone.com/pipermail/eap/ Description of Working Group: The EAP working group will restrict itself to the following work items in order to fully document and improve the interoperability of the existing EAP protocol: 1. IANA considerations for EAP. 2. Type space extension to support an expanded Type space. 3. EAP usage model. 4. Threat model and security requirements. 5. Documentation of interaction between EAP and other layers. 6. Resolution of interoperability issues. 7. EAP state machine. 8. EAP keying framework. 9. EAP network selection problem definition Items 1-6 were included within RFC 3748. Items 7-9 will be handled as separate documents. While the EAP WG is not currently chartered to standardize EAP methods, with the publication of RFC 3748, the EAP WG will assume responsibility for review of EAP methods requesting a Type code allocation, as specified in the IANA considerations section of RFC 3748. When the current work items are completed, the WG may be rechartered, or a new WG may be formed to standardize methods. Goals and Milestones: DoneRFC 3748 published DoneEAP state machine document submitted for publication as an Informational RFC Sep 04 EAP Keying Framework document submitted for publication as an Informational RFC Oct 04 EAP Network Selection Problem Definition document submitted as an Informational RFC ___ IETF-Announce mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf-announce
WG Action: RECHARTER: Protocol for carrying Authentication for Network Access (pana)
as an enforcement point (EP) to prevent unauthorized access or usage of the network. When a PaC succesfully authenticates itself to the PAA, EP(s) (e.g., access routers) will need to be suitably notified. SNMP will be used by the PAA to deliver the authorization information to one or more EPs when the PAA is separated from EPs. The WG will document the solution based on SNMP for carrying the authorization information between the PAA and the EP. The WG will also propose a solution of how the PaC discovers the IP address of PAA for sending the authentication request. The PANA WG will deliver - A mechanism for the PAC to discover the PAA on the link. - The PANA protocol itself, capable of carrying multiple authentication methods (e.g. using EAP) - A document that describes how SNMP is used to deliver authorization information from the PAA to the EP in the scenarios where the PAA and EP are separated. - A document that explains the establishment of an IPsec SA between the client and the 1st hop access router subsequent to authentication for securing the data packets on the link. Goals and Milestones: DoneSubmit usage scenarios and applicability statement to the IESG DoneSubmit security threat analysis to the IESG DoneSubmit protocol requirements to the IESG Aug 04Submit PANA framework to the IESG Aug 04Submit PANA protocol specification to the IESG Aug 04Submit IPsec-based access control to the IESG Aug 04Submit SNMP-based PAA-to-EP protocol specification to the IESG Dec 04Submit MIB for PANA to the IESG ___ IETF-Announce mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf-announce
Protocol Action: 'Cryptographic Message Syntax (CMS)' to Proposed Standard
The IESG has approved the following document: - 'Cryptographic Message Syntax (CMS) ' draft-ietf-smime-rfc3369bis-04.txt as a Proposed Standard This document is the product of the S/MIME Mail Security Working Group. The IESG contact persons are Steve Bellovin and Russ Housley. Technical Summary This document is a minor update from RFC 3369. It corrects some errors, and makes provision for easy addition of new certificate types. Working Group Summary The changes were uncontroversial. Protocol Quality Steve Bellovin reviewed this document for the IESG. ___ IETF-Announce mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf-announce
Protocol Action: 'Internet Voice Messaging' to Proposed Standard
The IESG has approved the following document: - 'Internet Voice Messaging ' draft-ietf-vpim-ivm-06.txt as a Proposed Standard This document is the product of the Voice Profile for Internet Mail Working Group. The IESG contact persons are Scott Hollenbeck and Ted Hardie. Technical Summary This document provides for the carriage of voicemail messages over Internet mail as part of a unified messaging infrastructure. The Internet Voice Messaging (IVM) concept described in this document is not a successor format to VPIM v2 (Voice Profile for Internet Mail Version 2), but rather an alternative specification for a different application. Working Group Summary There were no comments during the WG last call as all the issues and debates had been vetted in the WG. Additionally, there were no comments received during the IETF last call. Protocol Quality Scott Hollenbeck reviewed the spec for the IESG. ___ IETF-Announce mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf-announce
Last Call: 'Update to RFC 2418 Regarding the Management of IETF Mailing Lists' to BCP
The IESG has received a request from an individual submitter to consider the following document: - 'Update to RFC 2418 Regarding the Management of IETF Mailing Lists ' draft-wasserman-rfc2418-ml-update-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 [EMAIL PROTECTED] or [EMAIL PROTECTED] mailing lists by 2004-07-15. The file can be obtained via http://www.ietf.org/internet-drafts/draft-wasserman-rfc2418-ml-update-01.txt ___ IETF-Announce mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf-announce
Protocol Action: 'Finding FCIP Entities Using SLPv2' to Proposed Standard
The IESG has approved the following document: - 'Finding FCIP Entities Using SLPv2 ' draft-ietf-ips-fcip-slp-09.txt as a Proposed Standard This document is the product of the IP Storage Working Group. The IESG contact persons are Allison Mankin and Jon Peterson. Technical Summary draft-ietf-ips-fcip-slp-09.txt describes the use of the Service Location Protocol Version 2 (SLPv2) to perform dynamic discovery of participating FCIP Entities. Implementation guidelines, service type templates, and security considerations are specified. FCIP is a pure FC encapsulation protocol that transports FC frames. As defined by the IPS WG, it interconnects Fibre Channel switches over TCP/IP networks. Working Group Summary The Working Group had consensus to advance this documents to Proposed Standard. The SLPv2 and discovery aspects were given review and discussion on the mailing list by Erik Guttman and James Kempf, and this was an active discussion. This document had a revision following IESG review which was concerned about the Security Considerations and some text originally present on NAT, which was viewed as needing to be in a more general document and as not providing significant guidance. Protocol Quality The documents were reviewed for the IESG by Erik Guttman, James Kempf, Thomas Narten and Allison Mankin.David Black addressed the issues of the security review. RFC Editor Notes - Section 4.2 NAT and NAPT Considerations - delete this entire section - Section 5.2 - remove the line: # snmp://192.0.2.0 - Section 6.1. Security Implementation - section is replaced by new text: OLD: 6.1. Security Implementation Security for SLPv2 in an IP storage environment is specified in [IPS- SEC]. IPsec SHOULD be implemented for SLPv2 as specified in [IPS-SEC]. This includes ESP with a non-null transform to provide both authentication and confidentiality. SLPv2 authentication is OPTIONAL to implement and use, and SLPv2 authentication SHOULD be implemented when IPsec is not supported. NEW: 6.1. Security Implementation Security for SLPv2 in an IP storage environment is specified in [RFC3723]. IPsec is mandatory-to-implement for IPS clients and servers. Thus, all IP storage clients, including those invoking SLP, can be assumed to support IPsec. SLP servers, however, cannot be assumed to implement IPsec, since there is no such requirement in standard SLP. In particular, SLP Directory Agents (DA) may be running on machines other than those running the IPS protocols. IPsec SHOULD be implemented for SLPv2 as specified in [RFC3723]; this includes ESP with a non-null transform to provide both authentication and confidentiality. Because the IP storage services have their own authentication capabilities when located, SLPv2 authentication is OPTIONAL to implement and use (as discussed in more detail in [RFC 3723]). Change the draft's normative reference [IPS-SEC] to [RFC 3723]. ___ IETF-Announce mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf-announce
Last Call: 'Use of the SEED Encryption Algorithm in CMS' to Proposed Standard
The IESG has received a request from the S/MIME Mail Security WG to consider the following document: - 'Use of the SEED Encryption Algorithm in CMS ' draft-ietf-smime-cms-seed-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 [EMAIL PROTECTED] or [EMAIL PROTECTED] mailing lists by 2004-07-07. The file can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-smime-cms-seed-01.txt ___ IETF-Announce mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf-announce
Last Call: 'Vendor-Identifying Vendor Options for DHCPv4' to Proposed Standard
The IESG has received a request from the Dynamic Host Configuration WG to consider the following document: - 'Vendor-Identifying Vendor Options for DHCPv4 ' draft-ietf-dhc-vendor-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 [EMAIL PROTECTED] or [EMAIL PROTECTED] mailing lists by 2004-07-08. The file can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-dhc-vendor-03.txt ___ IETF-Announce mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf-announce
WG Action: RECHARTER: Multiprotocol Label Switching (mpls)
The charter of the Multiprotocol Label Switching (mpls) working group in the Routing Area of the IETF has been updated. For additional information, please contact the Area Directors or the working group Chairs. Multiprotocol Label Switching (mpls) Current Status: Active Working Group Chair(s): George Swallow [EMAIL PROTECTED] Loa Andersson [EMAIL PROTECTED] Routing Area Director(s): Bill Fenner [EMAIL PROTECTED] Alex Zinin [EMAIL PROTECTED] Routing Area Advisor: Alex Zinin [EMAIL PROTECTED] Mailing Lists: General Discussion: [EMAIL PROTECTED] To Subscribe: [EMAIL PROTECTED] In Body: subscribe (unsubscribe) Archive: http://cell.onecall.net/cell-relay/archives/mpls/mpls.index.html Description of Working Group: The MPLS working group is responsible for standardizing a base technology for using label switching and for the implementation of label-switched paths over various packet based link-level technologies, such as Packet-over-Sonet, Frame Relay, ATM, and LAN technologies (e.g. all forms of Ethernet, Token Ring, etc.). This includes procedures and protocols for the distribution of labels between routers and encapsulation. The working group is also responsible for specifying the necessary MIBs for the functionality specified in the base MPLS technology. The first generation of the MPLS standards are largely complete, and the current WG work items are: - procedures and protocols for multicast protocol extensions for point-to-multipoint TE, including soft-preemption - Define requirements and mechanisms for MPLS OAM - Define an overall OAM framework for MPLS applications - MPLS-specific aspects of traffic engineering for multi-areas/multi-AS in cooperation with the CCAMP WG - Determine (with CCAMP) what procedures are appropriate for evaluating proposals to extend the MPLS and GMPLS protocols, and document these - Document current implementation practices for MPLS load sharing The Working Group chairs tracking of the working group documents can be viewed at http://www.tla-group.com/~mpls/mpls-wg-docs.htm Goals and Milestones: Done Submit documents from original MPLS effort to IESG Done Framework for IP multicast over label-switched paths ready for advancement. Done LDP fault tolerance specification ready for advancement to Proposed Standard Done Submit Definitions of Managed Objects for MultoiProtocol Label Switching, Label Distribution Protocol (LDP) to the IESG for publication as Proposed Standards Done Specification for MPLS-specific recovery ready for advancement. Done Submit Multiprotocol Label Switching (MPLS) Forward Equivalency Class-To-Next Hop Label Forwarding Entry Management Information Base to the IESG for publication as Proposed Standards Done Submit Multiprotocol Label Switching (MPLS) Label Switching Router (LSR), Management Information Base to the IESG for publication as Proposed Standards Done Submit Multiprotocol Label Switching (MPLS) Management Overview to the IESG for publication as Proposed Standards Done Submit Definitions of Textual Conventions for Multiprotocol Label Switching (MPLS) Management to the IESG for publication as Proposed Standards Done Submit Multiprotocol Label Switching (MPLS) Traffic Engineering Management Information Base to the IESG for publication as Proposed Standards Done Submit the Traffic Engineering Link MIB to the IESG for as a Proposed Standard Done Submit a specification on Encapsulations to carry MPLS over IP and GRE to the IESG for as a Proposed Standard Nov 03 Together with CCAMP complete and establish the (G)MPLS change process Apr 04 Advance MPLS Architecture and MPLS encapsulation to Draft Standard Apr 04 Submit a specification on Soft Pre-emption of LSP Tunnels to the IESG for publication as a Proposed Standard Apr 04 Submit specification on LSR Self Test to the IESG for publication as a Proposed Standard Jul 04 Submit specification on LSP Ping to the IESG for publication as a Proposed Standard Jul 04 Submit a document defining the scope, requirements, and issues to resolve for setup of P2MP TE LSPs (MPLS and GMPLS) Aug 04 Submit an OAM Framework Document to the IESG for publication as an Informational RFC Oct 04 Advance 'Extension to RSVP for LSP Tunnels' to Draft Standard Nov 04 Submit document(s) specifying protocol extensions, enhancements and mechanisms for setup of P2MP TE LSPs Nov 04 Submit a BCP on MPLS load sharing to the IESG ___ IETF-Announce mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf-announce
Document Action: 'Protocol Independent Multicast - Dense Mode (PIM-DM): Protocol Specification (Revised)' to Experimental RFC
The IESG has approved the following document: - 'Protocol Independent Multicast - Dense Mode (PIM-DM): Protocol Specification (Revised) ' draft-ietf-pim-dm-new-v2-05.txt as an Experimental RFC This document is the product of the Protocol Independent Multicast Working Group. The IESG contact persons are Alex Zinin and Bill Fenner. Technical Summary This document specifies Protocol Independent Multicast - Dense Mode (PIM-DM). PIM-DM is a multicast routing protocol that uses the underlying unicast routing information base to flood multicast datagrams to all multicast routers. Prune messages are used to prevent future messages from propagating to routers with no group membership information. Working Group Summary The WG has a consensus on this document. Protocol Quality The document has been reviewed for the IESG by Alex Zinin. RFC Editor Note: Section 7.3, 2nd paragraph, 1st sentence: OLD: To use IPSec, the administrator of a PIM network configures each PIM router with one or more Security Associations and associated Security Parameters Indices that are used by senders to sign PIM protocol ^ messages and are used by receivers to authenticate received PIM protocol messages. NEW: To use IPSec, the administrator of a PIM network configures each PIM router with one or more Security Associations and associated Security Parameters Indices that are used by senders to authenticate PIM protocol messages and are used by receivers to authenticate received PIM protocol messages. ___ IETF-Announce mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf-announce
Protocol Action: 'The Internet Assigned Number Authority (IANA) Header Field Parameter Registry for the Session Initiation Protocol (SIP)' to BCP
The IESG has approved the following documents: - 'The Internet Assigned Number Authority (IANA) Header Field Parameter Registry for the Session Initiation Protocol (SIP) ' draft-ietf-sip-parameter-registry-02.txt as a BCP - 'The Internet Assigned Number Authority (IANA) Universal Resource Identifier (URI) Parameter Registry for the Session Initiation Protocol (SIP) ' draft-ietf-sip-uri-parameter-reg-02.txt as a BCP These documents are products of the Session Initiation Protocol Working Group. The IESG contact persons are Allison Mankin and Jon Peterson. Technical Summary These documents creates an IANA registries for SIP header field parameters and parameter values, and SIP/SIPS uri parameters and parameter values. It also lists the already existing parameters and parameter values to be used as the initial entries for this registry. The purpose of this to to update RFC 3427 and minimize problems from duplicated parameters and problematic values. Working Group Summary There was strong support of this registry. The working group pushed for adding the parameter values registry. A determination was made that such a registry could become large, so the compromise design was decided on: when parameter values are registrable, the registry for the parameter flags this, and points to the RFC documenting their set of values. Protocol Quality The document review for the IESG was done by Allison Mankin and IANA reviewed during Last Call without finding problems. There was a large amount of review by the working group. RFC Editor Notes: Change Title OLD: The Internet Assigned Number Authority Universal Resource Identifier Parameter Registry for the Session Initiation Protocol NEW The Internet Assigned Number Authority Uniform Resource Identifier Parameter Registry for the Session Initiation Protocol Uniform -not- Universal (and in the text, if universal appears, please substitute 'uniform') -- draft-ietf-sip-parameter-registry-02.txt, section 4.2 OLD: As per the terminology in RFC 2434 [2], the registration policy for SIP header field parameters and parameter values shall be Specification Required. NEW: As per the terminology in RFC 2434 [2], the registration policy for SIP header field parameters and parameter values shall be IETF Consensus. ___ IETF-Announce mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf-announce
Protocol Action: 'Internet Printing Protocol (IPP): Event Notifications and Subscriptions' to Proposed Standard
The IESG has approved the following documents: - 'Internet Printing Protocol (IPP): Event Notifications and Subscriptions ' draft-ietf-ipp-not-spec-12.txt as a Proposed Standard - 'Internet Printing Protocol (IPP): The 'ippget' Delivery Method for Event Notifications ' draft-ietf-ipp-notify-get-10.txt as a Proposed Standard - 'Internet Printing Protocol: Requirements for IPP Notifications ' draft-ietf-ipp-not-07.txt as an Informational RFC These documents are products of the Internet Printing Protocol Working Group. The IESG contact persons are Scott Hollenbeck and Ted Hardie. Technical Summary These documents describe extensions to the Internet Printing Protocol/1.1: Model and Semantics (RFC 2911, RFC 2910). The first extension allows a client to subscribe to printing related Events. Subscriptions are modeled as Subscription Objects. The Subscription Object specifies that when one of the specified Events occurs, the Printer delivers an asynchronous Event Notification to the specified Notification Recipient via the specified Push or Pull Delivery Method (i.e., protocol). The second extension is the 'ippget' Pull Delivery Method for use with the Event Notifications extension. This IPPGET Delivery Method is REQUIRED for all clients and Printers that support ipp-ntfy. The Notification Recipient, acting as a client, fetches (pulls) Event Notifications using the Get-Notifications operation. The final document in this set provides a statement of the requirements for notifications as part of an IPP service. Working Group Summary These documents are products of the Internet Printing Protocol Working Group of the IETF. The Working Group originally developed a general printer notification framework and three notification schemes, two based on IPP operations and one based on email. However, a previous IESG review pass caused the Working Group to eliminate two of the schemes and move forward with ippget alone. Protocol Quality Ned Freed and Scott Hollenbeck reviewed the specification for the IESG. ___ IETF-Announce mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf-announce
Last Call: 'A Presence-based GEOPRIV Location Object Format' to Proposed Standard
The IESG has received a request from the Geographic Location/Privacy WG to consider the following document: - 'A Presence-based GEOPRIV Location Object Format ' draft-ietf-geopriv-pidf-lo-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 [EMAIL PROTECTED] or [EMAIL PROTECTED] mailing lists by 2004-07-16. The file can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-geopriv-pidf-lo-02.txt ___ IETF-Announce mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf-announce
Last Call: 'The Alternative Network Address Types Semantics for the Session Description Protocol Grouping Framework' to Proposed Standard
The IESG has received a request from the Multiparty Multimedia Session Control WG to consider the following document: - 'The Alternative Network Address Types Semantics for the Session Description Protocol Grouping Framework ' draft-ietf-mmusic-anat-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 [EMAIL PROTECTED] or [EMAIL PROTECTED] mailing lists by 2004-07-20. The file can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-mmusic-anat-01.txt ___ IETF-Announce mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf-announce
Protocol Action: 'Network Mobility (NEMO) Basic Support Protocol' to Proposed Standard
The IESG has approved the following document: - 'Network Mobility (NEMO) Basic Support Protocol ' draft-ietf-nemo-basic-support-03.txt as a Proposed Standard This document is the product of the Network Mobility Working Group. The IESG contact persons are Margaret Wasserman and Thomas Narten. Technical Summary This document describes the NEMO Basic Support protocol that enables mobile networks to attach to different points in the Internet. The protocol is an extension of Mobile IPv6 and allows for session continuity for every node in the mobile network as the network moves. It also allows every node in the mobile network to be reachable while moving around. The Mobile Router, which connects the network to the Internet, runs the NEMO Basic Support protocol with its Home Agent. The protocol is designed in such a way that network mobility is transparent to the nodes inside the mobile network. Working Group Summary This document is the output of the NEMO WG. This document was reviewed by many members of the WG, and there is consensus to advance the draft. There are IPR claims regarding this technology from Cisco and Nokia. The WG is aware of those claims and made a consensus decision to continue work in spite of those claims. Protocol Quality This draft was reviewed for the IESG by Margaret Wasserman. ___ IETF-Announce mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf-announce
Last Call: 'Usage of the Session Description Protocol (SDP) Alternative Network Address Types (ANAT) Semantics in 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: - 'Usage of the Session Description Protocol (SDP) Alternative Network Address Types (ANAT) Semantics in the Session Initiation Protocol (SIP) ' draft-ietf-sip-anat-usage-00.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 [EMAIL PROTECTED] or [EMAIL PROTECTED] mailing lists by 2004-07-20. The file can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-sip-anat-usage-00.txt ___ IETF-Announce mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf-announce
Document Action: 'FLUTE - File Delivery over Unidirectional Transport' to Experimental RFC
The IESG has approved the following document: - 'FLUTE - File Delivery over Unidirectional Transport ' draft-ietf-rmt-flute-08.txt as an Experimental RFC This document is the product of the Reliable Multicast Transport Working Group. The IESG contact persons are Allison Mankin and Jon Peterson. ___ IETF-Announce mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf-announce
Protocol Action: 'IFAX service of ENUM' to Proposed Standard
The IESG has approved the following document: - 'IFAX service of ENUM ' draft-ietf-fax-faxservice-enum-03.txt as a Proposed Standard This document is the product of the Internet Fax Working Group. The IESG contact persons are Scott Hollenbeck and Ted Hardie. Technical Summary This document describes the functional specification and the definition of the ENUM NAPTR record for IFax service. IFax is Facsimile using Internet Mail. For this use, the DNS returns the email address of the referenced IFax system. This mechanism allows email-based fax communication to use telephone numbers, rather than requiring that the sender already know the recipient email address. Working Group Summary This document was reviewed by both the FAX and ENUM working groups. The FAX working group reached consensus on the document, and review by the ENUM working group was requested. Comments provided by the ENUM working group were received and incorporated to produce the document. Protocol Quality Scott Hollenbeck has reviewed the specification for the IESG. ___ IETF-Announce mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf-announce
Protocol Action: 'Reclassifying DHCPv4 Options' to Proposed Standard
The IESG has approved the following document: - 'Reclassifying DHCPv4 Options ' draft-ietf-dhc-reclassify-options-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 Thomas Narten. Technical Summary The DHCPv4 option codes defined for public use in RFC 2131 and RFC 2132, option codes 1-127, are nearly all assigned to DHCP options. Efforts such as the reclamation of unused DHCP option codes in RFC 3679 help to extend the life of the option code space, but ultimately the space is expected to be exhausted. This document reclassifies much of the site-specific option range, option codes 128-254, which has not been widely used for its original intended purpose, to be used as option codes for publicly defined DHCP options.' There are known to be some devices that use options in the range of 128-254 in undocumented ways. This document defines a process through which an option code is provisionally marked as a candidate for assignment to a DHCP option and subject to public review and comment before actual assignment. Vendors will be encouraged to bring forward specifications for options that currently use option codes that are reclassified by this document. Working Group Summary The dhc WG reviewed several alternative mechanisms for extending the option code space before choosing the mechanism specified in this document. The other mechanisms were described in earlier drafts of the document. The WG reviewed the alternatives in two WG meetings and on the WG mailing list. Protocol Quality The mechanism for review and reclassification of option codes in this document allows for public review of reclassifed option codes to avoid conflict with the use of DHCP option codes by existing and deployed devices. This document was reviewed for the IESG by Margaret Wasserman. ___ IETF-Announce mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf-announce
Protocol Action: 'WHOIS Protocol Specification' to Draft Standard
The IESG has approved the following document: - 'WHOIS Protocol Specification ' draft-daigle-rfc954bis-01.txt as a Draft 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. Technical Summary This document revises RFC 954, the existing Draft Standard for Whois by removing the policy elements of the existing specification and retaining the technical specification. This document contains no substantive changes to the Whois protocol. Working Group Summary This document is the product of an individual submitter. There has been considerable discussion of the appropriate standardization level for this work. The choice of cycling in grade reflects both the existance of numerous interoperable clients and servers and the consensus of the community, expressed in RFC 3707, that future development of administrative directory services should not be based on whois. There is no doubt that this work might have advanced to Full Standard at one time, but the current belief is that that time has now passed. Protocol Quality This document was reviewed for the IESG by Ted Hardie. RFC Editor Note: Please add the following to the Acknowledgements: Ken Harrenstien, Mary Stahl, and Elizabeth Feinler were the authors of the original Draft Standard for Whois. ___ IETF-Announce mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf-announce
Last Call: 'Management Information Base for Data Over Cable Service Interface Specification (DOCSIS) Cable Modem Termination Systems for Subscriber Management' to Proposed Standard
The IESG has received a request from the IP over Cable Data Network WG to consider the following document: - 'Management Information Base for Data Over Cable Service Interface Specification (DOCSIS) Cable Modem Termination Systems for Subscriber Management ' draft-ietf-ipcdn-subscriber-mib-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 [EMAIL PROTECTED] or [EMAIL PROTECTED] mailing lists by 2004-08-06 (note: some extra time (3 weeks) because IETF 60 is coming up). The file can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-ipcdn-subscriber-mib-14.txt ___ IETF-Announce mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf-announce
Protocol Action: 'Enumservice Registration for Presence Services' to Proposed Standard
The IESG has approved the following document: - 'Enumservice Registration for Presence Services ' draft-ietf-enum-pres-01.txt as a Proposed Standard This document is the product of the Telephone Number Mapping Working Group. The IESG contact persons are Allison Mankin and Jon Peterson. Technical Summary This document registers an ENUM service for presence services (as described in RFC 2778), pursuant to the guidelines in RFC 3761. Specifically, this document focuses on provisioning pres URIs in ENUM. Working Group Summary The working group was very comfortable with adopting this service registration for the standards track and progressing it. Protocol Quality There are not currently implementations of pres: service registrations, as far as can be ascertained. The service registration has been carefully constructed. It was reviewed for the IESG by Allison Mankin. RFC Editor Note: Change the example to be checklist compliant. OLD: $ORIGIN 0.0.6.2.3.3.5.2.0.2.1.e164.arpa. IN NAPTR 100 10 u E2U+pres !^.*$!pres:[EMAIL PROTECTED] NEW: $ORIGIN 3.8.0.0.6.9.2.3.6.1.4.4.e164.arpa. IN NAPTR 100 10 u E2U+pres !^.*$!pres:[EMAIL PROTECTED] ___ IETF-Announce mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf-announce
Additional Last Call (References): 'Source-Specific Protocol
Independent Multicast in 232/8' to BCP Reply-to: [EMAIL PROTECTED] The IESG has received a request from the MBONE Deployment WG to consider the following document: - 'Source-Specific Protocol Independent Multicast in 232/8 ' draft-ietf-mboned-ssm232-08.txt as a BCP This document has been reviewed by the IESG and the following issue was found: The document has a normative reference to an experimental protocol: RFC3618 Meyer, D. and B. Fenner (Editors), The Multicast Source Discovery Protocol (MSDP), RFC 3618, October, 2003. IETF procedures generally require that a standards track RFC may not have a normative reference to a document at a lower standards level. However, according to: http://www.ietf.org/internet-drafts/draft-ymbk-downref-02.txt an exception can be made by explicitly mentioning this issue during the last call. This procedure was not available when the original last call was made. The IESG plans to make a decision on whether to accept the reference in the next few weeks, and solicits final comments. Please send any comments to the [EMAIL PROTECTED] or [EMAIL PROTECTED] mailing lists by 2004-07-30. The file can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-mboned-ssm232-08.txt ___ IETF-Announce mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf-announce
Protocol Action: 'Dynamic Configuration of Link-Local IPv4 Addresses' to Proposed Standard
The IESG has approved the following document: - 'Dynamic Configuration of Link-Local IPv4 Addresses ' draft-ietf-zeroconf-ipv4-linklocal-17.txt as a Proposed Standard This document is the product of the Zero Configuration Networking Working Group. The IESG contact persons are Thomas Narten and Margaret Wasserman. Technical Summary This specification serves three important functions. First, it documents the IPv4 Link-local autoconfiguration protocol as shipped by Microsoft and Apple in popular operating system releases since 1998. Second, it offers definite rules for how this protocol should operate in the future. This differs in particular ways from the code which Apple and Microsoft have implemented. The changes come from experience with the existing implem- entations as well as Working Group assessment. Third, a set of unsolved issues are called out for implementors - focussing on use of Link-Local configuration for multihomed hosts. It is important for this specification to be issued as a standard as soon as possible since the number of non-standard implementations are multiplying. In particular, some implementations make assumptions about the setting of the TTL of packets sent by hosts which are incompatible with the recommendation set by the specification supported by IETF WG consensus. The longer we wait, the less interoperation we will see in practice. It is not a question of adoption: This protocol is already widely adopted. We must prevent it from further mutations. The current version of this protocol will not break existing implementations with the one exception. Those implementations which assumed that all datagrams would be sent with a TTL of 255 in order to drop incoming messages with TTLs not equal to 255 will not properly interoperate with hosts which implement the current specification. The TTL filtering feature appeared roughly at draft 3 and was removed as of draft 9 of this protocol specification. Most existing implementations and all existing Windows implementations interoperate with the current specification. It is important to note that there are differences between the current version of this protocol and those implemented and deployed on Apple and Microsoft platforms. The current version of the protocol is documented in this specification, as well as the deployed versions of the protocol. Working Group Summary Working group consensus has been slowly achieved through many contentious and laborious discussions. Several issues arose which were only decided by compromise: Avoiding a 'solution' for multihomed problems, requiring that advertisements of link local addresses cease once routeable address configuration exists, omission of special 'faster timers' text and other areas. The consensus, while rough, expresses the end result of years of exacting scrutiny of this document by several reviewers. Protocol Quality The basis of this protocol has been deployed on millions of hosts. The modifications to the protocol are quite minor and have received a very high degree attention during the critical review phase. This protocol has been reviewed for the IESG by Thomas Narten. ___ IETF-Announce mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf-announce
Document Action: 'Evaluation of Candidate Protocols for IP Flow Information Export (IPFIX)' to Informational RFC
The IESG has approved the following document: - 'Evaluation of Candidate Protocols for IP Flow Information Export (IPFIX) ' draft-leinen-ipfix-eval-contrib-03.txt as an Informational RFC This document is the product of the IP Flow Information Export Working Group. The IESG contact persons are Bert Wijnen and David Kessens. Technical Summary This document contains an evaluation of the five candidate protocols for an IP Flow Information Export (IPFIX) protocol, based on the requirements document produced by the IPFIX Working Group. The protocols are characterized and grouped in broad categories, and evaluated against specific requirements. Finally, a recommendation is made to select the NetFlow v9 protocol as the basis for the IPFIX specification. This document contains an evaluation of the five candidate protocols for an IP Flow Information Export (IPFIX) protocol, based on the requirements document produced by the IPFIX Working Group. The protocols are characterized and grouped in broad categories, and evaluated against specific requirements. Finally, a recommendation is made to select the NetFlow v9 protocol as the basis for the IPFIX specification. Working Group Summary The WG has consensus to publish this document as an Informational RFC. Protocol Quality Bert Wijnen reviewed this document for the IESG. ___ IETF-Announce mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf-announce
Protocol Action: 'IRIS - The Internet Registry Information Service (IRIS) Core Protocol' to Proposed Standard
The IESG has approved the following documents: - 'IRIS - The Internet Registry Information Service (IRIS) Core Protocol ' draft-ietf-crisp-iris-core-07.txt as a Proposed Standard - 'IRIS - A Domain Registry (dreg) Type for the Internet Registry Information Service ' draft-ietf-crisp-iris-dreg-07.txt as a Proposed Standard - 'IRIS - Using the Internet Registry Information Service (IRIS) over theBlocks Extensible Exchange Protocol (BEEP) ' draft-ietf-crisp-iris-beep-07.txt as a Proposed Standard These documents are products of the Cross Registry Information Service Protocol Working Group. The IESG contact persons are Ted Hardie and Scott Hollenbeck. Technical Summary This document describes an application layer client-server protocol for a framework representing the query and result operations of the administrative information services of Internet registries. Specified in XML, the protocol defines generic query and result operations and a mechanism for extending these operations for specific registry service needs. Working Group Summary The working group went through an extensive requirements process and had two competing proposals; this one and one based on LDAP. The group was able to come to consensus on this proposal, and there has been no significant dissent on the shape of this proposal since the working group decided on it as the way forward. Protocol Quality There is at least one implementation of the current specification. The document was reviewed during working group last call by the working group chairs, Dave Blacka, and Ted Hardie. ___ IETF-Announce mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf-announce
WG Action: Conclusion of The Operation of the IESG/IAB Nominating and Recall Committees (nomcom)
The Operation of the IESG/IAB Nominating and Recall Committees (nomcom) working group in the General Area has concluded. The IESG contact person is Harald Alvestrand. The mailing list will be closed. ___ IETF-Announce mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf-announce
WG Action: Conclusion of Prefix Taxonomy Ongoing Measurement Inter Network Experiment (ptomaine)
The Prefix Taxonomy Ongoing Measurement Inter Network Experiment (ptomaine) working group in the Operations and Management Area has concluded. The IESG contact persons are Bert Wijnen and David Kessens. The mailing list will be closed. ___ IETF-Announce mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf-announce
Protocol Action: 'Clarifying when Standards Track Documents may Refer Normatively to Documents at a Lower Level' to BCP
The IESG has approved the following document: - 'Clarifying when Standards Track Documents may Refer Normatively to Documents at a Lower Level ' draft-ymbk-downref-03.txt as a BCP This document has been reviewed in the IETF but is not the product of an IETF Working Group. The IESG contact person is Harald Alvestrand. Technical Summary IETF procedures generally require that a standards track RFC may not have a normative reference to a document at a lower standards level. For example a standards track document may not have a normative reference to an informational RFC. There are needs for exceptions to this rule, often caused by the IETF using informational RFCs to describe non-IETF standards, or IETF-specific modes of use of such standards. This document clarifies the procedure used in these circumstances. Working Group Summary This document has been developed based on IESG experience with reference issues. It has been discussed in the IESG and with the RFC Editor There was one (positive) Last Call comment. Protocol Quality This document has been reviewed for the IESG by Harald Alvestrand. ___ IETF-Announce mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf-announce
Protocol Action: 'End-to-End Object Encryption in the Extensible Messaging and Presence Protocol (XMPP)' to Proposed Standard
The IESG has approved the following document: - 'End-to-End Object Encryption in the Extensible Messaging and Presence Protocol (XMPP) ' draft-ietf-xmpp-e2e-09.txt as a Proposed Standard This document is the product of the Extensible Messaging and Presence Protocol Working Group. The IESG contact persons are Scott Hollenbeck and Ted Hardie. Technical Summary The End-to-End Object Encryption in XMPP document defines the mechanisms that would allow an XMPP sender to construct an encrypted and/or signed S/MIME body that is decrypted only at the final recipient, even though there may be several XMPP intermediaries along the path. Because intermediaries may exist and need to know how to route the message, the encrypted message is wrapped in an unencrypted envelope. The message may be an instant message intended for display, or a presence message intended to update the recipient's knowledge of the sender's state, or another type of message. In addition to working for XMPP networks, this specification also allows for the possibility of working over heterogeneous links, through the use of the CPIM standard instant message format and the PIDF standard presence information format (rather than the formats unique to XMPP which are normally transformed in gateways). Gateways to non-XMPP protocols can remove the XMPP envelope and readdress the secured payload for another protocol. The next concern is how the certificate used to sign or encrypt the message is verified against the sender's address. The e2e spec constrains what format the XMPP address must appear in within the certificate, and where. Timestamp checking is required so that this end-to-end encryption and signing can also protect from replay attacks. Finally, the mandatory to implement technologies are SHA-1, RSA and AES. Working Group Summary The working group has done a lot of review of this document, and even been careful to solicit and respond to outside review. There have been several issues but the chairs believe consensus has been reached. Protocol Quality Lisa Dusseault, Pete Resnick, and Scott Hollenbeck have reviewed this document for the IESG. RFC Editor Note: Please remove Appendix B. Please replace instances of in section 12.1 with RFC and the RFC number to be assigned to this document. ___ IETF-Announce mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf-announce
Protocol Action: 'The Early Session Disposition Type for the Session Initiation Protocol (SIP)' to Proposed Standard
The IESG has approved the following documents: - 'The Early Session Disposition Type for the Session Initiation Protocol (SIP) ' draft-ietf-sipping-early-disposition-03.txt as a Proposed Standard - 'Early Media and Ringing Tone Generation in the Session Initiation Protocol (SIP) ' draft-ietf-sipping-early-media-02.txt as an Informational RFC These documents are products of the Session Initiation Proposal Investigation Working Group. The IESG contact persons are Allison Mankin and Jon Peterson. Technical Summary The Early Session Disposition Type for the Session Initiation Protocol : This document defines a new disposition type (early-session) for the Content-Disposition header field in SIP. The treatment of early-session bodies is similar to the treatment of session bodies. That is, they follow the offer/answer model. Their only difference is that session descriptions whose disposition type is early-session are used to establish early media sessions within early dialogs, as opposed to regular sessions within regular dialogs. Early media refers to media (e.g., audio and video) that is exchanged before a particular session is accepted by the called user. Within a dialog, early media occurs from the moment the initial INVITE is sent until the callee generates a final response. It may be unidirectional or bi-directional, and can be generated by the caller, the callee, or both. Typical examples of early media generated by the callee are ringing tone and announcements (e.g., queuing status.) Early media generated by the caller typically consists of voice commands or DTMF tones that drive interactive voice servers. Early Media and Ringing Tone Generation in the Session Initiation Protocol This documents describes some models for early media handling. Working Group Summary The design choice of using an early-session Content-Disposition header field to parallel the session header field was not contentious. The working group had a very long process of coming to consensus on early media handling, given that there are real requirements for it, but potential abuses as well. The Informational document's models summarize the consensus that the group could reach. Protocol Quality Allison Mankin reviewed the documents for the IESG. RFC Editor Notes: In both documents: Expand the first appearance of UAC to User Agent Client (UAC), the first appearance of UAC to User Agent Server (UAS), and the first appearance of UA to User Agent (UA). Expand first instance of SRTP to Secure Realtime Transport Protocol (SRTP) Expand first instance of STUN to Simple Traversal of the UDP Protocol through NAT (STUN) In draft-ietf-sipping-early-disposition: Expand the first instance of PSTN to Public Switched Telephone Network (PSTN) Expand PIN to Personal Identification Number (PIN) Expand GUI to Graphical User Interface (GUI) In draft-ietf-sipping-early-media: Expand ICE to Interactive Connectivity Establishment (ICE) Expand SRTP to Secure Realtime Transport Protocol (SRTP) OLD: or DTMF tones to drive IVRs NEW: or dual tone multi-frequency (DTMF) tone to drive interactive voice response (IVR) systems OLD: A POTS-like SIP UA NEW: A POTS (Plain Old Telephone Service)-like SIP User Agent (UA) OLD: 3G IMS NEW: 3GPP IMS (Third Generation Partnership Project Internet Multimedia System) ___ IETF-Announce mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf-announce
Protocol Action: 'Update to RFC 2418 Regarding the Management of IETF Mailing Lists' to BCP
The IESG has approved the following document: - 'Update to RFC 2418 Regarding the Management of IETF Mailing Lists ' draft-wasserman-rfc2418-ml-update-01.txt as a BCP This document has been reviewed in the IETF but is not the product of an IETF Working Group. The IESG contact person is Harald Alvestrand. Technical Summary This document is an update to RFC 2418 that gives WG chairs explicit responsibility for managing WG mailing lists. In particular, it gives WG chairs the authority to temporarily suspend the mailing list posting privileges of disruptive individuals. Working Group Summary The document was proposed and discussed on the Solutions mailing list, and was discussed in the General Area meeting at IETF 59. It had strong support from many people. No objections were raised during Last Call. Protocol Quality The document was reviewed for the IESG by Harald Alvestrand RFC EDITOR NOTE: Please change the following text at the end of section 2: OLD: Other methods of mailing list control, including longer suspensions, must be approved by the IESG or carried out in accordance with other IESG-approved procedures. NEW: Other methods of mailing list control, including longer suspensions, must be carried out in accordance with other IETF-approved procedures. See BCP83 [RFC 3683] for one set of procedures already defined and accepted by the community. And, add an informative reference to: [RFC3683] Rose, M., A Practice for Revoking Posting Rights to IETF Mailing Lists, RFC 3683, BCP 83, March 2004. ___ IETF-Announce mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf-announce
Protocol Action: 'Video Message Message Context' to Proposed Standard
The IESG has approved the following document: - 'Video Message Message Context ' draft-hansen-lemonade-msgctxt-videomsg-01.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. Technical Summary The Message-Context header defined in RFC 3458 describes the context of a message (for example: fax-message or voice-message). This specification extends the Message-Context header with one additional context value: video-message. A receiving user agent (UA) may use this information as a hint to optimally present the message. Working Group Summary This document was the work of an individual submitter, but it was discussed both by the Lemonade and VPIM mailing group lists. Suggested changes were minor and have been incorporated. Protocol Quality This document was reviewed for the IESG by Ted Hardie ___ IETF-Announce mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf-announce
Protocol Action: 'A model for IETF Process Experiments' to BCP
The IESG has approved the following document: - 'A model for IETF Process Experiments ' draft-klensin-process-july14-02.txt as a BCP This document has been reviewed in the IETF but is not the product of an IETF Working Group. The IESG contact person is Harald Alvestrand. Technical Summary This document proposes a way to change IETF processes that provides notice to the community (via Last Call), a permanent record (via RFCs) and a reasonable expectation that the process changes will be evaluated for whether they worked or not, and rolled back if they did not work. Working Group Summary This document was discussed on the [EMAIL PROTECTED] mailing list, and the idea was presented at the Seoul IETF, in the Gen-Area meeting. The Last Call comments were positive to the idea. Protocol Quality This document has been reviewed for the IESG by Harald Alvestrand. NOTE TO RFC EDITOR: Please replace the abstract with the following: The IETF has designed process changes over the last ten years in one of two ways: announcement by the IESG (sometimes based on informal agreements with limited community involvement and awareness), and formal use of the same mechanism as is used for protocol specification. This document proposes a middle-ground approach to the system of making changes to IETF process, one that employs three steps. First, propose and carry out an experiment. Second, evaluate the experiment. Finally, establish permanent procedures based on operational experience. Please delete the following text from the end of section 1: We note that, if the procedures the IESG has adopted (and procedural exceptions it has made) over the last decade are legitimate, then the IESG has the authority to institute the changes proposed here by bootstrapping the proposed process. Please make RFC 2026 a normative reference, and all other references informational. ___ IETF-Announce mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf-announce
Document Action: 'Alternative Decision Making Processes for Consensus-blocked Decisions in the IETF' to Experimental RFC
The IESG has approved the following document: - 'Alternative Decision Making Processes for Consensus-blocked Decisions in the IETF' draft-hardie-alt-consensus-02.txt as an Experimental RFC This document has been reviewed in the IETF but is not the product of an IETF Working Group. The document had a 4-week IETF Last Call. The IESG contact person is Harald Alvestrand. Technical Summary This document proposes an experimental set of alternative decision-making processes for use in IETF working groups. There are a small number of cases in IETF working groups in which the group has come to consensus that a particular decision must be made but cannot come to consensus on the decision itself. This document describes alternative mechanisms which can be used to come to a decision in those cases. This is not meant to provide an exhaustive list, but to provide a known set of tools which can be used when required. Working Group Summary Discussion on various mailing lists has elicited a number of comments indicating that the procedures in this document are useless or of marginal utility, because in a deadlocked situation, one would not be able to get consensus to use them. We have seen no compelling argument that their availability would be harmful. People also stressed the importance of stressing that these procedures are a SUPPLEMENT to the normal consensus process. They do not in any way replace them. This document had a 4-week IETF Last Call. Protocol Quality This document was reviewed for the IESG by Harald Alvestrand. ___ IETF-Announce mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf-announce
Protocol Action: 'The IESG and RFC Editor documents: Procedures' to BCP
The IESG has approved the following document: - 'The IESG and RFC Editor documents: Procedures ' draft-iesg-rfced-documents-03.txt as a BCP This document is the product of the Internet Engineering Steering Group. The IESG contact persons are David Kessens and Harald Alvestrand. Technical Summary This document describes the IESG's procedures for handling documents submitted for RFC publication via the RFC Editor, subsequent to the changes proposed by the IESG at the Seoul IETF, March 2004. This document was written by Harald Alvestrand for the IESG. Protocol Quality David Kessens reviewed this document for the IESG. ___ IETF-Announce mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf-announce
WG Action: RECHARTER: Multiparty Multimedia Session Control (mmusic)
The charter of the Multiparty Multimedia Session Control (mmusic) working group in the Transport Area of the IETF has been updated. For additional information, please contact the Area Directors or the working group Chairs. Multiparty Multimedia Session Control (mmusic) -- Current Status: Active Working Group Chairs: Joerg Ott [EMAIL PROTECTED] Colin Perkins [EMAIL PROTECTED] Transport Area Directors: Allison Mankin [EMAIL PROTECTED] Jon Peterson [EMAIL PROTECTED] Transport Area Advisor: Jon Peterson [EMAIL PROTECTED] Mailing Lists: General Discussion: [EMAIL PROTECTED] To Subscribe: [EMAIL PROTECTED] In Body: subscribe your_email_address Archive: http://www.ietf.org/mailman/listinfo/mmusic Description of the Working Group The Multiparty MUltimedia SessIon Control (MMUSIC) Working Group was chartered to develop protocols to support Internet teleconferencing and multimedia communications. These protocols are now reasonably mature, and many have received widespread deployment. The group is now focussed on the revisions of these protocols in the light of implementation experience and additional demands that have arisen from other WGs (such as AVT, SIP, SIPPING, and MEGACO). Multimedia communications protocols use a common platform to express media and session descriptions: the Session Description Protocol, SDP. The many uses of SDP have led to (requests for) numerous extensions and have led to recognition of several flaws in the protocol design. In spite of these, it is widely deployed. - To support this current deployment, MMUSIC will revise SDP suitable for publication as a Draft Standard RFC. This will involve correcting minor bugs and clarifying the current specification. - Various extensions to SDP will be pursued to remedy the most urgent of SDP's shortcomings. These will be limited to use of SDP in conjunction with connection-oriented media such as TCP and SCTP, offering support to work with NATs and firewalls (e.g. via the ICE methodology), and exchange of media session security keys. With the exception of these specific items, only extensions within the existing SDP framework will be done (e.g. registering new codecs and defining parameters for them extending SDP to include new address families). To address the more fundamental issues with SDP, a next generation of SDP, referred to as SDPng, will be needed. An initial proposal is now available, and will be progressed to Experimental RFC while we gain experience with implementations. An informational document will be produced describing how the transition to a new session description protocol can be managed, to prepare implementors for such a future change. MMUSIC will maintain and revise the specification of the Real Time Streaming Protocol (RTSP), including fixes and clarifications based on implementation experience. The revised RTSP specification will be re-issued as a Proposed Standard RFC. We will also document how RTSP can be used in the presence of NAT boxes. An Internet Media Guide (IMG) is a collection of multimedia session descriptions expressed using SDP or some other session description format. It is used to describe a collection of multimedia sessions (e.g. television programme schedules). The IMG must be delivered to a potentially large audience, who use it to join a subset of the sessions described, and who may need to be notified of changes to the IMG. MMUSIC will investigate delivery mechanisms for IMGs, generalizing our work on session announcement and discovery protocols (SAP, RTSP, SIP). We will investigate and document requirements for IMG delivery mechanisms, and identify the requirements that these delivery mechanisms impose on the session description formats used by the IMG. We will then work to produce a framework document outlining the use of (existing) protocols to create an IMG delivery infrastructure. After successful completion of these initial milestones for IMG delivery, the MMUSIC working group will decide whether or not MMUSIC is the proper place to pursue any needed mechanisms for IMGs, and if so, recharter accordingly The MMUSIC work items will be pursued in close coordination with other IETF WGs related to multimedia conferencing and IP telephony (AVT, SIP, SIPPING, SIMPLE, XCON, MEGACO and, where appropriate, MIDCOM and NSIS). Where appropriate, new separate working groups may be split off (as has happened with the SIP WG). The Working Group is also charged with addressing security issues related to the protocols it develops. Goals and Milestones: Jun 04 Submit IMG requirements and framework for Informational Aug 04 Review work on IMGs and update charter accordingly Aug 04 Submit revised SDP spec for Proposed Standard Aug 04 Submit SDP Offer/Answer examples for Informational Sep 04 Submit SDP connection-oriented media draft for Proposed Standard Nov 04 Submit SDPng transition scenarios for Informational Nov 04 Submit SDPng base specification for
WG Action: RECHARTER: Layer 2 Virtual Private Networks (l2vpn)
The charter of the Layer 2 Virtual Private Networks (l2vpn) working group in the Internet Area of the IETF has been updated. For additional information, please contact the Area Directors or the working group Chairs. Layer 2 Virtual Private Networks (l2vpn) = Current Status: Active Working Group Chair(s): Rick Wilder [EMAIL PROTECTED] Vach Kompella [EMAIL PROTECTED] Loa Andersson [EMAIL PROTECTED] Internet Area Director(s): Thomas Narten [EMAIL PROTECTED] Margaret Wasserman [EMAIL PROTECTED] Internet Area Advisor: Thomas Narten [EMAIL PROTECTED] Technical Advisor(s): Russell Housley [EMAIL PROTECTED] Alex Zinin [EMAIL PROTECTED] Mailing Lists: General Discussion: [EMAIL PROTECTED] To Subscribe: https://www1.ietf.org/mailman/listinfo/l2vpn Archive: http://www.ietf.org/mail-archive/web/l2vpn/index.html Description of Working Group: Alex Zinin is the routing advisor. Russ Housley is the security advisor. This working group is responsible for defining and specifying a limited number of solutions for supporting provider-provisioned layer-2 virtual private networks (L2VPNs). The WG is responsible for standardization of the following solutions: 1. Virtual Private LAN Service (VPLS)--L2 service that emulates LAN across an IP and an MPLS-enabled IP network, allowing standard Ethernet devices communicate with each other as if they were connected to a common LAN segment. 2. Virtual Private Wire Service (VPWS)--L2 service that provides L2 point-to-point connectivity (e.g. Frame Relay DLCI, ATM VPI/VCI, point-to-point Ethernet) across an IP and an MPLS-enabled IP network. 3. IP-only VPNs -- An L2 service across an IP and MPLS-enabled IP network, allowing standard IP devices to communicate with each other as if they were connected to a common LAN or with some mesh of point-to-point circuits (not necessarily fully meshed). The WG will address both of the following cases: - the customer attachment uses the same L2 protocol at all attachment points in the L2VPN. - the customer attachment uses different L2 protocols at the attachment points in the L2VPN. This case is intended to address the needs of service providers who may start out with a single L2 protocol at attachment points, but wish to incrementally upgrade individual attachment points over time to newer technologies. This is a restricted form of interworking that is limited to providing the facilities necessary to carry IP over the L2VPN; general L2 interworking is not in scope. The WG will address intra-AS scenarios only at this point (other scenarios will be considered for inclusion in the updated charter when the current one is completed.) As a general rule, the WG will not create new protocols, but will provide functional requirements for extensions of the existing protocols that will be discussed in the protocol-specific WGs. As a specific example, this WG will not define new encapsulation mechanism, but will use those defined in the PWE3 WG. L2VPN WG will review proposed protocol extensions for L2VPNs before they are recommended to appropriate protocol-specific WGs. The WG will work on the following items. Adding new work items will require rechartering. 1. Discovery of PEs participating in L2 service, and topology of required connectivity 2. Signaling of l2vpn related information for the purpose of setup and maintenance of l2vpn circuits. As much as possible PWE3 signaling procedures should be used 3. Solution documents (providing the framework for a specific solution, should include info on how discovery, signaling, and encaps work together, include security, AS as a separate document) 4. MIBs 5. L2VPN-specific OAM extensions--extensions to existing OAM solutions for VPLS, VPWS, and IP-only L2VPNs. Where necessary, the WG will coordinate its activities with IEEE 802.1 ___ IETF-Announce mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf-announce
Protocol Action: 'A Mission Statement for the IETF' to BCP
The IESG has approved the following document: - 'A Mission Statement for the IETF ' draft-alvestrand-ietf-mission-02.txt as a BCP This document has been reviewed in the IETF but is not the product of an IETF Working Group. The IESG contact person is David Kessens. Technical Summary This memo gives a mission statement for the IETF, tries to define the terms used in the statement sufficiently to make the mission statement understandable and useful, argues why the IETF needs a mission statement, and tries to capture some of the debate that led to this point. Working Group Summary This is document is not the work of an IETF working group, but is a contribution by the IETF chair Protocol Quality David Kessens reviewed this document for the IESG. --- Note to the RFC editor: Please correct the following style/spelling errors: Old: Open process - any interested participant can participate in the work, New: Open process - any interested person can participate in the work, - Old: Misson: What an organization sets out to do. New: Mission: What an organization sets out to do. - Old: Sometimes the IETF defines standards that are ultimately used mostly for non-global IP-routing Internet. New: Sometimes the IETF defines standards that ultimately see the most use outside the global Internet. ___ IETF-Announce mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf-announce
Last Call: 'Session Description Protocol (SDP) Source Filters' to Proposed Standard
The IESG has received a request from the Multiparty Multimedia Session Control WG to consider the following document: - 'Session Description Protocol (SDP) Source Filters ' draft-ietf-mmusic-sdp-srcfilter-06.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 [EMAIL PROTECTED] or [EMAIL PROTECTED] mailing lists by 2004-08-23. The file can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-mmusic-sdp-srcfilter-06.txt ___ IETF-Announce mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf-announce
Document Action: 'MIDCOM Protocol Semantics' to Informational RFC
The IESG has approved the following document: - 'MIDCOM Protocol Semantics ' draft-ietf-midcom-semantics-08.txt as an Informational RFC This document is the product of the Middlebox Communication Working Group. The IESG contact persons are Jon Peterson and Allison Mankin. Technical Summary This document provides an abstract set of operations for the MIDCOM protocol - a detailed description of the messages and attributes that would be used. As such, it is a blueprint for concrete specification of a MIDCOM protocol. It defines the necessary set of synchronous and asynchronous transactions that might occur between middleboxes and their controllers. Working Group Summary This document was supported by the MIDCOM WG - while selection of the protocol instantiating these abstract operations might be controversial, everyone seems to be able to agree what these abstract operations should be. Protocol Quality This document was reviewed for the IESG by Jon Peterson. ___ IETF-Announce mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf-announce
Last Call: 'Early IANA Allocation of Standards Track Codepoints' to BCP
The IESG has received a request from an individual submitter to consider the following document: - 'Early IANA Allocation of Standards Track Codepoints ' draft-kompella-zinin-early-allocation-02.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 [EMAIL PROTECTED] or [EMAIL PROTECTED] mailing lists by 2004-09-02. The file can be obtained via http://www.ietf.org/internet-drafts/draft-kompella-zinin-early-allocation-02.txt ___ IETF-Announce mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf-announce
Last Call: 'The APPLICATION/MBOX Media-Type' to Proposed Standard
The IESG has received a request from an individual submitter to consider the following document: - 'The APPLICATION/MBOX Media-Type ' draft-hall-mime-app-mbox-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 [EMAIL PROTECTED] or [EMAIL PROTECTED] mailing lists by 2004-09-06. The file can be obtained via http://www.ietf.org/internet-drafts/draft-hall-mime-app-mbox-02.txt ___ IETF-Announce mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf-announce
Last Call: 'Using IGMPv3 and MLDv2 For Source-Specific Multicast' to Proposed Standard
The IESG has received a request from the Multicast Anycast Group Membership WG to consider the following document: - 'Using IGMPv3 and MLDv2 For Source-Specific Multicast ' draft-holbrook-idmr-igmpv3-ssm-07.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 [EMAIL PROTECTED] or [EMAIL PROTECTED] mailing lists by 2004-08-23. The file can be obtained via http://www.ietf.org/internet-drafts/draft-holbrook-idmr-igmpv3-ssm-07.txt ___ IETF-Announce mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf-announce
Protocol Action: 'AES Encryption for Kerberos 5' to Proposed Standard
The IESG has approved the following document: - 'AES Encryption for Kerberos 5 ' draft-raeburn-krb-rijndael-krb-07.txt as a Proposed Standard This document is the product of the Kerberos WG Working Group. The IESG contact persons are Russ Housley and Steve Bellovin. Technical Summary This document specifies the conventions for using the Advanced Encryption Standard (AES) in the Kerberos cryptosystem suite. Working Group Summary The KRB-WG Working Group came to rough consensus on this document. Protocol Quality At least two independent implementations have shown the test vectors to be correct. This document was reviewed by Russ Housley for the IESG. ___ IETF-Announce mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf-announce
Last Call: 'Randomness Requirements for Security' to BCP
The IESG has received a request from an individual submitter to consider the following document: - 'Randomness Requirements for Security ' draft-eastlake-randomness2-08.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 [EMAIL PROTECTED] or [EMAIL PROTECTED] mailing lists by 2004-09-06. The file can be obtained via http://www.ietf.org/internet-drafts/draft-eastlake-randomness2-08.txt ___ IETF-Announce mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf-announce
Protocol Action: 'Routing Policy Specification Language next generation (RPSLng)' to Proposed Standard
The IESG has approved the following document: - 'Routing Policy Specification Language next generation (RPSLng) ' draft-blunk-rpslng-08.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 Bert Wijnen. Technical Summary This memo presents a new set of simple extensions to the Routing Policy Specification Language (RPSL) enabling the language to also document routing policies for the IPv6 and multicast address families currently used in the Internet. Working Group Summary This document is an AD sponsored document. The document was reviewed and worked on on a public mailing list ([EMAIL PROTECTED]). Protocol Quality This document was reviewed by Bert Wijnen for the IESG. ___ IETF-Announce mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf-announce
Protocol Action: 'Diameter Network Access Server Application' to Proposed Standard
The IESG has approved the following document: - 'Diameter Network Access Server Application ' draft-ietf-aaa-diameter-nasreq-17.txt as a Proposed Standard This document is the product of the Authentication, Authorization and Accounting Working Group. The IESG contact persons are Bert Wijnen and David Kessens. Technical Summary This document describes the Diameter protocol application used for Authentication, Authorization and Accounting (AAA) services in the Network Access Server (NAS) environment. This application specification, when combined with the Diameter Base protocol, Transport Profile, and Extensible Authentication Protocol specifications, satisfies typical network access services requirements. Initial deployments of the Diameter protocol are expected to include legacy systems. Therefore, this application was carefully designed to ease the burden of protocol conversion between RADIUS and Diameter. This is achieved by including the RADIUS attribute space, and eliminating the need to perform many attribute translations. Working Group Summary This document is the product of the aaa working group, and had wg consensuus. Comments in IETF last call were addressed by the current document. Protocol Quality This document was reviewed for the IESG by Randy Bush and Bert Wijnen ___ IETF-Announce mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf-announce
Protocol Action: 'SEcure Neighbor Discovery (SEND)' to Proposed Standard
The IESG has approved the following document: - 'SEcure Neighbor Discovery (SEND) ' draft-ietf-send-ndopt-06.txt as a Proposed Standard This document is the product of the Securing Neighbor Discovery Working Group. The IESG contact persons are Margaret Wasserman and Thomas Narten. Technical Summary IPv6 nodes use the Neighbor Discovery Protocol (NDP) to discover other nodes on the link, to determine the link-layer addresses of other nodes on the link, to find routers, and to maintain reachability information about the paths to active neighbors. If not secured, NDP is vulnerable to various attacks. This document specifies security mechanisms for NDP. Unlike the original NDP specifications, these mechanisms do not make use of IPsec. Working Group Summary The only major issue in the WG about this document was that both Microsoft and Ericsson declared that they had IPR on CGA technology. This issue was resolved after license conditions agreeable to the WG participants and suited for public domain software were posted by the respective companies. Before this, the WG briefly investigated an alternative that would have required the configuration of hosts with certificates, which might have resulted in deployment problems. Another significant issue in the WG focused around the design of the protocol and whether it should be based on IPsec AH or stand on its own. After documenting the alternatives and comparing their pros and cons, the consensus of the WG was to use an ND options based approach instead of IPsec. The benefits of this were lack of impact on IPsec architecture and implementations, and better ability to make security decisions based on application state. This is important, for instance, for co-existence of SEND and insecure ND on the same link. A minor issue involved how to represent the authorization for routers to route a certain prefix. The WG originally favored attribute certificates, but since the PKIX WG was planning on defining an identity certificate extension for this purpose, the WG decided to go with the IP address range extension in draft-ietf-pkix-x509-ipaddr-as-extn-03.txt. Note that this constructs a normative dependence on that draft, and it would be helpful if we could get that draft to advance as quickly as possible (or alterntively figure out a way to remove the normative dependence) since there is a market window on how long before it becomes too late for SEND to achieve widespread deployment, and having an officially published RFC is important for implementors. Protocol Quality The basic protocol design has been implemented on Linux. That implementation was used to fine tune the design, and the results of the fine tuning went into the final draft. This document was reviewed for the IESG by Margaret Wasserman. ___ IETF-Announce mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf-announce
Last Call: 'A Session Initiation Protocol (SIP) Event Notification Extension for Resource Lists' to Proposed Standard
The IESG has received a request from the SIP for Instant Messaging and Presence Leveraging Extensions WG to consider the following document: - 'A Session Initiation Protocol (SIP) Event Notification Extension for Resource Lists ' draft-ietf-simple-event-list-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 [EMAIL PROTECTED] or [EMAIL PROTECTED] mailing lists by 2004-08-25. The file can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-simple-event-list-05.txt ___ IETF-Announce mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf-announce
Last Call: 'Internationalized Resource Identifiers (IRIs)' to Proposed Standard
The IESG has received a request from an individual submitter to consider the following document: - 'Internationalized Resource Identifiers (IRIs) ' draft-duerst-iri-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 [EMAIL PROTECTED] or [EMAIL PROTECTED] mailing lists by 2004-09-08. The file can be obtained via http://www.ietf.org/internet-drafts/draft-duerst-iri-09.txt ___ IETF-Announce mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf-announce
Last Call: 'T11 Network Address Authority (NAA) naming format for iSCSI Node Names' to Proposed Standard
The IESG has received a request from the IP Storage WG to consider the following document: - 'T11 Network Address Authority (NAA) naming format for iSCSI Node Names ' draft-ietf-ips-iscsi-name-ext-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 [EMAIL PROTECTED] or [EMAIL PROTECTED] mailing lists by 2004-08-25. The file can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-ips-iscsi-name-ext-05.txt ___ IETF-Announce mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf-announce
Last Call: 'RObust Header Compression (ROHC):Profiles for UDP-Lite' to Proposed Standard
The IESG has received a request from the Robust Header Compression WG to consider the following document: - 'RObust Header Compression (ROHC):Profiles for UDP-Lite ' draft-ietf-rohc-udp-lite-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 [EMAIL PROTECTED] or [EMAIL PROTECTED] mailing lists by 2004-08-25. The file can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-rohc-udp-lite-04.txt ___ IETF-Announce mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf-announce
Last Call: 'IANA Registration for ENUMservices email, fax, mms, ems and sms' to Proposed Standard
The IESG has received a request from the Telephone Number Mapping WG to consider the following document: - 'IANA Registration for ENUMservices email, fax, mms, ems and sms ' draft-ietf-enum-msg-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 [EMAIL PROTECTED] or [EMAIL PROTECTED] mailing lists by 2004-08-25. The file can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-enum-msg-02.txt ___ IETF-Announce mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf-announce
Last Call: 'IANA Registration for ENUMservices web and ft' to Proposed Standard
The IESG has received a request from the Telephone Number Mapping WG to consider the following document: - 'IANA Registration for ENUMservices web and ft ' draft-ietf-enum-webft-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 [EMAIL PROTECTED] or [EMAIL PROTECTED] mailing lists by 2004-08-25. The file can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-enum-webft-01.txt ___ IETF-Announce mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf-announce
Protocol Action: 'Definition of Managed Objects for Synthetic Sources for Performance Monitoring Algorithms.' to Proposed Standard
The IESG has approved the following document: - 'Definition of Managed Objects for Synthetic Sources for Performance Monitoring Algorithms. ' draft-ietf-rmonmib-sspm-mib-12.txt as a Proposed Standard This document is the product of the Remote Network Monitoring Working Group. The IESG contact persons are Bert Wijnen and David Kessens. 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 objects for configuring Synthetic Sources for Performance Monitoring (SSPM) algorithms. Working Group Summary The Working Group has consensus to publish this document as a standards track RFC. Protocol Quality Bert Wijnen reviewed this document for the IESG. ___ IETF-Announce mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf-announce
Last Call: 'Default Router Preferences and More-Specific Routes' to Proposed Standard
The IESG has received a request from the IP Version 6 Working Group to consider the following document: - 'Default Router Preferences and More-Specific Routes ' draft-ietf-ipv6-router-selection-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 [EMAIL PROTECTED] or [EMAIL PROTECTED] mailing lists by 2004-08-30. The file can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-ipv6-router-selection-05.txt ___ IETF-Announce mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf-announce
Last Call: 'IP Tunnel MIB' to Proposed Standard
The IESG has received a request from the IP Version 6 Working Group to consider the following document: - 'IP Tunnel MIB ' draft-ietf-ipv6-inet-tunnel-mib-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 [EMAIL PROTECTED] or [EMAIL PROTECTED] mailing lists by 2004-08-30. The file can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-ipv6-inet-tunnel-mib-02.txt ___ IETF-Announce mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf-announce
Document Action: 'Scenarios and Analysis for Introducing IPv6 into ISP Networks' to Informational RFC
The IESG has approved the following document: - 'Scenarios and Analysis for Introducing IPv6 into ISP Networks ' draft-ietf-v6ops-isp-scenarios-analysis-03.txt as an Informational RFC This document is the product of the IPv6 Operations Working Group. The IESG contact persons are David Kessens and Bert Wijnen. Technical Summary This document first describes different scenarios for the introduction of IPv6 into an ISP's existing IPv4 network without disrupting the IPv4 service. Then, this document analyses these scenarios and evaluates the relevance of the already defined transition mechanisms in this context. Known challenges are also identified. Working Group Summary This document is a product of the v6ops working group Protocol Quality This document was reviewed for the IESG by David Kessens ___ IETF-Announce mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf-announce
Document Action: 'Security Considerations for 6to4' to Informational RFC
The IESG has approved the following document: - 'Security Considerations for 6to4 ' draft-ietf-v6ops-6to4-security-04.txt as an Informational RFC This document is the product of the IPv6 Operations Working Group. The IESG contact persons are David Kessens and Bert Wijnen. Technical Summary The IPv6 interim mechanism 6to4 (RFC3056) uses automatic IPv6-over-IPv4 tunneling to interconnect IPv6 networks. The architecture includes 6to4 routers and 6to4 relay routers, which accept and decapsulate IPv4 protocol-41 (IPv6-in-IPv4) traffic from any node in the IPv4 internet. This characteristic enables a number of security threats, mainly Denial of Service. It also makes it easier for nodes to spoof IPv6 addresses. This document discusses these issues in more detail and suggests enhancements to alleviate the problems. Working Group Summary This document is a product of the v6ops working group Protocol Quality David Kessens reviewed this document for the IESG ___ IETF-Announce mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf-announce
Last Call: 'Securing FTP with TLS' to Proposed Standard
The IESG has received a request from an individual submitter to consider the following document: - 'Securing FTP with TLS ' draft-murray-auth-ftp-ssl-15.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 [EMAIL PROTECTED] or [EMAIL PROTECTED] mailing lists by 2004-09-13. The file can be obtained via http://www.ietf.org/internet-drafts/draft-murray-auth-ftp-ssl-15.txt ___ IETF-Announce mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf-announce
Last Call: 'Uniform Resource Identifier (URI): Generic Syntax' to Full Standard
The IESG has received a request from an individual submitter to consider the following document: - 'Uniform Resource Identifier (URI): Generic Syntax ' draft-fielding-uri-rfc2396bis-06.txt as a Full 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 [EMAIL PROTECTED] or [EMAIL PROTECTED] mailing lists by 2004-09-13. The file can be obtained via http://www.ietf.org/internet-drafts/draft-fielding-uri-rfc2396bis-06.txt Implementation Report can be accessed at http://www.ietf.org/IESG/implementation.html ___ IETF-Announce mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf-announce
Protocol Action: 'Internet Printing Protocol(IPP): Job and Printer Administrative Operations' to Proposed Standard
The IESG has approved the following document: - 'Internet Printing Protocol(IPP): Job and Printer Administrative Operations ' draft-ietf-ipp-ops-set2-04.txt as a Proposed Standard This document is the product of the Internet Printing Protocol Working Group. The IESG contact persons are Scott Hollenbeck and Ted Hardie. Technical Summary This document defines additional optional end user, operator, and administrator operations used to control Internet Printing Protocol Jobs and Printers. In addition, this document extends the semantic model of the Printer object by allowing them to be configured into trees and/or inverted trees that represent Printer object Fan-Out and Printer object Fan-In, respectively. The special case of a tree with only a single Subordinate node represents Chained Printers. Working Group Summary This document is a product of the IPP Working Group. The IESG first reviewed this document in 2002. Though it has taken two years to address the review comments, the working group did eventually decide to update the document instead of letting it lapse. Protocol Quality Ned Freed and Scott Hollenbeck reviewed the specification for the IESG. RFC Editor Note Please change the second paragraph in section 16 (Security Considerations) from this: Printer operations defined in this specification (see section 3) and Pause-Printer, Resume-Printer, and Purge-Job (defined in [RFC2911]) are intended for use by an operator and/or administrator. Job operations defined in this specification (see section 4) and Cancel- Job, Hold-Job, Release-Job defined in [RFC2911]) are intended for use by the job owner or may be an operator or administrator of the Printer object. These operator and administrative operations affect the service of all users. In appropriate use of an administrative operation by an un-authenticated end user could affect the quality of service for all users. Therefore, for both inter-net and intra-net, conformance to this specification REQUIRES that initial configuration of IPP Printer implementations MUST require successful certificate- based TLS [RFC2246] client authentication and successful operator and administrator authorization (see [RFC2911] sections 5.2.7 and 8 and [RFC2910]) for any administrative operations defined in this document. [RFC2910] REQUIRES the IPP Printer to support the minimum cypher suite required for TLS/1.0. The means for authorizing an operator or administrator of the Printer object are outside the scope of this specification, [RFC2911], and [RFC2910]. to this: Printer operations defined in this specification (see section 3) and Pause-Printer, Resume-Printer, and Purge-Job (defined in [RFC2911]) are intended for use by an operator and/or administrator. Job operations defined in this specification (see section 4) and Cancel-Job, Hold-Job, and Release-Job (defined in [RFC2911]) are intended for use by the job owner, operator, or administrator of the Printer object. These operator and administrative operations affect service for all users. Inappropriate use of an administrative operation by an unauthenticated end user can affect the quality of service for all users. Therefore, IPP Printer implementations MUST support both successful certificate-based TLS [RFC2246] client authentication and successful operator/administrator authorization (see [RFC2911] sections 5.2.7 and 8 and [RFC2910]) to perform the administrative operations defined in this document. [RFC2910] requires the IPP Printer to support the minimum cipher suite specified for TLS/1.0. The means for authorizing an operator or administrator of the Printer object are outside the scope of this specification, RFC 2910, and RFC 2911. A normative reference to RFC 2119 must be added. The change history comment at the end of the list of informative references should be removed. ___ IETF-Announce mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf-announce
Protocol Action: 'The tel URI for Telephone Numbers' to Proposed Standard
The IESG has approved the following document: - 'The tel URI for Telephone Numbers ' draft-ietf-iptel-rfc2806bis-09.txt as a Proposed Standard This document is the product of the IP Telephony Working Group. The IESG contact persons are Jon Peterson and Allison Mankin. Technical Summary This document defines a tel URI scheme for telephone numbers and thereby revises the original definition given in RFC2806. This revision eliminates all vestiges of dial string usage of the tel URI in favor of a model where a tel URI is always a globally unique identifier. It also clarifies the use of tel URIs as the user portion of SIP URIs. Working Group Summary The IPTEL working group supported this revision to RFC2806. Protocol Quality This document was reviewed for the IESG by Jon Peterson. RFC Editor Note: Section 3, 2nd paragraph: OLD: If the reserved characters +, ;, =, and ? are used as delimiters between components of the tel URI, they MUST NOT percent-encoded. NEW: If the reserved characters +, ;, =, and ? are used as delimiters between components of the tel URI, they MUST NOT be percent-encoded. ^^ ___ IETF-Announce mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf-announce
Protocol Action: 'Session Timers in the Session Initiation Protocol (SIP)' to Proposed Standard
The IESG has approved the following document: - 'Session Timers in the Session Initiation Protocol (SIP) ' draft-ietf-sip-session-timer-15.txt as a Proposed Standard This document is the product of the Session Initiation Protocol Working Group. The IESG contact persons are Allison Mankin and Jon Peterson. Technical Summary This document defines an extension to the Session Initiation Protocol (SIP). This extension allows for a periodic refresh of SIP sessions through a re-INVITE or UPDATE request. The refresh allows both user agents and proxies to determine if the SIP session is still active (primarily to decide whether to clean up state associated with it). The extension defines two new header fields, Session-Expires, which conveys the lifetime of the session, and Min-SE, which conveys the minimum allowed value for the session timer. It advises for a usage of thirty minutes for the minimum at this time, and it recommends use of the session timer extension the sips URI (TLS is used for each hop) so that a hacker cannot lower the timer and minimum. Working Group Summary There was strong support for this document by the working group. The function is important to SIP because of stateful proxies and forking, it had been handled ad hoc. The draft was one of the earliest ones of the WG. It was delayed waiting for an extensive revision to comply with RFC 3261. Protocol Quality The draft had a thorough review on the working group mailing list. Some implementations are in development. It was reviewed for the IESG by Allison Mankin. ___ IETF-Announce mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf-announce
Protocol Action: 'RTP payload format for a 64 kbit/s transparent call' to Proposed Standard
The IESG has approved the following document: - 'RTP payload format for a 64 kbit/s transparent call ' draft-ietf-avt-rtp-clearmode-05.txt as a Proposed Standard This document is the product of the Audio/Video Transport Working Group. The IESG contact persons are Allison Mankin and Jon Peterson. Technical Summary This RTP payload format is useful in VoIP gateways to encapsulate the clear channel mode of ISDN. Working Group Summary ' There was strong support within the AVT working group for this payload. It was a clear design choice to make a single payload for the 64 kbps ISDN clear channel, and not to solve the nx64 channel designs with the same payload format. Protocol Quality Payload formats similar to this, protyping the ideas, have been in the field for some time. The document was reviewed for the IESG by Allison Mankin. ___ IETF-Announce mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf-announce
Document Action: 'Framework for Layer 2 Virtual Private Networks (L2VPNs)' to Informational RFC
The IESG has approved the following document: - 'Framework for Layer 2 Virtual Private Networks (L2VPNs) ' draft-ietf-l2vpn-l2-framework-05.txt as an Informational RFC This document is the product of the Layer 2 Virtual Private Networks Working Group. The IESG contact persons are Thomas Narten and Margaret Wasserman. Note to the RFC editor: Please add the following sentence to end of the last paragraph in Section 4.1: Note that this flooding can remove the (weak) confidentiality property of this or any other bridged network. ___ IETF-Announce mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf-announce
Last Call: 'Domain Name System Media Types' to Informational RFC
The IESG has received a request from an individual submitter to consider the following document: - 'Domain Name System Media Types ' draft-josefsson-mime-dns-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 [EMAIL PROTECTED] or [EMAIL PROTECTED] mailing lists by 2004-09-17. The file can be obtained via http://www.ietf.org/internet-drafts/draft-josefsson-mime-dns-02.txt ___ IETF-Announce mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf-announce
Document Action: 'Service requirements for Layer 3 Virtual Private Networks' to Informational RFC
The IESG has approved the following document: - 'Service requirements for Layer 3 Virtual Private Networks ' draft-ietf-l3vpn-requirements-02.txt as an Informational RFC This document is the product of the Layer 3 Virtual Private Networks Working Group. The IESG contact persons are Thomas Narten and Margaret Wasserman. Note: this document was initially reviewed by the IESG in 2003, under the document title: draft-ietf-ppvpn-requirements-05.txt. IESG members may want to review their archives for previous reviews. Technical Summary This document provides requirements for Layer 3 Virtual Private Networks (L3VPNs). It identifies requirements applicable to a number of individual approaches that a Service Provider may use for the provisioning of a VPN service. This document expresses a service provider perspective, based upon past experience of IP-based service offerings and the ever-evolving needs of the customers of such services. Toward this end, it defines terminology and states general requirements. Detailed requirements are expressed from a customer as well as a service provider perspective. Working Group Summary There was support for this document in the Working Group. Protocol Quality This document has been reviewed for the IESG by Thomas Narten. ___ IETF-Announce mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf-announce
Last Call: 'Policy Core Extension Lightweight Directory Access Protocol Schema' to Proposed Standard
The IESG has received a request from an individual submitter to consider the following document: - 'Policy Core Extension Lightweight Directory Access Protocol Schema ' draft-reyes-policy-core-ext-schema-06.txt as a Proposed Standard This document is an individual submission and is not the product of any IETF Working Group. However, the document has been reviewed and discussed on the Policy Framework Working Group mailing list and as a result has undergone a number of revisions. The Policy Framework Working Group has no objections to publishing this document as a standards track 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 [EMAIL PROTECTED] or [EMAIL PROTECTED] mailing lists by 2004-09-22. The file can be obtained via http://www.ietf.org/internet-drafts/draft-reyes-policy-core-ext-schema-06.txt ___ IETF-Announce mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf-announce
WG Action: Conclusion of Internet Printing Protocol (ipp)
The Internet Printing Protocol (ipp) in the Application Area has concluded. The IESG contact persons are Ted Hardie and Scott Hollenbeck. The mailing list will remain active. +++ The Internet Printing Protocol (IPP) working group has concluded. The group was chartered to develop requirements for Internet printing and to describe a model and semantics for Internet printing. A further goal was to define a new application level Internet printing protocol for the following core functions: - for a user to find out about a printer's capabilities - for a user to submit print jobs to a printer - for a user to find out the status of a printer or a print job - for a user to cancel a previously submitted job The working group produced eighteen Informational, Experimental, and Standards Track RFCs, including Rationale for the Structure of the Model and Protocol for the Internet Printing Protocol (RFC 2568) and Requirements for Job, Printer, and Device Administrative Operations (RFC 3239). Version 1.0 of the Internet Printing Protocol is described in Experimental and Informational RFCs 2565, 2566 and 2639. Version 1.1 is described in Standards Track and Informational RFCs 2910, 2911, 3196, and 3510. Other documents (RFCs 2567, 2569, 3380, 3381, and 3382) supplement these RFCs. Four other working group documents that describe IPP notifications and administrative operations were recently approved for publication as RFCs by the IESG. The IESG contacts are Ted Hardie and Scott Hollenbeck. ___ IETF-Announce mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf-announce
WG Action: Conclusion of Internet Printing Protocol (ipp)
The Internet Printing Protocol (ipp) in the Application Area has concluded. The IESG contact persons are Ted Hardie and Scott Hollenbeck. The mailing list will remain active. +++ The Internet Printing Protocol (IPP) working group has concluded. The group was chartered to develop requirements for Internet printing and to describe a model and semantics for Internet printing. A further goal was to define a new application level Internet printing protocol for the following core functions: - for a user to find out about a printer's capabilities - for a user to submit print jobs to a printer - for a user to find out the status of a printer or a print job - for a user to cancel a previously submitted job The working group produced eighteen Informational, Experimental, and Standards Track RFCs, including Rationale for the Structure of the Model and Protocol for the Internet Printing Protocol (RFC 2568) and Requirements for Job, Printer, and Device Administrative Operations (RFC 3239). Version 1.0 of the Internet Printing Protocol is described in Experimental and Informational RFCs 2565, 2566 and 2639. Version 1.1 is described in Standards Track and Informational RFCs 2910, 2911, 3196, and 3510. Other documents (RFCs 2567, 2569, 3380, 3381, and 3382) supplement these RFCs. Four other working group documents that describe IPP notifications and administrative operations were recently approved for publication as RFCs by the IESG. The IESG contacts are Ted Hardie and Scott Hollenbeck. ___ IETF-Announce mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf-announce
Document Action: 'IPv6 Enterprise Network Scenarios' to Informational RFC
The IESG has approved the following document: - 'IPv6 Enterprise Network Scenarios ' draft-ietf-v6ops-ent-scenarios-05.txt as an Informational RFC This document is the product of the IPv6 Operations Working Group. The IESG contact persons are David Kessens and Bert Wijnen. RFC Editor Note: The authors of draft-ietf-v6ops-ent-scenarios-05.txt request to make the following changes: Old: on an external network from the OLTP network. New: on a remote network from the OLTP network. Old: ThinkMagic New: ThingMagic Technical Summary This document describes the scenarios for IPv6 deployment within enterprise networks. It defines a small set of basic enterprise scenarios and includes pertinent questions to allow enterprise administrators to further refine their deployment scenarios. Working Group Summary This document is a product of the v6ops working group. Protocol Quality David Kessens reviewed this document for the IESG. ___ IETF-Announce mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf-announce
Protocol Action: 'Source-Specific Protocol Independent Multicast in 232/8' to BCP
The IESG has approved the following document: - 'Source-Specific Protocol Independent Multicast in 232/8 ' draft-ietf-mboned-ssm232-08.txt as a BCP This document is the product of the MBONE Deployment Working Group. The IESG contact persons are David Kessens and Bert Wijnen. Technical Summary IP Multicast group addresses in the 232/8 (232.0.0.0 to 232.255.255.255) range are designated as source-specific multicast [SSM] destination addresses and are reserved for use by source- specific multicast applications and protocols. This document defines operational recommendations to ensure source-specific behavior within the 232/8 range. Working Group Summary This document is the product of the mboned working group, where it passed last call without substantive comment. Protocol Quality This specification was reviewed for the IESG by Randy Bush and Bert Wijnen ___ IETF-Announce mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf-announce
Last Call: 'RTP Payload Formats for European Telecommunications Standardsv Institute (ETSI) European Standard ES 202 050, ES 202 211, and ES 202 212 Distributed Speech Recognition Encoding' to Propo
The IESG has received a request from the Audio/Video Transport WG to consider the following document: - 'RTP Payload Formats for European Telecommunications Standards Institute (ETSI) European Standard ES 202 050, ES 202 211, and ES 202 212 Distributed Speech Recognition Encoding ' draft-ietf-avt-rtp-dsr-codecs-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 [EMAIL PROTECTED] or [EMAIL PROTECTED] mailing lists by 2004-09-09. The file can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-avt-rtp-dsr-codecs-03.txt ___ IETF-Announce mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf-announce
Document Action: 'EAP Method Requirements for Wireless LANs' to Informational RFC
The IESG has approved the following document: - 'EAP Method Requirements for Wireless LANs ' draft-walker-ieee802-req-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 Margaret Wasserman. Technical Summary The IEEE 802.11i MAC Security Enhancements Amendment makes use of IEEE 802.1X which in turn relies on the Extensible Authentication Protocol (EAP). This document defines requirements for EAP methods used in IEEE 802.11 wireless LAN deployments. The material in this document has been approved by IEEE 802.11 and it is being presented as an IETF RFC for informational purposes. Working Group Summary This document was not produced by an IETF WG. Protocol Quality This document was reviewed for the IESG by Margaret Wasserman. ___ IETF-Announce mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf-announce
Last Call: 'Use of PE-PE GRE or IP in BGP/MPLS IP VPNs' to Proposed Standard
The IESG has received a request from the Layer 3 Virtual Private Networks WG to consider the following document: - 'Use of PE-PE GRE or IP in BGP/MPLS IP VPNs ' draft-ietf-l3vpn-gre-ip-2547-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 [EMAIL PROTECTED] or [EMAIL PROTECTED] mailing lists by 2004-09-10. The file can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-l3vpn-gre-ip-2547-02.txt ___ IETF-Announce mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf-announce
Document Action: 'Application Aspects of IPv6 Transition' to Informational RFC
The IESG has approved the following document: - 'Application Aspects of IPv6 Transition ' draft-ietf-v6ops-application-transition-03.txt as an Informational RFC This document is the product of the IPv6 Operations Working Group. The IESG contact persons are David Kessens and Bert Wijnen. Technical Summary As IPv6 networks are deployed and the network transition discussed, one should also consider how to enable IPv6 support in applications running on IPv6 hosts, and the best strategy to develop IP protocol support in applications. This document specifies scenarios and aspects of application transition. It also proposes guidelines on how to develop IP version-independent applications during the transition period. Working Group Summary This document is a product of the v6ops working group. Protocol Quality David Kessens reviewed this document for the IESG. This document was subject to a two week IETF last call and no comments were received. RFC Editor note: In Section 1, add as the second-to-last paragraph: In the context of this document, the term application covers all kinds of applications, but the focus is on those network applications which have been developed using relatively low-level APIs (such as the C language, using standard libraries). Many such applications could be command-line driven, but that is not a requirement. In section 2, rewrite: OLD: Note that this draft does not address DCCP and SCTP considerations at this phase. NEW: The first two cases are not interesting in the longer term; only few applications are inherently IPv4- or IPv6-specific, and should work with both protocols without having to care about which one is being used. Note that this memo does not address DCCP and SCTP considerations. In section 3.2: OLD: Hence an operational technique is to use service names in the DNS, that is, if a node is offering multiple services, but only some of them over IPv6, add a DNS name for each of these services (with the associated A/ records), not just a single name for the whole node, also including the records. NEW: Hence an operational technique is to use service names in the DNS, that is, if a node is offering multiple services, but only some of them over IPv6, add a DNS name for each of these services or group of services (with the associated A/ records), not just a single name for the physical machine, also including the records. Add as the 3rd paragraph in section 4: Note that the first two cases, IPv4-only and IPv6-only applications, are not interesting in the longer term; only few applications are inherently IPv4- or IPv6-specific, and should work with both protocols without having to care about which one is being used. ___ IETF-Announce mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf-announce
Protocol Action: 'Definitions of Managed Objects for Network Address Translators (NAT)' to Proposed Standard
The IESG has approved the following document:
- 'Definitions of Managed Objects for Network Address Translators (NAT) '
draft-ietf-nat-natmib-09.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 Allison Mankin.
Technical Summary
This document defines a portion of the Management Information Base (MIB) for
devices implementing Network Address Translator (NAT) function. This MIB
module may be used for configuration of specific aspects of the NAT function
(but in particular, not to configure NAT bindings). Firewall configuration, in
a NAT-firewall-combining device, is specifically outside the scope of this
document.
Working Group Summary
Although this document is an individual submission (developed largely after
closure of IETF's NAT working group, it was reviewed by the MIDCOM working
group. A good number of comments were received from MIDCOM participants.
Protocol Quality
This specification was reviewed for the IESG by Allison Mankin, Bert Wijnen,
and Juergen Schoenwaelder, of the MIB Doctors.
RFC Editor Notes
Section 3. Terminology
OLD:
Definitions for majority of the terms used throughout the document
may be found in RFC 2663 [RFC2663]. Additional terms that further
classify NAPT implementations are defined in RFC 3489 [RFC3489].
Listed below are terms used in this document
NEW:
Definitions for majority of the terms used throughout the document
may be found in RFC 2663 [RFC2663]. Additional terms that further
classify NAPT implementations are defined in RFC 3489 [RFC3489].
Listed below are terms used in this document
Address realm - An address realm is a realm of unique network
addresses that are routable within the realm. For example, an
enterprise address realm could be constituted of private IP
addresses in the ranges specified in RFC 1918 [RFC1918], which
are routable within the enterprise, but not across the Internet.
A public realm is constituted of globally unique network
addresses.
[And add RFC 1918 to the Informative References]
---
OLD:
NAT Session - A NAT session is an association between a session
as seen in the private realm and a session as seen in the public
realm, by virtue of NAT translation. If a session in the private
realm were to be represented as (PrivateSrcAddr, PrivateDstAddr,
TransportProtocol, PrivateSrcPort, PrivateDstPort) and the
same session in the public realm were to be represented as
(PublicSrcAddr, PublicDstAddr, TransportProtocol, PublicSrcPort,
PublicDstPort), the NAT session will provide the translation
glue between the two session representations.
NEW:
NAT Session - A NAT session is an association between a session
as seen in the private realm and a session as seen in the public
realm, by virtue of NAT translation. If a session in the private
realm were to be represented as (PrivateSrcAddr, PrivateDstAddr,
TransportProtocol, PrivateSrcPort, PrivateDstPort) and the
same session in the public realm were to be represented as
(PublicSrcAddr, PublicDstAddr, TransportProtocol, PublicSrcPort,
PublicDstPort), the NAT session will provide the translation
glue between the two session representations. NAT sessions in
the document are restricted to sessions based on TCP and UDP
only . In the future, NAT sessions may be extended to be based
on other transport protocols such as SCTP, UDP-lite and DCCP.
---
Section 5. Definitions
OLD:
natAddrBindEntry OBJECT-TYPE
SYNTAX NatAddrBindEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
Each entry in this table holds information about
an active address BIND. These entries are lost
upon agent restart.
INDEX { ifIndex, natAddrBindLocalAddrType, natAddrBindLocalAddr }
::= { natAddrBindTable 1 }
NEW:
natAddrBindEntry OBJECT-TYPE
SYNTAX NatAddrBindEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
Each entry in this table holds information about
an active address BIND. These entries are lost
upon agent restart.
This row has indexing which may create variables with
more than 128 subidentifiers. Implementers of this table
must be careful not to create entries that would result
in OIDs which exceed the 128 subidentifier limit.
Otherwise, the information cannot be accessed using
SNMPv1, SNMPv2c or SNMPv3.
INDEX { ifIndex, natAddrBindLocalAddrType, natAddrBindLocalAddr }
::= { natAddrBindTable 1 }
-
OLD:
natAddrBindLocalAddr OBJECT-TYPE
SYNTAX InetAddress
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
This object represents the private-realm specific network
layer address, which maps
Last Call: 'GMPLS Signaling Procedure For Egress Control' to None
The IESG has received a request from the Common Control and Measurement Plane WG to consider the following document: - 'GMPLS Signaling Procedure For Egress Control ' draft-ietf-ccamp-gmpls-egress-control-03.txt as a None 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 [EMAIL PROTECTED] or [EMAIL PROTECTED] mailing lists by 2004-09-15. The file can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-egress-control-03.txt ___ IETF-Announce mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf-announce
