Subject: (ngtrans) Last Call: An anycast prefix for 6to4 relay routers to Proposed Standard

From: The IESG <[email-masked]>
Date: Mon, 19 Feb 2001 15:26:41 -0500

The IESG has received a request from the Next Generation Transition
Working Group to consider An anycast prefix for 6to4 relay routers
<draft-ietf-ngtrans-6to4anycast-01.txt> as a Proposed Standard.

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action.  Please send any comments to the
[email-masked] or [email-masked] mailing lists by March 5, 2001.

Files can be obtained via
http://www.ietf.org/internet-drafts/draft-ietf-ngtrans-6to4anycast-01.txt

---

From: Nathan Lutchansky <[email-masked]>
Date: Mon, 19 Feb 2001 20:02:52 -0500 (EST)

> <draft-ietf-ngtrans-6to4anycast-01.txt> as a Proposed Standard.

I could be wrong here, but for this to become a proposed standard, doesn't
IANA need to actually assign the anycast prefix in question so that we can
start developing "independent implementations", per the IETF
standardization process?  -Nathan

-- 
+-------------------+---------------------+------------------------+
| Nathan Lutchansky | [email-masked] |  Lithium Technologies  |
+------------------------------------------------------------------+
|  I dread success.  To have succeeded is to have finished one's   |
|  business on earth...  I like a state of continual becoming,     |
|  with a goal in front and not behind. - George Bernard Shaw      |
+------------------------------------------------------------------+

---

From: Bob Fink <[email-masked]>
Date: Mon, 19 Feb 2001 17:21:55 -0800

Nathan,

>standardization process?  -Nathan

For your info, RFC2026 says: "Usually, neither implementation nor 
operational experience is required for the designation of a specification 
as a Proposed Standard." See the full text below.

Presumably as soon as there is agreement at the IESG that 6to4anycast is to 
be approved for PS, the IANA/ICANN/whatever will fairly quickly assign an 
anycast address block.

Bob

===
>4.1.1  Proposed Standard
>
>    The entry-level maturity for the standards track is "Proposed
>    Standard".  A specific action by the IESG is required to move a
>    specification onto the standards track at the "Proposed Standard"
>    level.
>
>    A Proposed Standard specification is generally stable, has resolved
>    known design choices, is believed to be well-understood, has received
>    significant community review, and appears to enjoy enough community
>    interest to be considered valuable.  However, further experience
>    might result in a change or even retraction of the specification
>    before it advances.
>
>    Usually, neither implementation nor operational experience is
>    required for the designation of a specification as a Proposed
>    Standard.  However, such experience is highly desirable, and will
>    usually represent a strong argument in favor of a Proposed Standard
>    designation.
>
>    The IESG may require implementation and/or operational experience
>    prior to granting Proposed Standard status to a specification that
>    materially affects the core Internet protocols or that specifies
>    behavior that may have significant operational impact on the
>    Internet.
>
>    A Proposed Standard should have no known technical omissions with
>    respect to the requirements placed upon it.  However, the IESG may
>    waive this requirement in order to allow a specification to advance
>    to the Proposed Standard state when it is considered to be useful and
>    necessary (and timely) even with known technical omissions.
>
>
>
>
>
>
>Bradner                  Best Current Practice                 [Page 12]
>
>RFC 2026               Internet Standards Process           October 1996
>
>
>    Implementors should treat Proposed Standards as immature
>    specifications.  It is desirable to implement them in order to gain
>    experience and to validate, test, and clarify the specification.
>    However, since the content of Proposed Standards may be changed if
>    problems are found or better solutions are identified, deploying
>    implementations of such standards into a disruption-sensitive
>    environment is not recommended.
-end

---

From: Nathan Lutchansky <[email-masked]>
Date: Mon, 19 Feb 2001 22:34:00 -0500 (EST)

> as a Proposed Standard." See the full text below.

Ah, I believe I was thinking of the requirements for draft standards.
Thank you for the clarification.  -Nathan