[rfc-dist] RFC 3751 on Omniscience Protocol Requirements

[rfc-editor at rfc-editor.org ([e-mail])]

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


        RFC 3751

        Title:      Omniscience Protocol Requirements
        Author(s):  S. Bradner
        Status:     Informational
        Date:       1 April 2004
        Mailbox:    [e-mail]
        Pages:      9
        Characters: 20771
        Updates/Obsoletes/SeeAlso:    None

        I-D Tag:    draft-bradner-op-req-01.txt

        URL:        ftp://ftp.rfc-editor.org/in-notes/rfc3751.txt


There have been a number of legislative initiatives in the U.S. and
elsewhere over the past few years to use the Internet to actively
interfere with allegedly illegal activities of Internet users.  This
memo proposes a number of requirements for a new protocol, the
Omniscience Protocol, that could be used to enable such efforts.

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 [e-mail].  Requests to be
added to or deleted from the RFC-DIST distribution list should
be sent to [e-mail].

Details on obtaining RFCs via FTP or EMAIL may be obtained by sending
an EMAIL message to [e-mail] with the message body 
help: ways_to_get_rfcs.  For example:

        To: [e-mail]
        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 [e-mail].  Unless
specifically noted otherwise on the RFC itself, all RFCs are for
unlimited distribution.echo 
Submissions for Requests for Comments should be sent to
[e-mail].  Please consult RFC 2223, Instructions to RFC
Authors, for further information.


Joyce K. Reynolds and Sandy Ginoza
USC/Information Sciences Institute

...

Below is the data which will enable a MIME compliant Mail Reader 
implementation to automatically retrieve the ASCII version
of the RFCs.
-------------- next part --------------
Skipped content of type multipart/alternative
From rfc-editor at rfc-editor.org  Wed Apr  7 15:17:39 2004
From: rfc-editor at rfc-editor.org ([e-mail])
Date: Fri Apr  9 11:17:49 2004
Subject: [rfc-dist] RFC 3736 on Stateless Dynamic Host Configuration
	Protocol (DHCP) Service for IPv6
Message-ID: <[e-mail]>


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


        RFC 3736

        Title:      Stateless Dynamic Host Configuration Protocol
                    (DHCP) Service for IPv6
        Author(s):  R. Droms
        Status:     Standards Track
        Date:       April 2004
        Mailbox:    [e-mail]
        Pages:      9
        Characters: 18510
        Updates/Obsoletes/SeeAlso:    None

        I-D Tag:    draft-ietf-dhc-dhcpv6-stateless-04.txt

        URL:        ftp://ftp.rfc-editor.org/in-notes/rfc3736.txt


Stateless Dynamic Host Configuration Protocol service for IPv6
(DHCPv6) is used by nodes to obtain configuration information, such as
the addresses of DNS recursive name servers, that does not require the
maintenance of any dynamic state for individual clients.  A node that
uses stateless DHCP must have obtained its IPv6 addresses through some
other mechanism, typically stateless address autoconfiguration.  This
document explains which parts of RFC 3315 must be implemented in each
of the different kinds of DHCP agents so that agent can support
stateless DHCP.

This document is a product of the Dynamic Host Configuration Working
Group of the IETF.

This is now a Proposed Standard Protocol.

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

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

Details on obtaining RFCs via FTP or EMAIL may be obtained by sending
an EMAIL message to [e-mail] with the message body 
help: ways_to_get_rfcs.  For example:

        To: [e-mail]
        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 [e-mail].  Unless
specifically noted otherwise on the RFC itself, all RFCs are for
unlimited distribution.echo 
Submissions for Requests for Comments should be sent to
[e-mail].  Please consult RFC 2223, Instructions to RFC
Authors, for further information.


Joyce K. Reynolds and Sandy Ginoza
USC/Information Sciences Institute

...

Below is the data which will enable a MIME compliant Mail Reader 
implementation to automatically retrieve the ASCII version
of the RFCs.
-------------- next part --------------
Skipped content of type multipart/alternative
From rfc-editor at rfc-editor.org  Wed Apr  7 15:19:38 2004
From: rfc-editor at rfc-editor.org ([e-mail])
Date: Fri Apr  9 11:17:54 2004
Subject: [rfc-dist] RFC 3737 on IANA Guidelines for the Registry of Remote
	Monitoring (RMON) MIB modules
Message-ID: <[e-mail]>


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


        RFC 3737

        Title:      IANA Guidelines for the Registry of
                    Remote Monitoring (RMON) MIB modules
        Author(s):  B. Wijnen, A. Bierman
        Status:     Standards Track
        Date:       April 2004
        Mailbox:    [e-mail], [e-mail]
        Pages:      7
        Characters: 13127
        Updates/Obsoletes/SeeAlso:    None

        I-D Tag:    draft-ietf-rmonmib-rmon-oid-assignments-01.txt

        URL:        ftp://ftp.rfc-editor.org/in-notes/rfc3737.txt


This document defines the procedures for IANA to administer and
maintain the Object Identifier (OID) tree under the Remote Monitoring
(rmon) root.  This memo also documents the currently assigned values.

This document is a product of the Remote Network Monitoring Working
Group of the IETF.

This is now a Proposed Standard Protocol.

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

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

Details on obtaining RFCs via FTP or EMAIL may be obtained by sending
an EMAIL message to [e-mail] with the message body 
help: ways_to_get_rfcs.  For example:

        To: [e-mail]
        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 [e-mail].  Unless
specifically noted otherwise on the RFC itself, all RFCs are for
unlimited distribution.echo 
Submissions for Requests for Comments should be sent to
[e-mail].  Please consult RFC 2223, Instructions to RFC
Authors, for further information.


Joyce K. Reynolds and Sandy Ginoza
USC/Information Sciences Institute

...

Below is the data which will enable a MIME compliant Mail Reader 
implementation to automatically retrieve the ASCII version
of the RFCs.
-------------- next part --------------
Skipped content of type multipart/alternative
From rfc-editor at rfc-editor.org  Wed Apr  7 15:21:03 2004
From: rfc-editor at rfc-editor.org ([e-mail])
Date: Fri Apr  9 11:17:58 2004
Subject: [rfc-dist] RFC 3745 on MIME Type Registrations for JPEG 2000
	(ISO/IEC 15444)
Message-ID: <[e-mail]>


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


        RFC 3745

        Title:      MIME Type Registrations for JPEG 2000
                    (ISO/IEC 15444)
        Author(s):  D. Singer, R. Clark, D. Lee
        Status:     Standards Track
        Date:       April 2004
        Mailbox:    [e-mail], [e-mail],
                    [e-mail]
        Pages:      14
        Characters: 31224
        Updates/Obsoletes/SeeAlso:    None

        I-D Tag:    draft-singer-jp2-02.txt

        URL:        ftp://ftp.rfc-editor.org/in-notes/rfc3745.txt


This is now a Proposed Standard Protocol.

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

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

Details on obtaining RFCs via FTP or EMAIL may be obtained by sending
an EMAIL message to [e-mail] with the message body 
help: ways_to_get_rfcs.  For example:

        To: [e-mail]
        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 [e-mail].  Unless
specifically noted otherwise on the RFC itself, all RFCs are for
unlimited distribution.echo 
Submissions for Requests for Comments should be sent to
[e-mail].  Please consult RFC 2223, Instructions to RFC
Authors, for further information.


Joyce K. Reynolds and Sandy Ginoza
USC/Information Sciences Institute

...

Below is the data which will enable a MIME compliant Mail Reader 
implementation to automatically retrieve the ASCII version
of the RFCs.
-------------- next part --------------
Skipped content of type multipart/alternative
From rfc-editor at rfc-editor.org  Tue Apr 13 16:18:16 2004
From: rfc-editor at rfc-editor.org ([e-mail])
Date: Tue Apr 13 16:19:06 2004
Subject: [rfc-dist] BCP 85,
	RFC 3725 on Best Current Practices for Third Party Call
	Control (3pcc) in the Session Initiation Protocol (SIP)
