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

[Mary Barnes <[e-mail]>]

Hi Jon,

More responses inline below [MB].

Mary.

On Thu, Aug 18, 2016 at 11:43 AM, Peterson, Jon <[e-mail]>
wrote:

> Hi Mary,
>
> 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]
>
>
> If people really feel like it needs to be fixed, I can fix it - but I do
> feel justified in pointing out that our track record with this in SIP
> documents isn't real strong. The original RFC4474 used "header" informally
> quite a bit. So does RFC4244, actually, if you scroll through that. So does
> the Replaces header spec. So I'm not sure we really do have much of an
> expectation about being precise with this. The reason why, I imagine, is
> because the common and casual way we use it isn't actually ambiguous - no
> one who sees the phrase "Date header" is confused about whether we mean a
> header or a header field.
>
[MB] I don't disagree in general and specifically about RFC 4244, but we
went to a fair amount of effort for 4244bis (i.e., RFC 7044) to be more
precise and I do believe it improves readability and makes it more
understandable on a first read, in particular for folks that haven't been
involved in SIP standardization for 20 years.   Also, given the ordering of
the sections (i.e., ABNF towards the end), I find it really helps for
"canon" and "ppt" to be qualified as "header field parameters".   [/MB]

>
> But like I said, it isn't a huge deal to fix it - it's just that any
> pervasive edits like this can give rise to errors, and it's not clear that
> fixing this solves any real problem.
>
[MB] I don't disagree that there is a risk of introducing errors, but I
think, while tedious, this change is fairly straightforward in doing a find
and replaces (I personally usually don't do global changes as I'd rather
eyeball things to avoid the possibility of introducing the sorts of errors
you note).

Also, per Christer's later comment, I do think making the spec more
readable will be helpful for the gen-art reviewer.  My personal preference
is to fix things in the WG as it avoids others raising similar issues down
the road.  Of course, as you note, if I'm the only one that has this
concern, then fine. [/MB]

>
> <snip>
>
> 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]
>
>
> There is a summary of changes in the document; it's Section 15 "Changes
> from RFC4474". And well, the bis doesn't deprecate both the headers as
> such, it deprecates one header field and changes the syntax of the other.
> But more importantly, it keeps all the guts: the concept of an
> authentication and verification service, all the response codes, all the
> associated SIP behavior. The only real semantic change is the scope of
> protection of the signature itself, which has been reduced overall, and
> then with respects to the identities in particular has been honed to deal
> with telephone numbers better. Obsoleting the Identity-Info header and
> moving it into an "info" parameter of the Identity header is a just a
> syntactic change. Although we created some architectural modularity around
> credentials, the stir-certs mechanism still has the same properties as
> certs did in the original architecture. Allowing the Identity header to
> appear multiple times just removes a limitation in the original spec that
> doesn't seem useful in retrospect (and the way Identity-Info was originally
> done didn't allow it) rather than a change to how the header is to be
> understood.
>
> All that said, I do agree it probably should obsolete RFC4474, not merely
> update it. Or at least that's how I remember the process is supposed to
> work. I'll defer to chairs/Ads on this one.
>
> 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]
>
>
> There will be more examples!
>
> Jon Peterson
> Neustar, Inc.
>