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

From: "Orly Nicklass" <[email-masked]>
Date: Sun, 30 Oct 2005 00:35:26 +0200

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:[email-masked]] 
Sent: Monday, October 24, 2005 16:05
To: Orly Nicklass
Cc: [email-masked]; [email-masked]
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: [email-masked] [mailto:[email-masked]] On
Behalf Of Thomas D. Nadeau
	Sent: Monday, October 24, 2005 15:15
	To: Orly Nicklass
	Cc: [email-masked]; [email-masked]
	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: [email-masked]

		RAD's web site : www.rad.com <outbind://80/www.rad.com> 

_______________________________________________
pwe3 mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/pwe3

---

From: "Romascanu, Dan \(Dan\)" <[email-masked]>
Date: Mon, 31 Oct 2005 11:10:24 +0200

I do not believe that this is enough good reason to go against a clear
recommendation of RFC 2578 and RFC 4181. This is exactly the case
described in RFC 4181 when it says:
 
In the past,
     some IETF working groups have made their own assignments from
     subtrees delegated to them by IANA, but that practice has proven
     problematic and is NOT RECOMMENDED.
 
Regards,
 
Dan

  _____  

	From: Thomas D. Nadeau [mailto:[email-masked]] 
	Sent: Monday, October 31, 2005 1:05 AM
	To: Romascanu, Dan (Dan)
	Cc: Orly Nicklass; [email-masked]; [email-masked]; Wijnen,
Bert (Bert)
	Subject: Re: [PWE3] Re: PW-TC-MIB and PW-MIB

	    Because it allows all of the related modules to be grouped
together, 
	which seems to make logical sense. 

	    --Tom

		Why?

  _____  

			From: Thomas D. Nadeau
[mailto:[email-masked]] 

				[DR] actually RFC 4181 discourages the
practice of placing MIB modules under a subtree other than mib-2. See
section 4.5:
				 
				- The value assigned to the
MODULE-IDENTITY descriptor MUST be unique
				     and (for IETF standards-track MIB
modules) SHOULD reside under the
				     mgmt subtree [RFC2578].  Most often
it will be an IANA-assigned
				     value directly under mib-2
[RFC2578], although for media-specific
				     MIB modules that extend the IF-MIB
[RFC2863] it is customary to use
				     an IANA-assigned value under
transmission [RFC2578].  In the past,
				     some IETF working groups have made
their own assignments from
				     subtrees delegated to them by IANA,
but that practice has proven
				     problematic and is NOT RECOMMENDED.

			    I understand; however, we chose to follow
the model described for
			the MPLS MIB Modules in RFC3811.

			    --Tom

---

From: "Wijnen, Bert (Bert)" <[email-masked]>
Date: Mon, 31 Oct 2005 13:20:00 +0100

I think we have sort of grand-fathered the MPLS MIB case.
 
I do not see why a new set of MIB modules for PW would not just follow
the recommendations of RFC4181.
 
Bert

-----Original Message-----
From: Thomas D. Nadeau [mailto:[email-masked]]
Sent: Monday, October 31, 2005 00:05
To: Romascanu, Dan (Dan)
Cc: Orly Nicklass; [email-masked]; [email-masked]; Wijnen, Bert (Bert)
Subject: Re: [PWE3] Re: PW-TC-MIB and PW-MIB

    Because it allows all of the related modules to be grouped together, 
which seems to make logical sense. 

    --Tom

Why?

  _____  

From: Thomas D. Nadeau [ mailto:[email-masked] <mailto:[email-masked]> ] 

[DR] actually RFC 4181 discourages the practice of placing MIB modules under a subtree other than mib-2. See section 4.5:
 
- The value assigned to the MODULE-IDENTITY descriptor MUST be unique
     and (for IETF standards-track MIB modules) SHOULD reside under the
     mgmt subtree [RFC2578].  Most often it will be an IANA-assigned
     value directly under mib-2 [RFC2578], although for media-specific
     MIB modules that extend the IF-MIB [RFC2863] it is customary to use
     an IANA-assigned value under transmission [RFC2578].  In the past,
     some IETF working groups have made their own assignments from
     subtrees delegated to them by IANA, but that practice has proven
     problematic and is NOT RECOMMENDED.

    I understand; however, we chose to follow the model described for
the MPLS MIB Modules in RFC3811.

    --Tom