Message-ID: <[e-mail]>


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


        BCP 85
        RFC 3725

        Title:      Best Current Practices for Third Party Call
                    Control (3pcc) in the Session Initiation Protocol
                    (SIP)
        Author(s):  J. Rosenberg, J. Peterson, H. Schulzrinne,
                    G. Camarillo
        Status:     Best Current Practice
        Date:       April 2004
        Mailbox:    [e-mail], [e-mail],
                    [e-mail]
        Pages:      31
        Characters: 77308
        SeeAlso:    BCP 85

        I-D Tag:    draft-ietf-sipping-3pcc-06.txt

        URL:        ftp://ftp.rfc-editor.org/in-notes/rfc3725.txt


Third party call control refers to the ability of one entity to
create a call in which communication is actually between other
parties.  Third party call control is possible using the mechanisms
specified within the Session Initiation Protocol (SIP).  However,
there are several possible approaches, each with different benefits
and drawbacks.  This document discusses best current practices for the
usage of SIP for third party call control.

This document is a product of the Session Initiation Proposal
Investigation Working Group of the IETF.

This document specifies an Internet Best Current Practices for the
Internet Community, and requests discussion and suggestions for
improvements.  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 [e-mail].  Requests to be
added to or deleted from the RFC-DIST distribution list should
be sent to [e-mail].

Details on obtaining RFCs via FTP or EMAIL may be obtained by sending
an EMAIL message to [e-mail] with the message body 
help: ways_to_get_rfcs.  For example:

        To: [e-mail]
        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 [e-mail].  Unless
specifically noted otherwise on the RFC itself, all RFCs are for
unlimited distribution.echo 
Submissions for Requests for Comments should be sent to
[e-mail].  Please consult RFC 2223, Instructions to RFC
Authors, for further information.


Joyce K. Reynolds and Sandy Ginoza
USC/Information Sciences Institute

...

Below is the data which will enable a MIME compliant Mail Reader 
implementation to automatically retrieve the ASCII version
of the RFCs.
-------------- next part --------------
Skipped content of type multipart/alternative
From rfc-editor at rfc-editor.org  Tue Apr 13 16:21:06 2004
From: rfc-editor at rfc-editor.org ([e-mail])
Date: Tue Apr 13 16:22:02 2004
Subject: [rfc-dist] RFC 3747 on The Differentiated Services Configuration MIB
Message-ID: <[e-mail]>


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


        RFC 3747

        Title:      The Differentiated Services Configuration MIB
        Author(s):  H. Hazewinkel, Ed., D. Partain, Ed.
        Status:     Standards Track
        Date:       April 2004
        Mailbox:    [e-mail], [e-mail]
        Pages:      24
        Characters: 51659
        Updates/Obsoletes/SeeAlso:    None

        I-D Tag:    draft-ietf-snmpconf-diffpolicy-09.txt

        URL:        ftp://ftp.rfc-editor.org/in-notes/rfc3747.txt


This memo describes a MIB module that provides a conceptual layer
between high-level "network-wide" policy definitions that effect
configuration of the Differentiated Services (diffserv) subsystem and
the instance-specific information that would include such details as
the parameters for all the queues associated with each interface in a
system.  This essentially provides an interface for configuring
differentiated services at a conceptually higher layer than that of
the Differentiated Services MIB.

This document is a product of the Configuration Management with SNMP
Working Group of the IETF.

This is now a Proposed Standard Protocol.

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

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

Details on obtaining RFCs via FTP or EMAIL may be obtained by sending
an EMAIL message to [e-mail] with the message body 
help: ways_to_get_rfcs.  For example:

        To: [e-mail]
        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 [e-mail].  Unless
specifically noted otherwise on the RFC itself, all RFCs are for
unlimited distribution.echo 
Submissions for Requests for Comments should be sent to
[e-mail].  Please consult RFC 2223, Instructions to RFC
Authors, for further information.


Joyce K. Reynolds and Sandy Ginoza
USC/Information Sciences Institute

...

Below is the data which will enable a MIME compliant Mail Reader 
implementation to automatically retrieve the ASCII version
of the RFCs.
-------------- next part --------------
Skipped content of type multipart/alternative
From rfc-editor at rfc-editor.org  Tue Apr 13 16:22:51 2004
From: rfc-editor at rfc-editor.org ([e-mail])
Date: Tue Apr 13 16:23:03 2004
Subject: [rfc-dist] RFC 3750 on Unmanaged Networks IPv6 Transition Scenarios
Message-ID: <[e-mail]>


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


        RFC 3750

        Title:      Unmanaged Networks IPv6 Transition Scenarios
        Author(s):  C. Huitema, R. Austein, S. Satapati,
                    R. van der Pol
        Status:     Informational
        Date:       April 2004
        Mailbox:    [e-mail], [e-mail],
                    [e-mail], [e-mail]
        Pages:      20
        Characters: 48153
        Updates/Obsoletes/SeeAlso:    None

        I-D Tag:    draft-ietf-v6ops-unman-scenarios-03.txt

        URL:        ftp://ftp.rfc-editor.org/in-notes/rfc3750.txt


This document defines the scenarios in which IPv6 transition
mechanisms are to be used in unmanaged networks.  In order to evaluate
the suitability of these mechanisms, we need to define the scenarios
in which these mechanisms have to be used.  One specific scope is the
"unmanaged network", which typically corresponds to a home or small
office network.  The scenarios are specific to a single subnet, and
are defined in terms of IP connectivity supported by the gateway and
the Internet Service Provider (ISP).  We first examine the generic 
requirements of four classes of applications: local, client, peer to
peer and server.  Then, for each scenario, we infer transition
requirements by analyzing the needs for smooth migration of
applications from IPv4 to IPv6.

This document is a product of the IPv6 Operations Working Group of the
IETF.

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 [e-mail].  Requests to be
added to or deleted from the RFC-DIST distribution list should
be sent to [e-mail].

Details on obtaining RFCs via FTP or EMAIL may be obtained by sending
an EMAIL message to [e-mail] with the message body 
help: ways_to_get_rfcs.  For example:

        To: [e-mail]
        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 [e-mail].  Unless
specifically noted otherwise on the RFC itself, all RFCs are for
unlimited distribution.echo 
Submissions for Requests for Comments should be sent to
[e-mail].  Please consult RFC 2223, Instructions to RFC
Authors, for further information.


Joyce K. Reynolds and Sandy Ginoza
USC/Information Sciences Institute

...

Below is the data which will enable a MIME compliant Mail Reader 
implementation to automatically retrieve the ASCII version
of the RFCs.
-------------- next part --------------
Skipped content of type multipart/alternative
From rfc-editor at rfc-editor.org  Tue Apr 13 16:24:33 2004
From: rfc-editor at rfc-editor.org ([e-mail])
Date: Tue Apr 13 16:25:06 2004
Subject: [rfc-dist] RFC 3765 on NOPEER Community for Border Gateway Protocol
	(BGP) Route Scope Control
Message-ID: <[e-mail]>


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


        RFC 3765

        Title:      NOPEER Community for Border Gateway Protocol (BGP)
                    Route Scope Control
        Author(s):  G. Huston
        Status:     Informational
        Date:       April 2004
        Mailbox:    [e-mail]
        Pages:      7
        Characters: 16500
        Updates/Obsoletes/SeeAlso:    None

        I-D Tag:    draft-ietf-ptomaine-nopeer-03.txt

        URL:        ftp://ftp.rfc-editor.org/in-notes/rfc3765.txt


This document describes the use of a scope control Border Gateway
Protocol (BGP) community.  This well-known advisory transitive
community allows an origin AS to specify the extent to which a
specific route should be externally propagated.  In particular this
community, NOPEER, allows an origin AS to specify that a route with
this attribute need not be advertised across bilateral peer
connections.

This document is a product of the Prefix Taxonomy Ongoing Measurement
& Inter Network Experiment Working Group of the IETF.

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 [e-mail].  Requests to be
added to or deleted from the RFC-DIST distribution list should
be sent to [e-mail].

