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
- [ENUM] Comments to <draft-ietf-enum-e164-gstn-np-… M.Muench
- RE: [ENUM] Comments to <draft-ietf-enum-e164-gstn… Stastny, Richard
- RE: [ENUM] Comments to <draft-ietf-enum-e164-gstn… Yu, James
- RE: [ENUM] Comments to <draft-ietf-enum-e164-gstn… M.Muench
- RE: [ENUM] Comments to <draft-ietf-enum-e164-gstn… Yu, James
- RE: [ENUM] Comments to <draft-ietf-enum-e164-gstn… Stastny, Richard