-----Original Message-----
From: Daryl Malas [mailto:d.malas at cablelabs.com]
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,
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" <richard at shockey.us> 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: enum-bounces at ietf.org [mailto:enum-bounces at ietf.org] 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
enum at ietf.org
https://www.ietf.org/mailman/listinfo/enum
-----------------
Daryl Malas
CableLabs
(o) +1 303 661 3302
(f) +1 303 661 9199
mailto:d.malas at cablelabs.com