Details on obtaining RFCs via FTP or EMAIL may be obtained by sending
an EMAIL message to [e-mail] with the message body 
help: ways_to_get_rfcs.  For example:

        To: [e-mail]
        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 [e-mail].  Unless
specifically noted otherwise on the RFC itself, all RFCs are for
unlimited distribution.echo 
Submissions for Requests for Comments should be sent to
[e-mail].  Please consult RFC 2223, Instructions to RFC
Authors, for further information.


Joyce K. Reynolds and Sandy Ginoza
USC/Information Sciences Institute

...

Below is the data which will enable a MIME compliant Mail Reader 
implementation to automatically retrieve the ASCII version
of the RFCs.
-------------- next part --------------
Skipped content of type multipart/alternative
From rfc-editor at rfc-editor.org  Wed Apr 14 16:48:17 2004
From: rfc-editor at rfc-editor.org ([e-mail])
Date: Wed Apr 14 16:48:42 2004
Subject: [rfc-dist] RFC 3743 on Joint Engineering Team (JET) Guidelines for
	Internationalized Domain Names (IDN) Registration and
	Administration for Chinese, Japanese, and Korean
Message-ID: <[e-mail]>


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


        RFC 3743

        Title:      Joint Engineering Team (JET) Guidelines for
                    Internationalized Domain Names (IDN) Registration
                    and Administration for Chinese, Japanese, and
                    Korean
        Author(s):  K. Konishi, K. Huang, H. Qian, Y. Ko
        Status:     Informational
        Date:       April 2004
        Mailbox:    [e-mail], [e-mail],
                    [e-mail], [e-mail]
        Pages:      33
        Characters: 74963
        Updates/Obsoletes/SeeAlso:    None

        I-D Tag:    draft-jseng-idn-admin-05.txt

        URL:        ftp://ftp.rfc-editor.org/in-notes/rfc3743.txt


Achieving internationalized access to domain names raises many complex
issues.  These are associated not only with basic protocol design,
such as how names are represented on the network, compared, and
converted to appropriate forms, but also with issues and options for
deployment, transition, registration, and administration.

The IETF Standards for Internationalized Domain Names, known as
"IDNA", focuses on access to domain names in a range of scripts that
is broader in scope than the original ASCII.  The development process
made it clear that use of characters with similar appearances and/or
interpretations created potential for confusion, as well as
difficulties in deployment and transition.  The conclusion was that,
while those issues were important, they could best be addressed
administratively rather than through restrictions embedded in the
protocols.  This document defines a set of guidelines for applying
restrictions of that type for Chinese, Japanese and Korean (CJK)
scripts and the zones that use them and, perhaps, the beginning of a
framework for thinking about other zones, languages, and scripts.

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 [e-mail].  Requests to be
added to or deleted from the RFC-DIST distribution list should
be sent to [e-mail].

Details on obtaining RFCs via FTP or EMAIL may be obtained by sending
an EMAIL message to [e-mail] with the message body 
help: ways_to_get_rfcs.  For example:

        To: [e-mail]
        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 [e-mail].  Unless
specifically noted otherwise on the RFC itself, all RFCs are for
unlimited distribution.echo 
Submissions for Requests for Comments should be sent to
[e-mail].  Please consult RFC 2223, Instructions to RFC
Authors, for further information.


Joyce K. Reynolds and Sandy Ginoza
USC/Information Sciences Institute

...

Below is the data which will enable a MIME compliant Mail Reader 
implementation to automatically retrieve the ASCII version
of the RFCs.
-------------- next part --------------
Skipped content of type multipart/alternative
From rfc-editor at rfc-editor.org  Wed Apr 14 16:49:59 2004
From: rfc-editor at rfc-editor.org ([e-mail])
Date: Wed Apr 14 16:50:28 2004
Subject: [rfc-dist] RFC 3760 on Securely Available Credentials (SACRED) -
	Credential Server Framework
Message-ID: <[e-mail]>


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


        RFC 3760

        Title:      Securely Available Credentials (SACRED) -
                    Credential Server Framework
        Author(s):  D. Gustafson, M. Just, M. Nystrom
        Status:     Informational
        Date:       April 2004
        Mailbox:    [e-mail], [e-mail],
                    [e-mail]
        Pages:      22
        Characters: 49910
        Updates/Obsoletes/SeeAlso:    None

        I-D Tag:    draft-ietf-sacred-framework-07.txt

        URL:        ftp://ftp.rfc-editor.org/in-notes/rfc3760.txt


As the number, and more particularly the number of different types, of
devices connecting to the Internet increases, credential mobility
becomes an issue for IETF standardization.  This document responds to
the requirements on protocols for secure exchange of credentials
listed in RFC 3157, by presenting an abstract protocol framework.

This document is a product of the Securely Available Credentials
Working Group of the IETF.

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 [e-mail].  Requests to be
added to or deleted from the RFC-DIST distribution list should
be sent to [e-mail].

Details on obtaining RFCs via FTP or EMAIL may be obtained by sending
an EMAIL message to [e-mail] with the message body 
help: ways_to_get_rfcs.  For example:

        To: [e-mail]
        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 [e-mail].  Unless
specifically noted otherwise on the RFC itself, all RFCs are for
unlimited distribution.echo 
Submissions for Requests for Comments should be sent to
[e-mail].  Please consult RFC 2223, Instructions to RFC
Authors, for further information.


Joyce K. Reynolds and Sandy Ginoza
USC/Information Sciences Institute

...

Below is the data which will enable a MIME compliant Mail Reader 
implementation to automatically retrieve the ASCII version
of the RFCs.
-------------- next part --------------
Skipped content of type multipart/alternative
From rfc-editor at rfc-editor.org  Wed Apr 14 16:52:07 2004
From: rfc-editor at rfc-editor.org ([e-mail])
Date: Wed Apr 14 16:53:55 2004
Subject: [rfc-dist] RFC 3768 on Virtual Router Redundancy Protocol (VRRP)
Message-ID: <[e-mail]>


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


        RFC 3768

        Title:      Virtual Router Redundancy Protocol (VRRP)
        Author(s):  R. Hinden, Ed.
        Status:     Standards Track
        Date:       April 2004
        Mailbox:    [e-mail]
        Pages:      27
        Characters: 59969
        Obsoletes:  2338

        I-D Tag:    draft-ietf-vrrp-spec-v2-10.txt

        URL:        ftp://ftp.rfc-editor.org/in-notes/rfc3768.txt


This memo defines the Virtual Router Redundancy Protocol (VRRP).
VRRP specifies an election protocol that dynamically assigns
responsibility for a virtual router to one of the VRRP routers on a
LAN.  The VRRP router controlling the IP address(es) associated with
a virtual router is called the Master, and forwards packets sent to
these IP addresses.  The election process provides dynamic fail over
in the forwarding responsibility should the Master become
unavailable.  This allows any of the virtual router IP addresses on
the LAN to be used as the default first hop router by end-hosts.  The
advantage gained from using VRRP is a higher availability default
path without requiring configuration of dynamic routing or router
discovery protocols on every end-host.

This document is a product of the Virtual Router Redundancy Protocol
Working Group of the IETF.

This is now a Draft Standard Protocol.

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

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

Details on obtaining RFCs via FTP or EMAIL may be obtained by sending
an EMAIL message to [e-mail] with the message body 
help: ways_to_get_rfcs.  For example:

        To: [e-mail]
        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 [e-mail].  Unless
specifically noted otherwise on the RFC itself, all RFCs are for
unlimited distribution.echo 
Submissions for Requests for Comments should be sent to
[e-mail].  Please consult RFC 2223, Instructions to RFC
Authors, for further information.


Joyce K. Reynolds and Sandy Ginoza
USC/Information Sciences Institute

...

