Subject: [e2md] Action Required: Your version of the Problem statement needed

From: Bernie Hoeneisen <[email-masked]>
Date: Thu, 13 May 2010 15:28:16 +0200 (CEST)

Dear E2MD fellows

>From the different opinions stated within the last months, I've come to 
the conclusion that we are missing a common understanding of the problem 
statement for E2MD. Or in other words, I am not sure whether all of us are 
trying to solve the same problem...

If we want to make progress of any kind we must sort this out, 
before taking any further steps.

Therefore I kindly request all of you to express to this list,

   WHAT YOU THINK IS THE PROBLEM we are going to address with E2MD?

Please send your version of the problem statement to this list no later 
than May 20th, 2010. (Note: the deadline for requesting meeting time for 
Maastricht is approaching.)

Once we have collected all the different versions of problem statement, we 
can consolidate those and we will have a basis for the decision on the 
path forward.

Looking forward to get your input (by Thu, 20 May 2010)!

cheers,
  Bernie

---

From: "Richard Shockey" <[email-masked]>
Date: Thu, 13 May 2010 10:59:59 -0400

Well for me its killing off SS7 and TCAP. People have other use cases that
are also interesting.

I don't think we have a issue understanding what is the problem statement
is. 

Non URI data in ENUM. What about that doesn't people understand?

Bernie why are you making this so complicated? 

>From what I can see there is little or no disagreement among the folks on
this list except with Dean who is playing proxy for some BOF tourists in
Anaheim. Shadow boxing future issues is intellectually interesting but at
this stage counterproductive.

The goal is forming WG and sorting out the issues there. The only goal right
is revising the proposed charter for clarity and deciding on what you folks
want to do in Maastricht because it is increasingly clear that I'm not going
to be there.

BTW there is another issue here.  Dean has indicated he may not be in
Maastricht either so there needs to be a group consensus on who should lead
another BOF there.

Frankly I'd like to nominate Ray Bellis for one of the co-chairs.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Bernie Hoeneisen
Sent: Thursday, May 13, 2010 9:28 AM
To: E.164 To MetaData BOF discussion list
Subject: [e2md] Action Required: Your version of the Problem statement
needed

Dear E2MD fellows

cheers,
  Bernie
_______________________________________________
e2md mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/e2md

---

From: Ray Bellis <[email-masked]>
Date: Thu, 13 May 2010 15:55:18 +0000

> Non URI data in ENUM.

Rich,

That's part of it, I agree, but probably not sufficient.  How about:

"Records in ENUM-like databases which do not represent communication
end-points".

That covers:

1. trees other than e164.arpa (since they're not strictly "ENUM")
2. metadata like "unused" and "send-n"
3. data unnecessarily forced into "uri-like" syntax
4. the possibility of other RRs (not ideal for some of us, but
   needs addressing, if only to eliminate it).

Ray

---

From: "Richard Shockey" <[email-masked]>
Date: Thu, 13 May 2010 12:21:12 -0400

You have a point ... consider below...

-----Original Message-----
From: Ray Bellis [mailto:[email-masked]] 
Sent: Thursday, May 13, 2010 11:55 AM
To: Richard Shockey
Cc: 'E.164 To MetaData BOF discussion list'
Subject: Re: [e2md] Action Required: Your version of the Problem statement
needed

Rich,

"Records in ENUM like databases which do not represent Session Establishment
Data (SED)" That aligns the terminology with SPEERMINT.

That covers:

Ray

---

From: Ray Bellis <[email-masked]>
Date: Thu, 13 May 2010 17:09:03 +0000

> Data (SED)" That aligns the terminology with SPEERMINT.

Isn't that rather x-over-IP specific? (per the "Multimedia INTerconnect"
part of the SPEERMINT acronym)

Ray

---

From: Dean Willis <[email-masked]>
Date: Thu, 13 May 2010 12:25:51 -0500

