The MPLS WG Archive

["Wijnen, Bert (Bert)" <bwijnen@lucent.com>]

Here is my review

- compiles clean. Thanks!!
- introduction
  s/a MIB/a MIB module/
- the reference for RFC2119, that is [21] does not show
  up in the references. TO be consistent, you may want
  to make it [RFC2119]
- need to add an IPR section as per RFC2026 Section 10
  Such is needed for all stds track documents)
- Although you do explain in comments that IANA needs to assign
  a number, it probably will make things go easier, if you
  repeat that in an IANA Considerations Section, in which
  you list that IANA needs to assign a number under the transmission
  subtree.
- references need to be split in nromative and informative
- Just a note that MIB Boilerplate will prbably change in the
  next week or so. It is much shorter, so that is good (I think)
- mplsBitRate is still pretty strange, as discussed at the meeting
  on Saturday 16th, I think you know how to change it to be clearer
  In any event, it is probably better to use an Unsigned32, cause
  a negative value seems to make no sense at all.
- MplsOwner. As I explained at the meeting, I may still not be
  clear on what the text says. I think the "In all other respects"
  sentence seems to say that an operator may delete rows (entries)
  that have been created by other methods. Operator may do so
  via SN MP or OTHER methods. But operator is not supposed to
  make changes to rows created by other methods. 
  Did I get that? If so, can it be made clearer? 
  If not... then certainly it needs to be made clearer
- MplsLsrIndex
  Mmm... in which MIB module is this used?
- MplsTunnelIndex
  Probably better to make the base type Unsigned32 (1..65535)
  that is also more consistent with the MplsTunnelIndexOrZero


Thanks,
Bert