[MIB-DOCTORS] Re: draft-ietf-ccamp-gmpls-alarm-spec-04.txt [was: PRELIMINARY Agenda and Package for August 31, 2006 Telechat ]

Thanks for your thoughts, Bert.

>>   o draft-ietf-ccamp-gmpls-alarm-spec-04.txt
> On page 7, I see:
>
>     Severity: 8 bits
>
>        Indicates the impact of the alarm indicated in the TLV.  See
>        [RFC3877] and [M.3100] for more information on severity.  The
>        following values are defined:
>
>         Value       Definition
>         -----       ----------
>           0         Cleared
>           1         Indeterminate
>           2         Critical
>           3         Major
>           4         Minor
>           5         Warning
>
> And so I wonder if they mean bit values, or if they mean an 8-bit
> unsigned integer? I would assume (hope) the latter.

Yes. I don't think it is usual to specify protocol fields in ASN.1 (although 
that might avoid confusion :-). So here the authors mean the usual thing. 
That is, the field is 8 bits long, and the values are as listed.

> I also wonder why they do not use the same values as you do in RFC3877,
> that is start at 1 and keep zero reserved (for now).

A good question.
I don't suppose there is any good reason except that it usual to use zero in 
a protocol to mean that things are all cleared. This makes good 
forward/backward compatibility with an implementation that zeros out fields.

> On page 9
>
>     Error String: 32 bits minimum (variable)
>
>        A string of characters in US-ASCII, representing the type of
>        error/alarm.  This string is padded to the next largest 4 byte
>        boundary using null characters.  Null padding is not required
>        when the string is 32-bit aligned.  The contents of error
>        string are implementation dependent.  See the condition types
>        listed in Appendices of [GR833] for a list of example strings.
>        Note length includes padding.
>
> Strange they express this in BITs as opposed to OCTETS.

A bit of a hodge-podge, isn't it?

> And I am also wondering of this string is ever meant for human
> consumption. If so, then maybe it better be UTF-8 ??

I think that we would all welcome advice on that.

Actually, I seem to recall that this discussion was held once before.

The intention was to not limit the use of this field to human consumption. I 
don't have access to GR833 at the moment. Perhaps someone could check what 
characger representaiton it uses?

> page 14:
>
>    .Pa "Acknowledgments"
>
> .Pa ??
> nroff page eject maybe?

Hopefully this is within the RFC Editor's capabilities, but it woill be 
fixed if there is a new rev.

> - some reference/citation problems:
>
> !! Missing Reference for citation: [BCP26]
>  P015 L022:    an IANA Considerations Section in RFCs" [BCP26].

Quite right. This should not be referenced. It is instructive to writers of 
I-Ds, not to readers of this I-D.

Cheers,
Adrian

_______________________________________________
MIB-DOCTORS mailing list
MIB-DOCTORS@ietf.org
https://www1.ietf.org/mailman/listinfo/mib-doctors