Subject: [stir] Summary comments on draft-ietf-stir-* document trio at WG Last Call

From: Dave Crocker <[email-masked]>
Date: Fri, 12 Aug 2016 16:25:27 -0700

Greetings,

I've done self-initiated reviews on the three documents that were put 
into the STIR Working Group Last Call:

    *  Secure Telephone Identity Credentials: Certificates
       draft-ietf-stir-certificates-07.txt
       "The use of certificates in establishing authority over telephone
       numbers"

    *  Persona Assertion Token
       draft-ietf-stir-passport-05
       "A token format for verifying with non-repudiation the sender
       of and authorization"

    *  Authenticated Identity Management in the Session Initiation
       Protocol (SIP)
       draft-ietf-stir-rfc4474bis-10.txt
       "A mechanism for securely identifying originators of SIP requests"

This note is a summary of the core comments and conclusions in those 
reviews, with some further thoughts.

The summary of all that follows is quite simple:

      These documents are in need of extensive additional work and after 
that is done, they still will not specify a coherent capability.  The 
worked need to turn this into a coherent capability is substantial and 
possibly risky.

My specific reviews are:

   Review of:  draft-ietf-stir-passport-05
   https://mailarchive.ietf.org/arch/msg/stir/vypQUp6ILfCitdB2PEWo_2bZmZw

   Review of: draft-ietf-stir-rfc4474bis-10
   https://mailarchive.ietf.org/arch/msg/stir/N334mEfCpWowtSnXNrx2ElPGr84

   Review: draft-ietf-stir-certificates-07
   https://mailarchive.ietf.org/arch/msg/stir/VkB0HMs5JrHRLcOrDmMukdIzD3A

Separately, I posted a comment about the choice of JWT/JSON:

   https://mailarchive.ietf.org/arch/msg/stir/8S0DnRRY6rb368Rt-k4zqQkbd90

Since I'm not a phone guy, I should preface with some information about 
my background that is relevant to the following comments, beyond noting 
that I have done technical work for quite a few decades and that I have 
extensive and varied IETF experience:  I've built and run a couple of 
national email services.  I'm a Senior Technical Advisor to M3AAWG 
<m3aawg.org>, which is an Internet anti-abuse trade association. I'm 
also a co-author of the current specification for DKIM, which provides 
an authenticated identifier for email.  Further I participate in a 
number ad hoc industry consortia that develop anti-abuse-related 
enhancements that are based on the use of DKIM and SPF.  I participated 
in the the STIR effort as it was chartered.  None of this guarantees 
that anything that follows is correct, but it should provide some 
context for my views about efforts to design technical services used to 
mitigate abuse...

Telephone spam is a serious, urgent, global problem, and has been for 
some years.   Efforts to mitigate it would be greatly aided by reliable, 
accurate caller-id authentication, similar to the benefits that already 
accrue for email anti-abuse efforts based on authentication.

The primary benefit will be to allow development of accurate reputation 
information for the caller-id, because then there is assurance that it 
has only been used by an authorized actor. In general, this promotes 
identification of calls from good actors, rather than directly serving 
to identify bad actors -- absent additional mechanisms, such as ones 
ensuring a semantic of exclusivity, with a guarantee that /all/ calls 
using the caller-id will be validated.(cf, DMARC)  However given some 
essential operational differences between telephony and email, this 
assurance is probably more easily made for telephony than it is for email.

Discussions to pursue a standardized telephony authentication mechanism 
began approximately 5 years ago. The IETF's STIR working group began 3 
years ago.

The technical aspects of global telephony probably preclude ever 
achieving a solution that will cover all phone service, everywhere.  The 
mix of telephone administrations is challenging, but the considerable 
mix of telephony technologies is the major impediment: differences in 
their underlying semantics and limitations to their extensibility make a 
comprehensive, hybrid solution highly problematic, if not impossible.

The STIR working group nonetheless originally pursued a set of hybrid 
solutions, only more recently gravitating toward a narrower effort, 
targeting a SIP-only initial capability for authenticated calls. 
Telephony is increasingly using SIP and there already is a significant 
global infrastructure using it.  In technical terms, SIP is more 
amenable to this kind of authentication enhancement, than are the legacy 
technologies, especially given that its use of header-fields for 
parameters and meta-data is almost identical to that of email, even to 
the point of having a "From" header field.

The nature of the basic tasks for this type of authentication service 
include:

     *  Deciding where to get the caller-id from.  The legitimate 
