RE: [PWE3] Re: PW-TC-MIB and PW-MIB

Assuming the pwStdMIB is the root of all PW MIB and will be fixed in the two MIB modules at all relevant places, here are additional comments:

The order is not based on priority or importance of issues, it is based on page order:

TC draft:

1-in the TC MIB it will be wise to have the heading "PW-TC-STD-MIB" and in the PW MIB have "PW-STD-MIB", now they are mixed somehow with mpls wording.

2-The description of pwTcMIB includes reference to mpls TC, it should be removed (page 3)

3-text of dormant (4) status should be fixed a bit

4-for PWVlanCfg I think Unsigned32 is a better syntax (page 4)

5-Security section reference mpls by mistake, text should be fixed according to RFC 4181 (page 9)

6-Authors' Address section is odd, should be fixed (page 10)

7-IANA section , there is a statement:

"In the future, PWE3 related standards track PW modules should be
rooted under the pwStdMIB subtree...."

I think you meant to say MIB modules not PW modules.

Also, there is some better wording examples in 4181, maybe you can realign with that.

PW-MIB draft:

1-same as issue 1 above (heading)

2-section 4 on page 3, the PW MIB Structure, I think it is better to describes the layers as they are in the arch draft and not have the order mixed.

3-section 4.1 should be clarify regarding the conditions and constrains of creating conceptual row manually or via signaling. The existing explanation is not very clear

4-pwindex that is being referenced in section 4.2 should be written as pwIndex.

5-section 5 for some reason discuss ENET-STD-MIB, was that the real intention?

6-section 5--its second paragraph references PW as ifIndex, I have not seen any explicit request to IANA to add such type.

7-section 6-it will be a good idea to add the actual value of the enum numbers in the example

8-pwIndexNext, I think syntax of TestAndIncr is better here

9-the two priority objects use as default value 0 which is the highest priority. It is not clear what happen if few PWs have the same priority but resources are limited.

Is it implementation specific? Also, both use PW and VC, we better use just PW.

10-Many objects have special values for not applicable cases, do we really want to have those or use the option of no such for instances that are not relevant?

11-REFERENCE clause in few places use draft name, maybe it is better to use the title and not the draft name

12-Reference section better use title too and "work in progress" rather than ID version

13-Authors' Address section is odd, should be fixed

14-IANA section should be fixed

From: Thomas D. Nadeau [mailto:tnadeau at cisco.com]
Sent: Monday, October 24, 2005 16:05
To: Orly Nicklass
Cc: pwe3 at ietf.org; davidz at corrigent.com
Subject: Re: [PWE3] Re: PW-TC-MIB and PW-MIB

On Oct 24, 2005, at 9:38 AM, Orly Nicklass wrote:

Tom,

Before we get to other issues, I think you missed my point regarding the root name. XXX and YYY are minor typo that you happen to have.

The root name is either

pwMIB

or pwStdMIB.

pwStdMIB.

In the IANA consideration section you refer to pwStdMIB, but it the modules you used pwMIB. If indeed you meant pwMIB, then the module identity should be different and so are the nodes coming off it as shown below.

OK.

--tom

see in line, I marked in RED the way I think it should be.

From: pwe3-bounces at ietf.org [mailto:pwe3-bounces at ietf.org] On Behalf Of Thomas D. Nadeau
Sent: Monday, October 24, 2005 15:15
To: Orly Nicklass
Cc: pwe3 at ietf.org; davidz at corrigent.com
Subject: [PWE3] Re: PW-TC-MIB and PW-MIB

On Oct 23, 2005, at 4:40 PM, Orly Nicklass wrote:

Tom,

There is naming confusion with the recent MIBs in draft version 06 that affects other MIBs rooted under the same name space.

I assume the desired root should be pwStdMIB and not pwMIB, or alternatively all should be rearranged.

I copied below few sections from PW-MIB and from the PW-TC-MIB that show the inconsistency:

draft-ietf-pwe3-pw-mib-06 has the following:

pwMIB MODULE-IDENTITY ...

         ::= { pwMIB 799 } -- RFC Editor: To be assigned by IANA [Orly Nicklass] --should be pwStdMIB and not pwMIB
                              -- the value 2 is requested for this
                              -- specific Module. Please replace XXX
                              -- with the assigned value.

    Dang, that is a typo: 799 should be "XXX"[Orly Nicklass] right


   -- Top-level components of this MIB.

   -- Notifications
   pwNotifications OBJECT IDENTIFIER
                                 ::= { pwMIB 0 }
   -- Tables, Scalars
   pwObjects       OBJECT IDENTIFIER
                                 ::= { pwMIB 1 }
   -- Conformance
   pwConformance   OBJECT IDENTIFIER
                                 ::= { pwMIB 2 }

-----------------------------------------------------------------------------------------------------

draft-ietf-pwe3-tc-mib-06 has the following:

pwTcMIB MODULE-IDENTITY ...

::= { pwMIB XXXX } -- RFC Editor: please replace [Orly Nicklass] --should be pwStdMIB and not pwMIB

                            -- XXXX with IANA assigne value.

                            -- See IANA considerations sect.

pwMIB OBJECT IDENTIFIER [Orly Nicklass] --should be pwStdMIB and not pwMIB

         -- This object identifier needs to be assigned by IANA.
         ::= { transmission YYYY }

    Yes, "XXXX" should be "YYYY"

11. IANA Considerations

IANA is requested to make a MIB OID assignment under the
transmission branch, that is, assign the pwStdMIB under
{ transmission TBD }.
-- RFC Editor: Please assign TBD based on IANA-requested assignment

In the future, PWE3 related standards track PW modules should be
rooted under the pwStdMIB subtree. The IANA is requested to manage
that namespace.

11.1 IANA Considerations for PW-TC-STD-MIB

This document also requests IANA to assign { pwStdMIB 1 } to the PW
MIB specified in this document.

  -----------------------------------------------------------------------

Other problematic issues in those drafts are not addressed in this mail, but they do exist and need some fixing.

    Cool. Please post them ASAP. We are trying to close out the base MIBs

now so we need as much review as possible.

    --Tom

Orly Nicklass,

Associate VP R&D,

RAD Data Communications Ltd,

24 Raoul Wallenberg St.

Tel Aviv, 69719, Israel

Tel : +972 3 765 9969; Fax : +972 3 644 0930

email: orly_n at rad.com

RAD's web site : www.rad.com