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

[Mary Barnes <[e-mail]>]

Jon,

Thanks for responding to Dave's comments - I found that quite helpful.  I
have some comments/responses below [MB].  As a caveat to my responses, I
did not read all the details in Dave's review.

Regards,
Mary.

On Sat, Aug 13, 2016 at 2:40 AM, Peterson, Jon <[e-mail]>
wrote:

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

[MB] As pendantic as it might seem, in my experience, the expectation is
that we are precise with terminology in the specs, so that qualifying
'header' as 'header field' and 'parameter' as 'header field parameter' is a
reasonable expectation. I've had to do that with the RFCs that I've
authored and in re-reading this document recently, I think it adds to the
readability/understanding in particular since the ABNF comes later. [/MB]


>
> >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.
>
[MB]  I think the challenge is that 'basic SIP literacy' isn't such a basic
thing anymore and it does require *a lot* of background to parse this
document, but I don't know a way around that. [/MB]

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

[MB] I'm not sure on this one, in particular given that it deprecates the
header fields defined in RFC 4474 (per section 8).  And, unlike other -bis
specs there is no summary section in this document of the differences
between the two.  Also, currently this draft doesn't indicate what impact
it has on 4474 in the header page. There is the sentence at the end of
section 1 stating that this document "revises RFC 4474" but that's not
particularly meaningful. Given that when we produced RFC 7044, we obsoleted
RFC 4244 despite RFC 7044 being backwards compatible with RFC 4244, I
really think that this draft should be documented as obsoleting RFC 4474.
[/MB]

>
> >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.
>
[MB] As another RFC 4244 example, we did find that moving the syntax early
in the document in RFC 7044 made it more readable.  From a developer's
perspective, I think it's helpful to have the syntax in mind as one reads
all the details of the processing.[/MB]

>
> 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.
>
[MB] I would 3rd the need for examples.  That has been a usual practice for
other RFCs defining new SIP header fields (and header field parameters).
[/MB]

>
> 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.
>
>
> _______________________________________________
> stir mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/stir
>
>