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

From: "Orly Nicklass" <[email-masked]>
Date: Sat, 18 Feb 2006 19:32:18 +0200

David,
 
Following your reply I assume we should expect new drafts for TC and
core MIB. I forward the mail to the group to try and close the 
PwVlanCfg and the Statistics issue below.  The way we handle the
statistics in the PW MIB should be the way in all other MIBs, so we
better get consensus on the definition.
 
Orly
 
________________________________

From: David Zelig [mailto:[email-masked]] 
Sent: Sunday, February 12, 2006 11:45
To: Orly Nicklass; Thomas D. Nadeau
Subject: RE: [PWE3] Re: PW-TC-MIB and PW-MIB

Orly,
First, thanks for your help in reviewing the MIB modules thoroughly.
Please see inline
 
Thanks
David

	-----Original Message-----
	From: Orly Nicklass [mailto:[email-masked]]
	Sent: Sunday, February 12, 2006 6:15 AM
	To: Thomas D. Nadeau; David Zelig
	Subject: RE: [PWE3] Re: PW-TC-MIB and PW-MIB

	 Hi,
	 
	I scan through the new version and I see that 3 issues left, 3,
6 and 10. Can we close those during the upcoming meeting off line?
	 
	I also have few new issues, questions... from recent drafts:
	1-I think the IANA MIB for types should be in an independent
document not with PW MIB to separate control of progressing of those
documents in the standard track. The IANA types should not affect the PW
MIB progress.
	[DZ] While in some cases there is indeed separate document, RFC
4181 (section 3.5.1) make an example of RFC 1581 for such cases, where
the initial IANA maintained MIB is inside the main document. The fact
that there will be more types in the future will be handled by IANA
independently to the progress of the i-d. 

	2-TC-MIB:
	-Description  says ...initial version, ....should say only
....version. The initial is stated in the REVISION clause.[DZ]  OK 
	-PwVlanCfg--Vlan Tag can fit other services and not only
Ethernet, can we make it more general to fit others too? Also, what
about Priority Tag?[DZ]  This TC is for Ethernet only, and I need the
special values for VLAN manipulations. If you see a need for another
type of application, than a separate TC can handle it in the application
specific MIB module. 
	[Orly Nicklass] if it is for Ethernet only as stated, why do we
keep it in the main TC doc?
	 
	-PwOperStatusTc-regarding dormant, resources can be occupied by
higher or same priority Pws, not just higher.
	    also, I do not think the notPresent is the right naming for
the described case, it is more like notReady. Can you change that? it
implies missing info in various tables etc.
	[DZ] OK, Tom: OK with you? 
	-PwStatus-I think we should rename the customer part of the enum
with service end point to have it in compatible with psn naming.[DZ] OK 
	-PwFragSize- can you change ."..to the value set."  to" ....size
in bytes"?[DZ] OK 
	-PwFragStatus-the word both in the last paragraph in the
description better be removed as 3 things are there and not just
two.[DZ]  OK 
	 
	3-PW-MIB
	-The section of Conventions is redundant within the
introduction, it appears twice.[DZ]  OK 
	-last paragraph of 4.1, change "than" to "then"[DZ] OK 
	-4.2-I think we should change notPresent to notReady same as in
TC although I believe it is to match ifStatus, but the semantics is
different.[DZ]  As before 
	-4.2-pwVcOperStatus, Vc part should be removed[DZ]  OK 
	-in IANA-PWE3_MIB, description, we better write initial version
and not original version.[DZ] OK 
	-the IANAPwTypeTC has FRDLCI twice , 1 and 25[DZ] : it is
duplication also in the IANA document - 1 is for martini mode and I will
change the name of the bit to frDlciMartiniMode[Orly Nicklass]  pls do.
	 
	-pwStdMib, the description has copyright twice, remove the first
occurrence.[DZ] OK 
	-..CurrentInPackets missing the  say on the MUST be equal  part
as was done for other 32 bits counters.
	[DZ]  
	-Regarding the Statistics-it is more appropriate to have time
elapsed on current data than on interval.
	[DZ]  From our experience we should have both, The current
elapsed time appears in the pw Table (pwTimeElapsed ), and there is a
need at the interval level when time of day have changed or non-complete
interval because of other reasons.
	[Orly Nicklass] I think we should decide if we want to keep
incomplete intervals. How do we treat that kind of data? we do not know
the reason nor the validity of this data. I think such cases better be
ignored. If the data is not good data it does not matter the period it
represents.
	 
	- we can spare space by elimination non valid data, since in any
case those can not be used. We can simply skip those bad intervals and
not save the bad data. 
	[DZ] The fact that it is bad interval does not mean that the
data inside is not valuable, it just mean it is not reliable enough. for
example: although the number of errors may not be accurate for some
reason, it is important tot see that there were at least some errors. 
	[Orly Nicklass] doesn't bad interval means problems anyway?
maybe we should ask the group.
	 
	-Description of ....MoniSec is not clear, is it aligned with a
