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

["Philip Crocker" <[e-mail]>]

Adrian,

Thanks very much for your comments - please see my replies below, marked with [PJC].

Phil.


> -----Original Message-----
> From: Philip Crocker 
> Sent: 17 February 2005 12:11
> To: Philip Crocker
> Subject: FW: Comments on draft-ietf-ccamp-lmp-test-sonet-sdh-04.txt.
> 
> 
> 
> -----Original Message-----
> From: Adrian Farrel [mailto:[e-mail]]
> Sent: 17 February 2005 10:29
> To: Philip Crocker; [e-mail]
> Cc: [e-mail]
> Subject: Re: Comments on draft-ietf-ccamp-lmp-test-sonet-sdh-04.txt.
> 
> 
> Phil,
> How nice to hear from you.
> 
> > I have recently been looking in detail at 
> draft-ietf-ccamp-test-sonet-sdh-04.txt, 
> > and have a question and a comment on the draft.  I'd really 
> appreciate it if
> > you could spare the time to look at both these points.
> >
> > 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.  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.

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.  

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?  Assuming there are valid reasons for this function I think we should beef up the introductory text in section 1 to describe them.

> 
> 
> > 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, 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 would vote to remove all ambiguity and change the text.  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.

> 
> Cheers,
> Adrian
>