Subject: [mpls] AD review of draft-ietf-mpls-smp-requirements

From: "Adrian Farrel" <[email-masked]>
Date: Sun, 8 Jun 2014 22:24:36 +0100

Hi authors,

I have done my usual review of your document having received the
publication request. The purpose of my review is to improve the
quality of the document and to catch any issues that might otherwise
show up during IETF last call, Directorate reviews, or IESG evaluation.

This is a pretty good document. Thanks for the effort you have put in,
and thanks to Matt for working on the English. He deserves an
acknowledgement somewhere in the document.

I have only a few issues, and they don't merit a new revision now.
So I will start the IETF last call and raise these points to be 
addressed at that time.

Thanks,
Adrian

---

Could you expand "p2p" where it is first used?

---

The very first sentence is hard to parse

   MPLS transport networks can be characterized as being a network of
   connections between nodes within a mesh of nodes and the links
   between them. 

Maybe try

   The MPLS Transport Profile (MPLS-TP) provides tools to construct and
   operate a set of connections between nodes in an MPLS network.  The
   MPLS network is a mesh comprising nodes and the links between them.

---

I understand that you want to use RFC 2119 language to clarify the 
requirements, but RFC 2119 was developed for specifying protocols, so 
the direct reference and boilerplate quote is incongruous. I suggest
you use the language as found in RFC 5654, viz.:

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in RFC 2119 [RFC2119].
   Although this document is not a protocol specification, the use of
   this language clarifies the instructions to protocol designers
   producing solutions that satisfy the requirements set out in this
   document.

---

In Section 5.1 you have

   the control
   protocol SHOULD NOT be used as the primary resilience mechanism.

I agree, but I think that the term "primary resilience mechanism" may be
under defined. Can you do anything to clarify this? Maybe...

   the control
   protocol SHOULD NOT be used as the primary mechanism for detecting or
   reporting network failures, or for initiating or coordinating 
   protection switch-over.  That is, it SHOULD NOT be used as the 
   primary resilience mechanism.

---

From: Sam Aldrin <[email-masked]>
Date: Sun, 8 Jun 2014 17:30:48 -0400

Hi Adrian,

Thanks for the feedback and comments. Will definitely add Matt to ack section. Sorry for missing out to add him in the recent revision.

Thanks
Sam

Sent from my iPhone

> On Jun 8, 2014, at 5:24 PM, "Adrian Farrel" <[email-masked]> wrote:
> 
> Hi authors,
> 
> _______________________________________________
> mpls mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mpls

---

From: Jeong Ryoo <[email-masked]>
Date: Mon, 9 Jun 2014 00:27:22 +0000

Adrian, thanks for your review.

Matt definitely deserves an acknowledgement.

Thanks.

Jeong-dong

________________________________
보낸 사람 : "Sam Aldrin" <[email-masked]>
보낸 날짜 : 2014-06-09 06:31:03 ( +09:00 )
받는 사람 : [email-masked] <[email-masked]>
참조 : [email-masked] <[email-masked]>, <[email-masked]>
제목 : Re: [mpls] AD review of draft-ietf-mpls-smp-requirements

Hi Adrian,

Thanks
Sam

Sent from my iPhone

> On Jun 8, 2014, at 5:24 PM, "Adrian Farrel" wrote:
>
> Hi authors,
>