Subject: [VIPR] Review of VIPR Overview

From: Eric Burger <[email-masked]>
Date: Fri, 20 Jan 2012 07:44:27 -0500

I volunteered to review draft-jennings-vipr-overview-02, "Verification Involving PSTN Reachability: Requirements and Architecture Overview," during the VIPR meeting at IETF 82.  My focus is on the readiness of the document for adoption as a work group item.  I did not focus on whether the document is ready for publication.  As an aside, it is NOT ready for publication.

It is my belief the document is ready for adoption as a work group item.  The document is of a sufficient maturity, explains the problem, and is mostly self-consistent.  There are a number of items left for work group discussion, but they are not substantial open issues, which would indicate the document would not be ready for work group adoption.

What follows are my comments on the document.  Consider them as a potential starting point for work group discussion.

GENERAL
=======
This document reads like a patent application and product advertisement all rolled up into one.  There is no value in trying to convince the reader that VIPR is novel, fundamentally different that what was out there, clever, or neat (all language taken from the draft).  Such language is distracting for an implementor.  More to the point, we want implementors focusing on implementation, not thinking about how to show that one feature or another is not novel.  The most egregious examples of this language are Sections 5.3.1 in the second paragraph and 2.2 discussing how email is useless.  I would not want an implementor to think, "Well, I just received this via email, so if the assertion is email is useless, this protocol must be useless."

FORWARD (or no) REFERENCES
=========================
There are a number of forward references or references to items that a PSTN telecom engineer might be familiar with, but an Internet engineer might not be familiar with.  For example, REQ-2 refers to E.164 numbers.  This is the first we hear of E.164 numbers.  I would offer that mentioning that when we say Phone Number, we mean an E.164 number.  A good place for that would be in Section 2.1.  Include a reference to E.164 there, too.

REQ-12: what is call handover? This word appears only once, here. I know what that means in the PLMN, but I do not know what it means in the SIP world.

Call Agent: for a while, I thought I was reading an H.323 document, not a SIP document. I can get why one does not want to call the thing that knows VIPR a SIP User Agent, because it does more than a SIP User Agent.  If one wants to use the term "Call Agent," one must define it somewhere, preferably at the beginning of the document.  However, given the confusion with H.323 Call Agents, I would offer one either selects a different term, or perhaps use "VIPR-enabled User Agent."

Ticket: Section 5.3.3 starts talking about generating tickets, but never defines what a ticket is.  The reader has to read the whole document to figure that one out.

Section 5.3.4 talks about cached routes and 'next call agent in the path.'  However, the document never discusses chains of call agents, multiple routes (except in an aside in the previous paragraph to the reference to the path), or what a path is. In fact, this is the sole appearance of the word 'path' in the document.

OTHER
=====
REQ-4: Users do not make the federation; they make calls. Is not the requirement that without doing anything different users can now do inter-domain IP calls?

REQ-11: This describes a solution, not a requirement. I would offer language such as "The solution should be self-learning and adapt to VIPR call failures."

NITS
====
Page 11, 2nd list entry: s/SIP endpoints, or with non-IP/SIP endpoints and with non-IP/

Page 11, 7th list entry: Never, Ever? One Never is good enough. This whole section needs to be made relevant to implementors or be removed.  See the comment above about patent and marketing language in specification documents.

Page 21, 3rd from last paragraph in Section 5.3.4, floating period after the string "Section 5.3.3 ."

Page 24, Acknowledgements: let me in on the joke: I could imagine Theo being a thief of numbers.  Maybe in the fifth Ring [sic].  If he really is, I would suggest saying "5th thief [sic]". Otherwise, I would suggest saying "5th theft", if that is what the document means.

---

From: Cullen Jennings <[email-masked]>
Date: Thu, 26 Jan 2012 18:35:06 -0700

Eric, thanks for the review.

On Jan 20, 2012, at 5:44 AM, Eric Burger wrote:

> This document reads like a patent application and product advertisement all rolled up into one.  There is no value in trying to convince the reader that VIPR is novel, fundamentally different that what was out there, clever, or neat (all language taken from the draft).  Such language is distracting for an implementor.  More to the point, we want implementors focusing on implementation, not thinking about how to show that one feature or another is not novel.

mostly agree - always hard to decide how much the document should go into what problems this solves and where it is useful. That's not useful info for implementer but it is useful for someone considering deploying. But of course I agree with about gratuitous advertising can go. I've order a t shirt with "patent application and product advertisement all rolled up into one"

>  The most egregious examples of this language are Sections 5.3.1 in the second paragraph
'
Looks like deleting "neat", "clever" , "incredible " , and "enormous" would fix this paragraph. 

> and 2.2 discussing how email is useless.  I would not want an implementor to think, "Well, I just received this via email, so if the assertion is email is useless, this protocol must be useless."

How would you suggest a rephrase of email is useless.... (send over email please)

> FORWARD (or no) REFERENCES
+1 

> REQ-12: what is call handover? This word appears only once, here. I know what that means in the PLMN, but I do not know what it means in the SIP world.

I suspect we could just delete this and no one would care. 

> Call Agent: for a while, I thought I was reading an H.323 document, not a SIP document. I can get why one does not want to call the thing that knows VIPR a SIP User Agent, because it does more than…

Call Agent used to be PBX but then it got replaced ....

> REQ-4: Users do not make the federation; they make calls. Is not the requirement that without doing anything different users can now do inter-domain IP calls?
Perhaps change 

OLD
in inter-domain IP federation

NEW
in inter-domain calls using IP

> REQ-11: This describes a solution, not a requirement. I would offer language such as "The solution should be self-learning and adapt to VIPR call failures."
This needs to be rewritten. What it is trying to get at is a requirement that if the new IP based calls are not working, the systems fall back to doing inter domain calling in whatever way they did before 

> Page 11, 2nd list entry: s/SIP endpoints, or with non-IP/SIP endpoints and with non-IP/
+1

> Page 11, 7th list entry: Never, Ever? One Never is good enough. This whole section needs to be made relevant to implementors or be removed.  See the comment above about patent and marketing languag…
+1

> Page 21, 3rd from last paragraph in Section 5.3.4, floating period after the string "Section 5.3.3 ."
+1

> _______________________________________________
> VIPR mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/vipr

---

From: Mary Barnes <[email-masked]>
Date: Fri, 27 Jan 2012 15:16:39 -0600

Eric,

Thanks also for the review.  Just a few additional comments below [MB].

Mary.

> Looks like deleting "neat", "clever" , "incredible " , and "enormous" would fix this paragraph.
[MB] I actually did try to tone down the language, but I can se that
another pass would be helpful - I did at least remove all instances of
"nirvana".
> How would you suggest a rephrase of email is useless.... (send over email please)

[MB]  How about something like the following?

However, the email system has now become plagued with spam. This has
resulted in administrators spending a significant amount of time
maintaining spam filters. This does not always benefit the end users
as in some cases valid emails are dropped without the user being
notified.
[/MB]
> I suspect we could just delete this and no one would care.
[MB] There have been several documents related to handover of SIP
calls, including these two:
http://www.cs.columbia.edu/~hgs/papers/Schu0007_Application.pdf
http://www1.cs.columbia.edu/~andreaf/documents/other/pdad/ashutosh-dutta.pdf
There were drafts associated with those papers at one time and I
thought one had been published, but can't find it right off.
The first two papers use the term handoff in the body of the documents.

Here's a GSM focused paper that uses handover:
http://www.cttc.cat/resources/doc/071029-voip-umts-icc07-uploaded-cttc-33566.pdf

The terms are synonymous - handover is used in the GSM specs and
handoff in the CDMA specs.

