Synchronous Optical Network (SONET)/Synchronous Digital Hierarchy (SDH) Encoding for Link Management Protocol (LMP) Test Messages
draft-ietf-ccamp-lmp-test-sonet-sdh-04

[Ballot discuss]
I should have seen the below in my AD review. Appology that I missed it.

From Pekka (OPS directorate):

> o draft-ietf-ccamp-lmp-test-sonet-sdh-03.txt
>
>See above, the same issue about IANA namespace creation.

[IESG Secretary Note in Regards to Above Comment: Pekka is referencing comments made for draft-ietf-ccamp-lmp-wdm-02.txt, also a document for intended Proposed
Standard.  The comments can be read in Bert's DISCUSS held for that document.]

Similar change is needed in this doc indeed.

I will update with an RFC-Editor note later to clear my own discuss

New revision addresses AD comments.

I suspect IANA will want cvlarification of IANA Considerations section. It should refer back to the base LMP document which explains the rules for assignments.

Wg chairs are sending a response to a T1X1 liason statement reagrding review of this document.
Some changes that result will become part of the new revision.

AD review posted to WG mailing list

-----Original Message-----
From: Wijnen, Bert (Bert) [mailto:bwijnen@lucent.com]
Sent: donderdag 13 maart 2003 23:12
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/ ??
- 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
  ...
- 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.
- 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?
- last sentence before sect 4.1.3.1... pls check:
    Section .            4.1.3.1
  Actually also check the sentence before that
- 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 
- Security considerations are unacceptable.
  - No new security considerations compared to what?
  - Which security considerations DO apply?
- 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?
- copyright section has a year of 2001 !!??


Thanks,
Bert