Subject: [Enum] Robert and Douglas' Protocols and Services draft...

From: Michael Mealling <[email-masked]>
Date: Wed, 31 Oct 2001 08:42:38 -0500

Hi,
  Being one of the people who pointed out the need for something like this
I think this is the exact right way of solving this problem. Good job
guys! I would make two small additions to the document:

1) Define an IANA registry for both the protocols and the services. You've
   got the start of a template there, just add a field for the documents that 
   define the service and/or protocol and then add an IANA Considerations
   section.

2) I think you should specify the protocols in terms of ENUM usage and not
   leave them 'nakedly' defined. In the URI Resolution application it wasn't
   possible to say "just use the http protocol" because there were so many
   different ways of doing the URI resolution services. So we created 
   'profiles' of different protocols that narrowed the protocol down enough
   to make it interoperable for the specific Service you were attempting to do.
   I think you're going to have to do that here simply because there's 
   probably about a 100 different ways to do IM like functions with SIP. 
   For example: in the case of IM and SIP the actual protocol used would be 
   SIMPLE and not SIP itself, right?  Does that make sense?

-MM

-- 
--------------------------------------------------------------------------------
Michael Mealling	|      Vote Libertarian!       | urn:pin:1
[email-masked]      |                              | http://www.neonym.net

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

---

From: "Robert H. Walter" <[email-masked]>
Date: Wed, 31 Oct 2001 12:45:50 -0500

Hi Michael,

Thank you for the feedback... Your suggestion of defining an IANA
registry for both the protocols and services is excellent and we
will incorporate this into the next revision of the draft.

You raise an interesting point regarding the use of SIP with IM.
Will the SIP extension(s) proposed in the SIMPLE working group I-D
"SIP Extensions for Instant Messaging" (draft-ietf-simple-im-01.txt)
be absorbed into SIP or will a new extended SIP protocol (e.g. simple)
be born?  If the latter is the case, I agree that it makes sense to
specify SIMPLE as a resolution protocol.

Regards,

Bob

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]On Behalf Of
> Michael Mealling
> Sent: Wednesday, October 31, 2001 8:43 AM
> To: [email-masked]
> Subject: [Enum] Robert and Douglas' Protocols and Services draft...
> 
> 
> Hi,

---

From: "Judith Oppenheimer" <[email-masked]>
Date: Wed, 31 Oct 2001 13:24:13 -0500

What exactly is meant by "an IANA registry for both the protocols and
services"?

---------------------------------------------------------------------------
----------
Judith Oppenheimer
http://JudithOppenheimer.com
http://ICBTollFreeNews.com
212 684-7210, 1 800 The Expert
---------------------------------------------------------------------------
----------

> Robert H. Walter
> Sent: Wednesday, October 31, 2001 12:46 PM
> To: [email-masked]
> Cc: Michael Mealling
> Subject: QRE: [Enum] Robert and Douglas' Protocols and
> Services draft...
>
>
> Hi Michael,
>

---

From: Michael Mealling <[email-masked]>
Date: Wed, 31 Oct 2001 15:13:47 -0500

> will incorporate this into the next revision of the draft.

Cool...

> specify SIMPLE as a resolution protocol.

You're going to have this similar problem with every ENUM Service/protocol 
combination so its probably something that should be discussed in the
document.

-MM

---

From: Michael Mealling <[email-masked]>
Date: Wed, 31 Oct 2001 15:20:00 -0500

> What exactly is meant by "an IANA registry for both the protocols and

A list of the protocols and services that are used as part of the ENUM
application to ensure that there is a) clear documentation for a particular 
service or protocol and b) to ensure that collisions don't occur between
independent implementations.

See http://www.iana.org/numbers.html for some examples...

-MM

---

From: "Judith Oppenheimer" <[email-masked]>
Date: Wed, 31 Oct 2001 15:45:30 -0500

Got it ... just a quick reminder, IANA no longer exists.

Particularly for those of you who have insisted that ICANN will have
nothing to do wth ENUM, what was IANA, is now solely, wholly, ICANN.

ICANN staff, ICANN payroll, ICANN politics, ICANN decisions, ICANN policy.
ICANN implications and ICANN ramifications.

