Subject: Re: [Enum] voipeer agenda/charter uploaded

From: "Stastny Richard" <[email-masked]>
Date: Wed, 12 Oct 2005 18:17:06 +0200

Thanks,
 
>(ii).   Regarding RFC 3263, several folks asked for a
>                document that outlines the *deployment issues*
>                (and perhaps BCPs) with 3263.
>
>        Does (ii). clarify the situation?

Yes and no. I personally considered 3263 sufficent, but on the other
hand, if I consider the discussions going on since one year within GSMA
to leave out the NAPTR and SRV records (the so-called 4-step approach)
because they fear that two additional DNS queries may prolong their mobile
call setup time of 15 seconds by 100 milliseconds ...

... a BCP may be helpful clarifying the issue ;-)
 
Richard

________________________________

Von: David Meyer [mailto:[email-masked]]
Gesendet: Mi 12.10.2005 17:50
An: Stastny Richard
Cc: [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]
Betreff: Re: [Enum] voipeer agenda/charter uploaded

On Wed, Oct 12, 2005 at 01:23:40AM +0200, Stastny Richard wrote:
> Congatulations, the charter seems quite well done on first reading

        Hey, thanks!

> first questions and remarks:
> 
> 1. The goals and milestones seem to be a bit out-of-order and confusing
> 
> 2. -Jan 07          Submit I-D on the use of DNS SRV and NAPTR
>     -Jan 07          Submit document to IESG on the use of DNS SRV and NAPTR
>                  records as specified by RFC 3263 (BCP)
>
> What is the reason for this I-D and what in addition to RFC 3263
> should be stated?

        (i).    The dates are clearly botched, thanks for
                pointing that out. I'll just mention that I'm
                expecting that we'll hammer out some realistic
                dates for the work-plan I've described. I put up
                what I believe is a pretty agressive (and
                possibly unrealistic), and I'm planning for us to
                have that discussion in Vancouver.

        (ii).   Regarding RFC 3263, several folks asked for a
                document that outlines the *deployment issues*
                (and perhaps BCPs) with 3263.

        I'll fix (i). above. Does (ii). clarify the situation?

        Thanks for the comments.

        Dave

_______________________________________________
enum mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/enum

---

From: "Stastny Richard" <[email-masked]>
Date: Wed, 12 Oct 2005 18:21:33 +0200

I cannot fully follow this whole discussion, but definetely I cannot
parse this sentence:
 
>- 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

could you please explain what this means in plain English?

Richard

Von: [email-masked] im Auftrag von Peter Williams
Gesendet: Mi 12.10.2005 16:44
Cc: [email-masked]
Betreff: 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 <[email-masked]>
>To: David Meyer <[email-masked]>
>CC: Peter Williams <[email-masked]>, [email-masked],
>[email-masked]
>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
>[email-masked]
>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" <[email-masked]>
>>>>To: "Peter Williams" <[email-masked]>,<[email-masked]>
>>>>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: [email-masked] im Auftrag von Peter Williams
>>>>Gesendet: Di 11.10.2005 21:03
>>>>An: [email-masked]
>>>>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 <[email-masked]>
>>>>>To: [email-masked]
>>>>>CC: [email-masked], [email-masked], [email-masked],
>>>>>[email-masked]
>>>>>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 >>
>>>>>
>>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>