RFC 5216 on The EAP-TLS Authentication Protocol

2008-03-21 Thread rfc-editor

A new Request for Comments is now available in online RFC libraries.


RFC 5216

Title:  The EAP-TLS Authentication Protocol 
Author: D. Simon, B. Aboba, R. Hurst
Status: Standards Track
Date:   March 2008
Mailbox:[EMAIL PROTECTED], 
[EMAIL PROTECTED], 
[EMAIL PROTECTED]
Pages:  34
Characters: 71599
Obsoletes:  RFC2716

I-D Tag:draft-simon-emu-rfc2716bis-13.txt

URL:http://www.rfc-editor.org/rfc/rfc5216.txt

The Extensible Authentication Protocol (EAP), defined in RFC 3748,
provides support for multiple authentication methods.  Transport
Layer Security (TLS) provides for mutual authentication,
integrity-protected ciphersuite negotiation, and key exchange between
two endpoints.  This document defines EAP-TLS, which includes support for
certificate-based mutual authentication and key derivation.

This document obsoletes RFC 2716.  A summary of the changes between
this document and RFC 2716 is available in Appendix A.  [STANDARDS TRACK]

This document is a product of the EAP Method Update Working Group of the IETF.

This is now a Proposed Standard Protocol.

STANDARDS TRACK: This document specifies an Internet standards track
protocol for the Internet community,and requests discussion and suggestions
for improvements.  Please refer to the current edition of the Internet
Official Protocol Standards (STD 1) for the standardization state and
status of this protocol.  Distribution of this memo is unlimited.

This announcement is sent to the IETF list and the RFC-DIST list.
Requests to be added to or deleted from the IETF distribution list
should be sent to [EMAIL PROTECTED]  Requests to be
added to or deleted from the RFC-DIST distribution list should
be sent to [EMAIL PROTECTED]

Details on obtaining RFCs via FTP or EMAIL may be obtained by sending
an EMAIL message to [EMAIL PROTECTED] with the message body 

help: ways_to_get_rfcs. For example:

To: [EMAIL PROTECTED]
Subject: getting rfcs

help: ways_to_get_rfcs

Requests for special distribution should be addressed to either the
author of the RFC in question, or to [EMAIL PROTECTED]  Unless
specifically noted otherwise on the RFC itself, all RFCs are for
unlimited distribution.

Submissions for Requests for Comments should be sent to
[EMAIL PROTECTED]  Please consult RFC 2223, Instructions to RFC
Authors, for further information.


The RFC Editor Team
USC/Information Sciences Institute

...


___
IETF-Announce mailing list
IETF-Announce@ietf.org
https://www.ietf.org/mailman/listinfo/ietf-announce


RFC 5214 on Intra-Site Automatic Tunnel Addressing Protocol (ISATAP)

2008-03-21 Thread rfc-editor

A new Request for Comments is now available in online RFC libraries.


RFC 5214

Title:  Intra-Site Automatic Tunnel Addressing Protocol 
(ISATAP) 
Author: F. Templin, T. Gleeson, D. Thaler
Status: Informational
Date:   March 2008
Mailbox:[EMAIL PROTECTED], 
[EMAIL PROTECTED], 
[EMAIL PROTECTED]
Pages:  15
Characters: 30126
Obsoletes:  RFC4214

I-D Tag:draft-templin-rfc4214bis-05.txt

URL:http://www.rfc-editor.org/rfc/rfc5214.txt

The Intra-Site Automatic Tunnel Addressing Protocol (ISATAP) connects
dual-stack (IPv6/IPv4) nodes over IPv4 networks.  ISATAP views the
IPv4 network as a link layer for IPv6 and supports an automatic
tunneling abstraction similar to the Non-Broadcast Multiple Access
(NBMA) model.  This memo provides information for the Internet community.


INFORMATIONAL: This memo provides information for the Internet community.
It does not specify an Internet standard of any kind. Distribution of
this memo is unlimited.

This announcement is sent to the IETF list and the RFC-DIST list.
Requests to be added to or deleted from the IETF distribution list
should be sent to [EMAIL PROTECTED]  Requests to be
added to or deleted from the RFC-DIST distribution list should
be sent to [EMAIL PROTECTED]

