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

From: Alexander Mayrhofer <[email-masked]>
Date: Thu, 14 May 2009 10:35:20 +0200

Richard, fellow WG members,

I agree with Peter, as i think the real question is whether the WG want 
to continue pursue the draft-ietf-enum-trunkgroup ENUMservice or not.

The question whether the group wants to adopt the 
draft-malas-enum-trunk-sip is seperate from that - but i like the way 
that Peter proposed.

> 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)]

I think it is somehow *related* to ENUM because of the Enumservice that 
we are trying to get rid. Otherwise, i don't see why it would fit into 
ENUM. For example, it might well fit into DISPATCH as well?

> 2) Do you agree to abandon the approach in draft-ietf-enum-trunkgroup-00.txt?

Yes

> 3) Is the content of draft-malas-enum-trunk-sip-00.txt a better start instead?

Yes

> 4) Is anybody willing to review draft-malas-enum-trunk-sip-00.txt?

If it becomes an ENUM WG document, i might have to, being the secretary 
of the ENUM WG.

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

I would prefer if the WG concensus would be to remove 
draft-ietf-enum-trunkgroup from the WG "menu" entirely, and documenting 
the decision in draft-malas-enum-trunk-sip, but find a WG that suits 
better such SIP operational issues than the ENUM group.

The solution that Peter proposed is also viable, if authors and chairs 
believe that's a faster way. I just don't think the WG should accept new 
work, given it's current status of being slowly move to the pathology 
department.

Just to make clear: Content-wise, i definitely prefer the solution 
proposed in draft-malas-enum-trunk-sip. I'm just not entirely happy with 
the sloppy process.

Alex

---

From: "Richard Shockey" <[email-masked]>
Date: Thu, 14 May 2009 09:35:45 -0400

Well at least I got someone on the list to finally comment .. :-) 

Its not going into DISPATCH .it will never see the light of day.

>  -----Original Message-----
>  From: [email-masked] [mailto:[email-masked]] On Behalf
>  Of Alexander Mayrhofer
>  Sent: Thursday, May 14, 2009 4:35 AM
>  To: [email-masked]
>  Subject: Re: [Enum] WG: New Draft: Trunk Group Use in ENUM RESTART -
>  Secondrequest for guidence
>  
>  
>  _______________________________________________
>  enum mailing list
>  [email-masked]
>  https://www.ietf.org/mailman/listinfo/enum

---

From: "Richard Shockey" <[email-masked]>
Date: Thu, 14 May 2009 09:58:18 -0400

>  to continue pursue the draft-ietf-enum-trunkgroup ENUMservice or not.

Well my original intent was to 'clear the queue' so to speak and I'm
personally convinced this is an important draft to document. Its starting to
deploy now. I apologize if I had to 'shake the tree' so to speak to get
someone to finally answer the question on what to do.
  
>  draft-malas-enum-trunk-sip is seperate from that - but i like the way

Its fine with me as well.

>  I think it is somehow *related* to ENUM because of the Enumservice
>  that  we are trying to get rid. Otherwise, i don't see why it would fit
into
>  ENUM. For example, it might well fit into DISPATCH as well?

IMHO it's a individual draft or a ENUM WG draft I would not suggest to the
authors to go down the DISPATCH path. I currently have limited confidence in
the way DISPATCH will operate until proven otherwise. I'm personally pretty
disgusted actually. You have seen SIPPING flipped to DISPATCH. So whats the
difference except you have new chairs and not really new chairs at that.

>  > 2) Do you agree to abandon the approach in draft-ietf-enum-

As the co-author yes. As for Informational vs BCP I can live with
informational but I'll let Daryl comment on that.

>  > 3) Is the content of draft-malas-enum-trunk-sip-00.txt a better

Yes Either would work but this malas 00 IMHO is a much simpler approach and
would work equally as well. The document needs to be rewritten but that is a
wordsmithing issue.

>  draft-ietf-enum-trunkgroup from the WG "menu" entirely, and
>  documenting  the decision in draft-malas-enum-trunk-sip, but find a WG
that suits
>  better such SIP operational issues than the ENUM group.

