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

From: "Wijnen, Bert (Bert)" <[email-masked]>
Date: Fri, 25 Aug 2006 18:04:04 +0200

Nothing fatally flawed I think.

But just some comments.

>   o draft-ietf-ccamp-gmpls-alarm-spec-04.txt
>     GMPLS - Communication of Alarm Information (Proposed Standard)
>      - 2 of 8 
>     Token: Ross Callon

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.
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).

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

page 14:

    .Pa "Acknowledgments"

   Valuable comments and input were received from a number of people,
   including Wes Doonan, Bert for the DISMAN reference, Tom Petch for
   getting the disman WG interactions started.  We also thank David
   Black for his valuable comments.

.Pa ??
nroff page eject maybe?

- some reference/citation problems:

!! Missing Reference for citation: [BCP26]
  P015 L022:    an IANA Considerations Section in RFCs" [BCP26].

Bert

_______________________________________________
MIB-DOCTORS mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/mib-doctors

---

From: "Adrian Farrel" <[email-masked]>
Date: Fri, 25 Aug 2006 23:28:32 +0100

Thanks for your thoughts, Bert.

>        following values are defined:

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.

> 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.

> Strange they express this in BITs as opposed to OCTETS.

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

> 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?

> nroff page eject maybe?

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

>  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