Secure Telephone Identity Problem Statement and Requirements
RFC 7340

Note: This ballot was opened for revision 03 and is now closed.

(Richard Barnes) Yes

(Spencer Dawkins) (was No Objection) Yes

Comment (2014-02-18 for -03)
No email
send info
This first comment is about halfway to a Discuss. If the IESG wasn't already chatting about application of the Discuss criteria to a ballot for another document and frightening the incoming ADs, and if this wasn't pretty obviously a problem and trivial to fix, I'd have balloted Discuss, so please fix it :D

This document contains a problem statement *and* requirements resulting from that problem statement, but the presence of a section on requirements isn't apparent from the document title, and isn't mentioned in the Abstract. There's one mention of requirements (and maybe even "start of an attempt to develop requirements") several paragraphs into the Introduction:

   With this document we would like to
   start an attempt to develop a common understanding of the problem
   statement as well as requirements to develop a vision on how to
   advance the state of the art and to initiate technical work to enable
   secure call origin identification.

and nothing else until you hit 

7.  Requirements

   This section describes the high level requirements of the effort:

If you could make the requirements a bit more visible, that would be great. As it is, if someone asked me where the requirements for STIR are after this doc is published, I couldn't find them from the RFC index or from the abstract.

The rest of these comments are mostly places where the document wasn't clear to me, or was more US-centric than I was comfortable with. Please consider them along with any other comments you receive.

In this text:

1.  Introduction

   With this document we would like to
   start an attempt to develop a common understanding of the problem

   statement as well as requirements to develop a vision on how to
   advance the state of the art and to initiate technical work to enable
   secure call origin identification.

I'm not understanding what "start an attempt" means - is the intention that a follow-on problem statement doc would be published later? I would have guessed "yes" from this, but then I guessed "no" because the document also contains requirements, and now I'm back to being lost.

In this text:

2.  Problem Statement

   This model worked as long as the number of entities was relatively
   small, easily identified (e.g., through the concept of certificated
   carriers) and subject to effective legal sanctions in case of

does "certificated" have a different meaning than "certified"? It's a word (I checked), but it's not a familiar word to me.

In the same section:

   Other boiler-room
         ^^^^^^^^^^^ is this word clear to non-native English speakers?

   organizations use number spoofing to place illegal "robocalls"
   (automated telemarketing, see, for example, the FCC webpage [16] on
                                                   ^^^ please expand,
                                                   and qualify as "US"?

   this topic). Robocalls are a problem that has been recognized
   already by various regulators; for example, the Federal Trade
   Commission (FTC) recently organized a robocall competition to solicit
               ^^^ please qualify as "US"?

   ideas for creating solutions that will block illegal robocalls [17].

In this text, but not only in this text:

4.4.  VoIP-to-PSTN Call

   Consider Figure 4 where Alice calls Carl.  Carl uses a PSTN phone and
   Alice an IP-based phone.  When Alice initiates the call the E.164
   number needs to get translated to a SIP URI and subsequently to an IP
          ^^^^^^^^^^^^ is?

   address.  The call of Alice traverses her VoIP provider where the
   call origin identification information is added.  It then hits the
                                                   reaches?  ^^^ 

   PSTN/VoIP gateway.  

the wording is more casual than I'm accustomed to (and I'm a pretty casual guy). If someone could make a gentle pass looking for wording like this, that would be helpful for ESL readers. 

In this text:

5.  Limitations of Current Solutions

   SIP Identity is meant
   both to prevent originating calls with spoofed From headers and
   intermediaries, such as SIP proxies, from launching man-in-the-middle
   attacks to alter calls passing through.  

the wording was difficult for me to grok. Does that mean something like this?

   SIP Identity is meant
   to prevent SIP UAs from originating calls with spoofed From headers 
   to prevent intermediaries, such as SIP proxies, from launching 
   attacks by inserting spoofed headers as calls pass through. 

In this text:

7.  Requirements

   Usability:  Any validation mechanism must work without human
      intervention, e.g., CAPTCHA-like mechanisms.

I know what you mean, but the text says (in Latin) "for example, CAPTCHA", and I'm pretty sure you mean "anything but CAPTCHA".

