Subject: RE: [Speermint] I-DACTION:draft-ietf-speermint-reqs-and-terminology-01.txt

From: "James McEachern" <[email-masked]>
Date: Wed, 22 Feb 2006 09:52:21 -0500

Some additional comments on this draft.

Section 4.3 states that "Private ENUM is generally regarded as one or more technologies (including DNS and SIP Redirect)..."  Are we really suggesting that SIP Redirect is an instance of Private ENUM?

Section 4.4 states that tel URIs are out of scope for Speermint.  However, the tel URI phone context can contain a domain name, which section 5.2 identifies as the "primary key to any information regarding reachability". If a tel URI contains a domain name in the phone context, should it still be out of scope for Speermint?  Are we assuming that it must first be translated into a SIP URI?

Section 2:  the paragraph after the diagram still seems a bit misleading to me.  This paragraph ends by saying that "the CRD can be derived from ENUM (i.e., an E.164 DNS entry), or via any other mechanism available to the user". This implies that a call initiated with a SIP URI may need to use some "other mechanism" to derive the CRD, but section 5.2 makes it clear that the domain portion of the SIP URI actually is the CRD.  Would it be worth adding one more sentence to the end of section 2 to make this clear?  I'm thinking something like this:
"In the case where a SIP URI is used, the domain portion of the SIP URI is the CRD."

Section 4.4:  Shouldn't this be changed to Infrastructure ENUM now?  
In addition this section almost reads as if Infrastructure ENUM does everything required to find points of interconnection, while the current thinking is that it provides CRD, which then ties in with Speermint to find points of interconnection. 

Section 5.8 says our protocol must be generic enough to encompass other protocols.  Do we really view this as a "must", or could it be a "should"?

Comment:  I like the restructuring of the draft. I think it improves the flow of the document significantly. 

Thanks
Jim

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Tuesday, February 21, 2006 3:50 PM
To: [email-masked]
Cc: [email-masked]
Subject: [Speermint] I-DACTION:draft-ietf-speermint-reqs-and-terminology-01.txt 

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Session PEERing for Multimedia INTerconnect Working Group of the IETF.

	Title		: SPEERMINT Requirements and Terminology
	Author(s)	: D. Meyer
	Filename	: draft-ietf-speermint-reqs-and-terminology-01.txt
	Pages		: 11
	Date		: 2006-2-21
	
This document outlines the solutions space requirements and defines
   the terminology that is to be used by the Session PEERing for
   Multimedia INTerconnect Working Group (SPEERMINT).  It has as its
   primary objective to focus the working group during its discussions,
   and when writing requirements, gap analysis and other solutions
   oriented documents.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-speermint-reqs-and-terminology-01.txt

To remove yourself from the I-D Announcement list, send a message to 
[email-masked] with the word unsubscribe in the body of the message.  
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-speermint-reqs-and-terminology-01.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-ietf-speermint-reqs-and-terminology-01.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

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

---

From: David Meyer <[email-masked]>
Date: Wed, 22 Feb 2006 07:51:44 -0800

Jim,

	Thanks for the comments. 

> Section 4.3 states that "Private ENUM is generally regarded as one or more technologies (including DNS and SIP Redirect)..."  Are we really suggesting that SIP Redirect is an instance of Private EN…

	That should probably be reworded. I'm not sure I remember
	where that text came from (need to check my cvs logs).

> Section 4.4 states that tel URIs are out of scope for Speermint.  However, the tel URI phone context can contain a domain name, which section 5.2 identifies as the "primary key to any information r…

	See Richard's note on this (with which I agree). Other comments?

> "In the case where a SIP URI is used, the domain portion of the SIP URI is the CRD."

	That wasn't what I had in mind. I'll clarify that in -02.

> In addition this section almost reads as if Infrastructure ENUM does everything required to find points of interconnection, while the current thinking is that it provides CRD, which then ties in wi…
	Yes, since terminology (and all fronts) is evolving,
	some inconsistency reamins. Another -02 issue.
 
> Section 5.8 says our protocol must be generic enough to encompass other protocols.  Do we really view this as a "must", or could it be a "should"?

	First, the use of 2119 in non-standards track documents
	is, well, controversial, so words like should and must as
	used in a document like this are less rigorously
	defined. That being said, I like "should" better. Others?
 
> Comment:  I like the restructuring of the draft. I think it improves the flow of the document significantly. 

	Thanks. That was Richard's (Stastny) suggestion.

	Dave