technical challenges here are that the SIP phone world has several forms 
of caller-id strings and several places they can occur.  So defining a 
deterministic algorithm is not necessarily straightforward.
However resolving the details in obtaining and processing the variations 
in caller-id appears to primarily be a matter of defining a precise and 
reliable algorithm.

The specifications have text that I believe is intended to provide this 
detail, but I was unable to converge on an understanding of what the 
deterministic behavior and results would be.  It appears to talk about 
possibilities, rather than provide a clear, reasonable and deterministic 
algorithm.

     *  Deciding on the authentication algorithms and data packaging -- 
data to hash, hashing algorithm, crypto algorithm, where to to put the 
result, etc.  This is quite a bit of detail and needs to be done 
correctly, but rarely involves creativity or any interesting debates. 
However, here too the specification seems to provide for alternatives 
rather than a single, simple, clear, interoperable solution, absent 
additional, unstated private agreements.

     *  Deciding how the public key is to be associated with the 
relevant 'identity' and deciding how it will be found and validated. 
That is, a key query service.  In most crypto services, this involves a 
'certificate' with an authority hierarchy.

        For common certs, these involve an independent public key cert 
infrastructure (PKI).  For DANE, the hierarchy matches the domain name 
hierarchy for the name having the key, which is stored in the DNS.  For 
DKIM, the key is self-certified: this key also is stored with the name 
and can (presumably) only be put there by the domain owner.

        Use of the 'common' PKI service is widely viewed as highly 
problematic, particularly in terms of making serious reliance on proper 
authentication, for more than mitigating man-in-the-middle attacks.

        DKIM has extensive deployment and operational experience, 
however its authority hierarchy only aligns nicely with domain names.

        The DANE model does not have significant deployment penetration 
or operational experience.  Also as with DKIM, it's authority alignment 
is with domain names, not telephone number administration.

        OAuth is a recent capability that might provide a reasonable 
cert model that can be applied here, but I don't know enough yet to be sure.

        Caller-ids based on classic telephone numbers, however, are 
problematic.  Especially due to number portability, the authority 
hierarchy for numbers does not align at all well with the string of 
numbers.  In effect, any next number in a sequence can be administered 
by a different entity.  Worse, a prior attempt at an inter-organization 
query service based on telephone number (ENUM) was not successful.

        In other words, the requirement to have an inter-organization 
query and validation capability for keys associated with caller-ids 
should be viewed as both difficult and discouraging, essentially at the 
level of a open research task:  We have no global experience with a 
successful version of a comparable inter-provider service, or at least 
not at the necessary scale.  But we do have examples of failure...

In any event nothing in the current specification specifies how to find 
and validate the associated key.  All that is supplied is very general 
commentary.  And this fact is worth repeating:  The trio of documents do 
not attempt to specify the highest-risk component to the authentication 
service:  a complete and interoperable key query mechanism.

Based on the discussions on the working group mailing list and from 
various private discussions, it appears that folk think that what 
remains to be done are mere details, or policies, rather than 
development of core technologies or mechanisms, and that these will be 
settled elsewhere (ATIS-SIP Forum, or the like).  But the work remaining 
includes basic functional capabilities, not mere administrative or 
operational (policy) details.  Perhaps these will indeed get resolved in 
those later discussions, but it will require quite a bit of additional 
effort and time. I suspect it will require far more effort than is 
currently appreciated.

My sense is that the folk intending to pursue use of this work have an 
underlying expectation that there will be a set of bilateral and/or 
multilateral provider-based agreements that determine the remaining 
details, rather than there being an integrated public service.  This has 
been, after all, common in the telephone industry.  However it is at 
odds with the IETF's approach to the definition of open, interoperable 
services that work at scale.

Further, the IETF's publishing the current specifications will mean that 
the IETF is blessing a set of documents that do not offer a coherent, 
usable technical capability.  I believe that is somewhere between 
unusual and unprecedented.

The proffered drafts do not include any coherent description of the 
integrated service that is being specified.  Simple architectural charts 
that show the components and how they are functionally connected, with 
descriptions of their roles and interactions, go quite a long way 
towards developing a shared, community understanding of what is being 
done.  An essential example here is to delineate relevant administrative 
trust boundaries.

Note that even very recent discussions on the list demonstrate a basic 
lack of this shared understanding, such as where validation will be done 
and what will be done with the result. And this example has profound 
import to the service model, since validation at end-user devices 
requires a key query service that will operate over the open Internet, 
whereas validation only amongst 'authorized' providers won't.

Some individuals seem to have a clear model for this.  However the group 
does not.

