[mpls] MPLS-RT review on draft-dj-mpls-tp-exer-psc-01

Sam Aldrin <aldrin.ietf@gmail.com> Fri, 23 August 2013 20:38 UTC

Return-Path: <aldrin.ietf@gmail.com>
X-Original-To: mpls@ietfa.amsl.com
Delivered-To: mpls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5F3E411E8109 for <mpls@ietfa.amsl.com>; Fri, 23 Aug 2013 13:38:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.299
X-Spam-Level:
X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=-0.301, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_43=0.6]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t-1140Jf+48I for <mpls@ietfa.amsl.com>; Fri, 23 Aug 2013 13:38:37 -0700 (PDT)
Received: from mail-pa0-x22e.google.com (mail-pa0-x22e.google.com [IPv6:2607:f8b0:400e:c03::22e]) by ietfa.amsl.com (Postfix) with ESMTP id 9939B11E8108 for <mpls@ietf.org>; Fri, 23 Aug 2013 13:38:37 -0700 (PDT)
Received: by mail-pa0-f46.google.com with SMTP id fa1so1094399pad.5 for <mpls@ietf.org>; Fri, 23 Aug 2013 13:38:37 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=lsayIhAgPKelNBPknRu2Q0fGqH5AlfAhfPVVOJSFS4Y=; b=Zzylk9O6hSQu5pCFFxn0ULlGofqxuxduHMxUGgWV0UCvVXSruHGzWTuDJWX22A3Hq+ 1I63FoPrkfNT+1VknU2KB1Omkrop5piNmxT+TP7NvLbwXywBYEkkn27Ips+hucSzvYbx zxu/H2KQQknHcKdBAaUnqE9ZQq+bLPr0ActLEE82PyNs/766YlqK7oFgEzDEsq97NSBl xizAHA4nx9iZFXDPHRlTzfPEVIOHODk0qT3EbwUC2cXU3m87MlPPv3SgL3aaz+4sEpFm s+BMS5O2IRxWK2xcYtJA/yxHpMlW/pu66L2802czSs63sXH6XTFpIAAIp53yW6ZWMReP pV1g==
X-Received: by 10.68.96.130 with SMTP id ds2mr1585355pbb.99.1377290317275; Fri, 23 Aug 2013 13:38:37 -0700 (PDT)
Received: from [192.168.1.8] (c-98-248-237-85.hsd1.ca.comcast.net. [98.248.237.85]) by mx.google.com with ESMTPSA id om2sm1655264pbc.30.1969.12.31.16.00.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 23 Aug 2013 13:38:36 -0700 (PDT)
Content-Type: multipart/alternative; boundary="Apple-Mail=_68E95ED8-C854-4E1E-86F8-DD9EB559A85A"
Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\))
From: Sam Aldrin <aldrin.ietf@gmail.com>
In-Reply-To: <78783902-650F-467A-83DF-192773E37923@gmail.com>
Date: Fri, 23 Aug 2013 13:38:34 -0700
Message-Id: <43CB7BBF-7839-4775-A55A-95FAC23088E7@gmail.com>
References: <78783902-650F-467A-83DF-192773E37923@gmail.com>
To: draft-dj-mpls-tp-exer-psc@tools.ietf.org, "mpls-chairs@tools.ietf.org" <mpls-chairs@tools.ietf.org>
X-Mailer: Apple Mail (2.1508)
Cc: "<mpls@ietf.org>" <mpls@ietf.org>
Subject: [mpls] MPLS-RT review on draft-dj-mpls-tp-exer-psc-01
X-BeenThere: mpls@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Multi-Protocol Label Switching WG <mpls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mpls>, <mailto:mpls-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/mpls>
List-Post: <mailto:mpls@ietf.org>
List-Help: <mailto:mpls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mpls>, <mailto:mpls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 23 Aug 2013 20:38:38 -0000

Hi,

I have reviewed the draft as part of MPLS-RT review. Here are my comments regarding the draft, followed by assessment comments.

General comments:
-------------------------

- I am confused by the wording within the draft. What is the primary purpose? To modify the RFC6378 as it doesn't have the EXER mode?
For ex: It says in sec 2.1 "The following text should be added in Section 2.1 in [RFC6378] ". Who will be adding, how and where?
This comment applies to whole draft.

- As this draft is introducing a new mode(not fixing Errata), EXER, which needed update to the RFC6378, the format chosen is not readable. As in the earlier comment, this draft is adding text to the RFC in each of the relevant sections. As a reader it is confusing at best. One will not be able to understand all the details, unless this draft and RFC are put side by side. My preference is to update the RFC with the updated text and issue a new RFCbis or something. Sorry I do not know the IETF process for updating existing RFC's. WG chairs or WG could provide better guidance on this.

Editorial comments:
---------------------------

- I see 'RR' is added as Reverse Request. As the terminology of Remote Request is already used, using different term is advisable. 
- Sec 2.3  FPath? Not defined earlier. Could you add in the terminology or reference to it?
- In sec 2.1, PSC request fields, it says, values are set to the same in both EXER and Reverse directions. Is it correct?

Assessment comments:
----------------------------
a. Is the document coherent?
> Draft is consistent and coherent, except for one section, identified in the comment above.

b. Is it useful?
> Apparently it is already used in transport networks. As this is identified as missing piece, I feel it is necessary to fill the gap.

c. Is the document technically sound?
> Yes. The document is written well and addresses all the sections of RFC6378, to introduce this new mode.

d. Is this document ready for WG adoption?
> It depends on the answer to the questions in 'general comments'. Having a separate document is confusing at best, from readability perspective. As such, it is difficult to continue to be in the context, while reading the draft, as it refers to missing pieces in the RFC. I would like WG and chairs to make a call on how to have this documented i.e. integrate the text into RFC6378 and issue a new version of the RFC?
> IMO, as there are other documents which introduces modifications to the same RFC as well, better to consolidate all the changes and issue a new version of RFC.
> Once the above are addressed, and if the decision is to retain as a separate document, then a new version could be published with rest of the comments addressed, prior to adoption.

cheers
-sam