Liaison statement
Liaison Statement: LS214 - MPLS-TP survivability framework draft reviewed (ref # 28.05)

Thank you for your further liaison discussing our disposition of your
comments on draft-ietf-mpls-tp-survive-fwk. As you
will be aware, this document is now in an advanced state in
the IETF process.

We have examined your comments and respond as follows:

Comment 1
No further action is required

Comment 2
(2.1) Similar text to that which you requested has been added to the
end of Section 4.3.2
(2.2) No further action is required

Comment 3
(3.1) Text to clarify that this case applies only to linear
protection has been added. A forward pointer to section 4.8 has been
added for ring protection.

(3.2) The indicated document is present as an Informative reference
and is in accordance with normal IETF practice.

It is our understanding from reading A.5 and
http://www.itu.int/dms_pub/itu-t/oth/3E/01/T3E010000010001MSWE.doc
that you are able to make bibliographic reference to Internet-Drafts
that are work in progress. Further, it  is our understanding that
only Normative references are cascaded.

Comment 4
This substantial proposal of new text has been received too late
in the IETF review cycle to be included. This text would need
to be introduced via a new Internet-Draft.

Comment 5
(5.1) No further action is required
(5.2) The current document shows RFC4427 as a Normative  reference
and G.808.1 as an Informative reference. This is appropriate for
how they are used in this document and this has been confirmed
through IETF consensus.

If the ITU-T believe that there is a discrepancy between RFC4427
and G.808.1, we suggest that this should be addressed by proposing
revised a revised version of RFC4427.

Comment 6
No further action is required

Comment 7
No further action is required

Comment 8
Thank you for highlighting the continued confusion over the word
"level". We think that your proposed change to "type" does not
convey the different qualities of recovery, and may lead to
confusion with "mechanism". We have changed to use the word "grade".
This change can be seen in sections 1.4, 4, 4.1.1, 4.3, 4.3.2,
4.4.1, 4.4.2, 4.4.3, 4.6, and 4.9.1.

Comment 9
No further action is required

Comment 10
Please see resolution for comment 3

Comment 11
This reference to draft-ietf-mpls-tp-linear-protection has been
retained (see resolution for comment 3). This reference documents
where the solution that will be described, but, within the IETF
process, makes no pre-judgment about the explicit solution.
Please note also that the solution documented in the
draft-ietf-mpls-tp-linear-protection can be changed at any time
by working group consensus.

Comment 12
No further action is required

General Comments
No further action is required

New Comment A
The current IETF consensus on this document is that the term "span"
is as defined in this document and is distinct from a "link" as
explained in this document.

We are therefore unable to make this change to this document at
this stage in the process.

We hope that the Editors of draft-ietf-mpls-tp-rosetta-stone will
bring that document into line with these definitions.

New Comment B
The change has been made as suggested.

New Comment C
The text has been changed to highlight that segment recovery
(section 4.2.2) is not a form of span recovery.

New Comment D
Text has been added to section 4.3 along the lines of your suggestion.

New Comment E
This document is not a requirements document and sets no MPLS-TP
 requirements. There is, therefore, no need for any change.
Also it is now too late in the IETF process to make any movement
between normative and non-normative.

New Comment F
It looks as if the correct reference is to section 4.4.3. This
text has been clarified.

New Comment G
This is not new text - it was present in the 00 version of this
document. The text has been previously reviewed by the ITU-T
experts and there is no scope for further review.

New Comment H
This proposal for the removal of a significant piece of text
that has been present since the 00 version of the  document
comes after IETF consensus and is therefore too late in the
IETF process for this change to be considered.

Please note, however, that section 6.4 makes explicit, normative
reference to OAM Framework, and that the removal of a section
on OAM would give the impression  that the various functions
can be performed through the management plane and the control
plane, but not using  OAM. Such an impression would not be
desirable.