Subject: [PEPPERMINT] some comments on consolidated-provisioning-problem-statement-00

From: Otmar Lendl <[email-masked]>
Date: Tue, 11 Mar 2008 23:06:02 +0100

Some quick words on David's draft:

Overall: very good draft. It captures the core concepts we need.

>3.1.  Index/Key Data
>
>   The organization of registry data is based on specific phone numbers
>   or phone number prefixes (which could represent blocks of phone
>   numbers, regions, or theoretically whole countries).  For generality,
>   we will use the term prefix to include complete phone numbers as
>   well. 

Good catch. That makes the data modelling easier and covers both
open and closed numbering plans.

>                             These globally normalized prefixes always
>   begin with a plus (+) and a telephone country code.  

That's a good idea to make it clear that prefixes are fully qualified.
Maybe tweak the language a bit: "..prefixes are always written with a
leading + to avoid confusions").

>
>3.2.  Resolution Data
>
>   For each prefix, there is a variety of data that can be exchanged.
>   The most important set of data identifies that a specific VSP is
>   responsible for the prefix and in most cases the VSP provides a SIP
>   URI through which this prefix can be reached.

"reached" is maybe too strong. "addressed" might be better.

Perhaps add here a sentence stating that it is _not_ assumed that this
SIP URI is reachable via the public Internet using the RFC3263 process.
Instead, a further routing algorithm might be needed to find a suitable
next hop towards the destination network.

>
>   Like stated in the introduction it is imperative that the minimal set
>   of resolution data contain all the information required for a DNS
>   NAPTR RR.
>

I don't quite understand this sentence. Without specifying for which
enum-service you want to construct a NAPTR, it's hard to describe
the minimal set of data needed.

>   Additionally, as a future proofing mechanism it is recommended that
>   resolution data include a catchall (similar to a DNS TXT RR) for data
>   that is not currently present in any ENUM service definitions.

I don't quite get it. We have x- enumservices and quite generic
uri-schemes like data:, so we can put anything into NAPTRs. 
(which prejudices ENUM, which IMHO we shouldn't do at this step)

As we're talking about the provisioning protocol, we just need to make
sure we either can transmit arbitrary attribute/value pairs during the
provisioning step.

>   One final note.  One of the common "rewrite" rules for the URI in
>   NAPTR RRs for example is of the form "\[email-masked]"
>   where the "\1" refers to the telephone number being processed.  This
>   kind of shorthand should be available when processing prefixes in
>   bulk.

"..regardless of whether ENUM will be the query protocol".

>4.  Reachability vs. Routing
>
>   The goal of the registry is to provide sufficient information to
>   identify a responsible VSP for a prefix.  The responsible VSP can
>   provide a SIP URI that can be proxied or redirected as desired by the
>   VSP.  It is important to note that the registry is expected to return
>   the same responsibility data for all parties that query it.

Nicely put. Good.

>   Routing information is also out of scope of the registry provisioning
>   problem.  Once a responsible VSP is contacted, that VSP can use a
>   variety of techniques to route that request.  

hm. Shouldn't that be "Once the call originating VSP has learned the
identity of the responsible VSP, the O-VSP can use a variety of
techniques to route that request." ?

>
>5.  Operations on the Registry Data
>
>   Delete:  Remove a prefix from the registry.  Semantically it means
>   that the prefix no longer exists anywhere.
>
>   Port-out:  A port-out is similar to a delete, but could be logged
>   differently.  The semantics are that the prefix still exists, but
>   that the previous VSP is no longer responsible for it.

Perhaps note here that one difference between Delete and Port-out is
that in the case of Delete, further request can get matched by
super-prefixes existing in the registry, whereas in the Port-out case
the registry will return "not-found" even if a containing prefix exists.

>9.  Data Propegation

Propagation

>10.  Querying The Registry
>
>
>   When SIP is used for the query mechanism, the numbering registry
>   functions as a SIP redirect proxy [RFC3261] .  The input to this
>   mechanism is a URI or more importantly the UserInfo part of the URI
>   containing the number to be queried.  The response returned by the
>   proxy is either an error code indicating the absence of information
>   about the number queried or a redirect response (3XX) containing 1
>   (or more) Contact Headers representing available routing options.

Whoa, stop here. 

In 4. you wrote that the registry contains ownership information, not
routing information.

/ol
-- 
// Otmar Lendl <[email-masked]>, T: +43 1 5056416 - 33, F: - 933
// nic.at Internet Verwaltungs- und Betriebsgesellschaft m.b.H
// http://www.nic.at/  LG Salzburg, FN 172568b, Sitz: Salzburg
_______________________________________________
PEPPERMINT mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/peppermint

---

From: "David Schwartz" <[email-masked]>
Date: Wed, 12 Mar 2008 07:26:32 -0000

Hi Otmar.

Thanks for the input and nice catch with the 3XX redirect responses.

D.

-----Original Message-----
From: [email-masked] on behalf of Otmar Lendl
Sent: Tue 3/11/2008 10:06 PM
To: [email-masked]
Subject: [PEPPERMINT] some comments onconsolidated-provisioning-problem-statement-00

Nicely put. Good.

Propagation

Whoa, stop here. 

/ol

______________________________________________________________________
This email has been scanned by the MessageLabs Email Security System.
For more information please visit http://www.messagelabs.com/email 
______________________________________________________________________