ops-dir review of
        MPLS Forwarding Compliance and Performance Requirements
                     draft-ietf-mpls-forwarding-06

This was a good match in terms of review assignments;
it's a draft I meant to spend some time with, and now 
it appears ready for publication.

This draft identifies and explains the many details
(and potential pit-falls) of MPLS forwarding for the
implementer, and also for the system designer and 
deployer (likely the operator or service provider) 
audiences. To improve the relationship among the 
target audience members, the draft includes sections
providing questions to examine designs and recommendations
for testing.  Section 2.6.6. puts it well:

   The customer (system supplier or provider) should not dictate design,
   but should independently validate target functionality and
   performance.  However, it is not uncommon for service providers and
   system implementers to insist on reviewing design details (under NDA)
   due to past experiences with suppliers and to reject suppliers who
   are unwilling to provide details.

Thus, the point here is to avoid operational issues
through adequate preparation, and if implementers played
the role of designer and deployer with sufficient range
of variables through to the test recommendations, 
interactions among the audience members would be efficient.

I found a a few nits in 54 pages:

S1.3, item 4, and a couple of other places
(2.4.5.1 item 6) (2.4.5.2, item 2):
I suggest
s/hard requirements/non-negotiable requirements/
in an ESL scenario, "hard" could be interpreted as "difficult" 

S1.4
suggest s/customer's customer's/secondary customer's/

S2.1.2
suggest
s/forum is/fora are/
though most don't use "fora"

S2.1.7 last paragraph
s/give/given/

S2.1.8.1, 2nd paragraph, 2nd sentence
Reordering requires ...
should be
Restoring order requires  or  Re-sequencing requires
because "reordering" is the term for the impairment.
see RFC4737 later in the section, resequencing is used.

later in 5th para:
Packet reorder should . . .  should be
Packet reordering should . . .

S2.6.1, under Cryptographic Auth
s/can is some/can in some/

S2.7 discussed both high capacity and long-lived flows
but then its not clear that item 1 applies to high capacity
until reading to the end.  perhaps
s/very large/high capacity/

S4.2
suggest
s/IETF MIB/various IETF MIBs/

that's it,
Al



   

ops-dir review of
        MPLS Forwarding Compliance and Performance Requirements
                     draft-ietf-mpls-forwarding-06

This was a good match in terms of review assignments;
it's a draft I meant to spend some time with, and now 
it appears ready for publication.

This draft identifies and explains the many details
(and potential pit-falls) of MPLS forwarding for the
implementer, and also for the system designer and 
deployer (likely the operator or service provider) 
audiences. To improve the relationship among the 
target audience members, the draft includes sections
providing questions to examine designs and recommendations
for testing.  Section 2.6.6. puts it well:

   The customer (system supplier or provider) should not dictate design,
   but should independently validate target functionality and
   performance.  However, it is not uncommon for service providers and
   system implementers to insist on reviewing design details (under NDA)
   due to past experiences with suppliers and to reject suppliers who
   are unwilling to provide details.

Thus, the point here is to avoid operational issues
through adequate preparation, and if implementers played
the role of designer and deployer with sufficient range
of variables through to the test recommendations, 
interactions among the audience members would be efficient.

I found a a few nits in 54 pages:

S1.3, item 4, and a couple of other places
(2.4.5.1 item 6) (2.4.5.2, item 2):
I suggest
s/hard requirements/non-negotiable requirements/
in an ESL scenario, "hard" could be interpreted as "difficult" 

S1.4
suggest s/customer's customer's/secondary customer's/

S2.1.2
suggest
s/forum is/fora are/
though most don't use "fora"

S2.1.7 last paragraph
s/give/given/

S2.1.8.1, 2nd paragraph, 2nd sentence
Reordering requires ...
should be
Restoring order requires  or  Re-sequencing requires
because "reordering" is the term for the impairment.
see RFC4737 later in the section, resequencing is used.

later in 5th para:
Packet reorder should . . .  should be
Packet reordering should . . .

S2.6.1, under Cryptographic Auth
s/can is some/can in some/

S2.7 discussed both high capacity and long-lived flows
but then its not clear that item 1 applies to high capacity
until reading to the end.  perhaps
s/very large/high capacity/

S4.2
suggest
s/IETF MIB/various IETF MIBs/

that's it,
Al