Re: AD evaluation of draft-ietf-rserpool-mib-09

Hi,

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 tha=
t =

> snmptranslate handles these value as signed: 2^32-1 -> -1. The table is f=
ixed =

> now.
> =

> =

>> 2. Section 5:
>>    PolicyIDType ::=3D 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 ::=3D 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 ::=3D 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 lim=
ited =

> 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."
>>
>>    ::=3D { 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 it=
s =

> 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."
>>
>>    ::=3D { poolUserEntry 4 }
> =

> See above. The contents of the poolUserTable are provided by the PU itsel=
f.
> =

> =

>> 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=E4r=F6gatan 6                | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden| mailto: [email protected]
----------------------------------------------------------------------