Re: [Enum] Comments on draft-ietf-enum-infrastructure-enum-reqs

   From: "Pfautz, Penn L, GBLAM" <ppfautz@att.com>

   >There is also a lot of test discussing what is a "carrier-of-record".
   >But it seems to me that this is not a good idea -- if "infrastructure
   >ENUM" is to mean anything, the concept of the "carrier-of-record of an
   >E.164 number" must *already* be defined by some mechanism outside of
   >ENUM.  It might be useful to elucidate what the various possibilities
   >are, but the text must make clear that carrier-of-record is externally
   >defined.  Moving the discussion to section 2.2 seems to be a good idea.

   I believe the bullets in 2.1 make clear that carrier-of-record *is*
   externally
   defined and how in an easy to operationalize way while noting that
   national regulators have the final say.

I found the discussion quite confusing.  Let me try to explain why:

At the end of paragraph 2 of section 2.1, it says 'The
"carrier-of-record" is:', and since the section is titled
"Definition", this suggests that section 2.1 is authoritative in
defining the term.  Then there are three bullets which are presented
as alternatives to each other, but it's not particularly clear which
one applies in what cases.  And at the end, there is a sentence saying
the national authorities might change all this -- which suggests that
the national authorities are the authoritative definition anyway.

(BTW, shouldn't that last sentence be "It is understood that the
definition of carrier-of-record for E.164 numbers associated with a
geographic area is subject to modification by the national authorities
with jurisdiction over that geographic area."?  Otherwise, it sounds
like the definition depends on the jurisdiction of where the reader is
standing, not where the number is standing.)

The central problem is that this section doesn't make it clear what
the authoritative definition is.  IMO, it needs to state first that
the authoritative definition is in the telco universe.  If it then
wants to provide an explanation which is *likely* to remain consistent
with the authoritative definition, that's fine.  But the explication
has got to be explicitly marked as non-authoritative, especially
because it is in a section titled "Definition".

(Remember -- You work for AT&T and are very familiar with the concept
of carrier-of-record.  I (and most of your readers) have only a vague
idea of what carrier-of-record might mean.)

   This requirement was to address a specific request from the chairs
   that queries not simply be dropped on the floor without response
   causing re-queries and traffic flood.  The requirement you propose
   is actually much different and, while the initial (e.g., Tier 1)
   response may not be origin-sensitive, further processing is likely
   to be since A carrier may have different POIs for different
   interconnection partners.

OK, I hadn't looked at it like that.  But then I think the second
sentence of item 2 would be better phrased "Queries must not be
discarded without response..." -- "rejected" to my mind means an
explicit error response.  I doubt the DNS RFCs use the term
"rejected", but an NXDOMAIN response seems pretty close to "rejected"
to me, especially if it was generated due to some permissions
situation, rather than because there *really isn't* any information
for that name.

   I think the carrier-of-record definition has clear implications
   about the relationship Of infrastructure ENUM to number
   portability: if the number ports the right to register it moves to
   the recipient carrier as well.

If it's understood in the telco world that number porting changes the
carrier-of-record of the number, then I see no reason to mention it in
the I-D.

Dale

_______________________________________________
enum mailing list
enum@ietf.org
https://www1.ietf.org/mailman/listinfo/enum