Below is the data which will enable a MIME compliant Mail Reader 
implementation to automatically retrieve the ASCII version
of the RFCs.
-------------- next part --------------
Skipped content of type multipart/alternative
From rfc-editor at rfc-editor.org  Fri Apr 16 17:07:43 2004
From: rfc-editor at rfc-editor.org ([e-mail])
Date: Fri Apr 16 17:08:23 2004
Subject: [rfc-dist] RFC 3726 on Requirements for Signaling Protocols
Message-ID: <[e-mail]>


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


        RFC 3726

        Title:      Requirements for Signaling Protocols
        Author(s):  M. Brunner, Ed.
        Status:     Informational
        Date:       April 2004
        Mailbox:    [e-mail]
        Pages:      42
        Characters: 98020
        Updates/Obsoletes/SeeAlso:    None

        I-D Tag:    draft-ietf-nsis-req-09.txt

        URL:        ftp://ftp.rfc-editor.org/in-notes/rfc3726.txt


This document defines requirements for signaling across different
network environments, such as across administrative and/or technology
domains.  Signaling is mainly considered for Quality of Service (Qos)
such as the Resource Reservation Protocol (RSVP).  However, in recent
years, several other applications of signaling have been defined.  For
example, signaling for label distribution in Multiprotocol Label
Switching (MPLS) or signaling to middleboxes.  To achieve wide
applicability of the requirements, the starting point is a diverse set
of scenarios/use cases concerning various types of networks and
application interactions.  This document presents the assumptions
before listing the requirements.  The requirements are grouped
according to areas such as architecture and design goals, signaling
flows, layering, performance, flexibility, security, and mobility.

This document is a product of the Next Steps in Signaling Working
Group of the IETF.

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 [e-mail].  Requests to be
added to or deleted from the RFC-DIST distribution list should
be sent to [e-mail].

Details on obtaining RFCs via FTP or EMAIL may be obtained by sending
an EMAIL message to [e-mail] with the message body 
help: ways_to_get_rfcs.  For example:

        To: [e-mail]
        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 [e-mail].  Unless
specifically noted otherwise on the RFC itself, all RFCs are for
unlimited distribution.echo 
Submissions for Requests for Comments should be sent to
[e-mail].  Please consult RFC 2223, Instructions to RFC
Authors, for further information.


Joyce K. Reynolds and Sandy Ginoza
USC/Information Sciences Institute

...

Below is the data which will enable a MIME compliant Mail Reader 
implementation to automatically retrieve the ASCII version
of the RFCs.
-------------- next part --------------
Skipped content of type multipart/alternative
From rfc-editor at rfc-editor.org  Fri Apr 16 17:09:47 2004
From: rfc-editor at rfc-editor.org ([e-mail])
Date: Fri Apr 16 17:11:06 2004
Subject: [rfc-dist] RFC 3752 on Open Pluggable Edge Services (OPES) Use
	Cases and Deployment Scenarios
Message-ID: <[e-mail]>


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


        RFC 3752

        Title:      Open Pluggable Edge Services (OPES)
                    Use Cases and Deployment Scenarios
        Author(s):  A. Barbir, E. Burger, R. Chen, S. McHenry,
                    H. Orman, R. Penno
        Status:     Informational
        Date:       April 2004
        Mailbox:    [e-mail], [e-mail],
                    [e-mail], [e-mail],
                    [e-mail], [e-mail]
        Pages:      14
        Characters: 29481
        Updates/Obsoletes/SeeAlso:    None

        I-D Tag:    draft-ietf-opes-scenarios-01.txt

        URL:        ftp://ftp.rfc-editor.org/in-notes/rfc3752.txt


This memo provides a discussion of use cases and deployment scenarios
for Open Pluggable Edge Services (OPES).  The work examines services
that could be performed to requests and/or responses.

This document is a product of the Open Pluggable Edge Services Working
Group of the IETF.

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 [e-mail].  Requests to be
added to or deleted from the RFC-DIST distribution list should
be sent to [e-mail].

Details on obtaining RFCs via FTP or EMAIL may be obtained by sending
an EMAIL message to [e-mail] with the message body 
help: ways_to_get_rfcs.  For example:

        To: [e-mail]
        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 [e-mail].  Unless
specifically noted otherwise on the RFC itself, all RFCs are for
unlimited distribution.echo 
Submissions for Requests for Comments should be sent to
[e-mail].  Please consult RFC 2223, Instructions to RFC
Authors, for further information.


Joyce K. Reynolds and Sandy Ginoza
USC/Information Sciences Institute

...

Below is the data which will enable a MIME compliant Mail Reader 
implementation to automatically retrieve the ASCII version
of the RFCs.
-------------- next part --------------
Skipped content of type multipart/alternative
From rfc-editor at rfc-editor.org  Fri Apr 23 10:56:46 2004
From: rfc-editor at rfc-editor.org ([e-mail])
Date: Fri Apr 23 10:57:57 2004
Subject: [rfc-dist] RFC 3738 on Wave and Equation Based Rate Control (WEBRC)
	Building Block
Message-ID: <[e-mail]>


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


        RFC 3738

        Title:      Wave and Equation Based Rate Control (WEBRC)
                    Building Block
        Author(s):  M. Luby, V. Goyal
        Status:     Experimental
        Date:       April 2004
        Mailbox:    [e-mail], [e-mail]
        Pages:      32
        Characters: 82584
        Updates/Obsoletes/SeeAlso:    None

        I-D Tag:    draft-ietf-rmt-bb-webrc-04.txt

        URL:        ftp://ftp.rfc-editor.org/in-notes/rfc3738.txt


This document specifies Wave and Equation Based Rate Control (WEBRC),
which provides rate and congestion control for data delivery.  WEBRC
is specifically designed to support protocols using IP multicast.  It
provides multiple-rate, congestion-controlled delivery to receivers,
i.e., different receivers joined to the same session may be receiving
packets at different rates depending on the bandwidths of their
individual connections to the sender and on competing traffic along
these connections.  WEBRC requires no feedback from receivers to the
sender, i.e., it is a completely receiver-driven congestion control
protocol.  Thus, it is designed to scale to potentially massive
numbers of receivers attached to a session from a single
sender.  Furthermore, because each individual receiver adjusts to the
available bandwidth between the sender and that receiver, there is the
potential to deliver data to each individual receiver at the fastest
possible rate for that receiver, even in a highly heterogeneous
network architecture, using a single sender.

This document is a product of the Reliable Multicast Transport Working
Group of the IETF.

This memo defines an Experimental Protocol for the Internet community.
It does not specify an Internet standard of any kind.  Discussion and
suggestions for improvement are requested.  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 [e-mail].  Requests to be
added to or deleted from the RFC-DIST distribution list should
be sent to [e-mail].

Details on obtaining RFCs via FTP or EMAIL may be obtained by sending
an EMAIL message to [e-mail] with the message body 
help: ways_to_get_rfcs.  For example:

        To: [e-mail]
        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 [e-mail].  Unless
specifically noted otherwise on the RFC itself, all RFCs are for
unlimited distribution.echo 
Submissions for Requests for Comments should be sent to
[e-mail].  Please consult RFC 2223, Instructions to RFC
Authors, for further information.


Joyce K. Reynolds and Sandy Ginoza
USC/Information Sciences Institute

...

Below is the data which will enable a MIME compliant Mail Reader 
implementation to automatically retrieve the ASCII version
of the RFCs.
-------------- next part --------------
Skipped content of type multipart/alternative
From rfc-editor at rfc-editor.org  Fri Apr 23 10:58:11 2004
From: rfc-editor at rfc-editor.org ([e-mail])
Date: Fri Apr 23 10:58:50 2004
Subject: [rfc-dist] RFC 3754 on IP Multicast in Differentiated Services (DS)
	Networks
Message-ID: <[e-mail]>


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


        RFC 3754

        Title:      IP Multicast in Differentiated Services (DS)
                    Networks
        Author(s):  R. Bless, K. Wehrle
        Status:     Informational
        Date:       April 2004
        Mailbox:    [e-mail], [e-mail]
        Pages:      34
        Characters: 86533
        Updates/Obsoletes/SeeAlso:    None

        I-D Tag:    draft-bless-diffserv-multicast-07.txt

        URL:        ftp://ftp.rfc-editor.org/in-notes/rfc3754.txt


