Subject: Protocol Action: 'Data Channel Status Confirmation Extensions for the Link Management Protocol' to Proposed Standard

From: The IESG <[email-masked]>
Date: Wed, 13 Jan 2010 15:19:28 -0800 (PST)

The IESG has approved the following document:

- 'Data Channel Status Confirmation Extensions for the Link Management 
   Protocol '
   <draft-ietf-ccamp-confirm-data-channel-status-09.txt> as a Proposed Standard

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

The IESG contact persons are Adrian Farrel and Ross Callon.

A URL of this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-ccamp-confirm-data-channel-status-09.txt

Technical Summary

   This document defines an extention to the Link Management Protocol 
   (LMP) to provide a control plane tool that can assist in the location
   of stranded resources by allowing adjacent LSRs to confirm data 
   channel statuses, and provides triggers for notifying the management 
   plane if any discrepancies are found.

Working Group Summary

   This document received adequate attention and discussion in the 
   working group in its early revisions. The document has been laregly 
   stable for quite some time, mainly needing revisions as part of the 
   publication process.

Document Quality

   There have been no public statements related to intent to implement, 
   but it is expected that some/all of the primary Authors plan to 
   implement. Private comment to the AD reveal the existence of two
   implementations.

Personnel

   Lou Berger ([email-masked]) is the Document Shepherd.
   Adrian Farrel ([email-masked]) is the Responsible AD.

RFC Editor Note

Section 4.1.3
ADD to the end of the section
   The ERROR_CODE object in this message has a new Class Type (see
   Section 7.3), but is formed as the ERROR_CODE object defined in
   [RFC4204]. The following Error Codes are defined:

   0x01 = Channel Status Confirmation Procedure not supported
   0x02 = Unwilling to Confirm
END

---

Section 4.4

OLD
   Some nodes running in the network may only support the LMP Message
   Types, which are already defined in [RFC4204]. The three new types of
   LMP message defined in this document can not be recognized by these
   nodes. The unknown message behavior is not being specified in
   [RFC4204], it's suggested to discard the unknown message silently.
   The mechanism defined in this document presumes a certain non-
   standard behavior of existing/non-document supporting nodes. To use
   this mechanism all nodes MUST have the extensions described in this
   document for compatibility.
NEW
   Some nodes running in the network might only support the LMP Message
   Types which are already defined in [RFC4204]. The three new types of
   LMP message defined in this document can not be recognized by these
   nodes. The behavior of an LMP node that receives an unknown message
   is not specified in [RFC4204] and will be clarified in a separate
   document.

   Since the behavior of legacy nodes must be assumed to be unknown,
   this document assumes that a deployment intended to support the
   function described in this document will consist completely of nodes
   that support the protocol extensions described in this document.

   In future, it may be the case that LMP will be extended to allow
   function-support to be detected. In that case, it may become possible
   to deploy this function in a mixed environment.
END

---

Section 5
s/local police/local policy/

---

Section 5

OLD
   ConfirmDataChannelStatus SHOULD be sent using LMP [RFC4204] reliable
   transmission mechanisms. If after the retry limit is reached, a
   ConfirmDataChannelStatusAck message or a ConfirmDataChannelStatusNack
   message is not received by the SENDER, the SENDER SHOULD terminate
   the data channel confirmation procedure.
NEW
   ConfirmDataChannelStatus SHOULD be sent using LMP [RFC4204] reliable
   transmission mechanisms. If after the retry limit is reached, a
   ConfirmDataChannelStatusAck message or a ConfirmDataChannelStatusNack
   message is not received by the SENDER, the SENDER SHOULD terminate
   the data channel confirmation procedure and SHOULD raise an alert to
   the management plane.
END

---

Section 6
OLD
   The operation of the procedures described in this document does not
   of themselves constitute a security risk since they do not cause any
   change in network state. It would be possible, if the messages were
   intercepted or spoofed to cause bogus alerts in the management plane
   and so the use of the LMP security measures are RECOMMENDED.
NEW
   The operation of the procedures described in this document does not
   of themselves constitute a security risk since they do not cause any
   change in network state. It would be possible, if the messages were
   intercepted or spoofed to cause bogus alerts in the management plane
   and so the use of the LMP security measures described in [RFC4204]
   are RECOMMENDED.
END 

---

NEW
7.3. NEW LMP Error_Code Class Type

   IANA maintains the "Link Management Protocol (LMP)" registry which
   has a subregistry called "LMP Object Class name space and Class type
   (C-Type)". This subregistry has an entry for the ERROR_CODE object.
   IANA is requested to allocate a new value for an ERROR_CODE class
   type as follows.

           C-Type   Description                    Reference
           ------   ------------------------       ---------
                4   ConfirmDataChannelStatusNack   [This-ID]
END