Not going to happen. SPEERMINT wont take it and it the new RAI org is IMHO
just a reshuffling of the deck chairs. Pick your ship.

Its here or individual submission. 

>  believe that's a faster way. I just don't think the WG should accept
>  new  work, given it's current status of being slowly move to the
pathology
>  department.

IMHO finishing the work here with a single document the right way to go.
Lets clear the issue off the table. I don't like pushing off work to some
other WG that we should have completed ourselves. That's not right. We
agreed to do this in the first place, lets finish it.  

>  proposed in draft-malas-enum-trunk-sip. I'm just not entirely happy
>  with  the sloppy process.

Well it got caught is the process. It nothing new for WG's. You want bad
process I can talk about my current discussions with the IAB over the
liaison letter to SG2 over Infrastructure ENUM.

---

From: Daryl Malas <[email-masked]>
Date: Fri, 15 May 2009 11:14:12 -0600

All,

I personally think it should be considered as a BCP.  The main purpose is to
not simply "suggest" the use of the parameters in the SIP URI NAPTR, but
rather to say "it really, really should be done this way.  In fact, if you
do not do it this way, then you will likely be out of compatibility with
most implementations."  I think this is the best way to ensure industry
consistency.  This being said, if there is consensus to push it forward as
Informational, it is better to be documented than not at all, in my opinion.

Don, you commented before on this draft, do you have a perspective on the
value of this draft moving forward relative to the discussion?

Regards,

Daryl

> liaison letter to SG2 over Infrastructure ENUM.

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

---

From: Don Troshynski <[email-masked]>
Date: Thu, 21 May 2009 21:26:58 -0400

All,

After some thought, I think there is value in maneuvering this document toward a BCP.  It will take some work -- in my opinion, the debate involving a draft service type should be removed.  There is room to consider this a BCP because there exists the potential for different interpretations of the handling of trunk group information.  Should such information be interpreted locally to the ENUM client or added to the RURI for downstream handling?  Is this a matter of local policy?  

Also consider that if application of the technique in actual networks is a litmus test, there is enough precedent out there to consider this a BCP.

Don

-----Original Message-----
From: Daryl Malas [mailto:[email-masked]] 
Sent: Friday, May 15, 2009 1:14 PM
To: Richard Shockey; 'Alexander Mayrhofer'; [email-masked]; Don Troshynski
Subject: Re: [Enum] WG: New Draft: Trunk Group Use in ENUM RESTART - Secondrequest for guidence

All,

Regards,

Daryl

-----------------
Daryl Malas
CableLabs
(o) +1 303 661 3302
(f) +1 303 661 9199

---

From: Bernie Hoeneisen <[email-masked]>
Date: Fri, 22 May 2009 09:06:27 +0200 (CEST)

Hi Don et al.

IMHO it doesn't matter at this point in time whether it will be BCP or 
informational at the end of the day.

The more important question is find a proper home for this work: I 
propose this home to be SPEERMINT. This work, YMMV, is much closer to the 
SPEERMINT WG charter than to the ENUM WG charter. In case SPEERMINT won't 
take it, it's up to DISPATCH to decide on this.

cheers,
  Bernie

---

From: "Richard Shockey" <[email-masked]>
Date: Fri, 22 May 2009 09:59:24 -0400

Chair hat off ..

>  informational at the end of the day.

Yes it is important Bernie. BCP has a greater weight than Informational the
burden of proof is very different. BCP clearly requires extensive community
review.

>  propose this home to be SPEERMINT. 

NO .. Bernie you did not listen the SPEERMINT chairs do not want it there.
Its not in their charter.

This work, YMMV, is much closer to
>  the
>  SPEERMINT WG charter than to the ENUM WG charter. In case SPEERMINT
>  won't  take it, it's up to DISPATCH to decide on this.

NO again. Why do you want to kill this? The WG agreed to do it. I don't
understand this procedure argument at all. DISPATCH right now is a black
hole that no one understands how it will work. This is a perfectly simple
draft with a perfectly simple solution that needs to be clarified so people
can deploy it correctly.

IMHO the expertise is here in ENUM not in DISPATCH ..or SPEERMINT. 