> From: Michael Mealling [mailto:[email-masked]]
> Sent: Wednesday, October 31, 2001 3:20 PM
> To: Judith Oppenheimer
> Cc: [email-masked]; [email-masked]; 'Michael Mealling'
> Subject: Re: [Enum] Robert and Douglas' Protocols and
> Services draft...
>
>

---

From: Richard Shockey <[email-masked]>
Date: Wed, 31 Oct 2001 15:35:01 -0500

>will incorporate this into the next revision of the draft.

Yes this is needed ... but again I would recommend that the model for the 
IANA registry be coordinated w/ other groups with similar needs ..VPIM 
SIPPING etc.

>specify SIMPLE as a resolution protocol.

Its all SIP ... and IMHO there should be only one definition for SIP.  the 
session is either

Richard Shockey, Senior Manager, Strategic Technology Initiatives
NeuStar Inc.
45980 Center Oak Plaza   Bldg 8     Sterling, VA  20166
1120 Vermont Ave NW Suite 400 Washington DC 20005
Voice 571.434.5651 Cell : 314.503.0640,  Fax: 815.333.1237
<mailto: [email-masked]> or
<mailto: [email-masked]>
<http://www.neustar.com>
<http://www.enum.org>
<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<

---

From: Tony Rutkowski <[email-masked]>
Date: Wed, 31 Oct 2001 16:08:07 -0500

>nothing to do wth ENUM, what was IANA, is now solely, wholly, ICANN.

Hi Judith,

Actually, IANA is an Order for Supplies from NIST.
http://www.ntia.doc.gov/ntiahome/domainname/iana/SB1335-01-W-0650.doc

It seems doubtful, especially post 9-11, that IANA
will cease to be a USGOV contracted function.  Indeed,
the last event of a similar nature ten years ago is
what kept it cemented to DOD rather than transferred
to the private sector.

--tony

---

From: Dave Crocker <[email-masked]>
Date: Wed, 31 Oct 2001 13:07:34 -0800

>Got it ... just a quick reminder, IANA no longer exists.

that news will come as a large surprise to the folks running 
<http://www.iana.org/>.

d/

----------
Dave Crocker  <mailto:[email-masked]>
Brandenburg InternetWorking  <http://www.brandenburg.com>
tel +1.408.246.8253;  fax +1.408.273.6464

---

From: Richard Shockey <[email-masked]>
Date: Wed, 31 Oct 2001 16:18:34 -0500

>Got it ... just a quick reminder, IANA no longer exists.

Judith ..please ... this is getting quite tiresome ... the IANA functions 
are contracted to ICANN and as such it exists as a functional entity.

>ICANN implications and ICANN ramifications.

This is a warning .. the co-chairs patience for this kind of "Jim Fleming" 
ranting is wearing very thin and as I have stated in the past, we will use 
our administrative control of the mail list manager  if we are pressed.

>--------------------------------------------------

---

From: "Judith Oppenheimer" <[email-masked]>
Date: Wed, 31 Oct 2001 16:20:28 -0500

Uh huh.

> From: Dave Crocker [mailto:[email-masked]]
> Sent: Wednesday, October 31, 2001 4:08 PM
> To: Judith Oppenheimer
> Cc: [email-masked]
> Subject: RE: [Enum] Robert and Douglas' Protocols and
> Services draft...
>
>

---

From: "Judith Oppenheimer" <[email-masked]>
Date: Wed, 31 Oct 2001 16:18:54 -0500

Uh huh.

  -----Original Message-----
  From: Tony Rutkowski [mailto:[email-masked]]
  Sent: Wednesday, October 31, 2001 4:08 PM
  To: Judith Oppenheimer
  Cc: [email-masked]
  Subject: RE: [Enum] Robert and Douglas' Protocols and Services draft...

  Hi Judith,

  --tony

---

From: Michael Mealling <[email-masked]>
Date: Wed, 31 Oct 2001 16:18:05 -0500

> Got it ... just a quick reminder, IANA no longer exists.

hmm...

[bailey:]/home/michael(1): ping www.iana.org
www.iana.org is alive
 
> ICANN implications and ICANN ramifications.

http://www.ietf.org/rfc/rfc2860.txt

-MM

P.S. If I claim that the IRS doesn't exist does that mean I don't have
to pay taxes?

---

From: Patrik Fältström <[email-masked]>
Date: Wed, 31 Oct 2001 22:21:51 +0100

> nothing to do wth ENUM, what was IANA, is now solely, wholly, ICANN.

