RE: AD review of: draft-ietf-ccamp-lmp-test-sonet-sdh-01.txt

["Jonathan Lang" <Jonathan.Lang@RinconNetworks.com>]

[ post by non-subscriber.  with the massive amount of spam, it is easy to miss
  and therefore delete posts by non-subscribers.  if you wish to regularly
  post from an address that is not subscribed to this mailing list, send a
  message to <listname>-owner@ops.ietf.org and ask to have the alternate
  address added to the list of addresses from which submissions are
  automatically accepted. ]

Bert,
 We have addressed your comments (see inline) and have uploaded the
updated version.

-Jonathan & co-authors

> -----Original Message-----
> From: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org] On
Behalf
> Of Wijnen, Bert (Bert)
> Sent: Thursday, March 13, 2003 2:12 PM
> To: Ccamp-wg (E-mail)
> Subject: AD review of: draft-ietf-ccamp-lmp-test-sonet-sdh-01.txt
> 
> Here are my comments. Pls address them and do a quick
> revision. I do not intend to issue IETF Last Call before
> IETF meeting in SF is over.
> 
> - 2nd para in sect 1
>   s/is being developed/has been developed/ ??
changed to read "has been developed"

> - You have 16-bit fields for which you specify values as:
>     0x01
>     0x02
>     ...
>   And it is then not clear (to me) which bit you actually mean
>   Maybe better to do:
>    0x0001
>    0x0002
>    ...
done

> - I see a few times "Note that no change is required to the
>   TestsStatusSuccess and TestStatusFailure messages".
>   That however seems very obvious, because they will ALWAYS go
>   over the control channel. I think there is never a change to
>   those messages is there... but with making this statement, one
>   gets the impression that sometimes they will be changed.
This was meant to clarify that nothing was changed.  But, to avoid
confusion, we have removed the text.

> - sect 4.1.1.1. I see:
>        The type of the trace message.  The following values are
>        defined.  All other values are reserved and should be sent as
>        zero and ignored on receipt.
> 
>        1 = SONET Section Trace (J0 Byte)
>        2 = SONET Path Trace (J1 Byte)
>        3 = SONET Path Trace (J2 Byte)
>        4 = SDH Section Trace (J0 Byte)
>        5 = SDH Path Trace (J1 Byte)
>        6 = SDH Path Trace (J2 Byte)
> 
>   The text about "All other valies are reserved and should be sent
>   as zero..." is OK for field that have bitmasks or such, but here
>   you seem to be using the field as an integer field, no?
Thanks for catching this.  This has been changed.

> - last sentence before sect 4.1.3.1... pls check:
>      Section .            4.1.3.1
>   Actually also check the sentence before that
these are Microsoft issues that I'm trying to track down/fix.

> - page 11/12/13 I see strange formatting that causes lines to
>   go beyond col 72, and I am not sure that proper sections
>   are referenced when I see
>       Section 4.          ..1.3.1
Same as above.

> - Security considerations are unacceptable.
>   - No new security considerations compared to what?
>   - Which security considerations DO apply?
This has been modified to reference LMP security.

> - IANA considerations
>   - pls be specific as to in which name space(s) you want
>     IANA to assign code points. And within such a name space,
>     specify from which block (e.g. Consensus based? user sapce?
We have updated this.

> - copyright section has a year of 2001 !!??
Wishful thinking ;-)

It has been updated to read 2003.

> 
> 
> 
> 
> 
> Thanks,
> Bert