Details on obtaining RFCs via FTP or EMAIL may be obtained by sending
an EMAIL message to [EMAIL PROTECTED] with the message body 

help: ways_to_get_rfcs. For example:

To: [EMAIL PROTECTED]
Subject: getting rfcs

help: ways_to_get_rfcs

Requests for special distribution should be addressed to either the
author of the RFC in question, or to [EMAIL PROTECTED]  Unless
specifically noted otherwise on the RFC itself, all RFCs are for
unlimited distribution.

Submissions for Requests for Comments should be sent to
[EMAIL PROTECTED]  Please consult RFC 2223, Instructions to RFC
Authors, for further information.


The RFC Editor Team
USC/Information Sciences Institute

...


___
IETF-Announce mailing list
IETF-Announce@ietf.org
https://www.ietf.org/mailman/listinfo/ietf-announce


RFC 5182 on IMAP Extension for Referencing the Last SEARCH Result

2008-03-21 Thread rfc-editor

A new Request for Comments is now available in online RFC libraries.


RFC 5182

Title:  IMAP Extension for Referencing the 
Last SEARCH Result 
Author: A. Melnikov
Status: Standards Track
Date:   March 2008
Mailbox:[EMAIL PROTECTED]
Pages:  13
Characters: 24520
Updates:RFC3501

I-D Tag:draft-melnikov-imap-search-res-07.txt

URL:http://www.rfc-editor.org/rfc/rfc5182.txt

Many IMAP clients use the result of a SEARCH command as the input to
perform another operation, for example, fetching the found messages,
deleting them, or copying them to another mailbox.

This can be achieved using standard IMAP operations described in RFC
3501; however, this would be suboptimal.  The server will send the list
of found messages to the client; after that, the client will have to
parse the list, reformat it, and send it back to the server.  The
client can't pipeline the SEARCH command with the subsequent command,
and, as a result, the server might not be able to perform some
optimizations.

This document proposes an IMAP extension that allows a client to tell
a server to use the result of a SEARCH (or Unique Identifier (UID)
SEARCH) command as an input to any subsequent command.  [STANDARDS TRACK]

This is now a Proposed Standard Protocol.

STANDARDS TRACK: This document specifies an Internet standards track
protocol for the Internet community,and requests discussion and suggestions
for improvements.  Please refer to the current edition of the Internet
Official Protocol Standards (STD 1) for the standardization state and
status of this protocol.  Distribution of this memo is unlimited.

This announcement is sent to the IETF list and the RFC-DIST list.
Requests to be added to or deleted from the IETF distribution list
should be sent to [EMAIL PROTECTED]  Requests to be
added to or deleted from the RFC-DIST distribution list should
be sent to [EMAIL PROTECTED]

Details on obtaining RFCs via FTP or EMAIL may be obtained by sending
an EMAIL message to [EMAIL PROTECTED] with the message body 

help: ways_to_get_rfcs. For example:

To: [EMAIL PROTECTED]
Subject: getting rfcs

help: ways_to_get_rfcs

Requests for special distribution should be addressed to either the
author of the RFC in question, or to [EMAIL PROTECTED]  Unless
specifically noted otherwise on the RFC itself, all RFCs are for
unlimited distribution.

Submissions for Requests for Comments should be sent to
[EMAIL PROTECTED]  Please consult RFC 2223, Instructions to RFC
Authors, for further information.


The RFC Editor Team
USC/Information Sciences Institute

...


___
IETF-Announce mailing list
IETF-Announce@ietf.org
https://www.ietf.org/mailman/listinfo/ietf-announce


RFC 5166 on Metrics for the Evaluation of Congestion Control Mechanisms

2008-03-21 Thread rfc-editor

A new Request for Comments is now available in online RFC libraries.


RFC 5166

Title:  Metrics for the Evaluation of 
Congestion Control Mechanisms 
Author: S. Floyd, Ed.
Status: Informational
Date:   March 2008
Mailbox:[EMAIL PROTECTED]
Pages:  23
Characters: 53609
Updates/Obsoletes/SeeAlso:   None

