[Rserpool] AD evaluation of draft-ietf-rserpool-mib-09

[Magnus Westerlund <magnus.westerlund at ericsson.com>]

Hi,

I have reviewed the RSERPOOL MIB and have the below comments and
question. It appears a new draft will be needed after we have sorted out
the questions. The plan after having resolved this is to go to IETF last
call and have the MIB reviewers take a look at it. When that review is
in we can progress to the next step.

1.  Section 4: Why is range for an unsigned 1..-1?

2. Section 5:
   PolicyIDType ::= TEXTUAL-CONVENTION
   DISPLAY-HINT "x"
   STATUS       current
   DESCRIPTION  "The ID of the pool policy"
   SYNTAX       Unsigned32 (0..255)


I don't understand why the syntax restricts to the first 256 values when
the RSERPOOL policy space is the full 32-bit unsigned space?


PolicyLoadType ::= TEXTUAL-CONVENTION
   DISPLAY-HINT "d"
   STATUS       current
   DESCRIPTION  "The load status of a pool element"
   SYNTAX       Unsigned32 (0..16777215)

Section 3.1 of RFC 5356 defines load as an unsigned 32 using the full
space. So why is the load restricted to the range 0 to 16777215, when
full load is 0xffffffff?

3.

   TransportUseType ::= TEXTUAL-CONVENTION
   STATUS       current
   DESCRIPTION "The load status of a pool element"
   SYNTAX       INTEGER {
   dataOnly(0),
   dataPlusControl(1)

The description seems to be wrong.

4. Why isn't the strings bounded in length for several of the types?
Are they really needing the full 65535 string length?

5. Why is this element limited to 255 octets?

   enrpServerDescription OBJECT-TYPE
   SYNTAX     OCTET STRING (SIZE (0..255))
   MAX-ACCESS read-write
   STATUS     current
   DESCRIPTION
   "A textual description of this ENRP server, e.g. its location
   and a contact address of its administrator."
   ::= { enrpServerEntry 4 }

It seems that the purpose would require far more space. Location and
contact addresses can clearly be longer than 255 octets. Please remember
that the text may be UTF-8 and each character up to 4 octets long.

6. poolUserTable: It isn't clear if the table will contain only active
users or also past users for some duration. Can you please clarify the
status.

7. How is it expected that this information can be filled in by an ASAP
server?

   poolUserDescription OBJECT-TYPE
   SYNTAX     OCTET STRING (SIZE (0..255))
   MAX-ACCESS read-write
   STATUS     current
   DESCRIPTION
   "A textual description of this pool user, e.g. its location
   and a contact address of its administrator."
   ::= { poolUserEntry 4 }


8. Section 9.1:

To me it doesn't appear that the following references actually are
normative:
RFC 3237, rfc5351, rfc5355, rfc3410

Cheers

Magnus Westerlund

IETF Transport Area Director & TSVWG Chair
----------------------------------------------------------------------
Multimedia Technologies, Ericsson Research EAB/TVM
----------------------------------------------------------------------
Ericsson AB                | Phone  +46 10 7148287
Färögatan 6                | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund at ericsson.com
----------------------------------------------------------------------
_______________________________________________
rserpool mailing list
rserpool at ietf.org
https://www.ietf.org/mailman/listinfo/rserpool