Re: [VIPR] Review of VIPR Overview

Eric, thanks for the review.

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

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

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
> =========================
> 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.
+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 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."

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

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

> 
> 
> NITS
> ====
> 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 language in specification documents.
+1

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

> 
> 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.
> 
> _______________________________________________
> VIPR mailing list
> VIPR@ietf.org
> https://www.ietf.org/mailman/listinfo/vipr