[mpls] New Liaison Statement, "Liaison Statement: LS214 - MPLS-TP survivability framework draft reviewed (ref # 28.05)"

[Stewart Bryant(IETF RTG AREA) <[e-mail]>]

Title: Liaison Statement: LS214 - MPLS-TP survivability framework draft reviewed (ref # 28.05)
Submission Date: 2010-07-16
URL of the IETF Web page: https://datatracker.ietf.org/public/liaison_detail.cgi?detail_id=923 

From: Stewart Bryant(IETF RTG AREA) <[e-mail]>
To: ITU-T SG 15([e-mail], [e-mail])
Cc: [e-mail]
[e-mail]
[e-mail]
[e-mail]
[e-mail]
[e-mail]
[e-mail]
[e-mail]
[e-mail]
[e-mail]
[e-mail]
[e-mail]
Reponse Contact: [e-mail]
[e-mail]
Technical Contact: [e-mail]
[e-mail]
Purpose: In response 
Body: 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.
Attachment(s):
No document has been attached