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

Re: [Enum] voipeer agenda/charter uploaded


It would be natural to break down the strategic goals of ENUM (rechartered) for the Carrier ENUM question, in terms of the following categories::

(If I start using ISO terms and modelling conventions for all this, becuase its all been done before, slap me and remind me we are doing _IETF-styled_ reinvention of carrier-based telephony)

There will be multiple Carrier ENUM trees, one of which is public and ultimately, ICANN (i.e. US govt.) controlled.

Within an Carrier ENUM tree,

- voice providers will practice uniform and consistent peering

- voice providers will provision name server entries and their contents

- the structure of the tree will reflect the administrative rights of the provider under NRA licensing

- the structure of validation entity and security domains is orthogonoal to the structure of the tree reflecting the adminsitrative rights of providers to create and modify entries in the ENUM name servers serving the tree

- ENUM name servers will reflect number registration, and number porting, but will not directly perform registration or NP duties

- An ENUM name server is not intended to be an identity service for Carriers of Record, for current entries

- A carrier's obligation to wiretap a subsriber line shall not impact or influence the adminsitration of or content of, an entry in an ENUM name server.

- The adminsitration of entries, and the schema of services declared within an entry, shall be administered by the COR for the E.164 number identifying the entry

- Any E.164 number issued pusuant to national regulatory authority license may logically identify an entry.

-Entries that declare CORs, NRAs, schema definitions, provider service access points and other administrative meta-data are not within the scope of Carrier ENUM dliverables, though may be addessed in related ENUM series documents.

-------------

The ENUM charter SHOULD NOT focus its text on the above! Rather, it needs to characterise Carrier ENUM scheme, to be designed in the next round of WG activity. The deliverables that embody the above need to be identified, timetabled, and characterized, however, using the architectural principles listed above.


If the formulation of the charter is not occuring with the direct involvement of the folks who have already written Carrier ENUM drafts, and can improve upon the above considerably, there is SOMETHING VERY WRONG WITH THE TRANSPARENCY.

Improve the process, co-chairs, and make it transparent and available to mailing list participants, per our community norms.

Peter.


From: Christian de Larrinaga <cdel at firsthand.net>
To: David Meyer <dmm at 1-4-5.net>
CC: Peter Williams <home_pw at msn.com>, enum at ietf.org, Richard.Stastny at oefeg.at
Subject: Re: [Enum] voipeer agenda/charter uploaded
Date: Wed, 12 Oct 2005 11:21:43 +0100

Carrier ENUM is not mentioned here which is good I think.
But it is implied.
I would support a definition of Carrier ENUM as supporting peering/ transit and routing relationships but not for provisioning user services.
The VoiPeer charter seems to agree with this view?

If so then it should be taken on board by those working on a carrier ENUM plan?

Christian de Larrinaga
cdel at firsthand.net
Voex Inc.


On 11 Oct 2005, at 21:52, David Meyer wrote:


    Peter,

On Tue, Oct 11, 2005 at 12:23:14PM -0700, Peter Williams wrote:


IAB required, in a carefully worded policy communciated through a co-chair
that its acceptance of Carrier ENUM work itmes is contingent on aligning
voipeer.future and enum.future re-chartering. What this WG and its members
wants is irrelevant, per the last WG meeting and IAB considerations: all
that matters is satisfying IAB's mandate, which we must assume to be in our
interests.



    Can you describe how you feel the IAB "required" this?
    I'm a little confused as

    (i).    I'm not sure how that IAB can "require"
        anything; perhaps you mean s/IAB/IESG/
        (that would make more sense), and

    (ii).    I'm not sure what you think was "required" WRT
            Carrier ENUM alignment; there have been a lot of
        discussions around this, and it would be good to
        get everyone's assumptions on the table, and to
        make sure we're all using the same set.

    Can you (or anyone else) clarify these for us?



We have a good strawman from viopeer; its highly SIP specific, particularly
in some ENUM-related areas.



    SIP is the Internet-standard signalling protocol, after
    all. And we are talking about the Internet here (IETF and
    all).

    Thanks,

    Dave




We comment on their charter, BECAUSE we are REQUIRED to align with their
goals, objectives, methods, timelines, etc - for good and obivous reasons
- if we want Carrier ENUM to be adopted into the standards track.

Remember Carrier ENUM is not formally an IETF standards track  activity
today, and the rules on becoming so have been stated (and  restated, word
for word, indicating its a very sensitive topic).





From: "Stastny Richard" <Richard.Stastny at oefeg.at>
To: "Peter Williams" <home_pw at msn.com>,<enum at ietf.org>
Subject: Re: [Enum] voipeer agenda/charter uploaded
Date: Tue, 11 Oct 2005 21:13:38 +0200

I do not understand what you want to say?

This is the voipeer charter discussion and not
the enum charter discussion

BTW, estee,ed enum chairs, is there a enum charter proposal to expect soon.

With soon I mean before Vancouver

Richard


________________________________

Von: enum-bounces at ietf.org im Auftrag von Peter Williams
Gesendet: Di 11.10.2005 21:03
An: enum at ietf.org
Betreff: RE: [Enum] voipeer agenda/charter uploaded




FROM Proposed VIOPEER Charter:

"Routing fo sessions which are not signaled using SIP. In
   particular, voipeer is constrained to consider only those
   scenarios in which call routing is signaled using the
   SIP protocol and addressed by SIP or SIPS URIs or E.164
   (public telephone number) addresses. By extension, national
   and private formats numbering formats are out of scope for
   voipeer"

ENUM has broader scope, including H.323 URLs.

ENUM Charter needs to be session protocol agnostic, in essence. So its the
architectural support for multiple session/setup protocols thats required,
not any particular love of H.323.

Interaction between ENUM and VIOP peering must be only in the  generic
areas,
not SIP-specific areas.

I see no reason why ENUM should not be optionally "tuned" for today's SIP,
but not "architected" for SIP. There is little doubt that E.164 and ENUM
will, given their role, be around far longer than SIP will be.

All private and national number formats (that are conforming to E. 164 ) are
within the scope of ENUM.

In essence, ENUM is not just a name server for today's SIP proxies. It has
a
bigger role to play in the Internet. At the same time, it should play in
today's adoption space!



From: David Meyer <dmm at 1-4-5.net>
To: voipeer at lists.uoregon.edu
CC: enum at ietf.org, sipping at ietf.org, jon.peterson at neustar.biz,
mankin at psg.com
Subject: [Enum] voipeer agenda/charter uploaded
Date: Tue, 11 Oct 2005 11:06:44 -0700


      Please see

      http://www3.ietf.org/proceedings/05nov/agenda/voipeer.txt

      Note that the bulk of our session will be devoted to
      hammering out our charter (charter bashing).

      Thanks,

      Dave






<< attach4 >>








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





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







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


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







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