I-D Tag:draft-irtf-tmrg-metrics-11.txt

URL:http://www.rfc-editor.org/rfc/rfc5166.txt

This document discusses the metrics to be considered in an
evaluation of new or modified congestion control mechanisms for the
Internet.  These include metrics for the evaluation of new transport
protocols, of proposed modifications to TCP, of application-level
congestion control, and of Active Queue Management (AQM) mechanisms
in the router.  This document is the first in a series of documents
aimed at improving the models that we use in the evaluation of
transport protocols.

This document is a product of the Transport Modeling Research Group
(TMRG), and has received detailed feedback from many members of the
Research Group (RG).  As the document tries to make clear, there is
not necessarily a consensus within the research community (or the
IETF community, the vendor community, the operations community, or
any other community) about the metrics that congestion control
mechanisms should be designed to optimize, in terms of trade-offs
between throughput and delay, fairness between competing flows, and
the like.  However, we believe that there is a clear consensus that
congestion control mechanisms should be evaluated in terms of
trade-offs between a range of metrics, rather than in terms of
optimizing for a single metric.  This memo provides information for the 
Internet community.

This document is a product of the IRTF Working Group of the IETF.


INFORMATIONAL: This memo provides information for the Internet community.
It does not specify an Internet standard of any kind. Distribution of
this memo is unlimited.

This announcement is sent to the IETF list and the RFC-DIST list.
Requests to be added to or deleted from the IETF distribution list
should be sent to [EMAIL PROTECTED]  Requests to be
added to or deleted from the RFC-DIST distribution list should
be sent to [EMAIL PROTECTED]

Details on obtaining RFCs via FTP or EMAIL may be obtained by sending
an EMAIL message to [EMAIL PROTECTED] with the message body 

help: ways_to_get_rfcs. For example:

To: [EMAIL PROTECTED]
Subject: getting rfcs

help: ways_to_get_rfcs

Requests for special distribution should be addressed to either the
author of the RFC in question, or to [EMAIL PROTECTED]  Unless
specifically noted otherwise on the RFC itself, all RFCs are for
unlimited distribution.

Submissions for Requests for Comments should be sent to
[EMAIL PROTECTED]  Please consult RFC 2223, Instructions to RFC
Authors, for further information.


The RFC Editor Team
USC/Information Sciences Institute

...


___
IETF-Announce mailing list
IETF-Announce@ietf.org
https://www.ietf.org/mailman/listinfo/ietf-announce


RFC 5146 on Interworking Requirements to Support Operation of MPLS-TE over GMPLS Networks

2008-03-21 Thread rfc-editor

A new Request for Comments is now available in online RFC libraries.


RFC 5146

Title:  Interworking Requirements to Support Operation 
of MPLS-TE over GMPLS Networks 
Author: K. Kumaki, Ed.
Status: Informational
Date:   March 2008
Mailbox:[EMAIL PROTECTED]
Pages:  15
Characters: 31624
Updates/Obsoletes/SeeAlso:   None

I-D Tag:draft-ietf-ccamp-mpls-gmpls-interwork-reqts-04.txt

URL:http://www.rfc-editor.org/rfc/rfc5146.txt

Operation of a Multiprotocol Label Switching (MPLS) traffic
engineering (TE) network as a client network to a Generalized MPLS
(GMPLS) network has enhanced operational capabilities compared to
those provided by a coexistent protocol model (i.e., operation of
MPLS-TE over an independently managed transport layer).

The GMPLS network may be a packet or a non-packet network, and may
itself be a multi-layer network supporting both packet and non-packet
technologies.  An MPLS-TE Label Switched Path (LSP) originates and
terminates on an MPLS Label Switching Router (LSR).  The GMPLS network
provides transparent transport for the end-to-end MPLS-TE LSP.

This document describes a framework and Service Provider requirements
for operating MPLS-TE networks over GMPLS networks.  This memo provides 
information for the Internet community.

This document is a product of the Common Control and Measurement Plane Working 
Group of the IETF.


INFORMATIONAL: This memo provides information for the Internet community.
It does not specify an Internet standard of any kind. Distribution of
this memo is unlimited.