This document discusses the problems of IP Multicast use in
Differentiated Services (DS) networks, expanding on the discussion
in RFC 2475 ("An Architecture of Differentiated Services").  It also
suggests possible solutions to these problems, describes a potential
implementation model, and presents simulation results.

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 [e-mail].  Requests to be
added to or deleted from the RFC-DIST distribution list should
be sent to [e-mail].

Details on obtaining RFCs via FTP or EMAIL may be obtained by sending
an EMAIL message to [e-mail] with the message body 
help: ways_to_get_rfcs.  For example:

        To: [e-mail]
        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 [e-mail].  Unless
specifically noted otherwise on the RFC itself, all RFCs are for
unlimited distribution.echo 
Submissions for Requests for Comments should be sent to
[e-mail].  Please consult RFC 2223, Instructions to RFC
Authors, for further information.


Joyce K. Reynolds and Sandy Ginoza
USC/Information Sciences Institute

...

Below is the data which will enable a MIME compliant Mail Reader 
implementation to automatically retrieve the ASCII version
of the RFCs.
-------------- next part --------------
Skipped content of type multipart/alternative
From rfc-editor at rfc-editor.org  Fri Apr 23 11:01:35 2004
From: rfc-editor at rfc-editor.org ([e-mail])
Date: Fri Apr 23 11:02:20 2004
Subject: [rfc-dist] RFC 3759 on RObust Header Compression (ROHC):
	Terminology and Channel Mapping Examples
Message-ID: <[e-mail]>


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


        RFC 3759

        Title:      RObust Header Compression (ROHC):
                    Terminology and Channel Mapping Examples
        Author(s):  L-E. Jonsson
        Status:     Informational
        Date:       April 2004
        Mailbox:    [e-mail]
        Pages:      20
        Characters: 50168
        Updates:    3095

        I-D Tag:    draft-ietf-rohc-terminology-and-examples-02.txt

        URL:        ftp://ftp.rfc-editor.org/in-notes/rfc3759.txt


This document aims to clarify terms and concepts presented in RFC
3095.  RFC 3095 defines a Proposed Standard framework with profiles
for RObust Header Compression (ROHC).  The standard introduces various
concepts which might be difficult to understand and especially to
relate correctly to the surrounding environments where header
compression may be used.  This document aims at clarifying these
aspects of ROHC, discussing terms such as ROHC instances, ROHC
channels, ROHC feedback, and ROHC contexts, and how these terms
relate to other terms, like network elements and IP interfaces,
commonly used, for example, when addressing MIB issues.

This document is a product of the Robust Header Compression Working
Group of the IETF.

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 [e-mail].  Requests to be
added to or deleted from the RFC-DIST distribution list should
be sent to [e-mail].

Details on obtaining RFCs via FTP or EMAIL may be obtained by sending
an EMAIL message to [e-mail] with the message body 
help: ways_to_get_rfcs.  For example:

        To: [e-mail]
        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 [e-mail].  Unless
specifically noted otherwise on the RFC itself, all RFCs are for
unlimited distribution.echo 
Submissions for Requests for Comments should be sent to
[e-mail].  Please consult RFC 2223, Instructions to RFC
Authors, for further information.


Joyce K. Reynolds and Sandy Ginoza
USC/Information Sciences Institute

...

Below is the data which will enable a MIME compliant Mail Reader 
implementation to automatically retrieve the ASCII version
of the RFCs.
-------------- next part --------------
Skipped content of type multipart/alternative
From rfc-editor at rfc-editor.org  Mon Apr 26 16:13:35 2004
From: rfc-editor at rfc-editor.org ([e-mail])
Date: Mon Apr 26 16:14:00 2004
Subject: [rfc-dist] RFC 3782 on The NewReno Modification to TCP's Fast
	Recovery Algorithm
Message-ID: <[e-mail]>


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


        RFC 3782

        Title:      The NewReno Modification to TCP's Fast Recovery
                    Algorithm
        Author(s):  S. Floyd, T. Henderson, A. Gurtov
        Status:     Standards Track
        Date:       April 2004
        Mailbox:    [e-mail], [e-mail],
                    [e-mail]
        Pages:      19
        Characters: 49603
        Obsoletes:  2582

        I-D Tag:    draft-ietf-tsvwg-newreno-02.txt

        URL:        ftp://ftp.rfc-editor.org/in-notes/rfc3782.txt


The purpose of this document is to advance NewReno TCP's  Fast
Retransmit and Fast Recovery algorithms in RFC 2582 from Experimental
to Standards Track status.

The main change in this document relative to RFC 2582 is to specify
the Careful variant of NewReno's Fast Retransmit and Fast Recovery
algorithms.  The base algorithm described in RFC 2582 did not attempt
to avoid unnecessary multiple Fast Retransmits that can occur after a
timeout.  However, RFC 2582 also defined "Careful" and "Less Careful"
variants that avoid these unnecessary Fast Retransmits, and
recommended the Careful variant.  This document specifies the
previously-named "Careful" variant as the basic version of NewReno
TCP.

This document is a product of the Transport Area Working Group of the
IETF.

This is now a Proposed Standard Protocol.

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

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

Details on obtaining RFCs via FTP or EMAIL may be obtained by sending
an EMAIL message to [e-mail] with the message body 
help: ways_to_get_rfcs.  For example:

        To: [e-mail]
        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 [e-mail].  Unless
specifically noted otherwise on the RFC itself, all RFCs are for
unlimited distribution.echo 
Submissions for Requests for Comments should be sent to
[e-mail].  Please consult RFC 2223, Instructions to RFC
Authors, for further information.


Joyce K. Reynolds and Sandy Ginoza
USC/Information Sciences Institute

...

Below is the data which will enable a MIME compliant Mail Reader 
implementation to automatically retrieve the ASCII version
of the RFCs.
-------------- next part --------------
Skipped content of type multipart/alternative
From rfc-editor at rfc-editor.org  Mon Apr 26 16:15:19 2004
From: rfc-editor at rfc-editor.org ([e-mail])
Date: Mon Apr 26 16:16:09 2004
Subject: [rfc-dist] BCP 86,
	RFC 3766 on Determining Strengths For Public Keys Used
	For Exchanging Symmetric Keys
Message-ID: <[e-mail]>


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


        BCP 86
        RFC 3766

        Title:      Determining Strengths For Public Keys Used
                    For Exchanging Symmetric Keys
        Author(s):  H. Orman, P. Hoffman
        Status:     Best Current Practice
        Date:       April 2004
        Mailbox:    [e-mail], [e-mail]
        Pages:      23
        Characters: 55939
        SeeAlso:    BCP 86

        I-D Tag:    draft-orman-public-key-lengths-08.txt

        URL:        ftp://ftp.rfc-editor.org/in-notes/rfc3766.txt


Implementors of systems that use public key cryptography to exchange
symmetric keys need to make the public keys resistant to some
predetermined level of attack.  That level of attack resistance is the
strength of the system, and the symmetric keys that are exchanged must
be at least as strong as the system strength requirements.  The three
quantities, system strength, symmetric key strength, and public key
strength, must be consistently matched for any network protocol usage.

While it is fairly easy to express the system strength requirements in
terms of a symmetric key length and to choose a cipher that has a key
length equal to or exceeding that requirement, it is harder to choose
a public key that has a cryptographic strength meeting a symmetric key
strength requirement.  This document explains how to determine the
length of an asymmetric key as a function of a symmetric key strength
requirement.  Some rules of thumb for estimating equivalent resistance
to large-scale attacks on various algorithms are given.  The document 
also addresses how changing the sizes of the underlying large integers
(moduli, group sizes, exponents, and so on) changes the time to use
the algorithms for key exchange.

This document specifies an Internet Best Current Practices for the
Internet Community, and requests discussion and suggestions for
improvements.  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 [e-mail].  Requests to be
added to or deleted from the RFC-DIST distribution list should
be sent to [e-mail].

Details on obtaining RFCs via FTP or EMAIL may be obtained by sending
an EMAIL message to [e-mail] with the message body 
help: ways_to_get_rfcs.  For example:

        To: [e-mail]
        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 [e-mail].  Unless
