Subject: [MIB-DOCTORS] FW: Evaluation: draft-ietf-rserpool-mib-11.txt to Experimental RFC

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Mon, 16 Feb 2009 16:17:14 +0100

Technical Summary:

This document defines a SMIv2 compliant Management Information Base
(MIB) providing access to managed objects in an implementation of the
Reliable Server Pool architecture and protocols. It is intended as an
Experimental Track RFC.

Working Group Summary

This document has been reviewed by Rserpool protocol experts within the
WG and no controversy or difficulty was encountered with obtaining
consensus on this document.

Document Quality

There are no implementations of the MIB at this time, but a number of
researchers have implemented the protocols and reviewed the MIB
specification based on their work. 
MIB Directorate review was performed by Bert Wijnen. 

Personnel

Lyndon Ong, co-chair of the Rserpool WG, is shepherd for this document.

Magnus Westerlund provided review as the responsible Area Director.

---

From: "David B Harrington" <[email-masked]>
Date: Mon, 16 Feb 2009 13:38:39 -0500

Hi,

why experimental track? The abstract didn't mention why, so I thought
I would look in the document to see why it was experimental track.
(Boy! you'd think after this long as a MIB Doctor, I would know better
than to let my curiosity drive me to open any of these documents ;-)

There is no discussion in the document of why this is an experimental
track MIB module, and what that means to implementers and deployers. I
would think this should be documented in an Opartional Consideration
section, or something siliar, ir not the abstract and Introduction.

will this MIB module be assigned an OID in the experimental subtree?
That is known to cause problmes if it is moved from the expermiental
track later. Is this really necessary?

I think the authors should consider RFC 4181 "Guidelines for Authors
and Reviewers of MIB Documents" and apply it to this document. Some
aspects of the document does seem to apply RFC4181 guidelines, while
other aspects do not.

In the terminology section, it states that The terms "MIB module" and
"information module" are used interchangeably in this memo. I think
this could be confusing to people who have read RFC3444.

The introductory text does not seem to follow the guidelines of
RFC4181. It has only a one-sentence introduction. There is no
discussion about the relationship to other MIB modules, including
those that it imports from.

The points where the RFC Editor needs to make modifications are not
marked with comments.

There are quite a few TCs. Are these all really necessary?

The table and entry descriptions are rather sparse. 

The indexing seems odd. The MIB defines an rserpoolENRPIndex ""An
integer to uniquely identify an ENRP server." and a
rserpoolENRPIdentifier column in the row "The ENRP server identifier
of this ENRP server." Is there a one-to-one correspondence? or can
there be multiple rows with the same 
rserpoolENRPIdentifier? 

It seems this is disucssed in section 4, but it is not very clear just
looking at the MIB definition. Since the MIB definition is likely to
be distributed without the surrounding text, this will not be clear to
a user.

There is no discussion of the fate-sharing between tables.

There is no discussion about persistence of information across
reboots.

The use of addresses seems inconsistent in its ordering:
PASA address is (port, addr, type)
PENR address is (type, port, addr)
PEUserAddr seems to be (type, addr, opaqueaddr)
I am not quite sure how addresses are specified in the xxxTransportxxx
columns of the PE table.

rserpoolPEUserL3Type OBJECT-TYPE
   SYNTAX     InetAddressType { ipv4(1), ipv6(2) }
   MAX-ACCESS read-only
   STATUS     current
   DESCRIPTION
      "The network-layer protocol of an IP address of
      an user transport endpoint. Set to unknown for opaque address."
   ::= { rserpoolPEUserAddrTableEntry 2 }
extends the InetAddressType TC using the description clause.

The descriptions are very light, and the datatypes of the columns seem
rather opaque. For example:
RSerPoolOperationScopeTC ::= TEXTUAL-CONVENTION
   DISPLAY-HINT "1024t"
   STATUS       current
   DESCRIPTION  "The ID of an operation scope"
   SYNTAX       OCTET STRING (SIZE (0..65535))
I have no idea of the format this should take, and there is no
REFERENCE to where this is defined.

RSerPoolPoolHandleTC ::= TEXTUAL-CONVENTION
   DISPLAY-HINT "1024t"
   STATUS       current
   DESCRIPTION  "The pool handle"
   SYNTAX       OCTET STRING (SIZE (0..65535))
I have no idea of the format this should take, and there is no
REFERENCE to where this is defined.

RSerPoolPolicyLoadTC ::= TEXTUAL-CONVENTION
   DISPLAY-HINT "d"
   STATUS       current
   DESCRIPTION  "The load status of a pool element"
   SYNTAX       Unsigned32 (0..4294967295)
I have no idea of the format this should take, and there is no
REFERENCE to where this is defined. It also has no UNITS clause, so I
have no idea what this value represents - should I assume this is the
percentage of the device's capabilities, and when I say 4294967295,
this means we are using 4294967295 % of the capabilites - (wow)? 

The Opaque type has been obsoleted (decremented) in SMIv2. The
RSerPoolOpaqueAddressTC ::= TEXTUAL-CONVENTION
   DISPLAY-HINT "1024t"
   STATUS       current
   DESCRIPTION  "Opaque address"
   SYNTAX       OCTET STRING  (SIZE (0..65535))
looks like a workaround to put it back in.

The security considerations does not follow MIB security boilerplate,
and does not discuss sensitivities of the objects.

The IANA considerations should specify which subtree (experimental).

dbh 

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Romascanu, 
> Dan (Dan)
> Sent: Monday, February 16, 2009 10:17 AM
> To: MIB Doctors (E-mail); [email-masked]; [email-masked]
> Subject: [MIB-DOCTORS] FW: Evaluation: 
> draft-ietf-rserpool-mib-11.txt toExperimental RFC
> 
>  
> Technical Summary:
> 
> _______________________________________________
> MIB-DOCTORS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mib-doctors
>

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Tue, 17 Feb 2009 11:23:47 +0100

> From: David B Harrington [mailto:[email-masked]] 
> Sent: Monday, February 16, 2009 8:39 PM
> To: Romascanu, Dan (Dan); 'MIB Doctors (E-mail)'; 
> [email-masked]; [email-masked]
> Subject: RE: [MIB-DOCTORS] FW: Evaluation: 
> why experimental track? The abstract didn't mention why, so I 
> thought I would look in the document to see why it was 
> experimental track.
> (Boy! you'd think after this long as a MIB Doctor, I would 
> know better than to let my curiosity drive me to open any of 
> these documents ;-)
> 
> There is no discussion in the document of why this is an 
> experimental track MIB module, and what that means to 
> implementers and deployers. I would think this should be 
> documented in an Opartional Consideration section, or 
> something siliar, ir not the abstract and Introduction.
> 
> That is known to cause problmes if it is moved from the 
> expermiental track later. Is this really necessary?
> 

Yes, this is what this document requires. All rserpool protocol
documents are Experimental. Do you believe that in such case it makes
sense to define the MIB as anything but Experimental? 

Dan

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Tue, 17 Feb 2009 11:29:26 +0100

> know better than to let my curiosity drive me to open any of 

Please continue to do this! You and other MIB Doctors. Please!

It would be good if other MIB Doctors would do the same from time to
time, even if they did not take full responsibility on being THE MIB
doctor for one document or the other. MIB documents are still being
released in the IETF (and by other SDOs and vendors!) and there is
nobody but us to keep a minimal level of consistency and accuracy on
what is being implemented and deployed. 

Dan