>   WHAT YOU THINK IS THE PROBLEM we are going to address with E2MD?

Trying to address, or going to address?

What we are currently trying to do based on current proposals and
discussion, as seen by the people for whom I'm apparently either a
meat-puppet or proxy or whipping-boy, depending on your POV:

An easily extensible framework for inserting arbitrary data into the
DNS, where that data is related to an E.164 number also resolvable in
the DNS. The framework's organizational model is expected to be based as
closely as possible on the existing ENUM framework. The framework is
expected to provide for a multiplicity of different data types and
provide for a semantic definition of each data type as well as define
its relationship with the aforementioned E.164 number. The framework is
NOT expected to provide a selective query mechanism; rather, a DNS query
for framework data associated with an E.164 number is expected to return
all such data known by the DNS to the querying node. The framework's
expected query mechanism is straight-up DNS, and as such will make no
considerations for authentication, authorization, or selective response
based on the identity of the querying node. Further, the framework is
expected to make no considerations for network congestion, reliability,
integrity, privacy, or overly-large response sets beyond the inherent
mechanisms of the DNS. The framework is expected to provide for
standardization and IANA registration of new data types without a
requirement for IETF consensus on each new data type.

I believe every objection I've been able to understand is related to
some assertion in the preceding statement. I've explored each one of
these points on the list (and in many individual conversations with list
participants), including making proposals for alternate constructions,
and found that the group consensus comes back to supporting the above
definition after we've talked about it awhile. It's probable that we
don't see our consensus position from the same perspective as the "loyal
opposition", but we really do need to understand and argue it from their
point of view if we expect to overcome their arguments.

--
dean

---

From: Ray Bellis <[email-masked]>
Date: Thu, 13 May 2010 20:24:35 +0000

> An easily extensible framework for inserting arbitrary data into the DNS,
> where that data is related to an E.164 number also resolvable in the DNS.
> The framework's organizational model is expected to be based as closely as
> possible on the existing ENUM framework. The framework is expected to provide
> for a multiplicity of different data types and provide for a semantic
> definition of each data type as well as define its relationship with the
> aforementioned E.164 number.

OK, I'm with you up to here, although I'd argue that only the first sentence
is actually a "problem statement".

> The framework is NOT expected to provide a selective query mechanism; rather,
> a DNS query for framework data associated with an E.164 number is expected to
> return all such data known by the DNS to the querying node.

Just like ENUM.

> The framework's expected query mechanism is straight-up DNS,

Just like ENUM.

> and as such will make no considerations for authentication, authorization, or
> selective response based on the identity of the querying node.

Just like ENUM.

> Further, the framework is expected to make no considerations for network
> congestion, reliability, integrity, privacy, or overly-large response sets
> beyond the inherent mechanisms of the DNS.

Just like ENUM.

> The framework is expected to provide for standardization and IANA registration
> of new data types without a requirement for IETF consensus on each new data
> type.

Just like ENUM (§3.4 of draft-ietf-enum-enumservices-guide)

> I believe every objection I've been able to understand is related to some
> assertion in the preceding statement. I've explored each one of these points
> on the list (and in many individual conversations with list participants),
> including making proposals for alternate constructions, and found that the
> group consensus comes back to supporting the above definition after we've
> talked about it awhile.

Certain participants have particular as-yet undocumented use cases in mind
which might benefit from selective responses.  Of course that really _would_
be problematic for the DNS folks, where objections to "Source URI" are
already on record, and as also evidenced by the extensive discussions in
DNSEXT regarding the Google/Yahoo! "client IP" option.

Beyond that you're probably correct about the group consensus although I
believe your choice of words on some of the allegedly contentious points is
unnecessarily prejudicial.

> It's probable that we don't see our consensus position from the same
> perspective as the "loyal opposition", but we really do need to understand and
> argue it from their point of view if we expect to overcome their arguments.

