Re: Status of draft-ietf-ccamp-alarm-spec-00

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

A few additional comments. 

>  > -- Also, are there interactions/race conditions between this alarm
>  > communication with other mechanisms conveying problems along an LSP?
>  > Some discussion in the doc. would be valuable.

Nothing to discuss. Unless you can suggest a problem that we should
be worried about. 

>  > -- The document mentions briefly that the LSP state must
>  > be retained for the communicated alarm information to be useful.
>  >
>  > I think this is an important point, and worth expanding on in the doc.
>  > I don't think there is any discussion right now of how one might
>  > ensure that state has not been torn down by the time the alarm
>  > information is correlated and ready to be communicated upstream
>  > and downstream.

If the state has been torn down, there is clearly no LSP about which to
communicate alarm state. 

>  > -- And, can the document provide some examples of the types of alarms
>  > it is talking about/referring to? I think this will help a reader
>  > understand better the why behind this approach. 
>
> examples are illustrative anyway, if any they would be included in 
> appendix, imho such examples would better fit in an applicability 
> statement document

Agreed.
Besides, there is no limit to the alarms that this could be applied to.
Very specifically - any alarm that impacts or is related to the LSP. 

Thanks,
Adrian