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

From: Magnus Westerlund <[email-masked]>
Date: Tue, 20 Jan 2009 11:54:17 +0100

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: [email-masked]
----------------------------------------------------------------------
_______________________________________________
rserpool mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/rserpool

---

From: Thomas Dreibholz <[email-masked]>
Date: Thu, 22 Jan 2009 15:02:44 +0100

---

From: Magnus Westerlund <[email-masked]>
Date: Fri, 23 Jan 2009 16:06:20 +0100

Fixes looks good. I have requested IETF last call on this document and
also a MIB review.

Cheers

Magnus

Thomas Dreibholz skrev:
> * PGP Signed by an unknown key
> 
> On Dienstag 20 Januar 2009, Magnus Westerlund wrote:
> 
> Dear Magnus,
> 
> the RSERPOOL MIB I-D has been updated now. See my comments inline.
> 
> 
> This was a problem of the automatical export to the text table. Seems that 
> snmptranslate handles these value as signed: 2^32-1 -> -1. The table is fixed 
> now.
> 
> 
>> 2. Section 5:
> Fixed.
> Fixed.
> Fixed.
> The lengths of pool handle, opaque address and operation scope is not limited 
> by the RSerPool RFCs (the limit is only given by the ASAP/ENRP maximum 
> message sizes). Therefore, these fields should not be limited in the MIB, 
> too.
> 
> The description fields have been updated to 4096 now. This seems to be 
> sufficiently large for usuful descriptions using 4-octet characters.
> 
> 
> poolUserTable entries are only provided by PUs. That is, if SNMP is used to 
> query a host running one or more PU instances, this table will contain its 
> fields. A poolUserTable is not filled by a system hosting an ENRP server 
> only. All ENRP server related content is in the enrpServerTable branch.
> 
> Example:
> A host runs ENRP-1, PE-2, PE-500 as well as PU-99 and PU-5. Then, the MIB 
> table for this host will contain:
> enrpServerTable:
>    ENRP-1
>       enrpServerPoolTable:
>          Pool "xy":
>             PE-2
>             PE-500
> poolElementTable:
>    PE-2
>    PE-500
> poolUserTable:
>    PU-99
>    PU-5
> 
> If a host only runs an ENRP server, it will only contain the ENRP server entry 
> in its enrpServerTable. poolElementTable and poolUserTable will be empty.
> 
> 
> I have added a sentence to the I-D making this clearer.
> 
> 
> See above. The contents of the poolUserTable are provided by the PU itself.
> 
> 
>> 8. Section 9.1:
>>
> Fixed.
> Best regards

-- 

Magnus Westerlund