How can we understand and argue it from their point of view (and reach
consensus according to the IETF way) unless they come here and put their
point of view to us directly, in writing?  If it's not here in black and
white on the list then it's effectively just hearsay and FUD.

I do appreciate what you're trying to do, but proxying for the nay-sayers is
simply not going to achieve consensus.  They need to come here and speak for
themselves.

Kind regards,

Ray

---

From: "Richard Shockey" <[email-masked]>
Date: Thu, 13 May 2010 16:51:57 -0400

I may be thick this time of day but could you elaborate on your statement? I
don't Grok it.

-----Original Message-----
From: Ray Bellis [mailto:[email-masked]] 
Sent: Thursday, May 13, 2010 1:09 PM
To: Richard Shockey
Cc: 'E.164 To MetaData BOF discussion list'
Subject: Re: [e2md] Action Required: Your version of the Problem statement
needed

Ray

---

From: Dean Willis <[email-masked]>
Date: Thu, 13 May 2010 17:24:26 -0500

> simply not going to achieve consensus.  They need to come here and speak for

Practically speaking, they don't need to come here and we can't expect
them to.

They can achieve their goals merely by saying to the IESG/IAB (I*) that
E2MD is a bad idea and should not have a working group. If pressed, all
they have to do is rattle off the salient points in the problem
description I gave, and shut up. Said problem description unfortunately
hits a large majority of the "panic buttons".

We might (and evidently do) believe they're wrong. To make a case, we
need to 1) understand their arguments, 2) thoroughly refute those
arguments, and 3) do so in writing and in an I-D that is clear, concise,
and overcomes the arguments they're going to be making to the I*. This
I-D needs to be in front of the I* and lay out the arguments, so that
when they pop up, the I* has the refutation clearly in front of them.
further, once the I-D is in front of the I*, we need to take the time to
socialize it with the individuals involved. Once they've been talked
through the argument (if it is sound), they're a lot more likely to
press our opposition for details that said opposition is unlikely to be
prepared to present.

Think of this as a court case. The opposition are "confidential
informants" with good standing before the court, espousing a position
that is enshrined in tradition and practice. We're the plaintiffs,
asking the court to set a new precedent. The burden of proof is on us.
We aren't going to get very far by just showing up in front of the
bewigged justices and shouting about our inherent rightness.

--
Dean

---

From: Dean Willis <[email-masked]>
Date: Thu, 13 May 2010 17:36:15 -0500

> is actually a "problem statement".

Are the rest of the sentences true and consistent with the work we've
proposed to do?

...

> Just like ENUM.

That's not an answer to the argument. From their POV, it is an assertion
of what's wrong with the e2md approach.

> DNSEXT regarding the Google/Yahoo! "client IP" option.

On the other hand, taking selective response and DNS' weakness in this
area into consideration might well shift our solution space into another
line, where the objections would not be so easily argued.

In very large part, we're running into opposition because we're building
on top of the DNS. If we were building a parallel system, or an adjunct
system that DNS points into (but that puts the metadata itself outside
the DNS) then we wouldn't be getting the pushback we're getting.

So if there's any way WE can achieve consensus on a shift that
alleviates this issue, then we really, really ought to consider it.

> unnecessarily prejudicial.

Are they truly prejudicial, or just succinct and unapologetic? Clearly
they're emotionally loaded from the perspective of the IESG/IAB, but
does that make them "wrong"? Remember, I'm trying to phrase it the way
that "the opposition" will summarize the work, and they aren't going to
sugar-coat the pill for us.

We seem to feel like we have very good reasons for making the choices
that are producing the allegedly contentious points. Maybe if we got
them written down, we'd find that they're good enough to overcome the
contention. I'm personally not convinced yet, biut I'm prepared to be.

--
Dean

---

From: "Richard Shockey" <[email-masked]>
Date: Thu, 13 May 2010 18:48:48 -0400

RS> of course we can expect them to voice their opinions they don't need a
proxy. That is not the IETF way. 

