Subject: [mpls] AD Review of draft-ietf-mpls-tp-on-demand-cv

From: "Adrian Farrel" <[email-masked]>
Date: Tue, 19 Jul 2011 22:48:31 +0100

Hi,

I have performed my AD review of your draft prior to IETF last call and
IESG review. The purpose is to find any issues that might be raised at
those stages and to try to achieve a smoother progress through the
system.

My review has thrown up a number of minor editorial issues and a couple
of concerns with the IANA section. Otherwise the I-D is in pretty good 
shape - thanks.

Can you please have a look at the issues below and spin a new revision.
All issues are, of course, open for debate.

I have put the I-D into Revised ID Needed state, and as soon as I see
a revision, I will start the IETF last call.

Thanks,
Adrian

---

Please expand LSP in the Abstract
Ditto in Section 1

---

Section 1.1

Immediately after your careful text explaining terms you use
"traceroute" without explanation!

---

Please expand LSR in Section 1.2

---

Please expand ACH in Section 1.3

---

Section 2.2.3

   When sending On-demand CV packets using ACH, without IP
   encapsulation, there MAY be a need to identify the destination of the
   packet.

I think s/MAY/may/

You mean "may" as in "might" not as in "an implementation is permitted"

---

Section 2.3

   In order to identify a statically provisioned LSP and PW, new target
   FEC stack sub-TLVs are being defined.  The new sub-TLVs are assigned
   sub-type identifiers as follows, and are described in the following
   sections.

The present continuous tense is unhelpful.
Do you mean "are defined in this document"?

---

Section 2.3.1 and 2.3.2

s/global/Global/

---

Section 3.4.1

The MBZ field is not defined or explained.
0 on TX, ignore on RX?

---

Section 7.1, 7.2, 7.3

In all three subsections you have misnamed the registry.

Should read...
"Multi-Protocol Label Switching (MPLS) Label Switched Paths (LSPs) Ping 
Parameters"

---

Section 7.2                                                                     

   IANA is requested to assign sub-type values to the following sub-TLVs

Should read

   IANA has made early assignment of sub-type values to the following
   sub-TLVs. IANA is requested to make the assignments permanent.

---

Section 7.5                                          

It would help IANA if you named the new sub-registry and told them which
is the parent registry.

   Because the field in this case is an 8-octet field, the basis for all
   future allocations SHOULD be "Standards Based."

I think this is an 8 bit field! But also, I think that the reasoning is 
not important to IANA. You just have to tell them what to do.
Please don't use RFC 2119 language in the IANA section.
"Standards Based" does not a recognised allocation policy.

So...

NEW
   The allocation policy for this registry is "Standards Action" 
   [RFC5226].
END

---
                      
Heads-up on manageability.

We are currently attracting a bit of interest from the Ops ADs on our
drafts wrt how to make them manageable. There is not a requirement to 
specify MIB or YANG modules, but there is pressure to draw out the
"objects" that should be configurable, and those that should be
inspectable in a "Normal" implementation. I don't think this is a lot
of work (and you have done it a bit in some places such as Section 3.6.

Can you look to see whether you can draw something together for a small
new section called "Guidance on Manageability"