Re: [stir] Review of: draft-ietf-stir-rfc4474bis-10

["Peterson, Jon" <[e-mail]>]

I finally had a chance to go through these comments, and I did want to
provide a few responses on Dave's review of rfc4474bis here.

>Taken on its own and also when taken with its companion documents, the
>specifications are confusing and incomplete.  It is quite far from being
>ready for publication.

Having looked through Dave's specific concerns, I don't think he makes his
case for this criticism.

>Terminology is used inconsistently. It often is introduced with no
>background or citation.  Many uses of 'header' are probably supposed to
>be 'header field'.  My sense is that quite a bit of terminology is used
>equally loosely.

I think the use of terminology in the specification has proper background
and citations. Certainly Dave is correct that the text is pretty lax with
"header" vs. "header field" vs. "header field value," no denying that. If
people think this is a big deal, I will fix it. But the suggestion that
because this is true, terminology is loosely used to a point where it
would hamper implementation, that I think his comments don't really
substantiate.

>There is no integrative architectural description, so the reader has
>difficulty understanding what all of the pieces are or how they fit
>together.  In fact is appears that the document itself gets confused on
>this matter.

I'm not sure what an "integrative architectural description" would entail,
but there are a number of sections that provide overviews of operations
and related examples of how the architectural piece come together. I don't
think anything in the review comments genuinely substantiates that the
document itself is confused about its own architecture.

>Algorithms are all offered only as prose and often in a form mitigating
>comprehension, such as tending towards negation or disjunction, which
>humans process less well than affirmatives and conjunctions. From what I
>can tell, the algorithms often are incomplete, but serious analysis is
>difficult.

Algorithms are offered in steps with normative language, if that's what
you mean by "prose form". RFCs are typically composed of prose. The review
does reveal some very striking views about specmanship and algorithms in
particular which are foreign to my experience in the IETF.

>The documents appear to rely on a reader's having quite a bit of prior
>knowledge and are certainly not usable by an implementer who is not
>already deeply embedded in the community that produced these
>specifications.  My impression is that being embedded won't suffice
>either, both from my assessment of the documents' deficiencies and given
>back-channel comments I have heard about the expectation of the work to
>be done after these specifications are published.

We do expect basic SIP literacy, and a willingness to follow references
and read external specifications and sections that are cited. Readers that
are unwilling to do this will probably find a lot of things confusing in
there.

>Overall, the writing impedes comprehension and the document needs a very
>diligent pass by a technical editor.  I suspect this will uncover quite
>a number of semantic deficiencies in the text.

You did catch some good typos, and I caught a few more following your
notes through the text. I'm not sure that yielded the semantic
difficulties you speculate about here though.

>There is a possible tendency to support more alternative behavior than
>appropriate. Successful interoperability usually benefits from fewer
>choices, not more.  Common, mandatory canonicalization is an example.

Common, mandatory canonicalization of telephone numbers is unfortunately
only slightly more reliable than common, mandatory normalization of
internationalized domain names. At least it's just numbers. The algorithm
we have is good enough to cover the common operational case, and where it
fails, hopefully "canon" will help to close the gap.

>Credentials: the specification neither defines nor references a standard
>for the specification of credentials, here.  That means that the
>technical details -- as distinct from the operational policies -- of
>credentials are out of scope, although they are fundamental to proper
>operation of this serve.  This is a showstopper, in terms of
>specification completeness for the service.

Well, it does reference a standard for the specification of credentials:
stir-certs. I agree it would be a showstopper if we didn't have the
stir-certs work.

>How is the recipient to know what credential 'standard' is used?  How
>does this ensure interoperability between two participants who have not
>interacted before?

There is in practice only one at the moment. I'm content to worry about
interop problems when we have another one.

>At base, these specifications appear intended to roughly chart out a
>system structure, leaving most of the difficult work for later and
>elsewhere.  By way of example, there are few if any cross-organization
>key management services on the Internet that demonstrate the utility
>needed here.  I am pretty sure that Web certs don't qualify.  We know
>that DKIM's operation does, of course.  However DKIM strictly uses
>domain names as identifiers and they conveniently align with their
>administrative authorities, whereas telephone numbers do not...

I'd say that, by design, rfc4474bis is pretty tightly confined to
specifying the SIP over-the-wire protocol behavior. It takes a lot of spec
just to do that. 

And your praise of DKIM as a model is once again noted. I would respond
again that we are unlikely to abandon our years of work on this mechanism
and switch to DKIM at this point, no matter how many comments you place in
our path.

>      [[[ The mailing list just had an extensive regurgitation of
>critical commentary about ENUM.  What appears to be getting missed is
>that whatever mechanism is going to be used for finding and validating
>keys is going to have no operational history of reliability, safety or
>efficacy. ]]]

HTTP has none of those qualities, apparently.

>There is remarkably little of the original RFC 4474 substance still in
>this document.  Calling it a bis is a bit like tearing all of a building
>except its fireplace or its front door and calling that a remodeling.
>The previous document does not have an installed base, so I strongly
>suggest removing all references to it.  It will allow some of the text
>to be notably simpler and clearer.

I think enough of the concepts and protocol mechanisms of the original are
retained to warrant keeping this as a bis.

>The document is heavy with forward references.  These force the reader
>to stop what they are in the middle of, try to hold that place, and look
>forward to understand what they've just been interrupted from reading.
>As a literary style, forward references create useful tension.  In
>specifications they just interrupt the flow.  The document should be
>reorganization so that integrative text comes /after/ the text
>describing the pieces being integrated.  And opening overview, design
>summary, or the like can give a non-normative description of the
>architecture and the service, so the reader has a basic sense of the big
>picture, before diving into the detail of those to-be-integrated pieces.


Dave does make a number of organizational suggestions about the spec. The
spec has an overview, a design summary, before it gets down to specifying
things. The virtue of the "integrative" approach he describes is however
unclear to me. I think whether you define the auth service behavior first
or define the header syntax first, one of those sections is going to end
up pointing to the other. There wasn't much in his reorg suggestions that
seemed to me like a substantial improvement.

Overall, there are a handful of changes (beyond the typos, which again are
appreciated) I'd make based on the substance of Dave's review. Some of the
suggestions to rename sections seem harmless to me. Like some other people
who come to mind, he would like to see some more precise specification and
examples of how you break off the signature from JWT. He pointed out that
we really don't have any motivation for including multiple Identity
headers in there, and we probably do need an indication of what future
work might use that feature.

In terms of topics for discussion that might warrant the attention of the
working group, he did suggest we need to be sure we think the scope of the
signature is correct, and that we have enough confidence that
intermediaries won't break it, and that when it is broken, the verifier
behavior makes sense. I think we've focused a lot of attention on those
questions, but I'm happy to talk more about that if people think there's
room for improvement.

Also, he suggests that we might need a better pointer than RFC3986 Section
6.2.2 for URI normalization procedures. If anyone (including Dave!) knows
of one, I'd be happy to cite it instead.

Otherwise, I think we've got this covered. Anyone who's interested in
further details can see the attached.

Jon Peterson
Neustar, Inc.