Subject: [Enum] I-D ACTION:draft-ietf-enum-enumservices-guide-00.txt

From: [email-masked]
Date: Mon, 27 Feb 2006 15:50:02 -0500

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Telephone Number Mapping Working Group of the IETF.

	Title		: Guide and Template for IANA Registrations of Enumervices
	Author(s)	: J. Livingood, B. Hoeneisen
	Filename	: draft-ietf-enum-enumservices-guide-00.txt
	Pages		: 12
	Date		: 2006-2-27
	
   This document provides a guide to and template for the creation of
   new IANA registration of ENUM services.  It is also to be used for
   updates of existing IANA registrations.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-enum-enumservices-guide-00.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-enum-enumservices-guide-00.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-enum-enumservices-guide-00.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.
_______________________________________________
enum mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/enum

---

From: lconroy <[email-masked]>
Date: Tue, 28 Feb 2006 10:48:07 +0000

Hi folks,
   my initial reaction is "good stuff".
I like to read printouts - no tree-hugging here - so formal comments  
will follow
(especially as the section 5 ["consider update"] may involve me in  
work :).

On initial scan, I do have a couple of slight questions:

Section 3.2 states "This Enumservice indicates that the remote  
resource identified
     can be addressed by the associated URI scheme in order to foo  
the bar.".
Is this always required to be true?

Section 3.5 (Security Considerations) mandates coverage of access to  
Personally
Identifying Information. Good stuff.
Is it useful to split the Security Considerations section into two  
sub-headings
- one for protocol security issues and one for privacy/personal  
identity issues?

Again in Section 3.5, I note that the security section of an  
Enumservice registration
should not cover general issues.
Is is useful to split out the issues mentioned in the existing drafts  
and to produce
a general BCP that covers the issues mentioned already in those  
registrations (and
adds others if folk raise new issues :), including a reference to  
this BCP in each
Enumservice registration?
It would involve work to generate such a BCP, but it would deal with  
the general issues
in one place.
 From experience, this is A Good Idea, as some folk will just look at  
a single Enumservice
registration and so may miss some of the issues covered in others.
[It looks like this template proposes that the existing RFCs are to  
be considered for
re-drafting, so perhaps such a BCP could be done in concert with the  
proposed review.]

all the best,
   Lawrence

On 27 Feb 2006, at 20:50, [email-masked] wrote:
> Content-Type: text/plain
> Content-ID: <[email-masked]>
>
> ENCODING mime
> FILE /internet-drafts/draft-ietf-enum-enumservices-guide-00.txt

---

From: Bernie Hoeneisen <[email-masked]>
Date: Tue, 28 Feb 2006 14:25:31 +0100 (CET)

Hi Lawrence

Thanks for your good comments.

On Tue, 28 Feb 2006, lconroy wrote:

> Section 3.2 states "This Enumservice indicates that the remote resource 
> identified
>   can be addressed by the associated URI scheme in order to foo the bar.".

This is meant as an example. I think the content of such a section depends 
on the Enumservice to be registered.

> Personally Identifying Information. Good stuff. Is it useful to split 
> the Security Considerations section into two sub-headings - one for 
> protocol security issues and one for privacy/personal identity issues?

IMHO this makes sense.

> Again in Section 3.5, I note that the security section of an Enumservice 
> registration should not cover general issues.
> and to produce a general BCP that covers the issues mentioned already in 
> those registrations (and adds others if folk raise new issues :), 
> including a reference to this BCP in each Enumservice registration?
> It would involve work to generate such a BCP, but it would deal with the 
> general issues in one place.
> From experience, this is A Good Idea, as some folk will just look at a 
> single Enumservice registration and so may miss some of the issues 
> covered in others.

IMHO it makes sense to have the general issues at one place, where those 
can be referred to. I guess we'd have to find a clear structure for this 
to keep it manageable.

> [It looks like this template proposes that the existing RFCs are to be 
> considered for re-drafting, so perhaps such a BCP could be done in 
> concert with the proposed review.]

Hmmmm....Looks like a bigger concert...;-)

cheers
  Bernie