Subject: Re: [Enum] Why not re-use interim procedures for infrastructure ENUM?

From: "Stastny Richard" <[email-masked]>
Date: Mon, 6 Feb 2006 15:45:57 +0100

Richard Shockey wrote:
 
>However the "issue" as you call it Richard IMHO would not lie with the
>IAB. You should re read the charter of the IAB.

>It would lie with the IESG upon creation of the appropriate RFC that
>designated an Infrastructure apex. If the RFC is approved there is
>little or nothing the IAB can do to impede its deployment.

So to get this going, we first need a RFC 3761bis defining the apex
If the IESG approves, IAB will start negotiating with RIPE and ITU

Translated to practical issues this means:
1. we have to move forward with our draft to get a workable solution for the next 1 or 2 years (option2)
2. we also have to start the procedure by creating draft-enum-rfc3761bis.

Since 2 cannot be finished before May 2006, the question is, should be bother ITU-T already
now or wait for January 2007?

regards
Richard

________________________________

Von: Richard Shockey [mailto:[email-masked]]
Gesendet: Mo 06.02.2006 14:57
An: Stastny Richard
Cc: Rosbotham, Paul; [email-masked]
Betreff: Re: [Enum] Why not re-use interim procedures for infrastructure ENUM?

Stastny Richard wrote:
> Pail wrote:
>
>> I like your way forward.  I continue to have severe reservations of the Plan B approach,
ie i.c.c.e164.arpa, leaving things to >national matters.
>
> It is always national matters

Exactly

>
> We should not always blame ITU-T. First the issue hads to be sorted out with the IAB,
then with RIPE and only if this is done we should bother ITU. I should
be done until mid of
April, but I have slight doubts ;-)

Richard is again right ..we should not blame the ITU-T for being what
they are. In fact they seem to be running aspects their operation better
than the IETF.

The simple fact is the procedures we have in place right now are working
remarkably well. Far beyond the expectations of those of us that wrote
the rules in the first place.

However the "issue" as you call it Richard IMHO would not lie with the
IAB. You should re read the charter of the IAB.

It would lie with the IESG upon creation of the appropriate RFC that
designated an Infrastructure apex. If the RFC is approved there is
little or nothing the IAB can do to impede its deployment.

Certainly there would have to be renegotiations of various agreements
but the working model is in place and could be reasonably modified.

So long as the fundamental principal of respect for the national
sovereign rights of Nation States to regulate the use of their portions
of the E.164 plan is maintained and preserved I do not see a lot of
problems at the ITU, only be the usual problems of gratuitous bashing of
United States policy over control of the root.

>
>
>
> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]On Behalf Of
> Stastny Richard
> Sent: Saturday, February 04, 2006 12:09 AM
> To: Lind, Steven D, ALABS; Bernie Hoeneisen; [email-masked]
> Subject: Re: [Enum] Why not re-use interim procedures for infrastructure
> ENUM?
>
>
> Bernie, Steven,
>
> In principle Bernie is correct, but only in principle, because also Steven
> has a point in stating that this is an oversimplification. and it
> would IMHO unwise politically not to involve the ITU at all.
>
> The currently envisaged way forward is
>
> - discuss the proposal at the IETF meeting in Dallas
> The IETF (and the IAB) should come to a conclusion
> before RIPE and especially the ITU is involved.
> (note: if this is agreed, a simple addition of one or two lines
> to RFC3761 is sufficient)
>
> - the next ITU SG2 meeting takes place first half of May 2005
> so enough time to prepare a D contribution to explain
> the issue. (requires IAB and RIPE to principally agree)
>
> - if ITU SG2 accepts that the interim procedures are
> also sufficient for valid requests of member states, it
> may instruct the ITU TSB by stating this in the meeting
> report to approve also requests to RIPE for infrastructure
> ENUM delegations in the same way as it is done now for
> User ENUM requests. This would be the optimum
>
> - if ITU SG2 is not stating this in the meeting report
> (this could be for various reasons, eg no decision is
> made, the interim procedures need change, etc.)
> the next ITU SG2 meeting is in January 2006, (because
> of the ITU Plenipot Meeting in Fall in Turkey)
>
> - in this case we could still proceed with option 2.
>
> best regards
> Richard Stastny
>
>
> This e-mail has been scanned for viruses by the Cable & Wireless e-mail security system - powered by MessageLabs. For more information on a proactive managed e-mail security service,  visit http://www.cw.com/uk/emailprotection/
>
> The information contained in this e-mail is confidential and may also be subject to legal privilege. It is intended only for the recipient(s) named above. If you are not named above as a recipient, you must not read, copy, disclose, forward or otherwise use the information contained in this email. If you have received this e-mail in error, please notify the sender (whose contact details are above) immediately by reply e-mail and delete the message and any attachments without retaining any copies.
>
> _______________________________________________
> enum mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/enum
>
>
> _______________________________________________
> enum mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/enum
>