The design has chosen use of a JSON/JWT for a "Passport" abstraction of 
a common "token" collecting together identity, key and other 'claims' 
information.  In terms of computer science design, it looks reasonable; 
it is modular, based on some standardized technologies, and appears to 
be extensible.  And my original reaction to it was that while it was not 
necessary to the immediate task, it might have some long-term appeal. 
However the more I have slogged through the specifications and tried to 
discuss issues with individuals, it has become clear to me that it is 
adding quite a bit of complexity to the reading and probably to the 
software, for literally /no/ immediate benefit.  In fact, it is not 
merely additional overhead:  my sense is that it has made it more 
difficult to find various errors in the detail of the specifications. 
There is no JSON already in the SIP environment that is being signed; 
the extensibility is easily obtained more directly; and the aggregate 
specifications are significantly more difficult to comprehend.

The certificate draft is not a specification.  It is a discussion, often 
about basic concepts or about a hypothetical future.  Hence, the 
highest-risk component to the proposed capability remains entirely 
unspecified.

For all three documents, the writing often is bloated and opaque and 
error-prone, where the reader apparently is expected to have quite a bit 
of very detailed background that is not stated in the documents. One of 
the drafts had not even been processed through a spelling corrector, 
although this was a Las Call Verion.  Also, non-trivial algorithms are 
written as complex prose rather than simple algorithms. I suspect these 
have errors but can't be sure.  It often was not clear to me what was 
meant -- or it was clear that the text had not specified what it claimed 
to specify. The specifications are also often incomplete, with respect 
to the scope of the document.  That is, they simply don't cover what 
they say they will (and which they need to cover.)  The documents 
purport to provide modularity, but contain enough cross-references, 
cross-discussion and bi-directional dependencies to defeat this.

All of the above suggests a working group that did not seek to specify a 
complete capability, did not diligently participate in the specification 
and review of these documents, and does not have a precise and workable 
shared understanding of what the target service will be nor how that 
service will be achieved.  The difference between being able to validate 
at the callee's independent SIP implementation, versus requiring 
validation to be done by a service provider, is merely one of many 
examples of these problems with the working group effort..

I should also make at least a quick comment about the process problems 
that have been so clearly demonstrated on the list during my review 
effort:  In roughly 30 years of participating in the IETF and doing 
reviews of working group documents, I have never before seen an almost 
complete lack of public engagement in dealing with a review. 
Disagreement is common.  Silence is not.  The authors have refused to 
engage in substantive, public discussion about these reviews, promising 
instead to make back-room decisions as they see fit.  The rest of the 
working group has so far been almost completely silent on the substance 
of the reviews.

d/
-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net

---

From: "Peterson, Jon" <[email-masked]>
Date: Sat, 13 Aug 2016 07:54:49 +0000

>working group has so far been almost completely silent on the substance

I've only participated in the IETF for half as long as you, but I can say
I've never before seen someone decide to burst into a working group at the
last minute, dump 150+ objections on a document that is in last call into
a single mail, tap their feet impatiently at the lack of a timely public
vetting of those issues, and expect this all to lead to some kind of
productive result. The authors (well, I at least, and I seem to recall
some mail from Chris as well) have been willing to engage with you, just
apparently not on the terms you feel you are entitled to. From my
perspective, it is you who have refused to identify what you believe the
substantive issues are, instead hiding behind a claim that there are "many
and serious issues" buried deep in a mound of imposing comments. The
comments are objectively many, yes. Serious is a matter of opinion.

The list has hardly been silent since you dispatched your reviews, though
you may be frustrated that working group participants have mostly
concerned themselves with other issues. I don't want to speak for other
participants, at least one of whom said they found value in your comments,
but the lack of wider discussion may hinge on the way you've structured
your participation. Then again, it's also August. Chris, who is holding
the pen on stir-passport, is on vacation at the moment. I'm sure he'll
have some more notes when he gets back. Suggesting that this lack of
receptivity is a "process problem" rather than a problem with the way you
have chosen to engage with this working group is just one diagnosis. I
might seek a second opinion.

Jon Peterson
Neustar, Inc.

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

---

From: Dave Crocker <[email-masked]>
Date: Sun, 14 Aug 2016 07:51:33 -0700

Jon,

> a single mail, tap their feet impatiently at the lack of a timely public

You have again indulged in ad hominems, seeking to marginalize my 
postings, but mostly sounding more like the coarse frustrations of a 
plaintive child.[*]  Professional discourse really is a much healthier 
approach to these situations.  I encourage you to experiment with that 
alternative.

