[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Document Action: 'Problem Statement of Default Address Selection in Multi-prefix Environment: Operational Issues of RFC3484 Default Rules' to Informational RFC
The IESG has approved the following document:
- 'Problem Statement of Default Address Selection in Multi-prefix
Environment: Operational Issues of RFC3484 Default Rules '
<draft-ietf-v6ops-addr-select-ps-09.txt> as an Informational RFC
This document is the product of the IPv6 Operations Working Group.
The IESG contact persons are Ron Bonica and Dan Romascanu.
A URL of this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-v6ops-addr-select-ps-09.txt
> Technical Summary: Relevant content can frequently be found in the
> abstract and/or introduction of the document. If not, this may be
> an indication that there are deficiencies in the abstract or
> introduction.
One physical network can carry multiple logical networks. Moreover,
we can use multiple physical networks at the same time in a
host. In
that environment, end hosts might have multiple IP addresses and be
required to use them selectively. Without an appropriate source/
destination address selection mechanism, the host will experience
some trouble in communication. RFC 3484 defines both the source and
destination address selection algorithms, but the multi-prefix
environment considered here needs additional rules beyond those of
the default operation. This document describes the possible
problems
that end hosts could encounter in an environment with multiple
logical networks.
> Working Group Summary: Was there anything in WG process that is
> worth noting? For example, was there controversy about particular
> points or were there decisions where the consensus was particularly
> rough?
The problem statement and requirements have been thoroughly discussed
and seem to have a reasonably strong consensus. The proposed solution
is not yet agreed to.
> Document Quality: Are there existing implementations of the
> protocol? Have a significant number of vendors indicated their plan
> to implement the specification? Are there any reviewers that merit
> special mention as having done a thorough review, e.g., one that
> resulted in important changes or a conclusion that the document had
> no substantive issues? If there was a MIB Doctor, Media Type or
> other expert review, what was its course (briefly)? In the case of
> a MeFrom ietf-announce-bounces at ietf.org Tue Jun 17 09:11:21 2008
Return-Path: <ietf-announce-bounces at ietf.org>
X-Original-To: ietf-announce-archive at megatron.ietf.org
Delivered-To: ietfarch-ietf-announce-archive at core3.amsl.com
Received: from [127.0.0.1] (localhost [127.0.0.1])
by core3.amsl.com (Postfix) with ESMTP id 4E20B3A6A43;
Tue, 17 Jun 2008 09:11:21 -0700 (PDT)
X-Original-To: ietf-announce at ietf.org
Delivered-To: ietf-announce at core3.amsl.com
Received: by core3.amsl.com (Postfix, from userid 30)
id 18A153A69FB; Tue, 17 Jun 2008 09:11:19 -0700 (PDT)
X-idtracker: yes
From: The IESG <iesg-secretary at ietf.org>
To: IETF-Announce <ietf-announce at ietf.org>
Subject: Document Action: 'Problem Statement of Default Address
Selection in Multi-prefix Environment: Operational Issues of
RFC3484 Default Rules' to Informational RFC
Message-Id: <20080617161120.18A153A69FB at core3.amsl.com>
Date: Tue, 17 Jun 2008 09:11:20 -0700 (PDT)
Cc: v6ops mailing list <v6ops at ops.ietf.org>,
Internet Architecture Board <iab at iab.org>,
v6ops chair <v6ops-chairs at tools.ietf.org>,
RFC Editor <rfc-editor at rfc-editor.org>
X-BeenThere: ietf-announce at ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: IETF Announcements <ietf-announce.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/ietf-announce>,
<mailto:ietf-announce-request at ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/pipermail/ietf-announce>
List-Post: <mailto:ietf-announce at ietf.org>
List-Help: <mailto:ietf-announce-request at ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf-announce>,
<mailto:ietf-announce-request at ietf.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: ietf-announce-bounces at ietf.org
Errors-To: ietf-announce-bounces at ietf.org
The IESG has approved the following document:
- 'Problem Statement of Default Address Selection in Multi-prefix
Environment: Operational Issues of RFC3484 Default Rules '
<draft-ietf-v6ops-addr-select-ps-09.txt> as an Informational RFC
This document is the product of the IPv6 Operations Working Group.
The IESG contact persons are Ron Bonica and Dan Romascanu.
A URL of this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-v6ops-addr-select-ps-09.txt
> Technical Summary: Relevant content can frequently be found in the
> abstract and/or introduction of the document. If not, this may be
> an indication that there are deficiencies in the abstract or
> introduction.
One physical network can carry multiple logical networks. Moreover,
we can use multiple physical networks at the same time in a
host. In
that environment, end hosts might have multiple IP addresses and be
required to use them selectively. Without an appropriate source/
destination address selection mechanism, the host will experience
some trouble in communication. RFC 3484 defines both the source and
destination address selection algorithms, but the multi-prefix
environment considered here needs additional rules beyond those of
the default operation. This document describes the possible
problems
that end hosts could encounter in an environment with multiple
logical networks.
> Working Group Summary: Was there anything in WG process that is
> worth noting? For example, was there controversy about particular
> points or were there decisions where the consensus was particularly
> rough?
The problem statement and requirements have been thoroughly discussed
and seem to have a reasonably strong consensus. The proposed solution
is not yet agreed to.
> Document Quality: Are there existing implementations of the
> protocol? Have a significant number of vendors indicated their plan
> to implement the specification? Are there any reviewers that merit
> special mention as having done a thorough review, e.g., one that
> resulted in important changes or a conclusion that the document had
> no substantive issues? If there was a MIB Doctor, Media Type or
> other expert review, what was its course (briefly)? In the case of
> a Media Typedia Type review, on what date was the request posted?
Personnel
Fred Baker is shepard for this document
_______________________________________________
IETF-Announce mailing list
IETF-Announce at ietf.org
https://www.ietf.org/mailman/listinfo/ietf-announce
review, on what date was the request posted?
Personnel
Fred Baker is shepard for this document
_______________________________________________
IETF-Announce mailing list
IETF-Announce at ietf.org
https://www.ietf.org/mailman/listinfo/ietf-announce