Secure Telephone Identity Problem Statement and Requirements
draft-ietf-stir-problem-statement-05

[Ballot comment]
What is not clear to me: is  this document supposed to contain requirements, or is this supposed in https://datatracker.ietf.org/doc/draft-ietf-stir-threats/ ? 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.

[Ballot comment]
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.

[Ballot comment]
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.

[Ballot comment]

- 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
considered?

[Ballot comment]
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
  misbehavior.

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
  and
  to prevent intermediaries, such as SIP proxies, from launching
  man-in-the-middle
  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
  identification.

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.

[Ballot comment]
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
  misbehavior.

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
  and
  to prevent intermediaries, such as SIP proxies, from launching
  man-in-the-middle
  attacks by inserting spoofed headers as calls pass through
  intermediaries.

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

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.

[Ballot comment]
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
  misbehavior.

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
  and
  to prevent intermediaries, such as SIP proxies, from launching
  man-in-the-middle
  attacks by inserting spoofed headers as calls pass through the intermediaries.

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

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.

[Ballot comment]
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
  misbehavior.

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
  and
  to prevent intermediaries, such as SIP proxies, from launching
  man-in-the-middle
  attacks by altering calls as they pass through the intermediaries.

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

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.

[Ballot comment]
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
  misbehavior.

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
  and
  to prevent intermediaries, such as SIP proxies, from launching
  man-in-the-middle
  attacks by altering calls as they pass through the intermediaries.

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

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.

[Ballot comment]
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
  misbehavior.

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 and
  to prevent intermediaries, such as SIP proxies, from launching man-in-the-middle
  attacks by altering calls as they pass through the intermediaries.

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

Right. There will be security considerations associated with that improvement, right? 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.

IESG/Authors/WG Chairs:

IANA has reviewed draft-ietf-stir-problem-statement-03, which is currently in Last Call, and has the following comments:

We understand that this document doesn't require any IANA actions.

While it is helpful for the IANA Considerations section of the document to remain in place upon publication, if authors prefer to remove it, IANA does not object.

If this assessment is not accurate, please respond as soon as possible.

The following Last Call announcement was sent out:

From: The IESG
To: IETF-Announce
CC:
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (Secure Telephone Identity Problem Statement) to Informational RFC


The IESG has received a request from the Secure Telephone Identity
Revisited WG (stir) to consider the following document:
- 'Secure Telephone Identity Problem Statement'
  as Informational RFC

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2014-02-20. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract


  Over the past decade, Voice over IP (VoIP) systems based on SIP have
  replaced many traditional telephony deployments.  Interworking VoIP
  systems with the traditional telephone network has reduced the
  overall security of calling party number and Caller ID assurances by
  granting attackers new and inexpensive tools to impersonate or
  obscure calling party numbers when orchestrating bulk commercial
  calling schemes, hacking voicemail boxes or even circumventing multi-
  factor authentication systems trusted by banks.  Despite previous
  attempts to provide a secure assurance of the origin of SIP
  communications, we still lack of effective standards for identifying
  the calling party in a VoIP session.  This document examines the
  reasons why providing identity for telephone numbers on the Internet
  has proven so difficult, and shows how changes in the last decade may
  provide us with new strategies for attaching a secure identity to SIP
  sessions.




The file can be obtained via
http://datatracker.ietf.org/doc/draft-ietf-stir-problem-statement/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-ietf-stir-problem-statement/ballot/


No IPR declarations have been submitted directly on this I-D.

(1) What type of RFC is being requested?

It is appropriate to publish this problem statement as an Informational document.

(2) Please provide a Document Announcement Write-Up.

Technical Summary

  Over the past decade, Voice over IP (VoIP) systems based on SIP have
  replaced many traditional telephony deployments.  Interworking VoIP
  systems with the traditional telephone network has reduced the
  overall security of calling party number and Caller ID assurances by
  granting attackers new and inexpensive tools to impersonate or
  obscure calling party numbers when orchestrating bulk commercial
  calling schemes, hacking voicemail boxes or even circumventing multi-
  factor authentication systems trusted by banks.  Despite previous
  attempts to provide a secure assurance of the origin of SIP
  communications, we still lack of effective standards for identifying
  the calling party in a VoIP session.  This document examines the
  reasons why providing identity for telephone numbers on the Internet
  has proven so difficult, and shows how changes in the last decade may
  provide us with new strategies for attaching a secure identity to SIP
  sessions.

Working Group Summary

  This document is a product of the STIR working group.

Document Quality

  This document and its predecessors received significant review
  from during the working group formation stages to its current form.
  There is solid consensus that it reflects the problem the working
  group intends to address.

Personnel

  Robert Sparks is the document shepherd.
  Richard Barnes is the Responsible AD.

(3) Briefly describe the review of this document that was performed by the Document Shepherd.

The shepherd has reviewed this version of the document and its predecessors
to ensure it reflects working group discussions and to ensure it is ready
for wider review.

(4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed? 

No concerns.


(5) Do portions of the document need review from a particular or from broader perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML, or internationalization? If so, describe the review that
took place.

We have had good cross-area participation in the development of this document, particularly from individuals that participate heavily in the security area.

(6) Describe any specific concerns or issues that the Document Shepherd has with this document that the Responsible Area Director and/or the IESG should be aware of?

There are no specific concerns to call out.

(7) Has each author confirmed that any and all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have already been filed.

Yes.

(8) Has an IPR disclosure been filed that references this document?

No IPR disclosures have been filed referencing this document.

(9) How solid is the WG consensus behind this document?

This document has been thoroughly discussed by the group and has strong consensus.

(10) Has anyone threatened an appeal or otherwise indicated extreme discontent?

There has been no threat of appeal or significant discontent expressed with the content of this document.

(11) Identify any ID nits the Document Shepherd has found in this document.

There is one reference that is not used (currently [6]).

(12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, media type, and URI type reviews.

This document contains no content needing this type of formal review.

(13) Have all references within this document been identified as either normative or informative?

Yes.

(14) Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state?

There are no such references.

(15) Are there downward normative references references (see RFC 3967)?

There are no such references.

(16) Will publication of this document change the status of any existing RFCs?

No.

(17) Describe the Document Shepherd's review of the IANA considerations section.

The IANA Consideration section contains:

    This memo includes no request to IANA.

(18) List any new IANA registries that require Expert Review for future allocations.

There are none.

(19) Describe reviews and automated checks performed by the Document Shepherd to validate sections of the document written in a formal language, such as XML code, BNF rules, MIB definitions, etc.

There are no formal languages used in this document.