[PWE3] Advancing MIB documents

[Mark Townsley <[e-mail]>]

The following documents have all been to the IESG for balloting, and 
each have outstanding DISCUSS or COMMENT positions from ADs (mostly from 
our MIB expert, Dan Romascanu)  that need to be addressed before the 
documents can advance. In order for me to help advancing these 
documents, I need new documents or RFC Editor Note text that address 
these review comments - In particular those marked as "Discuss."

1. draft-ietf-pwe3-cep-mib (Proposed Standard)
2. draft-ietf-pwe3-pw-atm-mib (Proposed Standard)
3. draft-ietf-pwe3-tdm-mib-11.txt (Proposed Standard)

Details follow.... (all of this can be found in the IESG datatracker)

1. draft-ietf-pwe3-cep-mib (Proposed Standard)

This went on the IESG telechat last July, and needs either an update or 
RFC Editor text to address Dan's comments below:
>
> 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.


2. draft-ietf-pwe3-pw-atm-mib (Proposed Standard)

A new version has been posted recently, but does not seem to address the 
IESG comments below:

> Discusses and Comments
> Ron Bonica:
> Comment:
> [2008-07-02] support Dan's discuss
>
> Pasi Eronen:
> Comment:
> [2008-07-02] Jeffrey Hutzelman's SecDir review had some suggestions for
> clarifications and editorial improvements; they're not blocking,
> but should be considered in AUTH48 (if not earlier).
>
> Tim Polk:
> Discuss:
> [2008-07-01] The security considerations section refers to pwTDMTable 
> when listing the readable tables and
> objects that are security sensitive.  This table is specified in 
> pwe3-tdm-mib, so I believe this
> is a cut and paste error.  From the susequent text, I infer that the 
> tables that specify the
> connectivity topology are the missing link.  I wonder if the correct 
> reference is pwATMCfgTable?
>
> Comment:
> [2008-07-01] I support Dan's discuss regarding the formatting in the 
> security considerations section.  The text
> is much more readable using the usual parentheses instead of the 
> double quotes.
>
> Dan Romascanu:
> Discuss:
> [2008-07-02]
> The Security Considerations section is departing from the text at 
> http://www.ops.ietf.org/mib-security.html, by replacing in a few 
> places brackets by double quotes. These changes which are 
> non-conformant with RFC4181 are making the texts confusing, which was 
> also remarked in the SECDIR Review. I suggest to stick to the 
> guidelines and to use the standard text.
>
> Comment:
> [2008-07-02] The introduction section mentions the PWE3 WG and mail 
> list for further comments. I believe that this is inapropriate, as the 
> future RFC may be longer lived than the WG.
- draft-ietf-pwe3-tdm-mib-11.txt (Proposed Standard)

Again, there has been a document update, but it does not seem to address 
the comments from the IESG below:

> Ron Bonica:
> Comment:
> [2008-07-02] support Dan's discuss
>
> Pasi Eronen:
> Comment:
> [2008-07-01] Editorial suggestions from Scott Kelly's SecDir review:
> - I would suggest adding a sentence to the introduction which
> articulates the background the reader is assumed to have, for
> example, what RFCs they are expected to be conversant with,
> in order to understand the content of this document.
> - TDM should be expanded with first use
>
> Tim Polk:
> Comment:
> [2008-07-01] As noted in Scott Kelly's secdir review and Dan's 
> preliminary discuss, the replacement of
> parentheses with double quotes is somewhat confusing.  Since Dan is 
> already holding a discuss,
> I am balloting NoObj but would like to note that I support Dan's position.
>
> Dan Romascanu:
> Discuss:
> [2008-07-02] 1. The Security Considerations section is departing from 
> the text at http://www.ops.ietf.org/mib-security.html, by replacing in 
> a few places brackets by double quotes. These changes which are 
> non-conformant with RFC4181 are making the texts confusing, which was 
> also remarked in the Security Review. I suggest to stick to the 
> guidelines and to use the standard text.
>
> 2.
>   pwTDMCfgEntry  OBJECT-TYPE
>     SYNTAX            PwTDMCfgEntry
>     MAX-ACCESS        not-accessible
>     STATUS            current
>     DESCRIPTION
>         "These parameters define the characteristics of a
>           TDM PW. They are grouped here to ease NMS burden.
>           Once an entry is created here it may be re-used
>           by many PWs.
>           Unless otherwise specified, all objects in this table
>           MUST NOT be changed after row activation (see [PWMIB])
>           if the row index is in use by an entry in pwTDMTable.
>           Rows must persist after reboot."
>
>
> The last sentence contradicts the fact that this table has a 
> StorageType object.
>
> Comment:
> [2008-07-02]
> 1. The introduction has text about comments to be made to the WG and 
> the WG list. I believe that this text needs to be dropped, as the 
> future RFC may be longer lived than the WG
>
> 2. In Section 3, s/[SATOP] draft/[SATOP]
>
> 3. Last paragraph in Section 3 uses RFC2119 keywords. I wonder whether 
> this is appropriate, as the text describes terminology and 
> functionality defined someplace else and not in this document,
>
> 4. The procedure described in Section 7 ends with verifying that 
> pwTDMConfigError returns no error. What actions are being taken by a 
> manager and by the agent if there are errors reported in this object? 
> Is the procedure repeated from start, from some place within the 
> algorithm, do any entries need to be cleared and configured again?
>
> 5. The document makes a non-consistent use of the UNITS clause - it is 
> defined for some objects it is not for other.
>
> 6. The DESCRIPTION clause of pwTDMValidDayIntervals defines the 
> minimal value as 1. Why is then the syntax allowing for 0, is there 
> any special significance?






_______________________________________________
pwe3 mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/pwe3