In this text:

10.  Security Considerations

   This document is about improving the security of call origin

Right. There will be security considerations associated with that improvement. I think it's fair to say they'll be addressed in the documents that define those improvements, but this is kind of a punt.

(Sean Turner) Yes

Comment (2014-02-20 for -03)
No email
send info
Verbose but it got through the gauntlet I think it ought to go.

(Jari Arkko) No Objection

(Stewart Bryant) No Objection

(Gonzalo Camarillo) No Objection

(Benoît Claise) No Objection

Comment (2014-02-20 for -03)
No email
send info
What is not clear to me: is  this document supposed to contain requirements, or is this supposed in ? Or maybe the two?  The charter is not too clear about this.
I'm mean: certainly, we would have some (others) requirements from the threat model, right? However, I don't even see the "requirement" word in draft-ietf-stir-threats?
Can you please clarify

Unlike some of my esteemed IESG colleagues, I actually like this document, which gives some history, explain the problem statement, and explain the limitations of the current solutions. Granted, it's a little bit verbose, but if one document type could be verbose, this would be problem statement. On regular basis, I claim that the IETF makes it too difficult for for newcomers to jump on the IETF train (how many SIP RFCs do we have?). This type of document provides the needed entry point.

I agree with Spencer's and Stephen's comments.

(Stephen Farrell) No Objection

Comment (2014-02-19 for -03)
No email
send info
- I like the document overall, thanks!

- It'd be an easier read if references were given more
readable names, e.g. things like "Some have therefore
proposed weakening the security constraints of [1]..."
make it hard to know what's meant sometimes. I get that
this'd be a lot of editing work to fix though, but I
think it would make the eventual RFC more useful for
longer if someone has the time and energy.

- 5.3 uses the term "nonce" wrong I think, I guess you
mean cookie really.

- 6.2, a reference for the "some national authorities"
statement would be nice to have.

- 6.3, "architecting new certificate authorities" isn't
quite right, you're talking about building new PKIs which
is a deployment and not necessarily a s/w thing. Bit of a
nit though.

- 6.X, I could suggest adding a new 6.7 since another
important thing that has changed is snowdonia. I can buy
that that's not done here though since STIR has been
underway whilst we're still figuring out snowdonia.  It
could still be worth noting though, since there is a real
tension there the WG will have to deal with.  That
tension being the inherent one between securing origin
information (good) and assisting pervasive monitoring
(bad). I realise that not all those involved in STIR do
consider PM as a bad thing, as least insofar as it might
be assisted by STIR, but nonetheless the tension is real.

- 7: I think you should say that these requirements will
be elucidated further in the WG. The reason is that
they're quite informally stated (e.g. "golden root")
which is ok as long as they're not used later as gospel
since that would likely lead to repeating arguments and
delay. If you do mean these requirements as gospel, 
then I think I'd likely turn this into a discuss.

- 7: The privacy requirement is limited to the
out-of-band case. I'm sure there will be things to say
about the in-band case too that will be different for
different potential solutions. I'm not sure if there's a
useful requirement you can state here though for that
without getting into solution detail. Was that

(Joel Jaeggli) No Objection

(Martin Stiemerling) No Objection

(Brian Haberman) Abstain

Comment (2014-02-19 for -03)
No email
send info
I don't have an issue with the general premise of this document.  However, I think its verbosity leads to significant information loss, resulting in a far less useful document.  For example:

1. It is completely unclear that there will be a list of requirements at the end of the story (hence part of Spencer's Comment).

2. The actual problem statement section contains far more historical context than actual statement of a problem.

3. Sections 4.x could easily be condensed into a concise (and readable) bulleted list.

4. Sections 5.x do not need long-winded descriptions of the current solutions.  A reference will do.

I think the document would be much more useful in a condensed format.  However, since the WG has consensus on this formulation, I am not going to stand in the way.

Barry Leiba Abstain

Comment (2014-02-19 for -03)
No email
send info
Indeed, what Brian said.  I think it's important for us to take a step back and pare down some of the language we put into documents that amounts more to marketing hype than to technical material.  My sense is that most people reading this would glaze over before they got to the important bits.