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: pwe3-bounces at ietf.org
[mailto:pwe3-bounces at ietf.org] On Behalf Of Orly
Nicklass
Sent: Sunday, October 30, 2005 00:35
To: Thomas
D. Nadeau
Cc: davidz at corrigent.com; pwe3 at ietf.org
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
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.
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