RS> Fine lets recharter the ENUM WG and find out. The existing ENUM charter
was very explicit on allowing this kind of work to move forward.

2. The working group will examine and document the use of RFC 3761 to
facilitate network interconnection for services using E.164 addressing.
The working group will coordinate its activities with other IETF
Working groups, existing or to be chartered, that are investigating elements
of
peering and or interconnection for VoIP or other services that
typically use E.164 addressing.

3. The working group will continue examine and document various aspects
of ENUM administrative and /or operational procedures irrespective of
whether e164.arpa domain is used.

4. The working group will also examine the use of RFC 3761 technology
for storing and delivering other information about services addressed
by E.164 numbers, for example PSTN call routing and signaling data.

Again let's just go to the IESG and right now find out.  I've got precedent
( always a strong hand in any argument) and an approved charter on my side.
And RFC and approved ID's that are explicit on the issues. IMHO we have the
stronger argument and again this is not about the DNS its about making SIP
actually deploy better. 

Dean you have been working for lawyers too long.

---

From: Ray Bellis <[email-masked]>
Date: Fri, 14 May 2010 00:38:46 +0000

> Are the rest of the sentences true and consistent with the work we've proposed
> to do?

They're consistent with the approach in Bernie's draft.

However on the last call the it was proposed that it might be a good
idea to simply reboot the ENUM WG.  In another message Richard has shown
that much (if not all) of what we want to do is _already_ within charter.

[[[
I first proposed E2M during the Dublin IETF, as a way to mitigate concerns
that a particular ex-AD had over use of E2U for "non-communications data".
AFAICR he was OK with this proposal, which then laid dormant until Bernie
wrote it up.

For my own Send-N draft, my plan had actually been to simply wait for the
ENUM Services Guide draft to become an RFC, and the re-file under the expert
review process.
]]]

Ray

---

From: "Richard Shockey" <[email-masked]>
Date: Thu, 13 May 2010 21:20:13 -0400

So ... all in favor of re chartering the ENUM WG ..please hum on this list
or the ENUM WG list now attached.

Its time to force the issue. This is important work ultimately central to
making SIP work better. Stall and delay is not a rational option here. SIP
Service providers and IMS providers want clarity and direction on where the
technical standards are moving, if at all. If the IETF doesn't do this it
will be done privately and without proper community and peer review. 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Ray
Bellis
Sent: Thursday, May 13, 2010 8:39 PM
To: Dean Willis
Cc: E.164 To MetaData BOF discussion list
Subject: Re: [e2md] Dean's Proxy-Shill Version of the Problem statement

> Are the rest of the sentences true and consistent with the work we've
proposed

