Subject: [Enum] Re: Last Call: 'Infrastrucure ENUM Requirements' to Informational RFC (draft-ietf-enum-infrastructure-enum-reqs)

From: Pekka Savola <[email-masked]>
Date: Thu, 9 Nov 2006 14:38:38 +0200 (EET)

On Tue, 31 Oct 2006, The IESG wrote:
> - 'Infrastrucure ENUM Requirements '
>    <draft-ietf-enum-infrastructure-enum-reqs-03.txt> as an Informational
> RFC
> 
> The IESG plans to make a decision in the next few weeks, and solicits
> final comments on this action.  Please send any comments to the
> [email-masked] or [email-masked] mailing lists by 2006-11-30.

I'm a bit wary of using upper-case keywords in requirements documents 
such as this, but I personally don't have a major issue with it 
because it hopefully doesn't cause much confusion between "protocol 
requirements" and "operational requirements".

Some detailed comments below,

substantial
-----------

   2.  Queries of infrastructure ENUM fully qualified domain names MUST
       return a result, even if the result is a Name Error (RCODE = 3).
       Queries must not be rejected, e.g., based on access control
       lists.

==> the example with RCODE=3 is maybe not the best one.  Rather or at 
the very least, you should also mention RCODE=5 (Refused, e.g., for 
policy reasons) which might be much more applicable than Name Error.

Actually, maybe this could call for another requirement such as: 
'Queries for existing names MUST NOT be responded with Name Error 
(RCODE=3)'.. because this would balkanize the name space, where from 
one point in the Internet the authoritative answer would be "name does 
not exist" and from another, "name exists".

Or is there already consensus that it's OK to create a split-view DNS 
for information that's supposed to be publicly available?

   5.  Implementation of Infrastructure ENUM MUST NOT restrict the
       ability of an end-user, in a competitive environment, to choose a
       Registrar and/or Tier 2 name server provider for end-user ENUM
       registrations.

==> you mention 'Tier 2 name server provider' but it isn't clear what 
this means.  Would adding a reference help?  Or are you already 
assuming certain kind of name server architecture?