>  > After some thought, I think there is value in maneuvering this
>  document toward a BCP.  It will take some work -- in my opinion, the
>  debate involving a draft service type should be removed.  There is
>  room to consider this a BCP because there exists the potential for
>  different interpretations of the handling of trunk group information.
>  Should such information be interpreted locally to the ENUM client or
>  added to the RURI for downstream handling?  Is this a matter of local
>  policy?
>  >
>  > Also consider that if application of the technique in actual
>  networks is a litmus test, there is enough precedent out there to
>  consider this a BCP.
>  >
>  > Don
>  >
>  >>>  I agree with Peter, as i think the real question is whether the
>  WG
>  >>>  want
>  >>>> Then publish draft-malas-enum-trunk-sip-00.txt as draft-ietf-
>  enum-
>  >>>  trunkgroup-01.txt,

---

From: Peter Koch <[email-masked]>
Date: Sun, 24 May 2009 18:21:29 +0200

On Fri, May 22, 2009 at 09:59:24AM -0400, Richard Shockey wrote:

I agree with Bernie that the category is the second decision to make, but ...

> burden of proof is very different. BCP clearly requires extensive community

... this is the wrong (i.e., reverse) approach.
First, if you are concerned about review, you can have IETF wide Last Call
for Informational documents, as well, even though it is not mandatory.
Second, organizing review and increasing its quality are up to the editors and
the chairs, regardless of the document category.
If I understand correctly, the technique under discussion is to be applied
mostly if not solely to Infrastructure ENUM?  Also, we're reducing the
registration process for ENUM services from Standards Track to Expert Review.
Both indicate to me that BCP is inappropriate because of the lack of breadth.

> NO again. Why do you want to kill this? The WG agreed to do it. I don't

Could you point me to that declaration of consensus, please?

> IMHO the expertise is here in ENUM not in DISPATCH ..or SPEERMINT. 

There's some irony here in that even though it's all so simple, we don't
really see discussion of the contents of the draft ...

-Peter (who pleas guilty as charged)

---

From: Bernie Hoeneisen <[email-masked]>
Date: Mon, 25 May 2009 17:48:03 +0200 (CEST)

Hi Rich et al.

> burden of proof is very different. BCP clearly requires extensive community

Before "Publication Requested" this does not matter too much.

> NO .. Bernie you did not listen the SPEERMINT chairs do not want it there.

I am not aware of any statement of rejection from SPEERMINT chair side.
At least Jason stated something different compared to what you claim.

On Thu, 05 Mar 2009, Jason Livingood wrote:

   I'm willing to consider it but only if the ENUM WG chairs feel strongly
   that this should come over to us.  If you guys can process it rapidly,
   and feel it is within your scope, then go for it.  If you are not sure
   it is totally in-scope and you expect to shut down soon so that you
   cannot move the document ahead, then we could fit this in as an
   "implementer-specific" document.  That's a long way of saying we can
   help if you like, but it's really up to you and Patrik.  :-)

> Its not in their charter.

As stated earlier (YMMV), I believe this is closer to the SPEERMINT 
charter than to the ENUM charter. From the SPEERMINT charter:

   The most focused deliverables of SPEERMINT are best current practices
   regarding exchange of real-time sessions among VoIP and other
   real-time application service providers and, in particular, how
   such calls are routed.

>>In case SPEERMINT won't  take it, it's up to DISPATCH to decide on this.
>
> NO again. Why do you want to kill this?

I never stated any intention to kill this. What leads you to such a 
assumption?

Note: Stating "the work shall be carried out elsewhere" is different 
from "I don't want the work to be done at all".

> The WG agreed to do it.

I do not recall the ENUM WG taking on the new approach as a WG item.

> I don't understand this procedure argument at all. DISPATCH right now is 
> a black hole that no one understands how it will work.

Note: DISPATCH is not chartered to carry out work, but to decide where 
work is carried out best within the RAI area.

> This is a perfectly simple draft with a perfectly simple solution that 
> needs to be clarified so people can deploy it correctly.

Well, I am not aware of any I-D that looked simple in the beginning to 
stay as simple until the end...usually the opposite is the case.

BTW: What is your schedule to close the ENUM WG?

cheers,
  Bernie