Short further last call on draft-ietf-ccamp-rsvp-node-id-based-hello-02.txt

["Adrian Farrel" <adrian@olddog.co.uk>]

Hi,

Alex has reviewed this I-D as AD and says it is fine, but he thinks we
should take it down the standards track as Proposed Standard not BCP as it
was previously marked.

This revision changes:
- proposed status
- IPR boilerplate
- IANA clause to be a little more (about 10 words) detailed

Since we have changed the proposed status, we need to check back with you
guys.

Let's have a two week last call on this change.

If you do spot other issues as you go, then I guess we can handle them
too.

Last call will end 12 noon GMT on Thursday 22nd September.

Thanks,
Adrian


----- Original Message ----- 
From: <Internet-Drafts@ietf.org>
To: <i-d-announce@ietf.org>
Cc: <ccamp@ops.ietf.org>
Sent: Wednesday, September 07, 2005 8:50 PM
Subject: I-D ACTION:draft-ietf-ccamp-rsvp-node-id-based-hello-02.txt


> A New Internet-Draft is available from the on-line Internet-Drafts
directories.
> This draft is a work item of the Common Control and Measurement Plane
Working Group of the IETF.
>
> Title : Node ID based RSVP Hello: A Clarification Statement
> Author(s) : Z. Ali, et al.
> Filename : draft-ietf-ccamp-rsvp-node-id-based-hello-02.txt
> Pages : 7
> Date : 2005-9-7
>
> Use of Node-ID based RSVP Hello messages is implied in a number of
>    cases, e.g., when data and control plan are separated, when TE links
>    are unnumbered. Furthermore, when link level failure detection is
>    performed by some means other than exchanging RSVP Hello messages,
>    use of Node-ID based Hello session is optimal for detecting signaling
>    adjacency failure for Resource reSerVation Protocol-Traffic
>    Engineering (RSVP-TE). Nonetheless, this implied behavior is unclear
>    and this document formalizes use of Node-ID based RSVP Hello session
>    as a best current practice (BCP) in some scenarios. The procedure
>    described in this document applies to both Multi-Protocol Label
>    Switching (MPLS) and Generalized MPLS (GMPLS) capable nodes.
>
> A URL for this Internet-Draft is:
>
http://www.ietf.org/internet-drafts/draft-ietf-ccamp-rsvp-node-id-based-hello-02.txt
>
> To remove yourself from the I-D Announcement list, send a message to
> i-d-announce-request@ietf.org with the word unsubscribe in the body of
the message.
> You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce
> to change your subscription settings.
>
>
> Internet-Drafts are also available by anonymous FTP. Login with the
username
> "anonymous" and a password of your e-mail address. After logging in,
> type "cd internet-drafts" and then
> "get draft-ietf-ccamp-rsvp-node-id-based-hello-02.txt".
>
> A list of Internet-Drafts directories can be found in
> http://www.ietf.org/shadow.html
> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
>
>
> Internet-Drafts can also be obtained by e-mail.
>
> Send a message to:
> mailserv@ietf.org.
> In the body type:
> "FILE
/internet-drafts/draft-ietf-ccamp-rsvp-node-id-based-hello-02.txt".
>
> NOTE: The mail server at ietf.org can return the document in
> MIME-encoded form by using the "mpack" utility.  To use this
> feature, insert the command "ENCODING mime" before the "FILE"
> command.  To decode the response(s), you will need "munpack" or
> a MIME-compliant mail reader.  Different MIME-compliant mail readers
> exhibit different behavior, especially when dealing with
> "multipart" MIME messages (i.e. documents which have been split
> up into multiple messages), so check your local documentation on
> how to manipulate these messages.
>
>
> Below is the data which will enable a MIME compliant mail reader
> implementation to automatically retrieve the ASCII version of the
> Internet-Draft.
>


--------------------------------------------------------------------------
------


> _______________________________________________
> I-D-Announce mailing list
> I-D-Announce@ietf.org
> https://www1.ietf.org/mailman/listinfo/i-d-announce
>