RE: [ENUM] Comments to <draft-ietf-enum-e164-gstn-np-03.txt>

M.Muench@alcatel.de Wed, 13 March 2002 11:02 UTC

Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA02219 for <enum-archive@odin.ietf.org>; Wed, 13 Mar 2002 06:02:55 -0500 (EST)
Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id GAA07979 for enum-archive@odin.ietf.org; Wed, 13 Mar 2002 06:02:59 -0500 (EST)
Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA07007; Wed, 13 Mar 2002 05:51:03 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA06982 for <enum@optimus.ietf.org>; Wed, 13 Mar 2002 05:51:01 -0500 (EST)
Received: from mailrelay2.alcatel.de (mailrelay2.alcatel.de [194.113.59.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA02060 for <enum@ietf.org>; Wed, 13 Mar 2002 05:50:57 -0500 (EST)
From: M.Muench@alcatel.de
Received: from slsas5.stgl.netd.alcatel.de (slsas5.stgl.netd.alcatel.de [149.204.45.57]) by mailrelay2.alcatel.de (8.9.3/8.9.3) with ESMTP id LAA17219; Wed, 13 Mar 2002 11:50:21 +0100 (MET)
Subject: RE: [ENUM] Comments to <draft-ietf-enum-e164-gstn-np-03.txt>
To: "Yu, James" <james.yu@neustar.biz>
Cc: enum@ietf.org
Date: Wed, 13 Mar 2002 11:50:19 +0100
Message-ID: <OF765AC9B4.B023FD6E-ONC1256B7A.0032494E@stgl.netd.alcatel.de>
X-MIMETrack: Serialize by Router on DEMTA001/DE/ALCATEL(Release 5.0.9 |November 16, 2001) at 03/13/2002 11:50:21 AM
MIME-Version: 1.0
Content-type: text/plain; charset="us-ascii"
X-Alcanet-MTA-scanned-and-authorized: yes
X-Alcanet-MTA-scanned-and-authorized: yes
Sender: enum-admin@ietf.org
Errors-To: enum-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Enum Discussion List <enum.ietf.org>
X-BeenThere: enum@ietf.org

Hello James,

my general concern to the draft is that many examples for the RN coding and
the transfer of RN are listed.
>From my experience of all the NP and MNP customers of Alcatel I can say
that for every customer certain solutions for NP or MNP have to be analysed
and the detailed coding of the NP/MNP related parameters has to be defined
and checked if they all fit to the existing network requirements. It is not
so easy to provide you with detailed RN codings due to the fact that there
are so many realisations which uses sometimes different RN codings
dependent of the NP scenario, like Service Provider Portability (SPP) for
Geographic Numbers, SPP for Non-Geographic Numbers, Location Portability,
etc.
Maybe certain operators can provide you with detailed information.

Nevertheless, there is an easy way out of this situation. My proposal is
that we should use in the draft the logical terms of the NP related
parameters: Directory Number (DN), and Network Routing Number (RN). They
are used in the other standards as well (e.g. ITU-T Q.769.1).
As you can see in ITU-T Q.769.1, there are 3 different signalling methods
to map these logical terms to protocol parameters. This had been necessary
because within the ITU-T members it was not possible to get an agreement to
restrict the signalling enhancements for NP or MNP to only one solution.
This gives an impression how complicate it is to find a solution which fits
for all operators in the world. Therefore how the RN and DN are signalled
in the network and between networks is dependent on the involved operators.

For an ENUM environment it is sufficient to mention RN and DN, and as an
option the network specific parameter (network option).
That should be enough.

With regard to the complete description of all NP or MNP cases in this
draft I see the problem that, as mentioned in my previous email, some
scenarios in detailed descrption are missing, like SPP for Non-Geographic
Numbers, Location Portability, different scenarios for MNP (call related
and non-call related (e.g. for SMS)), ...
A lot of work has to be spent if the draft should reflect all scenarios in
the same kind of detailed descrption.


You mentioned in you answer that NP be realised based on "...10-digit GTT".
I think this is the realisation for U.S. I would say don't limit the GTT to
a certain value, because in some networks fewer digits could be enough and
other networks could need more digits for the GTT.

You mentioned in you answer that the bearer unrelated signalling can be
realised based on "...message relaying (this latter one is similar to
onward routing)." I do not agree that this is similar to onward routing, in
my opinion it is similar to All Call Query because every SCCP message is
analysed.


Kind regards,

Monika




_______________________________________________
enum mailing list
enum@ietf.org
https://www1.ietf.org/mailman/listinfo/enum