[[[

Ray

---

From: Ray Bellis <[email-masked]>
Date: Fri, 14 May 2010 07:23:28 +0000

> I may be thick this time of day but could you elaborate on your statement? I

I meant that the SPEERMINT term "SED" only applies (IMHO) to those
communication protocols that come under "multimedia" - e.g. SIP, etc.

We already have 'http' and 'mailto' URIs in ENUM, and whilst (at a stretch)
those could be considered "communication end-points" I wouldn't consider
them "SED".

Ray

P.s. +1 to the hum

---

From: Bernie Hoeneisen <[email-masked]>
Date: Fri, 14 May 2010 09:57:42 +0200 (CEST)

> They're consistent with the approach in Bernie's draft.

Just for clarification:

http://tools.ietf.org/html/draft-hoeneisen-e164-to-metadata-02 (based on 
the Dublin discussions and other sources) has never intended to force a 
particular solution. I intended to provide a problem statement and propose 
a possible solution to the problem that was being discussed prior to 
submission as I-D.

I still believe a solution along the lines of 
http://tools.ietf.org/html/draft-hoeneisen-e164-to-metadata-02 is 
feasible, however we need to address the concerns that have been raised in 
the meantime, one way or the other.

cheers,
  Bernie

---

From: Dean Willis <[email-masked]>
Date: Fri, 14 May 2010 03:10:57 -0500

Bernie Hoeneisen wrote:
> particular solution. I intended to provide a problem statement and 
> propose a possible solution to the problem that was being discussed 
> prior to submission as I-D.
> 
> feasible, however we need to address the concerns that have been raised 
> in the meantime, one way or the other.

Ok, that's important to think about.

Most of the "concerned parties" who spoke to me before or after the 
Anaheim BOF seemed to think that the cited draft's approach was a "done 
deal" and the that we were asking to form a WG that would polish that 
approach and send it up the tree.

Just how far away from that approach would we be willing to explore? 
Might we, for example, consider a model where the data is held somewhere 
outside of ENUM, and ENUM just contains a pointer to the data?

I ask because everytime we've started to move away from the 
metadata-in-enum model in conversation, we seem to have moved quickly 
back to it.

--
Dean

---

From: Bernie Hoeneisen <[email-masked]>
Date: Fri, 14 May 2010 10:15:04 +0200 (CEST)

As an individual I see it a viable way to work out at least parts of the 
E2MD cases in the ENUM WG (once we've sorted out which parts are 
suitable). In this case E2MD would continue to work on those parts that 
are not suitable for ENUM.

As a co-chair of the ENUM WG the appropriate answer to this consultative 
hum from Rich is: abstention

cheers,
  Bernie

---

From: Ray Bellis <[email-masked]>
Date: Fri, 14 May 2010 08:25:31 +0000

> outside of ENUM, and ENUM just contains a pointer to the data?

That depends on the data.

For Send-N, absolutely not.  The data is trivially small, and getting it
returned as quickly as possible in response to a query for an incomplete
number is a specific design goal.

For the example given during the BOF of a record describing a ring tone,
absolutely!  That should clearly take the form of a *reference* to the
ring-tone data, and not the data itself.

For unused, maybe a hybrid approach - a small amount of data might be
necessary in the actual record (i.e. a "reason code", combined with a
reference to more detailed information).

Ray

---

From: Jim Reid <[email-masked]>
Date: Fri, 14 May 2010 13:15:11 +0100

> Practically speaking, they don't need to come here and we can't expect

EH? Let me see if I've got this right. Some anonymous greybeards (who  
may or may not exist) don't/won't participate in the discussion or  
provide a clear indication of their concerns and requirements. But  
they get an absolute veto whatever bottom-up consensus the rest of us  
agree. Is this how the IETF works these days?

---

From: Jim Reid <[email-masked]>
Date: Fri, 14 May 2010 13:17:17 +0100

> or the ENUM WG list now attached.

hum++

Apologies for a relevant SubjectL header. :-)

---

From: Christian Larrinaga <[email-masked]>
Date: Fri, 14 May 2010 14:50:15 +0200

I don't believe IETF should be afraid if others decide to take IETF stuff and do their own take with it. That is not a good reason to do those carbuncle things In IETF. What is a good reason is if the WG is taking the initiative and doing work that is for everyone, scales and isn't just trying to satisfy a need in some walled garden. 

So what would be the workplan? Apologies if I've missed a draft that explains this. In which case I would be grateful for a pointer. 

Christian

On 14 May 2010, at 03:20, Richard Shockey wrote:

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

---

From: "Richard Shockey" <[email-masked]>
Date: Fri, 14 May 2010 09:50:54 -0400

CNAM is either way .. if the data is going to be used in a public DNS tree
yes there probably should be pointer that requires authentication. For all
the infrastructure EWNUM systems no..its just a look up function in a closed
trusted tree. 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Ray
Bellis
Sent: Friday, May 14, 2010 4:26 AM
To: Dean Willis
Cc: E.164 To MetaData BOF discussion list
Subject: Re: [e2md] Dean's Proxy-Shill Version of the Problem statement

Ray

---

