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

[Christer Holmberg <[e-mail]>]

Hi,

>From my experience as GenART reviewer, I can say that usage of consistent terminology is something that the whole IETF suffers from. But, it's getting better :)

There are also cases where we DO use consistent terminology, but where people have a different understanding of what it means. "Codec" is a very good (and unfortunately very often occurring) example. So, while the authors, or even everyone in the WG, have a common understanding of what something means, we need to make sure others will too.

Regards,

Christer

From: stir [mailto:[e-mail]] On Behalf Of Peterson, Jon
Sent: 18 August 2016 19:43
To: Mary Barnes <[e-mail]>
Cc: [e-mail]
Subject: Re: [stir] Review of: draft-ietf-stir-rfc4474bis-10

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.

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.

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