As for my bursting in on the scene:  You are well aware that I was quite 
active during the formation of this working group, including providing 
text for the charter, as well has my having extensive related experience 
to the problem being addressed here.  But even if I had had no prior 
contact, you sound as if you have never before experienced a diligent, 
cross-area review or the fine-grained inspection of an IESG member 
during the final approval process.  How odd.

In any event, you are also aware that at that time the effort was 
getting started I noted that the working group should focus on 
authenticating the SIP header, but you folk were insistent that you had 
to take a multi-pronged approach, in spite of very clear warnings that 
it would not be viable.  I also noted the need for a clear and concrete 
understanding of precisely how this work would get used and which 
entities would have what roles.

So here we are, 3 years later, with a proposal for authenticating the 
SIP header, exactly as I had recommended.  Better still is that it is 
quite clear that the group still does not yet have a solid and detailed 
agreement on the way this technology will get used.

Predictably, you've made a point of developing these specifications 
without trying to benefit from the 10 years of experience that has been 
gained in doing /exactly/ the same task for email.

The reviews I've done here are in the same form as I've been doing for 
years.  And yes, they took an extremely large amount of time to perform, 
so really, your thanks for my community-minded effort are greatly 
appreciated.

Sometimes, my reviews uncover basic and extensive problems.  You are not 
the first to be upset by them.  But, again, welcome to the world of open 
participation and late-stage cross-review.   Typically, the result of my 
reviews is significant improvement to the specifications.  Sometimes the 
authors respond constructively from the start, but not always.  It 
sometimes requires less emotional heads to rule.

> apparently not on the terms you feel you are entitled to. From my

You are trying to confuse 'interact' with 'engage'.  They are quite 
different.

Your postings on the list have been generic, with platitudes and 
challenges seeking to make me do more work.  They have not contained 
significant substance, until yesterday.  So no, you did /not/ engage.

Any foot-tapping of mine you might have heard was not impatience but 
rather frustration with your aggressive efforts to avoid engaging in 
public discussion of the reviews' substance.

> comments are objectively many, yes. Serious is a matter of opinion.

Jon, when someone puts the kind of very considerable time I've put into 
reviewing these documents and then posts it publicly, there is no 
hiding.  Or at least, not by me.

That you sought to impose an artificial burden back on me, as a way of 
limiting your public engagement with the details of the reviews, is your 
problem, not mine.

d/

[*] For reference, I filed a private complaint with the Chairs and AD, 
after Jon's second ad hominem posting in this sequence, but Robert chose 
merely to send a pro forma "let's do better" to both of us.  I noted to 
him it would not alter Jon's behavior, as indeed we now see it did not.

-- 

   Dave Crocker

---

From: Tony Rutkowski <[email-masked]>
Date: Sun, 14 Aug 2016 14:32:53 -0400

In 30 some years of Dave Crocker nastygrams, this is about
the worst I've seen.  You need to hold up a mirror to yourself
Dave.  Jon, Rich, Brian, and many others have been laboring
productively here, and the "dump 150+ objections in a last
call mail, and tap their feet impatiently" seems spot on.

--tony

---

From: "Gorman, Pierce A [CTO]" <[email-masked]>
Date: Sun, 14 Aug 2016 19:30:51 +0000

Respectfully, and without regard to timing or tenor, are any of Dave's objections material?  I'm not an expert on the material being discussed, but I have some responsibility for their commercial instantiation in my company and I'm concerned there is an emotional reaction which perhaps obfuscates real value in Dave's review.  No disrespect intended to Jon, Chris, et al, but if there is going to be a mauling over STIR, I'd prefer it be a short-lived one for the authors and their process rather than a long-lived one endured by the users.

Pierce

From: Tony Rutkowski [mailto:[email-masked]]
Sent: August 14, 2016 1:33 PM
To: [email-masked]; Peterson, Jon <[email-masked]>
Cc: [email-masked]
Subject: Re: [stir] Summary comments on draft-ietf-stir-* document trio at WG Last Call

--tony
On 2016-08-14 10:51 AM, Dave Crocker wrote:
You have again indulged in ad hominems, seeking to marginalize my postings, but mostly sounding more like the coarse frustrations of a plaintive child.[*]  Professional discourse really is a much healthier approach to these situations.  I encourage you to experiment with that alternative.

________________________________

This e-mail may contain Sprint proprietary information intended for the sole use of the recipient(s). Any use by others is prohibited. If you are not the intended recipient, please contact the sender and delete all copies of the message.

