Subject: Re: [Enum] WG: New Draft: Trunk Group Use in ENUM RESTART - Second request for guidence

From: Daryl Malas <[email-masked]>
Date: Tue, 12 May 2009 16:31:38 -0600

Richard,

Well, I guess I will throw my hat in the ring.  As an author of the proposed
draft, I think this is a valuable draft for the industry.  If I am the only
one, then I guess the draft is irrelevant.

Regards,

Daryl

On 4/28/09 7:05 PM, "Richard Shockey" <[email-masked]> wrote:

> Second call .. what is WG consensus here?
> 
> This is not a silence is consent issue. It requires a form of decision.
> 
> (Chair hat off) I've made my personal sentiments clear. We all thought this
> was a useful WG item. Some folks have come to us with a cleaner form of
> dealing with the use case that does not require a formal enumservice
> registration. It has wide applicability. Better to create a BCP or
> Informational than let multiple implementations go off in all sorts of non
> interoperable directions.
> 
> What does the WG want to do or do you want the chairs to decide? We are not
> going to have a meeting in Stockholm over this.
> 
> 
>>  -----Original Message-----
>>  From: [email-masked] [mailto:[email-masked]] On Behalf
>>  Of Richard Shockey
>>  Sent: Tuesday, April 21, 2009 2:29 PM
>>  To: 'Peter Koch'; 'IETF ENUM WG'
>>  Subject: Re: [Enum] WG: New Draft: Trunk Group Use in ENUM RESTART
>>  
>>  
>>  I'd like to take up where we left off on this subject and determine
>>  what the  WG consensus is on dealing with this issue.
>>  
>>  There is consensus that this is a item we had on the WG plate that has
>>  real applicability to applications in use and clarification on how these
>>  parameters should be represented in ENUM queries is a "good thing".
>>  
>>  The first question is then do we essentially adopt this new draft as a
>>  WG item and quickly move it forward?
>>  
>>  The second is as what Informational or BCP?
>>  
>>  
>>>  I have no expertise on the subject matter, but would like to share
>>>  some observations on process:
>>> 
>>>  On Fri, Mar 06, 2009 at 02:22:03PM +0000, Lawrence Conroy wrote:
>>> 
>>>>  beware - *who* gets to decide if a WG draft is dead?
>>> 
>>>  usually that's a WG consensus, either explicitly or by lack of
>>  motion
>>>  as to
>>>  be determined by the chairs.  In this case however, it seems that
>>  the
>>>  WG
>>>  (or those in the WG who actively follow the matter) have changed
>>  their
>>>  mind
>>>  about the direction of the draft.  Posting a new I-D was one way,
>>  but
>>>  if the
>>>  WG consensus is that the solution proposed in
>>>  "IANA Registration for an Enumservice Trunkgroup" is no longer the
>>>  right one
>>>  and instead a parameter to the SIP URI, as proposed in Trunk Group
>>  Use
>>>  in ENUM
>>>  will do better, then WG consensus could just direct the editors to
>>  re-
>>>  write
>>>  accordingly.  Now, it seems that the editors change on the fly,
>>  too,
>>>  but that's
>>>  up to the chairs (well, and any new editors) anyway.
>>> 
>>>> Also, why is putting this new stuff in the clutches of a sleeping
>>>> WG (or an inchoate one) going to make it any faster getting any
>>  BCP
>>>> through the IETF/IESG process? Does anyone remember IPTEL?
>>> 
>>>  I am a bit nervous about "fast tracking" in the last minute and the
>>>  status  of BCP.  The former seldomly works out, but the current
>>  work item
>>>  needs to get off the WG's plate anyway.  The latter doesn't seem
>>  necessary,
>>>  especially since we're about to re-classify all (or many of) those
>>>  Proposed Standards anyway.  A purely Informational document would
>>  do, and
>>  is
>>>  definitely more lightweight.  The draft would be an Informational
>>>  addendum to RFC 3764, which it needs to reference normatively.
>>> 
>>>  The draft itself, however, isn't really clear about the intended
>>>  status
>>>  "IANA Registration for an Enumservice Trunkgroup".  This document
>>  is a
>>>  normative
>>>  reference although it seems to have outlived its usefulness and
>>>  actually the
>>>  registration in there is kind of revoked.
>>>  However, the "trunk" ENUM service doesn't yet appear in
>>>  <http://www.iana.org/assignments/enum-services> if my pattern
>>  matching
>>>  skills
>>>  suffice.  So, instead of pursuing the old draft and immediately
>>>  revoking the
>>>  registration (or declaring it a no go), the new (well, "revised")
>>>  draft
>>>  should just state the new intended method of using trunk groups in
>>>  ENUM
>>>  and incorporate verbatim the relevant parts of the earlier draft
>>>  (without
>>>  suggesting there actually _is_ a valid ENUM servcie registration)
>>  in
>>>  an
>>>  appendix.
>>>  It wouldn't be the first time an IETF WG started an effort to do
>>  FOO
>>>  and the
>>>  document ends with the title "Why not to FOO".
>>> 
>>>  I'm not sure I follow the rationale in the first paragraph of
>>  section
>>>  1.2,
>>>  it feels like it's superseded by the newly born 5483 --
>>>  congratulations, by
>>>  the way.
>>> 
> 
> _______________________________________________
> enum mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/enum

-----------------
Daryl Malas
CableLabs
(o) +1 303 661 3302
(f) +1 303 661 9199
mailto:[email-masked]

---

From: "Richard Shockey" <[email-masked]>
Date: Wed, 13 May 2009 18:14:01 -0400

No ..I wouldn't say that.

This was always a very very specialized draft dealing with a very particular
type of PSTN data and its obvious the WG members are off to other things.

