Draft:  draft-ietf-ccamp-gmpls-alarm-spec-03.txt
Reviewer: Black_David@emc.com
Review Date: Wednesday 8/9/2006 11:00 AM CST
IETF LC Date: 8/9/2006

Summary: On the right track, but has open issues due to no usable email address for the only draft author is a fatal problem.  Otherwise, basically ready for publication, but has nits that should be fixed before publication.

The draft is generally well-written and to the point.  All
of these comments are minor.
- Section 3.1.  Say why the two-leading-one-bits form is used
	for ALARM_SPEC objects in this section in addition to
	Section 3.1.4.  It would be ok to move the text from Section
	3.1.4 up into Section 3.1.  Also, if there's a good explanation
	for why C-Type 1 and 2 are Reserved, that explanation should
	be added.
- Section 3.1.1 should give guidance for and examples of appropriate
	use of Severity values.
- Section 3.1.2 has a number of SHOULDs and SHOULD NOTs.  There needs
	to be an explanation of why these strong recommendations are
	being made (which would imply consequences of not following
	the recommendations) and/or a description of what goes wrong
	when they're not followed.  The overall explanation appears
	to be a desire to supply enough basic information to allow
	the recipient to understand the alarm (this info can be quite
	important as the recipient may be dealing with a crisis of
	which the alarm is a part).  The "MAY" for the ref
	count TLV needs to be explained  (why would it be used?).
- Section 3.1.2 on p10 discusses adding alarm objects to the
	"state of LSPs".  The quoted phrase needs to be defined -
	I think the addition is to the LSP state communicated by
	RSVP Path and Resv messages.