specifically noted otherwise on the RFC itself, all RFCs are for
unlimited distribution.echo 
Submissions for Requests for Comments should be sent to
[e-mail].  Please consult RFC 2223, Instructions to RFC
Authors, for further information.


Joyce K. Reynolds and Sandy Ginoza
USC/Information Sciences Institute

...

Below is the data which will enable a MIME compliant Mail Reader 
implementation to automatically retrieve the ASCII version
of the RFCs.
-------------- next part --------------
Skipped content of type multipart/alternative
From rfc-editor at rfc-editor.org  Tue Apr 27 16:14:46 2004
From: rfc-editor at rfc-editor.org ([e-mail])
Date: Tue Apr 27 16:15:39 2004
Subject: [rfc-dist] RFC 3771 on The Lightweight Directory Access Protocol
	(LDAP) Intermediate Response Message
Message-ID: <[e-mail]>


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


        RFC 3771

        Title:      The Lightweight Directory Access Protocol (LDAP)
                    Intermediate Response Message
        Author(s):  R. Harrison, K. Zeilenga
        Status:     Standards Track
        Date:       April 2004
        Mailbox:    [e-mail], [e-mail]
        Pages:      8
        Characters: 17114
        Updates:    2251

        I-D Tag:    draft-rharrison-ldap-intermediate-resp-01.txt

        URL:        ftp://ftp.rfc-editor.org/in-notes/rfc3771.txt


This document defines and describes the IntermediateResponse
message, a general mechanism for defining
single-request/multiple-response operations in Lightweight Directory
Access Protocol (LDAP).  The IntermediateResponse message is defined
in such a way that the protocol behavior of existing LDAP
operations is maintained.  This message is intended to be used in
conjunction with the LDAP ExtendedRequest and ExtendedResponse to
define new single-request/multiple-response operations or in
conjunction with a control when extending existing LDAP operations in
a way that requires them to return intermediate response information. 

This is now a Proposed Standard Protocol.

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

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

Details on obtaining RFCs via FTP or EMAIL may be obtained by sending
an EMAIL message to [e-mail] with the message body 
help: ways_to_get_rfcs.  For example:

        To: [e-mail]
        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 [e-mail].  Unless
specifically noted otherwise on the RFC itself, all RFCs are for
unlimited distribution.echo 
Submissions for Requests for Comments should be sent to
[e-mail].  Please consult RFC 2223, Instructions to RFC
Authors, for further information.


Joyce K. Reynolds and Sandy Ginoza
USC/Information Sciences Institute

...

Below is the data which will enable a MIME compliant Mail Reader 
implementation to automatically retrieve the ASCII version
of the RFCs.
-------------- next part --------------
Skipped content of type multipart/alternative
From rfc-editor at rfc-editor.org  Wed Apr 28 16:57:20 2004
From: rfc-editor at rfc-editor.org ([e-mail])
Date: Wed Apr 28 16:58:46 2004
Subject: [rfc-dist] RFC 3720 on Internet Small Computer Systems Interface
	(iSCSI)
Message-ID: <[e-mail]>


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


        RFC 3720

        Title:      Internet Small Computer Systems Interface (iSCSI)
        Author(s):  J. Satran, K. Meth, C. Sapuntzakis,
                    M. Chadalapaka, E. Zeidner
        Status:     Standards Track
        Date:       April 2004
        Mailbox:    [e-mail], [e-mail],
                    [e-mail], [e-mail],
                    [e-mail]
        Pages:      257
        Characters: 578468
        Updates/Obsoletes/SeeAlso:    None

        I-D Tag:    draft-ietf-ips-iscsi-20.txt

        URL:        ftp://ftp.rfc-editor.org/in-notes/rfc3720.txt


This document describes a transport protocol for Internet Small
Computer Systems Interface (iSCSI) that works on top of TCP.  The
iSCSI protocol aims to be fully compliant with the standardized SCSI
architecture model.

SCSI is a popular family of protocols that enable systems to
communicate with I/O devices, especially storage devices.  SCSI
protocols are request/response application protocols with a common
standardized architecture model and basic command set, as well as
standardized command sets for different device classes (disks, tapes,
media-changers etc.).

As system interconnects move from the classical bus structure to a
network structure, SCSI has to be mapped to network transport
protocols.  IP networks now meet the performance requirements of
fast system interconnects and as such are good candidates to "carry"
SCSI.

This document is a product of the IP Storage Working Group of the
IETF. 

This is now a Proposed Standard Protocol.

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

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

Details on obtaining RFCs via FTP or EMAIL may be obtained by sending
an EMAIL message to [e-mail] with the message body 
help: ways_to_get_rfcs.  For example:

        To: [e-mail]
        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 [e-mail].  Unless
specifically noted otherwise on the RFC itself, all RFCs are for
unlimited distribution.echo 
Submissions for Requests for Comments should be sent to
[e-mail].  Please consult RFC 2223, Instructions to RFC
Authors, for further information.


Joyce K. Reynolds and Sandy Ginoza
USC/Information Sciences Institute

...

Below is the data which will enable a MIME compliant Mail Reader 
implementation to automatically retrieve the ASCII version
of the RFCs.
-------------- next part --------------
Skipped content of type multipart/alternative
From rfc-editor at rfc-editor.org  Wed Apr 28 16:59:15 2004
From: rfc-editor at rfc-editor.org ([e-mail])
Date: Wed Apr 28 17:01:03 2004
Subject: [rfc-dist] RFC 3721 on Internet Small Computer Systems Interface
	(iSCSI) Naming and Discovery
Message-ID: <[e-mail]>


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


        RFC 3721

        Title:      Internet Small Computer Systems Interface (iSCSI)
                    Naming and Discovery
        Author(s):  M. Bakke, J. Hafner, J. Hufferd, K. Voruganti,
                    M. Krueger
        Status:     Informational
        Date:       April 2004
        Mailbox:    [e-mail], [e-mail],
                    [e-mail], [e-mail],
                    [e-mail]
        Pages:      22
        Characters: 47564
        Updates/Obsoletes/SeeAlso:    None

        I-D Tag:    draft-ietf-ips-iscsi-name-disc-10.txt

        URL:        ftp://ftp.rfc-editor.org/in-notes/rfc3721.txt


This document provides examples of the Internet Small Computer Systems
Interface (iSCSI; or SCSI over TCP) name construction and discussion
of discovery of iSCSI resources (targets) by iSCSI initiators.  This
document complements the iSCSI protocol document.  Flexibility is the
key guiding principle behind this document.  That is, an effort has
been made to satisfy the needs of both small isolated environments, as
well as large environments requiring secure/scalable solutions.

This document is a product of the IP Storage Working Group of the
IETF.

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 [e-mail].  Requests to be
added to or deleted from the RFC-DIST distribution list should
be sent to [e-mail].

Details on obtaining RFCs via FTP or EMAIL may be obtained by sending
an EMAIL message to [e-mail] with the message body 
help: ways_to_get_rfcs.  For example:

        To: [e-mail]
        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 [e-mail].  Unless
specifically noted otherwise on the RFC itself, all RFCs are for
unlimited distribution.echo 
Submissions for Requests for Comments should be sent to
[e-mail].  Please consult RFC 2223, Instructions to RFC
Authors, for further information.


Joyce K. Reynolds and Sandy Ginoza
USC/Information Sciences Institute

...

Below is the data which will enable a MIME compliant Mail Reader 
implementation to automatically retrieve the ASCII version
of the RFCs.
-------------- next part --------------
Skipped content of type multipart/alternative
From rfc-editor at rfc-editor.org  Wed Apr 28 17:01:02 2004
From: rfc-editor at rfc-editor.org ([e-mail])
Date: Wed Apr 28 17:01:48 2004
Subject: [rfc-dist] RFC 3722 on String Profile for Internet Small Computer
	Systems Interface (iSCSI) Names
Message-ID: <[e-mail]>


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


        RFC 3722

        Title:      String Profile for Internet Small Computer
                    Systems Interface (iSCSI) Names
        Author(s):  M. Bakke
        Status:     Standards Track
        Date:       April 2004
        Mailbox:    [e-mail]
        Pages:      8
        Characters: 14702
        Updates/Obsoletes/SeeAlso:    None

        I-D Tag:    draft-ietf-ips-iscsi-string-prep-06.txt

        URL:        ftp://ftp.rfc-editor.org/in-notes/rfc3722.txt


