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

From: "Wijnen, Bert (Bert)" <[email-masked]>
Date: Thu, 2 Oct 2003 15:32:36 +0200

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

Thanks,
Bert 

-----Original Message-----
From: Wijnen, Bert (Bert) [mailto:[email-masked]]
Sent: donderdag 28 augustus 2003 1:22
To: [email-masked]
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?

- 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.

- You have kept the PM-MIB as a normative reference. 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.

- 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.

- 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.

- 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 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.

Bert

---

From: Harrie Hazewinkel <[email-masked]>
Date: Thu, 2 Oct 2003 16:43:30 +0200

> 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
> - 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."

>   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

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.

>   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.

>   varBind. I should have seen this last time.

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

>   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."

>   If such is indeed the case.

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

---

From: "David Partain (LM/EAB)" <[email-masked]>
Date: Fri, 3 Oct 2003 08:18:00 +0200

> WHy can we not keep momentum once we're moving?

Hi all,

This is _entirely_ my fault, and I'll work today to get the
latest out.  Watch an I-D repository near you.

Cheers,

David