Re: [PWE3] Advancing MIB documents



    Hi,

    We will put the comments (or new draft updates) together this week and
get them to you/IESG ASAP.

    --Tom

 
> 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
> pwe3@ietf.org
> https://www.ietf.org/mailman/listinfo/pwe3

_______________________________________________
pwe3 mailing list
pwe3@ietf.org
https://www.ietf.org/mailman/listinfo/pwe3