Re: [dispatch] VIPR - proposed charter version 3

[Christer Holmberg <[e-mail]>]

Hi Mary, 

>"this problem" refers to that stated in the previous 
>paragraph, which is stated fairly clearly.  Would rewording 
>the first sentence in the second paragraph to something like 
>the following make it more clear to you?
> 
>" The VIPR WG will develop a peer to peer based approach to 
>finding domains that claim to be responsible for a given 
>phone number along with validation protocols to ensure a 
>reasonable likelihood that a given domain actually is 
>responsible for the phone number."

The text explains what the WG will do. But, as far as I understand, the claimed PROBLEM is that there are existing mechanisms that for various reasons can't be used.

Also, the charter currently DOES say that the problem statement is described in the drafts. So, I think it should be moved to the charter, so that we can agree on it as part of agreeing the charter.

Regards,

Christer






 
>The intent is not at all that the drafts MUST be adopted in 
>order to agree the problem statement.  The charter should be 
>standalone and as I responded to Keith, we can generalize the 
>deliverables (to match the work items that are described in 
>the body of the charter).  Certainly, having such detailed 
>documents at the outset can be misleading in terms of the 
>intent of the WG, however, as with any documents that might 
>be adopted or used as a starting point for the WG documents, 
>change control belongs to the WG. We have lots of examples of 
>similar situations (within RAI) that have resulted in a 
>significantly different WG document (even as early as a -00) 
>as compared to the individual document that was the starting 
>point for the WG document.
> 
> Thanks,
> Mary.
> 
> 
> On Tue, Jun 29, 2010 at 8:09 AM, Christer Holmberg 
> <[e-mail]> wrote:
> >
> > Hi,
> >
> > The second paragraph says: "The VIPR WG will address this 
> problem..."
> >
> > What problem?
> >
> > The charter does say that the problem statement is 
> described in the referenced drafts. But, shouldn't it be 
> described in the charter? Now it seems that we first have to 
> adopt the drafts in order to agree what the problem is...
> >
> > I also agree with Keith's comment regarding the usage of 
> "shall be based on this and that draft" wording.
> >
> > Regards,
> >
> > Christer
> >
> >
> >
> >
> >> -----Original Message-----
> >> From: [e-mail]
> >> [mailto:[e-mail]] On Behalf Of Mary Barnes
> >> Sent: 28. kesäkuuta 2010 21:00
> >> To: DRAGE, Keith (Keith)
> >> Cc: DISPATCH
> >> Subject: Re: [dispatch] VIPR - proposed charter version 3
> >>
> >> Hi Keith,
> >>
> >> That's a valid concern and we can rewrite the deliverables as 
> >> functional descriptions as we have done for other WG 
> charters even in 
> >> cases where documents existed (e.g., overload).  The 
> current text is 
> >> trying to say that these documents map to deliverables and can be 
> >> used as WG documents, although as it notes these should be 
> considered 
> >> starting points (i.e., it's understood the proposed WG has change 
> >> control), but certainly the current text is somewhat misleading.
> >>
> >> Thanks,
> >> Mary.
> >>
> >> On Mon, Jun 28, 2010 at 12:43 PM, DRAGE, Keith (Keith) 
> >> <[e-mail]> wrote:
> >> > I have a major issue with including "which shall form the
> >> bases of the WG documents" into the charter. To me this is 
> confusing 
> >> the charter discussion with the working group that might 
> eventually 
> >> result deciding what its deliverables, and their contents, 
> shall be.
> >> >
> >> > regards
> >> >
> >> > Keith
> >> >
> >> >> -----Original Message-----
> >> >> From: [e-mail]
> >> >> [mailto:[e-mail]] On Behalf Of Mary Barnes
> >> >> Sent: Monday, June 28, 2010 6:38 PM
> >> >> To: DISPATCH
> >> >> Subject: [dispatch] VIPR - proposed charter version 3
> >> >>
> >> >> Hi all,
> >> >>
> >> >> Below, please find version 3 of the VIPR proposed charter.
> >> >> It's been updated to reflect ML feedback, in particular
> >> VAP has been
> >> >> added and clarifications have been made with regards to impacts 
> >> >> (i.e., none) on existing PSTN interfaces.
> >> >>
> >> >> Regards,
> >> >> Mary
> >> >> (DISPATCH WG co-chair)
> >> >>
> >> >> ============================================
> >> >> VIPR Charter Proposal (Version 3)
> >> >>
> >> >> WG Name:  Verification Involving PSTN Reachability (VIPR)
> >> >>
> >> >> There are two globally deployed address spaces for 
> communications 
> >> >> used by more than a billion people daily - phone 
> numbers and DNS 
> >> >> rooted address such as web servers and email addresses. The 
> >> >> inter-domain signaling design of SIP is primarily designed
> >> for email
> >> >> style addresses yet a large percentage of SIP deployments
> >> mostly use
> >> >> phone numbers for identifying users. The goal of this
> >> working group
> >> >> is to enable inter-domain communications over the the
> >> Internet, using
> >> >> protocols such as SIP, while still allowing people to use phone 
> >> >> numbers to identify the person with whom they wish to 
> communicate.
> >> >>
> >> >> The VIPR WG will address this problem by developing a 
> peer to peer 
> >> >> based approach to finding domains that claim to be
> >> responsible for a
> >> >> given phone number and validation protocols to ensure a 
> reasonable 
> >> >> likelihood that a given domain actually is responsible for
> >> the phone
> >> >> number. In this context, "responsible" means an administrative 
> >> >> domain, which is at least one of the domains, to which a
> >> PSTN call to
> >> >> this phone number would be routed. Once the domain 
> responsible for 
> >> >> the phone number is found, existing protocols, such as 
> SIP, can be 
> >> >> used for inter-domain communications.
> >> >>
> >> >> Some validation protocols may be based on knowledge
> >> gathered around a
> >> >> PSTN call; for example, the ability to prove a call was
> >> received over
> >> >> the PSTN based on start and stop times.
> >> >> Other validation schemes, such as examining fingerprints or 
> >> >> watermarking of PSTN media to show that a domain received a 
> >> >> particular PSTN phone call, may also be considered by 
> the working 
> >> >> group. This validation will be accomplished using publicly
> >> available
> >> >> open interfaces to the PSTN, so the validation can be 
> performed by 
> >> >> any domain wishing to participate.  The WG will select and 
> >> >> standardize at least one validation scheme.
> >> >>
> >> >> The validation mechanism requires a domain to gather 
> and maintain 
> >> >> information related to PSTN calls.  This information is
> >> used by call
> >> >> agents such as phones, SBCs and IP PBXs to route calls.
> > The WG will
> >> >> define a client-server protocol between these call 
> agents and the 
> >> >> entity within a domain that maintains the information.
> >> >>
> >> >> To help mitigate SPAM issues when using SIP between
> >> domains, the WG
> >> >> will define a mechanism to enable one domain to check that
> >> incoming
> >> >> SIP messages are coming from a validated phone number.  A phone 
> >> >> number is considered validated if it is coming from a
> >> domain to which
> >> >> the calling domain had previously successfully placed a
> >> PSTN call.
> >> >> The working group will define new SIP headers and 
> option tags, as 
> >> >> necessary, to enable this.
> >> >>
> >> >> The essential characteristic of VIPR is establishing
> >> authentication
> >> >> by PSTN reachability when it is not possible to use a direct 
> >> >> reference to ENUM databases or other direct assertions of
> >> PSTN number
> >> >> ownership. Elements such as public ENUM easily coexist
> >> with VIPR but
> >> >> no direct interaction with ENUM will be required.  The
> >> solution set
> >> >> defined by this WG will be incrementally deployable using only 
> >> >> existing interfaces to the PSTN.  No changes will be 
> required to 
> >> >> existing PSTN capabilities, no new database access is
> >> needed nor is
> >> >> any new support from PSTN service providers required.
> >> >>
> >> >> The problem statement and some possible starting points
> >> for solutions
> >> >> are further discussed in the following internet drafts 
> which shall 
> >> >> form the bases of the WG documents:
> >> >>
> >> >> draft-rosenberg-dispatch-vipr-overview
> >> >> draft-rosenberg-dispatch-vipr-reload-usage
> >> >> draft-rosenberg-dispatch-vipr-pvp
> >> >> draft-rosenberg-dispatch-vipr-sip-antispam
> >> >> draft-rosenberg-dispatch-vipr-vap
> >> >>
> >> >> The working group will carefully coordinate with the
> >> security area,
> >> >> O&M area, as well as the appropriate RAI WGs such as 
> sipcore and 
> >> >> p2psip.
> >> >> _______________________________________________
> >> >> dispatch mailing list
> >> >> [e-mail]
> >> >> https://www.ietf.org/mailman/listinfo/dispatch
> >> >>
> >> _______________________________________________
> >> dispatch mailing list
> >> [e-mail]
> >> https://www.ietf.org/mailman/listinfo/dispatch
> >>
>