Subject: review of mpls-mgmt-overview revision 02

From: "Wijnen, Bert (Bert)" <[email-masked]>
Date: Fri, 29 Nov 2002 16:29:55 +0100

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

---

From: "Adrian Farrel" <[email-masked]>
Date: Fri, 29 Nov 2002 22:14:47 -0500

Bert,
Thanks. All nits are most welcome. I, for one, welcome your efforts to get RFCs
in clear and correct English.

A couple of follow-up questions/comments in the snipped text below...

Cheers,
Adrian
----- Original Message -----
From: "Wijnen, Bert (Bert)" <[email-masked]>

> A lot of it is indeed nits/spelling/grammar

Hmmm. I know what you SHOULD be able to asume...

>   Better get that in sync. True for most mib module names I believe

Ah! I made this global change after I thought I heard Tom suggest that you said
that the use of underscore was a requirement. At least one of us is out of synch
here - I will change back to hyphen.

>  Are mplsTunnelResourceTable and mplsTunnelCRDLPResTable both "resource"

Agreed. This draft, however, can only report what is in the MIB modules
themselves.

Tom and Joan - relying on you to pick up these things and then I'll change the
overview to match.

>   missing it here, if no, then why is that not needed?

Good question.
No there is no RSVP resource table. CR-LDP resource specification is a superset
of RSVP resource specification.
I will add a note explaining.

>   What is the "size of route"?

Syntax is "size of route that", but I agree that this could be clearer.

>   then they will have to be ready for RFC at the same time that this

You're right. Old reference from when we thought we were going to include them
in detail.

>   correct. The correct split is:
[SNIP]
>   the curretn text looks like.

I will wait as late as I can and then include the most up-to-date version.
But...
Do you consider that the boilerplate is appropriate for inclusion in this
overview or should I aim to hack it down? Actually, if the new material is
shorter, perhaps it will be fine.