That all said, I don't see that this applies directly to VIPR, so I
think it can be dropped.
[/MB]
> Call Agent used to be PBX but then it got replaced ....
[MB] From what I could find, there is a certain vendor that uses the
term "call agent" to refer to  SIP User Agents.I don't know that
calling it a VIPR-enabled User Agent is quite correct as the UA does
not necessarily have to be VIPR-enabled to use VIPR.  The call agent
is a more generic term - it could be the UA that is VIPR-enabled or
another entity. I think the problem is an inconsistency. When Call
agent is first used in the 2nd paragraph in 5.3,  it is referring to a
User Agent, however, in section 5.3, it is used to refer to an entity
that can be handling multiple phones/UAs - to me this implies
something like a state-ful SIP Proxy :

   The call agent is connected to one or more phones in the domain, and is
   responsible for routing calls, handling features, and processing call
   state.  The call agent is stateful, and is aware of when calls start
   and stop.

Elsewhere, it also states that the this entity in the first context
(Alice and Bob) can be any sort of endpoint - not just SIP, so you are
correct that we shouldn't call it a SIP UA.  Why don't we just use the
term "User Agent"  when we are referring to the entity that Alice and
Bob use to make calls and leave Call Agent as is elsewhere.    My
understanding is that a Node-ID gets you to a Call Agent which then
can access the mapping to the specific UA.   We can define Call Agent
to be the entity in a domain that handles the mappings, etc.

I think the problem really is that we split the overview document into
two parts - an overview (this doc) and then a framework document.  the
-01 version of the overview document clearly defines Call agent:
6.2.  Call Agent

   The call agent is a box within the domain which performs call
   processing on behalf of one or more phones within the domain.  ViPR
   can work with a wide variety of call agents, as long as they meet
   some specific criteria:

   o  The call agent must be know of the start time, stop time, caller
      ID, and called numbers of calls placed from phones towards the
      PSTN.
   o  The call agent must be capable of making routing decisions for
      outbound calls from phones that would otherwise go to the PSTN,
      directing them towards the PSTN or towards other domains (based on
      ViPR routing rules).

So, I think we might need to revisit how we've split the material or
include some more forward references.

[/MB]
>> Ticket: Section 5.3.3 starts talking about generating tickets, but never defines what a ticket is.  The reader has to read the whole document to figure that one out.
[MB] I think the problem is that when the ticket concept is first
introduced in 5.3.3, it's stated as a "form of shared secret" and it's
not clear that it means the ticket. We can make it clear there and add
a definition to the terminology section.  [/MB]
>> Section 5.3.4 talks about cached routes and 'next call agent in the path.'  However, the document never discusses chains of call agents, multiple routes (except in an aside in the previous paragra…
[MB] There is a note that we need to figure out whether or not we need
to or feel we should allow multiple routes.  If so, we probably need
to add a section somewhere - maybe not here but in framework document
about this functionality. We kindof have a chicken/egg situation
because we're trying to give a run through of the functionality in
this doc, but you really have to read the framework to understand some
of this.  I'm not quite sure of the way around - maybe simplify some
of the text in this section and include a reference to the framework
document. [/MB]
>> Page 24, Acknowledgements: let me in on the joke: I could imagine Theo being a thief of numbers.  Maybe in the fifth Ring [sic].  If he really is, I would suggest saying "5th thief [sic]". Otherwi…
[MB] The problem is that the security section only addresses 4
threats, so I have no idea what that comment means either. [/MB]

---

From: Cullen Jennings <[email-masked]>
Date: Sat, 28 Jan 2012 10:23:07 -0700

> threats, so I have no idea what that comment means either. [/MB]

The attack that Theo pointed out was the one described in last para of 6.2 which reads 

   An attacker could make a call so they know the call details of the
   call they made and use this to forge a validation for that call.
   They could then try to convince other users, which would have to be
   in the same domain as the attacker, to trust this validation.  This
   is mitigated by not sharing validations inside of domains where the
   users that can originate call from that domain are not trusted by the
   domain.

It's a good attack and Theo should get credit for pointing this out.