[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: UTF8String TC in draft-ietf-snmpconf-pm-13.txt (fwd)

Snmpconf folks --

Here is some discussion about the UTF8String TC that Bert asked me
to forward.  The "meat" of the discussion is a suggestion to change
the wording on requiring a SIZE constraint when a UTF8String index
object might cause overflow.  A SIZE constraint does not always
solve the problem, especially when other variable-length index
objects are present, and in some cases it may be preferable to
describe the constraint in a DESCRIPTION clause (or elsewhere).  
I've suggested some rewording along those lines for your
consideration.  It's adapted from the text for InetAddress that was
proposed in a recent discussion of 3291bis on the mibs@ops.ietf.org


---------- Forwarded message ----------
Date: Wed, 28 May 2003 14:11:44 +0200
From: "Wijnen, Bert (Bert)" <bwijnen@lucent.com>
To: C. M. Heard <heard@pobox.com>, "Wijnen, Bert (Bert)" <bwijnen@lucent.com>
Subject: RE: UTF8String TC in draft-ietf-snmpconf-pm-13.txt

Thanks again for your continued review and checking.

W.r.t. the UTF8String TC.
- My latest posting (last Monday) to the WG list was:
  - I am still bothered by your UTF8String. You had explained why you 
    had done it and want to keep it. So I will accept that the WG agrees
    with that. But the UTF8String is only different in case from Utf8String
    as in RFC2287. I do not think that this is wise. So if you do want to
    keep it, I'd like to see the name changed. Is it only meant for the
    Policy MIB and or related MIBs? Then maybe PmUTF8String makes more sense

And this is earlier (back in Feb) Discussion I had with authors:
> > > - Why is there a UTF8String TC ??
> > >   How does it differ (why must it differ) from SnmpAdminString?
> > >   Same question for Utf8String from RFC2287 ??
> > >   I would like to avoid a proliferation of various UTF*String TCs
> >
> > SnmpAdminString
> >    They're not admin strings
> >    They're often too long for AdminString's 255 octet limit
> > rfc2287
> >    Odd place to look (only a minor objection)
> >    The definition of SnmpAdminString is *much* better than the
> >    circa-1998 def'n of LongUtf8String in rfc2287.
> >
> > What we have is a copy of SnmpAdminString without the length
> > restriction.
> >
> > I'm definitely with you on the issue of proliferation of
> > locally-defined versions of what-should-be-global types. We just have
> > two problems and both stem from not having a central repository:
> >    1. When I write a type for a central repository I take care not to
> >       embed stuff in it that makes it non-reusable (like length
> >       restrictions). If I write a type for my own use, I'm under no
> >       such restriction and as we see many otherwise-reusable types are
> >       fettered with bad stuff.
> >    2. It seems wrong for documents to borrow stuff from unrelated
> >       non-framework documents.
> >
> > Issue #1 is the operative one. #2 is a style issue and maybe would be
> > trumped by the benefit of reusability.
> >
> > Wouldn't it be great if we just did it right and created the central
> > repository?
> >

We can keep pushing back only so much I guess.
But If you have new arguments to bring to the table, that would be great.

I keep thinking that maybe I (we) should start a IANA-GENERIC-TC-MIB
module in which we bring together all common/generic TCs and which then
also gets us out of the "need to advance TC docs along the stds track"
issue. My idea would be to then move all current common TCs into that
IANA MIB, and to tell people to import from there when they revise
docs (or write new docs) and to start depracting the original TCs
when such docs that contain origin al TCs get revised. Oh well...
Seperate topic I gues.

Your proposed text for the SIZE restrcition below is also a good 
suggestion. Will you post it or would you rather see me do it?


> -----Original Message-----
> From: C. M. Heard [mailto:heard@pobox.com]
> Sent: woensdag 28 mei 2003 2:21
> To: Wijnen, Bert (Bert)
> Subject: UTF8String TC in draft-ietf-snmpconf-pm-13.txt
> Bert,
> There is one more issue with draft-ietf-snmpconf-pm-13.txt that I
> should mention:  it defines the UTF8String TC, whose base type is
> OCTET STRING (SIZE (0..65535)) but which is otherwise similar to the
> following TCs are defined in SYSAPPL-MIB [RFC2287]:
>    Utf8String                  OCTET STRING (SIZE (0..255))
>    LongUtf8String              OCTET STRING (SIZE (0..1024))
> Perhaps there is a real need for something longer than 1024 octets
> (there are three object definitions where no constraint is used, all
> the rest are 1024 or less), but I am a little concerned about the
> proliferation of very similar TCs.  I also notice the following in
> the DESCRIPTION clause:
>         Note that when this TC is used for an object that
>         is used or envisioned to be used as an index, then
>         a SIZE restriction MUST be specified so that the
>         number of sub-identifiers for any object instance
>         does not exceed the limit of 128, as defined by
>         RFC3416 [10].
> They instead be using language similar to what we agreed
> on the the InetAddress TC (which avoids the citation too):
>         Note that when this TC is used for an object that
>         is used or envisioned to be used as an index, then
>         there may be issues with the limit of 128 sub-identifiers
>         specified in SMIv2, RFC 2578, STD 58, and in SNMPv3
>         protocol operations, RFC 3416, STD 62.  In this case,
>         the object definition MUST include a 'SIZE' clause to
>         limit the number of potential instance sub-identifiers
>         or else the applicable constraints MUST be stated in the
>         appropriate conceptual row DESCRIPTION clauses or in the
>         surrounding documentation if there is no single DESCRIPTION
>         clause that is appropriate.
> Mike