This announcement is sent to the IETF list and the RFC-DIST list.
Requests to be added to or deleted from the IETF distribution list
should be sent to [EMAIL PROTECTED]  Requests to be
added to or deleted from the RFC-DIST distribution list should
be sent to [EMAIL PROTECTED]

Details on obtaining RFCs via FTP or EMAIL may be obtained by sending
an EMAIL message to [EMAIL PROTECTED] with the message body 

help: ways_to_get_rfcs. For example:

To: [EMAIL PROTECTED]
Subject: getting rfcs

help: ways_to_get_rfcs

Requests for special distribution should be addressed to either the
author of the RFC in question, or to [EMAIL PROTECTED]  Unless
specifically noted otherwise on the RFC itself, all RFCs are for
unlimited distribution.

Submissions for Requests for Comments should be sent to
[EMAIL PROTECTED]  Please consult RFC 2223, Instructions to RFC
Authors, for further information.


The RFC Editor Team
USC/Information Sciences Institute

...


___
IETF-Announce mailing list
IETF-Announce@ietf.org
https://www.ietf.org/mailman/listinfo/ietf-announce


RFC 5145 on Framework for MPLS-TE to GMPLS Migration

2008-03-21 Thread rfc-editor

A new Request for Comments is now available in online RFC libraries.


RFC 5145

Title:  Framework for MPLS-TE to GMPLS 
Migration 
Author: K. Shiomoto, Ed.
Status: Informational
Date:   March 2008
Mailbox:[EMAIL PROTECTED]
Pages:  19
Characters: 44646
Updates/Obsoletes/SeeAlso:   None

I-D Tag:draft-ietf-ccamp-mpls-gmpls-interwork-fmwk-05.txt

URL:http://www.rfc-editor.org/rfc/rfc5145.txt

The migration from Multiprotocol Label Switching (MPLS) Traffic
Engineering (TE) to Generalized MPLS (GMPLS) is the process of
evolving an MPLS-TE control plane to a GMPLS control plane.  An
appropriate migration strategy will be selected based on various
factors including the service provider's network deployment plan,
customer demand, and operational policy.

This document presents several migration models and strategies for
migrating from MPLS-TE to GMPLS.  In the course of migration, MPLS-TE
and GMPLS devices, or networks, may coexist that may require
interworking between MPLS-TE and GMPLS protocols.  Aspects of the
required interworking are discussed as it will influence the choice
of a migration strategy.  This framework document provides a migration
toolkit to aid the operator in selection of an appropriate strategy.

This framework document also lists a set of solutions that may aid in
interworking, and highlights a set of potential issues.  This memo provides 
information for the Internet community.

This document is a product of the Common Control and Measurement Plane Working 
Group of the IETF.


INFORMATIONAL: This memo provides information for the Internet community.
It does not specify an Internet standard of any kind. Distribution of
this memo is unlimited.

This announcement is sent to the IETF list and the RFC-DIST list.
Requests to be added to or deleted from the IETF distribution list
should be sent to [EMAIL PROTECTED]  Requests to be
added to or deleted from the RFC-DIST distribution list should
be sent to [EMAIL PROTECTED]

Details on obtaining RFCs via FTP or EMAIL may be obtained by sending
an EMAIL message to [EMAIL PROTECTED] with the message body 

help: ways_to_get_rfcs. For example:

To: [EMAIL PROTECTED]
Subject: getting rfcs

help: ways_to_get_rfcs

Requests for special distribution should be addressed to either the
author of the RFC in question, or to [EMAIL PROTECTED]  Unless
specifically noted otherwise on the RFC itself, all RFCs are for
unlimited distribution.

Submissions for Requests for Comments should be sent to
[EMAIL PROTECTED]  Please consult RFC 2223, Instructions to RFC
Authors, for further information.


The RFC Editor Team
USC/Information Sciences Institute

...


___
IETF-Announce mailing list
IETF-Announce@ietf.org
https://www.ietf.org/mailman/listinfo/ietf-announce


RFC 5141 on A Uniform Resource Name (URN) Namespace for the International Organization for Standardization (ISO)

2008-03-21 Thread rfc-editor

