Re: [dispatch] VIPR - proposed charter version 3

Agreed - I will make that change in the version 4 of the charter.

Thanks,
Mary.

2010/6/30 Romascanu, Dan (Dan) <dromasca(_at_)avaya(_dot_)com>:
> Hi Mary,
>
> I also think that listing the deliverables should be independent from 
> mentioning the existing initial contributions. The existing contributions 
> could be listed as well, but they should not preclude other contributions on 
> the same items after the WG is formed.
>
> Regards,
>
> Dan
>
>
> > -----Original Message-----
> > From: dispatch-bounces(_at_)ietf(_dot_)org
> > [mailto:dispatch-bounces(_at_)ietf(_dot_)org] On Behalf Of Mary Barnes
> > Sent: Monday, June 28, 2010 9:00 PM
> > 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)
> > <keith(_dot_)drage(_at_)alcatel-lucent(_dot_)com> 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: dispatch-bounces(_at_)ietf(_dot_)org
> > > > [mailto:dispatch-bounces(_at_)ietf(_dot_)org] 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
> > > > dispatch(_at_)ietf(_dot_)org
> > > > https://www.ietf.org/mailman/listinfo/dispatch
> > _______________________________________________
> > dispatch mailing list
> > dispatch(_at_)ietf(_dot_)org
> > https://www.ietf.org/mailman/listinfo/dispatch
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf