Synchronous Optical Network/Synchronous Digital Hierarchy (SONET/SDH) Circuit Emulation over Packet (CEP) MIB Using SMIv2
draft-ietf-pwe3-cep-mib-16

[Ballot comment]
This is a placeholder comment to note that the following were not addressed as of version 15 of the document.

Lars Eggert
Comment (2011-02-03)

Section 7., paragraph 54:
>          An agent with CEP capability MUST be capable of supporting
>          at least n intervals. The minimum value of n is 4, the
>          default of n is 32 and the maximum value of n is 96.

  I don't get this. How can you state a MUST requirement for a specific
  value, and then give a range for that value?


SB> I see no text change.

Adrian Farrel

Comment (2011-02-02)



Section 2

  The mechanism for structured
  emulation (as outlined in the CEP draft)

Hmmm? do you mean RFC 4842?


---

Section 7

You can remove the two notes to the RFC Editor in the IMPORTS
clause as you have already fixed up the RFC numbers yourselves.

SB> The Editors note is still there for PWMIB - isn't that an RFC?

---

TEXTUAL CONVENTIONS

I'm a bit disappointed that the TCs defined here don't come with
REFERENCE clauses.

---

PwCepFracAsyncMap, pwCepType, pwCepFracMode, pwCepFracSdhVc4Mode, and
pwCepPerfIntervalReset

Although not a requirement, it is usual for INTEGER enumerations to
start at zero. Sometimes other schemes are used to stay in synch with
protocols - if so, it is nice to say so and give a reference.

SB> Does not seem to be addressed

---

pwCepValidIntervals

Telling us the default value for a read-only object is a little
distracting.

---

pwCepPeerCepOption

How is this object set when the PW is statically provisioned?

---

pwCepPerfCurrentAbsPtrAdjust. pwCepPerfIntervalAbsPtrAdjust, and
pwCepPerf1DayIntervalAbsPtrAdjust

Are the Description clauses in English?

---

pwCepPerfIntervalNumber OBJECT-TYPE
    SYNTAX        Integer32 (1..96)
    MAX-ACCESS    not-accessible
    STATUS        current
    DESCRIPTION
        "A number (normally between 1 and 96 to cover a 24 hour
        period) which identifies the interval for which the set
        of statistics is available. The interval identified by 1
        is the most recently completed 15-minute interval and
        the interval identified by N is the interval immediately
        preceding the one identified by N-1. The minimum range of
        N is 1 through 4. The default range is 1 through 32. The
        maximum value of N is 1 through 96."

I'd be interested in the non-normal case given the SYNTAX !

I find the text about ranges clumsy. Anyway, since the object is
not-accessible, it is moot.

---

pwCepPerf1DayIntervalUASs looks like it needs a Reference clause

[Ballot comment]
Section 7., paragraph 54:
>          An agent with CEP capability MUST be capable of supporting
>          at least n intervals. The minimum value of n is 4, the
>          default of n is 32 and the maximum value of n is 96.

  I don't get this. How can you state a MUST requirement for a specific
  value, and then give a range for that value?

[Ballot comment]
I'm entering a 'Yes' ballot because this work is technically sound and useful. However, I found a slew of nits that really should be worked on to make the RFC more valuable.

---

The various write-ups and announcements should be updated to reflect the new responsible AD

---

The double page-throws are a nuisance

---

Section 1

Need to expand CEP on first use

---

Section 2

  The mechanism for structured
  emulation (as outlined in the CEP draft)

Hmmm? do you mean RFC 4842?

---

Section 2

s/Since A SONET/Since a SONET/

---

6.3.  PW-STD-MIB Modules Usage

s/Modules/Module/

---

Section 7

The comments on the IMPORT clauses are welcome, but should not show
in square brackets as they are not references (because the MIB module
is standalone with section 10.

---

Section 7

You can remove the two notes to the RFC Editor in the IMPORTS
clause as you have already fixed up the RFC numbers yourselves.

---

MODULE-IDENTITY DESCRIPTION CLAUSE

-- RFC Editor: Please replace yyyy with actual RFC number and
-- remove this note

I think this is xxxx

---

TEXTUAL CONVENTIONS

I'm a bit disappointed that the TCs defined here don't come with
REFERENCE clauses.

---

PwCepFracAsyncMap, pwCepType, pwCepFracMode, pwCepFracSdhVc4Mode, and
pwCepPerfIntervalReset

Although not a requirement, it is usual for INTEGER enumerations to
start at zero. Sometimes other schemes are used to stay in synch with
protocols - if so, it is nice to say so and give a reference.

---

pwCepEntry

        however change of some objects (for example
        pwCepCfgIndex) during PW forwarding state MAY cause traffic
        disruption.

s/MAY/may/

---

pwCepValidIntervals

Telling us the default value for a read-only object is a little
distracting.

---

pwCepPeerCepOption

How is this object set when the PW is statically provisioned?

---

pwCepCfgIndex

Should indicate what meaning is assigned to the value zero since
zero is not a valid index to pwCepCfgTable

---

pwCepCfgJtrBfrDepth

        The actual jitter buffer MUST be at least twice this
        value for proper operation.
                                     
I think this warrants a REFERENCE

---

pwCepFracSdhVc4Tu3Map1 and similar objects

        "If the first TUG-3 within the VC-4 contains a TU-3, this
          variable must be set to the required mode. "

    DEFVAL { other }

So, I was going to say s/must/MUST/ but since you have a DEFVAL
defined for each case, I don't understand the meaning of the text.

---

pwCepPerfCurrentAbsPtrAdjust. pwCepPerfIntervalAbsPtrAdjust, and
pwCepPerf1DayIntervalAbsPtrAdjust

Are the Description clauses in English?

---

pwCepPerfIntervalNumber OBJECT-TYPE
    SYNTAX        Integer32 (1..96)
    MAX-ACCESS    not-accessible
    STATUS        current
    DESCRIPTION
        "A number (normally between 1 and 96 to cover a 24 hour
        period) which identifies the interval for which the set
        of statistics is available. The interval identified by 1
        is the most recently completed 15-minute interval and
        the interval identified by N is the interval immediately
        preceding the one identified by N-1. The minimum range of
        N is 1 through 4. The default range is 1 through 32. The
        maximum value of N is 1 through 96."

I'd be interested in the non-normal case given the SYNTAX !

I find the text about ranges clumsy. Anyway, since the object is
not-accessible, it is moot.

---
                                                 
UNITS clauses would be nice in objects like pwCepPerfIntervalTimeElapsed
and pwCepPerfIntervalInPtrAdjustSecs

---

pwCepPerf1DayIntervalNumber OBJECT-TYPE
    SYNTAX      Unsigned32(1..31)
    MAX-ACCESS  not-accessible
    STATUS      current
    DESCRIPTION
      "History Data Interval number. Interval 1 is the current day
      measurement period, interval 2 is the most recent previous
      day; interval 30 is 31 days ago. Intervals 3..31 are
      optional."
    ::= { pwCepPerf1DayIntervalEntry 1 }

What does "optional" mean in a not-accessible object?

---

pwCepPerf1DayIntervalUASs looks like it needs a Reference clause

---

Section 10.1
As indicated by idnits...                                                                         

The RFC number is missing from the BCP14 reference.

---

[Ballot comment]
1. I cannot understand why PwCepCfgIndexTC is a Textual Convention. It appears exactly once and has a very trivial syntax of runing index.

2. The following phrase in section 5 is confusing, I suggest to fix it because it describes an important issue:

'-  The MIB module is designed to be work with the PW-STD-MIB [PWMIB]
      module.'

Probably s/to be work with/to work in conjunction with/

3. DESCRIPTION clause of PwCepFracAsyncMap - the following phrase is confusing and must be clarified:

          The value of 'other' MUST
          be used if the Use of this object is not applicable

4. The indices pwCepTableIndex and pwCepFracIndex are defined as 'primary' in the DESCRIPTION clauses. It is not clear to me what this means because they are both the only indices in their respective tables.