---

From: Richard Shockey <[email-masked]>
Date: Sun, 14 Aug 2016 17:24:23 -0400

Again .. it should come as no suprise that I am in agreement with Jon’s comments here.  In addition, if Jon seems rather rude or sarcastic in dismissing your comments /concerns I believe he accurately represents the consensus of many of us on this list.  I prefer to reserve my rude / sarcastic comments for one WG at at time aka MODERN. Even then my rudeness there is based on the observation within the telecom industry that tactically MODERN is barking up the wrong tree.  Right idea, wrong application to start with. 

Dave if this is your attempt to build a case to demand a full stop during IESG review then some of us have to document the counter argument right now. 

First. I restate. The proposed protocol construct is in fact “fit for purpose”.  In fact its better than “fit for purpose”.  It is clearly and demonstrably more flexable and extensible than DKIM for a good reason.  SIP is not SMTP.  Your fundamental objection is a classic case of false equilivency.  Just because DKIM works for SMTP does not imply that it would/should work for SIP.   I catagorically reject the notion that they are the same.  I will go a bit farther. This is Telephony, not the Internet.  The delegations of authority in both naming and addressing (E.164), SIP being realtime,  and the primary nature of nation state regulatory oversight are very very different than in general case of Internet protocols, though in the US with Title II reclassification you can make the argument that the Internet is now Telephony and not the other way around.  I’ll save that discussion for another policy panel at another time and place.

Second, though the immediate needs as defined in the charter were to validate claims about the Caller-ID (E.164) and potentially Calling Name within SIP headers it was clear to most of us that there would be addititional claims put forward about the session by various parties that would not and could not be accmodiated by the DKIM protocols.  What those claims might be do not need to be identified at this time. Nor does the WG need to address how the protocols could be used in different naming and addressing schemes.  Jon is more than capable of sharing with us his views on how this could work for WEBRTC at the appropriate time. We build tools and keeping the protocol construct to the minimum level in order to permit application providers maximum flexibility in how to apply those tools is a “good thing” tm. 

I have certainly made clear my objections to the drafts but those are clearly editorial and not fundamentally archiectural.

Third given the unique issues of nation state plenary authority in the E.164 namespace it is not necessary nor is it proper to define the underlying Certificate Management construct or how either the public or private keys need to be distributed. There is no way the North Americian Telecom industry is going to permit the kind of shenanigans we have seen in the general WEB PKI space. As far as telephone numbers go, for the time being we know how that delegation model works and what the industry agrees to _may_ generally match that model.  I dbout DNS/DANE will ever be considered, but in any event it will not be decided here. 

https://datatracker.ietf.org/doc/draft-iab-web-pki-problems/

Dave you are absolutely correct in several assertions. “Telephone spam is a serious, urgent, global problem, and has been for
some years.” “The technical aspects of global telephony probably preclude ever achieving a solution that will cover all phone service, everywhere.” 

What I reject is the characterization of the proposed solution as some hybrid Medusa that needs to be decapitated by the brave Ulysses before it threatens western civilization or 140 Billion dollars of US Telecom revenue. ( Ok that was a bit over the top even by my standards). 

Its August.  We should know more in the upcoming days and weeks as the powers that be gather.  So I’ll leave Jon with the following thoughts as if I were channeling Chairman Wheeler “Examples, Examples, Examples”.  

I submit we have rough consensus and after the next SIPit we may even have running code. 

On 8/14/16, 10:51 AM, "stir on behalf of Dave Crocker" <[email-masked] on behalf of [email-masked]> wrote:

    Jon,

    

    

    

    

    d/

    -- 
    
       Dave Crocker

---

From: Dave Crocker <[email-masked]>
Date: Sun, 14 Aug 2016 14:59:15 -0700

On 8/14/2016 2:24 PM, Richard Shockey wrote:
> if Jon seems rather rude or sarcastic in dismissing your comments
> /concerns I believe he accurately represents the consensus of many of
> us on this list.

Richard,

You appear to be saying the it is acceptable to indulge in disrespectful
and unprofessional behavior as long as (some) others agree with you.

Forgive me but I don't find support for that view in RFC 7154 or RFC 7776.

In fact, such an effort at bullying a participant is at the core of
creating a hostile work environment.

d/

-- 

   Dave Crocker

---

From: Richard Shockey <[email-masked]>
Date: Sun, 14 Aug 2016 18:25:06 -0400

So Dave what are you doing?  

