The MPLS WG Archive

[Curtis Villamizar <curtis@fictitious.org>]

In message <4B6D09F3B826D411A67300D0B706EFDEB03BB0@nt-exch-yow.pmc-sierra.bc.ca
>, Shahram Davari writes:
> 
> > > 
> > > Before revising the document, I suggest answering all the 
> > follow up comments.
> > > 
> > > -Shahram
> > 
> > 
> > Shahram,
> > 
> > I suggest not.  It would be more productive to revise the document
> > reflecting the (sometimes long and largely unproductive) threads
> > rather than respond to every message.  After the document is revised,
> > provide an opportunity for new comments or for comments to be repeated
> > if clarifications didn't help or prior (valid) comments were not
> > reflected in the revision.
> > 
> > Its clear this document wasn't ready for last call, but at least the
> > false start drew some useful dialog (and some less so) and could
> > substantially improve the document if the comments are reflected.
> > 
> > Curtis
> > 
> 
> Up to you, but that would leave the comments raised as unresolved. And 
> people will certainly repeat those comments that have not been responded 
> to, which would then require a couple of more last calls.
> 
> -Shahram
>


I'm not suggesting comments should be ignored.  For example:

   This document describes a mechanism that can be used to detect data
   plane failures in MPLS LSPs.  The mechanisms described here are
   intended to detect forwarding faults in an MPLS LSP which prevent
   traffic from being delivered to its intended destination and
   isolate the fault to the LSR at which traffic stops flowing.  No
   attempt is made to determine that cause of the fault or diagnose
   problems any further.  Enumeration of all possible fault types is
   outside the scope of this document.

Removing "simple and efficient" in the first sentence addresses a long
message voicing an objection.

The last two sentences address some diatribe on this list about
lsp-ping != Y.1711 by agreeing that lsp-ping != Y.1711.  Its a
feature.

I think a lot of comment resulted from a poor understanding of how
traceroute mode was supposed to work.  I responded earlier by saying
that "like IP tracroute" was sufficient for me but needed to be in the
document.  So we'll put it there.

There was a lot of noise on this list.  If there were useful
comments that were missed they can be repeated.

We don't want to repeat the bgp-17 experience where comments were made
and the document remained unchanged for 10 months and no one was quite
sure what had been agreed to and what was being reviewed.

Curtis