This document describes how to prepare internationalized iSCSI names
to increase the likelihood that name input and comparison work
in ways that make sense for typical users throughout the world.

The Internet Small Computer Systems Interface (iSCSI) protocol
provides a way for hosts to access SCSI devices over an IP network.
The iSCSI end-points, called initiators and targets, each have a
globally-unique name that must be transcribable, as well as easily
compared.

This document is a product of the IP Storage Working Group of the
IETF.

This is now a Proposed Standard Protocol.

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

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

Details on obtaining RFCs via FTP or EMAIL may be obtained by sending
an EMAIL message to [e-mail] with the message body 
help: ways_to_get_rfcs.  For example:

        To: [e-mail]
        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 [e-mail].  Unless
specifically noted otherwise on the RFC itself, all RFCs are for
unlimited distribution.echo 
Submissions for Requests for Comments should be sent to
[e-mail].  Please consult RFC 2223, Instructions to RFC
Authors, for further information.


Joyce K. Reynolds and Sandy Ginoza
USC/Information Sciences Institute

...

Below is the data which will enable a MIME compliant Mail Reader 
implementation to automatically retrieve the ASCII version
of the RFCs.
-------------- next part --------------
Skipped content of type multipart/alternative
From rfc-editor at rfc-editor.org  Wed Apr 28 17:02:51 2004
From: rfc-editor at rfc-editor.org ([e-mail])
Date: Wed Apr 28 17:03:49 2004
Subject: [rfc-dist] RFC 3723 on Securing Block Storage Protocols over IP
Message-ID: <[e-mail]>


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


        RFC 3723

        Title:      Securing Block Storage Protocols over IP
        Author(s):  B. Aboba, J. Tseng, J. Walker, V. Rangan,
                    F. Travostino
        Status:     Standards Track
        Date:       April 2004
        Mailbox:    [e-mail], [e-mail],
                    [e-mail], [e-mail],
                    [e-mail]
        Pages:      70
        Characters: 171673
        Updates/Obsoletes/SeeAlso:    None

        I-D Tag:    draft-ietf-ips-security-19.txt

        URL:        ftp://ftp.rfc-editor.org/in-notes/rfc3723.txt


This document discusses how to secure block storage and storage
discovery protocols running over IP (Internet Protocol) using IPsec
and IKE (Internet Key Exchange).  Threat models and security protocols
are developed for iSCSI (Internet Protocol Small Computer System
Interface), iFCP (Internet Fibre Channel Storage Networking) and FCIP
(Fibre Channel over TCP/IP), as well as the iSNS (Internet Storage
Name Server) and SLPv2 (Service Location Protocol v2) discovery
protocols.  Performance issues and resource constraints are analyzed.

This document is a product of the IP Storage Working Group of the
IETF.

This is now a Proposed Standard Protocol.

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

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

Details on obtaining RFCs via FTP or EMAIL may be obtained by sending
an EMAIL message to [e-mail] with the message body 
help: ways_to_get_rfcs.  For example:

        To: [e-mail]
        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 [e-mail].  Unless
specifically noted otherwise on the RFC itself, all RFCs are for
unlimited distribution.echo 
Submissions for Requests for Comments should be sent to
[e-mail].  Please consult RFC 2223, Instructions to RFC
Authors, for further information.


Joyce K. Reynolds and Sandy Ginoza
USC/Information Sciences Institute

...

Below is the data which will enable a MIME compliant Mail Reader 
implementation to automatically retrieve the ASCII version
of the RFCs.
-------------- next part --------------
Skipped content of type multipart/alternative
From rfc-editor at rfc-editor.org  Wed Apr 28 17:05:06 2004
From: rfc-editor at rfc-editor.org ([e-mail])
Date: Wed Apr 28 17:05:53 2004
Subject: [rfc-dist] RFC 3746 on Forwarding and Control Element Separation
	(ForCES) Framework
Message-ID: <[e-mail]>


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


        RFC 3746

        Title:      Forwarding and Control Element Separation (ForCES)
                    Framework
        Author(s):  L. Yang, R. Dantu, T. Anderson, R. Gopal
        Status:     Informational
        Date:       April 2004
        Mailbox:    [e-mail], [e-mail],
                    [e-mail], [e-mail]
        Pages:      40
        Characters: 98660
        Updates/Obsoletes/SeeAlso:    None

        I-D Tag:    draft-ietf-forces-framework-13.txt

        URL:        ftp://ftp.rfc-editor.org/in-notes/rfc3746.txt


This document defines the architectural framework for the ForCES
(Forwarding and Control Element Separation) network elements, and
identifies the associated entities and their interactions.

This document is a product of the Forwarding and Control Element
Separation Working Group of the IETF.

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 [e-mail].  Requests to be
added to or deleted from the RFC-DIST distribution list should
be sent to [e-mail].

Details on obtaining RFCs via FTP or EMAIL may be obtained by sending
an EMAIL message to [e-mail] with the message body 
help: ways_to_get_rfcs.  For example:

        To: [e-mail]
        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 [e-mail].  Unless
specifically noted otherwise on the RFC itself, all RFCs are for
unlimited distribution.echo 
Submissions for Requests for Comments should be sent to
[e-mail].  Please consult RFC 2223, Instructions to RFC
Authors, for further information.


Joyce K. Reynolds and Sandy Ginoza
USC/Information Sciences Institute

...

Below is the data which will enable a MIME compliant Mail Reader 
implementation to automatically retrieve the ASCII version
of the RFCs.
-------------- next part --------------
Skipped content of type multipart/alternative
From rfc-editor at rfc-editor.org  Fri Apr 30 16:56:59 2004
From: rfc-editor at rfc-editor.org ([e-mail])
Date: Fri Apr 30 16:57:55 2004
Subject: [rfc-dist] RFC 3713 on A Description of the Camellia Encryption
	Algorithm
Message-ID: <[e-mail]>


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


        RFC 3713

        Title:      A Description of the Camellia Encryption Algorithm
        Author(s):  M. Matsui, J. Nakajima, S. Moriai
        Status:     Informational
        Date:       April 2004
        Mailbox:    [e-mail],
                    [e-mail],
                    [e-mail]
        Pages:      15
        Characters: 25031
        Updates/Obsoletes/SeeAlso:    None

        I-D Tag:    draft-nakajima-camellia-03.txt

        URL:        ftp://ftp.rfc-editor.org/in-notes/rfc3713.txt


This document describes the Camellia encryption algorithm.  Camellia
is a block cipher with 128-bit block size and 128-, 192-, and
256-bit keys.  The algorithm description is presented together with
key scheduling part and data randomizing part.

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 [e-mail].  Requests to be
added to or deleted from the RFC-DIST distribution list should
be sent to [e-mail].

Details on obtaining RFCs via FTP or EMAIL may be obtained by sending
an EMAIL message to [e-mail] with the message body 
help: ways_to_get_rfcs.  For example:

        To: [e-mail]
        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 [e-mail].  Unless
specifically noted otherwise on the RFC itself, all RFCs are for
unlimited distribution.echo 
Submissions for Requests for Comments should be sent to
[e-mail].  Please consult RFC 2223, Instructions to RFC
Authors, for further information.


Joyce K. Reynolds and Sandy Ginoza
USC/Information Sciences Institute

...

Below is the data which will enable a MIME compliant Mail Reader 
implementation to automatically retrieve the ASCII version
of the RFCs.
-------------- next part --------------
Skipped content of type multipart/alternative
From rfc-editor at rfc-editor.org  Fri Apr 30 16:59:03 2004
From: rfc-editor at rfc-editor.org ([e-mail])
Date: Fri Apr 30 16:59:24 2004
Subject: [rfc-dist] RFC 3761 on The E.164 to Uniform Resource Identifiers
	(URI) Dynamic Delegation Discovery System (DDDS) Application (ENUM)