A new Request for Comments is now available in online RFC libraries.


RFC 5141

Title:  A Uniform Resource Name (URN) 
Namespace for the International Organization for 
Standardization (ISO) 
Author: J. Goodwin, H. Apel
Status: Informational
Date:   March 2008
Mailbox:[EMAIL PROTECTED], 
[EMAIL PROTECTED]
Pages:  28
Characters: 57820
Updates/Obsoletes/SeeAlso:   None

I-D Tag:draft-goodwin-iso-urn-03.txt

URL:http://www.rfc-editor.org/rfc/rfc5141.txt

This document describes a Uniform Resource Name Namespace
Identification (URN NID) for the International Organization for
Standardization (ISO).  This URN NID is intended for use for the
identification of persistent resources published by the ISO standards
body (including documents, document metadata, extracted resources
such as standard schemata and standard value sets, and other
resources).  This memo provides information for the Internet community.


INFORMATIONAL: This memo provides information for the Internet community.
It does not specify an Internet standard of any kind. Distribution of
this memo is unlimited.

This announcement is sent to the IETF list and the RFC-DIST list.
Requests to be added to or deleted from the IETF distribution list
should be sent to [EMAIL PROTECTED]  Requests to be
added to or deleted from the RFC-DIST distribution list should
be sent to [EMAIL PROTECTED]

Details on obtaining RFCs via FTP or EMAIL may be obtained by sending
an EMAIL message to [EMAIL PROTECTED] with the message body 

help: ways_to_get_rfcs. For example:

To: [EMAIL PROTECTED]
Subject: getting rfcs

help: ways_to_get_rfcs

Requests for special distribution should be addressed to either the
author of the RFC in question, or to [EMAIL PROTECTED]  Unless
specifically noted otherwise on the RFC itself, all RFCs are for
unlimited distribution.

Submissions for Requests for Comments should be sent to
[EMAIL PROTECTED]  Please consult RFC 2223, Instructions to RFC
Authors, for further information.


The RFC Editor Team
USC/Information Sciences Institute

...


___
IETF-Announce mailing list
IETF-Announce@ietf.org
https://www.ietf.org/mailman/listinfo/ietf-announce


Protocol Action: 'Sieve Email Filtering: Body Extension' to Proposed Standard

2008-03-21 Thread The IESG
The IESG has approved the following document:

- 'Sieve Email Filtering: Body Extension '
as a Proposed Standard

This document is the product of the Sieve Mail Filtering Language Working 
Group. 

The IESG contact persons are Lisa Dusseault and Chris Newman.

A URL of this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-sieve-body-09.txt

Technical Summary
 
The SIEVE body extension adds tests for the occurrence of one or more
strings in the body of an email message.

The draft has a detailed description of how interactions with other
SIEVE extensions/actions are handled.

The security considerations section covers several identified security
concerns.

Working Group Summary

This document has been discussed and reviewed in the SIEVE Working Group.
There is strong consensus in the Working Group to publish this document
as a Proposed Standard.

Document Quality

A number of implementations of this extension have already been
developed and in some cases deployed. Most participants are eager to see
this specification published as an RFC.

Lisa Dusseault reviewed this spec for the IESG.

Document Shepherd: Cyrus Daboo 

___
IETF-Announce mailing list
IETF-Announce@ietf.org
https://www.ietf.org/mailman/listinfo/ietf-announce


ISI Being Extended 1 Year as RFC Editor

2008-03-21 Thread IETF Administrative Director
The IAOC is pleased to announce that the Internet Society on its behalf
has signed a Letter of Intent with the University of Southern California
to conclude terms with the Information Sciences Institute to renew its
contract as RFC Editor.  Assuming terms can be reached, the contract
renewal would begin on January 1, 2009 and run for one year.

After briefing the IAB and obtaining their support for this direction, as
part of the IAB's RFC Editor oversight role, the IAOC has engaged in
further discussions with ISI in furtherance of the agreement. 

It is anticipated that the renewal agreement will be concluded by July. 

Ray Pelletier
IAD
___
IETF-Announce mailing list
IETF-Announce@ietf.org
https://www.ietf.org/mailman/listinfo/ietf-announce