There is a reasonable argument that your position, at this stage of the process, is an attempt at bullying the consensus of the WG into believing that we have made a fundamental mistake in protocol design and architecture.  

I’ve stated my case in a reasonable rational manner but at some point your false assertions can’t hide behind political correctness. 

As you have correctly noted this is a very very serious business. The lives and wellbeing of our fellow citizens in the US, UK and elsewhere are at risk.  It should not be surprising that emotions are running a little high so chill out please. 

— 
Richard Shockey
Shockey Consulting LLC
Chairman of the Board SIP Forum
www.shockey.us
www.sipforum.org
richard<at>shockey.us
Skype-Linkedin-Facebook rshockey101
PSTN +1 703-593-2683

On 8/14/16, 5:59 PM, "stir on behalf of Dave Crocker" <[email-masked] on behalf of [email-masked]> wrote:

    Richard,

    

    d/
    
    -- 
    
       Dave Crocker

---

From: Dave Crocker <[email-masked]>
Date: Sun, 14 Aug 2016 17:05:23 -0700

On 8/14/2016 2:24 PM, Richard Shockey wrote:
> First. I restate. The proposed protocol construct is in fact “fit for
> purpose”.  In fact its better than “fit for purpose”.  It is clearly
> and demonstrably more flexable and extensible than DKIM for a good

As you will see, if you read my reviews, the specs are profoundly 
deficient.  Feel free to respond to the substance of those reviews, 
rather than proffer summary rejections like this.

As for what STIR can do, there is nothing in its application here that 
is seeking to accomplish anything more than DKIM does, albeit here it is 
for caller-ID.  That one difference does mandate significant specific 
technical differences, but that's very targeted work.

> reason.  SIP is not SMTP.  Your fundamental objection is a classic

DKIM has nothing to do with SMTP.  If you are going to make assertions 
about technologies, please do so carefully.

As for the technical reference that /does/ suit for DKIM, it pertains to 
the message header and body (RFC 5322).

The SIP header was carefully modeled after that very same email header. 
So when you declare incompatibility, please be specific.  In what ways 
exactly, beyond the one you discuss, below?

>   The delegations of authority in both
> naming and addressing (E.164), SIP being realtime,

Where SIP is using domain names, it appears to permit STIR equivalence 
to DKIM. I carefully noted that telephone /numbers/ pose a special 
challenge.  But you folks haven't solved that either, in spite of have 
text that you are claiming does...

As for realtime, please explain what there is in STIR that provides 
differential performance from DKIM.  I don't see it.  (I actually 
suspect it will be slower than DKIM, but maybe not.)

> Second, though the immediate needs as defined in the charter were to
> validate claims about the Caller-ID (E.164) and potentially Calling
> Name within SIP headers it was clear to most of us that there would
> be addititional claims put forward about the session by various
> parties that would not and could not be accmodiated by the DKIM

It is easy to argue fantasies.  They are usually far more appealing than 
the drawbacks of cold, hard reality, and they never suffer the need to 
be concrete.  The fact of that matter, however, is that the current 
specifications have no need for that general a model and there are no 
specifications drafted that do.  Hence 'fantasy'.

The IETF has periodically had similarly high-minded, but untested, 
generalities built into its protocols, in anticipation of eventually 
making enhancements.  (e.g., SNMP Security field; TCP QOS)  They proved 
useless by the time folks got around to trying to use them.

> Third given the unique issues of nation state plenary authority in
> the E.164 namespace it is not necessary nor is it proper to define
> the underlying Certificate Management construct or how either the
> public or private keys need to be distributed.

There are many details that can be deferred, no doubt.  But what has 
been done here is to specify nothing concrete about the mechanics of the 
query/validation service.

This essentially seems to pretend that everything about such a service 
is policy, when it clearly isn't.

d/
-- 

   Dave Crocker

-- 

   Dave Crocker

---

From: Dave Crocker <[email-masked]>
Date: Mon, 15 Aug 2016 12:41:33 -0700

On 8/14/2016 3:25 PM, Richard Shockey wrote:
> ...but at some point your false assertions can’t hide behind political correctness.

Richard,

First, I cannot tell what statements of mine you are claiming are false, 
nevermind why you think they are false.  But your assertion is quite 
serious, so I will ask you to document your claim carefully and in context.

I also have absolutely no idea what you are referring to, when you 
suggest someone (me?) is hiding behind political correctness.  Again, 
please explain careful and, since this is an assertion about someone's 
behavior, document it concretely.

Thanks.

d/

-- 

   Dave Crocker