Message-ID: <[e-mail]>


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


        RFC 3761

        Title:      The E.164 to Uniform Resource Identifiers (URI)
                    Dynamic Delegation Discovery System (DDDS)
                    Application (ENUM)
        Author(s):  P. Faltstrom, M. Mealling
        Status:     Standards Track
        Date:       April 2004
        Mailbox:    [e-mail], [e-mail]
        Pages:      18
        Characters: 41559
        Obsoletes:  2916

        I-D Tag:    draft-ietf-enum-rfc2916bis-07.txt

        URL:        ftp://ftp.rfc-editor.org/in-notes/rfc3761.txt


This document discusses the use of the Domain Name System (DNS) for
storage of E.164 numbers.  More specifically, how DNS can be used for
identifying available services connected to one E.164 number.  It
specifically obsoletes RFC 2916 to bring it in line with the Dynamic
Delegation Discovery System (DDDS) Application specification found in
the document series specified in RFC 3401.  It is very important to
note that it is impossible to read and understand this document
without reading the documents discussed in RFC 3401.

This document is a product of the Telephone Number Mapping Working
Group of the IETF.

This is now a Proposed Standard Working Group.

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 [e-mail].  Requests to be
added to or deleted from the RFC-DIST distribution list should
be sent to [e-mail].

Details on obtaining RFCs via FTP or EMAIL may be obtained by sending
an EMAIL message to [e-mail] with the message body 
help: ways_to_get_rfcs.  For example:

        To: [e-mail]
        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 [e-mail].  Unless
specifically noted otherwise on the RFC itself, all RFCs are for
unlimited distribution.echo 
Submissions for Requests for Comments should be sent to
[e-mail].  Please consult RFC 2223, Instructions to RFC
Authors, for further information.


Joyce K. Reynolds and Sandy Ginoza
USC/Information Sciences Institute

...

Below is the data which will enable a MIME compliant Mail Reader 
implementation to automatically retrieve the ASCII version
of the RFCs.
-------------- next part --------------
Skipped content of type multipart/alternative
From rfc-editor at rfc-editor.org  Fri Apr 30 17:00:43 2004
From: rfc-editor at rfc-editor.org ([e-mail])
Date: Fri Apr 30 17:01:25 2004
Subject: [rfc-dist] RFC 3762 on Telephone Number Mapping (ENUM) Service
	Registration for H.323
Message-ID: <[e-mail]>


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


        RFC 3762

        Title:      Telephone Number Mapping (ENUM) Service
                    Registration for H.323
        Author(s):  O. Levin
        Status:     Standards Track
        Date:       April 2004
        Mailbox:    [e-mail]
        Pages:      5
        Characters: 8450
        Updates/Obsoletes/SeeAlso:    None

        I-D Tag:    draft-ietf-enum-h323-01.txt

        URL:        ftp://ftp.rfc-editor.org/in-notes/rfc3762.txt


The H.323 specification defines a means for building multimedia
communication services over an arbitrary Packet Based Network,
including the Internet.  This document registers a Telephone Number
Mapping (ENUM) service for H.323 according to specifications and
guidelines in RFC 3761.

This document is a product of the Telephone Number Mapping Working
Group of the IETF.

This is now a Proposed Standard Protocol.

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

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

Details on obtaining RFCs via FTP or EMAIL may be obtained by sending
an EMAIL message to [e-mail] with the message body 
help: ways_to_get_rfcs.  For example:

        To: [e-mail]
        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 [e-mail].  Unless
specifically noted otherwise on the RFC itself, all RFCs are for
unlimited distribution.echo 
Submissions for Requests for Comments should be sent to
[e-mail].  Please consult RFC 2223, Instructions to RFC
Authors, for further information.


Joyce K. Reynolds and Sandy Ginoza
USC/Information Sciences Institute

...

Below is the data which will enable a MIME compliant Mail Reader 
implementation to automatically retrieve the ASCII version
of the RFCs.
-------------- next part --------------
Skipped content of type multipart/alternative
From rfc-editor at rfc-editor.org  Fri Apr 30 17:02:16 2004
From: rfc-editor at rfc-editor.org ([e-mail])
Date: Fri Apr 30 17:03:18 2004
Subject: [rfc-dist] RFC 3763 on One-way Active Measurement Protocol (OWAMP)
	Requirements
Message-ID: <[e-mail]>


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


        RFC 3763

        Title:      One-way Active Measurement Protocol (OWAMP)
                    Requirements
        Author(s):  S. Shalunov, B. Teitelbaum
        Status:     Informational
        Date:       April 2004
        Mailbox:    [e-mail], [e-mail]
        Pages:      11
        Characters: 23360
        Updates/Obsoletes/SeeAlso:    None

        I-D Tag:    draft-ietf-ippm-owdp-reqs-06.txt

        URL:        ftp://ftp.rfc-editor.org/in-notes/rfc3763.txt


With growing availability of good time sources to network nodes, it
becomes increasingly possible to measure one-way IP performance
metrics with high precision.  To do so in an interoperable manner, a
common protocol for such measurements is required.  This document
specifies requirements for a one-way active measurement protocol
(OWAMP) standard.  The protocol can measure one-way delay, as well as
other unidirectional characteristics, such as one-way loss.

This document is a product of the IP Performance Metrics Working Group
of the IETF.

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 [e-mail].  Requests to be
added to or deleted from the RFC-DIST distribution list should
be sent to [e-mail].

Details on obtaining RFCs via FTP or EMAIL may be obtained by sending
an EMAIL message to [e-mail] with the message body 
help: ways_to_get_rfcs.  For example:

        To: [e-mail]
        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 [e-mail].  Unless
specifically noted otherwise on the RFC itself, all RFCs are for
unlimited distribution.echo 
Submissions for Requests for Comments should be sent to
[e-mail].  Please consult RFC 2223, Instructions to RFC
Authors, for further information.


Joyce K. Reynolds and Sandy Ginoza
USC/Information Sciences Institute

...

Below is the data which will enable a MIME compliant Mail Reader 
implementation to automatically retrieve the ASCII version
of the RFCs.
-------------- next part --------------
Skipped content of type multipart/alternative
From rfc-editor at rfc-editor.org  Fri Apr 30 17:04:21 2004
From: rfc-editor at rfc-editor.org ([e-mail])
Date: Fri Apr 30 17:05:32 2004
Subject: [rfc-dist] RFC 3764 on enumservice registration for Session
	Initiation Protocol (SIP) Addresses-of-Record
Message-ID: <[e-mail]>


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


        RFC 3764

        Title:      enumservice registration for Session Initiation
                    Protocol (SIP) Addresses-of-Record
        Author(s):  J. Peterson
        Status:     Standards Track
        Date:       April 2004
        Mailbox:    [e-mail]
        Pages:      8
        Characters: 17604
        Updates/Obsoletes/SeeAlso:    None

        I-D Tag:    draft-ietf-enum-sip-01.txt

        URL:        ftp://ftp.rfc-editor.org/in-notes/rfc3764.txt


This document registers an Electronic Number (ENUM) service for the
Session Initiation Protocol (SIP), pursuant to the guidelines in
RFC 3761.  Specifically, this document focuses on provisioning SIP
addresses-of-record in ENUM.

This document is a product of the Telephone Number Mapping Working
Group of the IETF.

This is now a Proposed Standard Protocol.

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

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

Details on obtaining RFCs via FTP or EMAIL may be obtained by sending
an EMAIL message to [e-mail] with the message body 
help: ways_to_get_rfcs.  For example:

        To: [e-mail]
        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 [e-mail].  Unless
specifically noted otherwise on the RFC itself, all RFCs are for
unlimited distribution.echo 
Submissions for Requests for Comments should be sent to
[e-mail].  Please consult RFC 2223, Instructions to RFC
Authors, for further information.


Joyce K. Reynolds and Sandy Ginoza
USC/Information Sciences Institute

...

Below is the data which will enable a MIME compliant Mail Reader 
implementation to automatically retrieve the ASCII version
of the RFCs.
-------------- next part --------------
Skipped content of type multipart/alternative