[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Rserpool] AD evaluation of draft-ietf-rserpool-mib-09
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.
>
>
>> 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?
>
> 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:
>> 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?
>
> Fixed.
>
>
>> 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?
>
> Fixed.
>
>
>> 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.
>
> Fixed.
>
>
>> 4. Why isn't the strings bounded in length for several of the types?
>> Are they really needing the full 65535 string length?
>
> 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.
>
>> 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.
>
> The description fields have been updated to 4096 now. This seems to be
> sufficiently large for usuful descriptions using 4-octet characters.
>
>
>> 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.
>
> 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.
>
>
>> 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 }
>
> See above. The contents of the poolUserTable are provided by the PU itself.
>
>
>> 8. Section 9.1:
>>
>> To me it doesn't appear that the following references actually are
>> normative:
>> RFC 3237, rfc5351, rfc5355, rfc3410
>
> Fixed.
>
>
> Best regards
--
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