RE: [ipcdn] Re: Signaling MIB - Draft 3 - Last Call - Country Cod e (Issue 5)

["Woundy, Richard" <[e-mail]>]

David,

This might be a good approach -- I'll let others comment on the overall
proposal.

In the updated Printer MIB
<http://www.ietf.org/internet-drafts/draft-ietf-printmib-mib-info-15.txt>,
they were also concerned about country localization. Their corresponding MIB
object is:

prtLocalizationCountry OBJECT-TYPE
    -- Note: The size is fixed, was incorrectly 0..2 in RFC 1759.
    SYNTAX     OCTET STRING (SIZE(2))
    MAX-ACCESS read-only
    STATUS     current
    DESCRIPTION
        "A two character country code from ISO 3166, a blank string
        (two space characters) shall indicate that the country is not
        defined.  Examples: US, GB, FR, DE, ..."
    ::= { prtLocalizationEntry 3 }

(Note that this MIB has already passed MIB doctor and IESG review; it is on
the RFC editor queue.)

The lesson is that we ought to define a fixed two octet syntax in the
proposed object, and we need to define a "default value", e.g. two space
characters.

We also need to define what happens if the MIB object is set to a country
code value that the MTA does not understand (i.e. because the MTA does not
support the parameters for that country, because the country does not have a
defined set of parameters, or because the "country" does not exist).

-- Rich

-----Original Message-----
From: [e-mail] [mailto:[e-mail]]On Behalf Of
David De Reu
Sent: Monday, January 19, 2004 11:39 AM
To: IPCDN Mailing List
Subject: [ipcdn] Re: Signaling MIB - Draft 3 - Last Call - Country Code
(Issue 5)


Dear all,

There are a lot of country-dependent MIB objects in the current signaling
MIB definitions, e.g. the pktcSigDevToneTable. When an operator wants to
define the standard tones for his country, he has to add *a lot* of objects
to the config file. This is necessary, because there is no default value for
all these tones. And such a default value can not easily be defined, because
most values are actually country-dependent. Therefore, it would be useful to
have one single MIB object to tell the MTA to use a given set of default
values: the pktcCountryCode object.

The semantics of this object could be that an MTA "has to implement the
country-specific values" for the different tables and objects that are
country-dependent (which ones exactly can be designated later on). The MTA
would implement a default country code and, optionally, extra country codes.
The MIB definition would not impose any country codes that the MTA MUST
implement. However, for the purpose of certification testing, the exact
country codes and the exact definition of the values associated with these
codes, would be communicated to the MTA vendors participating in the
certification program.

For example, an MTA could implement the US country code as a default (with
US dial tone etc). A European operator wanting to deploy this MTA e.g. in
Belgium, would require the MTA to support the BE country code (thus using
the Belgian dial tone for example), which would probably be tested during
certification.

A proposed country code MIB object definition has been the following:

pktcCountryCode OBJECT-TYPE
     SYNTAX     OCTET STRING (SIZE (1..2))
     MAX-ACCESS read-write
     STATUS     current
     DESCRIPTION
         "This object identifies the telephony configuration
          parameters specific to a particular country used to set
          default values for the following tables: TBD."
        ::= { pktc xxx }

The MAX-ACCESS can of course be changed so that the object can only be set
in the config file, and is read-only from then on - I see no problem with
that.

For the country *codes* themselves, the ISO 3166-1 list of country codes
(see
http://www.iso.org/iso/en/prods-services/iso3166ma/index.html) seems a
useful source. This list defines an internationally agreed upon and widely
used two-letter abbreviation for each country. I believe this provides the
exact granularity needed in the context of this object.


Thanks,

Kind regards,

David

_____________________________________________________
David De Reu
tComLabs
Stapelplein 70/004 - 9000 Ghent - Belgium
Tel: [phone] - Fax: [phone]
www.tComLabs.com
_____________________________________________________



_______________________________________________
IPCDN mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/ipcdn

_______________________________________________
IPCDN mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/ipcdn