Of course some of us have had to deal with the Infrastructure ENUM issues
..but that is another sad story. Yes the liaison is coming.

IMHO silence on this is consent and my strong advise to you is to go ahead
and rewrite the document with all of the comments so far and submit it as a
WG document. The chairs will have to approve that we'll come back to the
list and see then if silence prevails we can kill the old draft and we'll
just see what happens then. If not then you will have my personal support to
submit it to the IESG as a individual submission.

>  From: Daryl Malas [mailto:[email-masked]]
>  Sent: Tuesday, May 12, 2009 6:32 PM
>  To: Richard Shockey; 'IETF ENUM WG'
>  Subject: Re: [Enum] WG: New Draft: Trunk Group Use in ENUM RESTART -
>  Second request for guidence
>  
>  Richard,
>

---

From: Bernie Hoeneisen <[email-masked]>
Date: Thu, 14 May 2009 09:04:05 +0200 (CEST)

Hi Rich et al.

On Wed, 13 May 2009, Richard Shockey wrote:

> IMHO silence on this is consent

I do disagree with you that silence on this is consent. On top of that 
many people have expressed their critical opinions earlier on this list.

IMHO this draft should go forward outside the ENUM WG as we are 
shutting it down.

cheers,
  Bernie

> and my strong advise to you is to go ahead

---

From: Peter Koch <[email-masked]>
Date: Thu, 14 May 2009 10:12:13 +0200

> many people have expressed their critical opinions earlier on this list.

I have to agree with Bernie here.  For a formal adoption it makes sense to have
at least some volunteers lined up to do the review, unless one is prepared to
continue with the "silence is consent" approach.

> IMHO this draft should go forward outside the ENUM WG as we are 

Yes, but: draft-ietf-enum-trunkgroup-00.txt, although expired, still is on the
WG's plate.  So, I think the right questions to ask are

1) Is anybody but the authors/editors of the respective drafts believes the WG
   should say anything in this direction (trunk groups). [But see the "price tag"
   under (4)]
2) Do you agree to abandon the approach in draft-ietf-enum-trunkgroup-00.txt?
3) Is the content of draft-malas-enum-trunk-sip-00.txt a better start instead?
4) Is anybody willing to review draft-malas-enum-trunk-sip-00.txt?

Then publish draft-malas-enum-trunk-sip-00.txt as draft-ietf-enum-trunkgroup-01.txt,
changing the intended state to Informational.

To start answering the question with the caveat already mentioned in
<http://www.ietf.org/mail-archive/web/enum/current/msg06872.html>, the
registration proposed in draft-ietf-enum-trunkgroup-00.txt doesn't really look
like an ENUM service.  From that perspective, the approach proposed in
draft-malas-enum-trunk-sip-00.txt appears more straight forward to me.
However, I think the draft needs more review and it should be clearer on its core
statement; right now it is structured so much as a counter proposal to
draft-ietf-enum-trunkgroup-00.txt, so it doesn't really stand on its own feet --
which is fine for a "-00".
In summary, I'd abstain from (1), answer yes to (2) and (3) and would do (4) as
far as my non experience with the core subject matter allows.

-Peter

---

From: Bernie Hoeneisen <[email-masked]>
Date: Thu, 14 May 2009 10:28:32 +0200 (CEST)

Some addition to my earlier post:

Recently a new WG DISPATCH has been established in the RAI area, 
exately for cases as this one. I suggest to divert this draft to DISPATCH 
and await guidance from there.

In addition we should officially discontinue the work on the old variant.

cheers,
  Bernie

On Thu, 14 May 2009, Bernie Hoeneisen wrote:

> I do disagree with you that silence on this is consent. On top of that many 
> people have expressed their critical opinions earlier on this list.
>
> IMHO this draft should go forward outside the ENUM WG as we are shutting it 
> down.
>
> cheers,
> Bernie
>

---

From: Lawrence Conroy <[email-masked]>
Date: Thu, 14 May 2009 18:02:59 +0100

Hi Richard, folks,
Maybe I wasn't clear in my March 3rd mail; IMHO, the original idea  
using a separate Enumservice is irrecoverable.
I join the crowd asking the WG chairs to declare it dead.

 From experience of Experiences in the IESG, this *new* item should be  
Informational, NOT BCP.
Customers can pull this out the final doc as a requirement regardless  
of its track.

I asked this in March, and I repeat - why isn't this a candidate for  
Individual or AD-sponsored?

all the best,
  Lawrence

On 13 May 2009, at 23:14, Richard Shockey wrote:
>> draft, I think this is a valuable draft for the industry.  If I am  
>> the
>> only

---

From: "Richard Shockey" <[email-masked]>
Date: Thu, 14 May 2009 17:42:27 -0400

>  I join the crowd asking the WG chairs to declare it dead.

OK ..its dead. Let me find the pearl handled revolver.

>  Informational, NOT BCP.  Customers can pull this out the final doc as a
requirement regardless
>  of its track.

Ultimately I don't have a problem with Informational though technically I
think it falls under the sort of draft that is ultimately a  BCP but I don't
want to belabor the point. What is important is there is documentation on
this particular type of usage or operators and vendors will attempt to
implement all sorts of silly things.

>  Individual or AD-sponsored?

Because it was a WG item to begin with and IMHO we should not, to use a US
colloquialism, be "buck-passers" as in the "buck stops here".

>  -
>  >>> was a useful WG item. Some folks have come to us with a cleaner
>  form
>  >> of
>  >>> Informational than let multiple implementations go off in all
>  sorts
>  >> of non
>  >>> What does the WG want to do or do you want the chairs to decide?
>  We
>  >> are not
>  >>>> There is consensus that this is a item we had on the WG plate
>  that
>  >> has
>  >>>> real applicability to applications in use and clarification on
>  how
>  >> these