==> it wasn't 100% clear what 'end-user ENUM registrations' means, 
also because this is pretty close to 'user ENUM ...'.  The ability to 
select who's controlling selected parts of its ENUM mapping 
("selecting the provider of the ENUM registration")? The ability of 
the user to register records of its own liking to its number ("ability 
to control the contents of the ENUM registration")?  I think you meant 
the former; should the latter also be a requirement?

   6.  Infrastructure ENUM SHALL be implemented under a top level 
domain
       that can support reliability and performance suitable for PSTN/
       PLMN applications.

==> this seems like a NOP requirement, given that you don't describe 
or give reference what those reliability or performance requirements 
are.  What are the real requirements?  Is it believed that some top 
level domains could not satisfy these?  If not, this requirement 
doesn't seem to be useful.

   8.  Proposed implementations of Infrastructure ENUM SHOULD:
       C.  Restrict the need for any additional resolver functionality
           to service provider resolvers.

==> you say this about service provider resolvers, but nothing about 
resolvers at large.  Maybe make these explicit:
 - Service provider resolvers should not be required to have 
additional functionality
 - Resolvers at large must not be required to have additional 
functionality

       E.  Minimize the client knowledge of the numbering plan 
required.

==> I'd go farther than saying 'minimize' as the clients who use this 
information should be expected to have zero knowledge of numbering 
plans.  This seems like a big NO-NO. Or are you referring to service 
provider resolvers with 'client' here?  While that might be acceptable 
as a performance optimization, I dislike even that.

4. Security Considerations

==> you mention user privacy concerns, but I'd also briefly mention 
(1-2 sentences) the requirement for the user to prevent or restrict 
number->username mapping information as you already mentioned in 
requirement 7.

editorial
---------

2.1. Definition

   Infrastructure ENUM is defined as the use of the technology in
   RFC3761 [2] by the carrier-of-record for a specific E.164 number [3]
   to map a telephone number into a URI [4] that identifies a specific
   point of interconnection to that service provider's network that
   could enable the originating party to establish communication with
   the associated terminating party.

==> that's a relatively long and complex sentence to start with.  
Could it be possible to rephrase it a bit?  Also it might be useful to 
s/carrier-of-record/carrier-of-record (as defined below)/; it wasn't 
first obvious to me where "carrier-of-record" is described.

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

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

---

From: Jim Reid <[email-masked]>
Date: Thu, 9 Nov 2006 13:50:59 +0000

On Nov 9, 2006, at 12:38, Pekka Savola wrote:

>        that can support reliability and performance suitable for  
> PSTN/PLMN
>        applications.
>

Indeed. I wonder why "top level domain" gets mentioned at all.  
There's nothing magical or special about Infrastructure ENUM that  
requires or justifies the creation of a TLD. It would be best to  
avoid opening up that layer-9 rat-hole in the ICANN/IANA/DoC world.  
Besides, didn't RFC3172 decree infrastructure domains live under .arpa?

---

From: "Pfautz, Penn L, GBLAM" <[email-masked]>
Date: Thu, 9 Nov 2006 12:29:14 -0500

Jim:
Just to be clear - we were not looking for a new TLD for infrastructure
ENUM. The authors of this draft would be happy to see the infrastructure
ENUM apex under .arpa. However, there may be other parties involved
(note that the ITU-T has yet to accept e164.arpa for user ENUM beyond
interim status.) We'd be happy with an apex domain that meets the
necessary performance requirements. 

Penn Pfautz

-----Original Message-----
From: Jim Reid [mailto:[email-masked]] 
Sent: Thursday, November 09, 2006 8:51 AM
To: Pekka Savola
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: Re: [Enum] Re: Last Call: 'Infrastrucure ENUM Requirements'
toInformational RFC (draft-ietf-enum-infrastructure-enum-reqs)

---

From: Jim Reid <[email-masked]>
Date: Thu, 9 Nov 2006 22:58:02 +0000

> necessary performance requirements.

I am sure that's the case. However the text in the draft doesn't say  
so. At least not clearly enough IMO. The current wording can (and  
will in some circles) be interpreted as meaning Infrastructure ENUM  
needs its own TLD. Just delete the words "top level" from the text  
and we're done. ie:

	6.  Infrastructure ENUM SHALL be implemented under a domain that can  
support 	reliability and performance suitable for PSTN/PLMN  
applications.

---

From: David Conrad <[email-masked]>
Date: Thu, 9 Nov 2006 17:40:18 -0800

Penn,

> However, there may be other parties involved

What performance requirements beyond those defined in RFC 3172 (which  
basically just applies 2870 to .ARPA) are necessary?

Thanks,
-drc

---

From: "Pfautz, Penn L, GBLAM" <[email-masked]>
Date: Fri, 10 Nov 2006 11:58:51 -0500

Will do.
Thanks for helping my clarify.

Penn 

-----Original Message-----
From: Jim Reid [mailto:[email-masked]] 
Sent: Thursday, November 09, 2006 5:58 PM
To: Pfautz, Penn L, GBLAM
Cc: Pekka Savola; [email-masked]; [email-masked];
[email-masked]

	6.  Infrastructure ENUM SHALL be implemented under a domain that
can  
support 	reliability and performance suitable for PSTN/PLMN  
applications.

with esmtp (Exim 4.43)
	id 1GiZic-0000k4-IR; Fri, 10 Nov 2006 11:59:06 -0500
Content-class: urn:content-classes:message
Subject: RE: [Enum] Re: Last Call: 'Infrastrucure ENUM Requirements'
	toInformational RFC (draft-ietf-enum-infrastructure-enum-reqs) 
Date: Fri, 10 Nov 2006 11:58:51 -0500
From: "Pfautz, Penn L, GBLAM" <[email-masked]>
To: "Jim Reid" <[email-masked]>
Cc: [email-masked], [email-masked], Pekka Savola <[email-masked]>,
	[email-masked]

Will do.
Thanks for helping my clarify.

Penn 

-----Original Message-----
From: Jim Reid [mailto:[email-masked]] 
Sent: Thursday, November 09, 2006 5:58 PM
To: Pfautz, Penn L, GBLAM
Cc: Pekka Savola; [email-masked]; [email-masked];
[email-masked]

	6.  Infrastructure ENUM SHALL be implemented under a domain that
can  
support 	reliability and performance suitable for PSTN/PLMN  
applications.