[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: FW: AD review of: draft-ietf-snmpconf-diffpolicy-07.txt




On Thursday, October 2, 2003, at 03:32 PM, Wijnen, Bert (Bert) wrote:

> Is it just me who missed an announcement, or has no follow up occured?
> WHy can we not keep momentum once we're moving?

I went through your comments and this was my reply. I wanted to discuss
it first with my co-editor, but not had a response yet. David P??

Although, I have an nroff version I do not seem to have a proper
template to generate the internet-draft (which my co-editor always did).
So there was no new draft.

I have put up the last information/version at
http://www.lisanza.net/snmpconf/

Sorry for the delay. See more details below.

Harrie
>
> Thanks,
> Bert
>
> -----Original Message-----
> From: Wijnen, Bert (Bert) [mailto:bwijnen@lucent.com]
> Sent: donderdag 28 augustus 2003 1:22
> To: snmpconf@snmp.com
> Subject: AD review of: draft-ietf-snmpconf-diffpolicy-07.txt
>
>
> We're getting close. Still afe nits.
>
> - sect 2, first para seems to end with an incomplete sentence?


Correct. It should have said:

"Without the Policy-based
Management MIB module a management application must emulated
its behavior by doing equivalent SNMP operations by means of
manager/agent communication."

>
> - sect 3 refers to RFC3512 as a BCP. Well, fist of all it is not
>   good to talk too much about the maturity level of documents
>   inside an RFC. that maturity level is an external label,
>   that may change over the lifetime of an RFC.
>   But in any case, way back when we decided to make RFC3512 an
>   Informational RFC, and that is what it is.

OK, I took out the BCP reference and change the reference
with the RFC.

>
> - You have kept the PM-MIB as a normative reference.

My fault, thought I changed it.

>  Based on the
>   text, that still seems to make sense... but.. this means that this
>   doc will be depending on the PM-MIB to be approved as PS as well.
>   So if I bring this one ot IESG, and if we approve it, then it will
>   hang in RFC-Editor queue till PM-MIB is ready for RFC as well.
>   I can accept the way it is... just let me know if that is indeed
>   what you wanted/intended.

If I understand the 'rules' correctly of standard level, I agree.
The problem is that the draft wants to address the usage
of the PM-MIB, however, one could use it without the PM-MIB.
This is provided as an example. But since it describes things
of the PM-MIB it indeed depends on it.
If this is the case I am not sure how to work around this.
If others have ideas, I would like to hear them.

> - Security section. So do I understand there is no sensitivity to
>   reading any of the objects in this MIB? If such is the case, it
>   might be good to state so. Now you only talk about write access.

You understood that correctly, my view is there are no values in
this MIB module for templates.
One could only retrieve the info like "there is a template".

I have added this:
"There is no sensitivity in reading any of the objects, while
it only provide information like "there is a template".
This is due to the fact that the managed objects that compose
the template are in the DIFFSERV-MIB. For more detail is
refered to [RFC3289]."

Is this OK?? And if others think differently, please speak up.

>
> - If you're gonna rev once more anyway, then
>    diffServConfigId OBJECT-TYPE
>        SYNTAX         SnmpAdminString (SIZE(1..116))
>        MAX-ACCESS     not-accessible
>        STATUS         current
>        DESCRIPTION
>           "A unique id for the per-hop-behavior policy.  The range
>           of up to 116 octets is chosen to stay within the SMI
>           limit of 128 subidentifiers in an object identifier."
>        ::= { diffServConfigEntry 1 }
>   s/SMI/SNMP/, cause the SMI does not limit it, it is the SNMP PDU
>   that does not allow for more than 128 subids in an OID in a
>   varBind. I should have seen this last time.

I leave as is, after reading list comments (from Jeff and Bert).

>
> - StorageType, I stated:
>      But in any event, you need to say something about write
>      access for permanent entries. See the StorageTypeTC in RFC2579
>   I see nothing about it. What I mean is some text in DESCRIPTION
>   clause aka:
>        Conceptual rows having the value 'permanent' need not
>        allow write-access to any columnar objects in the row.
>   if such is indeed the case.

I thought I addressed it with the extra text and the storage type
TC itself. Anyway, I added now:
"Rows that have a storage type of 'permanent' do not need
to allow write-access to any of its columnar objects."

>
> - I do not see that you addressed:
>   11. RowStatus
>      Need to say which (if any) objects can be changed while a
>      row is active. See RowStatus TC in RFC2579
>   It may be as simple as
>       All writable objects in this row may be modified at
>       any time.
>   If such is indeed the case.

Yes. I have added:
"All writable objects in this row may be modified at any time."