AD review of draft-ietf-rap-feedback-fr-pib-04.txt

["Bokaemper, Martin" <MBokaemper@juniper.net>]

[Sorry for the duplicate(?) ... I was still subscribed with 
 an old email address]
-----Original Message-----
From: Bokaemper, Martin 
Sent: Thursday, December 19, 2002 12:03 PM
To: Wijnen, Bert (Bert); Rap-wg (E-mail)
Subject: RE: AD review of draft-ietf-rap-feedback-fr-pib-04.txt

Hello Bert,

> Thanks for the revision.

Sorry, I forgot to post a change summary in the 
pre/post meeting hustle.

> My comments inline below.
>
> Current real concerns:
> - Section 3.2 start off with new text stating that SNMP Counter32 and
>   Counter64 are not supported by SPPI. What is this based on?
>   I do not understand that statement at all.

RFC3159 (SPPI) sections 7.1.1 and 7.1.5 say
"The Counter[32/64] type is not supported by the SPPI"
When addressing the comment on the Counter types in the
previous revision I stumbled over these sections and read 
them as 'these types are not to be used in PIB modules'. 

> - And as I explain below in my answers/comments, I am not sure that
>   your new definitions of Usage32/Usage64 make sense. Pls explain
>   in relation to the above and to my comments inline below.
[and from below]
> Mmm... I see that you now have defined two TCs Usage32 and Usage64
> that look very much like a Counter32 or a Counter64, if not that,
> then they look very much like a ZeroBasedCounter32 (as defined in RMON
> MIB, RFC2021) and ZerobasedCounter64 (as defined in HNUM-TC, RFC2856)
> 
> Is this wise?

The intention of the Usage32/64 TCs is to allow absolute
readings for cases when the PDP either explicitly or
implicitly knows the creation time of the object, so the
main difference to Counter32/64 is the initial value of 0.

ZeroBasedCounter[32/64] allow that too, so I agree they 
are more appropriate to use here - I have not been 
aware of these TCs before.
I'll remove the Usage TCs again and will import and use
ZeroBasedCounter[32/64] instead.   Any issues with that?

> > Could I have a response to this review today? Do you think you can fix
> > a new rev today, that would allow me to put it on IESG agenda for 27 Dec

I'll prepare a new revision with the changes mentioned here
this afternoon, so it can go to internet-drafts@ietf.org and this
list today.

On the 'minor things':
> - pls answer my questions inline below
> - In the Abstract, it is probably better to change
>      This document describes a Policy Information Base (PIB) to control 
>      policy usage collection and reporting in a device. 
[...]          
>   into something aka:
>      This document describes a portion of the Policy Information Base 
>      (PIB) to control policy usage collection and reporting in a device. 
[...]
>   The idea being (similar as with the MIB), that there is only ONE PIB
>   and several/multiple PIB Modules that together make up the PIB.

Will change this.

> > - I am missing a REVISION clause in the MODULE-IDENTITY macro
> 
> You have added that now. Thanks.
> But the LAST-UPDATED and the REVISION date/time need to be in sync.

Will be fixed.

[...]
> > - Not sure if it is me, but I do not understand the DESCRIPTION
> >   clauses of frwkFeedbackActionListGroup and frwkFeedbackActionListRefID
> >   How does that work? Can you be more elaborate so I can understand
> Mmm... I guess the WG members understand it... 
> It's a tidbit better though.

Still a convoluted sentence - will make some improvements here.

> > - can you explain (in the description clause) how the seOID is used
> >   for the selection process for object/attribute 
> >   frwkFeedbackSelUsageComboCapsSelection
> 
> it is a bit better

Not sure what/how to improve here - will leave unchanged.

[...]
> > - sect 3.2 at the end (i.e. top of page 10)
> >   missing 2) ??
> aha, now no longer ordered lists ;-)
> Anyway, a 1) does make people to expect a 2) and possibly more

The underlying issue is that there is one group that has
only one PRC in it, so numbering will always look odd.

[...]
> > - references must be split in normative and informative, again 
> >   see: http://www.rfc-editor.org/policy.html
> 
> Thanks for doing so. I now am missing reference [RFC2119] ??!!

Will add this.

[...]
> > - I am missing an IPR section as per RFC2026 sect 10.
> > 
> I see you did not add it. If we go for Informational, that is OK (I think)
> It would not be OK for STDS track

The 'ok' from all authors on this section did not arrive in 
time before the deadline, so it was not added. That should not 
be a problem since it's informational.

Fixing 'nits' in drafts opens the eye to other nits:
RFC3084 (COPS-PR), which is on the standards track, does not
seem to have any IPR statement. An accident?

ciao,
Martin.
--