day start or or somehow related to 96 intervals. It could be that time
less than 24H is ok for 1st interval, but bad data for the others-there
is no reference for such. [DZ] OK, I see the point, I will fix it. 
	[Orly Nicklass]   ok 
	
________________________________

	From: [email-masked] [mailto:[email-masked]] On
Behalf Of Orly Nicklass
	Sent: Sunday, October 30, 2005 00:35
	To: Thomas D. Nadeau
	Cc: [email-masked]; [email-masked]
	Subject: 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.--done
	2-The description of pwTcMIB includes reference to mpls TC, it
should be removed (page 3)-done
	 
	3-text of dormant (4) status should be fixed a bit[Orly
Nicklass] -I have not seen a change 
	[DZ] Missed it...
	4-for PWVlanCfg I think Unsigned32 is a better syntax (page
4)-done
	5-Security section reference mpls by mistake, text should be
fixed according to RFC 4181 (page 9)-done
	6-Authors' Address section is odd, should be fixed (page
10)-done
	7-IANA section , there is a statement:--done
	"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.done
	 
	PW-MIB draft:
	1-same as issue 1 above (heading)--done
	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.-done by using ref.
	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-done but typo err left 
	 
	4-pwindex that is being referenced in section 4.2 should be
written as pwIndex.-done
	5-section 5 for some reason discuss ENET-STD-MIB, was that the
real intention? -done
	6-section 5--its second paragraph references PW as ifIndex, I
have not seen any explicit request to IANA to add such type.-[Orly
Nicklass]   the text still reference PW as ifType ((2nd paragraph) will
there be a request for such from IANA? .
	[DZ] - there is a request in the IANA section, may be too
hidden...
	 
	7-section 6-it will be  a good idea to add the actual value of
the enum numbers in the example-not done
	 
	8-pwIndexNext, I think syntax of TestAndIncr is better
here-[Orly Nicklass] not done for re-use gap.
	 
	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.-implementation specific
	 
	Is it implementation specific? Also, both use PW and VC, we
better use just PW.-done
	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?-for discussion
	[DZ]  I am basically OK with this (Tom: any inputs from other
MIBs you have done in the IETF regarding this?). In the Ethernet case
(PW-ENET) I could not did much because of the complexity of modes and
the need for consistent view, but on the PW-MIB we can go over the items
and decide it on a per case basis.
	 
	11-REFERENCE clause in few places use draft name, maybe it is
better to use the title and not the draft name-done
	12-Reference section better use title too and "work in progress"
rather than ID version-done
	
	13-Authors' Address section is odd, should be fixed -done
	14-IANA section should be fixed-done

	
	
________________________________

	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] <mailto:[email-masked]> ] On Behalf
Of Thomas D. Nadeau
		Sent: Monday, October 24, 2005 15:15
		To: Orly Nicklass
		Cc: [email-masked] <mailto:[email-masked]> ;
[email-masked] <mailto:[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: "David Zelig" <[email-masked]>
Date: Sun, 19 Feb 2006 13:15:21 +0200

Orly,
Updated (this month) versions of TC and the core MIB are already published.
Have no problem to move the PwVlanCfg to the pw-enet-mib.
Regarding the statistics, would like to get more opinions, I still believe that we need time elapsed both for interval (where it means the actual interval length) and current
 
David
 
Snipped to end...

---

From: "Orly Nicklass" <[email-masked]>
Date: Mon, 20 Feb 2006 17:50:36 +0200

From: David Zelig [mailto:[email-masked]] 
Sent: Sunday, February 19, 2006 13:15
To: Orly Nicklass; Thomas D. Nadeau
Cc: [email-masked]
Subject: RE: [PWE3] Re: PW-TC-MIB and PW-MIB

Orly,
Updated (this month) versions of TC and the core MIB are already
published.
Have no problem to move the PwVlanCfg to the pw-enet-mib.
Regarding the statistics, would like to get more opinions, I still
believe that we need time elapsed both for interval (where it means the
actual interval length) and current
   [Orly Nicklass] 
   Incomplete interval might imply discontinuity, invalid data etc., in
such case what is the point of saving the duration of such?
   I suggest to close it in the next meeting to allow all PW MIBs to
align with one definitio/approach.

David
 
Snipped to end...

---

From: "David Zelig" <[email-masked]>
Date: Tue, 21 Feb 2006 08:58:03 +0200

Orly,
Even complete valid intervals may not always exactly 15 minutes/day
(depending on the table), there might be situations of 1-2 second slip
depending on the implementation. This is the reason for keeping time
elapsed also at the interval table.
 
David

From: Orly Nicklass [mailto:[email-masked]] 
Sent: Monday, February 20, 2006 5:51 PM
To: David Zelig; Thomas D. Nadeau
Cc: [email-masked]
Subject: RE: [PWE3] Re: PW-TC-MIB and PW-MIB

Orly,

David
 
Snipped to end...