- sg16-avd - lists.packetizer.com

APC-1699
by Archana Nehru 11 Oct '99

11 Oct '99

Hi all, I have uploaded the APC-1699 into the incoming directory. Please note that the APC-1699_final.doc is the correct version of the document. The APC-1699.doc present in the directory is corrupted and needs to be removed. Thanks Archana ________________________________________________________________________ Archana Nehru : Trillium Digital Systems, Inc E-mail: archie(a)trillium.com : Los Angeles, California Phone: +1 310 442 9222 ________________________________________________________________________

1 0

APC-1699
by Archana Nehru 11 Oct '99

11 Oct '99

Please find enclosed the APC-1699 for submission to the Red bank meeting. Somehow the security server is not allowing me to upload the file in the incoming directory. Thanks Archana ________________________________________________________________________ Archana Nehru : Trillium Digital Systems, Inc E-mail: archie(a)trillium.com : Los Angeles, California Phone: +1 310 442 9222 ________________________________________________________________________

1 0

[Fwd: The IETF's position on technology to support legal intercept]
by Christian Groves 11 Oct '99

11 Oct '99

G'Day all, This may be of some interest. Cheers, Christian -------- Original Message -------- Subject: The IETF's position on technology to support legal intercept Date: Mon, 11 Oct 1999 15:47:10 -0400 From: The IESG <iesg-secretary(a)ietf.org> Reply-To: raven(a)ietf.org To: IETF-Announce: ; CC: raven(a)ietf.org The use of the Internet for services that replace or supplement traditional telephony is, predictably, causing discussions in many countries about the point at which special rules about telephony services begin to apply to Internet service providers. In many countries, these rules could impose new legal obligations on ISPs, particularly requirements to comply with requests from law enforcement agencies or regulators to intercept, or gather and report other information about, communications. For example many traditional telephony devices, especially central-office switches, sold in those countries are required to have built-in wiretapping capabilities to allow telephone carriers to fulfill these obligations. A number of IETF working groups are currently working on protocols to support telephony over IP networks. The wiretap question has come up in one of these working groups, but the IESG has concluded that the general questions should be discussed, and conclusions reached, by the entire IETF, not just one WG. The key questions are: "should the IETF develop new protocols or modify existing protocols to support mechanisms whose primary purpose is to support wiretapping or other law enforcement activities" and "what should the IETF's position be on informational documents that explain how to perform message or data-stream interception without protocol modifications". We would like to encourage discussion of these questions on the new raven(a)ietf.org mailing list. Subscription requests should be mailed to raven-request(a)ietf.org OR subscribe via the web at http://www.ietf.org/mailman/listinfo/raven Time will be allocated at the Plenary session at the November IETF to discuss this orally and try to draw a consensus together. (PLEASE DISCUSS THIS ON THE NEW MAILING LIST AND NOT ON THE GENERAL IETF LIST) In addition to the general questions identified above, we believe it would be helpful for mailing list comments to address the following more specific questions: Adding wiretap capability is by definition adding a security hole. Considering the IETF's commitment to secure protocols, is it a reasonable thing to open such a hole to meet these requirements? Should the IETF as an international standards organization shape its protocols to support country-specific legal requirements? If the companies who employ the IETF participants and deploy the IETF's technology feel that having wiretap capability is a business necessity due to the regulatory requirements in the countries where they want to sell their products, would that make a difference to the IETF position on this subject? What is the appropriateness or feasibility of standardizing mechanisms to conform to requirements that may change several times over the life cycle of equipment built to conform to those standards? When IPv6 was under development, the IETF decided to mandate an encryption capability for all devices that claim to adhere to those standards. This was done in spite of the fact that, at the time the decision was made, devices meeting the IPv6 standard could not then be exported from the U.S. nor could they be used in some countries. Is that a precedent for what to do in this case? Could the IETF just avoid specifying the part of the technology that supports wiretapping, presumably assuming that some industry consortium or other standards organization would do so? Would letting that responsibility fall to others weaken the IETF's control over its own standards and traditional areas? If these functions must be done, is it better for the IETF to do them so that we can ensure they are done in the most secure way and, where permitted by the regulations, to ensure a reliable audit capability? What would the image of the IETF be if we were to refuse to standardize any technology that supported wiretapping? In the Internet community? In the business community? To the national regulatory authorities? The goal of the mailing list and then plenary session is to address the broad policy and direction issue and not specific technical issues such as where exactly in an architecture it would be best to implement wiretapping if one needed to do so. Nor are they to address what specific functions might be needed to implement wiretapping under which countries' laws. The intent is basically to discuss the question of what stance the IETF should take on the general issue.

1 0

Re: H.323v3 Final Text Posted
by Boaz Michaely 11 Oct '99

11 Oct '99

Hi Paul, It is not there now. Has it been moved elsewhere ? Boaz "Paul E. Jones" <paul.jones(a)TIES.ITU.INT> on 10/03/99 04:21:08 PM Please respond to Mailing list for parties associated with ITU-T Study Group 16 <ITU-SG16(a)mailbag.cps.intel.com> To: ITU-SG16(a)mailbag.cps.intel.com cc: (bcc: Boaz Michaely) Subject: H.323v3 Final Text Posted Folks, I posted the final text of H.323v3 here: ftp://standard.pictel.com/avc-site/Incoming/H323v3.zip This document should represent the combination of the white paper contribution, D.314, and two temporary documents submitted at the meeting to make corrections discussed and approved during the Berlin meeting. Please keep in mind that this is not the final text published by the ITU, so it has no official standing. There may still be strictly editorial corrections that may be applied before the final publication of this document. If you see such errors, please forward them to me. If you find technical errors, please notify me of that, as well, so that we can take steps to correct the problem. Best Regards, Paul

3 2

H.243 white doc uplopaded
by Patrick Luthi 11 Oct '99

11 Oct '99

Dear experts, The H.243 white document was uploaded to the Redbank directory of the Q11 FTP site (ftp://standard.pictel.com/lbc-site/1999_10_Redbank/). The file name is q11k04.zip. See you in Red Bank ! Patrick Luthi PictureTel

1 0

Re: submitting APC-1692
by Qiaobing Xie 11 Oct '99

11 Oct '99

Thanks, Chip! -Qiaobing On Oct 11, 4:41pm, Chip Sharp wrote: > Subject: Re: submitting APC-1692 > I've uploaded APC-1692 into the avc-site/incoming directory for Qiaobing. > > Chip > > At 12:08 PM 10/11/99 -0500, Qiaobing Xie wrote: > >Please find in the attached .zip file our APC-1692 submission to > >the Red Bank meeting. I have difficulty to directly upload the > >file into the ftp directory due to our company security control. > > > >Thanks, > > > >=============================================================== > > Qiaobing Xie, Ph.D > > Network Architecture & Technology > > Motorola, Inc. > > 1501 W. Shure Dr., Arlington Heights, IL 60004 > >=============================================================== > > > > > > > >X-Zm-Content-Name: APC-1692.zip > >Content-Description: Data > >Content-Type: application/octet-stream ; name="APC-1692.zip" > >X-Zm-Decoding-Hint: mimencode -b -u > > Support NetAid! http://www.netaid.org > -------------------------------------------------- > Chip Sharp Consulting Engineering > Cisco Systems Telco Bio-region > Reality - Love it or Leave it. > -------------------------------------------------- >-- End of excerpt from Chip Sharp

1 0

submitting APC-1692
by Qiaobing Xie 11 Oct '99

11 Oct '99

Please find in the attached .zip file our APC-1692 submission to the Red Bank meeting. I have difficulty to directly upload the file into the ftp directory due to our company security control. Thanks, =============================================================== Qiaobing Xie, Ph.D Network Architecture & Technology Motorola, Inc. 1501 W. Shure Dr., Arlington Heights, IL 60004 ===============================================================

2 1

APC-1735 (draft H.248)
by John Segers 11 Oct '99

11 Oct '99

Dear SG16 experts, The draft text for H.248 is availabe at <ftp://standards.nortelnetworks.com/megaco/docs/latest/MegacoH248v11.pdf >. From this document I will create APC-1735, showing the changes that were made, and upload that as soon as possible. With apologies for not meeting the deadline with APC-1735. Regards, John Segers -- John Segers email: jsegers(a)lucent.com Lucent Technologies Room HE 344 Dept. Forward Looking Work phone: +31 35 687 4724 P.O. Box 18, 1270 AA Huizen fax: +31 35 687 5954

1 0

Re: APC-1735 (draft H.248)
by Nancy-M Greene 11 Oct '99

11 Oct '99

Please note that the pdf file pointed to below does NOT have the ITU text in it, as it had the IETF text macro on when I created it - you will see the ITU text in APC-1735 though. At least two places where this is an issue is the scope, and the last paragraphs in Annex G. There are probably more places. Nancy -------------------------------------------------------------------------- Nancy M. Greene Internet & Service Provider Networks, Nortel Networks T:514-271-7221 (internal:ESN853-1077) E:ngreene@nortelnetworks.com > ---------- > From: John Segers[SMTP:jsegers@LUCENT.COM] > Sent: Monday, October 11, 1999 4:15 PM > To: ITU-SG16(a)MAILBAG.INTEL.COM > Subject: APC-1735 (draft H.248) > > Dear SG16 experts, > > The draft text for H.248 is availabe at > <ftp://standards.nortelnetworks.com/megaco/docs/latest/MegacoH248v11.pdf > >. From this document I will create APC-1735, showing the changes that > were made, and upload that as soon as possible. > > With apologies for not meeting the deadline with APC-1735. > > Regards, > > John Segers > -- > John Segers email: jsegers(a)lucent.com > Lucent Technologies Room HE 344 > Dept. Forward Looking Work phone: +31 35 687 4724 > P.O. Box 18, 1270 AA Huizen fax: +31 35 687 5954 >

1 0

Uploaded apc-1653
by Tony Crossman 11 Oct '99

11 Oct '99

Dear colleagues, I have uploaded the proposal to include G.722.1 capabilities in the H.323 Implementors Guide. The contribution can be found at the following location: ftp://standard.pictel.com/avc-site/Incoming/APC1653.zip Tony Crossman ********************************************* Antony Crossman PictureTel Corporation 100 Minuteman Road, Andover, MA 01810, USA Tel. +1 (978) 292 4557 Fax. +1 (978) 292 3228 email. tonyc(a)pictel.com *********************************************

1 0