[Ballot discuss]
modified DISCUSSED - cleaning up issues solved in version 13

1. I find the DESCRIPTION clause of the pwCepConfigError insufficient. Adding a description of the significance of setting each of the bits in the BITS construct would clarify the issue.

2. I have a hard time understanding the functionality of the pwCepConformanceCfgTable and I may no tbe alone. I suggest more clarification text about what type of information is entered by an agent in the 'description' objects? An example would be highly useful and also an indication about what is the manager supposed to do with this information.

-------- Original Message --------
Subject: Moving draft-ietf-pwe3-cep-mib (Proposed Standard) forward
Date: Fri, 25 Jul 2008 11:23:24 +0200
From: Mark Townsley
To: draft-ietf-pwe3-cep-mib@tools.ietf.org, Dan Romascanu , "pwe3-chairs@tools.ietf.org"



This is part of a general review of documents on my plate in the IESG in
advance of the Dublin meeting.  I am giving advice here on how to move
forward based on the current read of the tracker. See DISCUSS and
COMMENT actions cc'd from the tracker below.


Authors, Dan's comments are simple and actionable. Could you provide me
some RFC Editor Note text of the form "Old Text:" "New Text"? I can then
insert that, and perhaps we can even get this cleared before the PWE3
meeting.

Thanks,

- Mark


