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

--===============1697662320==
Content-Type: multipart/signed;
  boundary="nextPart1525447.uc0PGono2W";
  protocol="application/pgp-signature";
  micalg=pgp-sha1
Content-Transfer-Encoding: 7bit

--nextPart1525447.uc0PGono2W
Content-Type: text/plain;
  charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

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=
=20
snmptranslate handles these value as signed: 2^32-1 -> -1. The table is fix=
ed=20
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?

=46ixed.


> 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?

=46ixed.


> 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.

=46ixed.


> 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 limit=
ed=20
by the RSerPool RFCs (the limit is only given by the ASAP/ENRP maximum=20
message sizes). Therefore, these fields should not be limited in the MIB,=20
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=20
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=
=20
query a host running one or more PU instances, this table will contain its=
=20
fields. A poolUserTable is not filled by a system hosting an ENRP server=20
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=20
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 en=
try=20
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 itself.


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

=46ixed.


Best regards
=2D-=20
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
 Dr. Thomas Dreibholz

 University of Duisburg-Essen,                   Room ES210
 Inst. for Experimental Mathematics              Ellernstra=DFe 29
 Computer Networking Technology Group            D-45326 Essen/Germany
=2D----------------------------------------------------------------------
 E-Mail:     [email protected]
 Homepage:   http://www.iem.uni-due.de/~dreibh
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

--nextPart1525447.uc0PGono2W
Content-Type: application/pgp-signature; name=signature.asc 
Content-Description: This is a digitally signed message part.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)

iD8DBQBJeHyU32BbsHYPLWURAgKyAJ9od2B/gg6R8qsSgtSAfJj9cQp+zwCfVWvY
OSuCwB42XWweGS6Rm66e5qs=
=Ch4k
-----END PGP SIGNATURE-----

--nextPart1525447.uc0PGono2W--

--===============1697662320==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
rserpool mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/rserpool

--===============1697662320==--