The MPLS WG Archive

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

Here are my comments/nits that you can/should consider for
the next revision. A lot of it is indeed nits/spelling/grammar
stuff... do I have to repat that for all docs, or can I assume
that the authors/editors will seriously check those things
themselves?

Here we go.

- there is only ONE MIB. You keep talking about MIBs
  or "Management Information Bases". Please make sure to
  use consistent terminology... the correct termonology is:

   - Management Information Base (MIB)
   - MIB Module(s), when talking about one or more MIB modules
     as specified in a I-D or an RFC.

  This comment probably applies to other MPLS MIB documents as well

- In the abstract you talk about "the management architecture for MPLS"
  Is it indeed that wide? If so, then it should include all mechanisms
  that people can use for managing/configuring MPLS. I think the document
  is what the title says, namely an overview. Maybe instead of
  "management overview" it is even better to say "MIB overview".
  Anyway... I don;t think it is an architecture

- In this document you often say "this draft". Better to use terms like
  "this document" or "this memo" or such, so that it still is correct
  when published as RFC.

- I see you use mib module names with an underscore, for example
  MPLS-LDP_MIB, but the real module name is MPLS-LDP-MIB 
  Better get that in sync. True for most mib module names I believe

- 2nd para on page 6 (still sect 4.3
  s/map to one more/map to one or more/ ??

  Can you add some text how that mapping is done? Liek via shared index,
  or via augments, or via mapping table ?

- 2nd para sect 4.5
  sentence ends as: "... in question or." Seems incorrect
  s/objects needed for TE tunnels/objects needed for managing TE tunnels/ ??

- Sect 4.9
  "Interfaces Group of MIB II" ??
  This is just the IF-MIB as per RFC2863. No need to reference or talk about
  MIB II I think.

  "Thus, the MPLS interface" --> maybe better: "Thus, a MPLS interface"

- Make descriptors consistent. Like
   - mplsLdpEntityFrameRelayXxxxx
   - mplsLdpEntityConfFrXxxx
  so either make all freme-relay stuff xxxFrameRelayYyy or xxxFrYyy
  but do not mix all that. I also wonder why in some case
  Fr comes before the Xxxx and in other cases after it.
   - mplsLdpEntityFrameRelayXxxxx
   - mplsLdpEntityConfFrXxxx
  why not mplsLdpEntityFrameRelayConfXxxx

  A lot of that has to do with making it easier for users to see which 
  objects are in which tables and to which set of objects they belong.

- Sect 6.1, last sentence 4th bullet
  Add "and FrameRelays respectively" ??

- Sect 6.3
  Pls add some text if such notifications are generated per session or 
  per entity or whatever it is.

- sect 6.4
  Would be good to show which tables augment which other tables
  And explain how the others relate to each other (index sharing, 
  rowpointers, extension...)?

- Sect 7.1
  are mplsTunnelResourceTable and mplsTunnelCRDLPResTable both "resource"
  tables? If so, then why not use "Resource" in both cases, or just "Res"
  in both cases?  Consistency please!!!!!

  Question: Is there also a mplsTunnelRSVPResTable? If yes, then I am
  missing it here, if no, then why is that not needed?
  
  So Tunnel Computed Hop Table is: mplsTunnelCHopTable
  and Tunnel Actual Hop Table is: mplsTunnelARHopTable
  is the R for Route? If so then add Route in there

- sect 7.2
  ".. mplsTunnelMaxHops defines the size of route that may be configured
   on the LSR."
  I have difficulty understanding what that means. 
  What is the "size of route"?

- Your references to PWE3 and PPVPN WG docs are listed as normative.
  I doubt that they really are. In any event, if they are normative,
  then they will have to be ready for RFC at the same time that this
  doc goes to RFC.

- Your split of references for the SNMP boilerplate text is not
  correct. The correct split is:

> > 
> > Normative        Informative
> > ----------       ------------
> >  1905                1155
> >  1906                1157
> >                      1212
> >                      1215
> >  2571                1901
> >  2572                2570
> >  2573
> >  2574
> >  2575
> >  2578
> >  2579
> >  2580
> > 

- We're working on the new MIB boilerplate. Much shorter. Not 100% stable
  yet. If you prefer to use it (I assume the new boiler plate will be
  stable by the time you go to RFC-Editor queue), then I can send you what
  the curretn text looks like.

Thanks,
Bert