Wrong, see RFC 2860 for the real story.

   paf

---

From: "Judith Oppenheimer" <[email-masked]>
Date: Wed, 31 Oct 2001 16:38:44 -0500

>  ... the
> IANA functions

Functionally, you and I are saying exactly the same thing.  Its no rant to
suggest that list members perhaps less familiar with ICANN issues, are
entitled to know what "IANA" means.

> From: Richard Shockey [mailto:[email-masked]]
> Sent: Wednesday, October 31, 2001 4:19 PM
> To: Judith Oppenheimer
> Cc: [email-masked]

---

From: "Judith Oppenheimer" <[email-masked]>
Date: Wed, 31 Oct 2001 16:49:28 -0500

Me thinks thou dost protest too much.  (And rather poorly at that.)

What ever happened to "don't shoot the messenger"?

(I really only expected the predictable reaction from you know who.  Can we
end this thread now?)

> Sent: Wednesday, October 31, 2001 4:18 PM
> To: Judith Oppenheimer
> Cc: 'Michael Mealling'; [email-masked]; [email-masked]

---

From: Richard Shockey <[email-masked]>
Date: Wed, 31 Oct 2001 17:29:50 -0500

> > will incorporate this into the next revision of the draft.

Ah ... wait a minute ...Mike ...

Let me take a moment and try and see if there is some organization we can 
bring into this process.

We are on the right track here and this is necessary work but I'm wondering 
if we can get some consensus on who might be doing what and why.

First ..the problem statement .. it was clear for a long time that there 
has to be some form of IANA registry for protocol service fields in the 
DDDS context. Now the question is how ( and by whom) is this to be 
documented since I am going to make a supposition that there may be more 
than one application (SIP-VPIM) etc that need to define behaviors here and 
more than one protocol (ENUM) that wishes to use the service.

I'm seeing a possible fragamation of what is necessary here ...

IMHO ..

1. There needs to be a ID standards track that defines the need and 
requirements for a IANA Registry. Mike do you want us to do that here?

2. Perhaps we need some clarification on the actual usage of those fields 
by 2916.

3. Specific applications need to have specific documents defining the 
protocol service fields and behaviors appropriate to those applications. 
(SIP - VPIM) and make the specific request to the IANA for inclusion. I 
have wanted to avoid this WG take on those tasks since it clearly more 
appropriate for SIPPING or other WG's define those documents.

4. That said  the Walter/Ranalli drafts point out there are ambiguities in 
the role of various protocols such SMTP for voice mail vs SMTP for email 
that may need to be clarified and documented separately. but .....but

I'd like to understand more about the problem statement that requires such 
a proliferation of service definitions in Walter/Ranalli since inherent in 
draft is desire to finely granulate the capabilities of end points in ways 
that I'm not sure NAPTR records were meant for.  This begins to look a lot 
like RESCAP or some protocol to resolve capabilities of endpoints and that 
has been a problem in the IETF for a LONG LONG time and I'm not sure we 
want to go there.

I just want to make sure we handle the process correctly and I'm open to 
suggestions on what is the best work plan.

---

From: Michael Mealling <[email-masked]>
Date: Wed, 31 Oct 2001 17:53:33 -0500

> requirements for a IANA Registry. Mike do you want us to do that here?

This would be the place to define that, yes.

> 2. Perhaps we need some clarification on the actual usage of those fields 

Yes. Since 2916 says there's only one service this would update 2916.
But, since 2916 needs to be updated to bring it in line with the DDDS
documents it might as well be in there. Yes. Sorry. They should probably
all go in one document.

> appropriate for SIPPING or other WG's define those documents.

Right. This group just creates the registry and then specifies what
an item going into that registry has to specify in order to 'qualify'.
(See the IANA Considerations document on what kind of policies to 
implement here: First Come First Served, IETF Concensus, etc).

> suggestions on what is the best work plan.

The solution set in the URI Resolution was essentially to define the
'protocol' part as not really a 'on the wire' protocol but instead
a profile of another for a specific purpose. Each 'profile' would have
to specify which Services it did and how. In ENUM's case there could
very well be two ways of doing SIP+VPIM. If two people decided that
both had good ways of doing it they would both write up a spec and
then register with the IANA. They both have to write up how they
handle each given Service. But at that point its a market decision about
which 'profile' gets used...

-MM