--

Richard Shockey, Director - Member of Technical Staff
NeuStar Inc.
46000 Center Oak Plaza  -   Sterling, VA  20166
sip:rshockey(at)iptel.org   sip:57141(at)fwd.pulver.com
ENUM +87810-13313-31331
PSTN Office +1 571.434.5651 PSTN Mobile +1 703.593.2683
Fax: +1 815.333.1237
<mailto:richard(at)shockey.us> or
<mailto:richard.shockey(at)neustar.biz>
<http://www.neustar.biz> ; <http://www.enum.org>
<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<

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

---

From: Richard Shockey <[email-masked]>
Date: Mon, 06 Feb 2006 10:19:53 -0500

> If the IESG approves, IAB will start negotiating with RIPE and ITU

This is only a personal opinion but I do not believe you need to wait 
for 3761bis this could be defined in a separate document once there is 
agreement on the requirements.

As is usual IETF procedure ..requirements _first_ ..then the solution.

--

---

From: Jim Reid <[email-masked]>
Date: Mon, 6 Feb 2006 15:32:44 +0000

On Feb 6, 2006, at 14:45, Stastny Richard wrote:

> 1. we have to move forward with our draft to get a workable  
> solution for the next 1 or 2 years (option2)

There doesn't seem any point approaching ITU-T until this WG has  
something for them to consider. OTOH, it wouldn't hurt to give SG2 a  
heads-up that this group is working on Infrastructure/Carrier ENUM.

---

From: Richard Shockey <[email-masked]>
Date: Mon, 06 Feb 2006 10:44:41 -0500

Jim Reid wrote:
> something for them to consider.

Correct.

  OTOH, it wouldn't hurt to give SG2 a
> heads-up that this group is working on Infrastructure/Carrier ENUM.

Nope  ...no formal IETF liaison is necessary. The extensive readership 
of this list in Geneva circles is sufficient :-)

--

---

From: Richard Shockey <[email-masked]>
Date: Mon, 06 Feb 2006 14:09:30 -0500

lconroy wrote:
> Hi Richards, folks,
>   (i) Requirements first - that should be fun.

Lawrence ... you know the IETF drill here. We agreed some form of 
Requirements documentation was necessary. That _MUST_ come first.

  What's the schedule for
> ITU SG2
>       meetings after January 2007?
>  (ii) People keep talking about rfc3761bis, but I think we're talking about
>       different things - some folks seem to be talking about a 
> "traditional" rfc3761bis (i.e. obsoleting the current RFC 3761)

That is a item on our charter if you recall.

; others seem more interested in an RFC3761-doppelganger (i.e. in 
parallel with RFC
> 3761).
> 
> So... are we to work on a replacement doc or one to run in parallel?

It is the opinion of this particular co-chair that the revision of 
RFC3761bis to go to Draft Standard and a document outlining a protocol 
solution to the Requirements for Infrastructure ENUM are orthogonal issues.

They are separate documents but may be run in parallel.

--

---

From: lconroy <[email-masked]>
Date: Mon, 6 Feb 2006 18:26:15 +0000

Hi Richards, folks,
   (i) Requirements first - that should be fun. What's the schedule  
for ITU SG2
       meetings after January 2007?
  (ii) People keep talking about rfc3761bis, but I think we're  
talking about
       different things - some folks seem to be talking about a  
"traditional"
       rfc3761bis (i.e. obsoleting the current RFC 3761); others seem  
more
       interested in an RFC3761-doppelganger (i.e. in parallel with  
RFC 3761).

I'm assuming that the Pfautz/Linn draft is the one you take for  
requirements.
That would seem to tie in with the doppelganger approach, as that draft
covers requirements for Infrastructure ENUM only.

all the best,
   Lawrence

On 6 Feb 2006, at 15:19, Richard Shockey wrote:
> This is only a personal opinion but I do not believe you need to  
> wait for 3761bis this could be defined in a separate document once  
> there is agreement on the requirements.
>

---

From: Patrik Fältström <[email-masked]>
Date: Wed, 15 Feb 2006 10:04:05 +0100

On 6 feb 2006, at 19.26, lconroy wrote:

>       rfc3761bis (i.e. obsoleting the current RFC 3761); others  
> seem more

Regardless of what path this wg is suggesting, we do need a new RFC  
3761 as you (among others) have found non-clear things in RFC 3761.

And, I hereby report I am taking up the pen starting writing.

     Patrik