Dan Romascanu:
Discuss:
[2008-07-02] (modified DISCUSSED, I dropped the previous issue #3)

1. I find the DESCRIPTION clause of the pwCepConfigError insufficient.
Adding a description of the significance of setting each of the bits in
the BITS construct would clarify the issue.

2. I have a hard time understanding the functionality of the
pwCepConformanceCfgTable and I may no tbe alone. I suggest more
clarification text about the following:

2a. What does 'CEP PW statistics objects are supported (conformed to) or
not' mean? What is the behavior of the agent wrt. the respective objects
if an object is not supported? What is returned on a Get operation on a
'not supported' object?

2b. What type of information is entered by an agent in the 'description'
object? An example would be highly useful and also an indication about
what is the manager supposed to do with this information.

Comment:
[2008-07-01]
1. I cannot understand why PwCepCfgIndexTC is a Textual Convention. It
appears exactly once and has a very trivial syntax of runing index.

2. Introduction - mentioning the PWE3 WG and mailong list for comments
does not seem appropriate as the WG and the list may not be permanent.

3. The following phrase in section 5 is confusing, I suggest to fix it
because it describes an important issue:

'-  The MIB module is designed to be work with the PW-STD-MIB [PWMIB]
    module.'

Probably s/to be work with/to work in conjunction with/

4. DESCRIPTION clause of PwCepFracAsyncMap - the following phrase is
confusing and must be clarified:

        The value of 'other' MUST
        be used if the Use of this object is not applicable

5. The indices pwCepTableIndex and pwCepFracIndex are defined as
'primary' in the DESCRIPTION clauses. It is not clear to me what this
means because they are both the only indices in their respective tables.

6. There is a large number of counter objects in this MIB module which
can benefit from having optional UNITS clauses added to the definition
of the objects.

[Ballot discuss]
(modified DISCUSSED, I dropped the previous issue #3)

1. I find the DESCRIPTION clause of the pwCepConfigError insufficient. Adding a description of the significance of setting each of the bits in the BITS construct would clarify the issue.

2. I have a hard time understanding the functionality of the pwCepConformanceCfgTable and I may no tbe alone. I suggest more clarification text about the following:

2a. What does 'CEP PW statistics objects are supported (conformed to) or not' mean? What is the behavior of the agent wrt. the respective objects if an object is not supported? What is returned on a Get operation on a 'not supported' object?

2b. What type of information is entered by an agent in the 'description' object? An example would be highly useful and also an indication about what is the manager supposed to do with this information.

[Ballot comment]
1. I cannot understand why PwCepCfgIndexTC is a Textual Convention. It appears exactly once and has a very trivial syntax of runing index.

2. Introduction - mentioning the PWE3 WG and mailong list for comments does not seem appropriate as the WG and the list may not be permanent.

3. The following phrase in section 5 is confusing, I suggest to fix it because it describes an important issue:

'-  The MIB module is designed to be work with the PW-STD-MIB [PWMIB]
      module.'

Probably s/to be work with/to work in conjunction with/

4. DESCRIPTION clause of PwCepFracAsyncMap - the following phrase is confusing and must be clarified:

          The value of 'other' MUST
          be used if the Use of this object is not applicable

5. The indices pwCepTableIndex and pwCepFracIndex are defined as 'primary' in the DESCRIPTION clauses. It is not clear to me what this means because they are both the only indices in their respective tables.

6. There is a large number of counter objects in this MIB module which can benefit from having optional UNITS clauses added to the definition of the objects.

[Ballot discuss]
1. I find the DESCRIPTION clause of the pwCepConfigError insufficient. Adding a description of the significance of setting each of the bits in the BITS construct would clarify the issue.

2. I have a hard time understanding the functionality of the pwCepConformanceCfgTable and I may no tbe alone. I suggest more clarification text about the following:

2a. What does 'CEP PW statistics objects are supported (conformed to) or not' mean? What is the behavior of the agent wrt. the respective objects if an object is not supported? What is returned on a Get operation on a 'not supported' object?

2b. What type of information is entered by an agent in the 'description' object? An example would be highly useful and also an indication about what is the manager supposed to do with this information.

3. In the Security Consideration section I believe that the following is an overkill:

      'Administrators should consider
      whether read access to these objects should be allowed, since read
      access may be undesirable under certain circumstances.

I do not know what the administrators can do to forbid read-access. The implementers can do nothing if the object is defined to be read. I think that strongly recommending use of encryption and authentication, as well as usage of VACM and USM is secure enough.

IANA Last Call comments:

Upon approval of this document, the IANA will make the following
assignments in the registry at
http://www.iana.org/assignments/smi-numbers
Sub-registry: "Prefix: iso.org.dod.internet.mgmt.mib-2 (1.3.6.1.2.1)"

Decimal Name Description References
------- ---- ----------- ----------
TDB pwCepStdMIB PW-CEP-STD-MIB [RFC-pwe3-cep-mib-12]

We understand the above to be the only IANA Action for this
document.

PROTO Statement: draft-ietf-pwe3-cep-mib-12

The PWE3 Chairs would like to request Standards Track publication
of this document.

(1.a) Who is the Document Shepherd for this document? Has the
Document Shepherd personally reviewed this version of the
document and, in particular, does he or she believe this
version is ready for forwarding to the IESG for publication?

Danny McPherson (danny@tcb.net) is the Shepherd. I have
reviewed the document and it is ready for publication.

(1.b) Has the document had adequate review both from key WG members
and from key non-WG members? Does the Document Shepherd have
any concerns about the depth or breadth of the reviews that
have been performed?

This document (-10 revision) has been reviewed by the WG, both through
the LC process (ending 2007-06-22), and at IETF WG meetings. There
were minor comments during the two week LC that has completed. All
other comments were addressed in response to the LC query and seem
to have satisfied the initiators.

I have no concerns about state of readiness of this document.

(1.c) Does the Document Shepherd have concerns that the document
needs more review from a particular or broader perspective,
e.g., security, operational complexity, someone familiar with
AAA, internationalization or XML?

I have no concerns regarding the requirement for further review of
this document, although MIB Doctor review needs to occur and a
good bit of coordination has already occurred on that front per
MIB Doctor author participation on this document.

(1.d) Does the Document Shepherd have any specific concerns or
issues with this document that the Responsible Area Director
and/or the IESG should be aware of? For example, perhaps he
or she is uncomfortable with certain parts of the
document, or
has concerns whether there really is a need for it. In any
event, if the WG has discussed those issues and has indicated
that it still wishes to advance the document, detail those
concerns here.

I have no specific concerns about this document, nor are there
concerns that should be conveyed to the IESG or Responsible AD.

(1.e) How solid is the WG consensus behind this document? Does it
represent the strong concurrence of a few individuals, with
others being silent, or does the WG as a whole understand and
agree with it?

This document is fully understood and supported by the PWE3
WG. There is no contention as to whether this work provides utility
and it is generally supported across the WG.

(1.f) Has anyone threatened an appeal or otherwise indicated
extreme
discontent? If so, please summarise the areas of conflict in
separate email messages to the Responsible Area Director.
(It
should be in a separate email because this questionnaire is
entered into the ID Tracker.)

No one has indicated to the WG chairs or WG mailing list that they
have intentions of appealing any proposed publication of this
document.

(1.g) Has the Document Shepherd personally verified that the
document satisfies all ID nits? (See
http://www.ietf.org/ID-Checklist.html and
http://tools.ietf.org/tools/idnits/). Boilerplate checks are
not enough; this check needs to be thorough. Has the
document
met all formal review criteria it needs to, such as the MIB
Doctor, media type and URI type reviews?

No. MIB Doctor review has been initiated, although not yet
complete. There has been involvement of MIB Doctor folks
with this document already.

(1.h) Has the document split its references into normative and
informative?

Yes.

Are there normative references to documents that
are not ready for advancement or are otherwise in an unclear
state? If such normative references exist, what is the
strategy for their completion? Are there normative
references
that are downward references, as described in [RFC3967]? If
so, list these downward references to support the Area
Director in the Last Call procedure for them [RFC3967].

No. Normative references to PWMIB and PWTC are only comments,
with both documents currently in the IESG Processing queue.


(1.i) Has the Document Shepherd verified that the document IANA
consideration section exists and is consistent with the body
of the document? If the document specifies protocol
extensions, are reservations requested in appropriate IANA
registries? Are the IANA registries clearly identified? If
the document creates a new registry, does it define the
proposed initial contents of the registry and an allocation
procedure for future registrations? Does it suggested a
reasonable name for the new registry? See
[I-D.narten-iana-considerations-rfc2434bis]. If the document
describes an Expert Review process has Shepherd conferred
with
the Responsible Area Director so that the IESG can appoint
the
needed Expert during the IESG Evaluation?

The IANA Consideration Section of the document provides the
following IANA and RFC Editor Guidance, which we believe to
be straight-forward and reasonable:

---
The MIB module in this document uses the following IANA-assigned
OBJECT IDENTIFIER values recorded in the SMI Numbers registry:

Descriptor OBJECT IDENTIFIER value
---------- -----------------------

pwCepStdMIB { mib-2 XXXX }

Editor's Note (to be removed prior to publication): The IANA is
requested to assign a value for "XXXX" under the 'mib-2' subtree and
to record the assignment in the SMI Numbers registry. When the
assignment has been made, the RFC Editor is asked to replace "XXXX"
(here and in the MIB module) with the assigned value and to remove
this note.
---

(1.j) Has the Document Shepherd verified that sections of the
document that are written in a formal language, such as XML
code, BNF rules, MIB definitions, etc., validate correctly in
an automated checker?

No, although we have verified this with the authors. We have
also initiated MIB Doctor review on this document.

(1.k) The IESG approval announcement includes a Document
Announcement Write-Up. Please provide such a Document
Announcement Writeup? Recent examples can be found in the
"Action" announcements for approved documents. The approval
announcement contains the following sections:

Technical Summary

This memo defines a portion of the Management Information Base (MIB)
for use with network management protocols in the Internet community.
In particular, it describes managed objects for modeling SONET/SDH
circuits over a Packet Switch Network (PSN).

Working Group Summary

This document has been reviewed by the experts in the PWE3 WG
and there are no outstanding issues.

Protocol Quality

This is a very simple and well written, no protocol issues are
anticipated and no outstanding technical issues exist..

Personnel
Who is the Document Shepherd for this document?

Danny McPherson (danny@tcb.net)

Who is the Responsible Area Director?

Mark Townsley (townsley@cisco.com)