Re: Comments on draft-ietf-ccamp-lmp-test-sonet-sdh-04.txt.

["Adrian Farrel" <adrian@olddog.co.uk>]

Phil

> > > 1)  Firstly the question.  In section 1 (the 4th
> > > paragraph), the text
> > > indicates that SONET / SDH extensions to link verification and link
> > > property correlation require both section 3 and section 4 (Trace
> > > Monitoring).  However, it seems to me that the extensions described
> > > in section 3 alone are enough to perform link verification and link
> > > property correlation for SONET / SDH links.  Specifically, though
> > > the TraceMonitor<xx> and TraceMismatch messages defined in section
> > > 4 can be used to perform an external verification of SONET / SDH
> > > links, it is not clear why these messages are necessary in addition
> > > to the LMP link verification procedure (as extended by section 3).
> > > Could you please explain this?
> >
> > It is slightly unclear what you are asking.
> > Note that the Trace object is defined in section 4 and is
> > required for J0, J1 and J2 Test procedures as decribed in
> > section 3. Thus, both sections 3 and 4 are necessary for the
> > new link verification procedures.
> >
> > It is possible that you are baulking at "This requires a new
> > trace monitoring function that is also discussed in this
> > document." "Requires" may be slightly too strong.

> [PJC]
> I agree that the <Trace> object defined in section 4 is
> required by section 3.

OK. Sounded like you were saying that it seemed to you that the extensions
described in section 3 alone are enough to perform link verification and
link property correlation for SONET / SDH links.

> However, section 1 says that the 'trace monitoring function'
> is required by LMP SONET / SDH specific link verification
> and link correlation.  I understand 'trace monitoring function'
> to refer to the new TraceMonitor messages (and not just the
> Trace object), and hence my confusion.

Yup. As I say, "required" is too strong.

> If as you imply, the only part of section 4 required
> for LMP SONET / SDH specific link verification and
> link correlation is the Trace object, then I would
> recommend the text in section 1 be changed to reduce
> confusion.

We will try to catch this in authors' 48 hours.

> In any case, I remain unsure of the background and
> proposed uses of the TraceMonitor and other messages
> defined in section 4 - can you help here?

The motivation for trace monitoring is unchanged from overhead monitoring
in TDM. The purpose of the messages in LMP is to allow LMP control of this
feature. The net result is better fault management.

> Assuming there are valid reasons for this function I think
> we should beef up the introductory text in section 1 to
> describe them.

The ship has sailed; and besides, if you come to this draft with a
reasonable understanding of TDM (which you should given section 2) this is
not an issue.

> > > 2)  Secondly, I have a minor comment on section 4.  I
> > > understand from
> > > section 4.1.1 that a TraceMonitor message should contain a single
> > > <TRACE> object.  However, section 4.1.2 can be read to imply that a
> > > TraceMonitor message can contain more than one <TRACE> object.  Can
> > > I suggest the following replacement text for section 4.1.2?
> > >
> > >   The TraceMonitorAck message (Message Type TBA by IANA) is used to
> > >   acknowledge receipt of the TraceMonitor message and indicate that
> > >   the TRACE object in the TraceMonitor message have been received
> > >   and processed correctly (i.e. no Trace Mismatch).
> >
> > There is absolutely nothing wrong with the existing text.
> > "All of the TRACE Objects in the TraceMonitor message" is
> > perfectly fine when there is only one such object allowed.
> > Leaving the text as it is reduces any changes should the
> > number of Test objects on a TraceMonitor ever be increased.
>
>[PJC]
> I agree there's nothing strictly wrong with the existing text,

Good.

> but it's misleading to have one part of the document state
> there is exactly one object, and then have another referring
> to multiple objects.

I'm sorry you were mislead.

> I would vote to remove all ambiguity and change the text.

We don't vote :-)

> Yes, I agree that if the number is increased in the future,
> the wording has to be changed, but I believe the improved
> clarity makes it worth it.  However, this isn't an important issue
> and I don't feel strongly about this.

Excellent.

Thanks,
Adrian