Agreed - I will make that change in the version 4 of the charter. Thanks, Mary.
2010/6/30 Romascanu, Dan (Dan) <[email protected]>: > 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: [email protected] >> [mailto:[email protected]] 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) >> <[email protected]> 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: [email protected] >> >> [mailto:[email protected]] 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 >> >> [email protected] >> >> https://www.ietf.org/mailman/listinfo/dispatch >> >> >> _______________________________________________ >> dispatch mailing list >> [email protected] >> https://www.ietf.org/mailman/listinfo/dispatch >> > _______________________________________________ Ietf mailing list [email protected] https://www.ietf.org/mailman/listinfo/ietf