From: "Richard Shockey" <[email-masked]>
Date: Fri, 14 May 2010 09:53:06 -0400

So it seems, plus rough consensus is no longer tolerated ..its unanimous
consent.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Jim
Reid
Sent: Friday, May 14, 2010 8:15 AM
To: Dean Willis
Cc: E.164 To MetaData BOF discussion list
Subject: Re: [e2md] Dean's Proxy-Shill Version of the Problem statement

---

From: Otmar Lendl <[email-masked]>
Date: Fri, 14 May 2010 16:03:46 +0200

> Non URI data in ENUM. What about that doesn't people understand?

Ok. Can I take it as a given that you don't need E2MD to support

* different answers based on who's asking
* different answers based on source-URI
* different answers based on some kind of trunk (or SIP-peer) information

?

otmar
-- 
// Otmar Lendl <[email-masked]>, T: +43 1 5056416 - 33, F: - 933 //

---

From: Hadriel Kaplan <[email-masked]>
Date: Fri, 14 May 2010 10:38:31 -0400

We can't expect people who object to an E2MD working group to join this mailing list to voice their objections - this isn't even an official working group mailing list!  And even if it were, it's not reasonable for everyone in the IETF to join every IETF mailing list they don't like.  Only the people *interested* in the topic join a particular list, not people dis-interested in the topic.  

The process of the IETF is for people with a common problem and goal create a charter to work on it, and that charter gets hashed out in public.  This mailing list is simply to help us hash out such a charter - not the place for the public consensus debate.  Dean's just trying to lay out what objections we'll face if we try it again.

-hadriel

> Jim Reid

---

From: Dean Willis <[email-masked]>
Date: Fri, 14 May 2010 11:09:30 -0500

Jim Reid wrote:
> provide a clear indication of their concerns and requirements. But  they 
> get an absolute veto whatever bottom-up consensus the rest of us  agree. 
> Is this how the IETF works these days?
> 

Yep. That's pretty much the BOF process in a nutshell.

The BOF makes areguments "for". The opposition makes arguments -- 
usually "against", but there can be more than one faction. The I* weighs 
the arguments. The decision is "rough consensus".

Note that resources meeting rooms, meeting slots, IESG attention, RFC 
editor, etc. are all scarce. This biases the process towards rejecting 
new work, especially if that work is controversial.

They have no responsibility to let us form a working group just because 
we want to. We have to be able to form a consensus in the greater 
community that the work is doable, benefits the Internet, has a 
community of interest that will deploy IN THE INTERNET, and that we have 
the right people committed to doing the work in the IETF. Lacking such 
consensus, the default answer is "No."

--
Dean

---

From: "Richard Shockey" <[email-masked]>
Date: Fri, 14 May 2010 13:15:03 -0400

Oh certainly all of the below are essential attributes of a successful e2MD
system.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Otmar Lendl
Sent: Friday, May 14, 2010 10:04 AM
To: [email-masked]
Subject: Re: [e2md] Action Required: Your version of the Problem statement
needed

?

otmar

---

From: Otmar Lendl <[email-masked]>
Date: Sat, 15 May 2010 22:33:07 +0200

> Oh certainly all of the below are essential attributes of a successful e2MD

Which contradicts your

> > Non URI data in ENUM. What about that doesn't people understand?

statement.

Plain DNS and thus ENUM do not provide these extended query features,
and if you need need them in E2MD, then E2MD is not just ENUM with
non-uri data.

You can't have it both ways.

otmar

-- 
// 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

---

From: Lawrence Conroy <[email-masked]>
Date: Sun, 16 May 2010 12:39:46 +0100

Hi Otmar, folks,
 Regarding non-URI data ...

 (i) Actually, we DID have a perfectly valid URI that can
      be used to contain data; the Data URL.
     Apart from anything else, this IS used in HTML in existing
      web sites that do not cause the interwebs to implode.
     It would have worked just fine;
      use of data: was blocked because IESG folk didn't *like* it.
     Otherwise, we wouldn't be having this extended meditation on
      the number of angels that will fit on a pinhead.

Hence Plan B was to define a DDDS application to use NAPTR to hold
 non-URI data, without the arcane restrictions on use.

(ii) As in all things, the problem lies not with ENUM but in
      the stunning way in which DDDS was written and approved.
     It is perfectly possible** to define a DDDS Application
      that uses NAPTR to produce an output other than URIs
      (viz. SNAPTR, D2U, ...)
     That DDDS application would NOT inherit the same textual
      restrictions as E2U on use of its target -because it is not E2U-.
     That application would have a new flag** indicating that the
      "target output in REGEXP is text", and explaining how the text
       should be interpreted.
**  Speaking of stunningly stupid, someone might raise an erratum on
     3404, as that reserves *all* flags for future versions of itself.

I continue to fail to see what is wrong or hard about this. Either:
- we work on E2U to remove the arcane textual blocks on data that
   does not *directly* lead to making a communications session to
   a remote target, is not definitely an assigned E.164 number, ...
OR
- we create a new DDDS application and rely on resolvers cacheing
   the NAPTR RRset.

My preference is for the former, but I'm easy either way.
Unused & Send-N & CNAM & "SPID" should be out the door quickly once
 folk decide which way they want us to work the Layer 9 problem.
"Small bite", "short timescales", "running code" -- this hits
 the traditional IETF punch points.
It might even be done before I retire.

----

Regarding selective responses ...
Providing different answers based on who's asking is indeed not the
 way that DNS servers according to 1034/1035 are supposed to act.
Perhaps one should raise that with OpenDNS & Google?

Hadriel has already said that this IS happening/going to happen, and
 he's waiting for a DNS code point to do this officially. (see, e.g.
 his posting of 29th march, that I received at 22:17:18 +1:00).

Once that code point is in place, I would imagine that the E2MD output
 would be a description of the data that *could* be returned and how it
 would be used.
Why this particular data was returned to a query by this particular
 client is NOT in scope for E2MD, AFAICT.

----
 
For the other scribes, have a thought to decaf and reducing the
 intake of psychotomimetics.

all the best,
  Lawrence

---

From: Jim Reid <[email-masked]>
Date: Mon, 17 May 2010 12:50:06 +0100

> Perhaps one should raise that with OpenDNS & Google?

This isn't our problem and we should keep well out of it. FWIW, there  
has been a discussion about Stupid DNS Tricks (tm) on dnsop and it  
doesn't seem to be going anywhere. The web content providers who want  
this stuff appear to be unable to convince the WG that their ideas are  
sound or worthwhile. These schemes will also lose big time when/if  
they sign their zones.

Followups and replies to [email-masked]. Thanks.

---

From: Victor Pascual Avila <[email-masked]>
Date: Tue, 18 May 2010 13:20:00 +0200

On Mon, May 17, 2010 at 1:50 PM, Jim Reid <[email-masked]> wrote:
> FWIW, there has
> been a discussion about Stupid DNS Tricks (tm) on dnsop and it doesn't seem
> to be going anywhere. The web content providers who want this stuff appear
> to be unable to convince the WG that their ideas are sound or worthwhile.
> These schemes will also lose big time when/if they sign their zones.
>

Wasn't that discussion on dnsext?

Cheers,
-- 
Victor Pascual Ávila

---

From: Jim Reid <[email-masked]>
Date: Tue, 18 May 2010 12:30:30 +0100

> Wasn't that discussion on dnsext?

yeah... whatever... who cares?

---

From: Lawrence Conroy <[email-masked]>
Date: Tue, 18 May 2010 13:21:59 +0100

Hi Folks,
 To second Jim's hint, please don't go hunting down that thread -- it will make your eyes bleed.
... and it is not going anywhere fast.
all the best,
  Lawrence