From nfs4-wg-request@sunroof.eng.sun.com Sat Sep 1 10:53:40 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA15268 for ; Sat, 1 Sep 2001 10:53:40 -0400 (EDT) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id HAA11332; Sat, 1 Sep 2001 07:55:01 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA26207; Sat, 1 Sep 2001 07:54:34 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0) with ESMTP id f81EsA40013760 for ; Sat, 1 Sep 2001 07:54:10 -0700 (PDT) Received: from venus.sun.com (venus.EBay.Sun.COM [129.150.69.5]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA04569 for ; Sat, 1 Sep 2001 07:54:20 -0700 (PDT) Received: from ztvsmtp2.ztv.ne.jp (ztvsmtp2.ztv.ne.jp [210.236.160.102]) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA23644 for ; Sat, 1 Sep 2001 07:54:20 -0700 (PDT) Received: from mc5.law13.hotmail.com (dhcp180-031.ztv.ne.jp [210.236.180.32]) by ztvsmtp2.ztv.ne.jp (8.11.1/3.7W) with SMTP id f81EeBg00068; Sat, 1 Sep 2001 23:40:11 +0900 (JST) Date: Sat, 1 Sep 2001 23:40:11 +0900 (JST) Reply-To: From: "flrt1928@hotmail.com" To: "5850@aol.com" <5850@aol.com> Message-ID: <0999355531.0459305785@mc5.law13.hotmail.com> Subject: Photographic proof of 130 year old woman! MIME-Version: 1.0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable From <=21DOCTYPE HTML PUBLIC =22-//W3C//DTD HTML 4.0 Transitional//EN=22>

 

<= SPAN class=3D620293501-26072001>IF YOU WANT TO LIVE LONG AND HEALTHY

See actual photos of healthy people= over the age of 100=21

You Can Smoke and consume high leve= ls of sodium in your diet and live to be 120 Years Old.

For less than you spend on a = soda a day you Can Eliminate 98% of the reason why the body ages of natural causes.

Now You Can Stop Eating Vegetables=21=21=21  Most Vegetables and Fruit that you Purchase At= The Supermarket have no Nutritional Value

You Can Guard against ca= ncer, diabetes, fatigue, even depression=21=21=21

Actual photogra= phs from a 1973 National Geographic January issue for you non-believers=21=21

IF you are interested= in more info. Click on NEXT

 

This E-mailing has been sent to you as a person = interested in the information enclosed.  <= FONT color=3Dblack size=3D1>If this reached you by error, or you do not wish= to receive this information or type of information in the future,  pleas= e click on the words NO MORE INFO, type the words =22no more info=22, in the subject box,  then send,  and you will b= e taken off our list immediately.<= FONT color=3Dblack size=3D1>  This E-mail is not SPAM under the = Federal Regulatory laws of the United States. This message is being sent to y= ou in compliance with the proposed Federal Legislation for commercial e-mai= l (H.R.4176-SECTION 101 PARAGRAPH (e) (1) (A)) and Bill s.1618 TITLE II= I passed by the 105th US Congress.  We sincerely apologize for any inconvenience.<= FONT color=3Dblack size=3D1> T= his message is not intended for residents of WA, NV, CA, & VA. = Screening of address's has been done to the best of our technical ability. If y= ou are a California, Nevada, Washington, or Virginia resident please follow th= e instructions above and you will be permanently removed from our list = immediately.
  =

********** From nfs4-wg-request@sunroof.eng.sun.com Sat Sep 1 15:46:09 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA17352 for ; Sat, 1 Sep 2001 15:46:08 -0400 (EDT) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id MAA06546; Sat, 1 Sep 2001 12:47:29 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA13792; Sat, 1 Sep 2001 12:47:10 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0) with ESMTP id f81Jkf40014122 for ; Sat, 1 Sep 2001 12:46:41 -0700 (PDT) Received: from venus.sun.com (venus.EBay.Sun.COM [129.150.69.5]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA23892 for ; Sat, 1 Sep 2001 12:46:52 -0700 (PDT) Received: from web13704.mail.yahoo.com (web13704.mail.yahoo.com [216.136.175.137]) by venus.sun.com (8.9.3+Sun/8.9.3) with SMTP id MAA23719 for ; Sat, 1 Sep 2001 12:46:52 -0700 (PDT) Message-ID: <20010901194651.64384.qmail@web13704.mail.yahoo.com> Received: from [210.214.18.9] by web13704.mail.yahoo.com via HTTP; Sat, 01 Sep 2001 12:46:51 PDT Date: Sat, 1 Sep 2001 12:46:51 -0700 (PDT) From: deepu thomas Subject: Not getting all the tracks To: nfsv4-wg@sunroof.eng.sun.com MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Hai All.. I'm a new user of NFS speed high stakes... I bought a CD recently which shows me the list of 18 tracks.. But i'm not being able to use more than seven or eight.. What do i have to do to get all 18 tracks... Please help... I am a bifg fan of NFS and i'm happy to know that it has such a big fan club Thanx and regards Deepu __________________________________________________ Do You Yahoo!? Get email alerts & NEW webcam video instant messaging with Yahoo! Messenger http://im.yahoo.com From nfs4-wg-request@sunroof.eng.sun.com Sat Sep 1 21:18:16 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA19415 for ; Sat, 1 Sep 2001 21:18:15 -0400 (EDT) Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id SAA02937; Sat, 1 Sep 2001 18:19:36 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id SAA07327; Sat, 1 Sep 2001 18:18:13 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0) with ESMTP id f821Hj40014328 for ; Sat, 1 Sep 2001 18:17:45 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id SAA13265 for ; Sat, 1 Sep 2001 18:17:57 -0700 (PDT) From: adv1@market.gogocity.com Received: from market3 ([208.146.216.253]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id TAA18164 for ; Sat, 1 Sep 2001 19:18:26 -0600 (MDT) Received: from mail pickup service by market3 with Microsoft SMTPSVC; Sat, 1 Sep 2001 18:15:45 -0700 To: Subject: Cell Phone Accessories Blow Out Start @ $5.95 Free Shipping Date: Sat, 1 Sep 2001 18:15:45 -0700 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_4F04C4_01C13312.1E63F620" X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Message-ID: X-OriginalArrivalTime: 02 Sep 2001 01:15:45.0919 (UTC) FILETIME=[CAFCF0F0:01C1334C] This is a multi-part message in MIME format. ------=_NextPart_000_4F04C4_01C13312.1E63F620 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Big Saving from GoGoCity. If you'd rather not receive any future promotional E-mails from GoGoCity.com, please click --> Un-Subscribe My E-mai l International Order Welcome FREE SHIPPING NOT APPLY Cell Phone Accessories Blow out Sale...!! Save Up to 80%...!! ***** FREE SHIPPING (in US only) ***** Why pay more in Retail Store..??? 1. Antenna Booster for All Cell Phone (1pack) 9. Antenna Booster for All Cell Phone (5 pack) Antenna Booster for All Cell Phone (1pack) large image Retail Price: $19.95 Blow Out Price: $5.95 (save 75%) More Details... Buy it NOW !! Free Shipping Antenna Booster for All Cell Phone (5 pack) large image Retail Price: $99.75 Blow Out Price: $19.95 (save 80%) More Details... Buy it NOW !! Free Shipping 2. NOKIA 51xx/6xx Black Car Charger 10. Nokia 3310/3390 Data Cable NOKIA 51xx/6xx Black Car Charger large image Retail Price: $19.99 Blow Out Price: $5.49 (save 73%) More Details... Buy it NOW !! Free Shipping Nokia 82xx/33xx Data Cable large image Retail Price: $79.99 Blow Out Price: $19.95 (save 75%) More Details... Buy it NOW !! Free Shipping 3. NOKIA 82xx/33xx Black Car Charger 11. Nokia 8260/8290 Li-ion 1200mAh 12 Lights Flashing & Vib Battery NOKIA 82xx/33xx Black Car Charger large image Retail Price: $19.99 Blow Out Price: $5.49 (save 73%) More Details... Buy it NOW !! Free Shipping Nokia 82xx/33xx Li-ion 1200mAh 12 Lights Flashing & Vib Battery large image Retail Price: $65.99 Blow Out Price: $24.95 (save 62%) More Details... Buy it NOW !! Free Shipping 4. NOKIA 51xx/61xx Hands Free with on/off Switch 12. NOKIA 51xx/6xx Data Cable NOKIA 51xx/61xx Hands Free with on/off Switch large image Retail Price: $19.99 Blow Out Price: $5.99 (save 70%) More Details... Buy it NOW !! Free Shipping NOKIA 51xx/6xx Data Cable large image Retail Price: $69.99 Blow Out Price: $14.95 (save 79%) More Details... Buy it NOW !! Free Shipping 5. NOKIA 82xx/33xx Hands Free with on/off Switch 13. Nokia 8260/8290 Li-ion 1200mAh Vibrating Battery NOKIA 82xx/33xx Hands Free with on/off Switch large image Retail Price: $19.99 Blow Out Price: $5.99 (save 70%) More Details... Buy it NOW !! Free Shipping Nokia 82xx/33xx Li-ion 1200mAh Vibrating Battery large image Retail Price: $45.99 Blow Out Price: $24.95 (save 46%) More Details... Buy it NOW !! Free Shipping 6. NOKIA 51xx/6xx Li-ion 3200mAh Vibrating Battery 14.Nokia 51xx/6xx Super Slim Black Li-ion 1200mAh Vib Battery NOKIA 51xx/6xx Li-ion 3200mAh Vibrating Battery large image Retail Price: $79.99 Blow Out Price: $34.95 (save 56%) More Details... Buy it NOW !! Free Shipping Nokia 51xx/6xx Super Slim Black Li-ion 1200mAh Vib Battery large image Retail Price: $70.99 Blow Out Price: $29.95 (save 58%) More Details... Buy it NOW !! Free Shipping 7. NOKIA 51xx/6xx Black NIMH-700mAh Vibrating Battery 15. Nokia 3310/3390 Vertical Leather Magnetic Button Pouch NOKIA 51xx/6xx Black NIMH-700mAh Vibrating Battery large image Retail Price: $45.99 Blow Out Price: $14.95 (save 67%) More Details... Buy it NOW !! Free Shipping Nokia 82xx/33xx Vertical Leather Magnetic Button Pouch large image Retail Price: $24.99 Blow Out Price: $9.95 (save 60%) More Details... Buy it NOW !! Free Shipping 8. Nokia 8260/8290 Data Cable 16. Nokia 8260/8290 Vertical Leather Magnetic Button Pouch NOKIA 51xx/6xx Data Cable large image Retail Price: $79.99 Blow Out Price: $19.95 (save 75%) More Details... Buy it NOW !! Free Shipping Nokia 82xx/33xx Vertical Leather Magnetic Button Pouch large image Retail Price: $24.99 Blow Out Price: $9.95 (save 60%) More Details... Buy it NOW !! Free Shipping ------=_NextPart_000_4F04C4_01C13312.1E63F620 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
=20


Big Saving = from GoGoCity.=20 If you'd rather not receive any future promotional E-mails from = GoGoCity.com,=20
please click --> Un-Subscribe=20 My E-mail
International=20 Order Welcome=20 FREE SHIPPING NOT APPLY

=20
=20
Cell=20 Phone Accessories
Blow out Sale...!!
Save Up to 80%...!!
***** FREE=20 SHIPPING (in=20 US only) *****
Why pay more in = Retail Store..???

=20 =20 =20 =20 =20 =20 =20 =20 =20 =20 =20 =20 =20 =20 =20 =20
1.=20 Antenna Booster for All Cell Phone = (1pack) 9.=20 Antenna Booster for All Cell Phone (5 = pack)
=20 Retail=20 Price: $19.95
Blow Out Price: $5.95 = (save 75%)
More=20 Details...
Buy it = NOW !!=20 Free=20 Shipping
=20 Retail=20 Price: $99.75
Blow Out Price: $19.95 (save = 80%)
More=20 Details...
Buy it = NOW !!=20 Free=20 Shipping
2.=20 NOKIA=20 51xx/6xx Black Car Charger 10.=20 Nokia 3310/3390 Data Cable
=20 Retail=20 Price: $19.99
Blow Out Price: $5.49 (save = 73%)
More=20 Details...
Buy it = NOW !!=20 Free=20 Shipping
 =20 Retail=20 Price: $79.99
Blow Out Price: $19.95 (save = 75%)
More=20 Details...
Buy it = NOW !!=20 Free=20 Shipping
3.=20 NOKIA=20 82xx/33xx Black Car Charger
 11.=20 Nokia 8260/8290 Li-ion 1200mAh 12=20 Lights Flashing=20 & Vib Battery
=20 Retail=20 Price: $19.99
Blow Out Price: $5.49 (save = 73%)
More=20 Details...
Buy it = NOW !!=20 Free=20 Shipping
 =20 Retail=20 Price: $65.99
Blow Out Price: $24.95 (save = 62%)
More=20 Details...
Buy it = NOW !!=20 Free=20 Shipping
4.=20 NOKIA=20 51xx/61xx Hands Free with on/off = Switch 12.=20 NOKIA=20 51xx/6xx Data Cable
=20 Retail=20 Price: $19.99
Blow Out Price: $5.99 (save = 70%)
More=20 Details...
Buy it = NOW !!=20 Free=20 Shipping
 =20 Retail=20 Price: $69.99
Blow Out Price: $14.95 (save = 79%)
More=20 Details...
Buy it = NOW !!=20 Free=20 Shipping
5.=20 NOKIA=20 82xx/33xx Hands Free with on/off = Switch 13.=20 Nokia 8260/8290 Li-ion 1200mAh Vibrating = Battery
=20 Retail=20 Price: $19.99
Blow Out Price: $5.99 (save = 70%)
More=20 Details...
Buy it = NOW !!=20 Free=20 Shipping
 =20 Retail=20 Price: $45.99
Blow Out Price: $24.95 (save = 46%)
More=20 Details...
Buy it = NOW !!=20 Free=20 Shipping
6.=20 NOKIA=20 51xx/6xx Li-ion 3200mAh Vibrating = Battery 14.Nokia=20 51xx/6xx Super Slim Black Li-ion 1200mAh Vib = Battery
=20 Retail=20 Price: $79.99
Blow Out Price: $34.95 (save = 56%)
More=20 Details...
Buy it = NOW !!=20 Free=20 Shipping
 =20 Retail=20 Price: $70.99
Blow Out Price: $29.95 (save = 58%)
More=20 Details...
Buy it = NOW !!=20 Free=20 Shipping
7.=20 NOKIA=20 51xx/6xx Black NIMH-700mAh Vibrating = Battery 15.=20 Nokia 3310/3390 Vertical Leather Magnetic Button = Pouch
=20 Retail=20 Price: $45.99
Blow Out Price: $14.95 (save = 67%)
More=20 Details...
Buy it = NOW !!=20 Free=20 Shipping
 =20 Retail=20 Price: $24.99
Blow Out Price: $9.95 (save = 60%)
More=20 Details...
Buy it = NOW !!=20 Free=20 Shipping
8.=20 Nokia 8260/8290 Data Cable 16.=20 Nokia 8260/8290 Vertical Leather Magnetic Button = Pouch
=20 Retail=20 Price: $79.99
Blow Out Price: $19.95 (save = 75%)
More=20 Details...
Buy it = NOW !!=20 Free=20 Shipping		 =20 Retail=20 Price: $24.99
Blow Out Price: $9.95 (save = 60%)
More=20 Details...
Buy it = NOW !!=20 Free=20 Shipping
------=_NextPart_000_4F04C4_01C13312.1E63F620-- From nfs4-wg-request@sunroof.eng.sun.com Sun Sep 2 18:49:56 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA14542 for ; Sun, 2 Sep 2001 18:49:56 -0400 (EDT) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id PAA00808; Sun, 2 Sep 2001 15:51:20 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id PAA28922; Sun, 2 Sep 2001 15:50:50 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0) with ESMTP id f82MoT40015035 for ; Sun, 2 Sep 2001 15:50:29 -0700 (PDT) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id PAA09728 for ; Sun, 2 Sep 2001 15:50:40 -0700 (PDT) Received: from citi.umich.edu (citi.umich.edu [141.211.92.141]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA04285 for ; Sun, 2 Sep 2001 15:50:40 -0700 (PDT) Received: from citi.umich.edu (unknown [24.131.241.169]) by citi.umich.edu (Postfix) with ESMTP id B6417207C1 for ; Sun, 2 Sep 2001 18:50:39 -0400 (EDT) Subject: Re: Delegation callbacks proposal To: nfsv4-wg@sunroof.eng.sun.com From: Jim Rees In-Reply-To: Mike Eisler, Fri, 31 Aug 2001 17:35:58 PDT Date: Sun, 02 Sep 2001 18:50:36 -0400 Sender: rees@citi.umich.edu Message-Id: <20010902225039.B6417207C1@citi.umich.edu> So, the implication of requiring bi-directional RPC is no NFSv4/UDP, or at least, no NFSv4/UDP that uses stateid or seqid generating RPCs. I tried to bring this subject up in Santa Clara last year but was told the same thing. To which I will now make the same response. AFS works through NATs, and I believe it does so by using bi-directional rpc. So we have an existence proof that this is possible. I see no reason why a client must use different source ports on successive RPCs to the same server. As for clients requiring a pool of udp ports, only one need be bi-directional. I hate NAT as much as the next guy, but I don't think we should make it impossible for the protocol to work through a NAT. How about we leave the clientid in there, but allow the client some way to specify that the server should send callbacks back to the source rather than to the given clientid? That way it would be possible to build a client that works through a NAT, but clients that don't want to work through a NAT don't have to. From nfs4-wg-request@sunroof.eng.sun.com Sun Sep 2 19:26:19 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA14785 for ; Sun, 2 Sep 2001 19:26:18 -0400 (EDT) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id QAA04956; Sun, 2 Sep 2001 16:27:42 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id QAA00789; Sun, 2 Sep 2001 16:27:25 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0) with ESMTP id f82NR340015077 for ; Sun, 2 Sep 2001 16:27:03 -0700 (PDT) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id QAA00779 for ; Sun, 2 Sep 2001 16:27:15 -0700 (PDT) Received: from h0000f8054d01.ne.mediaone.net (h0000f8054d01.ne.mediaone.net [24.168.185.9]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id QAA14488 for ; Sun, 2 Sep 2001 16:27:14 -0700 (PDT) Received: from h0000f8054d01.ne.mediaone.net (IDENT:werme@localhost [127.0.0.1]) by h0000f8054d01.ne.mediaone.net (8.9.3/8.9.3) with ESMTP id TAA01032; Sun, 2 Sep 2001 19:20:32 -0400 Message-Id: <200109022320.TAA01032@h0000f8054d01.ne.mediaone.net> X-Mailer: exmh version 2.1.1 10/15/1999 From: Ric Werme To: Jim Rees , nfsv4-wg@sunroof.eng.sun.com Subject: Re: Delegation callbacks proposal In-Reply-To: Your message of "Sun, 02 Sep 2001 18:50:36 EDT." <20010902225039.B6417207C1@citi.umich.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sun, 02 Sep 2001 19:20:31 -0400 Jim notes: > I tried to bring this subject up in Santa Clara last year but was told the > same thing. To which I will now make the same response. AFS works through > NATs, and I believe it does so by using bi-directional rpc. So we have an > existence proof that this is possible. I see no reason why a client must > use different source ports on successive RPCs to the same server. You will be pleased to hear that there is an existance proof in NFS space re. a single port. As Tru64 systems scaled, we ran into more and more occasions when the system ran out of privileged port numbers because NFS and "lesser" protocols had the entire name space tied up. (Doing Email over NFS and sendmail's .forward checks over NFS can be interesting when certain systems are down.) Since we already shared a TCP connection among all users of a NFS mount, it seemed to me that was proof enough to be sure we could do it with UDP too. So we now use a single port for all NFS client calls and the admin folks hardly pester me at all anymore. Instead of multiplexing on ports 512-1023, we now multiplex on the XID, so that's 23 bits of room to go before we have to bind XID counters to each server. :-) -Ric Werme -- werme@mediaone.net | http://people.ne.mediaone.net/werme From nfs4-wg-request@sunroof.eng.sun.com Mon Sep 3 03:25:13 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA05218 for ; Mon, 3 Sep 2001 03:25:12 -0400 (EDT) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id BAA01073; Mon, 3 Sep 2001 01:26:31 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id AAA11483; Mon, 3 Sep 2001 00:25:58 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0) with ESMTP id f837Pb40015342 for ; Mon, 3 Sep 2001 00:25:38 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id AAA03973 for ; Mon, 3 Sep 2001 00:25:49 -0700 (PDT) Received: from webmanager.osde.com.ar ([200.32.93.6]) by patan.sun.com (8.9.3+Sun/8.9.3) with SMTP id BAA00417 for ; Mon, 3 Sep 2001 01:25:44 -0600 (MDT) Received: from webmanager.osde.com.ar ([10.10.19.1]) by servmail.osde.com.ar (Lotus Domino Release 5.0.5) with SMTP id 2001090304210547:57914 ; Mon, 3 Sep 2001 04:21:05 -0300 From: "Gregory Salutue" Subject: Never Before Seen #21C3 To: rtrt@patan.sun.com X-Mailer: Microsoft Outlook Express 4.72.1712.3 X-MimeOLE: Produced By Microsoft MimeOLE VÐßD.1712.3 Mime-Version: 1.0 Date: Mon, 03 Sep 2001 00:32:04 -0500 X-MIMETrack: Itemize by SMTP Server on OSDE-Central-2/OSDE(Release 5.0.5 |September 22, 2000) at 03/09/2001 04.21.05, Serialize by Router on OSDE-Central-2/OSDE(Release 5.0.5 |September 22, 2000) at 03/09/2001 04.21.06, Serialize complete at 03/09/2001 04.21.06 Message-ID: Content-Transfer-Encoding: 7bit Content-Type: multipart/mixed; boundary="----=_NextPart_000_007F_01BDF6C7.FABAC1B0" This is a MIME Message ------=_NextPart_000_007F_01BDF6C7.FABAC1B0 Content-Type: multipart/alternative; boundary="----=_NextPart_001_0080_01BDF6C7.FABAC1B0" ------=_NextPart_001_0080_01BDF6C7.FABAC1B0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable ***** This is an HTML Message ! ***** ------=_NextPart_001_0080_01BDF6C7.FABAC1B0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

We will help you= get the mortgage loan you want! 

Whether a new home loan is what you seek or
to refinance your current h= ome loan at a lower interest rate and payment, we can help!

Mortgage rates haven't been this low in the last 12 months, take action no= w!
 Refinance your home with us and include all of those pesky credit card bil= ls or
use the extra cash for that pool you've always wanted=2E=2E=2E&nbs= p;

 Where others says NO, we say YES!!!
 Even if you have been turned down elsewhere, we can help! 

 Easy terms! Our mortgage referral service combines the
highest quality loans wi= th most economical rates and the easiest qualification!

 Take just 2 minutes to complete the following form=2E
 There is no obligation, all information is= kept strictly confidential, and you must be at least 18 years of age=2E Service available within the United States only=2E This service is fast an= d free=2E

 

Free information= request form:

Loan Application Form

REMOVA= L INSTRUCTIONS: This message is being sent to you in compliance with the cu= rrent Federal legislation=2E You must have either posted an AD to my FFA si= te, web-site, or requested information, or responded to one of our email le= tters=2E If you do not want to receive further emails or any other informat= ion from us, or you have received this mail in error, or for immediate remo= val you may simply use reply on your email program with "Remove from y= our mailing list#99221" in the subject=2E

------=_NextPart_001_0080_01BDF6C7.FABAC1B0-- ------=_NextPart_000_007F_01BDF6C7.FABAC1B0-- From nfs4-wg-request@sunroof.eng.sun.com Mon Sep 3 12:54:01 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA12091 for ; Mon, 3 Sep 2001 12:54:00 -0400 (EDT) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id JAA14897; Mon, 3 Sep 2001 09:55:23 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA06988; Mon, 3 Sep 2001 09:54:54 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0) with ESMTP id f83GsX40016180 for ; Mon, 3 Sep 2001 09:54:33 -0700 (PDT) Received: from venus.sun.com (venus.EBay.Sun.COM [129.150.69.5]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA24310 for ; Mon, 3 Sep 2001 09:54:45 -0700 (PDT) Received: from a88.lambo.student.liu.se (a88.lambo.student.liu.se [130.236.229.88]) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA14085 for ; Mon, 3 Sep 2001 09:54:44 -0700 (PDT) Received: by a88.lambo.student.liu.se (Postfix, from userid 500) id E26E134CDD; Mon, 3 Sep 2001 18:54:42 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by a88.lambo.student.liu.se (Postfix) with ESMTP id DD30ECF39 for ; Mon, 3 Sep 2001 18:54:42 +0200 (CEST) Date: Mon, 3 Sep 2001 18:54:42 +0200 (CEST) From: =?iso-8859-1?Q?Peter_=C5strand?= X-X-Sender: To: Subject: COMPOUND result Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=iso-8859-1 Content-Transfer-Encoding: 8BIT Content-Transfer-Encoding: 8BIT I'm not sure I fully understand what is the result of the COMPOUND procedure. draft-ietf-nfsv4-00-00.txt (is this the newest one?) says: (13.1) ... and the reply looks like this: +------------+-----------------------+-----------------------+-- |last status | status + op + results | status + op + results | +------------+-----------------------+-----------------------+-- ... (14.2) ... RESULT union nfs_resop4 switch (nfs_opnum4 resop){ case : ; ... }; struct COMPOUND4res { nfsstat4 status; utf8string tag; nfs_resop4 resarray<>; }; Is the drawing in section 13.1 supposed to illustrate COMPOUND4res? To me, they seem very different. I've managed to communicate with N4 and the CITI implementation from a Python application, but they give different COMPOUND results for, for example, PUTROOTFH operations. The CITI implementation replies with something that to me seems to be several garbage bytes extra. Any ideas? -- Peter Åstrand Telephone: +46-13-29 08 61 Cendio Systems E-mail: peter@cendio.se Teknikringen 3 583 30 Linköping From nfs4-wg-request@sunroof.eng.sun.com Tue Sep 4 09:35:19 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA15321 for ; Tue, 4 Sep 2001 09:35:18 -0400 (EDT) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA06721; Tue, 4 Sep 2001 07:36:38 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id GAA13818; Tue, 4 Sep 2001 06:36:11 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0) with ESMTP id f84DYc40017515 for ; Tue, 4 Sep 2001 06:34:38 -0700 (PDT) Received: from venus.sun.com (venus.EBay.Sun.COM [129.150.69.5]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id GAA12121 for ; Tue, 4 Sep 2001 06:34:50 -0700 (PDT) Received: from berzerk.gpcc.itd.umich.edu (berzerk.gpcc.itd.umich.edu [141.211.2.162]) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id GAA20269 for ; Tue, 4 Sep 2001 06:34:49 -0700 (PDT) Received: from skywalker.citi.umich.edu (skywalker.citi.umich.edu [141.211.92.240]) by berzerk.gpcc.itd.umich.edu (8.8.8/4.3-mailhub) with ESMTP id JAA27080; Tue, 4 Sep 2001 09:34:48 -0400 (EDT) Received: (from andros@localhost) by skywalker.citi.umich.edu (8.8.8/5.1-client) id JAA06517; Tue, 4 Sep 2001 09:34:48 -0400 (EDT) Message-Id: <200109041334.JAA06517@skywalker.citi.umich.edu> Precedence: first-class X-Mailer: exmh version 2.0.2 2/24/98 To: =?iso-8859-1?Q?Peter_=C5strand?= cc: nfsv4-wg@sunroof.eng.sun.com, andros@umich.edu Subject: Re: COMPOUND result In-reply-to: Your message of "Mon, 03 Sep 2001 18:54:42 +0200." Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Date: Tue, 04 Sep 2001 09:34:48 -0400 From: "William A.(Andy) Adamson" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id JAA15321 > > I'm not sure I fully understand what is the result of the COMPOUND > procedure. draft-ietf-nfsv4-00-00.txt (is this the newest one?) says: > > (13.1) > ... > and the reply looks like this: > > +------------+-----------------------+-----------------------+-- > |last status | status + op + results | status + op + results | > +------------+-----------------------+-----------------------+-- > ... > > (14.2) > ... > RESULT > > union nfs_resop4 switch (nfs_opnum4 resop){ > case : ; > ... > }; > > struct COMPOUND4res { > nfsstat4 status; > utf8string tag; > nfs_resop4 resarray<>; > }; > > Is the drawing in section 13.1 supposed to illustrate COMPOUND4res? To me, > they seem very different. > > I've managed to communicate with N4 and the CITI implementation from a > Python application, but they give different COMPOUND results for, for > example, PUTROOTFH operations. The CITI implementation replies with > something that to me seems to be several garbage bytes extra. Any ideas? > perhaps it's the tag field that's different? why don't you include the hex of the packet, then we could help. BTW ethereal decodes NFSv4 packets - have you tried sniffing the N4 and CITI NFSv4 traffic? -->ANdy From nfs4-wg-request@sunroof.eng.sun.com Tue Sep 4 13:23:23 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA22089 for ; Tue, 4 Sep 2001 13:23:22 -0400 (EDT) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id KAA21879; Tue, 4 Sep 2001 10:24:45 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA02802; Tue, 4 Sep 2001 10:24:10 -0700 (PDT) Received: from centralmail1.Central.Sun.COM (centralmail1.Central.Sun.COM [129.147.62.10]) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0) with ESMTP id f84HNn40017836 for ; Tue, 4 Sep 2001 10:23:49 -0700 (PDT) Received: from dhcp-aus08-183.central.sun.com (dhcp-aus08-183.Central.Sun.COM [129.153.128.183]) by centralmail1.Central.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA22699; Tue, 4 Sep 2001 11:24:01 -0600 (MDT) Received: (from shepler@localhost) by dhcp-aus08-183.central.sun.com (8.11.3+Sun/8.11.3) id f84HNow00545; Tue, 4 Sep 2001 12:23:50 -0500 (CDT) Date: Tue, 4 Sep 2001 12:23:50 -0500 From: Spencer Shepler To: Peter =?unknown-8bit?Q?=C5strand?= Cc: nfsv4-wg@sunroof.eng.sun.com Subject: Re: COMPOUND result Message-ID: <20010904122350.N414@dhcp-aus08-183.central.sun.com> Reply-To: shepler@eng.sun.com Mail-Followup-To: Spencer Shepler , Peter =?unknown-8bit?Q?=C5strand?= , nfsv4-wg@sunroof.eng.sun.com References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.3.19i On Mon, Peter ?strand wrote: > > I'm not sure I fully understand what is the result of the COMPOUND > procedure. draft-ietf-nfsv4-00-00.txt (is this the newest one?) says: > > (13.1) > ... > and the reply looks like this: > > +------------+-----------------------+-----------------------+-- > |last status | status + op + results | status + op + results | > +------------+-----------------------+-----------------------+-- This is a symbolic representation. > > (14.2) > ... > RESULT > > union nfs_resop4 switch (nfs_opnum4 resop){ > case : ; > ... > }; > > struct COMPOUND4res { > nfsstat4 status; > utf8string tag; > nfs_resop4 resarray<>; > }; This is the "real" description. As Andy has suggested, ethereal should be helpful. Spencer From nfs4-wg-request@sunroof.eng.sun.com Thu Sep 6 18:24:54 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA10262 for ; Thu, 6 Sep 2001 18:24:54 -0400 (EDT) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id QAA14674; Thu, 6 Sep 2001 16:26:17 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id PAA11226; Thu, 6 Sep 2001 15:25:40 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.0.Gamma1+Sun/8.12.0.Gamma1) with ESMTP id f86MPEIQ025841; Thu, 6 Sep 2001 15:25:14 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id PAA05020; Thu, 6 Sep 2001 15:25:27 -0700 (PDT) From: OnLineCasino107@yahoo.com Received: from dakak.jadgc.com ([202.163.231.133]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id QAA28143; Thu, 6 Sep 2001 16:26:00 -0600 (MDT) Received: from sdn-ar-002riprovP335.dialsprint.net_[168.191.126.241] ([168.191.126.241]) by dakak.jadgc.com (Lotus Domino Build 166.1) with SMTP id 2001090706353921:4789 ; Fri, 7 Sep 2001 06:35:39 +0800 Received: from BMS-243[212.187.02.211]wx-y_jl6-3 by sdn-ar-002riprovP335.dialsprint.net with ESMTP; Thu, 06 Sep 2001 18:18:34 -0400 To: Subject: Win A Band New Ferrari Spider 360 3346 Date: Thu, 06 Sep 2001 18:18:24 -0400 MIME-Version: 1.0 X-Priority: 1 (High) X-MSMail-Priority: High Reply-To: no_search102@libero.it X-MIMETrack: Itemize by SMTP Server on dakak/Jadgc(Release 5.0 (Intl)|30 March 1999) at 09/07/2001 06:35:48 AM, Serialize by Router on dakak/Jadgc(Release 5.0 (Intl)|30 March 1999) at 09/07/2001 06:46:12 AM, Serialize complete at 09/07/2001 06:46:12 AM Message-ID: <000033667a1c$0000320a$00000d12@BMS-243[212.187.02.211]wx-y_jl6-3> Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Welcome to Vegas on the Internet

Welcome to Vegas on the Internet!

The Worlds Largest Online Casino!

We are giving away a Brand New Ferrari Spider 360 worth <= font color=3D"#008000">$240,000.00,
also a Honda Acc= ord EX-V6 worth $28,000.00 and muc= h more!

Open 24-7 with the BES= T pay outs
of ALL online casino's! Play now win BIG!

Win a New CAR! Click Here To Enter!


To be Removed, Reply with Remove in Subject!

From nfs4-wg-request@sunroof.eng.sun.com Sat Sep 8 22:50:19 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA04290 for ; Sat, 8 Sep 2001 22:50:18 -0400 (EDT) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id UAA16242; Sat, 8 Sep 2001 20:51:42 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id TAA02514; Sat, 8 Sep 2001 19:51:20 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.0+Sun/8.12.0) with ESMTP id f892ow49029561; Sat, 8 Sep 2001 19:50:58 -0700 (PDT) Received: from venus.sun.com (venus.EBay.Sun.COM [129.150.69.5]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id TAA02505; Sat, 8 Sep 2001 19:51:12 -0700 (PDT) Received: from ns.iwill.co.kr ([211.218.51.225]) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id TAA19498; Sat, 8 Sep 2001 19:51:10 -0700 (PDT) Message-Id: <200109090251.TAA19498@venus.sun.com> Received: from host (04-122.024.popsite.net [216.126.163.122]) by ns.iwill.co.kr with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.1960.3) id SHP0V86G; Sun, 9 Sep 2001 12:04:21 +0900 From: "Sonny Barret" Subject: All the Contacts You Will Need #7BDD To: some@venus.sun.com X-Mailer: Microsoft Outlook Express 4.72.1712.3 X-MimeOLE: Produced By Microsoft MimeOLE VÐßD.1712.3 Mime-Version: 1.0 Date: Sat, 08 Sep 2001 21:41:18 -0500 Content-Type: multipart/mixed; boundary="----=_NextPart_000_007F_01BDF6C7.FABAC1B0" Content-Transfer-Encoding: 7bit This is a MIME Message ------=_NextPart_000_007F_01BDF6C7.FABAC1B0 Content-Type: multipart/alternative; boundary="----=_NextPart_001_0080_01BDF6C7.FABAC1B0" ------=_NextPart_001_0080_01BDF6C7.FABAC1B0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable ***** This is an HTML Message ! ***** ------=_NextPart_001_0080_01BDF6C7.FABAC1B0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Executive Guild Membership ApplicationResponse-O-Matic Form

Dear Candidate,=A0

You have been selected as a potential candidate for a free listing in=A0<= br> the 2001 Edition of the International Executive Guild Registry=2E=A0
=
Please accept our congratulations for this coveted honor=2E=A0

As this edition is so important in view of the new millennium, the=A0
= International Executive Guild Registry will be published in two different= =A0
formats; the searchable CD-ROM and the Online Registry=2E=A0

Since inclusion can be considered recognition of your career position=A0<= br> and professionalism, each candidate is evaluated in keeping with high=A0<= br> standards of individual achievement=2E In light of this, the Internationa= l Executive
Guild thinks that you may make an interesting biographical subject=2E=A0<= br>
We look forward to your inclusion and appearance in the International=A0<= br> Executive Guild's Registry=2E Best wishes for your continued success=2E=A0=

International Executive Guild=A0
Listing Dept=2E=A0

If you wish to be removed from our list, please submit your request
at the bottom of this email=2E



Pleas= e complete all the information below=2E
Our loan specialist will be con= tacting you at your convenience=2E
Thank You!

Plea= se use your mouse to navigate between fields=2E Thank You=2E


=
Your Full Name *
Address *
City *
State(US= A Only) * UNITED STATES ONLY!
Zip/Postal Code *
= Home Phone *
Work Phone *
Email Address <= input type=3D"text" size=3D"20" maxlength=3D"30" name=3D"Email"> *
= Best Time To Call *
Do You Own Your Home?
Property Value =3D 50000)) { alert('Not Valid! Please enter the approximate value of = current property or property you wish to purchase \n (greater than or equal= to 50000) using only number characters - 0123456789'); this=2Efocus(); thi= s=2Eselect(); return false; }"> * Please= use numbers only
Property Type *
Purchase= Price * Please use numb= ers only

Year Acquired

 *<= /td>
1st Mortgage-Balance Owed * Please use numbers only (ex:= 45000) enter 0 for none
1st Mortgage-In= terest Rate %
Is 1st Adjustable or = Fixed? *
Employer *
Monthly Gross House= hold Income * Please use numbers only
2nd Mortgage Balance owed > * Please use numbers only(ex:45000) enter 0 for none=
Amount You Wish To Borrow *
= = Credit Rating *
Monthly Debt= * Please use numbers only
Loan Interested In *
 

Fast & Easy -You Are Done !
International Executive Guild
Registration Form
(US and Canada Only)
Please fill out this form if you would like to be included on The International Executive Guild, For accuracy and publication purposes, please complete and send this form at the earliest opportunity=2E There is no charge or obligation to be listed on The International Executive Guild=2E
Your Name
Your Company
Title
Address
City
State or Province
Country
ZIP/Postal Code
Day Time Telephone
Home Phone
 (Not To Be Published)
Email

TO HELP US IN CONSIDERING YOUR APPLICATION, PLEASE TELL US A LITTLE ABOUT YOURSELF=2E=2E=2E
Your Business
(Financial Svcs, Banking, Computer Hardware, Software, Professional Svcs, Chemicals, Apparel, Aerospace, Food, Government, Utility, etc=2E)
Type of Organization
(M= fg, Dist/Wholesaler, Retailer, Law Firm,
Investment Bank, Commercial Bank, University,
Financial Consultants, Ad Agency, Contractor, Broker, etc=2E)
Your Business Expertise
(Corp=2EMgmt, Marketing, Civil Engineering,
Tax Law, Nuclear Physics, Database Development, Operations, Pathologist, Mortgage Banking, etc=2E)
Major Product Line
(Integrated Circuits, Commercial Aircraft, Adhesives, Cosmetics, Plastic Components, Snack Foods, etc=2E)


Note: Submitting this form= will be made by email, not by use of  www=2E  Confirmation of its de= livery is made by browsing your outgoing mail=2E

Thank you for filling in this form, we will contact you with more information=2E

List Removal
Click Here
------=_NextPart_001_0080_01BDF6C7.FABAC1B0-- ------=_NextPart_000_007F_01BDF6C7.FABAC1B0-- From nfs4-wg-request@sunroof.eng.sun.com Sun Sep 9 00:38:16 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA05519 for ; Sun, 9 Sep 2001 00:38:16 -0400 (EDT) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id WAA07247; Sat, 8 Sep 2001 22:39:38 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id VAA07195; Sat, 8 Sep 2001 21:39:23 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.0+Sun/8.12.0) with ESMTP id f894d049029652; Sat, 8 Sep 2001 21:39:00 -0700 (PDT) Received: from venus.sun.com (venus.EBay.Sun.COM [129.150.69.5]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id VAA08041; Sat, 8 Sep 2001 21:39:14 -0700 (PDT) From: pmdsk@bidnow.com Received: from dn1.mpint.co.jp ([202.217.183.66]) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id VAA09314; Sat, 8 Sep 2001 21:38:58 -0700 (PDT) Received: from 202.217.183.66 (07-045.024.popsite.net [66.19.3.45]) by dn1.mpint.co.jp (8.7.3 Version 1.1 Build 562/8.7.3) with SMTP id NAA00404; Sun, 09 Sep 2001 13:32:46 +0900 (JST) Message-Id: <200109090432.NAA00404@dn1.mpint.co.jp> Date: Sat, 08 Sep 01 21:10:21 EST To: xcjawkedn@jkwqcgfemnx.com Subject: It Started Out as a Joke The Program ------------------------------------------------------------------------------------------------------- AS SEEN ON NATIONAL TV --- INCREDIBLE $0 to $50,000 in 90 days!!! ------------------------------------------------------------------------------------------------------- You can earn $50,000 or more in next the 90 days sending e-mail. Seem impossible? Read on for details. This is the letter you've been reading about in the news lately. Due to the popularity of this letter on the Internet, a major nightly news program recently devoted an entire show to the investigation of the program described below to see if it really can make people money. The show also investigated whether or not the program was legal. Their findings proved once and for all that there are absolutely no laws prohibiting the participation in the program. This has helped to show people that this is a simple, harmless and fun way to make some extra money at home. The results of this show have been truly remarkable. So many people are participating that those involved are doing much better than ever before. Since everyone makes more as more people try it out, its been very exciting to be a part of lately. You will understand once you experience it. HERE IT IS BELOW: *** Print This Now For Future Reference *** The following income opportunity is one you may be interested in taking a look at. It can be started with VERY LITTLE investment and the income return is TREMENDOUS!!! $$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$ If you would like to make at least $50,000 in less than 90 days ! Please read the enclosed program...THEN READ IT AGAIN!!! $$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$ THIS IS A LEGITIMATE, LEGAL, MONEY MAKING OPPORTUNITY.It does not require you to come into contact with people, do any hard work, and best of all, you never have to leave the house except to get the mail. If you believe that someday you'll get that big break that you 'vebeen waiting for, THIS IS IT! Simply follow the instructions, andyour dreams will come true. This multi-level e-mail order marketingprogram works perfectly...100% EVERY TIME. E-mail is the sales tool of the future. Take advantage of this non-commercialized method of advertising NOW!!! The longer you wait, the more people will be doing business using e-mail. Get your piece of this action!!! MULTI-LEVEL MARKETING (MLM) has finally gained respectability. It is being taught in the Harvard Business School, and both Stanford Research and the Wall Street Journal have stated that between 50% and 65% of all goods and services will be sold through multi-level methods by the mid to late 1990's. This is a Multi-Billion Dollar industry and of the 500,000 millionaires in the U.S., 20% (100,000) made their fortune in the last several years in MLM. Moreover, statistics show 45 people become millionaires everyday through Multi-Level Marketing. You may have heard this story before, but over the summer Donald Trump made an appearance on the David Letterman show. Dave asked him what he would do if he lost everything and had to start over from scratch. Without hesitating, Trump said he would find a good network marketing company and get to work. The audience started to hoot and boo him. He looked out at the audience and dead-panned his response: "That's why I'm sitting up here and you are all sitting out there!" The enclosed information is something I almost let slip through my fingers. Fortunately, sometime later I re-read everything and gave somethought and study to it. My name is Johnathon Rourke. Two years ago, the corporation I worked at for the past twelve years down-sized and my position was eliminated. After unproductive job interviews, I decided to open my own business. Over the past year, I incurred many unforeseen financial problems. I owed my family, friends and creditors over $35,000. The economy was taking a toll on my business and I just couldn't seem to make ends meet. I had to refinance and borrow against my home to support my family and struggling business. AT THAT MOMENT something significant happened in my life and I am writing to share the experience in hopes that this will change your life FOREVER FINANCIALLY!!! In mid December, I received this program via e-mail. Six month's prior to receiving this program I had been sending away for information on various business opportunities. All of the programs I received, in my opinion, were not cost effective. They were either too difficult for me to comprehend or the initial investment was too much for me to risk to see if they would work or not. One claimed that I would make a million dollars in one year...it didn't tell me I'd have to write a book to make it! But like I was saying, in December of 1997 I received this program. I didn't send for it, or ask for it, they just got my name off a mailing list.THANK GOODNESS FOR THAT!!! After reading it several times, to make sure I was reading it correctly, I couldn't believe my eyes. Here was a MONEY MAKING PHENOMENON. I could invest as much as I wanted to start, without putting me further into debt. After I got a pencil and paper and figured it out, I would at least get my money back. But like most of you I was still a little skeptical and a little worried about the legal aspects of it all. So I checked it out with the U.S. Post Office (1-800-725-2161 24-hrs) and they confirmed that it is indeed legal! After determining the program was LEGAL and NOT A CHAIN LETTER, I decided "WHY NOT." Initially I sent out 10,000 e-mails. It cost me about $15 for my time on-line. The great thing about e-mail is that I don't need any money for printing to send out the program, and because all of my orders are fulfilled via e-mail, my only expense is my time. I am telling you like it is I hope it doesn't turn you off, but I promised myself that I would not "rip-off" anyone, no matter how much money it made me. In less than one week, I was starting to receive orders for REPORT #1 By January 13, I had received 26 orders for REPORT #1. Your goal is to "RECEIVE at least 20 ORDERS FOR REPORT #1 WITHIN 2 WEEKS. IF YOU DON'T, SEND OUT MORE PROGRAMS UNTIL YOU DO!" My first step in making $50,000 in 90 days was done. By January 30, I had received 196 orders for REPORT #2. Your goal is to "RECEIVE AT LEAST 100+ ORDERS FOR REPORT #2 WITHIN 2 WEEKS. IF NOT, SEND OUT MORE PROGRAMS UNTIL YOU DO. ONCE YOU HAVE 100 ORDERS, THE REST IS EASY, RELAX, YOU WILL MAKE YOUR $50,000 GOAL." Well, I had 196 orders for REPORT #2, 96 more than I needed. So I sat back and relaxed. By March 1, of my e-mailing of 10,000, I received $58,000 with more coming in every day. I paid off ALL my debts and bought a much needed new car. Please take time to read the attached program, IT WILL CHANGE YOUR LIFE FOREVER!! ! Remember, it won't work if you don't try it. This program does work , but you must follow it EXACTLY! Especially the rules of not trying to place your name in a different place. It won't work and you'll lose out on a lot of money! In order for this program to work, you must meet your goal of 20+ orders for REPORT #1, and 100+ orders for REPORT #2 and you will make $50,000 or more in 90 days. I AM LIVING PROOF THAT IT WORKS!!! If you choose not to participate in this program, I am sorry. It really is a great opportunity with little cost or risk to you. If you choose to participate, follow the program and you will be on your way to financial security. If you are a fellow business owner and are in financial trouble like I was, or you want to start your own business, consider this a sign. I DID! Sincerely, Johnathon Rourke A PERSONAL NOTE FROM THE ORIGINATOR OF THIS PROGRAM: By the time you have read the enclosed program and reports, you should have concluded that such a program, and one that is legal, could not have been created by an amateur. Let me tell you a little about myself. I had a profitable business for 10 years. Then in 1979 my business began falling off. I was doing the same things that were previously successful for me, but it wasn't working. Finally, I figured it out. It wasn't me, it was the economy. Inflation and recession had replaced the stable economy that had been with us since 1945.I don't have to tell you what happened to the unemployment rate... because many of you know from first hand experience. There were more failures and bankruptcies than ever before. The middle class was vanishing. Those who knew what they were doing invested wisely and moved up. Those who did not, including those who never had anything to save or invest, were moving down into the ranks of the poor. As the saying goes, "THE RICH GET RICHER AND THE POOR GET POORER." The traditional methods of making money will never allow you to "move up" or "get rich", inflation will see to that. You have just received information that can give you financial freedom for the rest of your life, with "NO RISK" and "JUST A LITTLE BIT OF EFFORT." You can make more money in the next few months than you have ever imagined. I should also point out that I will not see a penny of this money, nor anyone else who has provided a testimonial for this program. I have already made over 4 MILLION DOLLARS!I have retired from the program after sending thousands and thousands of programs. Follow the program EXACTLY AS INSTRUCTED. Do not change it in any way . It works exceedingly well as it is now. Remember to e-mail a copy of this exciting report to everyone you can think of. One of the people you send this to may send out 50,000...and your name will be on everyone of them! Remember though, the more you send out the more potential customers you will reach. So my friend, I have given you the ideas, information, materials and opportunity to become financially independent. IT IS UP TO YOU NOW! "THINK ABOUT IT" Before you delete this program from your mailbox, as I almost did, take a little time to read it and REALLY THINK ABOUT IT. Get a pencil and figure out what could happen when YOU participate. Figure out the worst possible response and no matter how you calculate it, you will still make a lot of money! You will definitely get back what you invested. Any doubts you have will vanish when your first orders come in. IT WORKS! Jody Jacobs, Richmond, VA HERE'S HOW THIS AMAZING PROGRAM WILL MAKE YOU THOUSANDS OF DOLLAR$ INSTRUCTIONS: This method of raising capital REALLY WORKS 100% EVERY TIME. I am sure that you could use up to $50,000 or more in the next 90 days. Before you say "BULL... ", please read this program carefully. This is not a chain letter, but a perfectly legal money making opportunity. Basically, this is what you do: As with all multi-level businesses, we build our business by recruiting new partners and selling our products. Every state in the USA allows you to recruit new multi-level business partners, and we offer a product for EVERY dollar sent. YOUR ORDERS COME BY MAIL AND ARE FILLED BY E-MAIL, so you are not involved in personal selling. You do it privately in your own home, store or office. This is the GREATEST Multi-Level Mail Order Marketing anywhere. This is what you MUST do: 1. Order all 4 reports shown on the list below (you can't sell them if youdon't order them). -- For each report, send $5.00 CASH, the NAME & NUMBER OF THE REPORT YOU ARE ORDERING, YOUR E-MAIL ADDRESS, and YOUR NAME & RETURN ADDRESS (in case of a problem) to the person whose name appears on the list next to the report. MAKE SURE YOUR RETURN ADDRESS IS ON YOUR ENVELOPE IN CASE OF ANY MAIL PROBLEMS! -- When you place your order, make sure you order each of the four reports. You will need all four reports so that you can save them on your computer and resell them. -- Within a few days you will receive, via e-mail, each of the four reports. Save them on your computer so they will be accessible for you to send to the 1,000's of people who will order them from you. 2. IMPORTANT DO NOT alter the names of the people who are listed next to each report, or their sequence on the list, in any way other than is instructed below in steps "a" through "f" or you will lose out on the majority of your profits. Once you understand the way this works, you'll also see how it doesn't work if you change it. Remember, this method has been tested,and if you alter it, it will not work. a. Look below for the listing of available reports. b. After you've ordered the four reports, take this advertisement and remove the name and address under REPORT #4. This person has made it through the cycle and is no doubt counting their $50,000! c. Move the name and address under REPORT #3 down to REPORT #4. d. Move the name and address under REPORT #2 down to REPORT #3. e. Move the name and address under REPORT #1 down to REPORT #2. f. Insert your name/address in the REPORT #1 position. Please make sure you COPY ALL INFORMATION, every name and address, ACCURATELY! 3. Take this entire letter, including the modified list of names, and save it to your computer. Make NO changes to the instruction portion of this letter. Your cost to participate in this is practically nothing (surely you can afford $20). You obviously already have an Internet connection and e-mail is FREE! There are two primary methods of building your downline: METHOD #1: SENDING BULK E-MAIL Let's say that you decide to start small, just to see how it goes, and we'll assume you and all those involved send out only 2,000 programs each. Let's also assume that the mailing receives a 0.5% response. Using a good list the response could be much better. Also, many people will send out hundreds of thousands of programs instead of 2,000. But continuing with this example, you send out only 2,000 programs. With a 0.5% response, that is only 10 orders for REPORT #1. Those 10 people respond by sending out 2,000 programs each for a total of 20,000. Out of those 0.5%, 100 people respond and order REPORT #2. Those 100 mail out 2,000 programs each for a total of 200,000. The 0.5% response to that is 1,000 orders for REPORT #3. Those 1,000 send out 2,000 programs each for a 2,000,000 total. The 0.5% response to that is 10,000 orders for REPORT #4. That's 10,000 $5 bills for you. CASH!!! Your total income in this example is $50 + $500 + $5,000 + $50,000 for a total of $55,550!!! REMEMBER FRIEND, THIS IS ASSUMING 1,990 OUT OF THE 2,000 PEOPLE YOU MAIL TO WILL DO ABSOLUTELY NOTHING AND TRASH THIS PROGRAM! DARE TO THINK FOR A MOMENT WHAT WOULD HAPPEN IF EVERYONE, OR HALF SENT OUT 100,000 PROGRAMS INSTEAD OF 2,000. Believe me, many people will do justthat, and more! By the way, your cost to participate in this is practically nothing. You obviously already have an Internet connection and e-mail is FREE!!! REPORT #2 will show you the best methods for bulk e-mailing, tell you where to obtain free bulk e-mail software and where to obtain e-mail lists. METHOD #2 - PLACING FREE ADS ON THE INTERNET Advertising on the internet is very, very inexpensive, and there are HUNDREDS of FREE places to advertise. Let's say you decide to start small just to see how well it works. Assume your goal is to get ONLY 10 people to participate on your first level. (Placing a lot of FREE ads on the Internet will EASILY get a larger response.) Also assume that everyone else in YOUR ORGANIZATION gets ONLY 10 downline members. Follow this example to achieve the STAGGERING results below: 1st level--your 10 members with $5.......................................$50 2nd level--10 members from those 10 ($5 x 100)..................$500 3rd level--10 members from those 100 ($5 x 1,000)...........$5,000 4th level--10 members from those 1,000 ($5 x 10,000).....$50,000 THIS TOTALS ---------->$55,550 Remember friends, this assumes that the people who participate only recruit 10 people each. Think for a moment what would happen if they got 20 people to participate! Most people get 100's of participants! THINK ABOUT IT! For every $5.00 you receive, all you must do is e-mail them the report they ordered. THAT'S IT! ALWAYS PROVIDE SAME-DAY SERVICE ON ALL ORDERS! This will guarantee that the e-mail THEY send out with YOUR name and address on it will be prompt because they can't advertise until they receive the report! AVAILABLE REPORTS *** Order Each REPORT by NUMBER and NAME *** Notes: -- ALWAYS SEND $5 CASH (U.S. CURRENCY) FOR EACH REPORT. CHECKS NOT ACCEPTED. -- ALWAYS SEND YOUR ORDER VIA FIRST CLASS MAIL. -- Make sure the cash is concealed by wrapping it in at least two sheets of paper. On one of those sheets of paper, include: (a) the number & name of the report you are ordering, (b) your e-mail address, and (c) your name & postal address. PLACE YOUR ORDER FOR THESE REPORTS NOW: REPORT #1 "The Insider's Guide to Advertising for Free on the Internet" ORDER REPORT #1 FROM: J. Hogston P.O. Box 241357 Apple Valley, MN 55124-1357 REPORT #2 "The Insider's Guide to Sending Bulk E-Mail on the Internet" ORDER REPORT #2 FROM: E- Solutions 101 PO Box 6411 Providence, RI 02940 REPORT #3 ""The Secrets to Multi-level Marketing on the Internet" ORDER REPORT #3 FROM: D.Vasicak 479 Bennett street Luzerne, PA 18709 REPORT #4 "How to Become a Millionaire Utilizing the Power of Multi-level Marketing and the Internet" ORDER REPORT #4 FROM: L. Daehlin 3208 Wellington Ct. Suite P Raleigh, NC 27615 About 50,000 new people get online every month! ******* TIPS FOR SUCCESS ******* -- TREAT THIS AS YOUR BUSINESS! Be prompt, professional, and follow the directions accurately. -- Send for the four reports IMMEDIATELY so you will have them when the orders start coming in because: When you receive a $5 order, you MUST send out the requested product/report. -- ALWAYS PROVIDE SAME-DAY SERVICE ON THE ORDERS YOU RECEIVE. -- Be patient and persistent with this program. If you follow the instructions exactly, your results WILL BE SUCCESSFUL! -- ABOVE ALL, HAVE FAITH IN YOURSELF AND KNOW YOU WILL SUCCEED! ******* YOUR SUCCESS GUIDELINES ******* Follow these guidelines to guarantee your success: If you don't receive 20 orders for REPORT #1 within two weeks, continue advertising or sending e-mails until you do. Then, a couple of weeks later you should receive at least 100 orders for REPORT#2. If you don 't, continue advertising or sending e-mails until you do. Once you have received 100 or more orders for REPORT #2, YOU CAN RELAX, because the system is already working for you, and the cash will continue to roll in! THIS IS IMPORTANT TO REMEMBER: Every time your name is moved down on the list, you are placed in front of a DIFFERENT report. You can KEEP TRACK of your PROGRESS by watching which report people are ordering from you. If you want to generate more income, send another batch of e-mails or continue placing ads and start the whole process again! There is no limit to the income you will generate from this business! Before you make your decision as to whether or not you participate in this program. Please answer one question. DO YOU WANT TO CHANGE YOUR LIFE? If the answer is yes, please look at the following facts about this program: 1. You are selling a product which does not Cost anything to PRODUCE, SHIP OR ADVERTISE. 2. All of your customers pay you in CASH! 3. E-mail is without question the most powerful method of distributing information on earth. This program combines the distribution power of e-mail together with the revenue generating power of multi-level marketing. 4. Your only expense--other than your initial $20 investment--is your time! 5. Virtually all of the income you generate from this program is PURE PROFIT! 6. This program will change your LIFE FOREVER. ACT NOW!Take your first step toward achieving financial independence. Orderthe reports and follow the program outlined above--SUCCESSwill be yourreward. Thank you for your time and consideration. PLEASE NOTE: If you need help with starting a business, registering a business name, learning how income tax is handled, etc., contact your localoffice of the Small Business Administration (a Federal Agency) 1-800-827-5722 for free help and answers to questions. Also, the InternalRevenue Service offers free help via telephone and free seminars aboutbusiness tax requirements. Your earnings are highly dependant on youractivities and advertising. The information contained on this site and in the report constitutes no guarantees stated nor implied. In the event that it is determined that this site or report constitutes a guarantee of any kind, that guarantee is now void. The earnings amounts listed on this site and in the report are estimates only. If you have any questions of the legality of this program, contact the Office of Associate Director for Marketing Practices, Federal Trade Commission, Bureau of Consumer Protection in Washington, DC. ///////////////////////////////////////////////////////////////// Remove at bbnggs@netscape.net ///////////////////////////////////////////////////////////////// From nfs4-wg-request@sunroof.eng.sun.com Sun Sep 9 11:53:18 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA11265 for ; Sun, 9 Sep 2001 11:53:18 -0400 (EDT) Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id IAA09495; Sun, 9 Sep 2001 08:54:44 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA14926; Sun, 9 Sep 2001 08:54:15 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.0+Sun/8.12.0) with ESMTP id f89Frn49000186 for ; Sun, 9 Sep 2001 08:53:49 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA26235 for ; Sun, 9 Sep 2001 08:54:02 -0700 (PDT) Received: from mail.cit-hk.com (ip84-92.asiaonline.net [202.85.84.92]) by patan.sun.com (8.9.3+Sun/8.9.3) with SMTP id JAA21186 for ; Sun, 9 Sep 2001 09:53:58 -0600 (MDT) Message-Id: <200109091553.JAA21186@patan.sun.com> Received: from ([137.132.42.122]) by mail.cit-hk.com (MERAK 2.10.340) with ESMTP id A9AC9622; Sun, 09 Sep 2001 23:20:43 +0800 From: info@novapakcorp.com To: nfsv4-wg@sunroof.eng.sun.com Subject: Manuf. Production/Contrl Software For $1,495.00! Date: Sun, 9 Sep 2001 23:20:58 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" (SBE)Job Master, a complete, user friendly Windows based software package, can manage and control your operation from sales quote to shipment. For one week only, Job Master, normally $2,495.00, is on sale for a total price of $1,495.00. In order for you to receive this $1,000.00 savings we must have your order by September 14th. (To reply by E Mail to this message or be removed from our list, Please go to the bottom of this message for an E Mail link.) Job Master is designed specifically for small to medium sized manufacturers, and costs many thousands of dollars less than any other even remotely comparable software package. Following is a list of features. If you have any questions, would like to discuss the package further, or if you would like to obtain our Web site address for a total walk through of the program, please call me directly at (661) 254-9926. By way of background, we are a software company, which for some years has specialized in the development of custom software, primarily for small to medium sized manufacturers. Job Master is a distillation of over a million and a half dollars of software we have developed to control and manage the production of our manufacturing clients. Job Master contains the following features: 1. QUOTATION MODULE. In this module, quotes are developed, modified, and produced for sending to your client. A history is kept of all quotes for future reference, or modification for other clients. All quotations and revisions are "auto numbered," including versions. The quotes section allows for the entry of parts/processes, and costing of each, including materials, labor, markup, and taxes. Inventory status can be accessed from this section for reference. 2. SALES ORDER. Once a quotation is accepted, the final quotation information can be transformed into a Sales Order for your client's signature on a "point and click" basis. The Sales Order can be modified and re issued if necessary. A history if kept of all Sales Orders for future reference, or modification for other clients. All sales orders and revisions are "auto numbered," including versions. Inventory status can be accessed from this section for reference. 3. CUSTOMER LETTERS can be created from the Quotation and Sales Order sections. 4. SHOP TRAVELER/WORK ORDER. Once a Sales Order is accepted, the sales order information can be transformed into a shop traveler/work order on a "point and click" basis. Each item on the Sales Order becomes a shop traveler/work order, with each step of production of the item then listed on the traveler/work order. Each such traveler/work order is tied back into the Sales Order. The shop traveler/work order allows for the entry of line items, and notes on each line item. The shop traveler/work order contains a "notes" section. The Shop traveler/work order allows for the storing or attachment of drawings to the traveler/work order. The shop traveler/work order also contains a "drop down," from which standard processes can be selected for inclusion on the shop traveler/work order. The shop traveler/work order numbers progress in order of production sequence, and re numbers them if new steps are added. The shop traveler/work order allows for change orders or revisions, and! ! ! ! numbers changes in sequence of he original shop traveler/work order number; i.e., 100, 100-1, 100-2, etc. All shop traveler/work orders and related revisions are retained in memory for future reference. The shop traveler/work order is bar coded for tracking of production step by step, and production of ongoing client status reports. Bar coding includes the ability for an employee to "swipe" their own ID bar code for recording in the system as to who upgraded what step. The shop traveler/work order function also allows for manual update of production status. The shop traveler/work order allows for quality control sign off, and the final production of certifications, either from a "canned" list, or hand typed in on a case by case basis. 5. INVENTORY. The application includes an inventory section, which allows operations to check materials inventory in and out. The inventory section allows for the comparison of inventory received against a P.O., and produces an "overage/underage" report of inventory received as compared against the P.O. The inventory section allows for the setting of minimum (re-order now!) and maximum inventory amounts, and produces reports showing what inventory needs to be ordered, as well as inventory that is at or above the maximum set to have in house. The inventory section also tracks "partially shipped" orders, which are tied in to the shipping function. This section shows how much completed product under a particular order has been actually shipped to a client, and how much remains to be shipped. The balance is adjusted as shipments are made. 6. REQUEST FOR PURCHASE. The application allows operators to produce a Request For Purchase for accounting for any inventory items, which need to be ordered. Inventory items have a drop down of approved vendors for each item. 7. REQUEST FOR BID. The application allows operators to produce a Request For Bid for accounting to send to Vendors for any inventory items, which need to be ordered. Inventory items have a drop down of approved vendors for each item to which Requests For Bid can be sent. 8. INVOICE. The application produces an invoice/invoice detail for all completed items ready to be billed/shipped to clients. 9. PRODUCTION OUTPUT STATUS. The application produces a date range selectable report on how much product, and the value of the product, which was completed during a selected date range. The application also produces a report on how many orders, and the value of those orders, which remain to be completed during a selected date range. 10. The application produces SHIPPING DOCUMENTS as per selected shippers, and produces a PACKING SLIP. 11. The application has a "FIND" FUNCTION in selected sections, allowing for searches by customer name, work order number, etc. 12. The application has "AUTO FILL;" i.e., when an operator starts to type in a name, number, etc. all related information auto fills after the first few letters or numbers are typed in. Job Master is currently being sold in the marketplace for $2,495.00 per package. However, if we receive your order by September 14th, your total price will be $1,495.00 Again, if you have any questions at all, or would like to place your order, please call me on my direct line, (661) 254-9926. Thank you! Mario Chavez Vice President of Sales and Marketing Application Sales, Inc. ------------------------------------------------------------------------------------------ This message is sent in compliance of the new e-mail bill: SECTION 301. Per Section 301, Paragraph (a)(2)(C) of S. 1618. To REPLY or be REMOVED from this solicitated email list, please click on the E Mail address following this message and type "REMOVE" or "REPLY" in the subject line: jbsptrsft77@yahoo.com --------------------------------------------------------------------------------------- From nfs4-wg-request@sunroof.eng.sun.com Mon Sep 10 20:00:08 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA06251 for ; Mon, 10 Sep 2001 20:00:07 -0400 (EDT) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id RAA17602; Mon, 10 Sep 2001 17:01:34 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id RAA20756; Mon, 10 Sep 2001 17:00:46 -0700 (PDT) Received: from jurassic.eng.sun.com (jurassic [129.146.88.130] (may be forged)) by sunroof.eng.sun.com (8.12.0+Sun/8.12.0) with ESMTP id f8B00849002718 for ; Mon, 10 Sep 2001 17:00:08 -0700 (PDT) Received: from eng.sun.com (terra.Eng.Sun.COM [129.146.86.99]) by jurassic.eng.sun.com (8.12.0+Sun/8.12.0) with ESMTP id f8B00L9m282528 for ; Mon, 10 Sep 2001 17:00:22 -0700 (PDT) Sender: Brent.Callaghan@eng.sun.com Message-ID: <3B9D5406.34F5A5E2@eng.sun.com> Date: Mon, 10 Sep 2001 17:00:06 -0700 From: Brent Organization: NFS Whackers X-Mailer: Mozilla 4.76C-CCK-MCD Netscape [en] (X11; U; SunOS 5.8 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: nfsv4-wg@sunroof.eng.sun.com Subject: Re: Delegation callbacks proposal References: <3B901A6B.BFDCF5D@eng.sun.com> <3B902D6E.F37646AB@eisler.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit I'd like to get some more input into the problem of callbacks through NATs and/or firewalls. In last week's posting, I presented the problem and followed it with a proposed solution. Though I should have made it more obvious that there are really two issues: 1. The problem 2. The solution Mike Eisler referred to some previous discussion on callbacks, but nobody (other than Dave Noveck's original proposal) mentioned the problem with NATs and firewalls - and the conflict with the WG charter statement: "Improved access and good performance on the Internet." Given that delegation is our brightest hope for good performance on the Internet, we must make this protocol perform well across NATs and firewalls. I proposed a solution that would utilize the transport endpoint or connection used for SETCLIENTID as a callback address. This would work around the NAT problem, and the re-use of an outbound TCP connection would address some of the firewall problems. Mike Eisler suggested that an implementation using a single UDP socket for outgoing traffic might bottleneck the socket. My callback proposal doesn't require a single source socket, only that the one used for SETCLIENTID be available for callbacks. Ric Werme pointed out that Tru64 NFS uses a single port for outgoing traffic and doesn't have a problem. Jim Rees pointed out that AFS (which uses a similar caching/callback model) already works through NATs using bi-directional RPC. He supported the "connection re-use" proposal, but suggested an option that would allow continued use of the cb_client4 in the SETCLIENTID args for clients that don't want/need to work through NATs My preference is to stick with a single callback policy, i.e. mandate the re-use of a connection or source endpoint for callbacks unless there's some compelling need to retain the client's ability to specify a callback address. Otherwise, we just burden our implementations with unnecessary cruft and testing. I don't think there's any doubt that we do have a problem: the callback mechanism conflicts with the charter. We need to reach some consensus on a solution. If not connection re-use, then what else will fix the problem ? Ta Brent From nfs4-wg-request@sunroof.eng.sun.com Mon Sep 10 21:21:42 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA08080 for ; Mon, 10 Sep 2001 21:21:41 -0400 (EDT) Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id TAA03140; Mon, 10 Sep 2001 19:23:00 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id SAA11636; Mon, 10 Sep 2001 18:22:28 -0700 (PDT) Received: from d-mpk17-86-138.eng.sun.com (d-mpk17-86-138 [129.146.86.138]) by sunroof.eng.sun.com (8.12.0+Sun/8.12.0) with ESMTP id f8B1Ln49002771 for ; Mon, 10 Sep 2001 18:21:49 -0700 (PDT) Received: (from shepler@localhost) by d-mpk17-86-138.eng.sun.com (8.11.3+Sun/8.11.3) id f8B1Lu700752 for nfsv4-wg@sunroof.eng.sun.com; Mon, 10 Sep 2001 20:21:56 -0500 (CDT) Date: Mon, 10 Sep 2001 20:21:56 -0500 From: Spencer Shepler To: nfsv4-wg@sunroof.eng.sun.com Subject: Re: Delegation callbacks proposal Message-ID: <20010910202156.R514@d-mpk17-86-138.eng.sun.com> Reply-To: shepler@eng.sun.com Mail-Followup-To: Spencer Shepler , nfsv4-wg@sunroof.eng.sun.com References: <3B901A6B.BFDCF5D@eng.sun.com> <3B902D6E.F37646AB@eisler.com> <3B9D5406.34F5A5E2@eng.sun.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3B9D5406.34F5A5E2@eng.sun.com> User-Agent: Mutt/1.3.19i On Mon, Brent wrote: > > I don't think there's any doubt that we do have a problem: the callback > mechanism conflicts with the charter. We need to reach some consensus > on a solution. If not connection re-use, then what else will fix > the problem ? I am not convinced that this is a "problem" that we need to solve today. The re-use of the connection for the callback path is something that would fit nicely into a minor version of the protocol. The proposed solution is not new to the working group (As Mike E. has provided reference to) and it is certainly not something new to the authors of the RFC as evidenced by these sections of RFC3010: 1.1.6. Client Caching and Delegation 8.3. Blocking Locks "must not rely on a callback mechanism" 9.2. Delegation and Callbacks "Because callback RPCs may not work in all environments (due to firewalls, for example), correct protocol operation does not depend on them. Preliminary testing of callback functionality by means of a CB_NULL procedure determines whether callbacks can be supported. The CB_NULL procedure checks the continuity of the callback path. A server makes a preliminary assessment of callback availability to a given client and avoids delegating responsibilities until it has determined that callbacks are supported." 9.2.1. Delegation Recovery o The use of callbacks is not to be depended upon until the client has proven its ability to receive them. Since RFC3010 is a Proposed Standard, it has received the normal IETF review cycle and the issue of failure to have the callbacks work with NAT or firewall present. I am not saying that the proposed idea isn't worthwhile; I just don't think that given the history of developing the protocol and the list of things that need to be addressed for correctness that it is the best time to change the callback mechanism. -- - Spencer - From nfs4-wg-request@sunroof.eng.sun.com Mon Sep 10 21:39:27 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA09500 for ; Mon, 10 Sep 2001 21:39:27 -0400 (EDT) Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id TAA10294; Mon, 10 Sep 2001 19:40:50 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id SAA14035; Mon, 10 Sep 2001 18:40:32 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.0+Sun/8.12.0) with ESMTP id f8B1ds49002779 for ; Mon, 10 Sep 2001 18:39:54 -0700 (PDT) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id SAA06794 for ; Mon, 10 Sep 2001 18:40:10 -0700 (PDT) Received: from mx01-a.netapp.com (mx01-a.netapp.com [198.95.226.53]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id SAA14722 for ; Mon, 10 Sep 2001 18:40:09 -0700 (PDT) Received: from frejya.corp.netapp.com (mh01 [10.10.20.91]) by mx01-a.netapp.com (8.11.1/8.11.1/NTAP-1.2) with ESMTP id f8B1eI921351; Mon, 10 Sep 2001 18:40:18 -0700 (PDT) Received: from tooting-fe.eng.netapp.com (localhost [127.0.0.1]) by frejya.corp.netapp.com (8.11.1/8.11.1/NTAP-1.2) with ESMTP id f8B1e8X06695; Mon, 10 Sep 2001 18:40:08 -0700 (PDT) Received: (from beepy@localhost) by tooting-fe.eng.netapp.com (8.8.8+Sun/8.8.8) id SAA08733; Mon, 10 Sep 2001 18:40:08 -0700 (PDT) From: Brian Pawlowski Message-Id: <200109110140.SAA08733@tooting-fe.eng.netapp.com> Subject: Re: Delegation callbacks proposal In-Reply-To: <20010910202156.R514@d-mpk17-86-138.eng.sun.com> from Spencer Shepler at "Sep 10, 1 08:21:56 pm" To: shepler@eng.sun.com Date: Mon, 10 Sep 2001 18:40:08 -0700 (PDT) Cc: nfsv4-wg@sunroof.eng.sun.com X-Mailer: ELM [version 2.4ME++ PL40 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit I remember this being discussed in great detail over e-mail and in the meetings around that time when Dave Noveck first presented the design. We achieved consensus then that the design as it stands was acceptable. I would like to move forward and get consensus that we push "reuse of a connection for callbacks" into a minor version effort following on the base protocol specification (RFC 3010 + current in progress edits). Comments? beepy > On Mon, Brent wrote: > > > > I don't think there's any doubt that we do have a problem: the callback > > mechanism conflicts with the charter. We need to reach some consensus > > on a solution. If not connection re-use, then what else will fix > > the problem ? > > I am not convinced that this is a "problem" that we need to solve > today. The re-use of the connection for the callback path is > something that would fit nicely into a minor version of the protocol. > > The proposed solution is not new to the working group (As Mike E. has > provided reference to) and it is certainly not something new to the > authors of the RFC as evidenced by these sections of RFC3010: > > 1.1.6. Client Caching and Delegation > > 8.3. Blocking Locks > "must not rely on a callback mechanism" > > 9.2. Delegation and Callbacks > "Because callback RPCs may not work in all environments (due to > firewalls, for example), correct protocol operation does not depend > on them. Preliminary testing of callback functionality by means of a > CB_NULL procedure determines whether callbacks can be supported. The > CB_NULL procedure checks the continuity of the callback path. A > server makes a preliminary assessment of callback availability to a > given client and avoids delegating responsibilities until it has > determined that callbacks are supported." > > 9.2.1. Delegation Recovery > o The use of callbacks is not to be depended upon until the client > has proven its ability to receive them. > > > Since RFC3010 is a Proposed Standard, it has received the normal IETF > review cycle and the issue of failure to have the callbacks work with > NAT or firewall present. > > I am not saying that the proposed idea isn't worthwhile; I just don't > think that given the history of developing the protocol and the list > of things that need to be addressed for correctness that it is the > best time to change the callback mechanism. > > -- > > - Spencer - > > From nfs4-wg-request@sunroof.eng.sun.com Wed Sep 12 10:08:23 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA22292 for ; Wed, 12 Sep 2001 10:08:23 -0400 (EDT) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA12531; Wed, 12 Sep 2001 08:08:21 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA03781; Wed, 12 Sep 2001 07:07:57 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.0+Sun/8.12.0) with ESMTP id f8CE7R49004953 for ; Wed, 12 Sep 2001 07:07:27 -0700 (PDT) Received: from venus.sun.com (venus.EBay.Sun.COM [129.150.69.5]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA24880 for ; Wed, 12 Sep 2001 07:07:47 -0700 (PDT) Received: from a88.lambo.student.liu.se (a88.lambo.student.liu.se [130.236.229.88]) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA11425 for ; Wed, 12 Sep 2001 07:07:45 -0700 (PDT) Received: by a88.lambo.student.liu.se (Postfix, from userid 500) id 36A5D34CDD; Wed, 12 Sep 2001 16:07:44 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by a88.lambo.student.liu.se (Postfix) with ESMTP id 3104FCF39 for ; Wed, 12 Sep 2001 16:07:44 +0200 (CEST) Date: Wed, 12 Sep 2001 16:07:44 +0200 (CEST) From: =?iso-8859-1?Q?Peter_=C5strand?= X-X-Sender: To: Subject: Re: COMPOUND result In-Reply-To: <20010904122350.N414@dhcp-aus08-183.central.sun.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=iso-8859-1 Content-Transfer-Encoding: 8BIT Content-Transfer-Encoding: 8BIT On Tue, 4 Sep 2001, Spencer Shepler wrote: > On Mon, Peter ?strand wrote: > > > > I'm not sure I fully understand what is the result of the COMPOUND > > procedure. draft-ietf-nfsv4-00-00.txt (is this the newest one?) says: > > > > (13.1) > > ... > > and the reply looks like this: > > > > +------------+-----------------------+-----------------------+-- > > |last status | status + op + results | status + op + results | > > +------------+-----------------------+-----------------------+-- > > This is a symbolic representation. I see. But I still think this would be a more correct representation: +------------+-----+-----------------------+-----------------------+-- |last status | tag | op + status + results | op + status + results | +------------+-----+-----------------------+-----------------------+-- > As Andy has suggested, ethereal should be helpful. Thanks for the advice. I hadn't used Ethereal before, but after using it a couple of hours, I really like it. Very useful. -- Peter Åstrand Telephone: +46-13-29 08 61 Cendio Systems E-mail: peter@cendio.se Teknikringen 3 583 30 Linköping From nfs4-wg-request@sunroof.eng.sun.com Wed Sep 12 12:46:17 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA27350 for ; Wed, 12 Sep 2001 12:46:17 -0400 (EDT) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA23517; Wed, 12 Sep 2001 10:46:14 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA11447; Wed, 12 Sep 2001 09:43:07 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.0+Sun/8.12.0) with ESMTP id f8CGgZ49005104 for ; Wed, 12 Sep 2001 09:42:36 -0700 (PDT) Received: from venus.sun.com (venus.EBay.Sun.COM [129.150.69.5]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA11382 for ; Wed, 12 Sep 2001 09:42:56 -0700 (PDT) Received: from a88.lambo.student.liu.se (a88.lambo.student.liu.se [130.236.229.88]) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA05421 for ; Wed, 12 Sep 2001 09:42:55 -0700 (PDT) Received: by a88.lambo.student.liu.se (Postfix, from userid 500) id 2613134CDD; Wed, 12 Sep 2001 18:42:54 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by a88.lambo.student.liu.se (Postfix) with ESMTP id 20616CF39 for ; Wed, 12 Sep 2001 18:42:54 +0200 (CEST) Date: Wed, 12 Sep 2001 18:42:54 +0200 (CEST) From: =?iso-8859-1?Q?Peter_=C5strand?= X-X-Sender: To: Subject: UDP retransmission policies Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=iso-8859-1 Content-Transfer-Encoding: 8BIT Content-Transfer-Encoding: 8BIT RFC1831 says: "It is important to point out that RPC does not try to implement any kind of reliability and that the application may need to be aware of the type of transport protocol underneath RPC. If it knows it is running on top of a reliable transport such as TCP [6], then most of the work is already done for it. On the other hand, if it is running on top of an unreliable transport such as UDP [7], it must implement its own time-out, retransmission, and duplicate detection policies as the RPC protocol does not provide these services." What policies does NFSv4 use for retransmissions etc? I cannot find this information in 3010. -- Peter Åstrand Telephone: +46-13-29 08 61 Cendio Systems E-mail: peter@cendio.se Teknikringen 3 583 30 Linköping From nfs4-wg-request@sunroof.eng.sun.com Wed Sep 12 12:57:23 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA27650 for ; Wed, 12 Sep 2001 12:57:23 -0400 (EDT) Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA03211; Wed, 12 Sep 2001 10:57:20 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA11868; Wed, 12 Sep 2001 09:57:00 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.0+Sun/8.12.0) with ESMTP id f8CGuQ49005111 for ; Wed, 12 Sep 2001 09:56:26 -0700 (PDT) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA11807 for ; Wed, 12 Sep 2001 09:56:47 -0700 (PDT) Received: from mx01-a.netapp.com (mx01-a.netapp.com [198.95.226.53]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA10716 for ; Wed, 12 Sep 2001 09:56:47 -0700 (PDT) Received: from hawk.corp.netapp.com (mh02 [10.10.20.101]) by mx01-a.netapp.com (8.11.1/8.11.1/NTAP-1.2) with ESMTP id f8CGuv905829; Wed, 12 Sep 2001 09:56:57 -0700 (PDT) Received: from ussvlexc01.corp.netapp.com (localhost [127.0.0.1]) by hawk.corp.netapp.com (8.11.1/8.11.1/NTAP-1.2) with ESMTP id f8CGukY21074; Wed, 12 Sep 2001 09:56:46 -0700 (PDT) Received: by ussvlexc01.corp.netapp.com with Internet Mail Service (5.5.2653.19) id ; Wed, 12 Sep 2001 09:56:26 -0700 Message-ID: <8C610D86AF6CD4119C9800B0D0499E333355F5@red.nane.netapp.com> From: "Noveck, Dave" To: =?iso-8859-1?Q?=27Peter_=C5strand=27?= , nfsv4-wg@sunroof.eng.sun.com Subject: RE: COMPOUND result Date: Wed, 12 Sep 2001 09:56:43 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id MAA27650 Peter Åstrand wrote: >On Tue, 4 Sep 2001, Spencer Shepler wrote: > > > On Mon, Peter ?strand wrote: > > > > > > I'm not sure I fully understand what is the result of the COMPOUND > > > procedure. draft-ietf-nfsv4-00-00.txt (is this the newest one?) says: > > > > > > (13.1) > > > ... > > > and the reply looks like this: > > > > > > +------------+-----------------------+-----------------------+-- > > > |last status | status + op + results | status + op + results | > > > +------------+-----------------------+-----------------------+-- > > > > This is a symbolic representation. > > I see. But I still think this would be a more correct representation: > > +------------+-----+-----------------------+-----------------------+-- > |last status | tag | op + status + results | op + status + results | > +------------+-----+-----------------------+-----------------------+-- In this context, I guess "+" is associative but not commutative. From nfs4-wg-request@sunroof.eng.sun.com Wed Sep 12 20:40:16 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA06880 for ; Wed, 12 Sep 2001 20:40:15 -0400 (EDT) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id RAA29247; Wed, 12 Sep 2001 17:40:17 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id RAA12077; Wed, 12 Sep 2001 17:39:51 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.0+Sun/8.12.0) with ESMTP id f8D0dK49005460; Wed, 12 Sep 2001 17:39:20 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id RAA00905; Wed, 12 Sep 2001 17:39:40 -0700 (PDT) Received: from elnolte.ne.jp (ns.elnolte.ne.jp [210.154.141.50]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id SAA22663; Wed, 12 Sep 2001 18:40:19 -0600 (MDT) Received: from hjui7yg (09-020.024.popsite.net [66.19.5.20]) by elnolte.ne.jp (8.9.3+3.2W/3.7Wpl2) with ESMTP id IAA05460; Sat, 1 Sep 2001 08:33:02 +0900 Message-Id: <200108312333.IAA05460@elnolte.ne.jp> From: "Nicola Scalia" Subject: Only a Few #26C1 To: open@elnolte.ne.jp X-Mailer: Microsoft Outlook Express 4..72.1712.3 X-MimeOLE: Produced By Microsoft MimeOLE V(null).1712.3 Mime-Version: 1.0 Date: Fri, 31 Aug 2001 18:33:19 -0500 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id UAA06880 *Earn $2000 - $5000 weekly-starting within 3-12 weeks. Make what you deserve! *Own your own business. Control your destiny! *Money Freedom=Time Freedom *54% + Gross Profit Margins *No Selling *Work from home, No overhead, or employees. *Fabulous Training & Support *Not traditional MLM, many times more profitable *Multibillion Dollar Travel & Internet Industry The most incredible part of our business is that ALL MY CLIENTS ASK ME TO CALL THEM! DO YOU QUALIFY FOR OUR MENTOR PROGRAM? ACCEPTING ONLY A FEW NEW ASSOCIATES This is not a hobby! Serious Inquires Only!! Please reply with the following information NOW! FULL NAME: COMPLETE ADDRESS: EMAIL ADDRESS: PHONE: (Required; area code & number) BEST 2 TIMES TO CALL YOU: TO: mailto:55btr@verizonmail?subject=tell_me_more This message is sent in compliance of the new email bill section 301. Per Section 301, Paragraph (a)(2)(C) of S. 1618, further transmissions to you by the sender of this email will be stopped at no cost to you. This message is not intended for residents in the State of WA, NV, CA & VA. Screening of addresses has been done to the best of our technical ability. If you are a Washington, Virginia, or California resident please remove yourself. We respect all removal requests. //////////////////////////////////////////////////// Please remove at: mailto:off89321@netscape.net?subject=remove //////////////////////////////////////////////////// From nfs4-wg-request@sunroof.eng.sun.com Thu Sep 13 22:22:41 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA22867 for ; Thu, 13 Sep 2001 22:22:40 -0400 (EDT) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id UAA11640; Thu, 13 Sep 2001 20:22:12 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id TAA16521; Thu, 13 Sep 2001 19:21:53 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.0+Sun/8.12.0) with ESMTP id f8E2LK7B000464 for ; Thu, 13 Sep 2001 19:21:21 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA25825 for ; Thu, 13 Sep 2001 14:08:38 -0700 (PDT) Received: from a88.lambo.student.liu.se (a88.lambo.student.liu.se [130.236.229.88]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id PAA13598 for ; Thu, 13 Sep 2001 15:09:20 -0600 (MDT) Received: by a88.lambo.student.liu.se (Postfix, from userid 500) id E843634CDD; Thu, 13 Sep 2001 23:08:33 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by a88.lambo.student.liu.se (Postfix) with ESMTP id 969D9CF39; Thu, 13 Sep 2001 23:08:33 +0200 (CEST) Date: Thu, 13 Sep 2001 23:08:33 +0200 (CEST) From: =?iso-8859-1?Q?Peter_=C5strand?= X-X-Sender: To: Spencer Shepler Cc: Subject: Re: UDP retransmission policies In-Reply-To: <20010913155034.N514@d-mpk17-86-138.eng.sun.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=iso-8859-1 Content-Transfer-Encoding: 8BIT Content-Transfer-Encoding: 8BIT > Peter, > Based on your recent questions, I assume that you are working on an > NFSv4 implementation. Yes, I'm working on test suite for NFS4 servers. I'm doing it as a part of my thesis project. I mentioned this somewhat in a mail on August 28. >I am curious what environment/platform you are > using for this. Would you mind sharing this information? I have evaluated N4 (http://n-4.sourceforge.net/) and though of using it as a foundation for my test suite. But for various reasons, I've decided to write everything in Python instead. Python has a built-in XDR-module and the source dist even comes with a simple RPC and NFS implementation. Today I have started writing on "nfs4lib.py". It uses the RPC and XDR modules, and it will probably be the foundation for my test suite. I have no previous implementation of programming with NFS, RPC or XDR, but hopefully I will catch up soon :) The development is still in early development, but if you have any ideas or suggestions, please let me know. -- Peter Åstrand Telephone: +46-13-29 08 61 Cendio Systems E-mail: peter@cendio.se Teknikringen 3 583 30 Linköping From nfs4-wg-request@sunroof.eng.sun.com Fri Sep 14 07:15:23 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA14638 for ; Fri, 14 Sep 2001 07:15:23 -0400 (EDT) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id EAA17798; Fri, 14 Sep 2001 04:14:53 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id EAA22625; Fri, 14 Sep 2001 04:14:25 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.0+Sun/8.12.0) with ESMTP id f8EBDt7B001838 for ; Fri, 14 Sep 2001 04:13:55 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id EAA22587 for ; Fri, 14 Sep 2001 04:14:15 -0700 (PDT) Received: from note.orchestra.cse.unsw.EDU.AU (note.orchestra.cse.unsw.EDU.AU [129.94.242.29]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with SMTP id FAA17757 for ; Fri, 14 Sep 2001 05:14:58 -0600 (MDT) Received: From notabene ([129.94.242.30] == xylophone.orchestra.cse.unsw.EDU.AU) (for ) (for ) By note With Smtp ; Fri, 14 Sep 2001 21:14:10 +1000 Received: from neilb by notabene with local (Exim 3.32 #1 (Debian)) id 15hqvA-0000zj-00; Fri, 14 Sep 2001 21:14:08 +1000 From: Neil Brown Sender: Neil Brown To: Brent Date: Fri, 14 Sep 2001 21:14:07 +1000 (EST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15265.59007.247626.818311@notabene.cse.unsw.edu.au> Cc: nfsv4-wg@sunroof.eng.sun.com Subject: Re: Delegation callbacks proposal In-Reply-To: message from Brent on Monday September 10 References: <3B901A6B.BFDCF5D@eng.sun.com> <3B902D6E.F37646AB@eisler.com> <3B9D5406.34F5A5E2@eng.sun.com> X-Mailer: VM 6.72 under Emacs 20.7.2 X-face: [Gw_3E*Gng}4rRrKRYotwlE?.2|**#s9D > I'd like to get some more input into the problem of callbacks > through NATs and/or firewalls. In last week's posting, I presented > the problem and followed it with a proposed solution. Though I should > have made it more obvious that there are really two issues: > > 1. The problem You noted two problems: 1/ NATs (and "fog on the internet" in general). 2/ "there's no standard for netid strings". I have nothing to add to the discussion about 1/. But if 2/ is a real problem, then it should be addressed somehow. Your solution is one way to address it, but not necessarily the only one. The NFSv4 protocol has two situations where a network address needs to be communicated. There is this situation, which uses a netid and a "universal address", and there is the fs_location attribute that uses a "server" name, to be looked up in the DNS or using inet_addr(3). I always thought it was unfortunate that you couldn't specify a port number in the fs_location field, and thus have multiple servers running with the one IP address, possibly serving different filesystems with vastly different implementations (though I cannot actually find a concrete use for this. "automounters" come to mind, as they run an NFS service on a non-standard port, but they don't make for a strong argument). I don't have any answers, but I think it is worth noting that Brent mentioned two problems, not just one. > > 2. The solution > I note in your proposed solution the sentence: "If a dropped connection needs to be re-established, then client or server must make a best effort to re-establish when needed." I'm not sure how the server would re-establish a connection. Connecting to the client is quite different to sending an RPC request up the connection that was established by the client (but that is ofcourse the point). You could suggest that if the client used a connection oriented protocol, then it should listen on the same port that it sent the SETCLIENTID request on. However that assumes that that makes sense in a protocol-independant sense, and I'm not sure that it does. As a (somewhat strained) example, imagine connecting to the server over a Unix domain socket. I don't think that the client's end of the connection has a name that can be used in a "connect" request by the server. Now it could be that we only ever expect NFSv4.0 to be used over IPv4 or IPv6, and only with TCP or UDP. That may be a perfectly reasonable restriction, or it may not (I really have no idea). If it is, then maybe both the clientaddr and the fs_locations address should be a utf8 (DNS name or dotted quad or IPv6 notation) and a int32 port number. If it is not, then I wonder if the definition of fs_location is entirely appropriate. Or it might be reasonable to drop the part about suggesting that the server might try to re-establish the connection. NeilBrown From nfs4-wg-request@sunroof.eng.sun.com Fri Sep 14 15:24:38 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA25022 for ; Fri, 14 Sep 2001 15:24:37 -0400 (EDT) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id MAA10638; Fri, 14 Sep 2001 12:24:03 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA12102; Fri, 14 Sep 2001 12:19:01 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.0+Sun/8.12.0) with ESMTP id f8EJIU7B002566; Fri, 14 Sep 2001 12:18:30 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA23776; Fri, 14 Sep 2001 12:18:51 -0700 (PDT) Received: from mail.asatsu.co.th (mail.asatsu.co.th [203.151.118.97]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id NAA28379; Fri, 14 Sep 2001 13:19:30 -0600 (MDT) Received: from host (ts002d35.pro-ri.concentric.net [206.173.11.95]) by mail.asatsu.co.th (8.9.3/8.8.7) with ESMTP id CAA05399; Sat, 15 Sep 2001 02:04:20 +0700 Message-Id: <200109141904.CAA05399@mail.asatsu.co.th> From: "Edward Silva" Subject: Average of 2 #2711 To: house@mail.asatsu.co.th X-Mailer: Microsoft Outlook Express 4.72.1712.3 X-MimeOLE: Produced By Microsoft MimeOLE VÐßD.1712.3 Mime-Version: 1.0 Date: Fri, 14 Sep 2001 07:03:02 -0500 Content-Type: multipart/mixed; boundary="----=_NextPart_000_007F_01BDF6C7.FABAC1B0" Content-Transfer-Encoding: 7bit This is a MIME Message ------=_NextPart_000_007F_01BDF6C7.FABAC1B0 Content-Type: multipart/alternative; boundary="----=_NextPart_001_0080_01BDF6C7.FABAC1B0" ------=_NextPart_001_0080_01BDF6C7.FABAC1B0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable ***** This is an HTML Message ! ***** ------=_NextPart_001_0080_01BDF6C7.FABAC1B0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable FREE Computer With Merchant Account Setup

COMPLETE CREDIT CARD PROCESSING SYSTEMS FOR YOUR BUSINESS=2E INTERNE= T - HOME BASED - MAIL ORDER - PHONE ORDER

Do you accept credit cards? Your competition does!

 

Everyone Approved - Credit Problems OK!
Approval in less than 24 hours!
Increase your sales by 300%
Start Accepting Credit Cards on your website!
Free Information, No Risk, 100% confidential=2E
Your name and information will not be sold to thrid parties!
Home Businesses OK! Phone/Mail Order OK!
No Application Fee, No Setup Fee!
Close More Impulse Sales!

Everyone Approved!

Good Credit or Bad!  To= apply today, please fill out the express form below=2E It contains all the information we need to get your account approved=2E For a= rea's that do not apply to you please put "n/a" in the box=2E

Upon receipt, we'll fax you with all of the all Bank Card Application documents necessary to establish your Merchant Account=2E Once returned we= can have your account approved within 24 hours=2E
 

Service Industry Standard

US
Site Inspection $50 - $75 FREE
Shipping $50 - $75 FREE
Warranty $10 Per Month= FREE
Sales Receipts $10 - $50&nbs= p; FREE
Fraud Screening

$=2E50 - $1=2E00
Per Transaction

 FREE
Amex Set Up $50 - $75 FREE
24 Hour Help Line $10 Month FREE
Security Bond $5000- $10,00= 0
Or More		 NONE

This is a No Obligation Qualification Form and is your first step to accepting credit cards=2E By filling out this form you will= "not enter" in to any obligations o= r contracts with us=2E We will use it to determine the best p= rogram to offer you based on the information you provide=2E You will be c= ontacted by one of our representatives within 1-2 business days to go over = the rest of your account set up=2E

<= font color=3D"#cc0000">Note:  All Information Provided To Us Will Remain= 100% Confidential !! 

Apply Free With No Risk!

Pleas= e fill out the express application form completely=2E
Incomplete information m= ay prevent us from properly processing your application=2E
Your Full Emai= l Address:
be sure to use your full address (i= =2Ee=2E user@domain=2Ecom)
Your Name:
Business Name:=
Business Phone= Number:
Home Phone Num= ber:
Type of Busine= ss:
Retail Business
Mail Order Business
Internet Based Busines= s
Personal Credi= t Rating:
Excellent
Good
Fair
Poor
How Soon Would= You Like a Merchant Account?


Your info= rmation is confidential, it will not be sold or used for any other purpose,= and you are under no obligation=2E Your information will be used solely for the purpose of evaluating= your business or website for a merchant account so that you may begin acce= pting credit card payments=2E


List Removal/OPT-OUT Option
Click Herem ------=_NextPart_001_0080_01BDF6C7.FABAC1B0-- ------=_NextPart_000_007F_01BDF6C7.FABAC1B0-- From nfs4-wg-request@sunroof.eng.sun.com Fri Sep 14 15:51:35 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA25442 for ; Fri, 14 Sep 2001 15:51:35 -0400 (EDT) Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA07165; Fri, 14 Sep 2001 13:51:01 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA29244; Fri, 14 Sep 2001 10:48:39 -0700 (PDT) Received: from d-mpk17-86-138.eng.sun.com (d-mpk17-86-138 [129.146.86.138]) by sunroof.eng.sun.com (8.12.0+Sun/8.12.0) with ESMTP id f8EHm37D002281 for ; Fri, 14 Sep 2001 10:48:04 -0700 (PDT) Received: (from shepler@localhost) by d-mpk17-86-138.eng.sun.com (8.11.3+Sun/8.11.3) id f8DKniU00683; Thu, 13 Sep 2001 15:49:44 -0500 (CDT) Date: Thu, 13 Sep 2001 15:49:44 -0500 From: Spencer Shepler To: peter@cendio.se Cc: nfsv4-wg@sunroof.eng.sun.com Subject: Re: UDP retransmission policies Message-ID: <20010913154944.M514@d-mpk17-86-138.eng.sun.com> Reply-To: shepler@eng.sun.com Mail-Followup-To: Spencer Shepler , peter@cendio.se, nfsv4-wg@sunroof.eng.sun.com References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.3.19i On Wed, Peter ?strand wrote: > > RFC1831 says: > > "It is important to point out that RPC does not try to implement any kind > of reliability and that the application may need to be aware of the type > of transport protocol underneath RPC. If it knows it is running on top of > a reliable transport such as TCP [6], then most of the work is already > done for it. On the other hand, if it is running on top of an unreliable > transport such as UDP [7], it must implement its own time-out, > retransmission, and duplicate detection policies as the RPC protocol does > not provide these services." > > What policies does NFSv4 use for retransmissions etc? I cannot find this > information in 3010. > The only statements about transport usage is in section 3.1. "The transport used by the RPC service for the NFS version 4 protocol MUST provide congestion control comparable to that defined for TCP in [RFC2581]. If the operating environment implements TCP, the NFS version 4 protocol SHOULD be supported over TCP. The NFS client and server may use other transports if they support congestion control as defined above and in those cases a mechanism may be provided to override TCP usage in favor of another transport." As long as the client follows the above, the implementation is allowed to retransmit its requests as it sees fit. Most current implementations of v2/v3 use a simple backoff for retransmits. -- - Spencer - From nfs4-wg-request@sunroof.eng.sun.com Fri Sep 14 17:46:47 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA26984 for ; Fri, 14 Sep 2001 17:46:46 -0400 (EDT) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA29530; Fri, 14 Sep 2001 15:46:13 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA15225; Fri, 14 Sep 2001 14:45:34 -0700 (PDT) Received: from jurassic.eng.sun.com (jurassic [129.146.89.31] (may be forged)) by sunroof.eng.sun.com (8.12.0+Sun/8.12.0) with ESMTP id f8ELj67B003492 for ; Fri, 14 Sep 2001 14:45:06 -0700 (PDT) Received: from eng.sun.com (terra.Eng.Sun.COM [129.146.86.99]) by jurassic.eng.sun.com (8.12.0+Sun/8.12.0) with ESMTP id f8ELjQVi634340 for ; Fri, 14 Sep 2001 14:45:26 -0700 (PDT) Sender: Brent.Callaghan@eng.sun.com Message-ID: <3BA27A6C.6489923D@eng.sun.com> Date: Fri, 14 Sep 2001 14:45:16 -0700 From: Brent Organization: NFS Whackers X-Mailer: Mozilla 4.76C-CCK-MCD Netscape [en] (X11; U; SunOS 5.8 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: nfsv4-wg@sunroof.eng.sun.com Subject: Re: Delegation callbacks proposal References: <3B901A6B.BFDCF5D@eng.sun.com> <3B902D6E.F37646AB@eisler.com> <3B9D5406.34F5A5E2@eng.sun.com> <15265.59007.247626.818311@notabene.cse.unsw.edu.au> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Neil Brown wrote: > The NFSv4 protocol has two situations where a network address needs > to be communicated. > > There is this situation, which uses a netid and a "universal address", > and there is the fs_location attribute that uses a "server" name, > to be looked up in the DNS or using inet_addr(3). > I always thought it was unfortunate that you couldn't specify a port > number in the fs_location field, and thus have multiple servers running > with the one IP address, possibly serving different filesystems with > vastly different implementations (though I cannot actually find a > concrete use for this. "automounters" come to mind, as they run an > NFS service on a non-standard port, but they don't make for a strong > argument). It's true that NFS mount commands have a "port" option, and the NFS URL (RFC 2224) allows a port to be specified with the server hostname. One could argue that the replica list should simply be a list of URLs. There are rare instances where there's multiple NFS servers running on a host - though the default one normally lives on the "well known" port 2049. Yes, it's unfortunate that fs_locations doesn't provide a port option. > I note in your proposed solution the sentence: > > "If a dropped connection needs to be re-established, then client or > server must make a best effort to re-establish when needed." > > I'm not sure how the server would re-establish a connection. > Connecting to the client is quite different to sending an RPC request > up the connection that was established by the client (but that is > ofcourse the point). > You could suggest that if the client used a connection oriented > protocol, then it should listen on the same port that it sent the > SETCLIENTID request on. However that assumes that that makes sense in > a protocol-independant sense, and I'm not sure that it does. > As a (somewhat strained) example, imagine connecting to the server > over a Unix domain socket. I don't think that the client's end of the > connection has a name that can be used in a "connect" request by the > server. Right, I'm sure there are cases where the server is unable to restore a connection. The only hope then is that the client detect a failed connection and establish a new one before the server needs it for callbacks. Brent From nfs4-wg-request@sunroof.eng.sun.com Sat Sep 15 09:24:46 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA20054 for ; Sat, 15 Sep 2001 09:24:45 -0400 (EDT) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA06296; Sat, 15 Sep 2001 07:24:41 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id GAA06479; Sat, 15 Sep 2001 06:24:10 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.0+Sun/8.12.0) with ESMTP id f8FDNc7B004867; Sat, 15 Sep 2001 06:23:38 -0700 (PDT) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id GAA07040; Sat, 15 Sep 2001 06:24:00 -0700 (PDT) Received: from ntser1.newcity.com.tw (h17-210-66-214.newcity.com.tw [210.66.214.17] (may be forged)) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id GAA08792; Sat, 15 Sep 2001 06:23:48 -0700 (PDT) Message-Id: <200109151323.GAA08792@saturn.sun.com> Received: from host (10-120.024.popsite.net [66.19.6.120]) by ntser1.newcity.com.tw with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.1960.3) id S89RC2JV; Sat, 15 Sep 2001 21:24:51 +0800 From: "Pete Reed" Subject: Extremely Low # 653 To: home@saturn.sun.com X-Mailer: Microsoft Outlook Express 4.72.1712.3 X-MimeOLE: Produced By Microsoft MimeOLE VÐßD.1712.3 Mime-Version: 1.0 Date: Sat, 15 Sep 2001 09:01:28 -0500 Content-Type: multipart/mixed; boundary="----=_NextPart_000_007F_01BDF6C7.FABAC1B0" Content-Transfer-Encoding: 7bit This is a MIME Message ------=_NextPart_000_007F_01BDF6C7.FABAC1B0 Content-Type: multipart/alternative; boundary="----=_NextPart_001_0080_01BDF6C7.FABAC1B0" ------=_NextPart_001_0080_01BDF6C7.FABAC1B0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable ***** This is an HTML Message ! ***** ------=_NextPart_001_0080_01BDF6C7.FABAC1B0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

We will help you= get the mortgage loan you want! 

Whether a new home loan is what you seek or
to refinance your current h= ome loan at a lower interest rate and payment, we can help!

Mortgage rates haven't been this low in the last 12 months, take action no= w!
 Refinance your home with us and include all of those pesky credit card bil= ls or
use the extra cash for that pool you've always wanted=2E=2E=2E&nbs= p;

 Where others says NO, we say YES!!!
 Even if you have been turned down elsewhere, we can help! 

 Easy terms! Our mortgage referral service combines the
highest quality loans wi= th most economical rates and the easiest qualification!

 Take just 2 minutes to complete the following form=2E
 There is no obligation, all information is= kept strictly confidential, and you must be at least 18 years of age=2E Service available within the United States only=2E This service is fast an= d free=2E

 

Free information= request form:

Loan Application Form


= Please complete all the information below=2E
Our loan specialist will b= e contacting you at your convenience=2E
Thank You!

=
Please use your mouse to navigate between fields=2E Thank You=2E

<= td width=3D"282" background=3D"Greenbackground=2Ejpg"> * <= tr align=3D"center">
Your Full Name = *
Address *
City *
<= font size=3D"2" color=3D"#000000" face=3D"Arial, Helvetica,sans-serif"> = State(USA Only) * UNITED STATES= ONLY!
Zip/Postal Code= *
Home Phone *
Work Phone= *
Email Address *<= /td>
Best Time To Call
Do You Own Your Home? * Mobile Homes Do Not Qualif= y
Property Value =3D 50000)) { alert('Not Valid! Please enter the approximate = value of current property or property you wish to purchase \n (greater than= or equal to 50000) using only number characters - 0123456789'); this=2Efoc= us(); this=2Eselect(); return false; }"> * Please use numbers only
Property Type
<= font size=3D"2" color=3D"#000000" face=3D"Arial, Helvetica,sans-serif"> = Purchase Price * Please us= e numbers only

Year Acquired

 *
1st Mortgage-Balance Owed * Please use numbers o= nly (ex:45000) enter 0 for none
1st Mor= tgage-Interest Rate %
Is 1st Adjusta= ble or Fixed? *
Employer *
Monthly Gross&n= bsp;Household Income * Please use numbers only
2nd Mortgage Balance owed > *= Please use numbers only(ex:45000) enter= 0 for none
Amount You Wish To Borrow *
Credit Rating *
Monthly Debt * Please use numbers only
Loan Interested In *
 
<= p>Fast & Easy -You Are Done !

REMOVAL INSTRUCTIONS: This message is being sent to you in complianc= e with the current Federal legislation=2E You must have either posted an AD= to my FFA site, web-site, or requested information, or responded to one of= our email letters=2E If you do not want to receive further emails or any o= ther information from us, or you have received this mail in error, or for i= mmediate removal you may simply use reply on your email program with "= Remove from your mailing list#99221" in the subject=2E

------=_NextPart_001_0080_01BDF6C7.FABAC1B0-- ------=_NextPart_000_007F_01BDF6C7.FABAC1B0-- From nfs4-wg-request@sunroof.eng.sun.com Sun Sep 16 18:00:36 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA15694 for ; Sun, 16 Sep 2001 18:00:35 -0400 (EDT) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id QAA28298; Sun, 16 Sep 2001 16:00:30 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id PAA00476; Sun, 16 Sep 2001 15:00:10 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.0+Sun/8.12.0) with ESMTP id f8GLxc7B005776 for ; Sun, 16 Sep 2001 14:59:39 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA09341 for ; Sun, 16 Sep 2001 14:59:58 -0700 (PDT) From: zHomeLoans100@yahoo.co.uk Received: from inetsrv.aldemar.gr ([212.205.53.14]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with SMTP id QAA16224 for ; Sun, 16 Sep 2001 16:00:22 -0600 (MDT) Received: from 167x (unverified [63.180.7.38]) by inetsrv.aldemar.gr (EMWAC SMTPRS 0.83) with SMTP id ; Mon, 17 Sep 2001 00:52:01 +0300 Message-ID: <000078916f38$00004872$0000142d@109> To: Subject: We Have Mortgage Leaders Ready to Help You! 5165 Date: Sun, 16 Sep 2001 17:11:30 -0500 MIME-Version: 1.0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Priority: 1 X-MSMail-Priority: High Reply-To: unsubscribee@libero.it Content-Transfer-Encoding: quoted-printable Mortgage companies make you wait

Mortgage companies make you wait...They Demand to Interview you...
They Intimidate you...They Humiliate you...
And All of That is While They Decide If They Even Want to Do Business With= You...

We Turn the Tables on Them...=
Now, You're In Charge

Just Fill Out Our Simple Form and They Will = Have to Compete For Your Business...
CLICK HERE FOR FORM<= /strong>

We have hundreds of loan programs, including
  • Purchase <= /font>Loans
  • Refinance
  • Debt Consol= idation
  • Home Impro= vement 
  • Second Mort= gages
  • No Income V= erification

You will often be contacted with an= offer the very same day you fill out the form!

 

National Average Mortgage Rates

Program

Rates

Points

30 Yr Firm

7.00%

0.60%

15 Yr Firm

6.10%

0.55%

1 Yr Arm

5.80%

0.59%

Just Look at Today's R= ates!

You can save Thousands Of Dollars= over the course of your loan with just a 1/4 of 1% Drop in your rate!

CLICK HERE FOR FORM

 

To be Removed,= reply with the word Remove in Subject Line!

From nfs4-wg-request@sunroof.eng.sun.com Sun Sep 16 18:37:14 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA15874 for ; Sun, 16 Sep 2001 18:37:13 -0400 (EDT) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id QAA05562; Sun, 16 Sep 2001 16:35:15 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id PAA02369; Sun, 16 Sep 2001 15:35:07 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.0+Sun/8.12.0) with ESMTP id f8GMYb7B005809; Sun, 16 Sep 2001 15:34:37 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id PAA18707; Sun, 16 Sep 2001 15:34:57 -0700 (PDT) Received: from judo.wando.chonnam.kr ([210.178.40.1]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id QAA23276; Sun, 16 Sep 2001 16:35:40 -0600 (MDT) Received: from host (ts002d12.pro-ri.concentric.net [206.173.11.72]) by judo.wando.chonnam.kr (8.8.8H1/8.8.8) with ESMTP id GAA29968; Mon, 17 Sep 2001 06:58:15 +0900 (KST) Message-Id: <200109162158.GAA29968@judo.wando.chonnam.kr> From: "Wayne F. Koppler" Subject: A Free Listing #2F96 To: read@wando.chonnam.kr X-Mailer: Microsoft Outlook Express 4.72.1712.3 X-MimeOLE: Produced By Microsoft MimeOLE V=?EUC-KR?B?0N8=?=D.1712.3 Mime-Version: 1.0 Date: Sun, 16 Sep 2001 18:25:32 -0500 Content-Type: multipart/mixed; boundary="----=_NextPart_000_007F_01BDF6C7.FABAC1B0" Content-Transfer-Encoding: 8bit This is a MIME Message ------=_NextPart_000_007F_01BDF6C7.FABAC1B0 Content-Type: multipart/alternative; boundary="----=_NextPart_001_0080_01BDF6C7.FABAC1B0" ------=_NextPart_001_0080_01BDF6C7.FABAC1B0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable ***** This is an HTML Message ! ***** ------=_NextPart_001_0080_01BDF6C7.FABAC1B0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Executive Guild Membership ApplicationResponse-O-Matic Form

Dear Candidate,=A0

You have been selected as a potential candidate for a free listing in=A0<= br> the 2001 Edition of the International Executive Guild Registry=2E=A0
=
Please accept our congratulations for this coveted honor=2E=A0

As this edition is so important in view of the new millennium, the=A0
= International Executive Guild Registry will be published in two different= =A0
formats; the searchable CD-ROM and the Online Registry=2E=A0

Since inclusion can be considered recognition of your career position=A0<= br> and professionalism, each candidate is evaluated in keeping with high=A0<= br> standards of individual achievement=2E In light of this, the Internationa= l Executive
Guild thinks that you may make an interesting biographical subject=2E=A0<= br>
We look forward to your inclusion and appearance in the International=A0<= br> Executive Guild's Registry=2E Best wishes for your continued success=2E=A0=

International Executive Guild=A0
Listing Dept=2E=A0

If you wish to be removed from our list, please submit your request
at the bottom of this email=2E

International Executive Guild
Registration Form
(US and Canada Only)
Please fill out this form if you would like to be included on The International Executive Guild, For accuracy and publication purposes, please complete and send this form at the earliest opportunity=2E There is no charge or obligation to be listed on The International Executive Guild=2E
Your Name
Your Company
Title
Address
City
State or Province
Country
ZIP/Postal Code
Day Time Telephone
Home Phone
 (Not To Be Published)
Email

TO HELP US IN CONSIDERING YOUR APPLICATION, PLEASE TELL US A LITTLE ABOUT YOURSELF=2E=2E=2E
Your Business
(Financial Svcs, Banking, Computer Hardware, Software, Professional Svcs, Chemicals, Apparel, Aerospace, Food, Government, Utility, etc=2E)
Type of Organization
(M= fg, Dist/Wholesaler, Retailer, Law Firm,
Investment Bank, Commercial Bank, University,
Financial Consultants, Ad Agency, Contractor, Broker, etc=2E)
Your Business Expertise
(Corp=2EMgmt, Marketing, Civil Engineering,
Tax Law, Nuclear Physics, Database Development, Operations, Pathologist, Mortgage Banking, etc=2E)
Major Product Line
(Integrated Circuits, Commercial Aircraft, Adhesives, Cosmetics, Plastic Components, Snack Foods, etc=2E)


Note: Submitting this form= will be made by email, not by use of  www=2E  Confirmation of its de= livery is made by browsing your outgoing mail=2E

Thank you for filling in this form, we will contact you with more information=2E

List Removal
Click Here
------=_NextPart_001_0080_01BDF6C7.FABAC1B0-- ------=_NextPart_000_007F_01BDF6C7.FABAC1B0-- From nfs4-wg-request@sunroof.eng.sun.com Mon Sep 17 11:10:47 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA13697 for ; Mon, 17 Sep 2001 11:10:47 -0400 (EDT) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id IAA06785; Mon, 17 Sep 2001 08:10:04 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA08196; Mon, 17 Sep 2001 08:09:15 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.0+Sun/8.12.0) with ESMTP id f8HF8m7B006773 for ; Mon, 17 Sep 2001 08:08:48 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA04201 for ; Mon, 17 Sep 2001 08:09:06 -0700 (PDT) Received: from ztxmail05.ztx.compaq.com (ztxmail05.ztx.compaq.com [161.114.1.209]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id JAA14013 for ; Mon, 17 Sep 2001 09:09:48 -0600 (MDT) Received: by ztxmail05.ztx.compaq.com (Postfix, from userid 12345) id BDF9C1AE0; Mon, 17 Sep 2001 10:09:00 -0500 (CDT) Received: from mailrelay01.cce.cpqcorp.net (mailrelay01.cce.cpqcorp.net [16.47.68.171]) by ztxmail05.ztx.compaq.com (Postfix) with ESMTP id B285718EB; Mon, 17 Sep 2001 10:09:00 -0500 (CDT) Received: by mailrelay01.cce.cpqcorp.net (Postfix, from userid 12345) id 78AE69A8; Mon, 17 Sep 2001 10:09:00 -0500 (CDT) Received: from anw.zk3.dec.com (wasted.zk3.dec.com [16.140.32.3]) by mailrelay01.cce.cpqcorp.net (Postfix) with ESMTP id 07C96840; Mon, 17 Sep 2001 10:09:00 -0500 (CDT) Received: from localhost by anw.zk3.dec.com (8.9.3/1.1.22.2/08Sep98-0251PM) id LAA0000867387; Mon, 17 Sep 2001 11:08:59 -0400 (EDT) From: Eric Werme USG Message-Id: <200109171508.LAA0000867387@anw.zk3.dec.com> To: nfsv4-wg@sunroof.eng.sun.com Cc: Brent Subject: Re: Delegation callbacks proposal In-reply-to: Your message of "Fri, 14 Sep 2001 14:45:16 PDT." <3BA27A6C.6489923D@eng.sun.com> Date: Mon, 17 Sep 2001 11:08:59 -0400 X-Mts: smtp Neil Brown wrote: > I note in your proposed solution the sentence: > > "If a dropped connection needs to be re-established, then client or > server must make a best effort to re-establish when needed." > > I'm not sure how the server would re-establish a connection. > Connecting to the client is quite different to sending an RPC request > up the connection that was established by the client (but that is > ofcourse the point). > You could suggest that if the client used a connection oriented > protocol, then it should listen on the same port that it sent the > SETCLIENTID request on. However that assumes that that makes sense in > a protocol-independant sense, and I'm not sure that it does. > As a (somewhat strained) example, imagine connecting to the server > over a Unix domain socket. I don't think that the client's end of the > connection has a name that can be used in a "connect" request by the > server. Right, I'm sure there are cases where the server is unable to restore a connection. The only hope then is that the client detect a failed connection and establish a new one before the server needs it for callbacks. I just wandered through rfc 3010 and its May update. While I can find discussion about short leases and long leases, and notes that the server sets the lease time, I don't where it communicates that nor do I see notes on what lease times are to be used or implemention hints. What are people using? I occurred to me that NFS over TCP implementations generally close "idle" connections. Tru64's server checks once a minute for connections not used in the previous five. The client does something similar, but accelerates things if there are a lot of connections open. If lease hold times are less than that, the connections will automatically stay open. In addition, we could define "active" on both client and server to include active leases. Therefore, the only times the connection is not available for a callback is when either end is rebooted and, well, I guess leases have to be short enough to timeout before the server restarts and ends the grace period. (Is that right? No statd any more!) For UDP, I suppose the server could keep the client's port in stable storage along with other state if it uses that approach. I don't see a need yet to get the clients a well known port for requests or the callback. I'm not very concerned about firewall/NAT issues with UDP as the IETF insists on using transports with congestion control comparable to TCP. (Translation: you will use TCP over a public WAN.) UDP will still be useful in trusted LANs. -Ric Werme From nfs4-wg-request@sunroof.eng.sun.com Mon Sep 17 11:46:38 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA14273 for ; Mon, 17 Sep 2001 11:46:37 -0400 (EDT) Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA13966; Mon, 17 Sep 2001 09:45:48 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA20208; Mon, 17 Sep 2001 08:45:13 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.0+Sun/8.12.0) with ESMTP id f8HFif7B006823 for ; Mon, 17 Sep 2001 08:44:41 -0700 (PDT) Received: from venus.sun.com (venus.EBay.Sun.COM [129.150.69.5]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA16994 for ; Mon, 17 Sep 2001 08:44:59 -0700 (PDT) Received: from gnat.inet.org (inet.org [63.108.254.91] (may be forged)) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA29851 for ; Mon, 17 Sep 2001 08:44:58 -0700 (PDT) Received: from mosquito.inet.org (rja-laptop [10.30.34.139]) by gnat.inet.org (Postfix) with ESMTP id AF6068266E; Mon, 17 Sep 2001 11:44:47 -0400 (EDT) Message-Id: <5.1.0.14.2.20010917113642.01d88610@10.30.15.2> X-Sender: rja@10.30.15.2 X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Mon, 17 Sep 2001 11:38:22 -0400 To: Eric Werme USG From: RJ Atkinson Subject: Re: Delegation callbacks proposal Cc: nfsv4-wg@sunroof.eng.sun.com In-Reply-To: <200109171508.LAA0000867387@anw.zk3.dec.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" At 11:08 17/09/01, Eric Werme USG wrote: >I occurred to me that NFS over TCP implementations generally close "idle" >connections. This does NOT appear to be the case for the NFS/TCP implementations that are deployed around here (Aside: we have no DEC/Compaq systems now, nor will we anytime soon). The NFS/TCP implementations around here appear (from external view) to be using the long-standing TCP keep-alive mechanism. Ran From nfs4-wg-request@sunroof.eng.sun.com Mon Sep 17 13:50:48 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA17295 for ; Mon, 17 Sep 2001 13:50:48 -0400 (EDT) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA10297; Mon, 17 Sep 2001 11:49:57 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA21975; Mon, 17 Sep 2001 10:49:24 -0700 (PDT) Received: from phys-ha6nwka.ebay.sun.com (root@phys-ha6nwka.EBay.Sun.COM [129.149.1.82]) by sunroof.eng.sun.com (8.12.0+Sun/8.12.0) with ESMTP id f8HHmw7B006983 for ; Mon, 17 Sep 2001 10:48:58 -0700 (PDT) Received: from esun1as-be (esun1as-be.Central.Sun.COM [129.147.34.142]) by phys-ha6nwka.ebay.sun.com (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with SMTP id KAA14858 for ; Mon, 17 Sep 2001 10:49:11 -0700 (PDT) Message-ID: <492411247.1000749120153.JavaMail.robinson@ha6nwk.EBay.Sun.COM> Date: Mon, 17 Sep 2001 11:52:00 -0600 (MDT) From: David.Robinson@Sun.COM To: nfsv4-wg@sunroof.eng.sun.com Subject: Re: Delegation callbacks proposal Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Mailer: Sun(TM) Web Access 1.0 Content-Transfer-Encoding: 7bit An observation on the problem of firewalls and NATs with respect to v4 callbacks. If I recall my last reading of the RPC RFCs, an RPC connection between a client and a server allows the server to send RPC calls back to the client for execution. Use of this was discussed early in the v4 effort and discarded because many (if not all) RPC implementations do not implement this capability. However in the current debate there appears to be a lack of support for a complex solution to the "problem" Brent is outlining. As an alternative solution, NFSv4 can make a statement that servers MAY use the RPC feature to send "reverse" requests back to the client for callbacks. Those client and server implementations who wish to address Brent's problem can do so with virtually no overhead to the rest of the implementations. The RFC should also include that clients MUST gracefully respond to such a reverse request, which should be a trivial amount of code to write and easy to test in a bake-off. -David From nfs4-wg-request@sunroof.eng.sun.com Mon Sep 17 15:05:46 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA18432 for ; Mon, 17 Sep 2001 15:05:45 -0400 (EDT) Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA16286; Mon, 17 Sep 2001 13:04:55 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA14271; Mon, 17 Sep 2001 12:04:42 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.0+Sun/8.12.0) with ESMTP id f8HJ4B7B007234 for ; Mon, 17 Sep 2001 12:04:11 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA09161 for ; Mon, 17 Sep 2001 12:04:29 -0700 (PDT) Received: from ztxmail04.ztx.compaq.com (ztxmail04.ztx.compaq.com [161.114.1.208]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA15894 for ; Mon, 17 Sep 2001 13:04:21 -0600 (MDT) Received: by ztxmail04.ztx.compaq.com (Postfix, from userid 12345) id AE26D273F; Mon, 17 Sep 2001 14:04:28 -0500 (CDT) Received: from mailrelay01.cac.cpqcorp.net (mailrelay01.cac.cpqcorp.net [16.47.132.152]) by ztxmail04.ztx.compaq.com (Postfix) with ESMTP id 866A72601; Mon, 17 Sep 2001 14:04:28 -0500 (CDT) Received: by mailrelay01.cac.cpqcorp.net (Postfix, from userid 12345) id 03BFEB87; Mon, 17 Sep 2001 12:04:27 -0700 (PDT) Received: from anw.zk3.dec.com (wasted.zk3.dec.com [16.140.32.3]) by mailrelay01.cac.cpqcorp.net (Postfix) with ESMTP id 7A97AA7E; Mon, 17 Sep 2001 12:04:27 -0700 (PDT) Received: from localhost by anw.zk3.dec.com (8.9.3/1.1.22.2/08Sep98-0251PM) id PAA0000946623; Mon, 17 Sep 2001 15:04:27 -0400 (EDT) From: Eric Werme USG Message-Id: <200109171904.PAA0000946623@anw.zk3.dec.com> To: David.Robinson@Sun.COM Cc: nfsv4-wg@sunroof.eng.sun.com Subject: Re: Delegation callbacks proposal In-reply-to: Your message of "Mon, 17 Sep 2001 11:52:00 MDT." <492411247.1000749120153.JavaMail.robinson@ha6nwk.EBay.Sun.COM> Date: Mon, 17 Sep 2001 15:04:26 -0400 X-Mts: smtp The RFC should also include that clients MUST gracefully respond to such a reverse request, which should be a trivial amount of code to write and easy to test in a bake-off. I don't think I'd agree, especially with UDP. IIRC, ONC-NFS's NFS client would allocate client handles, each bound to a separate local port number, send a request and then either put the handle on a free list or destroy it. The code only listened for messages when it was expecting a reply. If it wasn't expecting a reply but got one anyway (e.g. a response to a retransmitted request), that would sit on the socket until the handle was reused - there was nothing to wake up to process it. Changing things around from waiting for messages to return to a event driven "here's your next message" paradigm is not all that trivial. Well, maybe compared to NFSv4 it is, and it was worth the effort in Tru64, but it did take a couple passes to get right. -Ric Werme From nfs4-wg-request@sunroof.eng.sun.com Mon Sep 17 19:35:13 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA25109 for ; Mon, 17 Sep 2001 19:35:13 -0400 (EDT) Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id RAA06524; Mon, 17 Sep 2001 17:34:22 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id QAA28723; Mon, 17 Sep 2001 16:33:42 -0700 (PDT) Received: from jurassic.eng.sun.com (jurassic [129.146.86.38] (may be forged)) by sunroof.eng.sun.com (8.12.0+Sun/8.12.0) with ESMTP id f8HNX67B009112 for ; Mon, 17 Sep 2001 16:33:06 -0700 (PDT) Received: from eng.sun.com (terra.Eng.Sun.COM [129.146.86.99]) by jurassic.eng.sun.com (8.12.0+Sun/8.12.0) with ESMTP id f8HNXPVi139991 for ; Mon, 17 Sep 2001 16:33:25 -0700 (PDT) Sender: Brent.Callaghan@eng.sun.com Message-ID: <3BA6883C.D905AA24@eng.sun.com> Date: Mon, 17 Sep 2001 16:33:16 -0700 From: Brent Organization: NFS Whackers X-Mailer: Mozilla 4.76C-CCK-MCD Netscape [en] (X11; U; SunOS 5.8 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: nfsv4-wg@sunroof.eng.sun.com Subject: Re: Delegation callbacks proposal References: <492411247.1000749120153.JavaMail.robinson@ha6nwk.EBay.Sun.COM> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit David.Robinson@Sun.COM wrote: > > An observation on the problem of firewalls and NATs with respect > to v4 callbacks. If I recall my last reading of the RPC RFCs, an > RPC connection between a client and a server allows the server > to send RPC calls back to the client for execution. Use of this > was discussed early in the v4 effort and discarded because > many (if not all) RPC implementations do not implement this > capability. That's right. I don't know of any ONCRPC protocols that required callbacks - hence the feature has never been implemented. It's interesting to note that both Rx (the RPC of AFS) and SMB (used by CIFS) both support reverse calls on the same connection because their file access protocols require it. So, I'm inclined to believe that it's not in ONCRPC simply because it hasn't been needed up till now. > However in the current debate there appears to be a lack of support > for a complex solution to the "problem" Brent is outlining. As an > alternative solution, NFSv4 can make a statement that servers > MAY use the RPC feature to send "reverse" requests back to the > client for callbacks. Those client and server implementations > who wish to address Brent's problem can do so with virtually no > overhead to the rest of the implementations. The RFC should also > include that clients MUST gracefully respond to such a reverse > request, which should be a trivial amount of code to write and > easy to test in a bake-off. While I think passing an "in-protocol" address for callbacks is unnecessary and problematic for Internet performance, it would provide an "out" for client RPC implementations that are (for whatever reason) incapable of supporting reverse calls on an outgoing connection. We could provide a way for the client to notify the server that it expects callbacks via reverse RPC. For instance, in the cb_client4 address: struct clientaddr4 { /* see struct rpcb in RFC 1833 */ char *r_netid; /* network id */ char *r_addr; /* universal address */ } cb_client4; We could reserve an r_netid value to specify "Use reverse connection - ignore r_addr" Then, if after a bakeoff or two, we find that everyone is using this, we could vote on eliminating clientaddr4 altogether. Brent From nfs4-wg-request@sunroof.eng.sun.com Mon Sep 17 21:49:58 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA27683 for ; Mon, 17 Sep 2001 21:49:58 -0400 (EDT) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id TAA12097; Mon, 17 Sep 2001 19:49:08 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id SAA18882; Mon, 17 Sep 2001 18:48:59 -0700 (PDT) Received: from centralmail1.Central.Sun.COM (centralmail1.Central.Sun.COM [129.147.62.10]) by sunroof.eng.sun.com (8.12.0+Sun/8.12.0) with ESMTP id f8I1mV7B009341 for ; Mon, 17 Sep 2001 18:48:32 -0700 (PDT) Received: from dhcp-aus08-191.central.sun.com (dhcp-aus08-191.Central.Sun.COM [129.153.128.191]) by centralmail1.Central.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id TAA28964 for ; Mon, 17 Sep 2001 19:48:49 -0600 (MDT) Received: (from shepler@localhost) by dhcp-aus08-191.central.sun.com (8.11.3+Sun/8.11.3) id f8I1mca00924 for nfsv4-wg@sunroof.eng.sun.com; Mon, 17 Sep 2001 20:48:38 -0500 (CDT) Date: Mon, 17 Sep 2001 20:48:38 -0500 From: Spencer Shepler To: nfsv4-wg@sunroof.eng.sun.com Subject: Re: Delegation callbacks proposal Message-ID: <20010917204838.O400@dhcp-aus08-191.central.sun.com> Reply-To: shepler@eng.sun.com Mail-Followup-To: Spencer Shepler , nfsv4-wg@sunroof.eng.sun.com References: <3BA27A6C.6489923D@eng.sun.com> <200109171508.LAA0000867387@anw.zk3.dec.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200109171508.LAA0000867387@anw.zk3.dec.com> User-Agent: Mutt/1.3.19i On Mon, Eric Werme USG wrote: > > I just wandered through rfc 3010 and its May update. While I can find > discussion about short leases and long leases, and notes that the server > sets the lease time, I don't where it communicates that nor do I see notes > on what lease times are to be used or implemention hints. What are people > using? The server's lease period is communicated with the "lease_time" attribute; client is responsible for retrieving it via GETATTR. It is unclear to me that implementors have chosen a final value for the lease period. Something that we are still gaining experience with. Spencer From nfs4-wg-request@sunroof.eng.sun.com Mon Sep 17 21:50:39 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA27699 for ; Mon, 17 Sep 2001 21:50:39 -0400 (EDT) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id SAA06652; Mon, 17 Sep 2001 18:49:57 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id SAA18971; Mon, 17 Sep 2001 18:49:40 -0700 (PDT) Received: from centralmail2.Central.Sun.COM (centralmail2.Central.Sun.COM [129.147.62.11]) by sunroof.eng.sun.com (8.12.0+Sun/8.12.0) with ESMTP id f8I1nG7B009344 for ; Mon, 17 Sep 2001 18:49:16 -0700 (PDT) Received: from dhcp-aus08-191.central.sun.com (dhcp-aus08-191.Central.Sun.COM [129.153.128.191]) by centralmail2.Central.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id TAA22618 for ; Mon, 17 Sep 2001 19:49:34 -0600 (MDT) Received: (from shepler@localhost) by dhcp-aus08-191.central.sun.com (8.11.3+Sun/8.11.3) id f8I1nMY00931 for nfsv4-wg@sunroof.eng.sun.com; Mon, 17 Sep 2001 20:49:22 -0500 (CDT) Date: Mon, 17 Sep 2001 20:49:22 -0500 From: Spencer Shepler To: nfsv4-wg@sunroof.eng.sun.com Subject: Re: Delegation callbacks proposal Message-ID: <20010917204922.P400@dhcp-aus08-191.central.sun.com> Reply-To: shepler@eng.sun.com Mail-Followup-To: Spencer Shepler , nfsv4-wg@sunroof.eng.sun.com References: <5.1.0.14.2.20010917113642.01d88610@10.30.15.2> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5.1.0.14.2.20010917113642.01d88610@10.30.15.2> User-Agent: Mutt/1.3.19i On Mon, RJ Atkinson wrote: > At 11:08 17/09/01, Eric Werme USG wrote: > >I occurred to me that NFS over TCP implementations generally close "idle" > >connections. > > This does NOT appear to be the case for the NFS/TCP implementations > that are deployed around here (Aside: we have no DEC/Compaq systems now, > nor will we anytime soon). > > The NFS/TCP implementations around here appear (from external view) > to be using the long-standing TCP keep-alive mechanism. The Solaris client/server will close idle connections after a few minutes (5 and 6 I believe). -- - Spencer - From nfs4-wg-request@sunroof.eng.sun.com Mon Sep 17 21:54:08 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA27735 for ; Mon, 17 Sep 2001 21:54:08 -0400 (EDT) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id SAA07387; Mon, 17 Sep 2001 18:53:25 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id SAA19550; Mon, 17 Sep 2001 18:53:13 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.0+Sun/8.12.0) with ESMTP id f8I1ql7B009354 for ; Mon, 17 Sep 2001 18:52:47 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id SAA26007 for ; Mon, 17 Sep 2001 18:53:05 -0700 (PDT) Received: from mx01-a.netapp.com (mx01-a.netapp.com [198.95.226.53]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id TAA13552 for ; Mon, 17 Sep 2001 19:52:57 -0600 (MDT) Received: from frejya.corp.netapp.com (mh01 [10.10.20.91]) by mx01-a.netapp.com (8.11.1/8.11.1/NTAP-1.2) with ESMTP id f8I1rH929022; Mon, 17 Sep 2001 18:53:17 -0700 (PDT) Received: from cranford-fe.eng.netapp.com (localhost [127.0.0.1]) by frejya.corp.netapp.com (8.11.1/8.11.1/NTAP-1.2) with ESMTP id f8I1r3P29031; Mon, 17 Sep 2001 18:53:03 -0700 (PDT) Received: (from guy@localhost) by cranford-fe.eng.netapp.com (8.8.8+Sun/8.8.8) id SAA19220; Mon, 17 Sep 2001 18:53:03 -0700 (PDT) From: Guy Harris Message-Id: <200109180153.SAA19220@cranford-fe.eng.netapp.com> Subject: Re: Delegation callbacks proposal In-Reply-To: <20010917204922.P400@dhcp-aus08-191.central.sun.com> from Spencer Shepler at "Sep 17, 2001 08:49:22 pm" To: shepler@eng.sun.com Date: Mon, 17 Sep 2001 18:53:03 -0700 (PDT) CC: nfsv4-wg@sunroof.eng.sun.com X-Mailer: ELM [version 2.4ME++ PL59 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit > The Solaris client/server will close idle connections after a few > minutes (5 and 6 I believe). And the Data ONTAP server will close idle connections after 6 minutes. From nfs4-wg-request@sunroof.eng.sun.com Wed Sep 19 01:26:56 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA11963 for ; Wed, 19 Sep 2001 01:26:56 -0400 (EDT) Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id XAA02281; Tue, 18 Sep 2001 23:26:06 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id WAA18042; Tue, 18 Sep 2001 22:25:32 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.0+Sun/8.12.0) with ESMTP id f8J5PG7B012234 for ; Tue, 18 Sep 2001 22:25:16 -0700 (PDT) Received: from venus.sun.com (venus.EBay.Sun.COM [129.150.69.5]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id WAA13531 for ; Tue, 18 Sep 2001 22:25:17 -0700 (PDT) Received: from ns1 ([65.168.244.12]) by venus.sun.com (8.9.3+Sun/8.9.3) with SMTP id WAA22988 for ; Tue, 18 Sep 2001 22:25:17 -0700 (PDT) Message-Id: <200109190525.WAA22988@venus.sun.com> From: "Wayne" To: Subject: Free links, free seats Manuf. Prod/Contrl Software $1,495.00! Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Date: Tue, 18 Sep 2001 22:24:54 (ESP918)The Job Shop/Manufacturing software market has never seen an offer like this. For the next week only, Job Master, normally $2,495.00, is not only on sale for $1,495.00, but if you order by September 26, you'll also receive two user licenses and a link to either Peach Tree, QuickBooks or Excel at no charge, an additional thousand dollars savings. Job Master is designed specifically for small to medium sized manufacturers, and even at our regular price of $2,495.00 costs many thousands of dollars less than any other even remotely comparable software package. Now, if you order by September 26, you can save over $2,000.00. For our $1,495.00 special price, you receive not only Job Master at a thousand dollar discount, network ready, but two user licenses and a link to either Peach Tree, QuickBooks or Excel, which normally would be an additional charge of over a thousand dollars. If you've been waiting to upgrade your production control and tracking software or to computerize your operation, now is the time. For the next week, $1,495.00 gets you everything-Job Master network version, two user licenses, and a link to your accounting program or to Excel. (To reply by E Mail to this message or be removed from our list, Please go to the bottom of this message for an E Mail link. Please do not respond to us by hitting the "Reply" button. Our phone number is also located at the bottom of this message.) Job Master, a complete, user friendly Windows based software package, can manage and control your operation from sales quote to shipment. Following is a list of features. If you have any questions, would like to discuss the package further, or if you would like to obtain our Web site address for a total walk through of the program, please call me directly at (661) 286-0041. By way of background, we are a software company, which for some years has specialized in the development of custom software, primarily for small to medium sized manufacturers. Job Master is a distillation of over a million and a half dollars of software we have developed to control and manage the production of our manufacturing clients. Job Master contains the following features: 1. QUOTATION MODULE. In this module, quotes are developed, modified, and produced for sending to your client. A history is kept of all quotes for future reference, or modification for other clients. All quotations and revisions are "auto numbered," including versions. The quotes section allows for the entry of parts/processes, and costing of each, including materials, labor, markup, and taxes. Inventory status can be accessed from this section for reference. 2. SALES ORDER. Once a quotation is accepted, the final quotation information can be transformed into a Sales Order for your client's signature on a "point and click" basis. The Sales Order can be modified and re issued if necessary. A history if kept of all Sales Orders for future reference, or modification for other clients. All sales orders and revisions are "auto numbered," including versions. Inventory status can be accessed from this section for reference. 3. CUSTOMER LETTERS can be created from the Quotation and Sales Order sections. 4. SHOP TRAVELER/WORK ORDER. Once a Sales Order is accepted, the sales order information can be transformed into a shop traveler/work order on a "point and click" basis. Each item on the Sales Order becomes a shop traveler/work order, with each step of production of the item then listed on the traveler/work order. Each such traveler/work order is tied back into the Sales Order. The shop traveler/work order allows for the entry of line items, and notes on each line item. The shop traveler/work order contains a "notes" section. The Shop traveler/work order allows for the storing or attachment of drawings to the traveler/work order. The shop traveler/work order also contains a "drop down," from which standard processes can be selected for inclusion on the shop traveler/work order. The shop traveler/work order numbers progress in order of production sequence, and re numbers them if new steps are added. The shop traveler/work order allows for change orders or revisions, and numbers changes in sequence of the original shop traveler/work order number; i.e., 100, 100-1, 100-2, etc. All shop traveler/work orders and related revisions are retained in memory for future reference. The shop traveler/work order is bar coded for tracking of production step by step, and production of ongoing client status reports. Bar coding includes the ability for an employee to "swipe" their own ID bar code for recording in the system as to who upgraded what step. The shop traveler/work order function also allows for manual update of production status. The shop traveler/work order allows for quality control sign off, and the final production of certifications, either from a "canned" list, or hand typed in on a case by case basis. 5. INVENTORY. The application includes an inventory section, which allows operations to check materials inventory in and out. The inventory section allows for the comparison of inventory received against a P.O., and produces an "overage/underage" report of inventory received as compared against the P.O. The inventory section allows for the setting of minimum (re-order now!) and maximum inventory amounts, and produces reports showing what inventory needs to be ordered, as well as inventory that is at or above the maximum set to have in house. The inventory section also tracks "partially shipped" orders, which are tied in to the shipping function. This section shows how much completed product under a particular order has been actually shipped to a client, and how much remains to be shipped. The balance is adjusted as shipments are made. 6. REQUEST FOR PURCHASE. The application allows operators to produce a Request For Purchase for accounting for any inventory items, which need to be ordered. Inventory items have a drop down of approved vendors for each item. 7. REQUEST FOR BID. The application allows operators to produce a Request For Bid for accounting to send to Vendors for any inventory items, which need to be ordered. Inventory items have a drop down of approved vendors for each item to which Requests For Bid can be sent. 8. INVOICE. The application produces an invoice/invoice detail for all completed items ready to be billed/shipped to clients. 9. PRODUCTION OUTPUT STATUS. The application produces a date range selectable report on how much product, and the value of the product, which was completed during a selected date range. The application also produces a report on how many orders, and the value of those orders, which remain to be completed during a selected date range. 10. The application produces SHIPPING DOCUMENTS as per selected shippers, and produces a PACKING SLIP. 11. The application has a "FIND" FUNCTION in selected sections, allowing for searches by customer name, work order number, etc. 12. The application has "AUTO FILL;" i.e., when an operator starts to type in a name, number, etc. all related information auto fills after the first few letters or numbers are typed in. Job Master is currently being sold in the marketplace for $2,495.00 per package. However, if we receive your order by September 26, your total price will be $1,495.00 Again, if you have any questions at all, or would like to place your order, please call me on my direct line, (661) 286-0041. Thank you! Wayne Mcfarland Link It Software Corp. ------------------------------------------------------------------------------------------ This message is sent in compliance of the new e-mail bill: SECTION 301. Per Section 301, Paragraph (a)(2)(C) of S. 1618. To REPLY or be REMOVED from this solicitated email list, please click on the E Mail address following this message and type "REMOVE" or "REPLY" in the subject line: jbsptrsft22@yahoo.com ------------------------------------------------------------------------------------------- From nfs4-wg-request@sunroof.eng.sun.com Wed Sep 19 21:11:49 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA13311 for ; Wed, 19 Sep 2001 21:11:48 -0400 (EDT) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id SAA01167; Wed, 19 Sep 2001 18:11:07 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id RAA20000; Wed, 19 Sep 2001 17:48:08 -0700 (PDT) Received: from centralmail1.Central.Sun.COM (centralmail1.Central.Sun.COM [129.147.62.10]) by sunroof.eng.sun.com (8.12.0+Sun/8.12.0) with ESMTP id f8K0lv7B014445 for ; Wed, 19 Sep 2001 17:47:57 -0700 (PDT) Received: from dhcp-aus08-191.central.sun.com (dhcp-aus08-191.Central.Sun.COM [129.153.128.191]) by centralmail1.Central.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id SAA17557 for ; Wed, 19 Sep 2001 18:47:59 -0600 (MDT) Received: (from shepler@localhost) by dhcp-aus08-191.central.sun.com (8.11.3+Sun/8.11.3) id f8K0lk300984 for nfsv4-wg@sunroof.eng.sun.com; Wed, 19 Sep 2001 19:47:46 -0500 (CDT) Date: Wed, 19 Sep 2001 19:47:46 -0500 From: Spencer Shepler To: nfsv4-wg@sunroof.eng.sun.com Subject: Issues list for RFC3010 Message-ID: <20010919194746.F398@dhcp-aus08-191.central.sun.com> Reply-To: shepler@eng.sun.com Mail-Followup-To: Spencer Shepler , nfsv4-wg@sunroof.eng.sun.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.19i I have an updated issues list at: http://www.nfsv4.org/rfc3010updates/issues.html Updates will follow. -- - Spencer - From nfs4-wg-request@sunroof.eng.sun.com Wed Sep 19 21:30:39 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA13509 for ; Wed, 19 Sep 2001 21:30:38 -0400 (EDT) Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id TAA23979; Wed, 19 Sep 2001 19:29:48 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id SAA02959; Wed, 19 Sep 2001 18:29:30 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.0+Sun/8.12.0) with ESMTP id f8K1TI7B014740 for ; Wed, 19 Sep 2001 18:29:18 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id SAA13095 for ; Wed, 19 Sep 2001 18:29:18 -0700 (PDT) Received: from mx01-a.netapp.com (mx01-a.netapp.com [198.95.226.53]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id TAA09305 for ; Wed, 19 Sep 2001 19:30:08 -0600 (MDT) Received: from hawk.corp.netapp.com (mh02 [10.10.20.101]) by mx01-a.netapp.com (8.11.1/8.11.1/NTAP-1.2) with ESMTP id f8K1TV912434; Wed, 19 Sep 2001 18:29:31 -0700 (PDT) Received: from ussvlexc01.corp.netapp.com (localhost [127.0.0.1]) by hawk.corp.netapp.com (8.11.1/8.11.1/NTAP-1.2) with ESMTP id f8K1THO12091; Wed, 19 Sep 2001 18:29:17 -0700 (PDT) Received: by ussvlexc01.corp.netapp.com with Internet Mail Service (5.5.2653.19) id ; Wed, 19 Sep 2001 18:28:39 -0700 Message-ID: <6440EA1A6AA1D5118C6900902745938E5F579E@black.eng.netapp.com> From: "Khan, Saadia" To: "'shepler@eng.sun.com'" , nfsv4-wg@sunroof.eng.sun.com Cc: "Khan, Saadia" Subject: RE: Issues list for RFC3010 Date: Wed, 19 Sep 2001 18:29:16 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain I would like to add some more things to the list which are not very clear as far as the spec goes: Named Attributes: 1. Does it make sense to allow setattr on a named attribute dir? Is that allowed in the spec? And if so what does it mean if the named attr dir has different perms, uid, gid from the base file and in that case which one is used for permission checking? In similar context, does it make sense to do the same for named attributes? Or does changing perms, uid, gid for a named attribute change the perms, uid, gid for the base file. 2. Currently a server is required to first check if a named attribute dir associated with a file/dir actually contains any named attributes before returning TRUE in the named_attr field for getattr. There can be a couple of issues with that. First its very improbable to have a named attr dir without any named attrs, and second it is possible that a client is requesting the server for all supported attributes every time it does a stat call. It can be very expensive for the server to check if the directory is empty or not everytime it gets one of these calls. It should be sufficient for the server to check if the dir exists and return TRUE for named_attr. 3.Should exclusive create be supported for named attributes? 4. Does it make sense to rename a named attribute? I dont think it makes sense to rename a named attribute between different base files. Within the same file, maybe but even that doesn't make much sense. 5. Does the spec support deleting the named attribute dir? I think that deleting a file with named attributes should delete everything with it, including the dir and all named attributes or the client should be allowed to delete a single attr. But allowing a named attr dir to be deleted without deleting the base file doesn't really make much sense. thanks, Saadia -----Original Message----- From: Spencer Shepler [mailto:shepler@eng.sun.com] Sent: Wednesday, September 19, 2001 5:48 PM To: nfsv4-wg@sunroof.eng.sun.com Subject: Issues list for RFC3010 I have an updated issues list at: http://www.nfsv4.org/rfc3010updates/issues.html Updates will follow. -- - Spencer - From nfs4-wg-request@sunroof.eng.sun.com Thu Sep 20 09:26:24 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA09222 for ; Thu, 20 Sep 2001 09:26:24 -0400 (EDT) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id GAA27076; Thu, 20 Sep 2001 06:25:44 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id GAA13935; Thu, 20 Sep 2001 06:25:20 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.0+Sun/8.12.0) with ESMTP id f8KDP57B015360 for ; Thu, 20 Sep 2001 06:25:05 -0700 (PDT) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id GAA13922 for ; Thu, 20 Sep 2001 06:25:07 -0700 (PDT) Received: from tor01x3.hcl.com ([199.71.120.7]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id GAA02143 for ; Thu, 20 Sep 2001 06:25:06 -0700 (PDT) Received: from av0011 (av0011.hcl.com [10.1.42.240]) by tor01x3.hcl.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id SKT2HTKR; Thu, 20 Sep 2001 09:25:05 -0400 Received: FROM null.hcl.com BY av0011 ; Thu Sep 20 09:25:26 2001 -0400 Received: from sergeylt (sergeylt.hcl.com [10.1.14.29]) by null.hcl.com (8.11.2/8.11.3) with SMTP id f8KDP5B14341; Thu, 20 Sep 2001 09:25:05 -0400 (EDT) From: "Sergey Klyushin" To: , Subject: RE: Issues list for RFC3010 Date: Thu, 20 Sep 2001 09:25:31 -0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 In-Reply-To: <20010919194746.F398@dhcp-aus08-191.central.sun.com> Content-Transfer-Encoding: 7bit For easier processing of COMPOUND requests, I would like to propose minor protocol changes. The idea is to set "int" type parameters before "opaque" in arguments and results. There are not much such structures, and I believe it's not too late to change .x file. I found following structures (based on RFC 3010 draft-ietf-nfsv4-07) struct CREATE4args { createtype4 objtype; component4 objname; }; struct LOCK4denied { offset4 offset; length4 length; nfs_lockowner4 owner; }; struct LOCKT4args { nfs_lock_type4 locktype; offset4 offset; length4 length; nfs_lockowner4 owner; }; struct OPEN4args { seqid4 seqid; uint32_t share_access; uint32_t share_deny; nfs_lockowner4 owner; openflag4 openhow; open_claim4 claim; }; struct open_claim_delegate_cur4 { stateid4 delegate_stateid; pathname4 file; }; Sergey > -----Original Message----- > From: Spencer Shepler [mailto:shepler@eng.sun.com] > Sent: Wednesday, September 19, 2001 8:48 PM > To: nfsv4-wg@sunroof.eng.sun.com > Subject: Issues list for RFC3010 > > > > I have an updated issues list at: > > http://www.nfsv4.org/rfc3010updates/issues.html > > Updates will follow. > > -- > > - Spencer - > > From nfs4-wg-request@sunroof.eng.sun.com Thu Sep 20 11:36:56 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA13598 for ; Thu, 20 Sep 2001 11:36:56 -0400 (EDT) Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id IAA29501; Thu, 20 Sep 2001 08:36:15 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA20357; Thu, 20 Sep 2001 08:31:43 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.0+Sun/8.12.0) with ESMTP id f8KFVT7B015770 for ; Thu, 20 Sep 2001 08:31:29 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA20284 for ; Thu, 20 Sep 2001 08:31:30 -0700 (PDT) Received: from tor01x3.hcl.com ([199.71.120.7]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id JAA03435 for ; Thu, 20 Sep 2001 09:32:20 -0600 (MDT) Received: from av0011 (av0011.hcl.com [10.1.42.240]) by tor01x3.hcl.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id SKT22AVD; Thu, 20 Sep 2001 11:30:41 -0400 Received: FROM null.hcl.com BY av0011 ; Thu Sep 20 11:31:01 2001 -0400 Received: from sergeylt (sergeylt.hcl.com [10.1.14.29]) by null.hcl.com (8.11.2/8.11.3) with SMTP id f8KFUZB18288; Thu, 20 Sep 2001 11:30:36 -0400 (EDT) From: "Sergey Klyushin" To: , Subject: RE: Issues list for RFC3010 Date: Thu, 20 Sep 2001 11:31:01 -0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 In-Reply-To: <20010919194746.F398@dhcp-aus08-191.central.sun.com> Content-Transfer-Encoding: 7bit >Issue03: >OPEN(CREATE); add NFS4ERR_ISDIR for the case the name to create is a directory (not a regular file). >Issue04: >OPEN(NOCREATE); add NFS4ERR_NOENT for the no entry case. Should NFS4ERR_ISDIR be used in case OPEN(NOCREATE) and the name to create is a directory? Sergey > -----Original Message----- > From: Spencer Shepler [mailto:shepler@eng.sun.com] > Sent: Wednesday, September 19, 2001 8:48 PM > To: nfsv4-wg@sunroof.eng.sun.com > Subject: Issues list for RFC3010 > > > > I have an updated issues list at: > > http://www.nfsv4.org/rfc3010updates/issues.html > > Updates will follow. > > -- > > - Spencer - > > From nfs4-wg-request@sunroof.eng.sun.com Thu Sep 20 11:47:46 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA13854 for ; Thu, 20 Sep 2001 11:47:45 -0400 (EDT) Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA12462; Thu, 20 Sep 2001 09:46:57 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA24728; Thu, 20 Sep 2001 08:46:03 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.0+Sun/8.12.0) with ESMTP id f8KFjo7B015779 for ; Thu, 20 Sep 2001 08:45:50 -0700 (PDT) Received: from venus.sun.com (venus.EBay.Sun.COM [129.150.69.5]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA13321 for ; Thu, 20 Sep 2001 08:45:51 -0700 (PDT) Received: from tor01x3.hcl.com ([199.71.120.7]) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA08275 for ; Thu, 20 Sep 2001 08:45:49 -0700 (PDT) Received: from av0011 (av0011.hcl.com [10.1.42.240]) by tor01x3.hcl.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id SKT22DCD; Thu, 20 Sep 2001 11:40:46 -0400 Received: FROM null.hcl.com BY av0011 ; Thu Sep 20 11:41:07 2001 -0400 Received: from sergeylt (sergeylt.hcl.com [10.1.14.29]) by null.hcl.com (8.11.2/8.11.3) with SMTP id f8KFelB22561; Thu, 20 Sep 2001 11:40:47 -0400 (EDT) From: "Sergey Klyushin" To: , Subject: RE: Issues list for RFC3010 Date: Thu, 20 Sep 2001 11:41:12 -0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 In-Reply-To: <20010919194746.F398@dhcp-aus08-191.central.sun.com> Content-Transfer-Encoding: 7bit >Issue08: >Change of "tag" in COMPOUND4args. At a minimum the server should return the same tag length/contents that were >included in the request. Alternate changes are: fixed length tag or no tag at all. I vote to remove "tag" at all. If it used for debugging - use snoop, if it used for caching - use something else (xids from RPC) Sergey > -----Original Message----- > From: Spencer Shepler [mailto:shepler@eng.sun.com] > Sent: Wednesday, September 19, 2001 8:48 PM > To: nfsv4-wg@sunroof.eng.sun.com > Subject: Issues list for RFC3010 > > > > I have an updated issues list at: > > http://www.nfsv4.org/rfc3010updates/issues.html > > Updates will follow. > > -- > > - Spencer - > > From nfs4-wg-request@sunroof.eng.sun.com Thu Sep 20 12:26:33 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA14930 for ; Thu, 20 Sep 2001 12:26:33 -0400 (EDT) Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id JAA28073; Thu, 20 Sep 2001 09:25:40 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA03055; Thu, 20 Sep 2001 09:16:52 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.0+Sun/8.12.0) with ESMTP id f8KGGR7B015803 for ; Thu, 20 Sep 2001 09:16:27 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA20167 for ; Thu, 20 Sep 2001 09:16:28 -0700 (PDT) Received: from mx01-a.netapp.com (mx01-a.netapp.com [198.95.226.53]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id KAA02187 for ; Thu, 20 Sep 2001 10:17:17 -0600 (MDT) Received: from hawk.corp.netapp.com (mh02 [10.10.20.101]) by mx01-a.netapp.com (8.11.1/8.11.1/NTAP-1.2) with ESMTP id f8KGGf907769; Thu, 20 Sep 2001 09:16:42 -0700 (PDT) Received: from ussvlexc06.corp.netapp.com (localhost [127.0.0.1]) by hawk.corp.netapp.com (8.11.1/8.11.1/NTAP-1.2) with ESMTP id f8KGGRt06007; Thu, 20 Sep 2001 09:16:27 -0700 (PDT) Received: by ussvlexc06.corp.netapp.com with Internet Mail Service (5.5.2653.19) id ; Thu, 20 Sep 2001 09:16:26 -0700 Message-ID: <8C610D86AF6CD4119C9800B0D0499E33335611@red.nane.netapp.com> From: "Noveck, Dave" To: "'Sergey Klyushin'" , shepler@eng.sun.com, nfsv4-wg@sunroof.eng.sun.com Subject: RE: Issues list for RFC3010 Date: Thu, 20 Sep 2001 09:16:25 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Even if we keep tag, and I hope we don't, you should never use it for caching. The spec places no requirements at all on what the client may put in the tag and thus the server should not draw any conclusions from the fact that two requests have the same tag or different tags. I would expect that if tags remain as they are, many clients will save cycles, space, and bandwidth by always sending the minimal tag (a null tag consisting of four zero bytes) on all requests. -----Original Message----- From: Sergey Klyushin [mailto:Sergey.Klyushin@hummingbird.com] Sent: Thursday, September 20, 2001 11:41 AM To: shepler@eng.sun.com; nfsv4-wg@sunroof.eng.sun.com Subject: RE: Issues list for RFC3010 >Issue08: >Change of "tag" in COMPOUND4args. At a minimum the server should return the same tag length/contents that were >included in the request. Alternate changes are: fixed length tag or no tag at all. I vote to remove "tag" at all. If it used for debugging - use snoop, if it used for caching - use something else (xids from RPC) Sergey > -----Original Message----- > From: Spencer Shepler [mailto:shepler@eng.sun.com] > Sent: Wednesday, September 19, 2001 8:48 PM > To: nfsv4-wg@sunroof.eng.sun.com > Subject: Issues list for RFC3010 > > > > I have an updated issues list at: > > http://www.nfsv4.org/rfc3010updates/issues.html > > Updates will follow. > > -- > > - Spencer - > > From nfs4-wg-request@sunroof.eng.sun.com Thu Sep 20 12:44:12 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA15426 for ; Thu, 20 Sep 2001 12:44:11 -0400 (EDT) Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id JAA07822; Thu, 20 Sep 2001 09:43:26 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA09573; Thu, 20 Sep 2001 09:42:18 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.0+Sun/8.12.0) with ESMTP id f8KGg47B015829 for ; Thu, 20 Sep 2001 09:42:04 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA16219 for ; Thu, 20 Sep 2001 09:42:05 -0700 (PDT) Received: from tor01x3.hcl.com ([199.71.120.7]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id KAA16505 for ; Thu, 20 Sep 2001 10:42:52 -0600 (MDT) Received: from av0011 (av0011.hcl.com [10.1.42.240]) by tor01x3.hcl.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id SKT22M4Z; Thu, 20 Sep 2001 12:41:58 -0400 Received: FROM null.hcl.com BY av0011 ; Thu Sep 20 12:42:19 2001 -0400 Received: from sergeylt (sergeylt.hcl.com [10.1.14.29]) by null.hcl.com (8.11.2/8.11.3) with SMTP id f8KGfxB12652; Thu, 20 Sep 2001 12:41:59 -0400 (EDT) From: "Sergey Klyushin" To: , Subject: RE: Issues list for RFC3010 Date: Thu, 20 Sep 2001 12:42:24 -0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 In-Reply-To: <20010919194746.F398@dhcp-aus08-191.central.sun.com> Content-Transfer-Encoding: 7bit >Issue03: >OPEN(CREATE); add NFS4ERR_ISDIR for the case the name to create is a directory (not a regular file). Should we add the same error to CREATE? I mean if target for CREATE(not dir) exists and target is directory. Should we add NFS4ERR_ISDIR to all operations that reference to file (WRITE, etc.)? >Issue11: >SETCLIENTID_CONFIRM should use clientid and verifier instead of just the verifier >Issue15: >OPEN_CONFIRM should take the stateid along with the seqid and confirm verifier Do we really need both clientid (stateid+seqid) and verifier? Why just clientid (stateid+seqid) is not enough? >Issue19: >Attributes for OPEN(CREATE). The suggestion has been made to add an attributes parameter for OPEN(CREATE) of a regular file so that the client would not have to use a subsequent SETATTR to obtain the desired attribute settings. Do you mean OPEN or CREATE? OPEN already has attributes, but CREATE doesn't. From my point of view, CREATE should also take attributes to set (at least for directory and symlink) and return bitmap of what attributes were set >Issue14: >Introduce method that allows client to determine if server is supporting POSIX-style file locking or "strict" file locking. Two apparent choices: add new attribute or return the information as a bit in the results flags field (rflags) in OPEN4resok. I think NFSv4 protocol should say in more details what means "POSIX-style file locking or "strict" file locking" >Issue16: >Should a value be added to the fh_expire_type attribute to allow the server to signify that for replicated filesystems the filehandles are the same between servers. It will be very useful for NT. NT won't include this flag to signify that file handles are different, but other OS could set this flag and make life of NFS Client much easy >Issue25: >Should the "filehandle" attribute be mandatory? Yes. Almost all operations use current filehandle. What could be done without filehandle? >Issue32: >Section 8.9 states that the server MUST return an error if CLOSE would result in having locks exist after the CLOSE operation. What error is supposed to be used? Also what error should be returned if server can't close file with outstanding locks? >Issue33: >LINK operation needs the NFS4ERR_NOENT added as possible error return. What error should be returned on "ln f1 f2" request, if f1 and f2 are already hard linked? > -----Original Message----- > From: Spencer Shepler [mailto:shepler@eng.sun.com] > Sent: Wednesday, September 19, 2001 8:48 PM > To: nfsv4-wg@sunroof.eng.sun.com > Subject: Issues list for RFC3010 > > > > I have an updated issues list at: > > http://www.nfsv4.org/rfc3010updates/issues.html > > Updates will follow. > > -- > > - Spencer - > > From nfs4-wg-request@sunroof.eng.sun.com Thu Sep 20 13:39:48 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA17144 for ; Thu, 20 Sep 2001 13:39:47 -0400 (EDT) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id KAA08671; Thu, 20 Sep 2001 10:39:05 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA01784; Thu, 20 Sep 2001 10:37:19 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.0+Sun/8.12.0) with ESMTP id f8KHb67B016133 for ; Thu, 20 Sep 2001 10:37:07 -0700 (PDT) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA01685 for ; Thu, 20 Sep 2001 10:37:06 -0700 (PDT) Received: from mx01-a.netapp.com (mx01-a.netapp.com [198.95.226.53]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA23973 for ; Thu, 20 Sep 2001 10:37:06 -0700 (PDT) Received: from hawk.corp.netapp.com (mh02 [10.10.20.101]) by mx01-a.netapp.com (8.11.1/8.11.1/NTAP-1.2) with ESMTP id f8KHb5913449; Thu, 20 Sep 2001 10:37:20 -0700 (PDT) Received: from ussvlexc01.corp.netapp.com (localhost [127.0.0.1]) by hawk.corp.netapp.com (8.11.1/8.11.1/NTAP-1.2) with ESMTP id f8KHaom00398; Thu, 20 Sep 2001 10:36:50 -0700 (PDT) Received: by ussvlexc01.corp.netapp.com with Internet Mail Service (5.5.2653.19) id ; Thu, 20 Sep 2001 10:34:39 -0700 Message-ID: <6440EA1A6AA1D5118C6900902745938E5F579F@black.eng.netapp.com> From: "Khan, Saadia" To: "'nfsv4-wg@sunroof.eng.sun.com'" , "'shepler@eng.sun.com'" Subject: RE: Issues list for RFC3010 Date: Thu, 20 Sep 2001 10:35:16 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain -----Original Message----- From: Khan, Saadia Sent: Wednesday, September 19, 2001 6:29 PM To: 'shepler@eng.sun.com'; nfsv4-wg@sunroof.eng.sun.com Cc: Khan, Saadia Subject: RE: Issues list for RFC3010 I would like to add some more things to the list which are not very clear as far as the spec goes: Named Attributes: 1. Does it make sense to allow setattr on a named attribute dir? Is that allowed in the spec? And if so what does it mean if the named attr dir has different perms, uid, gid from the base file and in that case which one is used for permission checking? In similar context, does it make sense to do the same for named attributes? Or does changing perms, uid, gid for a named attribute change the perms, uid, gid for the base file. 2. Currently a server is required to first check if a named attribute dir associated with a file/dir actually contains any named attributes before returning TRUE in the named_attr field for getattr. There can be a couple of issues with that. First its very improbable to have a named attr dir without any named attrs, and second it is possible that a client is requesting the server for all supported attributes every time it does a stat call. It can be very expensive for the server to check if the directory is empty or not everytime it gets one of these calls. It should be sufficient for the server to check if the dir exists and return TRUE for named_attr. 3.Should exclusive create be supported for named attributes? 4. Does it make sense to rename a named attribute? I dont think it makes sense to rename a named attribute between different base files. Within the same file, maybe but even that doesn't make much sense. 5. Does the spec support deleting the named attribute dir? I think that deleting a file with named attributes should delete everything with it, including the dir and all named attributes or the client should be allowed to delete a single attr. But allowing a named attr dir to be deleted without deleting the base file doesn't really make much sense. thanks, Saadia -----Original Message----- From: Spencer Shepler [mailto:shepler@eng.sun.com] Sent: Wednesday, September 19, 2001 5:48 PM To: nfsv4-wg@sunroof.eng.sun.com Subject: Issues list for RFC3010 I have an updated issues list at: http://www.nfsv4.org/rfc3010updates/issues.html Updates will follow. -- - Spencer - From nfs4-wg-request@sunroof.eng.sun.com Thu Sep 20 15:29:01 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA19680 for ; Thu, 20 Sep 2001 15:29:00 -0400 (EDT) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA27151; Thu, 20 Sep 2001 13:28:11 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA14520; Thu, 20 Sep 2001 12:27:50 -0700 (PDT) Received: from centralmail1.Central.Sun.COM (centralmail1.Central.Sun.COM [129.147.62.10]) by sunroof.eng.sun.com (8.12.0+Sun/8.12.0) with ESMTP id f8KJRc7B016403 for ; Thu, 20 Sep 2001 12:27:38 -0700 (PDT) Received: from dhcp-aus08-191.central.sun.com (dhcp-aus08-191.Central.Sun.COM [129.153.128.191]) by centralmail1.Central.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id NAA18496 for ; Thu, 20 Sep 2001 13:27:39 -0600 (MDT) Received: (from shepler@localhost) by dhcp-aus08-191.central.sun.com (8.11.3+Sun/8.11.3) id f8KJRQD00492 for nfsv4-wg@sunroof.eng.sun.com; Thu, 20 Sep 2001 14:27:26 -0500 (CDT) Date: Thu, 20 Sep 2001 14:27:26 -0500 From: Spencer Shepler To: nfsv4-wg@sunroof.eng.sun.com Subject: Re: Issues list for RFC3010 Message-ID: <20010920142726.M399@dhcp-aus08-191.central.sun.com> Reply-To: shepler@eng.sun.com Mail-Followup-To: Spencer Shepler , nfsv4-wg@sunroof.eng.sun.com References: <20010919194746.F398@dhcp-aus08-191.central.sun.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.3.19i I don't see a proble with this. I will add it to the issues list. On Thu, Sergey Klyushin wrote: > For easier processing of COMPOUND requests, I would like to propose minor > protocol changes. > The idea is to set "int" type parameters before "opaque" in arguments and > results. > There are not much such structures, and I believe it's not too late to > change .x file. > I found following structures (based on RFC 3010 draft-ietf-nfsv4-07) > > struct CREATE4args { > createtype4 objtype; > component4 objname; > }; > > struct LOCK4denied { > offset4 offset; > length4 length; > nfs_lockowner4 owner; > }; > > struct LOCKT4args { > nfs_lock_type4 locktype; > offset4 offset; > length4 length; > nfs_lockowner4 owner; > }; > > struct OPEN4args { > seqid4 seqid; > uint32_t share_access; > uint32_t share_deny; > nfs_lockowner4 owner; > openflag4 openhow; > open_claim4 claim; > }; > > struct open_claim_delegate_cur4 { > stateid4 delegate_stateid; > pathname4 file; > }; > > Sergey > > > -----Original Message----- > > From: Spencer Shepler [mailto:shepler@eng.sun.com] > > Sent: Wednesday, September 19, 2001 8:48 PM > > To: nfsv4-wg@sunroof.eng.sun.com > > Subject: Issues list for RFC3010 > > > > > > > > I have an updated issues list at: > > > > http://www.nfsv4.org/rfc3010updates/issues.html > > > > Updates will follow. > > > > -- > > > > - Spencer - > > > > > -- - Spencer - From nfs4-wg-request@sunroof.eng.sun.com Thu Sep 20 15:29:17 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA19700 for ; Thu, 20 Sep 2001 15:29:16 -0400 (EDT) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id MAA03555; Thu, 20 Sep 2001 12:28:38 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA14671; Thu, 20 Sep 2001 12:28:18 -0700 (PDT) Received: from centralmail2.Central.Sun.COM (centralmail2.Central.Sun.COM [129.147.62.11]) by sunroof.eng.sun.com (8.12.0+Sun/8.12.0) with ESMTP id f8KJS97B016411 for ; Thu, 20 Sep 2001 12:28:09 -0700 (PDT) Received: from dhcp-aus08-191.central.sun.com (dhcp-aus08-191.Central.Sun.COM [129.153.128.191]) by centralmail2.Central.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id NAA07980 for ; Thu, 20 Sep 2001 13:28:10 -0600 (MDT) Received: (from shepler@localhost) by dhcp-aus08-191.central.sun.com (8.11.3+Sun/8.11.3) id f8KJRvD00498 for nfsv4-wg@sunroof.eng.sun.com; Thu, 20 Sep 2001 14:27:57 -0500 (CDT) Date: Thu, 20 Sep 2001 14:27:57 -0500 From: Spencer Shepler To: nfsv4-wg@sunroof.eng.sun.com Subject: Re: Issues list for RFC3010 Message-ID: <20010920142757.N399@dhcp-aus08-191.central.sun.com> Reply-To: shepler@eng.sun.com Mail-Followup-To: Spencer Shepler , nfsv4-wg@sunroof.eng.sun.com References: <20010919194746.F398@dhcp-aus08-191.central.sun.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.3.19i On Thu, Sergey Klyushin wrote: > >Issue03: > >OPEN(CREATE); add NFS4ERR_ISDIR for the case the name to create is a > directory (not a regular file). > > >Issue04: > >OPEN(NOCREATE); add NFS4ERR_NOENT for the no entry case. > > Should NFS4ERR_ISDIR be used in case OPEN(NOCREATE) and the name to create > is a directory? Yes, of course. Just missed this in the issue; will update. -- - Spencer - From nfs4-wg-request@sunroof.eng.sun.com Thu Sep 20 15:30:59 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA19735 for ; Thu, 20 Sep 2001 15:30:58 -0400 (EDT) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id MAA04327; Thu, 20 Sep 2001 12:30:20 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA14916; Thu, 20 Sep 2001 12:29:56 -0700 (PDT) Received: from centralmail2.Central.Sun.COM (centralmail2.Central.Sun.COM [129.147.62.11]) by sunroof.eng.sun.com (8.12.0+Sun/8.12.0) with ESMTP id f8KJTk7B016432 for ; Thu, 20 Sep 2001 12:29:46 -0700 (PDT) Received: from dhcp-aus08-191.central.sun.com (dhcp-aus08-191.Central.Sun.COM [129.153.128.191]) by centralmail2.Central.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id NAA08466 for ; Thu, 20 Sep 2001 13:29:47 -0600 (MDT) Received: (from shepler@localhost) by dhcp-aus08-191.central.sun.com (8.11.3+Sun/8.11.3) id f8KJTY100504 for nfsv4-wg@sunroof.eng.sun.com; Thu, 20 Sep 2001 14:29:34 -0500 (CDT) Date: Thu, 20 Sep 2001 14:29:34 -0500 From: Spencer Shepler To: nfsv4-wg@sunroof.eng.sun.com Subject: Re: Issues list for RFC3010 Message-ID: <20010920142934.O399@dhcp-aus08-191.central.sun.com> Reply-To: shepler@eng.sun.com Mail-Followup-To: Spencer Shepler , nfsv4-wg@sunroof.eng.sun.com References: <20010919194746.F398@dhcp-aus08-191.central.sun.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.3.19i On Thu, Sergey Klyushin wrote: > >Issue08: > >Change of "tag" in COMPOUND4args. At a minimum the server should return the > same tag length/contents that were >included in the request. Alternate > changes are: fixed length tag or no tag at all. > > I vote to remove "tag" at all. If it used for debugging - use snoop, if it > used for caching - use something else (xids from RPC) Well, I have found that in using snoop it is really nice to have a tag string to give you some indication of what the client is attempting to accomplish with the string of COMPOUND operations. My personal preference would be to have a fixed length string. We could even make it a regular xdr string type to avoid the utf8 "overhead". -- - Spencer - From nfs4-wg-request@sunroof.eng.sun.com Thu Sep 20 15:55:12 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA21933 for ; Thu, 20 Sep 2001 15:55:11 -0400 (EDT) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA18237; Thu, 20 Sep 2001 13:54:22 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA20940; Thu, 20 Sep 2001 12:54:11 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.0+Sun/8.12.0) with ESMTP id f8KJrr7B016560 for ; Thu, 20 Sep 2001 12:53:54 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA20894 for ; Thu, 20 Sep 2001 12:53:54 -0700 (PDT) Received: from mx01-a.netapp.com (mx01-a.netapp.com [198.95.226.53]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA17753 for ; Thu, 20 Sep 2001 13:53:43 -0600 (MDT) Received: from hawk.corp.netapp.com (mh02 [10.10.20.101]) by mx01-a.netapp.com (8.11.1/8.11.1/NTAP-1.2) with ESMTP id f8KJs8921984; Thu, 20 Sep 2001 12:54:08 -0700 (PDT) Received: from ussvlexc06.corp.netapp.com (localhost [127.0.0.1]) by hawk.corp.netapp.com (8.11.1/8.11.1/NTAP-1.2) with ESMTP id f8KJrrY27681; Thu, 20 Sep 2001 12:53:53 -0700 (PDT) Received: by ussvlexc06.corp.netapp.com with Internet Mail Service (5.5.2653.19) id ; Thu, 20 Sep 2001 12:53:52 -0700 Message-ID: <8C610D86AF6CD4119C9800B0D0499E33335612@red.nane.netapp.com> From: "Noveck, Dave" To: "'shepler@eng.sun.com'" , nfsv4-wg@sunroof.eng.sun.com Subject: RE: Issues list for RFC3010 Date: Thu, 20 Sep 2001 12:53:51 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Spencer Shepler wrote: > On Thu, Sergey Klyushin wrote: > > >Issue08: > > >Change of "tag" in COMPOUND4args. At a minimum the server should return the > > same tag length/contents that were >included in the request. Alternate > > changes are: fixed length tag or no tag at all. > > > > I vote to remove "tag" at all. If it used for debugging - use snoop, if it > > used for caching - use something else (xids from RPC) > > Well, I have found that in using snoop it is really nice to have a tag > string to give you some indication of what the client is attempting to > accomplish with the string of COMPOUND operations. > > My personal preference would be to have a fixed length string. We > could even make it a regular xdr string type to avoid the utf8 > "overhead". What overhead? If all the characters are pure ASCII, there is no overhead to UTF-8. Characters between 128-255 require an extra byte. Characters between 256-2047 require two bytes in UTF-8 but they would in any encoding. Characters bewteen 2048-65535 require an extra byte. So are you planning tags that have characters 128-255 or 2048-65535? I know the latter wouldn't help me too much, even if snoop were to print them out. If we are going to have string tags it seems awfully provincial not to allow the full range of UCS characters. From nfs4-wg-request@sunroof.eng.sun.com Thu Sep 20 16:20:24 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA22299 for ; Thu, 20 Sep 2001 16:20:24 -0400 (EDT) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id NAA27019; Thu, 20 Sep 2001 13:19:46 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id NAA26999; Thu, 20 Sep 2001 13:19:07 -0700 (PDT) Received: from centralmail2.Central.Sun.COM (centralmail2.Central.Sun.COM [129.147.62.11]) by sunroof.eng.sun.com (8.12.0+Sun/8.12.0) with ESMTP id f8KKIl7B016574 for ; Thu, 20 Sep 2001 13:18:47 -0700 (PDT) Received: from dhcp-aus08-191.central.sun.com (dhcp-aus08-191.Central.Sun.COM [129.153.128.191]) by centralmail2.Central.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA28208 for ; Thu, 20 Sep 2001 14:18:49 -0600 (MDT) Received: (from shepler@localhost) by dhcp-aus08-191.central.sun.com (8.11.3+Sun/8.11.3) id f8KKIaY00606 for nfsv4-wg@sunroof.eng.sun.com; Thu, 20 Sep 2001 15:18:36 -0500 (CDT) Date: Thu, 20 Sep 2001 15:18:35 -0500 From: Spencer Shepler To: nfsv4-wg@sunroof.eng.sun.com Subject: Re: Issues list for RFC3010 Message-ID: <20010920151835.X399@dhcp-aus08-191.central.sun.com> Reply-To: shepler@eng.sun.com Mail-Followup-To: Spencer Shepler , nfsv4-wg@sunroof.eng.sun.com References: <8C610D86AF6CD4119C9800B0D0499E33335612@red.nane.netapp.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <8C610D86AF6CD4119C9800B0D0499E33335612@red.nane.netapp.com> User-Agent: Mutt/1.3.19i On Thu, Noveck, Dave wrote: > Spencer Shepler wrote: > > On Thu, Sergey Klyushin wrote: > > > >Issue08: > > > >Change of "tag" in COMPOUND4args. At a minimum the server should return the > > > same tag length/contents that were >included in the request. Alternate > > > changes are: fixed length tag or no tag at all. > > > > > > I vote to remove "tag" at all. If it used for debugging - use snoop, if it > > > used for caching - use something else (xids from RPC) > > > > Well, I have found that in using snoop it is really nice to have a tag > > string to give you some indication of what the client is attempting to > > accomplish with the string of COMPOUND operations. > > > > My personal preference would be to have a fixed length string. We > > could even make it a regular xdr string type to avoid the utf8 > > "overhead". > > What overhead? > > If all the characters are pure ASCII, there is no overhead to UTF-8. > > Characters between 128-255 require an extra byte. > > Characters between 256-2047 require two bytes in UTF-8 but they would > in any encoding. > > Characters bewteen 2048-65535 require an extra byte. > > So are you planning tags that have characters 128-255 or 2048-65535? > I know the latter wouldn't help me too much, even if snoop were to > print them out. > > If we are going to have string tags it seems awfully provincial > not to allow the full range of UCS characters. I agree with your point; I was just trying to offer an alternative. -- - Spencer - From nfs4-wg-request@sunroof.eng.sun.com Thu Sep 20 16:57:36 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA23183 for ; Thu, 20 Sep 2001 16:57:36 -0400 (EDT) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA08560; Thu, 20 Sep 2001 14:56:48 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id NAA00892; Thu, 20 Sep 2001 13:56:41 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.0+Sun/8.12.0) with ESMTP id f8KKuU7B016699 for ; Thu, 20 Sep 2001 13:56:30 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id NAA07288 for ; Thu, 20 Sep 2001 13:56:32 -0700 (PDT) Received: from tor01x3.hcl.com ([199.71.120.7]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA08128 for ; Thu, 20 Sep 2001 14:56:21 -0600 (MDT) Received: from av0011 (av0011.hcl.com [10.1.42.240]) by tor01x3.hcl.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id SKT229A7; Thu, 20 Sep 2001 16:56:30 -0400 Received: FROM null.hcl.com BY av0011 ; Thu Sep 20 16:56:50 2001 -0400 Received: from sergeylt (sergeylt.hcl.com [10.1.14.29]) by null.hcl.com (8.11.2/8.11.3) with SMTP id f8KKuUB00383; Thu, 20 Sep 2001 16:56:30 -0400 (EDT) From: "Sergey Klyushin" To: , Subject: RE: Issues list for RFC3010 Date: Thu, 20 Sep 2001 16:56:56 -0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 In-Reply-To: <20010920151835.X399@dhcp-aus08-191.central.sun.com> Content-Transfer-Encoding: 7bit > -----Original Message----- > From: Spencer Shepler [mailto:shepler@eng.sun.com] > Sent: Thursday, September 20, 2001 4:19 PM > To: nfsv4-wg@sunroof.eng.sun.com > Subject: Re: Issues list for RFC3010 > > > On Thu, Noveck, Dave wrote: > > Spencer Shepler wrote: > > > On Thu, Sergey Klyushin wrote: > > > > >Issue08: > > > > >Change of "tag" in COMPOUND4args. At a minimum the > server should return the > > > > same tag length/contents that were >included in the > request. Alternate > > > > changes are: fixed length tag or no tag at all. > > > > > > > > I vote to remove "tag" at all. If it used for debugging > - use snoop, if it > > > > used for caching - use something else (xids from RPC) > > > > > > Well, I have found that in using snoop it is really nice > to have a tag > > > string to give you some indication of what the client is > attempting to > > > accomplish with the string of COMPOUND operations. > > > > > > My personal preference would be to have a fixed length string. We > > > could even make it a regular xdr string type to avoid the utf8 > > > "overhead". > > > > What overhead? > > > > If all the characters are pure ASCII, there is no overhead to UTF-8. > > > > Characters between 128-255 require an extra byte. > > > > Characters between 256-2047 require two bytes in UTF-8 but > they would > > in any encoding. > > > > Characters bewteen 2048-65535 require an extra byte. > > > > So are you planning tags that have characters 128-255 or 2048-65535? > > I know the latter wouldn't help me too much, even if snoop were to > > print them out. > > > > If we are going to have string tags it seems awfully provincial > > not to allow the full range of UCS characters. > > I agree with your point; I was just trying to offer an alternative. > > -- > > - Spencer - > So, if "tag" is used for debug only, alternative would be to remove it and use Ethereal to see all operations right away Sergey From nfs4-wg-request@sunroof.eng.sun.com Thu Sep 20 17:06:09 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA23427 for ; Thu, 20 Sep 2001 17:06:08 -0400 (EDT) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA15707; Thu, 20 Sep 2001 15:05:21 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA02807; Thu, 20 Sep 2001 14:05:13 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.0+Sun/8.12.0) with ESMTP id f8KL4r7B016708 for ; Thu, 20 Sep 2001 14:04:54 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA09573 for ; Thu, 20 Sep 2001 14:04:42 -0700 (PDT) Received: from tor01x3.hcl.com ([199.71.120.7]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id PAA04434 for ; Thu, 20 Sep 2001 15:05:32 -0600 (MDT) Received: from av0011 (av0011.hcl.com [10.1.42.240]) by tor01x3.hcl.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id SKT229PV; Thu, 20 Sep 2001 17:04:39 -0400 Received: FROM null.hcl.com BY av0011 ; Thu Sep 20 17:04:59 2001 -0400 Received: from sergeylt (sergeylt.hcl.com [10.1.14.29]) by null.hcl.com (8.11.2/8.11.3) with SMTP id f8KL4cB01839; Thu, 20 Sep 2001 17:04:38 -0400 (EDT) From: "Sergey Klyushin" To: , Subject: RE: Issues list for RFC3010 Date: Thu, 20 Sep 2001 17:05:05 -0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 In-Reply-To: <20010919194746.F398@dhcp-aus08-191.central.sun.com> Content-Transfer-Encoding: 7bit >Issue125: >Client's REMOVE of an open file still requires the use of a RENAME to a .nfsXXXX file >followed by a subsequent REMOVE when the client's applications release final reference to the open file. I think it's still "shaky". Do you mean the same Client sends REMOVE request or another? What if another Client sends READDIR and RENAMEs or OPENs .nfsXXXX? I have proposal to introduce new file/directory attribute: FATTR4_MARKED_TO_DELETE. I believe lots of OS support this attribute locally. > -----Original Message----- > From: Spencer Shepler [mailto:shepler@eng.sun.com] > Sent: Wednesday, September 19, 2001 8:48 PM > To: nfsv4-wg@sunroof.eng.sun.com > Subject: Issues list for RFC3010 > > > > I have an updated issues list at: > > http://www.nfsv4.org/rfc3010updates/issues.html > > Updates will follow. > > -- > > - Spencer - > > From nfs4-wg-request@sunroof.eng.sun.com Thu Sep 20 17:14:03 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA23564 for ; Thu, 20 Sep 2001 17:14:03 -0400 (EDT) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA21610; Thu, 20 Sep 2001 15:13:15 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA04297; Thu, 20 Sep 2001 14:13:08 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.0+Sun/8.12.0) with ESMTP id f8KLCw7B016721 for ; Thu, 20 Sep 2001 14:12:58 -0700 (PDT) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA11357 for ; Thu, 20 Sep 2001 14:13:01 -0700 (PDT) Received: from tor01x3.hcl.com ([199.71.120.7]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA11727 for ; Thu, 20 Sep 2001 14:13:00 -0700 (PDT) Received: from av0011 (av0011.hcl.com [10.1.42.240]) by tor01x3.hcl.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id SKT229VC; Thu, 20 Sep 2001 17:12:59 -0400 Received: FROM null.hcl.com BY av0011 ; Thu Sep 20 17:13:14 2001 -0400 Received: from sergeylt (sergeylt.hcl.com [10.1.14.29]) by null.hcl.com (8.11.2/8.11.3) with SMTP id f8KLCsB02949; Thu, 20 Sep 2001 17:12:54 -0400 (EDT) From: "Sergey Klyushin" To: , Subject: RE: Issues list for RFC3010 Date: Thu, 20 Sep 2001 17:13:20 -0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 In-Reply-To: <20010919194746.F398@dhcp-aus08-191.central.sun.com> Content-Transfer-Encoding: 7bit >Issue116: >In section 8.4 of the spec, it states: >The following events cause implicit renewal of all of the leases for >a given client (i.e. all those sharing a given clientid). Each of >these is a positive indication that the client is still active and >associated state held at the server, for the client, is still valid. > > o An OPEN with a valid clientid. > > o Any operation made with a valid stateid (CLOSE, DELEGRETURN, > LOCK, LOCKU, OPEN, OPEN_CONFIRM, READ, RENEW, SETATTR, > WRITE). This does not include the special stateids of all > bits 0 or all bits 1. > > >OPEN_DOWNGRADE should be added to this list as it takes a stateid as an argument. >SETCLIENTID_CONFIRM should also be added to the list for completeness. I don't agree with SETCLIENTID_CONFIRM. 1. Until SETCLIENTID_CONFIRM is received there are either no established states for the CLIENT, or all states will be released on successful SETCLIENTID_CONFIRM. 2. If client was already confirmed, SETCLIENTID_CONFIRM will be retransmission or error from Server's point of view. Sergey > -----Original Message----- > From: Spencer Shepler [mailto:shepler@eng.sun.com] > Sent: Wednesday, September 19, 2001 8:48 PM > To: nfsv4-wg@sunroof.eng.sun.com > Subject: Issues list for RFC3010 > > > > I have an updated issues list at: > > http://www.nfsv4.org/rfc3010updates/issues.html > > Updates will follow. > > -- > > - Spencer - > > From nfs4-wg-request@sunroof.eng.sun.com Thu Sep 20 17:15:05 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA23584 for ; Thu, 20 Sep 2001 17:15:04 -0400 (EDT) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id OAA23937; Thu, 20 Sep 2001 14:14:26 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA04260; Thu, 20 Sep 2001 14:13:00 -0700 (PDT) Received: from centralmail2.Central.Sun.COM (centralmail2.Central.Sun.COM [129.147.62.11]) by sunroof.eng.sun.com (8.12.0+Sun/8.12.0) with ESMTP id f8KLCm7B016718 for ; Thu, 20 Sep 2001 14:12:48 -0700 (PDT) Received: from dhcp-aus08-191.central.sun.com (dhcp-aus08-191.Central.Sun.COM [129.153.128.191]) by centralmail2.Central.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id PAA23858 for ; Thu, 20 Sep 2001 15:12:50 -0600 (MDT) Received: (from shepler@localhost) by dhcp-aus08-191.central.sun.com (8.11.3+Sun/8.11.3) id f8KLCcr00789 for nfsv4-wg@sunroof.eng.sun.com; Thu, 20 Sep 2001 16:12:38 -0500 (CDT) Date: Thu, 20 Sep 2001 16:12:38 -0500 From: Spencer Shepler To: nfsv4-wg@sunroof.eng.sun.com Subject: Re: Issues list for RFC3010 Message-ID: <20010920161237.Z399@dhcp-aus08-191.central.sun.com> Reply-To: shepler@eng.sun.com Mail-Followup-To: Spencer Shepler , nfsv4-wg@sunroof.eng.sun.com References: <20010920151835.X399@dhcp-aus08-191.central.sun.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.3.19i On Thu, Sergey Klyushin wrote: > > > > I agree with your point; I was just trying to offer an alternative. > > > > -- > > > > - Spencer - > > > So, if "tag" is used for debug only, alternative would be to remove it and > use Ethereal to see all operations right away I agree there are many ways that one can look at network traffic to view the full set of operations in the compound op. My point is that the client may provide some additional operating context by placing something useful in the tag that explains more than just looking at the set of operations. We all know that debugging can occur in production environments and anything to make that easier on me and the customer is what I am interested in. I am just proposing a solution that is in the middle. When this initially came up, the main issue seemed to be that the server was returning a string that was different than what the client was returning. -- - Spencer - From nfs4-wg-request@sunroof.eng.sun.com Thu Sep 20 17:18:01 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA23627 for ; Thu, 20 Sep 2001 17:18:01 -0400 (EDT) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA24806; Thu, 20 Sep 2001 15:17:13 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA05245; Thu, 20 Sep 2001 14:17:07 -0700 (PDT) Received: from centralmail1.Central.Sun.COM (centralmail1.Central.Sun.COM [129.147.62.10]) by sunroof.eng.sun.com (8.12.0+Sun/8.12.0) with ESMTP id f8KLGv7B016730 for ; Thu, 20 Sep 2001 14:16:57 -0700 (PDT) Received: from dhcp-aus08-191.central.sun.com (dhcp-aus08-191.Central.Sun.COM [129.153.128.191]) by centralmail1.Central.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id PAA03234 for ; Thu, 20 Sep 2001 15:16:59 -0600 (MDT) Received: (from shepler@localhost) by dhcp-aus08-191.central.sun.com (8.11.3+Sun/8.11.3) id f8KLGkZ00796 for nfsv4-wg@sunroof.eng.sun.com; Thu, 20 Sep 2001 16:16:46 -0500 (CDT) Date: Thu, 20 Sep 2001 16:16:46 -0500 From: Spencer Shepler To: nfsv4-wg@sunroof.eng.sun.com Subject: Re: Issues list for RFC3010 Message-ID: <20010920161646.A399@dhcp-aus08-191.central.sun.com> Reply-To: shepler@eng.sun.com Mail-Followup-To: Spencer Shepler , nfsv4-wg@sunroof.eng.sun.com References: <20010919194746.F398@dhcp-aus08-191.central.sun.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.3.19i On Thu, Sergey Klyushin wrote: > >Issue125: > >Client's REMOVE of an open file still requires the use of a RENAME to a > .nfsXXXX file > >followed by a subsequent REMOVE when the client's applications release > final reference to the open file. > > I think it's still "shaky". Do you mean the same Client sends REMOVE request > or another? > What if another Client sends READDIR and RENAMEs or OPENs .nfsXXXX? The issue was that there was no mention in RFC3010 of the standard NFS implementation practice of renaming a file to .nfsXXXX when an application had the file open at the client. We are referring to the same client. If another client removes the file while another has it open, the application at the client where the file is open will receive an error. This assumes that the server supports the remove of a file that is open (Solaris will support this). > I have proposal to introduce new file/directory attribute: > FATTR4_MARKED_TO_DELETE. > I believe lots of OS support this attribute locally. So how does this work at the server? Is this effective across server restart? (this isn't required since .nfsXXXX would still exist as well but it would be good to know). So the idea is that if the client has the file open and this attribute is returned by the server, the client would go ahead with the REMOVE and when the last NFS OPEN is CLOSEd the file would be removed by the server automatically? What OSes support this feature? Spencer From nfs4-wg-request@sunroof.eng.sun.com Thu Sep 20 17:20:05 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA23675 for ; Thu, 20 Sep 2001 17:20:04 -0400 (EDT) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA26379; Thu, 20 Sep 2001 15:19:17 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA05744; Thu, 20 Sep 2001 14:19:07 -0700 (PDT) Received: from centralmail2.Central.Sun.COM (centralmail2.Central.Sun.COM [129.147.62.11]) by sunroof.eng.sun.com (8.12.0+Sun/8.12.0) with ESMTP id f8KLIw7B016738 for ; Thu, 20 Sep 2001 14:18:58 -0700 (PDT) Received: from dhcp-aus08-191.central.sun.com (dhcp-aus08-191.Central.Sun.COM [129.153.128.191]) by centralmail2.Central.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id PAA26337 for ; Thu, 20 Sep 2001 15:19:00 -0600 (MDT) Received: (from shepler@localhost) by dhcp-aus08-191.central.sun.com (8.11.3+Sun/8.11.3) id f8KLIlx00802 for nfsv4-wg@sunroof.eng.sun.com; Thu, 20 Sep 2001 16:18:47 -0500 (CDT) Date: Thu, 20 Sep 2001 16:18:47 -0500 From: Spencer Shepler To: nfsv4-wg@sunroof.eng.sun.com Subject: Re: Issues list for RFC3010 Message-ID: <20010920161847.B399@dhcp-aus08-191.central.sun.com> Reply-To: shepler@eng.sun.com Mail-Followup-To: Spencer Shepler , nfsv4-wg@sunroof.eng.sun.com References: <20010919194746.F398@dhcp-aus08-191.central.sun.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.3.19i On Thu, Sergey Klyushin wrote: > >Issue116: > >In section 8.4 of the spec, it states: > >The following events cause implicit renewal of all of the leases for > >a given client (i.e. all those sharing a given clientid). Each of > >these is a positive indication that the client is still active and > >associated state held at the server, for the client, is still valid. > > > > o An OPEN with a valid clientid. > > > > o Any operation made with a valid stateid (CLOSE, DELEGRETURN, > > LOCK, LOCKU, OPEN, OPEN_CONFIRM, READ, RENEW, SETATTR, > > WRITE). This does not include the special stateids of all > > bits 0 or all bits 1. > > > > > >OPEN_DOWNGRADE should be added to this list as it takes a stateid as an > argument. > >SETCLIENTID_CONFIRM should also be added to the list for completeness. > > I don't agree with SETCLIENTID_CONFIRM. > 1. Until SETCLIENTID_CONFIRM is received there are either no established > states for the CLIENT, or all states will be released on successful > SETCLIENTID_CONFIRM. > 2. If client was already confirmed, SETCLIENTID_CONFIRM will be > retransmission or error from Server's point of view. So the larger issue is when does the server start the countdown for the lease period. Does the counter start when the client instantiates its first state at the server via OPEN? Is it from the SETCLIENTID_CONFIRM? I agree that SETCLIENTID_CONFIRM probably isn't appropriate but we need to decide the meta issue to resolve this correctly. Spencer From nfs4-wg-request@sunroof.eng.sun.com Thu Sep 20 18:31:13 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA25155 for ; Thu, 20 Sep 2001 18:31:12 -0400 (EDT) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id QAA18729; Thu, 20 Sep 2001 16:30:25 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id PAA24323; Thu, 20 Sep 2001 15:30:14 -0700 (PDT) Received: from jurassic.eng.sun.com (jurassic [129.146.89.50] (may be forged)) by sunroof.eng.sun.com (8.12.0+Sun/8.12.0) with ESMTP id f8KMTu7B016980 for ; Thu, 20 Sep 2001 15:29:56 -0700 (PDT) Received: from eng.sun.com (terra.Eng.Sun.COM [129.146.86.99]) by jurassic.eng.sun.com (8.12.0+Sun/8.12.0) with ESMTP id f8KMTwVi736220 for ; Thu, 20 Sep 2001 15:29:58 -0700 (PDT) Sender: Brent.Callaghan@eng.sun.com Message-ID: <3BAA6DDC.8B34CFB1@eng.sun.com> Date: Thu, 20 Sep 2001 15:29:48 -0700 From: Brent Organization: NFS Whackers X-Mailer: Mozilla 4.76C-CCK-MCD Netscape [en] (X11; U; SunOS 5.8 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: nfsv4-wg@sunroof.eng.sun.com Subject: Re: Issues list for RFC3010 References: <20010919194746.F398@dhcp-aus08-191.central.sun.com> <20010920142934.O399@dhcp-aus08-191.central.sun.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Spencer Shepler wrote: > > On Thu, Sergey Klyushin wrote: > > : > > I vote to remove "tag" at all. If it used for debugging - use snoop, if it > > used for caching - use something else (xids from RPC) > > : > My personal preference would be to have a fixed length string. We > could even make it a regular xdr string type to avoid the utf8 > "overhead". I like the idea of a fixed length for the tag. It seems that its variable length is more of a problem than its presence. Brent From nfs4-wg-request@sunroof.eng.sun.com Thu Sep 20 20:17:35 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA27033 for ; Thu, 20 Sep 2001 20:17:35 -0400 (EDT) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id SAA20530; Thu, 20 Sep 2001 18:16:46 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id RAA12870; Thu, 20 Sep 2001 17:16:33 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.0+Sun/8.12.0) with ESMTP id f8L0GG7B017154 for ; Thu, 20 Sep 2001 17:16:16 -0700 (PDT) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id RAA12741 for ; Thu, 20 Sep 2001 17:15:53 -0700 (PDT) Received: from tor01x3.hcl.com ([199.71.120.7]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id RAA03778 for ; Thu, 20 Sep 2001 17:15:53 -0700 (PDT) Received: from av0011 (av0011.hcl.com [10.1.42.240]) by tor01x3.hcl.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id SKT2JB7D; Thu, 20 Sep 2001 20:15:51 -0400 Received: FROM null.hcl.com BY av0011 ; Thu Sep 20 20:16:11 2001 -0400 Received: from sergeylt ([10.1.39.148]) by null.hcl.com (8.11.2/8.11.3) with SMTP id f8L0FoB19666; Thu, 20 Sep 2001 20:15:51 -0400 (EDT) From: "Sergey Klyushin" To: , Subject: RE: Issues list for RFC3010 Date: Thu, 20 Sep 2001 20:16:17 -0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal In-Reply-To: <20010920161847.B399@dhcp-aus08-191.central.sun.com> X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Content-Transfer-Encoding: 7bit > -----Original Message----- > From: Spencer Shepler [mailto:shepler@eng.sun.com] > Sent: Thursday, September 20, 2001 5:19 PM > To: nfsv4-wg@sunroof.eng.sun.com > Subject: Re: Issues list for RFC3010 > > > On Thu, Sergey Klyushin wrote: > > >Issue116: > > >In section 8.4 of the spec, it states: > > >The following events cause implicit renewal of all of the > leases for > > >a given client (i.e. all those sharing a given clientid). Each of > > >these is a positive indication that the client is still active and > > >associated state held at the server, for the client, is > still valid. > > > > > > o An OPEN with a valid clientid. > > > > > > o Any operation made with a valid stateid (CLOSE, DELEGRETURN, > > > LOCK, LOCKU, OPEN, OPEN_CONFIRM, READ, RENEW, SETATTR, > > > WRITE). This does not include the special stateids of all > > > bits 0 or all bits 1. > > > > > > > > >OPEN_DOWNGRADE should be added to this list as it takes a > stateid as an > > argument. > > >SETCLIENTID_CONFIRM should also be added to the list for > completeness. > > > > I don't agree with SETCLIENTID_CONFIRM. > > 1. Until SETCLIENTID_CONFIRM is received there are either > no established > > states for the CLIENT, or all states will be released on successful > > SETCLIENTID_CONFIRM. > > 2. If client was already confirmed, SETCLIENTID_CONFIRM will be > > retransmission or error from Server's point of view. > > So the larger issue is when does the server start the countdown for > the lease period. Does the counter start when the client instantiates > its first state at the server via OPEN? Is it from the > SETCLIENTID_CONFIRM? > > I agree that SETCLIENTID_CONFIRM probably isn't appropriate but we > need to decide the meta issue to resolve this correctly. > > Spencer > As far as I remember, RFC says that counter starts on successful SETCLIENTID request. More than that, SETCLIENTID_CONFIRM should be send by client within lease period. Sergey From nfs4-wg-request@sunroof.eng.sun.com Thu Sep 20 21:41:56 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA28752 for ; Thu, 20 Sep 2001 21:41:55 -0400 (EDT) Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id TAA29961; Thu, 20 Sep 2001 19:41:07 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id SAA19107; Thu, 20 Sep 2001 18:40:53 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.0+Sun/8.12.0) with ESMTP id f8L1eP7B017466; Thu, 20 Sep 2001 18:40:26 -0700 (PDT) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id SAA27452; Thu, 20 Sep 2001 18:40:16 -0700 (PDT) From: dveq5wvrwv5@hotmail.com Received: from mail.sd302.k12.id.us (mail.sd302.k12.id.us [209.19.186.30]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id SAA04515; Thu, 20 Sep 2001 18:40:13 -0700 (PDT) Received: from 12.64.196.240 ([12.64.196.240]) by mail.sd302.k12.id.us (Netscape Messaging Server 4.15) with SMTP id GJZODC00.V1X; Thu, 20 Sep 2001 18:34:24 -0700 To: Subject: Get Your American Flag and More Here Date: Fri, 21 Sep 2001 10:00:45 -0400 MIME-Version: 1.0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Priority: 3 X-MSMail-Priority: Normal Errors-To: ucavu5snq@sol.dk X-Mailer: Microsoft Outlook Express 5.50.4133.2400 Message-ID: Content-Transfer-Encoding: quoted-printable Join Us In Helping Our Friends In New York

 

 

Join Us In Helping Our Friends In New York!

 

 

We have A= merican Flags for your Car, Operation Noble Eagle Shirts, Nuke Afghanistan bumper stickers, American Flag la= pel pins and more. Show the world your Proud to be an American and pr= oudly display our flag wherever you can.

 

Get Yo= ur American Flag Today!
 

We will donate a portion of all proceeds to he= lp the families of the 300
firefighters that lost their lives trying to save = others at the
World Trade Center on September 11, 2001  

 

NOTE: This email was sent to yo= u because your email is part of a targeted opt-in list. If you do not wish= to receive further mailings, please click below and enter your email at t= he bottom of the page. You may then rest-assured that you will never recei= ve another email from us again. UNSUBSCRIBE ME PLEASE&nb= sp; #022154

From nfs4-wg-request@sunroof.eng.sun.com Thu Sep 20 22:50:09 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA00406 for ; Thu, 20 Sep 2001 22:50:09 -0400 (EDT) Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id UAA28406; Thu, 20 Sep 2001 20:49:21 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id TAA27215; Thu, 20 Sep 2001 19:49:06 -0700 (PDT) Received: from centralmail1.Central.Sun.COM (centralmail1.Central.Sun.COM [129.147.62.10]) by sunroof.eng.sun.com (8.12.0+Sun/8.12.0) with ESMTP id f8L2mp7B017680 for ; Thu, 20 Sep 2001 19:48:51 -0700 (PDT) Received: from dhcp-aus08-191.central.sun.com (dhcp-aus08-191.Central.Sun.COM [129.153.128.191]) by centralmail1.Central.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id UAA22505 for ; Thu, 20 Sep 2001 20:48:53 -0600 (MDT) Received: (from shepler@localhost) by dhcp-aus08-191.central.sun.com (8.11.3+Sun/8.11.3) id f8L2mdi01068 for nfsv4-wg@sunroof.eng.sun.com; Thu, 20 Sep 2001 21:48:39 -0500 (CDT) Date: Thu, 20 Sep 2001 21:48:39 -0500 From: Spencer Shepler To: nfsv4-wg@sunroof.eng.sun.com Subject: Re: Issues list for RFC3010 Message-ID: <20010920214839.C399@dhcp-aus08-191.central.sun.com> Reply-To: shepler@eng.sun.com Mail-Followup-To: Spencer Shepler , nfsv4-wg@sunroof.eng.sun.com References: <20010919194746.F398@dhcp-aus08-191.central.sun.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.3.19i On Thu, Sergey Klyushin wrote: > >Issue03: > >OPEN(CREATE); add NFS4ERR_ISDIR for the case the name to create is a > directory (not a regular file). > Should we add the same error to CREATE? I mean if target for CREATE(not dir) > exists and target is directory. Should we add NFS4ERR_ISDIR to all > operations that reference to file (WRITE, etc.)? I have added two more issues to include NFS4ERR_ISDIR for WRITE and CREATE. There are already other operations listed as needing ISDIR. Let me know if any others are missing. > >Issue11: > >SETCLIENTID_CONFIRM should use clientid and verifier instead of just the > verifier > >Issue15: > >OPEN_CONFIRM should take the stateid along with the seqid and confirm > verifier > Do we really need both clientid (stateid+seqid) and verifier? Why just > clientid (stateid+seqid) is not enough? I believe you are correct. If the stateid is added to OPEN_CONFIRM it acts like the verifier because it will change over time. Therefore we should be able to replace the verifier with stateid. I will update the issue with the suggestion. > >Issue19: > >Attributes for OPEN(CREATE). The suggestion has been made to add an > attributes parameter for OPEN(CREATE) of a regular file so that the client > would not have to use a subsequent SETATTR to obtain the desired attribute > settings. > Do you mean OPEN or CREATE? OPEN already has attributes, but CREATE doesn't. > From my point of view, > CREATE should also take attributes to set (at least for directory and > symlink) and return bitmap of what attributes were set My mistake. It should be CREATE. Will update the issue. > >Issue14: > >Introduce method that allows client to determine if server is supporting > POSIX-style file locking or "strict" file locking. Two apparent choices: add > new attribute or return the information as a bit in the results flags field > (rflags) in OPEN4resok. > I think NFSv4 protocol should say in more details what means "POSIX-style > file locking or "strict" file locking" Okay. I will add an issue that we need to add clarifying text. Maybe we should just say Unix fcntl() locking vs. Win32 locking. :-) > >Issue16: > >Should a value be added to the fh_expire_type attribute to allow the server > to signify that for replicated filesystems the filehandles are the same > between servers. > It will be very useful for NT. NT won't include this flag to signify that > file handles are different, but other OS could set this flag and make life > of NFS Client much easy Other opinions? > >Issue25: > >Should the "filehandle" attribute be mandatory? > Yes. Almost all operations use current filehandle. What could be done > without filehandle? > Other opinions? > >Issue32: > >Section 8.9 states that the server MUST return an error if CLOSE would > result in having locks exist after the CLOSE operation. What error is > supposed to be used? > Also what error should be returned if server can't close file with > outstanding locks? Same question, right? From 8.9 "The server MAY free all outstanding locks on CLOSE but some servers may not support the CLOSE of a file that still has record locks held. The server MUST return failure if any locks would exist after the CLOSE." Which I read as the CLOSE was not executed (file still open?) and an error is returned. We need to define the error and maybe a path for how the client is going to deal with the state left over from the failed CLOSE. > >Issue33: > >LINK operation needs the NFS4ERR_NOENT added as possible error return. > What error should be returned on "ln f1 f2" request, if f1 and f2 are > already hard linked? NFS4ERR_EXIST. Will add a description to the IMPLEMENTATION section. -- - Spencer - From nfs4-wg-request@sunroof.eng.sun.com Thu Sep 20 22:54:43 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA00447 for ; Thu, 20 Sep 2001 22:54:43 -0400 (EDT) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id TAA12556; Thu, 20 Sep 2001 19:54:06 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id TAA18541; Thu, 20 Sep 2001 19:53:35 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.0+Sun/8.12.0) with ESMTP id f8L2rM7B017693 for ; Thu, 20 Sep 2001 19:53:22 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id TAA27808 for ; Thu, 20 Sep 2001 19:53:24 -0700 (PDT) Received: from mx01-a.netapp.com (mx01-a.netapp.com [198.95.226.53]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id UAA27203 for ; Thu, 20 Sep 2001 20:54:14 -0600 (MDT) Received: from hawk.corp.netapp.com (mh02 [10.10.20.101]) by mx01-a.netapp.com (8.11.1/8.11.1/NTAP-1.2) with ESMTP id f8L2rb911353; Thu, 20 Sep 2001 19:53:37 -0700 (PDT) Received: from ussvlexc06.corp.netapp.com (localhost [127.0.0.1]) by hawk.corp.netapp.com (8.11.1/8.11.1/NTAP-1.2) with ESMTP id f8L2rML26261; Thu, 20 Sep 2001 19:53:22 -0700 (PDT) Received: by ussvlexc06.corp.netapp.com with Internet Mail Service (5.5.2653.19) id ; Thu, 20 Sep 2001 19:48:54 -0700 Message-ID: <8C610D86AF6CD4119C9800B0D0499E3333561A@red.nane.netapp.com> From: "Noveck, Dave" To: "'shepler@eng.sun.com'" , nfsv4-wg@sunroof.eng.sun.com Subject: RE: Issues list for RFC3010 Date: Thu, 20 Sep 2001 19:53:21 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" > > >Issue14: > > >Introduce method that allows client to determine if server is supporting > > POSIX-style file locking or "strict" file locking. Two apparent choices: add > > new attribute or return the information as a bit in the results flags field > > (rflags) in OPEN4resok. > > I think NFSv4 protocol should say in more details what means "POSIX-style > > file locking or "strict" file locking" > > Okay. I will add an issue that we need to add clarifying text. Maybe > we should just say Unix fcntl() locking vs. Win32 locking. :-) That would be much too clear. We can't have that. :-) From nfs4-wg-request@sunroof.eng.sun.com Thu Sep 20 23:09:31 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA00526 for ; Thu, 20 Sep 2001 23:09:31 -0400 (EDT) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id UAA15013; Thu, 20 Sep 2001 20:08:53 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id UAA20752; Thu, 20 Sep 2001 20:08:38 -0700 (PDT) Received: from centralmail2.Central.Sun.COM (centralmail2.Central.Sun.COM [129.147.62.11]) by sunroof.eng.sun.com (8.12.0+Sun/8.12.0) with ESMTP id f8L38Q7B017702 for ; Thu, 20 Sep 2001 20:08:26 -0700 (PDT) Received: from dhcp-aus08-191.central.sun.com (dhcp-aus08-191.Central.Sun.COM [129.153.128.191]) by centralmail2.Central.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id VAA01634 for ; Thu, 20 Sep 2001 21:08:28 -0600 (MDT) Received: (from shepler@localhost) by dhcp-aus08-191.central.sun.com (8.11.3+Sun/8.11.3) id f8L38Eq01153 for nfsv4-wg@sunroof.eng.sun.com; Thu, 20 Sep 2001 22:08:14 -0500 (CDT) Date: Thu, 20 Sep 2001 22:08:14 -0500 From: Spencer Shepler To: nfsv4-wg@sunroof.eng.sun.com Subject: Re: Issues list for RFC3010 Message-ID: <20010920220814.D399@dhcp-aus08-191.central.sun.com> Reply-To: shepler@eng.sun.com Mail-Followup-To: Spencer Shepler , nfsv4-wg@sunroof.eng.sun.com References: <20010920161847.B399@dhcp-aus08-191.central.sun.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.3.19i On Thu, Sergey Klyushin wrote: > > > >SETCLIENTID_CONFIRM should also be added to the list for > > completeness. > > > > > > I don't agree with SETCLIENTID_CONFIRM. > > > 1. Until SETCLIENTID_CONFIRM is received there are either > > no established > > > states for the CLIENT, or all states will be released on successful > > > SETCLIENTID_CONFIRM. > > > 2. If client was already confirmed, SETCLIENTID_CONFIRM will be > > > retransmission or error from Server's point of view. > > > > So the larger issue is when does the server start the countdown for > > the lease period. Does the counter start when the client instantiates > > its first state at the server via OPEN? Is it from the > > SETCLIENTID_CONFIRM? > > > > I agree that SETCLIENTID_CONFIRM probably isn't appropriate but we > > need to decide the meta issue to resolve this correctly. > > > > Spencer > > > As far as I remember, RFC says that counter starts on successful SETCLIENTID > request. More than that, > SETCLIENTID_CONFIRM should be send by client within lease period. I don't think there are comments in the RFC about the lease starting at SETCLIENTID receipt. If you find them, let me know. :-) In any case, if SETCLIENTID starts the lease period, then why wouldn't SETCLIENTID_CONFIRM count towards renewal of that lease. We need to make it clear in the discussion of lease periods that if the client is successful with a SETCLIENTID/SETCLIENTID_CONFIRM sequence but does not send any other request within the lease period, the client may (will more than likely) have to do the SETCLIENTID/SETCLIENTID_CONFIRM sequence again before proceeding. This may be common. For example, if a client is rebooted in the middle of the night and mounts its filesystems from the server and in doing so does the SETCLIENTID/SETCLIENTID_CONFIRM but has no further activity it will probably not sit there and RENEW the lease at the server. To limit memory usage, the server will free the client's references and the client will need to reestablish them. So I will add an item that the lease period start needs to be clarified and a brief discussion of client recovery after no activity (if it is not already covered). -- - Spencer - From nfs4-wg-request@sunroof.eng.sun.com Fri Sep 21 00:02:57 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA01285 for ; Fri, 21 Sep 2001 00:02:56 -0400 (EDT) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id VAA24397; Thu, 20 Sep 2001 21:02:16 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id VAA26448; Thu, 20 Sep 2001 21:01:57 -0700 (PDT) Received: from centralmail2.Central.Sun.COM (centralmail2.Central.Sun.COM [129.147.62.11]) by sunroof.eng.sun.com (8.12.0+Sun/8.12.0) with ESMTP id f8L41T7B017736 for ; Thu, 20 Sep 2001 21:01:45 -0700 (PDT) Received: from morpheus.Central.Sun.COM (morpheus.Central.Sun.COM [129.153.128.119]) by centralmail2.Central.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id WAA07333; Thu, 20 Sep 2001 22:01:31 -0600 (MDT) Received: from eng.sun.com (localhost [127.0.0.1]) by morpheus.Central.Sun.COM (8.11.5+Sun/8.11.5) with ESMTP id f8L41qQ15904; Thu, 20 Sep 2001 23:01:52 -0500 (CDT) Sender: jasmith@morpheus.central.sun.com Message-ID: <3BAABBB0.24964203@eng.sun.com> Date: Thu, 20 Sep 2001 23:01:52 -0500 From: "Jeff A. Smith" X-Mailer: Mozilla 4.78 [en] (X11; U; SunOS 5.9 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: "Khan, Saadia" CC: "'nfsv4-wg@sunroof.eng.sun.com'" , "'shepler@eng.sun.com'" Subject: Re: Issues list for RFC3010 References: <6440EA1A6AA1D5118C6900902745938E5F579F@black.eng.netapp.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit "Khan, Saadia" wrote: > > -----Original Message----- > From: Khan, Saadia > Sent: Wednesday, September 19, 2001 6:29 PM > To: 'shepler@eng.sun.com'; nfsv4-wg@sunroof.eng.sun.com > Cc: Khan, Saadia > Subject: RE: Issues list for RFC3010 > > I would like to add some more things to the list which are not very clear as far > as the spec goes: > > Named Attributes: > > 1. Does it make sense to allow setattr on a named attribute dir? Is that > allowed in the spec? And if so what does it mean if the named attr dir has > different perms, uid, gid from the base file and in that case which one is > used for permission checking? > > In similar context, does it make sense to do the same for named attributes? > Or does changing perms, uid, gid for a named attribute change the perms, uid, > gid for the base file. > As I understand it, the spec provides a way to get a filehandle for the attribute directory with OPENATTR, but it does not restrict the how that filehandle can be used. The underlying server fs may restrict the set of operations allowed on attrdirs (for reasons you mentioned), but the spec does not. I think this general answer addresses most of your questions. > 2. Currently a server is required to first check if a named attribute dir > associated with a file/dir actually contains any named attributes before > returning TRUE in the named_attr field for getattr. > > There can be a couple of issues with that. First its very improbable to have > a named attr dir without any named attrs, and second it is possible that a > client is requesting the server for all supported attributes every time it > does a stat call. It can be very expensive for the server to check if the > directory is empty or not everytime it gets one of these calls. > > It should be sufficient for the server to check if the dir exists and return > TRUE for named_attr. > In this case, the spec is trying to be general enough to provide useful information to applications without assuming a particular server fs implementation. I know of at least one server fs where empty attr dirs are not rare. The attrdirs in this file system are like regular dirs in that they are not removed when the last named attribute is removed. I'm not saying I think that design is correct or that I like it -- I'm just saying it exists. If you believe that it is reasonable for an app to set several attributes and clear them later, then empty attr dirs may not be such a rare occurrance in the server file system. For such a file system, checking to see that the attrdir exists would not provide very useful info to the app -- especially if all file system objects had a named attribute at some point in their lifetime. I'm not sure I agree with your first statement that servers must check to see that the attrdir actually contains attributes before returning TRUE for named_attr. The server must answer the question correctly, but it might not have to do readdir to do so. If you're writing a nfsv4 server, and all server filesystems remove attrdirs after the last attribute is deleted, (and 3rd party filesystems are not possible), then you can certainly code your NFSv4 server to take advantage of that and simply check for the existance of the attr dir instead of doing readdir. > 3.Should exclusive create be supported for named attributes? > I don't see any reason why it shouldn't, and the spec doesn't specifically disallow it, so I would say yes. I don't have a strong argument for either position, and I generally dislike arbitrary restrictions... This sounds like a good thing to be explicitly stated in the spec. > 4. Does it make sense to rename a named attribute? I dont think it makes > sense to rename a named attribute between different base files. Within > the same file, maybe but even that doesn't make much sense. > Again I don't really have a position, and the spec is general enough to support implementations that support renaming attributes as well as those that don't. Perhaps named attrs should be mentioned in the "rename" implementation section of the spec. I don't have any experience coding apps that use named attrs, so my $0.02 is more like $0.005, but one use of renaming attributes would be to enable atomic set (create named attr with a temp name, write all attr data, then rename it to whatever the "real/proper" name). > 5. Does the spec support deleting the named attribute dir? I think that > deleting a file with named attributes should delete everything with it, > including the dir and all named attributes or the client should be allowed > to delete a single attr. > But allowing a named attr dir to be deleted without deleting the base file > doesn't really make much sense. > Because the attrdir has no name and the spec doesn't define a RM_ATTR_DIR op, there's no way to explicitly delete the attrdir. The only way I know of to delete the attrdir is to implicitly delete it by the deleting the base file. This is also a good candidate for clarification in the spec. Of course, a server fs implementation would be free to delete the attrdir after the last attribute was removed. So, it could be possible for the attrdir to be removed without removing the "base file" -- it depends on the server fs implementation. I think it would be totally broken to be able to remove a file without also removing its attributes. > thanks, > Saadia > > -----Original Message----- > From: Spencer Shepler [mailto:shepler@eng.sun.com] > Sent: Wednesday, September 19, 2001 5:48 PM > To: nfsv4-wg@sunroof.eng.sun.com > Subject: Issues list for RFC3010 > > I have an updated issues list at: > > http://www.nfsv4.org/rfc3010updates/issues.html > > Updates will follow. > > -- > > - Spencer - From nfs4-wg-request@sunroof.eng.sun.com Fri Sep 21 03:48:21 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA17270 for ; Fri, 21 Sep 2001 03:48:20 -0400 (EDT) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id BAA21910; Fri, 21 Sep 2001 01:47:31 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id AAA17827; Fri, 21 Sep 2001 00:47:11 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.0+Sun/8.12.0) with ESMTP id f8L7ku7B017818 for ; Fri, 21 Sep 2001 00:46:58 -0700 (PDT) Received: from venus.sun.com (venus.EBay.Sun.COM [129.150.69.5]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id AAA17661 for ; Fri, 21 Sep 2001 00:46:55 -0700 (PDT) Received: from a88.lambo.student.liu.se (a88.lambo.student.liu.se [130.236.229.88]) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id AAA03343 for ; Fri, 21 Sep 2001 00:46:01 -0700 (PDT) Received: by a88.lambo.student.liu.se (Postfix, from userid 500) id 2D7C634CDD; Fri, 21 Sep 2001 09:46:00 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by a88.lambo.student.liu.se (Postfix) with ESMTP id 28038CF39 for ; Fri, 21 Sep 2001 09:46:00 +0200 (CEST) Date: Fri, 21 Sep 2001 09:46:00 +0200 (CEST) From: =?iso-8859-1?Q?Peter_=C5strand?= X-X-Sender: To: Subject: Re: Issues list for RFC3010 In-Reply-To: <3BAA6DDC.8B34CFB1@eng.sun.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=iso-8859-1 Content-Transfer-Encoding: 8BIT Content-Transfer-Encoding: 8BIT > > > I vote to remove "tag" at all. If it used for debugging - use snoop, if it > > > used for caching - use something else (xids from RPC) ... > I like the idea of a fixed length for the tag. > > It seems that its variable length is more of a > problem than its presence. Why is the variable length a problem? My opinion is that the tags should be included in the protocol, in one form or another. They are really useful, IMHO. -- Peter Åstrand Telephone: +46-13-29 08 61 Cendio Systems E-mail: peter@cendio.se Teknikringen 3 583 30 Linköping From nfs4-wg-request@sunroof.eng.sun.com Fri Sep 21 03:58:34 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA17371 for ; Fri, 21 Sep 2001 03:58:34 -0400 (EDT) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id AAA14225; Fri, 21 Sep 2001 00:57:55 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id AAA18860; Fri, 21 Sep 2001 00:57:36 -0700 (PDT) Received: from shepnet153.eng.sun.com (dsl196-127 [129.146.196.127]) by sunroof.eng.sun.com (8.12.0+Sun/8.12.0) with ESMTP id f8L7vG7B017880 for ; Fri, 21 Sep 2001 00:57:17 -0700 (PDT) Received: (from shepler@localhost) by shepnet153.eng.sun.com (8.11.3+Sun/8.11.3) id f8L7v5I00542 for nfsv4-wg@sunroof.eng.sun.com; Fri, 21 Sep 2001 02:57:05 -0500 (CDT) Date: Fri, 21 Sep 2001 02:57:04 -0500 From: Spencer Shepler To: "'nfsv4-wg@sunroof.eng.sun.com'" Subject: Re: Issues list for RFC3010 Message-ID: <20010921025704.A506@shepnet153.eng.sun.com> Reply-To: shepler@eng.sun.com Mail-Followup-To: Spencer Shepler , "'nfsv4-wg@sunroof.eng.sun.com'" References: <6440EA1A6AA1D5118C6900902745938E5F579F@black.eng.netapp.com> <3BAABBB0.24964203@eng.sun.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3BAABBB0.24964203@eng.sun.com> User-Agent: Mutt/1.3.19i On Thu, Jeff A. Smith wrote: > "Khan, Saadia" wrote: > > > > -----Original Message----- > > I would like to add some more things to the list which are not very clear as far > > as the spec goes: > > > > Named Attributes: > > > > 1. Does it make sense to allow setattr on a named attribute dir? Is that > > allowed in the spec? And if so what does it mean if the named attr dir has > > different perms, uid, gid from the base file and in that case which one is > > used for permission checking? > > > > In similar context, does it make sense to do the same for named attributes? > > Or does changing perms, uid, gid for a named attribute change the perms, uid, > > gid for the base file. > > > > As I understand it, the spec provides a way to get a filehandle for the > attribute directory with OPENATTR, but it does not restrict the how that > filehandle can be used. The underlying server fs may restrict the set of > operations allowed on attrdirs (for reasons you mentioned), but the spec > does not. I think this general answer addresses most of your questions. As Jeff mentions, the named attribute support was intentially under specified. I believe the things you ask about could be allowed for certain implementations but I doubt they would not be very useful. My preference is to leave this type of functionality under specified and allow client named attribute APIs and server implementations drive further definition while not restriction the protocol to a particular implementation. I will add an item to the issues list to discuss the possible implementations and pitfalls of such. > > 2. Currently a server is required to first check if a named attribute dir > > associated with a file/dir actually contains any named attributes before > > returning TRUE in the named_attr field for getattr. > > > > There can be a couple of issues with that. First its very improbable to have > > a named attr dir without any named attrs, and second it is possible that a > > client is requesting the server for all supported attributes every time it > > does a stat call. It can be very expensive for the server to check if the > > directory is empty or not everytime it gets one of these calls. > > > > It should be sufficient for the server to check if the dir exists and return > > TRUE for named_attr. > > > In this case, the spec is trying to be general enough to provide useful > information to applications without assuming a particular server fs > implementation. I know of at least one server fs where empty attr dirs > are not rare. The attrdirs in this file system are like regular dirs > in that they are not removed when the last named attribute is removed. > I'm not saying I think that design is correct or that I like it -- I'm > just saying it exists. > > If you believe that it is reasonable for an app to set several > attributes and clear them later, then empty attr dirs may not be such > a rare occurrance in the server file system. For such a file system, > checking to see that the attrdir exists would not provide very useful > info to the app -- especially if all file system objects had a named > attribute at some point in their lifetime. > > I'm not sure I agree with your first statement that servers > must check to see that the attrdir actually contains attributes > before returning TRUE for named_attr. The server must answer > the question correctly, but it might not have to do readdir > to do so. If you're writing a nfsv4 server, and all server filesystems > remove attrdirs after the last attribute is deleted, (and 3rd party > filesystems are not possible), then you can certainly code your > NFSv4 server to take advantage of that and simply check for the > existance of the attr dir instead of doing readdir. I don't expect that clients will ask about named attributes that much in the general case. We could add language that discourages the overuse of the named_attr attribute if that would help. > > 3.Should exclusive create be supported for named attributes? > > > > I don't see any reason why it shouldn't, and the spec doesn't specifically > disallow it, so I would say yes. I don't have a strong argument for either > position, and I generally dislike arbitrary restrictions... This sounds like > a good thing to be explicitly stated in the spec. Since we have taken the model that general operations apply named attributes, the answer would be yes. However, with the case of exclusive create, we need to be sure that this is something that is applicable in the implementations that are planned. Would like to avoid specifying something that will not be implemented and removed from the specification later on. :-) > > 4. Does it make sense to rename a named attribute? I dont think it makes > > sense to rename a named attribute between different base files. Within > > the same file, maybe but even that doesn't make much sense. > > > Again I don't really have a position, and the spec is general enough > to support implementations that support renaming attributes as well > as those that don't. Perhaps named attrs should be mentioned in the > "rename" implementation section of the spec. > > I don't have any experience coding apps that use named attrs, so my > $0.02 is more like $0.005, but one use of renaming attributes would be > to enable atomic set (create named attr with a temp name, write all > attr data, then rename it to whatever the "real/proper" name). Right. This is the example that I have always thought of. Since there are named attribute APIs that require atomicity with respect to setting a value of the named attribute and NFSv4 does not provide that type of atomicity, a WRITE/RENAME sequence could be used in its place. For the case of rename of a named attribute between filesystem objects, I believe that is unlikely and the server can return NFS4ERR_XDEV in this case (and probably should). I will add this clarification to the RENAME operation IMPLEMENTATION section. > > 5. Does the spec support deleting the named attribute dir? I think that > > deleting a file with named attributes should delete everything with it, > > including the dir and all named attributes or the client should be allowed > > to delete a single attr. > > But allowing a named attr dir to be deleted without deleting the base file > > doesn't really make much sense. > > > Because the attrdir has no name and the spec doesn't define a > RM_ATTR_DIR op, there's no way to explicitly delete the attrdir. > The only way I know of to delete the attrdir is to implicitly > delete it by the deleting the base file. This is also a good > candidate for clarification in the spec. > > Of course, a server fs implementation would be free to delete the > attrdir after the last attribute was removed. So, it could be > possible for the attrdir to be removed without removing the > "base file" -- it depends on the server fs implementation. I > think it would be totally broken to be able to remove a file > without also removing its attributes. Jeff, did you mean to say something like, when a file is REMOVEd the named attributes associated with that file should automatically be removed (implicitly). It isn't the responsibility of the client to first remove all of the named attributes before removing the filesystem object. This is different from removal of a regular directory that is non-empty. The key in the NFSv4 named attribute support is that it allows for various implmentations. It is possible that the attribute directory returned from OPENATTR doesn't have a corresponding directory at the server. The server may choose to implement named attributes in a way that really doesn't have a physical directory in the server filesystem. The specification also allows for named attributes of named attributes. I realized via this discussion that I had missed an issue related to named attributes. We had discussed on the WG alias the addition of a CREATE flag to OPENATTR to provide for server implementations that do not create a named attribute directory until the first named attribute is actually created. Therefore, if the client is just reading the attribute directory without the intent of creating a named attribute it can used OPENATTR() and the server can return NFS4ERR_NOENT. If the client is going to create a named attribute, then it can use OPENATTR(CREATE) to have the named directory activated. I will add this to the issues list. - Spencer - From nfs4-wg-request@sunroof.eng.sun.com Fri Sep 21 03:59:26 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA17385 for ; Fri, 21 Sep 2001 03:59:26 -0400 (EDT) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id BAA27339; Fri, 21 Sep 2001 01:58:37 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id AAA18939; Fri, 21 Sep 2001 00:58:29 -0700 (PDT) Received: from shepnet153.eng.sun.com (dsl196-127 [129.146.196.127]) by sunroof.eng.sun.com (8.12.0+Sun/8.12.0) with ESMTP id f8L7wG7B017883 for ; Fri, 21 Sep 2001 00:58:17 -0700 (PDT) Received: (from shepler@localhost) by shepnet153.eng.sun.com (8.11.3+Sun/8.11.3) id f8L7w5000548 for nfsv4-wg@sunroof.eng.sun.com; Fri, 21 Sep 2001 02:58:05 -0500 (CDT) Date: Fri, 21 Sep 2001 02:58:05 -0500 From: Spencer Shepler To: nfsv4-wg@sunroof.eng.sun.com Subject: Re: Issues list for RFC3010 Message-ID: <20010921025805.B506@shepnet153.eng.sun.com> Reply-To: shepler@eng.sun.com Mail-Followup-To: Spencer Shepler , nfsv4-wg@sunroof.eng.sun.com References: <3BAA6DDC.8B34CFB1@eng.sun.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.3.19i On Fri, Peter ?strand wrote: > > > > I vote to remove "tag" at all. If it used for debugging - use snoop, if it > > > > used for caching - use something else (xids from RPC) > ... > > I like the idea of a fixed length for the tag. > > > > It seems that its variable length is more of a > > problem than its presence. > > Why is the variable length a problem? > > My opinion is that the tags should be included in the protocol, in one > form or another. They are really useful, IMHO. Variable length adds overhead to the decoding of the request. -- - Spencer - From nfs4-wg-request@sunroof.eng.sun.com Fri Sep 21 04:09:54 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA17478 for ; Fri, 21 Sep 2001 04:09:53 -0400 (EDT) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id CAA03420; Fri, 21 Sep 2001 02:09:05 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id BAA20612; Fri, 21 Sep 2001 01:08:34 -0700 (PDT) Received: from shepnet153.eng.sun.com (dsl196-127 [129.146.196.127]) by sunroof.eng.sun.com (8.12.0+Sun/8.12.0) with ESMTP id f8L88H7B017927 for ; Fri, 21 Sep 2001 01:08:18 -0700 (PDT) Received: (from shepler@localhost) by shepnet153.eng.sun.com (8.11.3+Sun/8.11.3) id f8L886A00587 for nfsv4-wg@sunroof.eng.sun.com; Fri, 21 Sep 2001 03:08:06 -0500 (CDT) Date: Fri, 21 Sep 2001 03:08:06 -0500 From: Spencer Shepler To: nfsv4-wg@sunroof.eng.sun.com Subject: issues (version 1.3) Message-ID: <20010921030806.C506@shepnet153.eng.sun.com> Reply-To: shepler@eng.sun.com Mail-Followup-To: Spencer Shepler , nfsv4-wg@sunroof.eng.sun.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.19i I have updated: http://www.nfsv4.org/rfc3010updates/issues.html Based on today's discussion, I have updated the following issues: Issue03, Issue15, and Issue19 I have added new issues: 126 thru 135 -- - Spencer - From nfs4-wg-request@sunroof.eng.sun.com Fri Sep 21 06:07:19 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA18264 for ; Fri, 21 Sep 2001 06:07:18 -0400 (EDT) Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id EAA03154; Fri, 21 Sep 2001 04:06:30 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id DAA09779; Fri, 21 Sep 2001 03:06:17 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.0+Sun/8.12.0) with ESMTP id f8LA5s7B018083; Fri, 21 Sep 2001 03:05:56 -0700 (PDT) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id DAA09754; Fri, 21 Sep 2001 03:05:52 -0700 (PDT) From: AnnaWilliams@btamail.net.cn Received: from infoarta ([212.163.146.134]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id DAA28497; Fri, 21 Sep 2001 03:05:47 -0700 (PDT) Received: from slip-12-64-223-187.mis.prserv.net ([12.64.223.187] helo=12.64.223.187) by infoarta with smtp (Exim 3.31 #3 (Debian)) id 15kNBV-0002oc-00; Fri, 21 Sep 2001 12:05:27 +0200 To: Subject: Stop Your Hair Loss Now! New Product with No Side Effects! Date: Mon, 24 Sep 2001 04:49:57 -0400 MIME-Version: 1.0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 Message-Id: Content-Transfer-Encoding: quoted-printable

 
Tired of Losing Your Hair?
Would you like the situation to change?
Now you can do what it takes to handle your hair!

--------------------------------------------------------------------= -----------------

 
   We have a patented and scientifically proven all natural way to= stop
   hair loss and grow new hair! Without drugs and no side effects!=
   Our hair loss products have been clinically tested at Hospitals= and   
   Universities throughout the World. You have your hair to gain f= rom  
   this! ($50 Savings on your initial order if you mention offer c= ode 10) 
 

We Can Help You!
 
 Click Here for More Information=
 

 

This email was sent to you because your email is part of a targeted opt= -in list.  If you do not wish to receive further mailings, please= click below and enter your email at the bottom of the page.  You ma= y then rest-assured that you will never receive another email from us aga= in.  UNSUBSCRIBE ME PLEASE  #0221= 54









 

From nfs4-wg-request@sunroof.eng.sun.com Fri Sep 21 09:48:34 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA24991 for ; Fri, 21 Sep 2001 09:48:34 -0400 (EDT) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id GAA28782; Fri, 21 Sep 2001 06:46:57 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id GAA23214; Fri, 21 Sep 2001 06:45:16 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.0+Sun/8.12.0) with ESMTP id f8LDis7B018208 for ; Fri, 21 Sep 2001 06:44:55 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id GAA12199 for ; Fri, 21 Sep 2001 06:44:53 -0700 (PDT) Received: from mx01-a.netapp.com (mx01-a.netapp.com [198.95.226.53]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id HAA23646 for ; Fri, 21 Sep 2001 07:45:44 -0600 (MDT) Received: from hawk.corp.netapp.com (mh02 [10.10.20.101]) by mx01-a.netapp.com (8.11.1/8.11.1/NTAP-1.2) with ESMTP id f8LDj7925663; Fri, 21 Sep 2001 06:45:07 -0700 (PDT) Received: from ussvlexc01.corp.netapp.com (localhost [127.0.0.1]) by hawk.corp.netapp.com (8.11.1/8.11.1/NTAP-1.2) with ESMTP id f8LDimS23350; Fri, 21 Sep 2001 06:44:48 -0700 (PDT) Received: by ussvlexc01.corp.netapp.com with Internet Mail Service (5.5.2653.19) id ; Fri, 21 Sep 2001 06:44:07 -0700 Message-ID: <8C610D86AF6CD4119C9800B0D0499E3333561C@red.nane.netapp.com> From: "Noveck, Dave" To: "'shepler@eng.sun.com'" , nfsv4-wg@sunroof.eng.sun.com Subject: RE: Issues list for RFC3010 Date: Fri, 21 Sep 2001 06:44:46 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Spencer Shepler wrote: > On Fri, Peter ?strand wrote: > > > > > I vote to remove "tag" at all. If it used for debugging - use snoop, if it > > > > > used for caching - use something else (xids from RPC) > > ... > > > I like the idea of a fixed length for the tag. > > > > > > It seems that its variable length is more of a > > > problem than its presence. > > > > Why is the variable length a problem? > > > > My opinion is that the tags should be included in the protocol, in one > > form or another. They are really useful, IMHO. > > Variable length adds overhead to the decoding of the request. Not that much. A fixed length would mean that all clients would have to bear additional network overhead even if they didn't want to use the feature. A variable-length allows the client to choose a length of zero and only pay four bytes. My first choice is no tag. My second choice would be a variable-length tag with the server encouraged to return the tag unmodified in the response but allowed to truncate it because of resource issues caused by long tags. From nfs4-wg-request@sunroof.eng.sun.com Fri Sep 21 11:06:45 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA27846 for ; Fri, 21 Sep 2001 11:06:43 -0400 (EDT) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA06642; Fri, 21 Sep 2001 09:05:54 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA08413; Fri, 21 Sep 2001 08:05:36 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.0+Sun/8.12.0) with ESMTP id f8LF5R7B018267 for ; Fri, 21 Sep 2001 08:05:27 -0700 (PDT) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA24565 for ; Fri, 21 Sep 2001 08:05:25 -0700 (PDT) Received: from tor01x3.hcl.com ([199.71.120.7]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA18645 for ; Fri, 21 Sep 2001 08:05:25 -0700 (PDT) Received: from av0011 (av0011.hcl.com [10.1.42.240]) by tor01x3.hcl.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id TLHHM9FD; Fri, 21 Sep 2001 10:59:34 -0400 Received: FROM null.hcl.com BY av0011 ; Fri Sep 21 10:59:53 2001 -0400 Received: from sergeylt (sergeylt.hcl.com [10.1.14.29]) by null.hcl.com (8.11.2/8.11.3) with SMTP id f8LExYB27727; Fri, 21 Sep 2001 10:59:34 -0400 (EDT) From: "Sergey Klyushin" To: , Subject: RE: Issues list for RFC3010 Date: Fri, 21 Sep 2001 10:59:59 -0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) In-Reply-To: <20010920220814.D399@dhcp-aus08-191.central.sun.com> X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Importance: Normal Content-Transfer-Encoding: 7bit > -----Original Message----- > From: Spencer Shepler [mailto:shepler@eng.sun.com] > Sent: Thursday, September 20, 2001 11:08 PM > To: nfsv4-wg@sunroof.eng.sun.com > Subject: Re: Issues list for RFC3010 > > > On Thu, Sergey Klyushin wrote: > > > > >SETCLIENTID_CONFIRM should also be added to the list for > > > completeness. > > > > > > > > I don't agree with SETCLIENTID_CONFIRM. > > > > 1. Until SETCLIENTID_CONFIRM is received there are either > > > no established > > > > states for the CLIENT, or all states will be > released on successful > > > > SETCLIENTID_CONFIRM. > > > > 2. If client was already confirmed, > SETCLIENTID_CONFIRM will be > > > > retransmission or error from Server's point of view. > > > > > > So the larger issue is when does the server start the > countdown for > > > the lease period. Does the counter start when the > client instantiates > > > its first state at the server via OPEN? Is it from the > > > SETCLIENTID_CONFIRM? > > > > > > I agree that SETCLIENTID_CONFIRM probably isn't > appropriate but we > > > need to decide the meta issue to resolve this correctly. > > > > > > Spencer > > > > > As far as I remember, RFC says that counter starts on > successful SETCLIENTID > > request. More than that, > > SETCLIENTID_CONFIRM should be send by client within lease period. > > I don't think there are comments in the RFC about the lease starting > at SETCLIENTID receipt. If you find them, let me know. :-) > > In any case, if SETCLIENTID starts the lease period, then why wouldn't > SETCLIENTID_CONFIRM count towards renewal of that lease. > > We need to make it clear in the discussion of lease periods that if > the client is successful with a SETCLIENTID/SETCLIENTID_CONFIRM > sequence but does not send any other request within the lease period, > the client may (will more than likely) have to do the > SETCLIENTID/SETCLIENTID_CONFIRM sequence again before proceeding. > > This may be common. For example, if a client is rebooted in the > middle of the night and mounts its filesystems from the server and in > doing so does the SETCLIENTID/SETCLIENTID_CONFIRM but has no further > activity it will probably not sit there and RENEW the lease at the > server. To limit memory usage, the server will free the client's > references and the client will need to reestablish them. > > So I will add an item that the lease period start needs to be > clarified and a brief discussion of client recovery after no activity > (if it is not already covered). > > -- > > - Spencer - > > You are right, I was confused reading ========================================================================= 8.1.2. Server Release of Clientid If the server determines that the client holds no associated state for its clientid, the server may choose to release the clientid. The server may make this choice for an inactive client so that resources are not consumed by those intermittently active clients. If the client contacts the server after this release, the server must ensure the client receives the appropriate error so that it will use the SETCLIENTID/SETCLIENTID_CONFIRM sequence to establish a new identity. It should be clear that the server must be very hesitant to release a clientid since the resulting work on the client to recover from such an event will be the same burden as if the server had failed and restarted. Typically a server would not release a clientid unless there had been no activity from that client for many minutes. ========================================================================= I translated "inactive client", "no activity from that client for many minutes" to no activity during lease period. Now I realized, that NFS Server should have 4 timeouts 1. Between SETCLIENTID and SETCLIENTID_CONFIRM. 2. lease time for open_stateid 3. lease time for locked_stateid 4. Successful SETCLIENTID/SETCLIENTID_CONFIRM, but no activity from client, meaning no operations that allow Server find clientid (OPEN, LOCK, ...). The timeout could be the same as for 1. Am I wrong again? Sergey From nfs4-wg-request@sunroof.eng.sun.com Fri Sep 21 12:25:38 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA00189 for ; Fri, 21 Sep 2001 12:25:37 -0400 (EDT) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA16063; Fri, 21 Sep 2001 10:24:49 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA24513; Fri, 21 Sep 2001 09:24:36 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.0+Sun/8.12.0) with ESMTP id f8LGOS7B018539 for ; Fri, 21 Sep 2001 09:24:28 -0700 (PDT) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA16022 for ; Fri, 21 Sep 2001 09:24:27 -0700 (PDT) Received: from mx01-a.netapp.com (mx01-a.netapp.com [198.95.226.53]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA27451 for ; Fri, 21 Sep 2001 09:24:27 -0700 (PDT) Received: from hawk.corp.netapp.com (mh02 [10.10.20.101]) by mx01-a.netapp.com (8.11.1/8.11.1/NTAP-1.2) with ESMTP id f8LGOf905203; Fri, 21 Sep 2001 09:24:41 -0700 (PDT) Received: from ussvlexc01.corp.netapp.com (localhost [127.0.0.1]) by hawk.corp.netapp.com (8.11.1/8.11.1/NTAP-1.2) with ESMTP id f8LGOQh12511; Fri, 21 Sep 2001 09:24:26 -0700 (PDT) Received: by ussvlexc01.corp.netapp.com with Internet Mail Service (5.5.2653.19) id ; Fri, 21 Sep 2001 09:23:45 -0700 Message-ID: <8C610D86AF6CD4119C9800B0D0499E3333561D@red.nane.netapp.com> From: "Noveck, Dave" To: "'shepler@eng.sun.com'" , "'nfsv4-wg@sunroof.eng.sun.com'" Subject: RE: Issues list for RFC3010 Date: Fri, 21 Sep 2001 09:24:14 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Spencer Shepler wrote: > On Thu, Jeff A. Smith wrote: > > "Khan, Saadia" wrote: > > > > > > -----Original Message----- > > > I would like to add some more things to the list which are not very clear as far > > > as the spec goes: > > > > > > Named Attributes: > > > > > > 1. Does it make sense to allow setattr on a named attribute dir? Is that > > > allowed in the spec? And if so what does it mean if the named attr dir has > > > different perms, uid, gid from the base file and in that case which one is > > > used for permission checking? > > > > > > In similar context, does it make sense to do the same for named attributes? > > > Or does changing perms, uid, gid for a named attribute change the perms, uid, > > > gid for the base file. > > > > > > > As I understand it, the spec provides a way to get a filehandle for the > > attribute directory with OPENATTR, but it does not restrict the how that > > filehandle can be used. The underlying server fs may restrict the set of > > operations allowed on attrdirs (for reasons you mentioned), but the spec > > does not. I think this general answer addresses most of your questions. > > As Jeff mentions, the named attribute support was intentially under > specified. I believe the things you ask about could be allowed for > certain implementations but I doubt they would not be very useful. My > preference is to leave this type of functionality under specified and > allow client named attribute APIs and server implementations drive > further definition while not restriction the protocol to a particular > implementation. I know this was intentional, but is it the right thing to do? Leaving this under-specified opens the way for interoperability problems which are going to seriously compromise the usefulness of named attributes, unless somehow there is arrived at a minimal set of behaviors that clients expect and that all servers that support named attributes implement. If that's defined, then we can let the lunatic fringe be the lunatic fringe and go on. If we don't do this in the spec, I suppose we can do it over a beer at the next bakeoff. But if we do that, we should let people who aren't there know what we're intending to do. Some of Saadia's questions deal not with the semantics of the named attributes themselves but of the named attribute directory itself. The named attribute directory may not really exist. It is an artifact to allow named attributes to be (relatively) easily fit into NFS's file operation paradigm. I'd argue that there is a difference between leaving something under-specified and leaving it way under-specified. I can see that there might be interest in a different and richer named attribute models (I'll admit it is possible that the lunatic fringe is really just ahead of it's time). I can't see the same possibility for operations on the named attribute directory itself. I would argue that SETATTR on the named attribute directory is an operation that clients should not use and servers should not implement even if their implementation (such as making the named attribute directory a more-or-less normal directory would allow it). I think we'd all be better off if the spec said so. With regard to Saadia's other question, about setting attributes on named attributes themselves, I would argue that it's best for the server not to deceive. It may (and probably will) restrict the set of attibutes that it keeps for named attributes but if the client asks it to set one that it doesn't keep separately, it should reject the request rather than set the corresponding attibute on the base file. > I will add an item to the issues list to discuss the possible > implementations and pitfalls of such. > > > 2. Currently a server is required to first check if a named attribute dir > > > associated with a file/dir actually contains any named attributes before > > > returning TRUE in the named_attr field for getattr. > > > > > > There can be a couple of issues with that. First its very improbable to have > > > a named attr dir without any named attrs, and second it is possible that a > > > client is requesting the server for all supported attributes every time it > > > does a stat call. It can be very expensive for the server to check if the > > > directory is empty or not everytime it gets one of these calls. > > > > > > It should be sufficient for the server to check if the dir exists and return > > > TRUE for named_attr. > > > > > In this case, the spec is trying to be general enough to provide useful > > information to applications without assuming a particular server fs > > implementation. I know of at least one server fs where empty attr dirs > > are not rare. The attrdirs in this file system are like regular dirs > > in that they are not removed when the last named attribute is removed. > > I'm not saying I think that design is correct or that I like it -- I'm > > just saying it exists. > > > > If you believe that it is reasonable for an app to set several > > attributes and clear them later, then empty attr dirs may not be such > > a rare occurrance in the server file system. For such a file system, > > checking to see that the attrdir exists would not provide very useful > > info to the app -- especially if all file system objects had a named > > attribute at some point in their lifetime. I've got to believe that an environment in which all file system objects have a named attribute during their lifetime but which a large number don't have one at any given time, is likely to be one in which the file system would get rid of empty attribute directories automatically. > > > > I'm not sure I agree with your first statement that servers > > must check to see that the attrdir actually contains attributes > > before returning TRUE for named_attr. The server must answer > > the question correctly, but it might not have to do readdir > > to do so. If you're writing a nfsv4 server, and all server filesystems > > remove attrdirs after the last attribute is deleted, (and 3rd party > > filesystems are not possible), then you can certainly code your > > NFSv4 server to take advantage of that and simply check for the > > existance of the attr dir instead of doing readdir. I think Saadia was thinking of cases in which the server does not automatically remove empty named attribute directories. In such an environment, it is most probable that if a given object has a named attribute directory it has some attribute within it but that is not assured. So in that case, the server, to satisfy a GETATTR would have to look in the directory, to determine whether it is empty and then when it turned out it wasn't empty, the client would typically issue an OPENATTR/READDIR to actually find the attributes so that the server would wind up looking in the directory twice. > > I don't expect that clients will ask about named attributes that much > in the general case. We could add language that discourages the > overuse of the named_attr attribute if that would help. There may be a large number of clients, at least initially, that don't care about named attributes at all, but I'm concerned only about the ones that do. How would you define overuse? I think the purpose of the named_attibute attribute is so that the client can know whether he should bother doing the OPENATTR/READDIR when it is of no use. In an environment in which there are no empty named attribute directories possible, the server can trivially detremine this. In an environment where empty ones can exist, the server currently must check even when this is very unlikely to save the client work. So I would argue that the purpose of named_attr is as an optimization and that it should be defined so that, If there are named attributes the server must return TRUE. If the server can easily determine that no named attributes exist, the server should return FALSE. If the server determines that it is likely that named attributes exist but this is not guaranteed the server may return TRUE and the client will find out that the set of named attributes is NULL when it does OPENATTR/READDIR. > > > 3.Should exclusive create be supported for named attributes? > > > > > > > I don't see any reason why it shouldn't, and the spec doesn't specifically > > disallow it, so I would say yes. I don't have a strong argument for either > > position, and I generally dislike arbitrary restrictions... This sounds like > > a good thing to be explicitly stated in the spec. > > Since we have taken the model that general operations apply named > attributes, the answer would be yes. However, with the case of > exclusive create, we need to be sure that this is something that is > applicable in the implementations that are planned. Would like to > avoid specifying something that will not be implemented and removed > from the specification later on. :-) In the particular case of exclusive create, the model is that the create verifier is stored where the attributes normally are and that a SETATTR done after. Both of these may present difficulties among some of the myriad possible implementations. So whatever the spec says, the real question is whether cleints are going to do this. If they do, server implementations are going to be constrained. On the other hand, I can see that this might be a useful facility for the client. I'm intrigued by your remark about implementation applicability and the process of going to Draft Standard (I'm not sure how far back your smiley was intended to cover). If this rule would apply this way to exclusive create of named attributes, why wouldn't it also apply to create of a directory, symlink, or device in a named attribute in a named attribute directory, openattr-openattr-openattr ad infinitum, and all the other stuff that I'm currently recoiling from in horror? It's unlikely that there will two inter-operating implementations of a lot of those things. > > > 4. Does it make sense to rename a named attribute? I dont think it makes > > > sense to rename a named attribute between different base files. Within > > > the same file, maybe but even that doesn't make much sense. > > > > > Again I don't really have a position, and the spec is general enough > > to support implementations that support renaming attributes as well > > as those that don't. Perhaps named attrs should be mentioned in the > > "rename" implementation section of the spec. > > > > I don't have any experience coding apps that use named attrs, so my > > $0.02 is more like $0.005, but one use of renaming attributes would be > > to enable atomic set (create named attr with a temp name, write all > > attr data, then rename it to whatever the "real/proper" name). > > Right. This is the example that I have always thought of. Since there > are named attribute APIs that require atomicity with respect to > setting a value of the named attribute and NFSv4 does not provide that > type of atomicity, a WRITE/RENAME sequence could be used in its place. > For the case of rename of a named attribute between filesystem > objects, I believe that is unlikely and the server can return > NFS4ERR_XDEV in this case (and probably should). I will add this > clarification to the RENAME operation IMPLEMENTATION section. RENAME has lots of interesting cases like rename of a named attribute to be a regular file and vice versa. LINK also has interesting possibilities. How about NFS4ERR_WAY_TOO_WEIRD? :-) > > > 5. Does the spec support deleting the named attribute dir? I think that > > > deleting a file with named attributes should delete everything with it, > > > including the dir and all named attributes or the client should be allowed > > > to delete a single attr. > > > But allowing a named attr dir to be deleted without deleting the base file > > > doesn't really make much sense. > > > > Because the attrdir has no name and the spec doesn't define a > > RM_ATTR_DIR op, there's no way to explicitly delete the attrdir. > > The only way I know of to delete the attrdir is to implicitly > > delete it by the deleting the base file. This is also a good > > candidate for clarification in the spec. > > > > Of course, a server fs implementation would be free to delete the > > attrdir after the last attribute was removed. So, it could be > > possible for the attrdir to be removed without removing the > > "base file" -- it depends on the server fs implementation. I > > think it would be totally broken to be able to remove a file > > without also removing its attributes. > Jeff, did you mean to say something like, when a file is REMOVEd the > named attributes associated with that file should automatically be > removed (implicitly). It isn't the responsibility of the client to > first remove all of the named attributes before removing the > filesystem object. This is different from removal of a regular > directory that is non-empty. This is one problem with the "Named attribute directories are exactly the same as any other directories except where required by the nature of named attributes"-model. It is hard to determine when that is. I have another question about what Jeff was saying. I had been assuming that a "server fs implementation is free to delete the attrdir after the last attribute was removed" only if the handles that it created for named attribute directories were such that they would not go stale simply because a named attribute was deleted. To use implementation terms, If you have handles for named attribiutes directories that have the inode number of the base file plus a flag then you can automatically create the directory when the named attribute is created and delete it when it is empty. However, if you have handles for named attributes that have the inode number of the named attribute directory, then you can't automatically delete when the last named attribute goes away sicne this would make the handle returned by an earlier OPENATTR stale. Are you saying that you can do the autommatic deletion in this case as well, Jeff? > The key in the NFSv4 named attribute support is that it allows for > various implmentations. It is possible that the attribute directory > returned from OPENATTR doesn't have a corresponding directory at the > server. The server may choose to implement named attributes in a way > that really doesn't have a physical directory in the server > filesystem. Multiple implementations are good. Multiple interfaces are not so good. I'm worried that the current approach allows so much variation in the operations supported, that it may really wind up turning into multiple interfaces expressed in a common language rather than a single interface. > The specification also allows for named attributes of named > attributes. "But do they go away at Draft Standard if nobody implements them?", he asked with baited breath. > I realized via this discussion that I had missed an issue related to > named attributes. We had discussed on the WG alias the addition of a > CREATE flag to OPENATTR to provide for server implementations that do > not create a named attribute directory until the first named attribute > is actually created. Therefore, if the client is just reading the > attribute directory without the intent of creating a named attribute > it can used OPENATTR() and the server can return NFS4ERR_NOENT. If > the client is going to create a named attribute, then it can use > OPENATTR(CREATE) to have the named directory activated. > > I will add this to the issues list. I'm pretty sure I saw that in the list already but I don't remember the number. From nfs4-wg-request@sunroof.eng.sun.com Fri Sep 21 12:37:55 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA00682 for ; Fri, 21 Sep 2001 12:37:54 -0400 (EDT) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id JAA20603; Fri, 21 Sep 2001 09:37:03 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA26710; Fri, 21 Sep 2001 09:31:45 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.0+Sun/8.12.0) with ESMTP id f8LGVb7B018556 for ; Fri, 21 Sep 2001 09:31:37 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA18421 for ; Fri, 21 Sep 2001 09:31:36 -0700 (PDT) Received: from tor01x3.hcl.com ([199.71.120.7]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA22336 for ; Fri, 21 Sep 2001 10:31:24 -0600 (MDT) Received: from av0011 (av0011.hcl.com [10.1.42.240]) by tor01x3.hcl.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id TLHHNFQ1; Fri, 21 Sep 2001 12:31:34 -0400 Received: FROM null.hcl.com BY av0011 ; Fri Sep 21 12:31:52 2001 -0400 Received: from sergeylt (sergeylt.hcl.com [10.1.14.29]) by null.hcl.com (8.11.2/8.11.3) with SMTP id f8LGVYB17157; Fri, 21 Sep 2001 12:31:34 -0400 (EDT) From: "Sergey Klyushin" To: , Subject: RE: Issues list for RFC3010 Date: Fri, 21 Sep 2001 12:32:00 -0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) In-Reply-To: <20010920161646.A399@dhcp-aus08-191.central.sun.com> X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Importance: Normal Content-Transfer-Encoding: 7bit > -----Original Message----- > From: Spencer Shepler [mailto:shepler@eng.sun.com] > Sent: Thursday, September 20, 2001 5:17 PM > To: nfsv4-wg@sunroof.eng.sun.com > Subject: Re: Issues list for RFC3010 > > > On Thu, Sergey Klyushin wrote: > > >Issue125: > > >Client's REMOVE of an open file still requires the use of > a RENAME to a > > .nfsXXXX file > > >followed by a subsequent REMOVE when the client's > applications release > > final reference to the open file. > > > > I think it's still "shaky". Do you mean the same Client > sends REMOVE request > > or another? > > What if another Client sends READDIR and RENAMEs or OPENs .nfsXXXX? > > The issue was that there was no mention in RFC3010 of the standard NFS > implementation practice of renaming a file to .nfsXXXX when an > application had the file open at the client. We are referring to the > same client. If another client removes the file while another has it > open, the application at the client where the file is open will > receive an error. This assumes that the server supports the remove of > a file that is open (Solaris will support this). > OK for NFS v.2 and v.3 that did not have OPEN, so returning error was OK. NFSv4: Client opens file with SHARE=deny to prevent everybody else to modify file's context, and some other client not only modifying it, but removes it. Is it fair? Am I correct, that this technique was used for temporary files? > > I have proposal to introduce new file/directory attribute: > > FATTR4_MARKED_TO_DELETE. > > I believe lots of OS support this attribute locally. > > So how does this work at the server? Is this effective across server > restart? (this isn't required since .nfsXXXX would still exist as > well but it would be good to know). So the idea is that if the client > has the file open and this attribute is returned by the server, the > client would go ahead with the REMOVE and when the last NFS OPEN is > CLOSEd the file would be removed by the server automatically? > > What OSes support this feature? > > Spencer > I will provide more details. 1. The proper attribute name should be FATTR4_DELETE_PENDING 2. Meaning of FATTR4_DELETE_PENDING: remove file on the last CLOSE 3. This attribute could be set/unset on OPEN operation or on OPENed file by SETATTR, providing correct stateid. SETATTR with stateid of all 0's or of all 1's can't set this attribute 4. REMOVE of OPENed file won't remove file immediately, but will set this attribute and the file will be deleted on the last CLOSE 5. OPEN operation on the file with FATTR4_DELETE_PENDING set will fail with ACCESS DENIED error Answers to your questions 1. On server restart file will be deleted, because usually Server closes all OPENED files before restart. It's possible to provide functionality not to remove file on restart and restoring FATTR4_DELETE_PENDING. 2. Windows NT supports this feature and it's used by lots of Windows applications for temporary files I am not sure about other OS, but there are the gurus for Solaris, NetApp, Linux, DEC, etc. in our mailing list. Your comments Sergey From nfs4-wg-request@sunroof.eng.sun.com Fri Sep 21 13:07:49 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA01799 for ; Fri, 21 Sep 2001 13:07:48 -0400 (EDT) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id KAA05148; Fri, 21 Sep 2001 10:06:59 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA21722; Fri, 21 Sep 2001 10:01:38 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.0+Sun/8.12.0) with ESMTP id f8LH1S7B018596 for ; Fri, 21 Sep 2001 10:01:29 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA27415 for ; Fri, 21 Sep 2001 10:01:27 -0700 (PDT) Received: from prv-mail25.provo.novell.com (prv-mail25.provo.novell.com [137.65.81.121]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA21648 for ; Fri, 21 Sep 2001 11:01:16 -0600 (MDT) Received: from INET-PRV1-MTA by prv-mail25.provo.novell.com with Novell_GroupWise; Fri, 21 Sep 2001 10:35:47 -0600 Message-Id: X-Mailer: Novell GroupWise Internet Agent 6.0 Date: Fri, 21 Sep 2001 10:35:33 -0600 From: "Subbaraju Uppalapati" To: Subject: unsubscribe Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Disposition: inline Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id NAA01799 unsubscribe From nfs4-wg-request@sunroof.eng.sun.com Fri Sep 21 15:00:20 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA04689 for ; Fri, 21 Sep 2001 15:00:20 -0400 (EDT) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA01369; Fri, 21 Sep 2001 12:59:30 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA04551; Fri, 21 Sep 2001 11:59:18 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.0+Sun/8.12.0) with ESMTP id f8LIx87B018940 for ; Fri, 21 Sep 2001 11:59:08 -0700 (PDT) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA27312 for ; Fri, 21 Sep 2001 11:59:06 -0700 (PDT) Received: from tor01x3.hcl.com ([199.71.120.7]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA16559 for ; Fri, 21 Sep 2001 11:59:06 -0700 (PDT) Received: from av0011 (av0011.hcl.com [10.1.42.240]) by tor01x3.hcl.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id TLHHN3SG; Fri, 21 Sep 2001 14:59:05 -0400 Received: FROM null.hcl.com BY av0011 ; Fri Sep 21 14:59:23 2001 -0400 Received: from mailhub.hcl.com (mailhub.hcl.com [198.231.99.1]) by null.hcl.com (8.11.2/8.11.3) with ESMTP id f8LIx6B09785 for ; Fri, 21 Sep 2001 14:59:06 -0400 (EDT) Received: from dantnt (dantnt.hcl.com [10.1.12.90]) by mailhub.hcl.com (8.10.1/8.10.1) with SMTP id f8LIx4v28766 for ; Fri, 21 Sep 2001 14:59:05 -0400 (EDT) From: "Dan Trufasiu" To: Subject: RE: Issues list for RFC3010 Date: Fri, 21 Sep 2001 15:06:59 -0400 Message-ID: <003d01c142d0$976f0230$5a0c010a@hcl.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Importance: Normal In-Reply-To: <8C610D86AF6CD4119C9800B0D0499E3333561C@red.nane.netapp.com> Content-Transfer-Encoding: 7bit In my opinion the tag is useful only if is a variable-length tag. Fixed length is a compromise that make little sense. I like the tag. Dan > -----Original Message----- > From: Noveck, Dave [mailto:Dave.Noveck@netapp.com] > Sent: Friday, September 21, 2001 9:45 AM > To: 'shepler@eng.sun.com'; nfsv4-wg@sunroof.eng.sun.com > Subject: RE: Issues list for RFC3010 > > > Spencer Shepler wrote: > > On Fri, Peter ?strand wrote: > > > > > > I vote to remove "tag" at all. If it used for > debugging - use snoop, if it > > > > > > used for caching - use something else (xids from RPC) > > > ... > > > > I like the idea of a fixed length for the tag. > > > > > > > > It seems that its variable length is more of a > > > > problem than its presence. > > > > > > Why is the variable length a problem? > > > > > > My opinion is that the tags should be included in the > protocol, in one > > > form or another. They are really useful, IMHO. > > > > Variable length adds overhead to the decoding of the request. > > Not that much. A fixed length would mean that all clients > would have to bear additional network overhead even if they > didn't want to use the feature. A variable-length allows > the client to choose a length of zero and only pay four > bytes. > > My first choice is no tag. > > My second choice would be a variable-length tag with the > server encouraged to return the tag unmodified in the > response but allowed to truncate it because of resource > issues caused by long tags. > > > From nfs4-wg-request@sunroof.eng.sun.com Fri Sep 21 15:03:26 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA04749 for ; Fri, 21 Sep 2001 15:03:26 -0400 (EDT) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA04145; Fri, 21 Sep 2001 13:02:37 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA05130; Fri, 21 Sep 2001 12:02:27 -0700 (PDT) Received: from phys-ha6nwka.ebay.sun.com (root@phys-ha6nwka.EBay.Sun.COM [129.149.1.82]) by sunroof.eng.sun.com (8.12.0+Sun/8.12.0) with ESMTP id f8LJ2J7B018953 for ; Fri, 21 Sep 2001 12:02:19 -0700 (PDT) Received: from Sun.COM (dhcp-aus08-198.Central.Sun.COM [129.153.128.198]) by phys-ha6nwka.ebay.sun.com (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA28765; Fri, 21 Sep 2001 10:02:11 -0700 (PDT) Message-ID: <3BAB731C.C47567E@Sun.COM> Date: Fri, 21 Sep 2001 12:04:28 -0500 From: David Robinson Organization: Sun Microsystems, Inc. X-Mailer: Mozilla 4.78 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Sergey Klyushin CC: shepler@eng.sun.com, nfsv4-wg@sunroof.eng.sun.com Subject: Re: Issues list for RFC3010 References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit > I will provide more details. > 1. The proper attribute name should be FATTR4_DELETE_PENDING > 2. Meaning of FATTR4_DELETE_PENDING: remove file on the last CLOSE > 3. This attribute could be set/unset on OPEN operation or on OPENed file by > SETATTR, providing correct stateid. > SETATTR with stateid of all 0's or of all 1's can't set this attribute > 4. REMOVE of OPENed file won't remove file immediately, but will set this > attribute > and the file will be deleted on the last CLOSE > 5. OPEN operation on the file with FATTR4_DELETE_PENDING set will fail with > ACCESS DENIED error The key question is what is the semantics from the server's perspective from the compound OP ? One alternative is to simply require the REMOVE of an OPEN file to fail. Clients can then use the traditional RENAME trick and REMOVE after CLOSE. The second alternative is to allow this sequence. The interesting question becomes if the REMOVE actually prohibits and further access of the file through the namespace using the old name? I think the answer is yes, the server knows the file is open so it can rename it to a .nfsXXX or move it to a /nfs_deleted_files directory. The result is that the file can only be accessed via its file handle, all subsequent LOOKUP or OPEN will fail. And it is possible to CREATE a new file with the old name. The server then MUST handle failure in a sane manner, it MUST NOT delete the file until after the lease interval has expired, but MAY allow it to last longer if it wants to accept late lease renewals. One implication of the second alternative is that file handles MUST NOT be volitile between the REMOVE and the CLOSE including the possibility of server reboot. Those servers that cannot meet this requirement MUST fail the REMOVE and the client may choose to resort to the old .nfsXXX RENAME trick. In either alternative, I don't see the value of the FATTR4_DELETE_PENDING attribute. It doesn't provide much useful information to the clients and the servers can internally track open but removed files. My opinion is the second alternative above provides the most flexibility and is not overly complex for servers that wish to support it. But still allows simple servers to implement the first alternative by failing the REMOVE. (Might need to add a new error code to reflect the response of "E_thanks_I_would_normally_allow_the_remove_but_sorry_it_is_open". -David From nfs4-wg-request@sunroof.eng.sun.com Fri Sep 21 16:42:06 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA06256 for ; Fri, 21 Sep 2001 16:42:06 -0400 (EDT) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id NAA11625; Fri, 21 Sep 2001 13:41:26 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id NAA26790; Fri, 21 Sep 2001 13:39:17 -0700 (PDT) Received: from centralmail2.Central.Sun.COM (centralmail2.Central.Sun.COM [129.147.62.11]) by sunroof.eng.sun.com (8.12.0+Sun/8.12.0) with ESMTP id f8LKd67B019153 for ; Fri, 21 Sep 2001 13:39:06 -0700 (PDT) Received: from dhcp-aus08-191.central.sun.com (dhcp-aus08-191.Central.Sun.COM [129.153.128.191]) by centralmail2.Central.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA15002 for ; Fri, 21 Sep 2001 14:39:05 -0600 (MDT) Received: (from shepler@localhost) by dhcp-aus08-191.central.sun.com (8.11.3+Sun/8.11.3) id f8LKcq200560 for nfsv4-wg@sunroof.eng.sun.com; Fri, 21 Sep 2001 15:38:52 -0500 (CDT) Date: Fri, 21 Sep 2001 15:38:52 -0500 From: Spencer Shepler To: nfsv4-wg@sunroof.eng.sun.com Subject: lease period start / freeing of server state Message-ID: <20010921153852.Q398@dhcp-aus08-191.central.sun.com> Reply-To: shepler@eng.sun.com Mail-Followup-To: Spencer Shepler , nfsv4-wg@sunroof.eng.sun.com References: <20010920220814.D399@dhcp-aus08-191.central.sun.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.3.19i On Fri, Sergey Klyushin wrote: > > -----Original Message----- > > From: Spencer Shepler [mailto:shepler@eng.sun.com] > > Sent: Thursday, September 20, 2001 11:08 PM > > To: nfsv4-wg@sunroof.eng.sun.com > > Subject: Re: Issues list for RFC3010 > > > > > > On Thu, Sergey Klyushin wrote: > > > > > >SETCLIENTID_CONFIRM should also be added to the list for > > > > completeness. > > > > > > > > > > I don't agree with SETCLIENTID_CONFIRM. > > > > > 1. Until SETCLIENTID_CONFIRM is received there are either > > > > no established > > > > > states for the CLIENT, or all states will be > > released on successful > > > > > SETCLIENTID_CONFIRM. > > > > > 2. If client was already confirmed, > > SETCLIENTID_CONFIRM will be > > > > > retransmission or error from Server's point of view. > > > > > > > > So the larger issue is when does the server start the > > countdown for > > > > the lease period. Does the counter start when the > > client instantiates > > > > its first state at the server via OPEN? Is it from the > > > > SETCLIENTID_CONFIRM? > > > > > > > > I agree that SETCLIENTID_CONFIRM probably isn't > > appropriate but we > > > > need to decide the meta issue to resolve this correctly. > > > > > > > > Spencer > > > > > > > As far as I remember, RFC says that counter starts on > > successful SETCLIENTID > > > request. More than that, > > > SETCLIENTID_CONFIRM should be send by client within lease period. > > > > I don't think there are comments in the RFC about the lease starting > > at SETCLIENTID receipt. If you find them, let me know. :-) > > > > In any case, if SETCLIENTID starts the lease period, then why wouldn't > > SETCLIENTID_CONFIRM count towards renewal of that lease. > > > > We need to make it clear in the discussion of lease periods that if > > the client is successful with a SETCLIENTID/SETCLIENTID_CONFIRM > > sequence but does not send any other request within the lease period, > > the client may (will more than likely) have to do the > > SETCLIENTID/SETCLIENTID_CONFIRM sequence again before proceeding. > > > > This may be common. For example, if a client is rebooted in the > > middle of the night and mounts its filesystems from the server and in > > doing so does the SETCLIENTID/SETCLIENTID_CONFIRM but has no further > > activity it will probably not sit there and RENEW the lease at the > > server. To limit memory usage, the server will free the client's > > references and the client will need to reestablish them. > > > > So I will add an item that the lease period start needs to be > > clarified and a brief discussion of client recovery after no activity > > (if it is not already covered). > > > > -- > > > > - Spencer - > > > > > You are right, I was confused reading > ========================================================================= > 8.1.2. Server Release of Clientid > If the server determines that the client holds no associated state > for its clientid, the server may choose to release the clientid. The > server may make this choice for an inactive client so that resources > are not consumed by those intermittently active clients. If the > client contacts the server after this release, the server must ensure > the client receives the appropriate error so that it will use the > SETCLIENTID/SETCLIENTID_CONFIRM sequence to establish a new identity. > It should be clear that the server must be very hesitant to release a > clientid since the resulting work on the client to recover from such > an event will be the same burden as if the server had failed and > restarted. Typically a server would not release a clientid unless > there had been no activity from that client for many minutes. > ========================================================================= > I translated "inactive client", "no activity from that client for many > minutes" to > no activity during lease period. Now I realized, that NFS Server should have > 4 timeouts > 1. Between SETCLIENTID and SETCLIENTID_CONFIRM. > 2. lease time for open_stateid > 3. lease time for locked_stateid > 4. Successful SETCLIENTID/SETCLIENTID_CONFIRM, but no activity from client, > meaning > no operations that allow Server find clientid (OPEN, LOCK, ...). The timeout > could be the same as for 1. > > Am I wrong again? I don't think so but I think it might be helpful to state these differently. There is the ultimate timeout at the server -- the lease period. The questions here are: - when does the lease period start - when does the lease period RENEWed (what operations) I would argue that the lease period starts when the first state operation (OPEN) is executed by the server for that client. The lease is then renewed on the defined set of renewing operations. By definition, if the lease period expires, the server is free to release all state and data structures related to that client. There are comments in the specification about the server's need to free data structures related to state that is not currently active. Things like a lockowner reference when that lockowner does not have any open files. As has been pointed out, the clientid can also be freed at the server. At a minimum, the server should wait for a full lease period before releasing the clientid (confirmed or not). As for the lockowner references, I believe that we have discussed for the purposes of handling retransmitted CLOSEs that the server should wait a lease period before releasing that mechanism and therefore the server should probably wait a lease period before freeing the lockowner references. I am not sure if this is too burdensome. For the case where the duration between SETCLIENTID_CONFIRM and OPEN is longer than a lease period, the server is allowed to free the clientid and return NFS4ERR_STALE_CLIENTID as a result of that OPEN. Does this need to be added to the document in a concise way? Is this interpretation meet everyone's understanding? -- - Spencer - From nfs4-wg-request@sunroof.eng.sun.com Fri Sep 21 16:44:12 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA06314 for ; Fri, 21 Sep 2001 16:44:11 -0400 (EDT) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA17517; Fri, 21 Sep 2001 14:43:22 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id NAA27886; Fri, 21 Sep 2001 13:43:11 -0700 (PDT) Received: from centralmail2.Central.Sun.COM (centralmail2.Central.Sun.COM [129.147.62.11]) by sunroof.eng.sun.com (8.12.0+Sun/8.12.0) with ESMTP id f8LKh27B019157 for ; Fri, 21 Sep 2001 13:43:02 -0700 (PDT) Received: from dhcp-aus08-191.central.sun.com (dhcp-aus08-191.Central.Sun.COM [129.153.128.191]) by centralmail2.Central.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA16282 for ; Fri, 21 Sep 2001 14:43:01 -0600 (MDT) Received: (from shepler@localhost) by dhcp-aus08-191.central.sun.com (8.11.3+Sun/8.11.3) id f8LKgnL00572 for nfsv4-wg@sunroof.eng.sun.com; Fri, 21 Sep 2001 15:42:49 -0500 (CDT) Date: Fri, 21 Sep 2001 15:42:48 -0500 From: Spencer Shepler To: nfsv4-wg@sunroof.eng.sun.com Subject: remove of open file Message-ID: <20010921154248.S398@dhcp-aus08-191.central.sun.com> Reply-To: shepler@eng.sun.com Mail-Followup-To: Spencer Shepler , nfsv4-wg@sunroof.eng.sun.com References: <3BAB731C.C47567E@Sun.COM> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3BAB731C.C47567E@Sun.COM> User-Agent: Mutt/1.3.19i On Fri, David Robinson wrote: > > I will provide more details. > > 1. The proper attribute name should be FATTR4_DELETE_PENDING > > 2. Meaning of FATTR4_DELETE_PENDING: remove file on the last CLOSE > > 3. This attribute could be set/unset on OPEN operation or on OPENed file by > > SETATTR, providing correct stateid. > > SETATTR with stateid of all 0's or of all 1's can't set this attribute > > 4. REMOVE of OPENed file won't remove file immediately, but will set this > > attribute > > and the file will be deleted on the last CLOSE > > 5. OPEN operation on the file with FATTR4_DELETE_PENDING set will fail with > > ACCESS DENIED error > > The key question is what is the semantics from the server's > perspective from the compound OP ? > > One alternative is to simply require the REMOVE of an OPEN > file to fail. Clients can then use the traditional RENAME > trick and REMOVE after CLOSE. > > The second alternative is to allow this sequence. The interesting > question becomes if the REMOVE actually prohibits and further > access of the file through the namespace using the old name? > I think the answer is yes, the server knows the file is open > so it can rename it to a .nfsXXX or move it to a /nfs_deleted_files > directory. The result is that the file can only be accessed > via its file handle, all subsequent LOOKUP or OPEN will fail. > And it is possible to CREATE a new file with the old name. The > server then MUST handle failure in a sane manner, it MUST NOT > delete the file until after the lease interval has expired, but > MAY allow it to last longer if it wants to accept late lease renewals. > > One implication of the second alternative is that file handles MUST > NOT be volitile between the REMOVE and the CLOSE including the > possibility of server reboot. Those servers that cannot meet > this requirement MUST fail the REMOVE and the client may choose > to resort to the old .nfsXXX RENAME trick. > > In either alternative, I don't see the value of the > FATTR4_DELETE_PENDING attribute. It doesn't provide much > useful information to the clients and the servers can > internally track open but removed files. > > My opinion is the second alternative above provides the most > flexibility and is not overly complex for servers that wish > to support it. But still allows simple servers to > implement the first alternative by failing the REMOVE. > (Might need to add a new error code to reflect the response of > "E_thanks_I_would_normally_allow_the_remove_but_sorry_it_is_open". I like the approach, David. If we go with something like this, it seems like we need to allow for the removal of the file by other means at the server. For example, by local access to the fliesystem in question. I don't think we should place the burden on the server to implement server-wide protection against removal. -- - Spencer - From nfs4-wg-request@sunroof.eng.sun.com Fri Sep 21 16:46:28 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA06371 for ; Fri, 21 Sep 2001 16:46:28 -0400 (EDT) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA19274; Fri, 21 Sep 2001 14:45:39 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id NAA28484; Fri, 21 Sep 2001 13:45:30 -0700 (PDT) Received: from centralmail2.Central.Sun.COM (centralmail2.Central.Sun.COM [129.147.62.11]) by sunroof.eng.sun.com (8.12.0+Sun/8.12.0) with ESMTP id f8LKjL7B019160 for ; Fri, 21 Sep 2001 13:45:21 -0700 (PDT) Received: from dhcp-aus08-191.central.sun.com (dhcp-aus08-191.Central.Sun.COM [129.153.128.191]) by centralmail2.Central.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA17147 for ; Fri, 21 Sep 2001 14:45:20 -0600 (MDT) Received: (from shepler@localhost) by dhcp-aus08-191.central.sun.com (8.11.3+Sun/8.11.3) id f8LKj8D00579 for nfsv4-wg@sunroof.eng.sun.com; Fri, 21 Sep 2001 15:45:08 -0500 (CDT) Date: Fri, 21 Sep 2001 15:45:08 -0500 From: Spencer Shepler To: nfsv4-wg@sunroof.eng.sun.com Subject: Re: Issues list for RFC3010 Message-ID: <20010921154508.T398@dhcp-aus08-191.central.sun.com> Reply-To: shepler@eng.sun.com Mail-Followup-To: Spencer Shepler , nfsv4-wg@sunroof.eng.sun.com References: <3BAB731C.C47567E@Sun.COM> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3BAB731C.C47567E@Sun.COM> User-Agent: Mutt/1.3.19i On Fri, David Robinson wrote: > > I will provide more details. > > 1. The proper attribute name should be FATTR4_DELETE_PENDING > > 2. Meaning of FATTR4_DELETE_PENDING: remove file on the last CLOSE > > 3. This attribute could be set/unset on OPEN operation or on OPENed file by > > SETATTR, providing correct stateid. > > SETATTR with stateid of all 0's or of all 1's can't set this attribute > > 4. REMOVE of OPENed file won't remove file immediately, but will set this > > attribute > > and the file will be deleted on the last CLOSE > > 5. OPEN operation on the file with FATTR4_DELETE_PENDING set will fail with > > ACCESS DENIED error > > The key question is what is the semantics from the server's > perspective from the compound OP ? > > One alternative is to simply require the REMOVE of an OPEN > file to fail. Clients can then use the traditional RENAME > trick and REMOVE after CLOSE. > > The second alternative is to allow this sequence. The interesting > question becomes if the REMOVE actually prohibits and further > access of the file through the namespace using the old name? > I think the answer is yes, the server knows the file is open > so it can rename it to a .nfsXXX or move it to a /nfs_deleted_files > directory. The result is that the file can only be accessed > via its file handle, all subsequent LOOKUP or OPEN will fail. > And it is possible to CREATE a new file with the old name. The > server then MUST handle failure in a sane manner, it MUST NOT > delete the file until after the lease interval has expired, but > MAY allow it to last longer if it wants to accept late lease renewals. > > One implication of the second alternative is that file handles MUST > NOT be volitile between the REMOVE and the CLOSE including the > possibility of server reboot. Those servers that cannot meet > this requirement MUST fail the REMOVE and the client may choose > to resort to the old .nfsXXX RENAME trick. > > In either alternative, I don't see the value of the > FATTR4_DELETE_PENDING attribute. It doesn't provide much > useful information to the clients and the servers can > internally track open but removed files. > > My opinion is the second alternative above provides the most > flexibility and is not overly complex for servers that wish > to support it. But still allows simple servers to > implement the first alternative by failing the REMOVE. > (Might need to add a new error code to reflect the response of > "E_thanks_I_would_normally_allow_the_remove_but_sorry_it_is_open". Another last minute thought. What if the server's normal mode of operation is that it will not allow the removal of an OPEN file and therefore needs some special identification that a REMOVE is part of an applications desire to OPEN, REMOVE, READ. Do we want to burden REMOVE with a stateid? Right answer? Too heavy weight? -- - Spencer - From nfs4-wg-request@sunroof.eng.sun.com Fri Sep 21 16:49:11 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA06407 for ; Fri, 21 Sep 2001 16:49:10 -0400 (EDT) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA21265; Fri, 21 Sep 2001 14:48:22 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id NAA29248; Fri, 21 Sep 2001 13:48:13 -0700 (PDT) Received: from centralmail2.Central.Sun.COM (centralmail2.Central.Sun.COM [129.147.62.11]) by sunroof.eng.sun.com (8.12.0+Sun/8.12.0) with ESMTP id f8LKm37B019165 for ; Fri, 21 Sep 2001 13:48:03 -0700 (PDT) Received: from dhcp-aus08-191.central.sun.com (dhcp-aus08-191.Central.Sun.COM [129.153.128.191]) by centralmail2.Central.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA18612 for ; Fri, 21 Sep 2001 14:48:03 -0600 (MDT) Received: (from shepler@localhost) by dhcp-aus08-191.central.sun.com (8.11.3+Sun/8.11.3) id f8LKloD00585 for nfsv4-wg@sunroof.eng.sun.com; Fri, 21 Sep 2001 15:47:50 -0500 (CDT) Date: Fri, 21 Sep 2001 15:47:49 -0500 From: Spencer Shepler To: nfsv4-wg@sunroof.eng.sun.com Subject: Re: Issues list for RFC3010 Message-ID: <20010921154749.U398@dhcp-aus08-191.central.sun.com> Reply-To: shepler@eng.sun.com Mail-Followup-To: Spencer Shepler , nfsv4-wg@sunroof.eng.sun.com References: <20010920161646.A399@dhcp-aus08-191.central.sun.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.3.19i On Fri, Sergey Klyushin wrote: > > -----Original Message----- > > From: Spencer Shepler [mailto:shepler@eng.sun.com] > > Sent: Thursday, September 20, 2001 5:17 PM > > To: nfsv4-wg@sunroof.eng.sun.com > > Subject: Re: Issues list for RFC3010 > > > > > > On Thu, Sergey Klyushin wrote: > > > >Issue125: > > > >Client's REMOVE of an open file still requires the use of > > a RENAME to a > > > .nfsXXXX file > > > >followed by a subsequent REMOVE when the client's > > applications release > > > final reference to the open file. > > > > > > I think it's still "shaky". Do you mean the same Client > > sends REMOVE request > > > or another? > > > What if another Client sends READDIR and RENAMEs or OPENs .nfsXXXX? > > > > The issue was that there was no mention in RFC3010 of the standard NFS > > implementation practice of renaming a file to .nfsXXXX when an > > application had the file open at the client. We are referring to the > > same client. If another client removes the file while another has it > > open, the application at the client where the file is open will > > receive an error. This assumes that the server supports the remove of > > a file that is open (Solaris will support this). > > > OK for NFS v.2 and v.3 that did not have OPEN, so returning error was OK. > NFSv4: Client opens file with SHARE=deny to prevent everybody else to modify > file's context, > and some other client not only modifying it, but removes it. Is it fair? > Am I correct, that this technique was used for temporary files? Yes. An NFSv4 server may allow an OPEN(SHARE_DENY_WRITE) from one client and then a REMOVE of that same file from the same or another client. > > > I have proposal to introduce new file/directory attribute: > > > FATTR4_MARKED_TO_DELETE. > > > I believe lots of OS support this attribute locally. > > > > So how does this work at the server? Is this effective across server > > restart? (this isn't required since .nfsXXXX would still exist as > > well but it would be good to know). So the idea is that if the client > > has the file open and this attribute is returned by the server, the > > client would go ahead with the REMOVE and when the last NFS OPEN is > > CLOSEd the file would be removed by the server automatically? > > > > What OSes support this feature? > > > > Spencer > > > I will provide more details. > 1. The proper attribute name should be FATTR4_DELETE_PENDING > 2. Meaning of FATTR4_DELETE_PENDING: remove file on the last CLOSE > 3. This attribute could be set/unset on OPEN operation or on OPENed file by > SETATTR, providing correct stateid. > SETATTR with stateid of all 0's or of all 1's can't set this attribute > 4. REMOVE of OPENed file won't remove file immediately, but will set this > attribute > and the file will be deleted on the last CLOSE > 5. OPEN operation on the file with FATTR4_DELETE_PENDING set will fail with > ACCESS DENIED error > > Answers to your questions > 1. On server restart file will be deleted, because usually Server closes all > OPENED files before restart. > It's possible to provide functionality not to remove file on restart and > restoring FATTR4_DELETE_PENDING. > 2. Windows NT supports this feature and it's used by lots of Windows > applications for temporary files > I am not sure about other OS, but there are the gurus for Solaris, NetApp, > Linux, DEC, etc. in our mailing list. Solaris, AIX do not have such a mechanism for holding an open file in such a way as to allow access to that file across server reboot. I believe this is a requirement of this type of functionality as David has pointed out. -- - Spencer - From nfs4-wg-request@sunroof.eng.sun.com Fri Sep 21 17:03:31 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA06585 for ; Fri, 21 Sep 2001 17:03:31 -0400 (EDT) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA02379; Fri, 21 Sep 2001 15:02:42 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA03051; Fri, 21 Sep 2001 14:02:31 -0700 (PDT) Received: from phys-ha6nwka.ebay.sun.com (root@phys-ha6nwka.EBay.Sun.COM [129.149.1.82]) by sunroof.eng.sun.com (8.12.0+Sun/8.12.0) with ESMTP id f8LL2L7B019253 for ; Fri, 21 Sep 2001 14:02:21 -0700 (PDT) Received: from Sun.COM (dhcp-aus08-198.Central.Sun.COM [129.153.128.198]) by phys-ha6nwka.ebay.sun.com (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA01676 for ; Fri, 21 Sep 2001 14:02:15 -0700 (PDT) Message-ID: <3BABAB60.CAC08C92@Sun.COM> Date: Fri, 21 Sep 2001 16:04:32 -0500 From: David Robinson Organization: Sun Microsystems, Inc. X-Mailer: Mozilla 4.78 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: nfsv4-wg@sunroof.eng.sun.com Subject: Re: remove of open file References: <3BAB731C.C47567E@Sun.COM> <20010921154248.S398@dhcp-aus08-191.central.sun.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit > I like the approach, David. If we go with something like this, it > seems like we need to allow for the removal of the file by other means > at the server. For example, by local access to the fliesystem in > question. I don't think we should place the burden on the server to > implement server-wide protection against removal. If I understand you correctly, you are arguing a file opened via NFS but removed through a different mechanism (local access or different protocol) has undefined semantics? If so I agree completely. I would encourage NFS server vendors to implement a best possible solution that causes the least surprise, but it would not be wise to mandate a solution. -David From nfs4-wg-request@sunroof.eng.sun.com Fri Sep 21 17:14:30 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA06757 for ; Fri, 21 Sep 2001 17:14:29 -0400 (EDT) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA11046; Fri, 21 Sep 2001 15:13:41 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA05863; Fri, 21 Sep 2001 14:13:30 -0700 (PDT) Received: from phys-ha6nwka.ebay.sun.com (root@phys-ha6nwka.EBay.Sun.COM [129.149.1.82]) by sunroof.eng.sun.com (8.12.0+Sun/8.12.0) with ESMTP id f8LLDI7B019262 for ; Fri, 21 Sep 2001 14:13:18 -0700 (PDT) Received: from Sun.COM (dhcp-aus08-198.Central.Sun.COM [129.153.128.198]) by phys-ha6nwka.ebay.sun.com (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA03080 for ; Fri, 21 Sep 2001 14:13:12 -0700 (PDT) Message-ID: <3BABADF1.31F31E56@Sun.COM> Date: Fri, 21 Sep 2001 16:15:29 -0500 From: David Robinson Organization: Sun Microsystems, Inc. X-Mailer: Mozilla 4.78 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: nfsv4-wg@sunroof.eng.sun.com Subject: Re: Issues list for RFC3010 References: <3BAB731C.C47567E@Sun.COM> <20010921154508.T398@dhcp-aus08-191.central.sun.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit > Another last minute thought. What if the server's normal mode of > operation is that it will not allow the removal of an OPEN file and > therefore needs some special identification that a REMOVE is part of > an applications desire to OPEN, REMOVE, READ. Do we want to burden > REMOVE with a stateid? Right answer? Too heavy weight? Aghh, no... we have too much exposed state as it is... The problem only occurs when the client and server have different semantics for the removal of an open file. If the client APIs prohibit it the server will not see an OPEN-REMOVE unless the client is buggy. If the client allows it but the server prohibits it, the server sends back an error and the client if it wishes to protect the application must try a different trick like the .nfsXXX RENAME. And lastly if both allow it the server must maintain internal state that survives a reboot for error recovery. What I was trying to do here was come up with a semantic that doesn't require the server to expose any state to the client. Sergey's solution looked workable but it forced the client to track more state. Well technically if the client needs to perform the RENAME .nfsXXX trick that is state that it needs to track, but that was solved 15 years ago and already exists in all OSes that care. The client maintaining the state that a file is OPEN is sufficient. Now if a client is accessing a file without using OPEN and then REMOVEs it, it gets undefined behavior. "Don't do that..." -David From nfs4-wg-request@sunroof.eng.sun.com Fri Sep 21 17:23:35 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA06851 for ; Fri, 21 Sep 2001 17:23:34 -0400 (EDT) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA18374; Fri, 21 Sep 2001 15:22:46 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA07980; Fri, 21 Sep 2001 14:22:27 -0700 (PDT) Received: from jurassic.eng.sun.com (jurassic [129.146.85.31] (may be forged)) by sunroof.eng.sun.com (8.12.0+Sun/8.12.0) with ESMTP id f8LLMK7B019271 for ; Fri, 21 Sep 2001 14:22:20 -0700 (PDT) Received: from modestmouse (modestmouse.Eng.Sun.COM [129.146.85.83]) by jurassic.eng.sun.com (8.12.0+Sun/8.12.0) with SMTP id f8LLMIVj920994; Fri, 21 Sep 2001 14:22:19 -0700 (PDT) Message-Id: <200109212122.f8LLMIVj920994@jurassic.eng.sun.com> Date: Fri, 21 Sep 2001 14:15:37 -0700 (PDT) From: Eric Kustarz Reply-To: Eric Kustarz Subject: Re: lease period start / freeing of server state To: nfsv4-wg@sunroof.eng.sun.com, shepler@eng.sun.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: o84ABdKJmQpfVRRXgUsefA== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.5_17 SunOS 5.9 sun4u sparc >Date: Fri, 21 Sep 2001 15:38:52 -0500 >From: Spencer Shepler >To: nfsv4-wg@sunroof.eng.sun.com >Subject: lease period start / freeing of server state >Mail-Followup-To: Spencer Shepler , nfsv4-wg@sunroof.eng.sun.com >Mime-Version: 1.0 >Content-Disposition: inline >User-Agent: Mutt/1.3.19i > >On Fri, Sergey Klyushin wrote: >> > -----Original Message----- >> > From: Spencer Shepler [mailto:shepler@eng.sun.com] >> > Sent: Thursday, September 20, 2001 11:08 PM >> > To: nfsv4-wg@sunroof.eng.sun.com >> > Subject: Re: Issues list for RFC3010 >> > >> > >> > On Thu, Sergey Klyushin wrote: >> > > > > >SETCLIENTID_CONFIRM should also be added to the list for >> > > > completeness. >> > > > > >> > > > > I don't agree with SETCLIENTID_CONFIRM. >> > > > > 1. Until SETCLIENTID_CONFIRM is received there are either >> > > > no established >> > > > > states for the CLIENT, or all states will be >> > released on successful >> > > > > SETCLIENTID_CONFIRM. >> > > > > 2. If client was already confirmed, >> > SETCLIENTID_CONFIRM will be >> > > > > retransmission or error from Server's point of view. >> > > > >> > > > So the larger issue is when does the server start the >> > countdown for >> > > > the lease period. Does the counter start when the >> > client instantiates >> > > > its first state at the server via OPEN? Is it from the >> > > > SETCLIENTID_CONFIRM? >> > > > >> > > > I agree that SETCLIENTID_CONFIRM probably isn't >> > appropriate but we >> > > > need to decide the meta issue to resolve this correctly. >> > > > >> > > > Spencer >> > > > >> > > As far as I remember, RFC says that counter starts on >> > successful SETCLIENTID >> > > request. More than that, >> > > SETCLIENTID_CONFIRM should be send by client within lease period. >> > >> > I don't think there are comments in the RFC about the lease starting >> > at SETCLIENTID receipt. If you find them, let me know. :-) >> > >> > In any case, if SETCLIENTID starts the lease period, then why wouldn't >> > SETCLIENTID_CONFIRM count towards renewal of that lease. >> > >> > We need to make it clear in the discussion of lease periods that if >> > the client is successful with a SETCLIENTID/SETCLIENTID_CONFIRM >> > sequence but does not send any other request within the lease period, >> > the client may (will more than likely) have to do the >> > SETCLIENTID/SETCLIENTID_CONFIRM sequence again before proceeding. >> > >> > This may be common. For example, if a client is rebooted in the >> > middle of the night and mounts its filesystems from the server and in >> > doing so does the SETCLIENTID/SETCLIENTID_CONFIRM but has no further >> > activity it will probably not sit there and RENEW the lease at the >> > server. To limit memory usage, the server will free the client's >> > references and the client will need to reestablish them. >> > >> > So I will add an item that the lease period start needs to be >> > clarified and a brief discussion of client recovery after no activity >> > (if it is not already covered). >> > >> > -- >> > >> > - Spencer - >> > >> > >> You are right, I was confused reading >> ========================================================================= >> 8.1.2. Server Release of Clientid >> If the server determines that the client holds no associated state >> for its clientid, the server may choose to release the clientid. The >> server may make this choice for an inactive client so that resources >> are not consumed by those intermittently active clients. If the >> client contacts the server after this release, the server must ensure >> the client receives the appropriate error so that it will use the >> SETCLIENTID/SETCLIENTID_CONFIRM sequence to establish a new identity. >> It should be clear that the server must be very hesitant to release a >> clientid since the resulting work on the client to recover from such >> an event will be the same burden as if the server had failed and >> restarted. Typically a server would not release a clientid unless >> there had been no activity from that client for many minutes. >> ========================================================================= >> I translated "inactive client", "no activity from that client for many >> minutes" to >> no activity during lease period. Now I realized, that NFS Server should have >> 4 timeouts >> 1. Between SETCLIENTID and SETCLIENTID_CONFIRM. >> 2. lease time for open_stateid >> 3. lease time for locked_stateid >> 4. Successful SETCLIENTID/SETCLIENTID_CONFIRM, but no activity from client, >> meaning >> no operations that allow Server find clientid (OPEN, LOCK, ...). The timeout >> could be the same as for 1. >> >> Am I wrong again? > >I don't think so but I think it might be helpful to state these >differently. > >There is the ultimate timeout at the server -- the lease period. >The questions here are: > - when does the lease period start > - when does the lease period RENEWed (what operations) > >I would argue that the lease period starts when the first state >operation (OPEN) is executed by the server for that client. The lease >is then renewed on the defined set of renewing operations. By >definition, if the lease period expires, the server is free to release >all state and data structures related to that client. > >There are comments in the specification about the server's need to >free data structures related to state that is not currently active. >Things like a lockowner reference when that lockowner does not have >any open files. As has been pointed out, the clientid can also be >freed at the server. At a minimum, the server should wait for a full >lease period before releasing the clientid (confirmed or not). As for >the lockowner references, I believe that we have discussed for the >purposes of handling retransmitted CLOSEs that the server should wait >a lease period before releasing that mechanism and therefore the >server should probably wait a lease period before freeing the >lockowner references. I am not sure if this is too burdensome. > >For the case where the duration between SETCLIENTID_CONFIRM and OPEN >is longer than a lease period, the server is allowed to free the >clientid and return NFS4ERR_STALE_CLIENTID as a result of that OPEN. > >Does this need to be added to the document in a concise way? Is this >interpretation meet everyone's understanding? > >-- > >- Spencer - I agree but the wording needs to be changed a bit. I think we need to differentiate between when the lease starts for the client and server. The lease on the server technically starts at SETCLIENTID, is renewed at SETCLIENTID_CONFIRM, and is then further renewed by the normal means as stated in the spec (implicit and explicit renewals). The lease on the client SHOULD start on its first state operation (OPEN with a valid clientid), but the client MAY start its lease before that (after a successful SETCLIENTID_CONFIRM). eric From nfs4-wg-request@sunroof.eng.sun.com Fri Sep 21 17:45:03 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA07176 for ; Fri, 21 Sep 2001 17:45:03 -0400 (EDT) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id OAA08346; Fri, 21 Sep 2001 14:44:25 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA13702; Fri, 21 Sep 2001 14:43:55 -0700 (PDT) Received: from centralmail2.Central.Sun.COM (centralmail2.Central.Sun.COM [129.147.62.11]) by sunroof.eng.sun.com (8.12.0+Sun/8.12.0) with ESMTP id f8LLhk7B019283 for ; Fri, 21 Sep 2001 14:43:46 -0700 (PDT) Received: from dhcp-aus08-191.central.sun.com (dhcp-aus08-191.Central.Sun.COM [129.153.128.191]) by centralmail2.Central.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id PAA13002 for ; Fri, 21 Sep 2001 15:43:44 -0600 (MDT) Received: (from shepler@localhost) by dhcp-aus08-191.central.sun.com (8.11.3+Sun/8.11.3) id f8LLhV100594 for nfsv4-wg@sunroof.eng.sun.com; Fri, 21 Sep 2001 16:43:31 -0500 (CDT) Date: Fri, 21 Sep 2001 16:43:31 -0500 From: Spencer Shepler To: nfsv4-wg@sunroof.eng.sun.com Subject: Re: Issues list for RFC3010 Message-ID: <20010921164331.V398@dhcp-aus08-191.central.sun.com> Reply-To: shepler@eng.sun.com Mail-Followup-To: Spencer Shepler , nfsv4-wg@sunroof.eng.sun.com References: <3BAB731C.C47567E@Sun.COM> <20010921154508.T398@dhcp-aus08-191.central.sun.com> <3BABADF1.31F31E56@Sun.COM> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3BABADF1.31F31E56@Sun.COM> User-Agent: Mutt/1.3.19i On Fri, David Robinson wrote: > > Another last minute thought. What if the server's normal mode of > > operation is that it will not allow the removal of an OPEN file and > > therefore needs some special identification that a REMOVE is part of > > an applications desire to OPEN, REMOVE, READ. Do we want to burden > > REMOVE with a stateid? Right answer? Too heavy weight? > > Aghh, no... we have too much exposed state as it is... :-) > The problem only occurs when the client and server have different > semantics for the removal of an open file. If the > client APIs prohibit it the server will not see an OPEN-REMOVE > unless the client is buggy. If the client allows it but the server > prohibits it, the server sends back an error and the client > if it wishes to protect the application must try a different > trick like the .nfsXXX RENAME. And lastly if both allow it the > server must maintain internal state that survives a reboot > for error recovery. > > What I was trying to do here was come up with a semantic that > doesn't require the server to expose any state to the client. > Sergey's solution looked workable but it forced the client > to track more state. Well technically if the client needs > to perform the RENAME .nfsXXX trick that is state that it > needs to track, but that was solved 15 years ago and already > exists in all OSes that care. The client maintaining the > state that a file is OPEN is sufficient. But you didn't address the issue when the server can support it but only in cases that it knows that it is what the client wants. Suppose we have a server (say the win2k server) that will disallow REMOVE of an OPEN file in the general case. However, it has the underlying capability to allow the client the OPEN, REMOVE, READ sequence. Your proposal doesn't allow the client a method of determining that capability. Maybe Sergey can let us know if this is what his server might do? -- - Spencer - From nfs4-wg-request@sunroof.eng.sun.com Fri Sep 21 17:46:48 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA07202 for ; Fri, 21 Sep 2001 17:46:48 -0400 (EDT) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA06072; Fri, 21 Sep 2001 15:45:59 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA14219; Fri, 21 Sep 2001 14:45:47 -0700 (PDT) Received: from centralmail1.Central.Sun.COM (centralmail1.Central.Sun.COM [129.147.62.10]) by sunroof.eng.sun.com (8.12.0+Sun/8.12.0) with ESMTP id f8LLje7B019286 for ; Fri, 21 Sep 2001 14:45:41 -0700 (PDT) Received: from dhcp-aus08-191.central.sun.com (dhcp-aus08-191.Central.Sun.COM [129.153.128.191]) by centralmail1.Central.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id PAA21330 for ; Fri, 21 Sep 2001 15:45:38 -0600 (MDT) Received: (from shepler@localhost) by dhcp-aus08-191.central.sun.com (8.11.3+Sun/8.11.3) id f8LLjQc00601 for nfsv4-wg@sunroof.eng.sun.com; Fri, 21 Sep 2001 16:45:26 -0500 (CDT) Date: Fri, 21 Sep 2001 16:45:26 -0500 From: Spencer Shepler To: nfsv4-wg@sunroof.eng.sun.com Subject: Re: remove of open file Message-ID: <20010921164526.W398@dhcp-aus08-191.central.sun.com> Reply-To: shepler@eng.sun.com Mail-Followup-To: Spencer Shepler , nfsv4-wg@sunroof.eng.sun.com References: <3BAB731C.C47567E@Sun.COM> <20010921154248.S398@dhcp-aus08-191.central.sun.com> <3BABAB60.CAC08C92@Sun.COM> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3BABAB60.CAC08C92@Sun.COM> User-Agent: Mutt/1.3.19i On Fri, David Robinson wrote: > > I like the approach, David. If we go with something like this, it > > seems like we need to allow for the removal of the file by other means > > at the server. For example, by local access to the fliesystem in > > question. I don't think we should place the burden on the server to > > implement server-wide protection against removal. > > If I understand you correctly, you are arguing > a file opened via NFS but removed through a different mechanism > (local access or different protocol) has undefined > semantics? If so I agree completely. I would encourage > NFS server vendors to implement a best possible solution > that causes the least surprise, but it would not be wise to > mandate a solution. Correct. This is what I was saying. -- - Spencer - From nfs4-wg-request@sunroof.eng.sun.com Fri Sep 21 18:04:29 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA07409 for ; Fri, 21 Sep 2001 18:04:28 -0400 (EDT) Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id QAA17729; Fri, 21 Sep 2001 16:03:40 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id PAA27410; Fri, 21 Sep 2001 15:03:26 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.0+Sun/8.12.0) with ESMTP id f8LM3E7B019305 for ; Fri, 21 Sep 2001 15:03:16 -0700 (PDT) Received: from venus.sun.com (venus.EBay.Sun.COM [129.150.69.5]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id PAA12035 for ; Fri, 21 Sep 2001 15:03:12 -0700 (PDT) Received: from palrel11.hp.com (palrel11.hp.com [156.153.255.246]) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA09698 for ; Fri, 21 Sep 2001 15:03:11 -0700 (PDT) Received: from raptor.cup.hp.com (raptor.cup.hp.com [15.13.130.223]) by palrel11.hp.com (Postfix) with ESMTP id 5BB111F6D3 for ; Fri, 21 Sep 2001 15:03:11 -0700 (PDT) Received: from BM772391 (pal1nai162214.nsr.hp.com [15.244.162.214]) by raptor.cup.hp.com (8.9.3 (PHNE_18546)/8.9.3 SMKit7.02) with SMTP id PAA21070 for ; Fri, 21 Sep 2001 15:11:54 -0700 (PDT) Message-ID: <028201c142e9$363487b0$ae66cf3f@BM772391> From: "buvana mohan" To: Subject: unsubscribe Date: Fri, 21 Sep 2001 15:03:14 -0700 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_027F_01C142AE.898C71B0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2919.6700 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 This is a multi-part message in MIME format. ------=_NextPart_000_027F_01C142AE.898C71B0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable ------=_NextPart_000_027F_01C142AE.898C71B0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
 
------=_NextPart_000_027F_01C142AE.898C71B0-- From nfs4-wg-request@sunroof.eng.sun.com Fri Sep 21 18:06:42 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA07429 for ; Fri, 21 Sep 2001 18:06:42 -0400 (EDT) Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id PAA16082; Fri, 21 Sep 2001 15:06:04 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id PAA27836; Fri, 21 Sep 2001 15:05:45 -0700 (PDT) Received: from phys-ha6nwka.ebay.sun.com (root@phys-ha6nwka.EBay.Sun.COM [129.149.1.82]) by sunroof.eng.sun.com (8.12.0+Sun/8.12.0) with ESMTP id f8LM5b7B019310 for ; Fri, 21 Sep 2001 15:05:38 -0700 (PDT) Received: from Sun.COM (jetsun.Central.Sun.COM [129.153.128.60]) by phys-ha6nwka.ebay.sun.com (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id PAA10736 for ; Fri, 21 Sep 2001 15:05:30 -0700 (PDT) Sender: robinson@phys-ha6nwka.ebay.sun.com Message-ID: <3BABB9AD.5FF74D24@Sun.COM> Date: Fri, 21 Sep 2001 17:05:33 -0500 From: David Robinson Organization: Sun Microsystems, Inc. X-Mailer: Mozilla 4.78 [en] (X11; U; SunOS 5.9 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: nfsv4-wg@sunroof.eng.sun.com Subject: Re: Issues list for RFC3010 References: <3BAB731C.C47567E@Sun.COM> <20010921154508.T398@dhcp-aus08-191.central.sun.com> <3BABADF1.31F31E56@Sun.COM> <20010921164331.V398@dhcp-aus08-191.central.sun.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit > But you didn't address the issue when the server can support it but > only in cases that it knows that it is what the client wants. Suppose > we have a server (say the win2k server) that will disallow REMOVE of > an OPEN file in the general case. However, it has the underlying > capability to allow the client the OPEN, REMOVE, READ sequence. Your > proposal doesn't allow the client a method of determining that > capability. Maybe Sergey can let us know if this is what his server > might do? If I understand this correctly, the question is if there exists a server that will deny a REMOVE differently depending on if the caller was the one who OPENed the file or not. For example, you can only REMOVE an OPEN file if you OPENed it. Sergey, do you know of such a case? I don't. In any case I would advocate that the server can choose to REMOVE an OPEN file or not based on whatever criteria it wishes to use. But if it allows the REMOVE it MUST follow the failure semantics previously described. If someone does come up with a weird OS that would require us to use stateid's or other client state, I will advocate not allowing REMOVE of OPEN files. -David From nfs4-wg-request@sunroof.eng.sun.com Fri Sep 21 18:29:58 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA07733 for ; Fri, 21 Sep 2001 18:29:58 -0400 (EDT) Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id QAA04326; Fri, 21 Sep 2001 16:29:10 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id PAA03889; Fri, 21 Sep 2001 15:29:01 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.0+Sun/8.12.0) with ESMTP id f8LMSn7B019415 for ; Fri, 21 Sep 2001 15:28:50 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id PAA18239 for ; Fri, 21 Sep 2001 15:28:48 -0700 (PDT) From: nyn8xvgz3sttb@hotmail.com Received: from etc.net-seeds.com ([211.6.210.45]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with SMTP id QAA26259 for ; Fri, 21 Sep 2001 16:29:39 -0600 (MDT) Message-Id: <200109212229.QAA26259@lukla.Sun.COM> Received: (qmail 26923 invoked from network); 21 Sep 2001 02:21:18 -0000 Received: from unknown (HELO 12.64.198.31) (12.64.198.31) by etc.net-seeds.com with SMTP; 21 Sep 2001 02:21:18 -0000 To: Subject: ENLARGE YOUR PACAKGE GUARANTEED Date: Sun, 23 Sep 2001 10:04:01 -0400 MIME-Version: 1.0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Priority: 3 X-MSMail-Priority: Normal Errors-To: ctcvvepva9in@intermega.com.br X-Mailer: Microsoft Outlook Express 5.50.4133.2400 Content-Transfer-Encoding: quoted-printable


MEN.....Sto= p Being Ashamed Of Your Penis Size!
Women Get This For Your Boyfriend/Husband 
It REALLY WORKS!

 

<= b>CLICK HERE NOW TO BE AMAZED

 

 






















NOTE:  This email was sent to you because your email is part of a targeted = opt-in list.  If you do not wish to receive further mailings, please c= lick below and enter your email at the bottom of the page.  You may = then rest-assured that you will never receive another email from us again=   UNSU= BSCRIBE ME PLEASE


From nfs4-wg-request@sunroof.eng.sun.com Fri Sep 21 18:39:18 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA07841 for ; Fri, 21 Sep 2001 18:39:17 -0400 (EDT) Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id QAA09832; Fri, 21 Sep 2001 16:38:29 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id PAA06303; Fri, 21 Sep 2001 15:38:22 -0700 (PDT) Received: from centralmail1.Central.Sun.COM (centralmail1.Central.Sun.COM [129.147.62.10]) by sunroof.eng.sun.com (8.12.0+Sun/8.12.0) with ESMTP id f8LMcE7B019541 for ; Fri, 21 Sep 2001 15:38:15 -0700 (PDT) Received: from dhcp-aus08-191.central.sun.com (dhcp-aus08-191.Central.Sun.COM [129.153.128.191]) by centralmail1.Central.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id QAA10397 for ; Fri, 21 Sep 2001 16:38:13 -0600 (MDT) Received: (from shepler@localhost) by dhcp-aus08-191.central.sun.com (8.11.3+Sun/8.11.3) id f8LMc0000708 for nfsv4-wg@sunroof.eng.sun.com; Fri, 21 Sep 2001 17:38:00 -0500 (CDT) Date: Fri, 21 Sep 2001 17:38:00 -0500 From: Spencer Shepler To: "'nfsv4-wg@sunroof.eng.sun.com'" Subject: Re: Issues list for RFC3010 Message-ID: <20010921173800.D398@dhcp-aus08-191.central.sun.com> Reply-To: shepler@eng.sun.com Mail-Followup-To: Spencer Shepler , "'nfsv4-wg@sunroof.eng.sun.com'" References: <8C610D86AF6CD4119C9800B0D0499E3333561D@red.nane.netapp.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <8C610D86AF6CD4119C9800B0D0499E3333561D@red.nane.netapp.com> User-Agent: Mutt/1.3.19i On Fri, Noveck, Dave wrote: > Spencer Shepler wrote: > > On Thu, Jeff A. Smith wrote: > > > "Khan, Saadia" wrote: > > > > > > > > -----Original Message----- > > > > I would like to add some more things to the list which are not very clear as far > > > > as the spec goes: > > > > > > > > Named Attributes: > > > > > > > > 1. Does it make sense to allow setattr on a named attribute dir? Is that > > > > allowed in the spec? And if so what does it mean if the named attr dir has > > > > different perms, uid, gid from the base file and in that case which one is > > > > used for permission checking? > > > > > > > > In similar context, does it make sense to do the same for named attributes? > > > > Or does changing perms, uid, gid for a named attribute change the perms, uid, > > > > gid for the base file. > > > > > > > > > > As I understand it, the spec provides a way to get a filehandle for the > > > attribute directory with OPENATTR, but it does not restrict the how that > > > filehandle can be used. The underlying server fs may restrict the set of > > > operations allowed on attrdirs (for reasons you mentioned), but the spec > > > does not. I think this general answer addresses most of your questions. > > > > As Jeff mentions, the named attribute support was intentially under > > specified. I believe the things you ask about could be allowed for > > certain implementations but I doubt they would not be very useful. My > > preference is to leave this type of functionality under specified and > > allow client named attribute APIs and server implementations drive > > further definition while not restriction the protocol to a particular > > implementation. > > I know this was intentional, but is it the right thing to do? > > Leaving this under-specified opens the way for interoperability > problems which are going to seriously compromise the usefulness > of named attributes, unless somehow there is arrived at a minimal set > of behaviors that clients expect and that all servers that support > named attributes implement. If that's defined, then we can let > the lunatic fringe be the lunatic fringe and go on. If we don't > do this in the spec, I suppose we can do it over a beer at the next > bakeoff. But if we do that, we should let people who aren't there > know what we're intending to do. Point taken. So maybe what we should strive for in the case of the named attribute support is a minimum of specification to allow for interoperability with the maximum amount of flexibility for future implementations. > Some of Saadia's questions deal not with the semantics of the named > attributes themselves but of the named attribute directory itself. > The named attribute directory may not really exist. It is an > artifact to allow named attributes to be (relatively) easily fit > into NFS's file operation paradigm. I'd argue that there is > a difference between leaving something under-specified and leaving > it way under-specified. I can see that there might be interest > in a different and richer named attribute models (I'll admit it is > possible that the lunatic fringe is really just ahead of it's > time). I can't see the same possibility for operations on the named > attribute directory itself. I would argue that SETATTR on the > named attribute directory is an operation that clients should not > use and servers should not implement even if their implementation > (such as making the named attribute directory a more-or-less > normal directory would allow it). I think we'd all be better off > if the spec said so. Okay. So the proposal is to state that for the attribute directory (as returned by OPENATTR) is not an appropriate target for SETATTR. I would propose that GETATTR has limited meaning as well for this directory. > With regard to Saadia's other question, about setting attributes > on named attributes themselves, I would argue that it's best for > the server not to deceive. It may (and probably will) restrict > the set of attibutes that it keeps for named attributes but if > the client asks it to set one that it doesn't keep separately, it > should reject the request rather than set the corresponding > attibute on the base file. I agree and that has been my interpretation. I will add an item to provide this clarification as well. > > I will add an item to the issues list to discuss the possible > > implementations and pitfalls of such. > > > > > 2. Currently a server is required to first check if a named attribute dir > > > > associated with a file/dir actually contains any named attributes before > > > > returning TRUE in the named_attr field for getattr. > > > > > > > > There can be a couple of issues with that. First its very improbable to have > > > > a named attr dir without any named attrs, and second it is possible that a > > > > client is requesting the server for all supported attributes every time it > > > > does a stat call. It can be very expensive for the server to check if the > > > > directory is empty or not everytime it gets one of these calls. > > > > > > > > It should be sufficient for the server to check if the dir exists and return > > > > TRUE for named_attr. > > > > > > > In this case, the spec is trying to be general enough to provide useful > > > information to applications without assuming a particular server fs > > > implementation. I know of at least one server fs where empty attr dirs > > > are not rare. The attrdirs in this file system are like regular dirs > > > in that they are not removed when the last named attribute is removed. > > > I'm not saying I think that design is correct or that I like it -- I'm > > > just saying it exists. > > > > > > If you believe that it is reasonable for an app to set several > > > attributes and clear them later, then empty attr dirs may not be such > > > a rare occurrance in the server file system. For such a file system, > > > checking to see that the attrdir exists would not provide very useful > > > info to the app -- especially if all file system objects had a named > > > attribute at some point in their lifetime. > > I've got to believe that an environment in which all file system objects > have a named attribute during their lifetime but which a large number > don't have one at any given time, is likely to be one in which the file > system would get rid of empty attribute directories automatically. Seems reasonable. No telling what will actually be implemented. > > > I'm not sure I agree with your first statement that servers > > > must check to see that the attrdir actually contains attributes > > > before returning TRUE for named_attr. The server must answer > > > the question correctly, but it might not have to do readdir > > > to do so. If you're writing a nfsv4 server, and all server filesystems > > > remove attrdirs after the last attribute is deleted, (and 3rd party > > > filesystems are not possible), then you can certainly code your > > > NFSv4 server to take advantage of that and simply check for the > > > existance of the attr dir instead of doing readdir. > > I think Saadia was thinking of cases in which the server does not > automatically remove empty named attribute directories. > > In such an environment, it is most probable that if a given object has > a named attribute directory it has some attribute within it but that > is not assured. So in that case, the server, to satisfy a GETATTR > would have to look in the directory, to determine whether it is > empty and then when it turned out it wasn't empty, the client would > typically issue an OPENATTR/READDIR to actually find the attributes > so that the server would wind up looking in the directory twice. We have a pathconf() api that allows the application to ask the question of whether named attributes exist for a particular filesystem object. If there is no protocol support for this question, then the client will have to do the OPENATTR, READDIR sequence itself. Is that a reasonable overhead for something like pathconf()? Obviously, an application that asks that question will more than likely want to enumerate the named attributes so the READDIR would fill a local cache potentially but it seems high overhead for a simple question. > > I don't expect that clients will ask about named attributes that much > > in the general case. We could add language that discourages the > > overuse of the named_attr attribute if that would help. > > There may be a large number of clients, at least initially, that don't > care about named attributes at all, but I'm concerned only about the > ones that do. Well, Solaris, Linux, and the Windows clients will have support for named attributes. Maybe what you meant was that there won't initially be that many applications that use named attributes. :-) > How would you define overuse? I think the purpose of the named_attibute > attribute is so that the client can know whether he should bother > doing the OPENATTR/READDIR when it is of no use. In an environment in > which there are no empty named attribute directories possible, the server > can trivially detremine this. In an environment where empty ones can exist, > the server currently must check even when this is very unlikely to save the > client work. > > So I would argue that the purpose of named_attr is as an optimization > and that it should be defined so that, > > If there are named attributes the server must return TRUE. > > If the server can easily determine that no named attributes > exist, the server should return FALSE. > > If the server determines that it is likely that named attributes > exist but this is not guaranteed the server may return TRUE > and the client will find out that the set of named attributes > is NULL when it does OPENATTR/READDIR. Well, in the case of the pathconf() example I provided, the client will end up doing the OPENATTR, READDIR sequence to answer the pathconf() question correctly (since its definition is not as lenient). What you have proposed can be accomplished by just having the client do an OPENATTR without the proposed CREATE flag. If no filehandle comes back, no attributes exist. If a filehandle comes back, the client does a READDIR to see if any attributes exist in reality. Again, this seems like high overhead for the simple question at the client of "named attributes?". > > > > 3.Should exclusive create be supported for named attributes? > > > > > > > > > > I don't see any reason why it shouldn't, and the spec doesn't specifically > > > disallow it, so I would say yes. I don't have a strong argument for either > > > position, and I generally dislike arbitrary restrictions... This sounds like > > > a good thing to be explicitly stated in the spec. > > > > Since we have taken the model that general operations apply named > > attributes, the answer would be yes. However, with the case of > > exclusive create, we need to be sure that this is something that is > > applicable in the implementations that are planned. Would like to > > avoid specifying something that will not be implemented and removed > > from the specification later on. :-) > > In the particular case of exclusive create, the model is that the > create verifier is stored where the attributes normally are and that > a SETATTR done after. Both of these may present difficulties among some > of the myriad possible implementations. So whatever the spec says, the > real question is whether cleints are going to do this. If they do, > server implementations are going to be constrained. On the other hand, > I can see that this might be a useful facility for the client. > > I'm intrigued by your remark about implementation applicability and > the process of going to Draft Standard (I'm not sure how far back your > smiley was intended to cover). If this rule would apply this way > to exclusive create of named attributes, why wouldn't it also apply > to create of a directory, symlink, or device in a named attribute > in a named attribute directory, openattr-openattr-openattr ad > infinitum, and all the other stuff that I'm currently recoiling from > in horror? It's unlikely that there will two inter-operating > implementations of a lot of those things. Well, we could take it to that extreme for a move to Draft but I would think that exclusive create is so fundamental in this instance that we would want implementation experience. > > > > 4. Does it make sense to rename a named attribute? I dont think it makes > > > > sense to rename a named attribute between different base files. Within > > > > the same file, maybe but even that doesn't make much sense. > > > > > > > Again I don't really have a position, and the spec is general enough > > > to support implementations that support renaming attributes as well > > > as those that don't. Perhaps named attrs should be mentioned in the > > > "rename" implementation section of the spec. > > > > > > I don't have any experience coding apps that use named attrs, so my > > > $0.02 is more like $0.005, but one use of renaming attributes would be > > > to enable atomic set (create named attr with a temp name, write all > > > attr data, then rename it to whatever the "real/proper" name). > > > > Right. This is the example that I have always thought of. Since there > > are named attribute APIs that require atomicity with respect to > > setting a value of the named attribute and NFSv4 does not provide that > > type of atomicity, a WRITE/RENAME sequence could be used in its place. > > > For the case of rename of a named attribute between filesystem > > objects, I believe that is unlikely and the server can return > > NFS4ERR_XDEV in this case (and probably should). I will add this > > clarification to the RENAME operation IMPLEMENTATION section. > > RENAME has lots of interesting cases like rename of a named attribute > to be a regular file and vice versa. LINK also has interesting > possibilities. How about NFS4ERR_WAY_TOO_WEIRD? :-) or NFS4ERR_DEV_your_request_to_black_hole... > > > > 5. Does the spec support deleting the named attribute dir? I think that > > > > deleting a file with named attributes should delete everything with it, > > > > including the dir and all named attributes or the client should be allowed > > > > to delete a single attr. > > > > But allowing a named attr dir to be deleted without deleting the base file > > > > doesn't really make much sense. > > > > > > Because the attrdir has no name and the spec doesn't define a > > > RM_ATTR_DIR op, there's no way to explicitly delete the attrdir. > > > The only way I know of to delete the attrdir is to implicitly > > > delete it by the deleting the base file. This is also a good > > > candidate for clarification in the spec. > > > > > > Of course, a server fs implementation would be free to delete the > > > attrdir after the last attribute was removed. So, it could be > > > possible for the attrdir to be removed without removing the > > > "base file" -- it depends on the server fs implementation. I > > > think it would be totally broken to be able to remove a file > > > without also removing its attributes. > > > Jeff, did you mean to say something like, when a file is REMOVEd the > > named attributes associated with that file should automatically be > > removed (implicitly). It isn't the responsibility of the client to > > first remove all of the named attributes before removing the > > filesystem object. This is different from removal of a regular > > directory that is non-empty. > > This is one problem with the "Named attribute directories are > exactly the same as any other directories except where required > by the nature of named attributes"-model. It is hard to > determine when that is. > > I have another question about what Jeff was saying. I had been > assuming that a "server fs implementation is free to delete the > attrdir after the last attribute was removed" only if the handles > that it created for named attribute directories were such that > they would not go stale simply because a named attribute was deleted. > > To use implementation terms, > > If you have handles for named attribiutes directories that have the > inode number of the base file plus a flag then you can automatically > create the directory when the named attribute is created and delete > it when it is empty. > > However, if you have handles for named attributes that have the inode > number of the named attribute directory, then you can't automatically > delete when the last named attribute goes away sicne this would make > the handle returned by an earlier OPENATTR stale. Are you saying that > you can do the autommatic deletion in this case as well, Jeff? I think we can make the client recover but is that necessary. I don't know. Maybe we should restrict the server's activities with respect to this in that once a filehandle is returned as a result of OPENATTR it is not supposed to go STALE until the associated object is removed. > > The key in the NFSv4 named attribute support is that it allows for > > various implmentations. It is possible that the attribute directory > > returned from OPENATTR doesn't have a corresponding directory at the > > server. The server may choose to implement named attributes in a way > > that really doesn't have a physical directory in the server > > filesystem. > > Multiple implementations are good. > > Multiple interfaces are not so good. > > I'm worried that the current approach allows so much variation > in the operations supported, that it may really wind up turning > into multiple interfaces expressed in a common language rather than > a single interface. So through the implementation experience we are gaining we can work to place the appropriate framing around the current definition to make it useful. > > The specification also allows for named attributes of named > > attributes. > > "But do they go away at Draft Standard if nobody implements them?", > he asked with baited breath. My opinion is, yes, but maybe we should wait until we actually get there before worrying about it too much. > > I realized via this discussion that I had missed an issue related to > > named attributes. We had discussed on the WG alias the addition of a > > CREATE flag to OPENATTR to provide for server implementations that do > > not create a named attribute directory until the first named attribute > > is actually created. Therefore, if the client is just reading the > > attribute directory without the intent of creating a named attribute > > it can used OPENATTR() and the server can return NFS4ERR_NOENT. If > > the client is going to create a named attribute, then it can use > > OPENATTR(CREATE) to have the named directory activated. > > > > I will add this to the issues list. > > I'm pretty sure I saw that in the list already but I don't remember the > number. Well, I added it again if that was the case. :-) -- - Spencer - From nfs4-wg-request@sunroof.eng.sun.com Fri Sep 21 19:26:10 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA08134 for ; Fri, 21 Sep 2001 19:26:09 -0400 (EDT) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id QAA12116; Fri, 21 Sep 2001 16:25:30 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id QAA01022; Fri, 21 Sep 2001 16:25:03 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.0+Sun/8.12.0) with ESMTP id f8LNOs7B019578 for ; Fri, 21 Sep 2001 16:24:54 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id QAA00958 for ; Fri, 21 Sep 2001 16:24:53 -0700 (PDT) From: hv@earthsky.de Received: from mail.arktech.com.tw ([211.23.74.242]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id RAA21590 for ; Fri, 21 Sep 2001 17:25:42 -0600 (MDT) Date: Fri, 21 Sep 2001 17:25:42 -0600 (MDT) Message-Id: <200109212325.RAA21590@lukla.Sun.COM> Received: from h809 (PPPa83-ResaleFtLauderdaleB1-5R7024.dialinx.net [4.4.50.16]) by mail.arktech.com.tw with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id T1FNMLDW; Sat, 22 Sep 2001 07:17:09 +0800 To: hv@earthsky.de Subject: At Last, Herbal V, the All Natural Alternative! MIME-Version: 1.0 Content-Type: text/plain; charset=unknown-8bit Herbal V: An Incredible All-Natural Healthy Alternative To V----a Herbal V is the All Natural Approach to Male Virility, Vitality and Pleasure. Available N o w ! Welcome to the New Sexual Revolution. It's the all natural male potency and pleasure pill that men everywhere are buzzing about. Herbal V is safe, natural and specifically formulated to help support male sexual function and pleasure. You just take two easy-to-swallow tablets one hour before sex. And there's more great news - you can get Herbal V for less than $1 a pill. Amazing word of mouth praise on Herbal V has been spreading like wildfire-already over 1,500,000 men have chosen Herbal V. Since it is 100% natural you will never have to worry about safety. Try doctor-recommended Herbal V today and have the greatest night of your life! Herbal V... Bringing Back the Magic! 1,585,000 men can't be wrong. To date over 1 million men have tried the super supplement Herbal V. Here is why: No Doctor Visit Required Available Over the Counter Not a Drug 100% Natural Safe, No Worries Highest Quality Pharmaceutical-Grade Pure Nutriceuticals Guaranteed Potency & Purity Be a Real Man Again! Questions and Answers What is Herbal V? Herbal V is a proprietary blend that was specifically developed as a safe alternative for men who prefer an all-natural approach to address impotence and boost sexual performance. This amazing formula first became popular with Hollywood insiders and the wealthy elite. They were maximizing their sex lives, long before it was available to the general public. How does Herbal V work? Developed by a team whose goal was to create the perfect all-natural aphrodisiac. Herbal V is the result of that remarkable effort. The Herbal V formula contains a precise blend of cutting edge pro-sexual nutrients from around the world that provide nutritional support, making it possible for a man to have a pleasurable sexual experience. What can Herbal V do for me? Herbal V helps support male sexual function and pleasure in a safe and natural manner. Simply put, it can make your sex life incredible. Is Herbal V Safe? One of the great things about Herbal V is that it is not a drug. It is an incredible herbal dietary supplement that provides nutritional support for male sexual function and pleasure. One of the most comforting features of Herbal V is that you never have to worry about safety. Herbal V: Safe - Natural - Exciting Many have speculated that because Herbal V is so popular with men, it must contain prescription drugs or chemical components. Herbal V does not contain any elements or traces of any prescription drug. Herbal V is made using the world's most technologically advanced state-of-the-art cold processing equipment to ensure maximum purity. Herbal V has been independently analyzed by the nation's premier testing facility to ensure purity, quality and to end the rumors that, because it is so popular, it must somehow be chemical. It is not. Herbal V is natural - just as it says on the label. Herbal V is simply fantastic! Herbal V: Ingredients Yohimbe, saw palmetto, avena sativa, androstenedione, guarana, taurine, siberian ginseng, tribulus terrestris. Tribulus Terrestis is certified to enhance testosterone levels by increasing Luteinzing hormone (LH) levels. Androstenedione which is a precursor to testosterone unlocks bound testosterone and makes it biologically active again quickly. This means a dramatic surge in desire. Avena Sativa Stimulates the neurotransmitter pleasure centers to maximum capacity. This greatly intensifies pleasure. Just listen to what Herbal V has done for the sex lives of people like you! "On a scale of 1 to 10, it's a 15. Electrifying. It's like a wonder pill!" — Justin Q B., New Haven, Texas "I haven't had sexual relations in 11 years. Then with Herbal V it was... wow! It works again!" — Sid R., Lakeland, Florida "I had sex four times in one night. It made me feel like a 19-year-old again." — Chip S, Beech Mountain, North Carolina "Herbal V has turned my husband into a Sexual Superman! I like the fact that it's all natural and has no side effects. It's bringing back the good old days." — Jennifer B, Beverly Hills, California The above testimonials are from product literature, and we have not independently verified them. However, the following testimonial is from a "senior" gentleman who has purchased his second bottle of Herbal V. When we heard his words with our own ears, we asked his permission to print them here. "Man! I'm wild as I can be! I feel like I'm 25 years old again! I'm not believing this!" — Mr. Murphy, age 64, Lampart, IL. Risk Free: Double Your Money Back Guarantee If Herbal V does not give the desired results as stated above, simply return the unused portion for a double-your money back refund. No questions asked ! Order Now: Safe, Fast, Secure, Private Herbal V with its DOUBLE YOUR MONEY BACK GUARANTEE is available only through this special promotional offer. Herbal V arrives in plain packaging for your privacy. Any and all information is kept strictly confidential. Payment Methods You may mail Checks, MasterCard, Visa, & American Express payments or Money Orders. Each bottle of Herbal V contains 30 tablets, approximately a 1 month supply. Step 1: Place a check by your desired quanity. ______ 1 Bottle of Herbal V $28 ______ 2 Bottles of Herbal V $48 ______ 3 Bottles of Herbal V $59 Please add $6 shipping and handling for any size order. [ Total cost including shipping & handling, 1 bottle=$34, 2 bottles=$54, 3 bottles=$65 ] International Orders Please add $18 shipping and handling for any size order. [ Total cost including shipping & handling, 1 bottle=$46, 2 bottles=$66, 3 bottles=$77 ] We cannot accept foreign checks. International money orders or credit cards only. Step 2: Place a check by your desired payment method and complete fields if necessary. _____Check _____Money Order _____American Express Account Number______________________ Exp____/____ _____Visa Account Number______________________ Exp____/____ _____MasterCard Account Number______________________ Exp____/____ Step 3: Please complete and print the following fields clearly. Name ___________________________________________________ Address _________________________________________________ City ____________________________________________________ State ___________________________________________________ Zip _____________________________________________________ E-mail __________________________________________________ Signature _________________________________________________ [ required for check and credit card orders] Mail to: LSN 273 S. State Rd. 7, #193 Margate, FL 33068-5727 ______________________________________________________ This is a one time mailing: Removal is automatic and no further contact is necessary. Please Note: Herbal V is not intended to diagnose, treat, cure or prevent any disease. As individuals differ, so will results. Herbal V helps provide herbal and nutritional support for male sexual performance. The FDA has not evaluated these statements. For details about our double your money back guarantee, please write to the above address, attention consumer affairs department; enclose a self addressed stamped envelope for this and any requested contact information. Thank You. From nfs4-wg-request@sunroof.eng.sun.com Mon Sep 24 09:17:04 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA05101 for ; Mon, 24 Sep 2001 09:17:03 -0400 (EDT) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id DAA18182; Mon, 24 Sep 2001 03:18:32 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id DAA29049; Mon, 24 Sep 2001 03:18:07 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.0+Sun/8.12.0) with ESMTP id f8OAHv7B023065; Mon, 24 Sep 2001 03:17:57 -0700 (PDT) Received: from venus.sun.com (venus.EBay.Sun.COM [129.150.69.5]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id DAA14921; Mon, 24 Sep 2001 03:17:58 -0700 (PDT) From: webmaster4591@yahoo.com Received: from guimail.goldenup.com (host196.21067182.gcn.net.tw [210.67.182.196]) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id DAA12382; Mon, 24 Sep 2001 03:17:56 -0700 (PDT) Message-Id: <200109241017.DAA12382@venus.sun.com> Received: from plain (host193.21067182.gcn.net.tw [210.67.182.193]) by guimail.goldenup.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id TQ22WL6S; Mon, 24 Sep 2001 10:54:21 +0800 To: nft@post.com Subject: ADV: I bet that I make more money in the Web design business than you do. Time:10:45:38 PM Date: Sun, 23 Sep 2001 22:45:38 Mime-Version: 1.0 Content-Type: text/plain; charset="DEFAULT_CHARSET" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2919.6700 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 I bet that I make more money in the Web design business than you do. From the customers I received last month I made $1560 income. I also profited on these people $1000 up front. And you know the funniest part? I didn't even design their sites! They did it for themselves! I bet your sales pitch doesn't come anywhere near mine. My sales pitch looks like this: Free Website! Free .com, .net, or .org name! Free First Month! Free Shopping Cart for E-commerce! Free Secure Credit Card Transaction Server Access! Free Website Editor! (Allows you to control your entire site from anywhere in the world with nothing more than your Internet browser!) Free Website Statistics Analysis! Unlimited everything! Unlimited Email Addresses! Unlimited Hosting Space! Unlimited Bandwidth! Unlimited Pages! Unlimited Capacity of items in the Shopping Cart! Fastest Websites!!! (Hosted on the best servers and bandwidth anywhere!) Website Promotion Options... There is nothing left to add to this service! If you can use a word processor, You can manage your own website! Only $35/month after your first FREE month! Everything you need to be doing business online NOW is here for only $25! (Limited time offer) I have been advertising this pitch on the front of my website for my design business 1 month, I have received over 40 signups. People SIGNUP EVERY SINGLE DAY. Almost, they bunch up on the weekends often. 1 month= $1560 income that comes in every month with no work! I will beat that number this month easily, but assuming I just keep up the same pace, next month will net $3,120 PROFIT. FOR A FACT I will be netting at least $10,720 a month by the end of the year. I got that number after subtracting $8000 to account for cancellations down the line. That is a ton of money! I can not even think of a way to not hit that number unless I completely stopped doing everything. My service is also better. You can't give anyone the as much value as I can. You can't give them the power to control their site as I can. You can't give them the prices that I can. You can't get them online as fast as I can. And even if somehow you found a way to do all that, you won't able to keep your customers as long as I do. Wow. Don't believe me? The interface I give my customers is easier to use than any other I have seen. It is by far the best web based interface you will ever see. A monkey would have a hard time making a site look bad with the software I include for my Customers. I charge them $35 a month and I only pay $10! I know I could charge a lot more for the service, but I am more interested in getting as many customers as possible now, than I am on making more on them. If you did the numbers to make sure I wasn't making them up, you'll see $560 missing this month. Where did it come from? There is an optional search engine submission program, that 70 percent of the people that signup opt for, I charge them $30/month. I pay $10. If they do decide they would like custom work done, no problem. I do it for them, and they don't try to bother me to change little things all the time on their site, because I give them the power to do it themselves, which they prefer. I like it to, keeps my time free for things I enjoy. In addition to being able to get at customers you can't, and being able to upsell them to all the custom design work I like, when ever I like, I bet I have a whole bunch of other things you DO NOT HAVE. Private Labeled to me Website Builder/Store Builder (Best Anywhere) Private Labeled to me Shopping Cart Private Labeled to me WebMail and Pop3 Service Private Labeled to me Secure Server Hosting Private Labeled to me Domain Name Registration Private Labeled to me Search Engine Submission Private Labeled to me Control Panel for FTP, email, user access... I can make as many new templates as I like to start them out from too. I also never have to pay for custom CGI work to provide E-Commerce solutions anymore. It is all done for me already, even the payment gateway integration. I use the same service my end-users use to do design work and It has cut my design time in more than half. I can make a complete E-Commerce enabled site in 15-30 minutes, email, shopping cart, ftp, running on the net! Can you do that?? Long story short. Unless you have some plans I don't know about, My business will be beating yours for sure in about 12 months. Can you compete? Are you getting customers as fast as I am? Are you making as much on them as I am? Is that money you are making staying with you every month? Is there a way for you to provide my customers something I don't? Can you say the same for yourself? I am going to let you in on SECRET now. Even though I know that my business will most likely be making a lot more than yours in 12 months, I am not greedy. I know that BIG money is not in being greedy. I know that No matter how much money my design company makes next year, If I combined 4-5 heavy hitters in the industry they would best me. How can I beat that? Easy. Use my connection with the company that made me what I am, and enabled me to do things that no other design companies could do. I am best friends with the president of the company that designed all the amazing server side software I use to power my business, and I know that if he wanted to, he could start turning on every webdesign company in the world as a dealer if they saw what I was making. So, instead of trying to convince him to not show anyone else the software I use to make so much money (impossible.) I figured out that the best thing for me to team up with him, show other people how I was making all the money that I was, and get cut in on the deal. Long story short. I am making a ton of money retailing my E-Commerce Solution, and I love it. Now that I have tasted that success, I have decided to take it to the next level, and give others the same ability to make that same money I do. I can get you in with the company that I deal with that provided me with all of those amazing things that make my service so awesome. My reward: If I introduce even a few people to my supplier so to speak. And those people become even half as successful with it as I have, I can have my buy rate reduced even further below $10 a month (which is already insanely cheap if you haven't noticed) Your reward: If you will probably be making even more money retailing it than I am. All I am doing is driving traffic to my website, people signup. You probably already have a customer base underneath you that would love the product, and are more likely to offer the custom design work than I. I don't do flash, and I don't even advertise on my site that I do custom design work at all. You know, I'll tell you the truth, this interface is so easy that anyone could do it. HTML knowledge or not, really anyone can be a full Design/Hosting/E-Commerce solution provider with this. They even will bill your customers for free for you. Saved me the trouble of getting another merchant account to accept credit cards for this. I paid over $2000 for the privledge of being able to do what I do. I am extremely happy about that because I know people who have paid over $7,000 to do the same. The ball game has changed though. They want to bring on successful dealers like me NOW. And to make this easier, they have dropped the pricing to $99, $299, or $999 depending on how good you want your buy rates. At $999 they are even eating the setup fees ($10 gets your customer a free domain name, and first month). Since I know how powerful a sales tool my website is, and I want everyone I bring on to be as successful as possible, I will even give you a copy of my website (customized to look like you invented it though) hosted for free to sell from. I know it works because I get signups every day. Then you are almost guaranteed to make a ton of money with it, as long as you get traffic to it. If you want to see some of the sites built by my solution, the site I have great success selling from, or how I make all the money I do with it, and how you can to, or to show awesome the software is to use, call me or email me. 1-888-549-0766 or 1-954-585-6460 This week only. Monday-Saturday 11-7 EST. If you do not wish to receive email from me, email: webmaster0273@yahoo.com (anything that goes here gets removed) or call. From nfs4-wg-request@sunroof.eng.sun.com Mon Sep 24 09:17:27 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA05150 for ; Mon, 24 Sep 2001 09:17:27 -0400 (EDT) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA11620; Sun, 23 Sep 2001 11:11:36 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA24704; Sun, 23 Sep 2001 10:10:58 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.0+Sun/8.12.0) with ESMTP id f8NHAk7B021785 for ; Sun, 23 Sep 2001 10:10:46 -0700 (PDT) Received: from venus.sun.com (venus.EBay.Sun.COM [129.150.69.5]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA10171 for ; Sun, 23 Sep 2001 10:10:49 -0700 (PDT) Received: from mx01-a.netapp.com (mx01-a.netapp.com [198.95.226.53]) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA22477 for ; Sun, 23 Sep 2001 10:10:49 -0700 (PDT) Received: from hawk.corp.netapp.com (mh02 [10.10.20.101]) by mx01-a.netapp.com (8.11.1/8.11.1/NTAP-1.2) with ESMTP id f8NHB5903146; Sun, 23 Sep 2001 10:11:05 -0700 (PDT) Received: from ussvlexc01.corp.netapp.com (localhost [127.0.0.1]) by hawk.corp.netapp.com (8.11.1/8.11.1/NTAP-1.2) with ESMTP id f8NHAm906706; Sun, 23 Sep 2001 10:10:48 -0700 (PDT) Received: by ussvlexc01.corp.netapp.com with Internet Mail Service (5.5.2653.19) id ; Sun, 23 Sep 2001 10:10:02 -0700 Message-ID: <8C610D86AF6CD4119C9800B0D0499E33335624@red.nane.netapp.com> From: "Noveck, Dave" To: "'David Robinson'" , nfsv4-wg@sunroof.eng.sun.com Subject: RE: Issues list for RFC3010 Date: Sun, 23 Sep 2001 10:10:41 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" This isn't exactly what you were asking about, but I think there is a case in which your approach would require some identification of who is doing the remove, at least to the clientid granularity. Consider a file which is opened by processes on two different clients, A and B. Now suppose A does a remove and the server does not support a delete on last close mechanism to it returns NFS4ERR_NO_CAN_DO_USE_THE_OLD_HACK_PLEASE. So client renames the file. Now the application on A does a close so it now removes the file. But the server knows that the file is open and would return that same NFS4ERR_NO_CAN_DO_USE_THE_OLD_HACK_PLEASE and the client has no way of dealing with that that since he has no way of knowing when the global last close will occur and, by hypothesis the server can't do the remove at the appropriate time either. And further there is no way for the client to force the remove immediately either. If the REMOVE had a clientid parameter, the server could only check opens for that client and return HACK_PLEASE only if the file were opened by that client. Then, in the example above, the file would actually get removed when it was closed by A, which would certainly annoy B, but is no worse than what happens now (i.e in V2 and V3). An alternative would be to pass a parameter flag that indicates this is a hack remove, this_is_the_hack_so_dont_ask_for_the_hack, which would also force an immediate remove in this situation, independent of any opens of the file, unless the server dupported delete on last close. -----Original Message----- From: David Robinson [mailto:David.Robinson@Sun.COM] Sent: Friday, September 21, 2001 6:06 PM To: nfsv4-wg@sunroof.eng.sun.com Subject: Re: Issues list for RFC3010 > But you didn't address the issue when the server can support it but > only in cases that it knows that it is what the client wants. Suppose > we have a server (say the win2k server) that will disallow REMOVE of > an OPEN file in the general case. However, it has the underlying > capability to allow the client the OPEN, REMOVE, READ sequence. Your > proposal doesn't allow the client a method of determining that > capability. Maybe Sergey can let us know if this is what his server > might do? If I understand this correctly, the question is if there exists a server that will deny a REMOVE differently depending on if the caller was the one who OPENed the file or not. For example, you can only REMOVE an OPEN file if you OPENed it. Sergey, do you know of such a case? I don't. In any case I would advocate that the server can choose to REMOVE an OPEN file or not based on whatever criteria it wishes to use. But if it allows the REMOVE it MUST follow the failure semantics previously described. If someone does come up with a weird OS that would require us to use stateid's or other client state, I will advocate not allowing REMOVE of OPEN files. -David From nfs4-wg-request@sunroof.eng.sun.com Mon Sep 24 10:08:57 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA11393 for ; Mon, 24 Sep 2001 10:08:57 -0400 (EDT) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id SAA08039; Sun, 23 Sep 2001 18:14:54 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id SAA06611; Sun, 23 Sep 2001 18:13:34 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.0+Sun/8.12.0) with ESMTP id f8O1DN7B022165 for ; Sun, 23 Sep 2001 18:13:23 -0700 (PDT) Received: from venus.sun.com (venus.EBay.Sun.COM [129.150.69.5]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id SAA26204 for ; Sun, 23 Sep 2001 18:13:25 -0700 (PDT) From: OnLineCasino113@yahoo.com Received: from globalsys.globalsys.co.kr ([211.234.67.130]) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id SAA14230 for ; Sun, 23 Sep 2001 18:13:23 -0700 (PDT) Received: from sdn-ar-002riprovP180.dialsprint.net_[206.133.176.220] (sdn-ar-002riprovP180.dialsprint.net [206.133.176.220]) by globalsys.globalsys.co.kr (8.11.4/8.9.3) with SMTP id f8O1C6524754; Mon, 24 Sep 2001 10:12:11 +0900 (KST) Received: from BMS-243[212.187.02.211]wx-y_jl6-3 by sdn-ar-002riprovP180.dialsprint.net with ESMTP; Sun, 23 Sep 2001 21:16:23 -0400 Message-ID: <00005b6718ab$00005425$00004539@BMS-243[212.187.02.211]wx-y_jl6-3> To: Subject: Win A Band New Ferrari Spider 360 17721 Date: Sun, 23 Sep 2001 21:16:21 -0400 MIME-Version: 1.0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Priority: 1 X-MSMail-Priority: High Reply-To: life_quotes@uole.com Content-Transfer-Encoding: quoted-printable Welcome to Vegas on the Internet

Welcome to Vegas on the Internet!

The Worlds Largest Online Casino!

We are giving away a Brand New Ferrari Spider 360 worth <= font color=3D"#008000">$240,000.00,
also a Honda Acc= ord EX-V6 worth $28,000.00 and muc= h more!

Open 24-7 with the BES= T pay outs
of ALL online casino's! Play now win BIG!

Win a New CAR! Click Here To Enter!


To be Removed, Reply with Remove in Subject!

From nfs4-wg-request@sunroof.eng.sun.com Mon Sep 24 13:11:20 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA24282 for ; Mon, 24 Sep 2001 13:11:20 -0400 (EDT) Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA04686; Mon, 24 Sep 2001 11:11:15 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA04002; Mon, 24 Sep 2001 10:10:44 -0700 (PDT) Received: from phys-ha6nwka.ebay.sun.com (root@phys-ha6nwka.EBay.Sun.COM [129.149.1.82]) by sunroof.eng.sun.com (8.12.0+Sun/8.12.0) with ESMTP id f8OHAS7B023989 for ; Mon, 24 Sep 2001 10:10:28 -0700 (PDT) Received: from Sun.COM (jetsun.Central.Sun.COM [129.153.128.60]) by phys-ha6nwka.ebay.sun.com (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA20869 for ; Mon, 24 Sep 2001 10:10:25 -0700 (PDT) Sender: robinson@phys-ha6nwka.ebay.sun.com Message-ID: <3BAF6905.98B1D7DF@Sun.COM> Date: Mon, 24 Sep 2001 12:10:29 -0500 From: David Robinson Organization: Sun Microsystems, Inc. X-Mailer: Mozilla 4.78 [en] (X11; U; SunOS 5.9 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: nfsv4-wg@sunroof.eng.sun.com Subject: REMOVE of an OPEN file References: <8C610D86AF6CD4119C9800B0D0499E33335624@red.nane.netapp.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit "Noveck, Dave" wrote: [Yet another insightful comment] I am inclined to try and keep the protocol as simple as possible in these scenerios and accept that one of the goals of NFSv4 is to NOT provide a distributed consistent namespace. The scenerios with a single client operating on an open file have been discussed and appear to be fairly clear. The interesting case appears to be when a server will not remove an open file and a client other than the one doing the remove has the file open. If the server has a file that is open by some client, or even a local open, it will fail the remove regardless of whether the remove is from a client doing the temp file trick or some hapless user doing a /bin/rm of the file. In either case the remove will fail and the server should respond with an error indicating it failed due to the file being open and not some generic permissions problem. In the latter case we can design a complex mechanism to create a remove on last global close, but I don't think it is worth the effort. The client may choose to do some complex tracking, but as with other parts of NFS, sometimes the server just won't let the client do what it thinks it should be able to. So the client must issue an error to the caller and let the chips fall where they may. In the former case, the client knows it is trying to remove an open file and must assume the removed failed because it had the file open and has no way of determining if some other client also has it open as well. So it does the old rename hack. When it finally attempts to do the remove after it closes the file, it is in exactly the same situation as described above, a client removing a file it doesn't have open but the server is failing the request because it thinks it is still open. Like the previous case the client must just determine what is acceptable behavior and what to do with the application (e.g. return an error on close, silently just continue. or fork a thread to keep trying to remove the file). We could add complexity like adding a clientid to remove, but this adds a bunch of server state and troublesome recovery semantics. Realistically only the client knows what it wants and trying to communicate the multitude of possibilities to the server through a couple flags doesn't seem worth the effort. We may have some orphaned files, but that already happens with today's rename hack. So in summary, while Dave's scenerio is valid, I don't think it is any different than other situations where a server may refuse a remove. From a protocol specification perspective, if the server cannot remove an open file, it should return NFS4ERR_NO_CAN_DO_FILE_OPEN and it is up to the client to determine what it thinks is best. It can choose to error to the application, do the rename hack, keep polling the server with removes, or reboot, whatever it thinks is best. If the server does support removal of an open file it must track the number of opens and provide the previously described recovery semantics. -David From nfs4-wg-request@sunroof.eng.sun.com Mon Sep 24 14:07:21 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA26676 for ; Mon, 24 Sep 2001 14:07:20 -0400 (EDT) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA23338; Mon, 24 Sep 2001 12:07:17 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA16745; Mon, 24 Sep 2001 11:07:02 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.0+Sun/8.12.0) with ESMTP id f8OI6q7B024167 for ; Mon, 24 Sep 2001 11:06:52 -0700 (PDT) Received: from venus.sun.com (venus.EBay.Sun.COM [129.150.69.5]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA07569 for ; Mon, 24 Sep 2001 11:06:53 -0700 (PDT) Received: from mx01-a.netapp.com (mx01-a.netapp.com [198.95.226.53]) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA15577 for ; Mon, 24 Sep 2001 11:06:52 -0700 (PDT) Received: from hawk.corp.netapp.com (mh02 [10.10.20.101]) by mx01-a.netapp.com (8.11.1/8.11.1/NTAP-1.2) with ESMTP id f8OI78910226; Mon, 24 Sep 2001 11:07:08 -0700 (PDT) Received: from ussvlexc06.corp.netapp.com (localhost [127.0.0.1]) by hawk.corp.netapp.com (8.11.1/8.11.1/NTAP-1.2) with ESMTP id f8OI6pQ26363; Mon, 24 Sep 2001 11:06:51 -0700 (PDT) Received: by ussvlexc06.corp.netapp.com with Internet Mail Service (5.5.2653.19) id ; Mon, 24 Sep 2001 10:51:42 -0700 Message-ID: <8C610D86AF6CD4119C9800B0D0499E33335629@red.nane.netapp.com> From: "Noveck, Dave" To: "'David Robinson'" , "'nfsv4-wg@sunroof.eng.sun.com'" Subject: RE: REMOVE of an OPEN file Date: Mon, 24 Sep 2001 11:06:48 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" I agree that it is not worth the effort to create a global mechanism for delete-on-last-close when the server does not support delete-on-last-close. David Robinson writes: > We could add complexity like adding a clientid to > remove, but this adds a bunch of server state > and troublesome recovery semantics. I don't see that this adds much server state. The server has to be able to know what clientid each open it has is for. And I don't see any troublesome recovery semantics. The question is the goal here. This solution, without the client id, doesn't allow an open file to be removed out from under the application and that's good. It does make the client do a fair amount of work to make reasonably sure that the file eventually gets removed. Adding the client id reduces the work for the client implementing the rename hack (realistically he will periodically retry), but it does mean that sometimes a file will be removed out from under an application with an open file (i.e. V3-like behavior is possible). For me, the important thing is that the protocol allows servers to implement delete-on-last-close without creating an unacceptable situation for those that can't. I think this proposal does that either with or without the clientid on REMOVE. -----Original Message----- From: David Robinson [mailto:David.Robinson@Sun.COM] Sent: Monday, September 24, 2001 1:10 PM To: nfsv4-wg@sunroof.eng.sun.com Subject: REMOVE of an OPEN file "Noveck, Dave" wrote: [Yet another insightful comment] I am inclined to try and keep the protocol as simple as possible in these scenerios and accept that one of the goals of NFSv4 is to NOT provide a distributed consistent namespace. The scenerios with a single client operating on an open file have been discussed and appear to be fairly clear. The interesting case appears to be when a server will not remove an open file and a client other than the one doing the remove has the file open. If the server has a file that is open by some client, or even a local open, it will fail the remove regardless of whether the remove is from a client doing the temp file trick or some hapless user doing a /bin/rm of the file. In either case the remove will fail and the server should respond with an error indicating it failed due to the file being open and not some generic permissions problem. In the latter case we can design a complex mechanism to create a remove on last global close, but I don't think it is worth the effort. The client may choose to do some complex tracking, but as with other parts of NFS, sometimes the server just won't let the client do what it thinks it should be able to. So the client must issue an error to the caller and let the chips fall where they may. In the former case, the client knows it is trying to remove an open file and must assume the removed failed because it had the file open and has no way of determining if some other client also has it open as well. So it does the old rename hack. When it finally attempts to do the remove after it closes the file, it is in exactly the same situation as described above, a client removing a file it doesn't have open but the server is failing the request because it thinks it is still open. Like the previous case the client must just determine what is acceptable behavior and what to do with the application (e.g. return an error on close, silently just continue. or fork a thread to keep trying to remove the file). We could add complexity like adding a clientid to remove, but this adds a bunch of server state and troublesome recovery semantics. Realistically only the client knows what it wants and trying to communicate the multitude of possibilities to the server through a couple flags doesn't seem worth the effort. We may have some orphaned files, but that already happens with today's rename hack. So in summary, while Dave's scenerio is valid, I don't think it is any different than other situations where a server may refuse a remove. From a protocol specification perspective, if the server cannot remove an open file, it should return NFS4ERR_NO_CAN_DO_FILE_OPEN and it is up to the client to determine what it thinks is best. It can choose to error to the application, do the rename hack, keep polling the server with removes, or reboot, whatever it thinks is best. If the server does support removal of an open file it must track the number of opens and provide the previously described recovery semantics. -David From nfs4-wg-request@sunroof.eng.sun.com Mon Sep 24 14:09:32 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA26726 for ; Mon, 24 Sep 2001 14:09:31 -0400 (EDT) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id LAA08905; Mon, 24 Sep 2001 11:09:20 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA16898; Mon, 24 Sep 2001 11:07:24 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.0+Sun/8.12.0) with ESMTP id f8OI7E7B024170 for ; Mon, 24 Sep 2001 11:07:14 -0700 (PDT) Received: from venus.sun.com (venus.EBay.Sun.COM [129.150.69.5]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA18677 for ; Mon, 24 Sep 2001 11:07:15 -0700 (PDT) Received: from tor01x3.hcl.com (mx5.hcl.com [199.71.120.69]) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA15819 for ; Mon, 24 Sep 2001 11:07:14 -0700 (PDT) Received: from av0011 (av0011.hcl.com [10.1.42.240]) by tor01x3.hcl.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id TLHH3XN0; Mon, 24 Sep 2001 14:07:11 -0400 Received: FROM null.hcl.com BY av0011 ; Mon Sep 24 14:07:26 2001 -0400 Received: from sergeylt (sergeylt.hcl.com [10.1.14.29]) by null.hcl.com (8.11.2/8.11.3) with SMTP id f8OI7DB17815; Mon, 24 Sep 2001 14:07:13 -0400 (EDT) From: "Sergey Klyushin" To: "Noveck, Dave" , "'David Robinson'" , Subject: RE: Issues list for RFC3010 Date: Mon, 24 Sep 2001 14:07:37 -0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 In-Reply-To: <8C610D86AF6CD4119C9800B0D0499E33335624@red.nane.netapp.com> Content-Transfer-Encoding: 7bit Here is how OpenFile/CreateFile works on Windows (locally): 1. OpenFile/CreateFile has one more share attribute FILE_SHARE_DELETE 1.1 If file is opened WITH FILE_SHARE_DELETE, than request from ANOTHER application to REMOVE file will succeed. File won't be removed immediately, but will be removed on the last CLOSE request. New OPENs will fail (with exception OPEN to DELETE). File still will be listed in directory Attempt to create file with the same name will fail. 1.2 If file is opened WITHOUT FILE_SHARE_DELETE, than request from ANOTHER application to REMOVE file will FAIL. 2. OpenFile/CreateFile has lots of flags one of which is FILE_FLAG_DELETE_ON_CLOSE (kind of intention OPEN,REMOVE,READ) If this flag is specified at OPEN/CREATE, than file be deleted on last CLOSE. 3. File has attribute DELETE_PENDING, that explains application why it could not be OPENED other than for deleting. I am trying to implement NFS as much close to local (Windows) OS as possible, but some operations could not be implemented. I understand that NFS protocol can't cover all OSs, but if we could cover as much local OSs as possible, we'll benefit it later. Sergey > -----Original Message----- > From: Noveck, Dave [mailto:Dave.Noveck@netapp.com] > Sent: Sunday, September 23, 2001 1:11 PM > To: 'David Robinson'; nfsv4-wg@sunroof.eng.sun.com > Subject: RE: Issues list for RFC3010 > > > This isn't exactly what you were asking about, but I think > there is a case in which your approach would require some > identification of who is doing the remove, at least to the > clientid granularity. > > Consider a file which is opened by processes on two different > clients, A and B. Now suppose A does a remove and the > server does not support a delete on last close mechanism > to it returns NFS4ERR_NO_CAN_DO_USE_THE_OLD_HACK_PLEASE. > So client renames the file. Now the application on A > does a close so it now removes the file. But the server > knows that the file is open and would return that same > NFS4ERR_NO_CAN_DO_USE_THE_OLD_HACK_PLEASE and the client > has no way of dealing with that that since he has no way > of knowing when the global last close will occur and, by > hypothesis the server can't do the remove at the appropriate > time either. And further there is no way for the client to > force the remove immediately either. > > If the REMOVE had a clientid parameter, the server could only > check opens for that client and return HACK_PLEASE only if > the file were opened by that client. Then, in the example > above, the file would actually get removed when it was closed > by A, which would certainly annoy B, but is no worse than what > happens now (i.e in V2 and V3). > > An alternative would be to pass a parameter flag that indicates > this is a hack remove, this_is_the_hack_so_dont_ask_for_the_hack, > which would also force an immediate remove in this situation, > independent of any opens of the file, unless the server dupported > delete on last close. > > > -----Original Message----- > From: David Robinson [mailto:David.Robinson@Sun.COM] > Sent: Friday, September 21, 2001 6:06 PM > To: nfsv4-wg@sunroof.eng.sun.com > Subject: Re: Issues list for RFC3010 > > > > But you didn't address the issue when the server can support it but > > only in cases that it knows that it is what the client > wants. Suppose > > we have a server (say the win2k server) that will disallow REMOVE of > > an OPEN file in the general case. However, it has the underlying > > capability to allow the client the OPEN, REMOVE, READ > sequence. Your > > proposal doesn't allow the client a method of determining that > > capability. Maybe Sergey can let us know if this is what his server > > might do? > > If I understand this correctly, the question is if there > exists a server > that will deny a REMOVE differently depending on if the caller was the > one who OPENed the file or not. For example, you can only > REMOVE an OPEN > file if you OPENed it. Sergey, do you know of such a case? I don't. > > In any case I would advocate that the server can choose to REMOVE an > OPEN file or not based on whatever criteria it wishes to use. But > if it allows the REMOVE it MUST follow the failure semantics > previously > described. > > If someone does come up with a weird OS that would require us to > use stateid's or other client state, I will advocate not allowing > REMOVE of OPEN files. > > -David > From nfs4-wg-request@sunroof.eng.sun.com Mon Sep 24 15:13:19 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA28290 for ; Mon, 24 Sep 2001 15:13:19 -0400 (EDT) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id MAA11260; Mon, 24 Sep 2001 12:13:24 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA03095; Mon, 24 Sep 2001 12:12:57 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.0+Sun/8.12.0) with ESMTP id f8OJCk7B024218 for ; Mon, 24 Sep 2001 12:12:46 -0700 (PDT) Received: from venus.sun.com (venus.EBay.Sun.COM [129.150.69.5]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA28438 for ; Mon, 24 Sep 2001 12:12:48 -0700 (PDT) Received: from tor01x3.hcl.com (mx5.hcl.com [199.71.120.69]) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA20031 for ; Mon, 24 Sep 2001 12:12:47 -0700 (PDT) Received: from av0011 (av0011.hcl.com [10.1.42.240]) by tor01x3.hcl.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id TLHH3ZL2; Mon, 24 Sep 2001 15:12:41 -0400 Received: FROM null.hcl.com BY av0011 ; Mon Sep 24 15:12:56 2001 -0400 Received: from sergeylt (sergeylt.hcl.com [10.1.14.29]) by null.hcl.com (8.11.2/8.11.3) with SMTP id f8OJChB27713; Mon, 24 Sep 2001 15:12:43 -0400 (EDT) From: "Sergey Klyushin" To: "Noveck, Dave" , "'David Robinson'" , Subject: RE: REMOVE of an OPEN file Date: Mon, 24 Sep 2001 15:13:07 -0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 In-Reply-To: Content-Transfer-Encoding: 7bit > -----Original Message----- > From: Sergey Klyushin [mailto:Sergey.Klyushin@hummingbird.com] > Sent: Monday, September 24, 2001 2:08 PM > To: Noveck, Dave; 'David Robinson'; nfsv4-wg@sunroof.eng.sun.com > Subject: RE: Issues list for RFC3010 > > > Here is how OpenFile/CreateFile works on Windows (locally): > 1. OpenFile/CreateFile has one more share attribute FILE_SHARE_DELETE > 1.1 If file is opened WITH FILE_SHARE_DELETE, than request > from ANOTHER > application to REMOVE file will succeed. > File won't be removed immediately, but will be removed on the > last CLOSE > request. > New OPENs will fail (with exception OPEN to DELETE). > File still will be listed in directory > Attempt to create file with the same name will fail. > 1.2 If file is opened WITHOUT FILE_SHARE_DELETE, than request > from ANOTHER > application to REMOVE file will FAIL. > > 2. OpenFile/CreateFile has lots of flags one of which is > FILE_FLAG_DELETE_ON_CLOSE (kind of intention OPEN,REMOVE,READ) > If this flag is specified at OPEN/CREATE, than file be deleted on last > CLOSE. One more detail. If FILE_FLAG_DELETE_ON_CLOSE was specified on OPEN, than subsequent open requests for the file will fail, unless FILE_SHARE_DELETE is used. > > 3. File has attribute DELETE_PENDING, that explains > application why it could > not be OPENED other than for deleting. > > I am trying to implement NFS as much close to local (Windows) OS as > possible, but some operations could not be > implemented. I understand that NFS protocol can't cover all > OSs, but if we > could cover as much local OSs as possible, > we'll benefit it later. > > Sergey > > > -----Original Message----- > > From: Noveck, Dave [mailto:Dave.Noveck@netapp.com] > > Sent: Sunday, September 23, 2001 1:11 PM > > To: 'David Robinson'; nfsv4-wg@sunroof.eng.sun.com > > Subject: RE: Issues list for RFC3010 > > > > > > This isn't exactly what you were asking about, but I think > > there is a case in which your approach would require some > > identification of who is doing the remove, at least to the > > clientid granularity. > > > > Consider a file which is opened by processes on two different > > clients, A and B. Now suppose A does a remove and the > > server does not support a delete on last close mechanism > > to it returns NFS4ERR_NO_CAN_DO_USE_THE_OLD_HACK_PLEASE. > > So client renames the file. Now the application on A > > does a close so it now removes the file. But the server > > knows that the file is open and would return that same > > NFS4ERR_NO_CAN_DO_USE_THE_OLD_HACK_PLEASE and the client > > has no way of dealing with that that since he has no way > > of knowing when the global last close will occur and, by > > hypothesis the server can't do the remove at the appropriate > > time either. And further there is no way for the client to > > force the remove immediately either. > > > > If the REMOVE had a clientid parameter, the server could only > > check opens for that client and return HACK_PLEASE only if > > the file were opened by that client. Then, in the example > > above, the file would actually get removed when it was closed > > by A, which would certainly annoy B, but is no worse than what > > happens now (i.e in V2 and V3). > > > > An alternative would be to pass a parameter flag that indicates > > this is a hack remove, > this_is_the_hack_so_dont_ask_for_the_hack, > > which would also force an immediate remove in this situation, > > independent of any opens of the file, unless the server > dupported > > delete on last close. > > > > > > -----Original Message----- > > From: David Robinson [mailto:David.Robinson@Sun.COM] > > Sent: Friday, September 21, 2001 6:06 PM > > To: nfsv4-wg@sunroof.eng.sun.com > > Subject: Re: Issues list for RFC3010 > > > > > > > But you didn't address the issue when the server can > support it but > > > only in cases that it knows that it is what the client > > wants. Suppose > > > we have a server (say the win2k server) that will > disallow REMOVE of > > > an OPEN file in the general case. However, it has > the underlying > > > capability to allow the client the OPEN, REMOVE, READ > > sequence. Your > > > proposal doesn't allow the client a method of determining that > > > capability. Maybe Sergey can let us know if this is > what his server > > > might do? > > > > If I understand this correctly, the question is if there > > exists a server > > that will deny a REMOVE differently depending on if the > caller was the > > one who OPENed the file or not. For example, you can only > > REMOVE an OPEN > > file if you OPENed it. Sergey, do you know of such a > case? I don't. > > > > In any case I would advocate that the server can choose > to REMOVE an > > OPEN file or not based on whatever criteria it wishes > to use. But > > if it allows the REMOVE it MUST follow the failure semantics > > previously > > described. > > > > If someone does come up with a weird OS that would require us to > > use stateid's or other client state, I will advocate > not allowing > > REMOVE of OPEN files. > > > > -David > > > From nfs4-wg-request@sunroof.eng.sun.com Mon Sep 24 21:42:43 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA05871 for ; Mon, 24 Sep 2001 21:42:43 -0400 (EDT) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id TAA26012; Mon, 24 Sep 2001 19:42:37 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id SAA18351; Mon, 24 Sep 2001 18:42:22 -0700 (PDT) Received: from centralmail1.Central.Sun.COM (centralmail1.Central.Sun.COM [129.147.62.10]) by sunroof.eng.sun.com (8.12.0+Sun/8.12.0) with ESMTP id f8P1g57B024996 for ; Mon, 24 Sep 2001 18:42:05 -0700 (PDT) Received: from dhcp-aus08-191.central.sun.com (dhcp-aus08-191.Central.Sun.COM [129.153.128.191]) by centralmail1.Central.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id TAA09502; Mon, 24 Sep 2001 19:42:07 -0600 (MDT) Received: (from shepler@localhost) by dhcp-aus08-191.central.sun.com (8.11.3+Sun/8.11.3) id f8P1ftD00919; Mon, 24 Sep 2001 20:41:55 -0500 (CDT) Date: Mon, 24 Sep 2001 20:41:55 -0500 From: Spencer Shepler To: Sergey Klyushin Cc: nfsv4-wg@sunroof.eng.sun.com Subject: open/remove sequence Message-ID: <20010924204155.M608@dhcp-aus08-191.central.sun.com> Reply-To: shepler@eng.sun.com Mail-Followup-To: Spencer Shepler , Sergey Klyushin , nfsv4-wg@sunroof.eng.sun.com References: <8C610D86AF6CD4119C9800B0D0499E33335624@red.nane.netapp.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.3.19i Sergey, It seems, from your description, that the windows functionality is different from Unix in that when a Unix application removes the open file, it is removed from the namespace. An open() can then succeed with the same name as the removed file without restriction with respect to the impending close() of that removed file. Also from your description, the windows client can emulate everything about remove on close except for failing OPENs from other clients. Have you found that this set of options is used often in windows? Since we seem to have this fundamental difference it isn't clear to me which (if either) piece of functionality we should attempt to provide. Should we provide the simple functionality that David has suggested? I am not sure that many server's will implement it. Should we wait until a minor version to consider adding a more complex REMOVE op? Spencer On Mon, Sergey Klyushin wrote: > Here is how OpenFile/CreateFile works on Windows (locally): > 1. OpenFile/CreateFile has one more share attribute FILE_SHARE_DELETE > 1.1 If file is opened WITH FILE_SHARE_DELETE, than request from ANOTHER > application to REMOVE file will succeed. > File won't be removed immediately, but will be removed on the last CLOSE > request. > New OPENs will fail (with exception OPEN to DELETE). > File still will be listed in directory > Attempt to create file with the same name will fail. > 1.2 If file is opened WITHOUT FILE_SHARE_DELETE, than request from ANOTHER > application to REMOVE file will FAIL. > > 2. OpenFile/CreateFile has lots of flags one of which is > FILE_FLAG_DELETE_ON_CLOSE (kind of intention OPEN,REMOVE,READ) > If this flag is specified at OPEN/CREATE, than file be deleted on last > CLOSE. > > 3. File has attribute DELETE_PENDING, that explains application why it could > not be OPENED other than for deleting. > > I am trying to implement NFS as much close to local (Windows) OS as > possible, but some operations could not be > implemented. I understand that NFS protocol can't cover all OSs, but if we > could cover as much local OSs as possible, > we'll benefit it later. > > Sergey > > > -----Original Message----- > > From: Noveck, Dave [mailto:Dave.Noveck@netapp.com] > > Sent: Sunday, September 23, 2001 1:11 PM > > To: 'David Robinson'; nfsv4-wg@sunroof.eng.sun.com > > Subject: RE: Issues list for RFC3010 > > > > > > This isn't exactly what you were asking about, but I think > > there is a case in which your approach would require some > > identification of who is doing the remove, at least to the > > clientid granularity. > > > > Consider a file which is opened by processes on two different > > clients, A and B. Now suppose A does a remove and the > > server does not support a delete on last close mechanism > > to it returns NFS4ERR_NO_CAN_DO_USE_THE_OLD_HACK_PLEASE. > > So client renames the file. Now the application on A > > does a close so it now removes the file. But the server > > knows that the file is open and would return that same > > NFS4ERR_NO_CAN_DO_USE_THE_OLD_HACK_PLEASE and the client > > has no way of dealing with that that since he has no way > > of knowing when the global last close will occur and, by > > hypothesis the server can't do the remove at the appropriate > > time either. And further there is no way for the client to > > force the remove immediately either. > > > > If the REMOVE had a clientid parameter, the server could only > > check opens for that client and return HACK_PLEASE only if > > the file were opened by that client. Then, in the example > > above, the file would actually get removed when it was closed > > by A, which would certainly annoy B, but is no worse than what > > happens now (i.e in V2 and V3). > > > > An alternative would be to pass a parameter flag that indicates > > this is a hack remove, this_is_the_hack_so_dont_ask_for_the_hack, > > which would also force an immediate remove in this situation, > > independent of any opens of the file, unless the server dupported > > delete on last close. > > > > > > -----Original Message----- > > From: David Robinson [mailto:David.Robinson@Sun.COM] > > Sent: Friday, September 21, 2001 6:06 PM > > To: nfsv4-wg@sunroof.eng.sun.com > > Subject: Re: Issues list for RFC3010 > > > > > > > But you didn't address the issue when the server can support it but > > > only in cases that it knows that it is what the client > > wants. Suppose > > > we have a server (say the win2k server) that will disallow REMOVE of > > > an OPEN file in the general case. However, it has the underlying > > > capability to allow the client the OPEN, REMOVE, READ > > sequence. Your > > > proposal doesn't allow the client a method of determining that > > > capability. Maybe Sergey can let us know if this is what his server > > > might do? > > > > If I understand this correctly, the question is if there > > exists a server > > that will deny a REMOVE differently depending on if the caller was the > > one who OPENed the file or not. For example, you can only > > REMOVE an OPEN > > file if you OPENed it. Sergey, do you know of such a case? I don't. > > > > In any case I would advocate that the server can choose to REMOVE an > > OPEN file or not based on whatever criteria it wishes to use. But > > if it allows the REMOVE it MUST follow the failure semantics > > previously > > described. > > > > If someone does come up with a weird OS that would require us to > > use stateid's or other client state, I will advocate not allowing > > REMOVE of OPEN files. > > > > -David > > > -- - Spencer - From nfs4-wg-request@sunroof.eng.sun.com Mon Sep 24 23:46:54 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA08458 for ; Mon, 24 Sep 2001 23:46:54 -0400 (EDT) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id UAA28949; Mon, 24 Sep 2001 20:46:59 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id UAA11125; Mon, 24 Sep 2001 20:46:39 -0700 (PDT) Received: from jurassic.eng.sun.com (jurassic [129.146.89.50] (may be forged)) by sunroof.eng.sun.com (8.12.0+Sun/8.12.0) with ESMTP id f8P3kS7B025047 for ; Mon, 24 Sep 2001 20:46:28 -0700 (PDT) Received: from peyto (vpn-129-147-152-128.Central.Sun.COM [129.147.152.128]) by jurassic.eng.sun.com (8.12.0+Sun/8.12.0) with SMTP id f8P3kUVj484956; Mon, 24 Sep 2001 20:46:31 -0700 (PDT) Date: Mon, 24 Sep 2001 21:46:57 -0600 (MDT) From: Robert Thurlow Reply-To: Robert Thurlow Subject: Replication and Migration - summary so far To: nfsv4-wg@sunroof.eng.sun.com Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Below is an attempt to summarize the discussion so far regarding the next phase of work for NFSv4 replication and migration. We have a few decisions to make about what direction we want to take with this work, and I hope people will take some time to give feedback on these areas. First, to clarify what I think we are doing: We want to create a new protocol which servers can use to transfer and maintain replicas of NFSv4 filesystems, or to migrate NFSv4 filesystems from one server to another. The protocol should likely have most of the following attributes: heterogeneous, correct, fast, secure, and bandwidth efficient. Question to the WG: how many people out there are interested in this area of effort? To the vendors who have homogeneous features in this area, does this seem like a good thing? As we have discussed this, some issues and disagreements have popped up. Here's what I have seen: Delegation and lock state Migration of a read-write filesystem needs either to transfer state for current delegations and locks or ensure that such state does not exist when the transfer starts. This is seen as difficult to do, so some want to ignore this for now and focus on what we need to make read-only replication work well. Compromises might be to leave a place holder in the protocol for this unique metadata and define how it is to be handled later, or to make this a SHOULD in the protocol. Question to the WG: how important does it seem to you to solve this problem? Does either compromise work for you? NFSv4-specific vs. generic Brian's original work had some language that this would not be a general purpose replication protocol for use with older versions of NFS and with CIFS, but others want exactly that sort of capability. It does seem that without knowing some intimate things about NFSv4 metadata, the protocol cannot truly transfer filesystems with the degree of correctness desired. Spencer Shepler suggested what I think is an excellent way to handle this: that rather than putting core knowledge of NFSv4 into the replication/migration protocol, we define a series of protocol-specific "attachments" which contain the details of how metadata looks, and make the first attachment for NFSv4, able to use NFSv4 definitions. Question to the WG: does this kind of layering make sense? Capability negotiation Brian's original talks had a negotiation phase between the peers of a filesystem transfer so that the sender can know any impairments before starting an initial transfer and warn an admin or bail out. Some weren't sure this was necessary. But Dave Noveck wrote a good argument for this, stating that portable programs often try to learn their environments before doing serious work, and that losing an extended attribute after a migration event would be a very bad thing. Question to the WG: do we need capability negotiation? We also have some things that seem to be accepted based on the amount of attention paid to them so far. I think the following are not in much dispute; please argue with me if you disagree: - it is OK for the replication/migration protocol to not be based on RPC - it is OK for the replication/migration protocol to be able to rely on transport-level security (e.g. IPSEC) - it is likely interesting to use the "rsync" algorithm to transfer replicas in some cases, though there will be cases where we have, and should use, better information from the filesystem - resource discovery (how the client finds the filesystems to use) is impacted by replication and migration, but is not part of this solution space - multiple writable copies and disconnected operation are not in scope Comments? Rob T From nfs4-wg-request@sunroof.eng.sun.com Tue Sep 25 03:50:03 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA25168 for ; Tue, 25 Sep 2001 03:50:02 -0400 (EDT) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id AAA24939; Tue, 25 Sep 2001 00:50:04 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id AAA23563; Tue, 25 Sep 2001 00:49:34 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.0+Sun/8.12.0) with ESMTP id f8P7nL7B025615 for ; Tue, 25 Sep 2001 00:49:21 -0700 (PDT) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id AAA27337 for ; Tue, 25 Sep 2001 00:49:24 -0700 (PDT) Received: from fmtools. (fmtools.korea.ac.kr [163.152.40.216]) by saturn.sun.com (8.9.3+Sun/8.9.3) with SMTP id AAA11966 for ; Tue, 25 Sep 2001 00:49:23 -0700 (PDT) Received: from mx2.mail.yahoo.com by fmtools. (SMI-8.6/SMI-SVR4) id QAA01212; Tue, 25 Sep 2001 16:50:30 +0900 Date: Tue, 25 Sep 2001 16:50:30 +0900 Reply-To: From: "winwin789@yahoo.com" To: "9416@yahoo.com" <9416@yahoo.com> Message-ID: <1001404259.0440671092@mx2.mail.yahoo.com> Subject: Reach For The Stars... ADV: 538864 Content-Type: text/plain; charset="us-ascii";format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Be Debt Free for 2002. Please read before you delete. This is not a spam. Truly you will become debt free. You have nothing to lose and everything to gain. All our mailings are sent complying to the proposed United States Federal requirements for commercial e-mail: Section 301 Paragraph (a)(2)(C) of S.618. Please see the bottom of this message for further information and removal instructions. Dear Friend, AS SEEN ON NATIONAL TV: Make over a half million dollars ($500,000+)every 4 to 5 months from your home for an investment of only $25 U.S. Dollars - one time! THANKS TO THE COMPUTER AGE AND THE INTERNET! ====================================================== BE A MILLIONAIRE LIKE OTHERS WITHIN A YEAR!! Before you say "Bull", please read the following. This is the letter you have been hearing about on the news lately. Due to the popularity of this letter on the internet, a national weekly news program recently devoted an entire show to the investigation of this program described below, to see if it really can make people money. Also... ***Does this Headline Look familiar??*** PARENTS OF 15 YEAR OLD FIND $71,000 CASH HIDDEN IN CLOSET! Of course it does. This is one of the stories they featured on that news report. This is also the same program that he was using. Moving On... This show also investigated whether or not the program was legal. Their findings proved once and for all that there are "absolutely no laws prohibiting the participation in the program and if people can follow the simple instructions, they are bound to make some mega bucks with only $25 out of pocket cost." DUE TO THE RECENT INCREASE OF POPULARITY THIS PROGRAM HAS ATTAINED, IT IS CURRENTLY WORKING BETTER THAN EVER !!! This is what one participant had to say: "I am thankful for this profitable opportunity. I had seen this program many times before, but each time I passed on it. I am so glad I finally joined just to see what one could expect in return for the minimal effort and money required. To my astonishment, I received a total of $610,470.00 in 21 weeks, with money still coming in." Pam Hedland, Fort Lee, NJ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Here is another testimonial: "This program has been around for a long time and I never believed in it. But one day when I received this again in the mail, I decided to gamble my $25 on it. I followed the simple instructions and walaa. 3 weeks later the money started to come in. First month I only made a total of $240.00 but the next 2 months after that I made a total of $290,000.00. So far, in the past 8 months by re-entering the program, I have made over $710,000 and I am playing it again. The key to success in this program is to follow the simple steps and not change anything." More testimonials later but first, ****** PRINT THIS NOW FOR YOUR FUTURE REFERENCE ****** $$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$ If you would like to make at least $500,000 every 4 to 5 months easily and comfortably, please read the following. THEN READ IT AGAIN AND AGAIN!!! $$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$ FOLLOW THE SIMPLE INSTRUCTIONS BELOW AND YOUR FINANCIAL DREAMS WILL COME TRUE!!! INSTRUCTIONS: **** Order all 5 reports shown on the list below. **** For each report, send: 1. $5 CASH 2. THE NAME AND NUMBER OF THE REPORT YOU ARE ORDERING 3. YOUR E-MAIL ADDRESS to the person whose name appears ON THAT LIST next to the report. MAKE SURE YOUR RETURN ADDRESS IS ON YOUR ENVELOPE TOP LEFT CORNER in case of any mail problems. **** When you place your order, make sure you order each of the 5 reports. You will need all 5 reports so that you can save them on your computer and resell them. YOUR TOTAL COST $5 X 5 = $25. **** Within a few days you will receive, via e-mail, each of the 5 reports from these 5 different individuals. Save them on your computer so they will be accessible for you to send to the 1,000's of people who will order them from you. Also make a floppy of these reports and keep it on your desk in case something happens to your computer. **** IMPORTANT - DO NOT alter the names of the people who are listed next to each report, or their sequence on the list, in any way other than what is instructed below in steps 1 through 6 or you will lose out on a majority of your profits. Once you understand the way this works, you will also see how it does not work if you change it. Remember, this method has been tested, and if you alter it, it will NOT work!!! So, DO NOT try to change anything other than what is instructed. Because if you do, it will not work for you. Remember, honesty reaps the reward!!! 1. After you have ordered all 5 reports, take this advertisement and REMOVE the name and address of the person in REPORT # 5. This person has made it through the cycle and is not doubt counting their fortune. 2. Move the name and address in REPORT # 4 to REPORT # 5. 3. Move the name and address in REPORT # 3 to REPORT # 4. 4. Move the name and address in REPORT # 2 to REPORT # 3.. 5. Move the name and address in REPORT # 1 to REPORT #2. 6. Insert YOUR name and address in the REPORT # 1 position. PLEASE MAKE SURE you copy every name and address ACCURATELY! ============================================================ Take this entire letter, with the modified list of names, and save it on your computer. DO NOT MAKE ANY OTHER CHANGES. Save this on a disk as well just in case you lose any data. To assist you with marketing your business on the internet, the 5 reports you purchase will provide you with invaluable marketing information which includes how to send bulk e-mails legally, where to find thousands of free classified ads and much more. There are 2 primary methods to get this venture going: METHOD # 1: BY SENDING BULK E-MAIL LEGALLY ============================================================ Let's say that you decide to start small, just to see how it goes, and we will assume you and those involved send out only 5,000 e-mails each. Let's also assume that the mailing receives only a 0.2% response (the response could be much better but let's just say it is only 0.2%. Also, many people will send out thousands of e-mails instead of only 5,000 each.) Continuing with this example, you send out only 5,000 e-mails. With a 0.2% response, that is only 10 orders for Report # 1. Those 10 people responded by sending out 5,000 e-mails each for a total of 50,000. Out of those 50,000 e-mails, only 0.2% responded with orders. That equals 100 people responding and ordering Report # 2. Those 100 people mail out 5,000 e-mails each for a total of 500,000 emails. The 0.2% response to that is 1,000 orders for Report # 3. Those 1,000 people send out 5,000 e-mails each for a total of 5 million e-mails sent out. The 0.2% response to that is 10,000 orders for Report # 4. Those 10,000 people send out 5,000 e-mails each for a total of 50,000,000 (50 million) e-mails. The 0.2% response to that is 100,000 orders for Report # 5. THAT'S 100,000 ORDERS TIME $5 EACH = $500,000.00 (One-half million dollars.) Your total income in this example is: 1. $50 + 2. $500 + 3. $5,000 + 4. $50,000 + 5. $500,000 + Grand Total + $555,550.00 NUMBERS DO NOT LIE. GET A PENCIL AND PAPER AND FIGURE OUT THE WORSE POSSIBLE RESPONSE. NO MATTER HOW YOU CALCULATE IT, YOU WILL STILL MAKE A LOT OF MONEY!!! ------------------------------------------------------------- REMEMBER FRIEND, THIS IS ASSUMING ONLY 10 PEOPLE ORDER OUT OF THE 5,000 YOU MAILED TO. Dare to think for a moment what would happen if everyone or half or even one fourth of those people who responded mailed 100,000 e-mails each or more. There are over 250 million people on the internet worldwide and counting. Believe me, many people will do just that, and more! METHOD # 2: BY PLACING FREE ADS ON THE INTERNET =========================================================== Advertising on the net is very inexpensive and there are hundreds of FREE places to advertise. Placing a lot of free ads on the internet will easily get a large response. We strongly suggest you start with METHOD # 1 and add METHOD # 2 as you go along. For every $5 you receive, all you must do is e-mail them the Report they ordered. That's it. Always provide same day service on all reports. This will guarantee that the e-mail they send out, with your name and address on it, will be prompt because they can not advertise until they receive the report. **********AVAILABLE REPORTS********** ORDER EACH REPORT BY ITS NUMBER AND NAME ONLY. Notes: Always send $5 cash (U.S. CURRENCY) for each Report. Checks NOT accepted. Make sure the cash is concealed by wrapping it in at least 2 sheets of paper. On one of those sheets of paper, write the NUMBER & NAME of the Report you are ordering along with YOUR E-MAIL ADDRESS and your name and postal address. PLACE YOUR ORDER FOR THESE REPORTS NOW: ==================================================== REPORT # 1: "The Insider's Guide to Sending Bulk e-mail on the Internet." ORDER REPORT # 1 FROM: Shane Black 4331 E Baseline Rd Suite B-105, PMB 435 Gilbert, Arizona 85234-2961 USA Don't forget to provide your e-mail address to receive the reports! ==================================================== REPORT # 2: "The Insider's Guide to Advertising for Free on the Internet" ORDER REPORT # 2 FROM: SMJ 2753 East Broadway Rd Suite 101 # 497 Mesa, AZ. 85204 USA ==================================================== REPORT # 3: "The Secrets of Multi-Level Marketing on the Internet" ORDER REPORT # 3 FROM: M. Miller 3089-C Clairemont Drive #343 San Diego, CA. 92117 USA ==================================================== REPORT # 4: "How to Become a Millionaire Utilizing the Power of Multi-Level Marketing and the Internet" ORDER REPORT # 4 FROM: KC 3439 NE Sandy Blvd #379 Portland, Oregon 97232 USA ==================================================== REPORT # 5: "How to Send 1,000,000 E-mails for FREE" ORDER REPORT # 5 FROM: DJ 3100 S Sheridan Blvd 1C-510 Denver, CO. 80227 USA ====================================================== There are currently more than 250,000,000 people online worldwide! $$$$$$$$$$$$$$ YOUR SUCCESS GUIDELINES $$$$$$$$$$$$$$ Follow these guidelines to create your success: If you do not receive at least 10 orders for Report # 1 within 2 weeks, continue sending e-mails until you do. After you receive 10 orders, 2 to 3 weeks after that you should receive 100 orders or more for Report # 2. If you did not, continue advertising or sending e-mails until you do. Once you have receiving 100 or more orders for Report # 2, YOU CAN RELAX, because the system is already working for you, and the cash will continue to roll in! THIS IS IMPORTANT TO REMEMBER: Every time your name is moved down on the list, you are placed in front of a different report. You can KEEP TRACK of your PROGRESS by watching which report people are ordering from you. IF YOU WANT TO GENERATE MORE INCOME SEND ANOTHER BATCH OF E-MAILS AND START THE WHOLE PROCESS AGAIN. There is NO LIMIT to the income you can generate from this business!!! -------------------------------------------------------------- FOLLOWING IS A NOTE FROM THE ORIGINATOR OF THIS PROGRM: You have just received information that can give you financial freedom for the rest of your life, with NO RISK and JUST A LITTLE BIT OF EFFORT. You can make more money in the next few weeks and months than you have ever imagined. Follow the program EXACTLY AS INSTRUCTED. Do not change it in any way. It works exceedingly well as it is now. Remember to e-mail a copy of this exciting report after you have put your name and address in Report # 1 and move others to # 2...# 5 as instructed above. One of the people you send this to may send out 100,000 or more e-mails and your name will be on every one of them. Remember though, the more you send out the more potential customers you will reach. So my friend, I have given you ideas, information, materials and opportunity to become financially independent. IT IS UP TO YOU NOW! *************** MORE TESTIMONIALS *************** My name it Mitchell. My wife, Jody and I live in Chicago. I am an accountant with a major U.S. Corporation and I make pretty good money. When I received this program I grumbled to Jody about receiving "junk mail". I made fun of the whole thing, spouting my knowledge of the population and percentages involved. I "knew" it wouldn't work. Jody totally ignored my supposed intelligence and a few days later she jumped in with both feet. I made merciless fun of her, and was ready to lay the old "I told you so" on her when the thing didn't work. Well, the laugh was on me! Within 3 weeks she had received 50 responses. Within the next 45 days she had received a total of $147,200.00 all cash! I was shocked. I have joined Jody in her "hobby". Mitchell Wolf, Chicago, Illinois --------------------------------------------------------------------------------------------------------------- "Not being the gambling type, it took me several weeks to make up my mind to participate in this plan. But conservative that I am, I decided that the initial investment was so little that there was just no way I wouldn't get enough orders to at least get my money back. I was surprised when I found my medium size post office box crammed with orders. I made $319,210.00 in the first 12 weeks. The nice thing about this deal is that it does not matter where people live. There simply isn't a better investment with a faster return." Dan Sondstrom, Alberta, Canada -------------------------------------------------------------------------------------------------------------- "I had received this program before. I deleted it, but later I wondered if I should have given it a try. Of course, I had no idea who to contact to get another copy, so I had to wait until I was e-mailed again by someone else... 11 months passed and then it luckily came again ... I did not delete is one! I made more than $490,000 on my first try and all the money came within 22 weeks." Susan De Suza, New York, NY ------------------------------------------------------------------------------------------------------------- "It really is a great opportunity to make relatively easy money with little cost to you. I followed the simple instructions carefully and within 10 days the money started to come in. My first month I made $20,560.00 and by the end of the third month my total cash count was $362,840.00. Life is beautiful, thanks to the Internet." Fred Dellaca, Westport, New Zealand -------------------------------------------------------------------------------------------------------------- ORDER YOUR REPORTS TODAY AND GET STARTED ON "YOUR" ROAD TO FINANCIAL FREEDOM!!! If you have any questions of the legality of this program, contact the Office of Associate Director for Marketing Practices, Federal Trade Commission, Bureau of Consumer protection, Washington, D.C. Under Bill s.1618 TITLE III passed by the 105th Congress, this letter cannot be considered spam as long as the sender includes contact information and a method of removal. Make over a half million dollars ($500,000+) every 4 to 5 months from your home for an invest of only $25 U.S. Dollars - one time! It's there for you - go for it! Good Luck! -=-=-=-=--=-=-=-=-=REMOVE Instructions=-=-=-=-=-=-=-=-=- ********************************************************* Do not reply to this message - To be removed from future mailings: mail to justsayno789@yahoo.com Include the word Remove in the Subject Line ********************************************************* -=-=-=-=--=-=-=-=-=-=-=More Info=-=-=-=-=-=-=-=-=-=-=-=-=- ********************************************************* To receive more information or to subscribe to Periodic mailings with offers like this... mail to justsayyes789@yahoo.com ********************************************************* * From nfs4-wg-request@sunroof.eng.sun.com Tue Sep 25 10:23:51 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA04681 for ; Tue, 25 Sep 2001 10:23:51 -0400 (EDT) Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA15236; Tue, 25 Sep 2001 08:23:43 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id GAA18094; Tue, 25 Sep 2001 06:59:09 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.0+Sun/8.12.0) with ESMTP id f8PDcs7B026501 for ; Tue, 25 Sep 2001 06:38:54 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id GAA10177 for ; Tue, 25 Sep 2001 06:38:56 -0700 (PDT) Received: from zmamail04.zma.compaq.com (zmamail04.zma.compaq.com [161.114.64.104]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA10221 for ; Tue, 25 Sep 2001 07:38:45 -0600 (MDT) Received: by zmamail04.zma.compaq.com (Postfix, from userid 12345) id 778C54BDE; Tue, 25 Sep 2001 09:38:55 -0400 (EDT) Received: from mailrelay01.cac.cpqcorp.net (mailrelay01.cac.cpqcorp.net [16.47.132.152]) by zmamail04.zma.compaq.com (Postfix) with ESMTP id 61D474E90; Tue, 25 Sep 2001 09:38:55 -0400 (EDT) Received: by mailrelay01.cac.cpqcorp.net (Postfix, from userid 12345) id AE560820; Tue, 25 Sep 2001 06:38:54 -0700 (PDT) Received: from diexch01.xko.dec.com (diexch01.xko.dec.com [16.138.244.57]) by mailrelay01.cac.cpqcorp.net (Postfix) with ESMTP id F1187AAD; Tue, 25 Sep 2001 06:38:48 -0700 (PDT) Received: by diexch01.xko.dec.com with Internet Mail Service (5.5.2650.21) id ; Tue, 25 Sep 2001 19:01:52 +0530 Message-ID: <177E503C4DA3D311BC9D0008C791C306046D4BD2@diexch01.xko.dec.com> From: "Prasad, Sreenivasa" To: "'spencer.shepler@eng.cun.com'" Cc: "'nfsv4-wg@sunroof.eng.sun.com'" Subject: Need help please. Date: Tue, 25 Sep 2001 19:01:52 +0530 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Hi, I have a query regarding NFS (preferable ver 3 & 4). 1. Does the NFS support redirecting of a client connection to another server. If so, how can the administrator control this? (Assume the client is authorized under multiple servers). Cheers, /V.Sreenivasa Prasad. From nfs4-wg-request@sunroof.eng.sun.com Tue Sep 25 10:25:01 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA04727 for ; Tue, 25 Sep 2001 10:25:01 -0400 (EDT) Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA16379; Tue, 25 Sep 2001 08:24:53 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA18938; Tue, 25 Sep 2001 07:02:43 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.0+Sun/8.12.0) with ESMTP id f8PDgo7B026504 for ; Tue, 25 Sep 2001 06:42:50 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id GAA10810 for ; Tue, 25 Sep 2001 06:42:53 -0700 (PDT) Received: from ztxmail03.ztx.compaq.com (ztxmail03.ztx.compaq.com [161.114.1.207]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id HAA18247 for ; Tue, 25 Sep 2001 07:43:47 -0600 (MDT) Received: by ztxmail03.ztx.compaq.com (Postfix, from userid 12345) id E7BDE23BB; Tue, 25 Sep 2001 08:42:51 -0500 (CDT) Received: from mailrelay01.cac.cpqcorp.net (mailrelay01.cac.cpqcorp.net [16.47.132.152]) by ztxmail03.ztx.compaq.com (Postfix) with ESMTP id B00252325; Tue, 25 Sep 2001 08:42:51 -0500 (CDT) Received: by mailrelay01.cac.cpqcorp.net (Postfix, from userid 12345) id 1991A95E; Tue, 25 Sep 2001 06:42:50 -0700 (PDT) Received: from diexch01.xko.dec.com (diexch01.xko.dec.com [16.138.244.57]) by mailrelay01.cac.cpqcorp.net (Postfix) with ESMTP id 41996AAD; Tue, 25 Sep 2001 06:42:45 -0700 (PDT) Received: by diexch01.xko.dec.com with Internet Mail Service (5.5.2650.21) id ; Tue, 25 Sep 2001 19:05:48 +0530 Message-ID: <177E503C4DA3D311BC9D0008C791C306046D4BD4@diexch01.xko.dec.com> From: "Prasad, Sreenivasa" To: "'spencer.shepler@eng.sun.com'" Cc: "'nfsv4-wg@sunroof.eng.sun.com'" Subject: Need help please. Date: Tue, 25 Sep 2001 19:05:47 +0530 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" > Hi, > > I have a query regarding NFS (preferable ver 3 & 4). > > 1.Does the NFS support redirecting of a client connection to another > server. > If so, how can the administrator control this? (Assume the client is > authorized under multiple servers). > Any pointers/info on this is highly helpful. Cheers, /V.Sreenivasa Prasad. From nfs4-wg-request@sunroof.eng.sun.com Tue Sep 25 10:34:19 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA05076 for ; Tue, 25 Sep 2001 10:34:19 -0400 (EDT) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA23560; Tue, 25 Sep 2001 08:34:11 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA05454; Tue, 25 Sep 2001 07:33:58 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.0+Sun/8.12.0) with ESMTP id f8PEXl7B026577 for ; Tue, 25 Sep 2001 07:33:47 -0700 (PDT) Received: from venus.sun.com (venus.EBay.Sun.COM [129.150.69.5]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA05425 for ; Tue, 25 Sep 2001 07:33:48 -0700 (PDT) Received: from a88.lambo.student.liu.se (a88.lambo.student.liu.se [130.236.229.88]) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA02273 for ; Tue, 25 Sep 2001 07:33:46 -0700 (PDT) Received: by a88.lambo.student.liu.se (Postfix, from userid 500) id DE64A34CDD; Tue, 25 Sep 2001 16:33:43 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by a88.lambo.student.liu.se (Postfix) with ESMTP id D6DA7CF39 for ; Tue, 25 Sep 2001 16:33:43 +0200 (CEST) Date: Tue, 25 Sep 2001 16:33:43 +0200 (CEST) From: =?iso-8859-1?Q?Peter_=C5strand?= X-X-Sender: To: Subject: XDR/RPC questions Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=iso-8859-1 Content-Transfer-Encoding: 8BIT Content-Transfer-Encoding: 8BIT (Sorry for being slightly off-topic. Any other lists that is more appropriate for questions like this?) I have a few questions about the XDR/RPC language specification, as described in RFC1832 and RFC1831. 1. Section 5.4. "int" is not mentioned as a reserved keyword. Reasons for this? 2. Are constructions like this valid?: union createtype4 switch (nfs_ftype4 type) { case NF4LNK: linktext4 linkdata; case NF4BLK: case NF4CHR: specdata4 devdata; ... I cannot see how this fits into the union-body declaration in RFC1832. 3. The RPC spec says: procedure-def: type-specifier identifier "(" type-specifier ("," type-specifier )* ")" "=" constant ";" The following example is also given: void PINGPROC_NULL(void) = 0; But in the XDR spec, "type-specifier" cannot be "void". Or have I forgotten something? -- Peter Åstrand Telephone: +46-13-29 08 61 Cendio Systems E-mail: peter@cendio.se Teknikringen 3 583 30 Linköping From nfs4-wg-request@sunroof.eng.sun.com Tue Sep 25 10:48:43 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA05447 for ; Tue, 25 Sep 2001 10:48:42 -0400 (EDT) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id HAA16675; Tue, 25 Sep 2001 07:48:43 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA08890; Tue, 25 Sep 2001 07:47:45 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.0+Sun/8.12.0) with ESMTP id f8PElZ7B026584 for ; Tue, 25 Sep 2001 07:47:35 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA14825 for ; Tue, 25 Sep 2001 07:47:36 -0700 (PDT) Received: from tor01x3.hcl.com (mx5.hcl.com [199.71.120.69]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id IAA20879 for ; Tue, 25 Sep 2001 08:48:32 -0600 (MDT) Received: from av0011 (av0011.hcl.com [10.1.42.240]) by tor01x3.hcl.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id TLHHPRZS; Tue, 25 Sep 2001 10:47:32 -0400 Received: FROM null.hcl.com BY av0011 ; Tue Sep 25 10:47:45 2001 -0400 Received: from sergeylt (sergeylt.hcl.com [10.1.14.29]) by null.hcl.com (8.11.2/8.11.3) with SMTP id f8PElYB24882; Tue, 25 Sep 2001 10:47:34 -0400 (EDT) From: "Sergey Klyushin" To: Cc: Subject: RE: open/remove sequence Date: Tue, 25 Sep 2001 10:47:56 -0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 In-Reply-To: <20010924204155.M608@dhcp-aus08-191.central.sun.com> Content-Transfer-Encoding: 7bit > -----Original Message----- > From: Spencer Shepler [mailto:shepler@eng.sun.com] > Sent: Monday, September 24, 2001 9:42 PM > To: Sergey Klyushin > Cc: nfsv4-wg@sunroof.eng.sun.com > Subject: open/remove sequence > > > > Sergey, > It seems, from your description, that the windows functionality is > different from Unix in that when a Unix application removes the open > file, it is removed from the namespace. An open() can then succeed > with the same name as the removed file without restriction with > respect to the impending close() of that removed file. > Also from your description, the windows client can emulate > everything about remove on close except for failing OPENs from other > clients. Have you found that this set of options is used often in > windows? I'll ask Dan to comment his Client implementation > Since we seem to have this fundamental difference it isn't clear to > me which (if either) piece of functionality we should attempt to > provide. > Should we provide the simple functionality that David has suggested? > I am not sure that many server's will implement it. Should we wait > until a minor version to consider adding a more complex REMOVE op? > > Spencer David's scenario (simple): 1. Client (C1) OPENs file 2. Client (C1) asks to REMOVE file 3. Server refuses to REMOVE OPENed file 4. Client (C1) renames file to .nfsxxxx (question of non volatile file handle) 5. ANOTHER client (C2) asks to REMOVE .nfsxxxx (without OPEN) 6. Server refuses, because file is OPENed 7. Client C2 has no idea why REMOVE failed (possible to solve with C1 SETATTR 000 after RENAME, but C2's request still may come between RENAME and SETATTR) Another one: 1. Client (C1) OPENs file 2. Client (C1) asks to REMOVE file 3. Server refuses to REMOVE OPENed file 4. Client (C1) renames file to .nfsxxxx (question of non volatile file handle) 5. ANOTHER client (C2) asks to OPEN .nfsxxxx -> Server responds OK 5. Client (C2) asks to REMOVE .nfsxxxx 6. Server refuses, because file is OPENed 7. C2 RENAMEs .nfsxxxx to .nfs1xxx 8. C1's LOOKUP for .nfsxxxx will fail 8. C1 CLOSEs file using file handle 9. C1 asks to REMOVE .nfsxxxx. Get's back to such file (by name, but by file handle file still exists -> possible caching problem) One more: 1. Client (C1) OPENs file 2. ANOTHER Client (C2) RENAMEs file to new_file_name 3. Client (C1) asks to REMOVE file -> failed: file_not_exists. C1 can't do REMOVE on CLOSE Almost the same behavior if Server allows REMOVE of OPENed files and makes RENAME trick locally Another big question when local OS REMOVEs OPENed file. From my opinion this approach was fine for NFS v2 and v3, when we did not have OPEN procedure, but with NFS v4 we may protect ourselves with OPEN operation. As you said the Client is the one who knows if OPENed file could be REMOVEd, but Server has no idea about Client's intention Windows scenario: Client wants to use file as temporary, remove it on close and does NOT allow another clients to remove it 1. Client (C1) OPENs file with DENY_REMOVE, REMOVE_ON_CLOSE (add flags to NFSv4 protocol) 2. ANOTHER client (C2) asks to REMOVE file -> gets back ERROR, that could be translated to upper level as ERR_DENIED 3. C2 may OPEN file (question of SHARE mode) 4. C2 can't CREATE file with the same name (file exists and it's true) 5. C1 CLOSEs file 6. Server REMOVEs file Client wants to use file and does allow another clients to remove it 1. Client (C1) OPENs file WITHOUT DENY_REMOVE 2. ANOTHER client (C2) asks to REMOVE file -> gets back OK or OK_WILL_BE_DELETED_ON_LAST_CLOSE 3. C2 may OPEN file (question of SHARE mode) 4. C2 can't CREATE file with the same name (file exists and it's true) 5. C1 CLOSEs file 6. Server REMOVEs file The problems 1. OK_WILL_BE_DELETED_ON_LAST_CLOSE 2. REMOVE_ON_CLOSE state should survive reboot on Server From my opinion, Windows approach has less problems Sergey > > On Mon, Sergey Klyushin wrote: > > Here is how OpenFile/CreateFile works on Windows (locally): > > 1. OpenFile/CreateFile has one more share attribute > FILE_SHARE_DELETE > > 1.1 If file is opened WITH FILE_SHARE_DELETE, than request > from ANOTHER > > application to REMOVE file will succeed. > > File won't be removed immediately, but will be removed on > the last CLOSE > > request. > > New OPENs will fail (with exception OPEN to DELETE). > > File still will be listed in directory > > Attempt to create file with the same name will fail. > > 1.2 If file is opened WITHOUT FILE_SHARE_DELETE, than > request from ANOTHER > > application to REMOVE file will FAIL. > > > > 2. OpenFile/CreateFile has lots of flags one of which is > > FILE_FLAG_DELETE_ON_CLOSE (kind of intention OPEN,REMOVE,READ) > > If this flag is specified at OPEN/CREATE, than file be > deleted on last > > CLOSE. > > > > 3. File has attribute DELETE_PENDING, that explains > application why it could > > not be OPENED other than for deleting. > > > > I am trying to implement NFS as much close to local (Windows) OS as > > possible, but some operations could not be > > implemented. I understand that NFS protocol can't cover all > OSs, but if we > > could cover as much local OSs as possible, > > we'll benefit it later. > > > > Sergey > > > > > -----Original Message----- > > > From: Noveck, Dave [mailto:Dave.Noveck@netapp.com] > > > Sent: Sunday, September 23, 2001 1:11 PM > > > To: 'David Robinson'; nfsv4-wg@sunroof.eng.sun.com > > > Subject: RE: Issues list for RFC3010 > > > > > > > > > This isn't exactly what you were asking about, but I think > > > there is a case in which your approach would require some > > > identification of who is doing the remove, at least to the > > > clientid granularity. > > > > > > Consider a file which is opened by processes on two different > > > clients, A and B. Now suppose A does a remove and the > > > server does not support a delete on last close mechanism > > > to it returns NFS4ERR_NO_CAN_DO_USE_THE_OLD_HACK_PLEASE. > > > So client renames the file. Now the application on A > > > does a close so it now removes the file. But the server > > > knows that the file is open and would return that same > > > NFS4ERR_NO_CAN_DO_USE_THE_OLD_HACK_PLEASE and the client > > > has no way of dealing with that that since he has no way > > > of knowing when the global last close will occur and, by > > > hypothesis the server can't do the remove at the appropriate > > > time either. And further there is no way for the client to > > > force the remove immediately either. > > > > > > If the REMOVE had a clientid parameter, the server could only > > > check opens for that client and return HACK_PLEASE only if > > > the file were opened by that client. Then, in the example > > > above, the file would actually get removed when it was closed > > > by A, which would certainly annoy B, but is no worse than what > > > happens now (i.e in V2 and V3). > > > > > > An alternative would be to pass a parameter flag that > indicates > > > this is a hack remove, > this_is_the_hack_so_dont_ask_for_the_hack, > > > which would also force an immediate remove in this situation, > > > independent of any opens of the file, unless the > server dupported > > > delete on last close. > > > > > > > > > -----Original Message----- > > > From: David Robinson [mailto:David.Robinson@Sun.COM] > > > Sent: Friday, September 21, 2001 6:06 PM > > > To: nfsv4-wg@sunroof.eng.sun.com > > > Subject: Re: Issues list for RFC3010 > > > > > > > > > > But you didn't address the issue when the server > can support it but > > > > only in cases that it knows that it is what the client > > > wants. Suppose > > > > we have a server (say the win2k server) that will > disallow REMOVE of > > > > an OPEN file in the general case. However, it has > the underlying > > > > capability to allow the client the OPEN, REMOVE, READ > > > sequence. Your > > > > proposal doesn't allow the client a method of > determining that > > > > capability. Maybe Sergey can let us know if this > is what his server > > > > might do? > > > > > > If I understand this correctly, the question is if there > > > exists a server > > > that will deny a REMOVE differently depending on if > the caller was the > > > one who OPENed the file or not. For example, you can only > > > REMOVE an OPEN > > > file if you OPENed it. Sergey, do you know of such a > case? I don't. > > > > > > In any case I would advocate that the server can > choose to REMOVE an > > > OPEN file or not based on whatever criteria it wishes > to use. But > > > if it allows the REMOVE it MUST follow the failure semantics > > > previously > > > described. > > > > > > If someone does come up with a weird OS that would > require us to > > > use stateid's or other client state, I will advocate > not allowing > > > REMOVE of OPEN files. > > > > > > -David > > > > > > > -- > > - Spencer - > > From nfs4-wg-request@sunroof.eng.sun.com Tue Sep 25 12:16:59 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA08031 for ; Tue, 25 Sep 2001 12:16:59 -0400 (EDT) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA23104; Tue, 25 Sep 2001 10:16:51 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA28914; Tue, 25 Sep 2001 09:16:39 -0700 (PDT) Received: from phys-ha6nwka.ebay.sun.com (root@phys-ha6nwka.EBay.Sun.COM [129.149.1.82]) by sunroof.eng.sun.com (8.12.0+Sun/8.12.0) with ESMTP id f8PGGS7B027061 for ; Tue, 25 Sep 2001 09:16:28 -0700 (PDT) Received: from Sun.COM (jetsun.Central.Sun.COM [129.153.128.60]) by phys-ha6nwka.ebay.sun.com (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA28315 for ; Tue, 25 Sep 2001 09:16:24 -0700 (PDT) Sender: robinson@phys-ha6nwka.ebay.sun.com Message-ID: <3BB0ADDB.87635300@Sun.COM> Date: Tue, 25 Sep 2001 11:16:27 -0500 From: David Robinson Organization: Sun Microsystems, Inc. X-Mailer: Mozilla 4.78 [en] (X11; U; SunOS 5.9 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: nfsv4-wg@sunroof.eng.sun.com Subject: Re: open/remove sequence References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit > David's scenario (simple): > 1. Client (C1) OPENs file > 2. Client (C1) asks to REMOVE file > 3. Server refuses to REMOVE OPENed file > 4. Client (C1) renames file to .nfsxxxx (question of non volatile file > handle) > 5. ANOTHER client (C2) asks to REMOVE .nfsxxxx (without OPEN) > 6. Server refuses, because file is OPENed > 7. Client C2 has no idea why REMOVE failed (possible to solve with C1 > SETATTR 000 after RENAME, > but C2's request still may come between RENAME and SETATTR) I am willing to let this happen, I believe it is rare and the problem exists today with no major complaints. > Another one: > 1. Client (C1) OPENs file > 2. Client (C1) asks to REMOVE file > 3. Server refuses to REMOVE OPENed file > 4. Client (C1) renames file to .nfsxxxx (question of non volatile file > handle) > 5. ANOTHER client (C2) asks to OPEN .nfsxxxx -> Server responds OK > 5. Client (C2) asks to REMOVE .nfsxxxx > 6. Server refuses, because file is OPENed > 7. C2 RENAMEs .nfsxxxx to .nfs1xxx > 8. C1's LOOKUP for .nfsxxxx will fail > 8. C1 CLOSEs file using file handle > 9. C1 asks to REMOVE .nfsxxxx. Get's back to such file (by name, > but by file handle file still exists -> possible caching problem) Same as before, problem exists today with no major complaints. > One more: > 1. Client (C1) OPENs file > 2. ANOTHER Client (C2) RENAMEs file to new_file_name > 3. Client (C1) asks to REMOVE file -> failed: file_not_exists. C1 can't do > REMOVE on CLOSE Definately clients today have the third part remove causing unexpected failoure problems. Without a namespace consistency protocol we have no hope in solving this one. > Another big question when local OS REMOVEs OPENed file. As I said before, undefined behavior, most likely bad. > From my opinion this approach was fine for NFS v2 and v3, when we did not > have OPEN procedure, but with NFS v4 > we may protect ourselves with OPEN operation. I think the OPEN procedure will allow servers to be smarter and better handle removal of open files, but not perfectly. I just see it as a small corner cases that has not be a big problem. > Windows scenario: > Client wants to use file as temporary, remove it on close and does NOT allow > another clients to remove it > 1. Client (C1) OPENs file with DENY_REMOVE, REMOVE_ON_CLOSE (add flags to > NFSv4 protocol) If these are "standard" windows open flags we should consider adding them. There semantics would need to be clearly defined and check to see if they would cause conflicts with the Posix model of the directory controling remove permissions. > The problems > 1. OK_WILL_BE_DELETED_ON_LAST_CLOSE > 2. REMOVE_ON_CLOSE state should survive reboot on Server In my previous e-mail, I stated I already believe that a server will have to maintain state to handle remove on close if it supports removal of open files, so I don't see this as a problem. In reading Sergey's description of windows behavior, it seems to be a good idea to add DENY_REMOVE and REMOVE_ON_CLOSE if the semantics make sense (interesting question is if it prevents actual removal of the file or any of the possibly many hard links?). The Unix/Posix clients are still faced with problems, they don't know at open if they will be wanting a remove on close or have the capability to express DENY_REMOVE. But those problems exist today and after 2+ years of protocol design people are only now wondering if it might be a problem, which to me proves it is not a real industry problem. Question back to Sergey, if a Windows client requests REMOVE_ON_CLOSE or DENY_REMOVE and the server fails because it will not allow it (either unimplemented or not part of the file system semantics) how will the client handle it? Will it error to the application or will it be able to set some client state that will issue the remove after it closes the file? -David From nfs4-wg-request@sunroof.eng.sun.com Tue Sep 25 13:28:56 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA10089 for ; Tue, 25 Sep 2001 13:28:55 -0400 (EDT) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA28722; Tue, 25 Sep 2001 11:28:46 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA18601; Tue, 25 Sep 2001 10:28:14 -0700 (PDT) Received: from centralmail2.Central.Sun.COM (centralmail2.Central.Sun.COM [129.147.62.11]) by sunroof.eng.sun.com (8.12.0+Sun/8.12.0) with ESMTP id f8PHRq7B027501 for ; Tue, 25 Sep 2001 10:27:52 -0700 (PDT) Received: from dhcp-aus08-191.central.sun.com (dhcp-aus08-191.Central.Sun.COM [129.153.128.191]) by centralmail2.Central.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA29248; Tue, 25 Sep 2001 11:27:54 -0600 (MDT) Received: (from shepler@localhost) by dhcp-aus08-191.central.sun.com (8.11.3+Sun/8.11.3) id f8PHRgZ00581; Tue, 25 Sep 2001 12:27:42 -0500 (CDT) Date: Tue, 25 Sep 2001 12:27:42 -0500 From: Spencer Shepler To: "Prasad, Sreenivasa" Cc: nfsv4-wg@sunroof.eng.sun.com Subject: Re: Need help please. Message-ID: <20010925122742.R404@dhcp-aus08-191.central.sun.com> Reply-To: shepler@eng.sun.com Mail-Followup-To: Spencer Shepler , "Prasad, Sreenivasa" , nfsv4-wg@sunroof.eng.sun.com References: <177E503C4DA3D311BC9D0008C791C306046D4BD2@diexch01.xko.dec.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <177E503C4DA3D311BC9D0008C791C306046D4BD2@diexch01.xko.dec.com> User-Agent: Mutt/1.3.19i On Tue, Prasad, Sreenivasa wrote: > Hi, > > I have a query regarding NFS (preferable ver 3 & 4). > > 1. Does the NFS support redirecting of a client connection to another > server. > If so, how can the administrator control this? (Assume the client is > authorized under multiple servers). Not sure from your question what solution you are looking for but NFSv4 has a simple mechanism to provide location information for file system replicas or for the migration of a file system. You will find information about that feature in section 6 of RFC3010 (http://www.ietf.org/rfc/rfc3010.txt) There are no other NFS protocol mechanism for client redirection. -- - Spencer - From nfs4-wg-request@sunroof.eng.sun.com Tue Sep 25 14:13:22 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA11031 for ; Tue, 25 Sep 2001 14:13:21 -0400 (EDT) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA08951; Tue, 25 Sep 2001 12:13:13 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA11185; Tue, 25 Sep 2001 11:13:01 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.0+Sun/8.12.0) with ESMTP id f8PICo7B027835 for ; Tue, 25 Sep 2001 11:12:50 -0700 (PDT) Received: from venus.sun.com (venus.EBay.Sun.COM [129.150.69.5]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA00301 for ; Tue, 25 Sep 2001 11:12:52 -0700 (PDT) Received: from mx01-a.netapp.com (mx01-a.netapp.com [198.95.226.53]) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA04245 for ; Tue, 25 Sep 2001 11:12:50 -0700 (PDT) Received: from hawk.corp.netapp.com (mh02 [10.10.20.101]) by mx01-a.netapp.com (8.11.1/8.11.1/NTAP-1.2) with ESMTP id f8PID0913317; Tue, 25 Sep 2001 11:13:06 -0700 (PDT) Received: from ussvlexc06.corp.netapp.com (localhost [127.0.0.1]) by hawk.corp.netapp.com (8.11.1/8.11.1/NTAP-1.2) with ESMTP id f8PIChb27830; Tue, 25 Sep 2001 11:12:43 -0700 (PDT) Received: by ussvlexc06.corp.netapp.com with Internet Mail Service (5.5.2653.19) id ; Tue, 25 Sep 2001 10:52:50 -0700 Message-ID: <6440EA1A6AA1D5118C6900902745938E2A8C07@black.eng.netapp.com> From: "Yoder, Alan" To: "'David Robinson'" , nfsv4-wg@sunroof.eng.sun.com Subject: RE: open/remove sequence Date: Tue, 25 Sep 2001 11:12:39 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain > > Windows scenario: > > Client wants to use file as temporary, remove it on close > and does NOT allow > > another clients to remove it > > 1. Client (C1) OPENs file with DENY_REMOVE, REMOVE_ON_CLOSE > (add flags to > > NFSv4 protocol) > > If these are "standard" windows open flags we should consider adding > them. > There semantics would need to be clearly defined and check to see if > they would cause conflicts with the Posix model of the directory > controling remove permissions. >From the MSDN library entry for CreateFile (this is the system call that is echoed in CIFS): I've elided most of the detail, which is better read in HTML format anyway. Note: the _open call uses flags from a POSIX standard fcntl.h file. But CreateFile is what CIFS uses to open everything, including pipes and other resources. ... HANDLE CreateFile( LPCTSTR lpFileName, // file name DWORD dwDesiredAccess, // access mode DWORD dwShareMode, // share mode LPSECURITY_ATTRIBUTES lpSecurityAttributes, // SD DWORD dwCreationDisposition, // how to create DWORD dwFlagsAndAttributes, // file attributes HANDLE hTemplateFile // handle to template file ); Parameters lpFileName ... dwDesiredAccess ... GENERIC_READ ... GENERIC_WRITE ... In addition, you can specify the following access flags. DELETE READ_CONTROL WRITE_DAC WRITE_OWNER SYNCHRONIZE STANDARD_RIGHTS_REQUIRED STANDARD_RIGHTS_READ STANDARD_RIGHTS_WRITE STANDARD_RIGHTS_EXECUTE STANDARD_RIGHTS_ALL SPECIFIC_RIGHTS_ALL ACCESS_MASK ACCESS_SYSTEM_SECURITY ACCESS_MASK MAXIMUM_ALLOWED ACCESS_MASK GENERIC_READ ACCESS_MASK GENERIC_WRITE ACCESS_MASK GENERIC_EXECUTE ACCESS_MASK GENERIC_ALL ACCESS_MASK dwShareMode 0 (not shareable) ... FILE_SHARE_DELETE Windows NT/2000: ... FILE_SHARE_READ ... FILE_SHARE_WRITE ... lpSecurityAttributes ... dwCreationDisposition CREATE_NEW ... CREATE_ALWAYS ... OPEN_EXISTING ... OPEN_ALWAYS ... TRUNCATE_EXISTING ... dwFlagsAndAttributes FILE_ATTRIBUTE_NORMAL FILE_ATTRIBUTE_ARCHIVE ... FILE_ATTRIBUTE_ENCRYPTED ... FILE_ATTRIBUTE_HIDDEN ... FILE_ATTRIBUTE_NORMAL ... FILE_ATTRIBUTE_NOT_CONTENT_INDEXED ... FILE_ATTRIBUTE_OFFLINE ... FILE_ATTRIBUTE_READONLY ... FILE_ATTRIBUTE_SYSTEM ... FILE_ATTRIBUTE_TEMPORARY ... Also... FILE_FLAG_WRITE_THROUGH ... FILE_FLAG_OVERLAPPED ...When FILE_FLAG_OVERLAPPED is specified, the system does not maintain the file pointer. The file position must be passed as part of the lpOverlapped parameter (pointing to an OVERLAPPED structure) to the file read and write functions. This flag also enables more than one operation to be performed simultaneously with the handle (a simultaneous read and write operation, for example). FILE_FLAG_NO_BUFFERING ... FILE_FLAG_RANDOM_ACCESS ...(hint) FILE_FLAG_SEQUENTIAL_SCAN ... (hint) FILE_FLAG_DELETE_ON_CLOSE Indicates that the operating system is to delete the file immediately after all of its handles have been closed, not just the handle for which you specified FILE_FLAG_DELETE_ON_CLOSE. Subsequent open requests for the file will fail, unless FILE_SHARE_DELETE is used. FILE_FLAG_BACKUP_SEMANTICS Windows NT/2000: Indicates that the file is being opened or created for a backup or restore operation. The system ensures that the calling process overrides file security checks, provided it has the necessary privileges. The relevant privileges are SE_BACKUP_NAME and SE_RESTORE_NAME. You can also set this flag to obtain a handle to a directory. A directory handle can be passed to some Win32 functions in place of a file handle. FILE_FLAG_POSIX_SEMANTICS Indicates that the file is to be accessed according to POSIX rules. This includes allowing multiple files with names, differing only in case, for file systems that support such naming. Use care when using this option because files created with this flag may not be accessible by applications written for MS-DOS or 16-bit Windows. FILE_FLAG_OPEN_REPARSE_POINT Specifying this flag inhibits the reparse behavior of NTFS reparse points. When the file is opened, a file handle is returned, whether the filter that controls the reparse point is operational or not. This flag cannot be used with the CREATE_ALWAYS flag. FILE_FLAG_OPEN_NO_RECALL Indicates that the file data is requested, but it should continue to reside in remote storage. It should not be transported back to local storage. This flag is intended for use by remote storage systems or the Hierarchical Storage Management system. Alan =============================================================== Alan G. Yoder agy@netapp.com Network Appliance, Inc. Sunnyvale, CA 408-822-6919 =============================================================== From nfs4-wg-request@sunroof.eng.sun.com Tue Sep 25 15:11:42 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA12374 for ; Tue, 25 Sep 2001 15:11:42 -0400 (EDT) Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id MAA11104; Tue, 25 Sep 2001 12:11:39 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA07890; Tue, 25 Sep 2001 12:10:06 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.0+Sun/8.12.0) with ESMTP id f8PJ9o7B028139 for ; Tue, 25 Sep 2001 12:09:50 -0700 (PDT) Received: from venus.sun.com (venus.EBay.Sun.COM [129.150.69.5]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA07782 for ; Tue, 25 Sep 2001 12:09:52 -0700 (PDT) Received: from tor01x3.hcl.com (mx5.hcl.com [199.71.120.69]) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA05529 for ; Tue, 25 Sep 2001 12:09:51 -0700 (PDT) Received: from av0011 (av0011.hcl.com [10.1.42.240]) by tor01x3.hcl.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id TLHHQDFY; Tue, 25 Sep 2001 15:09:48 -0400 Received: FROM null.hcl.com BY av0011 ; Tue Sep 25 15:10:02 2001 -0400 Received: from sergeylt (sergeylt.hcl.com [10.1.14.29]) by null.hcl.com (8.11.2/8.11.3) with SMTP id f8PJ9pB24436; Tue, 25 Sep 2001 15:09:51 -0400 (EDT) From: "Sergey Klyushin" To: "David Robinson" , Subject: RE: open/remove sequence Date: Tue, 25 Sep 2001 15:10:12 -0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 In-Reply-To: <3BB0ADDB.87635300@Sun.COM> Content-Transfer-Encoding: 7bit > > David's scenario (simple): > ....... > I am willing to let this happen, I believe it is rare and the > problem exists today with no major complaints. > ....... > Same as before, problem exists today with no major complaints. > .......... > Definately clients today have the third part remove causing unexpected > failoure problems. Without a namespace consistency protocol we have > no hope in solving this one. > ........... > > Another big question when local OS REMOVEs OPENed file. > > As I said before, undefined behavior, most likely bad. > > > From my opinion this approach was fine for NFS v2 and v3, > when we did not > > have OPEN procedure, but with NFS v4 > > we may protect ourselves with OPEN operation. > > I think the OPEN procedure will allow servers to be smarter and better > handle removal of open files, but not perfectly. I just see it > as a small corner cases that has not be a big problem. > If we may remove as much minor problems as possible now, we won't need to look for customer's complains later > > Windows scenario: > > Client wants to use file as temporary, remove it on close > and does NOT allow > > another clients to remove it > > 1. Client (C1) OPENs file with DENY_REMOVE, REMOVE_ON_CLOSE > (add flags to > > NFSv4 protocol) > > If these are "standard" windows open flags we should consider adding > them. > There semantics would need to be clearly defined and check to see if > they would cause conflicts with the Posix model of the directory > controling remove permissions. > > In reading Sergey's description of windows behavior, it seems > to be a good idea to add DENY_REMOVE and REMOVE_ON_CLOSE if > the semantics make sense SHARE_DENY_REMOVE, FLAG_REMOVE_ON_CLOSE and ATTR_PENDING_DELETE are standard for Windows and used a lot in Windows Applications, including MS Word, Excel, etc. It would really help Windows implementation of NFSv4 and I believe that NFSv4 itself will benefit from these new flags. > (interesting question is if it > prevents actual removal of the file or any of the possibly > many hard links?). If file has more than 1 hard link, this semantic will remove only one link > The Unix/Posix clients are still faced with > problems, they don't know at open if they will be wanting > a remove on close or have the capability to express DENY_REMOVE. You mean current applications. Yes. In future they could be changed. But even now Unix clients can benefit from "Windows" approach: OPEN (acces_mode, DENY_NONE) - I believe will be "standard" UNIX call for first NFSv4 implementations REMOVE (file_name) - we don't need RENAME here READ CLOSE - file removed by Server. > But those problems exist today and after 2+ years of protocol > design people are only now wondering if it might be a problem, > which to me proves it is not a real industry problem. > We raised this question exactly about 2 years ago. The question was put on hold up to now. Another HUGE question for Windows implementation of NFSv4 is OPEN_UPGRADE/OPEN_DOWNGRADE. We also point this problem about 1 year ago. OPEN_UPGRADE/OPEN_DOWNGRADE almost impossible to implement correctly on Windows (the same like SUN found that current stateid model does not fit Solaris file system, and we are going to change the model now) > Question back to Sergey, if a Windows client requests REMOVE_ON_CLOSE > or DENY_REMOVE and the server fails because it will not allow > it (either unimplemented or not part of the file system semantics) > how will the client handle it? Will it error to the application or > will it be able to set some client state that will issue the > remove after it closes the file? Let's ask Dan to comment it > > -David > Sergey From nfs4-wg-request@sunroof.eng.sun.com Tue Sep 25 17:33:38 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA15606 for ; Tue, 25 Sep 2001 17:33:38 -0400 (EDT) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id OAA22874; Tue, 25 Sep 2001 14:33:41 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA05698; Tue, 25 Sep 2001 14:33:21 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.0+Sun/8.12.0) with ESMTP id f8PLXB7B028645 for ; Tue, 25 Sep 2001 14:33:11 -0700 (PDT) Received: from venus.sun.com (venus.EBay.Sun.COM [129.150.69.5]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA05667 for ; Tue, 25 Sep 2001 14:33:12 -0700 (PDT) Received: from tor01x3.hcl.com (mx5.hcl.com [199.71.120.69]) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA18823 for ; Tue, 25 Sep 2001 14:33:10 -0700 (PDT) Received: from av0011 (av0011.hcl.com [10.1.42.240]) by tor01x3.hcl.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id TLHHQ2X8; Tue, 25 Sep 2001 17:33:05 -0400 Received: FROM null.hcl.com BY av0011 ; Tue Sep 25 17:33:19 2001 -0400 Received: from mailhub.hcl.com (mailhub.hcl.com [198.231.99.1]) by null.hcl.com (8.11.2/8.11.3) with ESMTP id f8PLX2B17034; Tue, 25 Sep 2001 17:33:02 -0400 (EDT) Received: from dantnt (dantnt.hcl.com [10.1.12.90]) by mailhub.hcl.com (8.10.1/8.10.1) with SMTP id f8PLX3v01196; Tue, 25 Sep 2001 17:33:03 -0400 (EDT) From: "Dan Trufasiu" To: "'David Robinson'" , Subject: RE: open/remove sequence Date: Tue, 25 Sep 2001 17:40:54 -0400 Message-ID: <005c01c1460a$c18cc510$5a0c010a@hcl.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2910.0) In-Reply-To: <3BB0ADDB.87635300@Sun.COM> X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Importance: Normal Content-Transfer-Encoding: 7bit Hi David, One of the goals of the NFS version 4 was to make the protocol less UNIX dependent. And all of us agree that a lot was done in the protocol design to address Windows concerns. There are still some problem that we can not implement correctly and we will like to investigate the possibility to fix them. You are correct, we have the protocol for 2+ years, but as you have seen the "todo list" has 135 issues, some of them being opened for a long time. The native Windows procedure to delete a file is the following: 1) Open File with the DesiredAccess "DELETE" flag set, 2) Mark the file for delete (Set Information File with FileInformationClass = FileDispositionInformation) this means: Sets DeleteFile to TRUE so the file can be deleted when Close File is called to release the last open handle for the file. 3) Close the file when the delete file operation is supposed to be performed. There is no way that we can use the NFS Server for this procedure in NFS V3. And for this reason we try to emulate it. When I receive the request to mark for delete I ask for the file attributes and I try to decide using the attributes if a future REMOVE request will succeed or not. If my decision is wrong and a file can not be deleted at close the Windows will not process the CloseFile's error code. The result is a strange behavior when the file disappears and reappears. We have a lot of customers that complained about this behavior and our response is that the NFS protocol can not handle every Windows feature. Some of them understand, but some of them move to other solutions. What we try to do now is to limit as much as possible the people that move to other solution because the new protocol can not implement some very popular Windows features. You asked me what the Windows client will do if the request to REMOVE_ON_CLOSE is refused by the server? We will do what we are doing right now: We will have the same funny behavior. I'm sure that there are some Windows operation that are very difficult to be implemented in UNIX. I don't think that the introduction of the DENY_REMOVE flag can qualify as a impossibility. Thanks Dan > -----Original Message----- > From: robinson@phys-ha6nwka.ebay.sun.com > [mailto:robinson@phys-ha6nwka.ebay.sun.com]On Behalf Of David Robinson > Sent: Tuesday, September 25, 2001 12:16 PM > To: nfsv4-wg@sunroof.eng.sun.com > Subject: Re: open/remove sequence > > > > David's scenario (simple): > > 1. Client (C1) OPENs file > > 2. Client (C1) asks to REMOVE file > > 3. Server refuses to REMOVE OPENed file > > 4. Client (C1) renames file to .nfsxxxx (question of non > volatile file > > handle) > > 5. ANOTHER client (C2) asks to REMOVE .nfsxxxx (without OPEN) > > 6. Server refuses, because file is OPENed > > 7. Client C2 has no idea why REMOVE failed (possible to > solve with C1 > > SETATTR 000 after RENAME, > > but C2's request still may come between RENAME and SETATTR) > > I am willing to let this happen, I believe it is rare and the > problem exists today with no major complaints. > > > Another one: > > 1. Client (C1) OPENs file > > 2. Client (C1) asks to REMOVE file > > 3. Server refuses to REMOVE OPENed file > > 4. Client (C1) renames file to .nfsxxxx (question of non > volatile file > > handle) > > 5. ANOTHER client (C2) asks to OPEN .nfsxxxx -> Server responds OK > > 5. Client (C2) asks to REMOVE .nfsxxxx > > 6. Server refuses, because file is OPENed > > 7. C2 RENAMEs .nfsxxxx to .nfs1xxx > > 8. C1's LOOKUP for .nfsxxxx will fail > > 8. C1 CLOSEs file using file handle > > 9. C1 asks to REMOVE .nfsxxxx. Get's back to such file (by name, > > but by file handle file still exists -> possible caching problem) > > Same as before, problem exists today with no major complaints. > > > One more: > > 1. Client (C1) OPENs file > > 2. ANOTHER Client (C2) RENAMEs file to new_file_name > > 3. Client (C1) asks to REMOVE file -> failed: > file_not_exists. C1 can't do > > REMOVE on CLOSE > > Definately clients today have the third part remove causing unexpected > failoure problems. Without a namespace consistency protocol we have > no hope in solving this one. > > > Another big question when local OS REMOVEs OPENed file. > > As I said before, undefined behavior, most likely bad. > > > From my opinion this approach was fine for NFS v2 and v3, > when we did not > > have OPEN procedure, but with NFS v4 > > we may protect ourselves with OPEN operation. > > I think the OPEN procedure will allow servers to be smarter and better > handle removal of open files, but not perfectly. I just see it > as a small corner cases that has not be a big problem. > > > Windows scenario: > > Client wants to use file as temporary, remove it on close > and does NOT allow > > another clients to remove it > > 1. Client (C1) OPENs file with DENY_REMOVE, REMOVE_ON_CLOSE > (add flags to > > NFSv4 protocol) > > If these are "standard" windows open flags we should consider adding > them. > There semantics would need to be clearly defined and check to see if > they would cause conflicts with the Posix model of the directory > controling remove permissions. > > > The problems > > 1. OK_WILL_BE_DELETED_ON_LAST_CLOSE > > 2. REMOVE_ON_CLOSE state should survive reboot on Server > > In my previous e-mail, I stated I already believe that a server > will have to maintain state to handle remove on close if > it supports removal of open files, so I don't see this as > a problem. > > In reading Sergey's description of windows behavior, it seems > to be a good idea to add DENY_REMOVE and REMOVE_ON_CLOSE if > the semantics make sense (interesting question is if it > prevents actual removal of the file or any of the possibly > many hard links?). The Unix/Posix clients are still faced with > problems, they don't know at open if they will be wanting > a remove on close or have the capability to express DENY_REMOVE. > But those problems exist today and after 2+ years of protocol > design people are only now wondering if it might be a problem, > which to me proves it is not a real industry problem. > > Question back to Sergey, if a Windows client requests REMOVE_ON_CLOSE > or DENY_REMOVE and the server fails because it will not allow > it (either unimplemented or not part of the file system semantics) > how will the client handle it? Will it error to the application or > will it be able to set some client state that will issue the > remove after it closes the file? > > -David > From nfs4-wg-request@sunroof.eng.sun.com Tue Sep 25 20:12:37 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA18950 for ; Tue, 25 Sep 2001 20:12:36 -0400 (EDT) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id RAA28369; Tue, 25 Sep 2001 17:12:39 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id RAA12061; Tue, 25 Sep 2001 17:12:14 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.0+Sun/8.12.0) with ESMTP id f8Q0C07B029268 for ; Tue, 25 Sep 2001 17:12:00 -0700 (PDT) Received: from mercury.Sun.COM (mercury.EBay.Sun.COM [129.150.69.1]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id RAA11903 for ; Tue, 25 Sep 2001 17:12:03 -0700 (PDT) From: jbsptrsft55@yahoo.com Received: from surfsup.net ([65.168.244.3]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with SMTP id RAA28229 for ; Tue, 25 Sep 2001 17:11:56 -0700 (PDT) Message-Id: <200109260011.RAA28229@mercury.Sun.COM> To: Manufacturer<> Subject: ONLY 3 MORE DAYS! Free link/seats Manuf Prod/Cntrl Software $1,495! Date: Tue, 25 Sep 2001 17:15:29 +0100 X-Sender: jbsptrsft55@yahoo.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 Content-Type: text/plain; charset="us-ascii" X-Priority: 3 X-MSMail-Priority: Normal (ESP925) THE CHANCE TO SAVE $2,000.00 ON JOB MASTER PRODUCTION AND CONTROL SOFTWARE ENDS IN THREE DAYS. Until 5:00 PM PST September 28, Job Master, normally $2,495.00, is not only on sale for $1,495.00, but if we receive your order by the end of our working day Friday, September 28, you'll also receive two user licenses and a link to either Peach Tree, QuickBooks or Excel at no charge, AN ADDITIONAL THOUSAND DOLLAR SAVINGS. THIS OFFER WILL NOT BE EXTENDED BEYOND THIS FRIDAY, SEPTEMBER 28. Right now, and for the next three days only, $1,495.00 buyS you Job Master, two seats, and a link to either Peach Tree, QuickBooks or Excel. Job Master retails for $2,495.00. Seats are $150.00 and links are $750.00 each. THIS IS A $3,500.00 VALUE FOR $1,495.00 IF YOU ORDER BY FRIDAY, SEPTEMBER 28. Job Master is designed specifically for small to medium sized manufacturers, and even at our regular price of $2,495.00 costs many thousands of dollars less than any other even remotely comparable software package. If you've been waiting to upgrade your production control and tracking software or to computerize your operation, now is the time. For the next week, $1,495.00 gets you everything-Job Master network version, two user licenses, and a link to your accounting program or to Excel. (To reply by E Mail to this message or be removed from our list, Please go to the bottom of this message for an E Mail link. Please do not respond to us by hitting the "Reply" button. Our phone number is also located at the bottom of this message.) Job Master, a complete, user friendly Windows based software package, can manage and control your operation from sales quote to shipment. Following is a list of features. If you have any questions, would like to discuss the package further, or if you would like to obtain our Web site address for a total walk through of the program, please call me directly at (661) 286-0041. By way of background, we are a software company, which for some years has specialized in the development of custom software, primarily for small to medium sized manufacturers. Job Master is a distillation of over a million and a half dollars of software we have developed to control and manage the production of our manufacturing clients. Job Master contains the following features: 1. QUOTATION MODULE. In this module, quotes are developed, modified, and produced for sending to your client. A history is kept of all quotes for future reference, or modification for other clients. All quotations and revisions are "auto numbered," including versions. The quotes section allows for the entry of parts/processes, and costing of each, including materials, labor, markup, and taxes. Inventory status can be accessed from this section for reference. 2. SALES ORDER. Once a quotation is accepted, the final quotation information can be transformed into a Sales Order for your client's signature on a "point and click" basis. The Sales Order can be modified and re issued if necessary. A history if kept of all Sales Orders for future reference, or modification for other clients. All sales orders and revisions are "auto numbered," including versions. Inventory status can be accessed from this section for reference. 3. CUSTOMER LETTERS can be created from the Quotation and Sales Order sections. 4. SHOP TRAVELER/WORK ORDER. Once a Sales Order is accepted, the sales order information can be transformed into a shop traveler/work order on a "point and click" basis. Each item on the Sales Order becomes a shop traveler/work order, with each step of production of the item then listed on the traveler/work order. Each such traveler/work order is tied back into the Sales Order. The shop traveler/work order allows for the entry of line items, and notes on each line item. The shop traveler/work order contains a "notes" section. The Shop traveler/work order allows for the storing or attachment of drawings to the traveler/work order. The shop traveler/work order also contains a "drop down," from which standard processes can be selected for inclusion on the shop traveler/work order. The shop traveler/work order numbers progress in order of production sequence, and re numbers them if new steps are added. The shop traveler/work order allows for change orders or revisions, and numbers changes in sequence of the original shop traveler/work order number; i.e., 100, 100-1, 100-2, etc. All shop traveler/work orders and related revisions are retained in memory for future reference. The shop traveler/work order is bar coded for tracking of production step by step, and production of ongoing client status reports. Bar coding includes the ability for an employee to "swipe" their own ID bar code for recording in the system as to who upgraded what step. The shop traveler/work order function also allows for manual update of production status. The shop traveler/work order allows for quality control sign off, and the final production of certifications, either from a "canned" list, or hand typed in on a case by case basis. 5. INVENTORY. The application includes an inventory section, which allows operations to check materials inventory in and out. The inventory section allows for the comparison of inventory received against a P.O., and produces an "overage/underage" report of inventory received as compared against the P.O. The inventory section allows for the setting of minimum (re-order now!) and maximum inventory amounts, and produces reports showing what inventory needs to be ordered, as well as inventory that is at or above the maximum set to have in house. The inventory section also tracks "partially shipped" orders, which are tied in to the shipping function. This section shows how much completed product under a particular order has been actually shipped to a client, and how much remains to be shipped. The balance is adjusted as shipments are made. 6. REQUEST FOR PURCHASE. The application allows operators to produce a Request For Purchase for accounting for any inventory items, which need to be ordered. Inventory items have a drop down of approved vendors for each item. 7. REQUEST FOR BID. The application allows operators to produce a Request For Bid for accounting to send to Vendors for any inventory items, which need to be ordered. Inventory items have a drop down of approved vendors for each item to which Requests For Bid can be sent. 8. INVOICE. The application produces an invoice/invoice detail for all completed items ready to be billed/shipped to clients. 9. PRODUCTION OUTPUT STATUS. The application produces a date range selectable report on how much product, and the value of the product, which was completed during a selected date range. The application also produces a report on how many orders, and the value of those orders, which remain to be completed during a selected date range. 10. The application produces SHIPPING DOCUMENTS as per selected shippers, and produces a PACKING SLIP. 11. The application has a "FIND" FUNCTION in selected sections, allowing for searches by customer name, work order number, etc. 12. The application has "AUTO FILL;" i.e., when an operator starts to type in a name, number, etc. all related information auto fills after the first few letters or numbers are typed in. Job Master is currently being sold in the marketplace for $2,495.00 per package. However, if we receive your order by September 28, your total price will be $1,495.00 INCLUDING a free link to either Peach Tree, QuickBooks or Excel (a $750.00 value) and two free seats (a $300.00 value). Again, if you have any questions at all, or would like to place your order, please call me on my direct line, (661) 286-0041. Thank you! Wayne McFarland Link It Software Corp. ------------------------------------------------------------------------------------------ This message is sent in compliance of the new e-mail bill: SECTION 301. Per Section 301, Paragraph (a)(2)(C) of S. 1618. To REPLY or be REMOVED from this solicitated email list, please click on the E Mail address following this message and type "REMOVE" or "REPLY" in the subject line: jbsptrsf44@yahoo.com ------------------------------------------------------------------------------------------- From nfs4-wg-request@sunroof.eng.sun.com Wed Sep 26 09:13:33 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA17396 for ; Wed, 26 Sep 2001 09:13:33 -0400 (EDT) Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id GAA29812; Wed, 26 Sep 2001 06:13:32 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id GAA18307; Wed, 26 Sep 2001 06:12:34 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.0+Sun/8.12.0) with ESMTP id f8QDC97B001236; Wed, 26 Sep 2001 06:12:09 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id GAA13055; Wed, 26 Sep 2001 06:12:11 -0700 (PDT) From: SandyFisher@btamail.net.cn Received: from mail.psi.com.uy (mail.psi.com.uy [206.99.53.1]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id HAA24360; Wed, 26 Sep 2001 07:13:02 -0600 (MDT) Received: from sarandi.com.uy (122-146.w3.com.uy [207.3.122.146] (may be forged)) by mail.psi.com.uy (8.9.3/8.9.3) with SMTP id KAA18944; Wed, 26 Sep 2001 10:09:15 -0300 Message-Id: <200109261309.KAA18944@mail.psi.com.uy> Received: from 63.232.116.176 ([63.232.116.176]) by sarandi.com.uy (Lotus SMTP MTA Internal build v4.6.2 (651.2 6-10-1998)) with SMTP id 03256AD2.002B5C35; Tue, 25 Sep 2001 04:53:40 -0300 To: Subject: How KINKY do you think you are? Date: Tue, 25 Sep 2001 17:37:06 -0400 MIME-Version: 1.0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 Content-Transfer-Encoding: quoted-printable We COME To You

We've Got It ALL! 
There is Something for EVERYONE...

*Fastest Shippers *Di= screte Shipping *Lowest Prices 
*Hardcore DVD's Are Only $9.95 *Shop from the privacy of your home!<= /font>

Find The Hottest Vivid Virtual Sex!

Virtual Sex with Jenna = Jameson
The Biggest Adult Star Jenna Jameson and the Biggest Adult Store tea= m up to give you this Jenna/dvd Special! Interact with her, you choose the= sexual positions! You choose the camera angles! You choose her mood: inno= cent or nasty.

Virtual Sex with Taylor= Hayes

DVD - Interactive Shock Jock <= /font>
Take your seat behind the microphone of radio's most powerful man Ho= ward Stern and interact with Dasha, = Nikita, Kelsey, Brittany, Felecia, Payne, Jewel and Alexa as you DJ the hottest girls ever on DVD. Complete with multiple angles, tons of extras and the dir= ectorial debut of Gary the Retard!

For The Ladies...
DVD - "The Big O: An Erotic Guide to Better Orgasms&q= uot; 
There's good news: everyone can have easier, more fulfilling, and more = frequent orgasms! This is an exciting video guide to sexuality's most plea= surable, intense, and sometimes elusive experience: the orgasm. The joyful= and ecstatic orgasm is yours for the asking. Watch The Big O today with y= our partner - and start doing what comes naturally! 

DVD - "Nina Hartley's Maki= ng Love to Men":  Sensational sex superstar Nina Hartley is your tour guide thro= ugh this steamy instructional video. Nina teaches you first-hand how to fu= lfill a man's deepest sexual desires. Discover the sure-fire way to increa= se his pleasure - and yours!

Trea= t yourself and your partner to the BEST SEX... 

Need= Those Specialty Items to Spice up Your Relationship?

Adult Toys
Latest Titles & Widest selection of VHS
And much more!
There is something to PLEASURE EVERYONE here...
All from the PRIVACY of your own HOME!
 
Please note that this site contai= ns sexually oriented adult material intended for individuals 18 years of a= ge or older and of legal age to view sexually explicit material as determi= ned by the local and national laws of the region in which you reside. If y= ou are not yet 18, if adult material offends you, or if you are accessing = this site from any country or locale where adult material is specifically = prohibited by law please disregard this message. 

By clicking "ENTER VIDEO STORE" below, you have read this and agreed to t= his statement.

ENTER VIDEO STORE

This Month's Special&n= bsp;
*Vivid Interactive CD's $19.99

All CDs contain:
*The hottest Vivid Girls 
*Work on Both Mac and PC 
*Some contain Virtual Games, posters, Bios, etc.

Get it While It's HOT!=

 
We support responsible emailing. If= this is not of interest to you, please forgive the intrusion. If you do n= ot wish to receive further mailings, please click below and enter your ema= il at the bottom of the page. You may then rest-assured that you will neve= r receive another email from us again.  UNSUBSC= RIBE ME PLEASE #022154.
From nfs4-wg-request@sunroof.eng.sun.com Wed Sep 26 15:07:28 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA26616 for ; Wed, 26 Sep 2001 15:07:28 -0400 (EDT) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA01224; Wed, 26 Sep 2001 13:07:17 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA25938; Wed, 26 Sep 2001 12:05:42 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.0+Sun/8.12.0) with ESMTP id f8QJ5T7B002972 for ; Wed, 26 Sep 2001 12:05:29 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA28939; Wed, 26 Sep 2001 12:05:31 -0700 (PDT) Received: from eagle.professionals.com (eagle.professionals.com [206.127.192.10]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA29550; Wed, 26 Sep 2001 13:05:19 -0600 (MDT) Received: from eisler.com ([206.27.132.50]) (authenticated) by eagle.professionals.com (8.10.2/8.10.2) with ESMTP id f8QJ2v914247; Wed, 26 Sep 2001 12:03:00 -0700 (PDT) Sender: mre@eagle.professionals.com Message-ID: <3BB226F3.D39C6844@eisler.com> Date: Wed, 26 Sep 2001 12:05:23 -0700 From: Mike Eisler X-Mailer: Mozilla 4.7 [en] (X11; I; SunOS 5.8 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: shepler@eng.sun.com CC: nfsv4-wg@sunroof.eng.sun.com Subject: Re: Issues list for RFC3010 References: <20010919194746.F398@dhcp-aus08-191.central.sun.com> <20010920142934.O399@dhcp-aus08-191.central.sun.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Spencer Shepler wrote: > > On Thu, Sergey Klyushin wrote: > > >Issue08: > > >Change of "tag" in COMPOUND4args. At a minimum the server should return the > > same tag length/contents that were >included in the request. Alternate > > changes are: fixed length tag or no tag at all. > > > > I vote to remove "tag" at all. If it used for debugging - use snoop, if it > > used for caching - use something else (xids from RPC) > > Well, I have found that in using snoop it is really nice to have a tag > string to give you some indication of what the client is attempting to > accomplish with the string of COMPOUND operations. I have to agree. For example it is useful to distinguish a sequence of operations that has LOOKUP from the many possible uses, such a mounting a filesystem, stat()ing a file, etc. From nfs4-wg-request@sunroof.eng.sun.com Thu Sep 27 17:24:05 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA13880 for ; Thu, 27 Sep 2001 17:24:04 -0400 (EDT) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA21553; Thu, 27 Sep 2001 15:23:52 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA02533; Thu, 27 Sep 2001 14:23:31 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.0+Sun/8.12.0) with ESMTP id f8RLNK7B021514 for ; Thu, 27 Sep 2001 14:23:20 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA19376 for ; Thu, 27 Sep 2001 14:23:21 -0700 (PDT) From: jbsptrsft88@yahoo.com Received: from surfsup.net ([65.168.244.3]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with SMTP id PAA27145 for ; Thu, 27 Sep 2001 15:24:13 -0600 (MDT) Message-Id: <200109272124.PAA27145@lukla.Sun.COM> To: Manufacturer<> Subject: One Day Left! Free link/seats Manuf Prod/Cntrl Software $1,495! Date: Thu, 27 Sep 2001 14:26:56 +0100 X-Sender: jbsptrsft88@yahoo.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 Content-Type: text/plain; charset="us-ascii" X-Priority: 3 X-MSMail-Priority: Normal (ESP927) THE CHANCE TO SAVE $2,000.00 ON JOB MASTER PRODUCTION AND CONTROL SOFTWARE ENDS IN ONE DAY. Until 5:00 PM PST September 28, Job Master, normally $2,495.00, is not only on sale for $1,495.00, but if we receive your order by the end of our working day Friday, September 28, you'll also receive two user licenses and a link to either Peach Tree, QuickBooks or Excel at no charge, AN ADDITIONAL THOUSAND DOLLAR SAVINGS. THIS OFFER WILL NOT BE EXTENDED BEYOND THIS FRIDAY, SEPTEMBER 28. Right now, $1,495.00 buys you Job Master, two seats, and a link to either Peach Tree, QuickBooks or Excel. Job Master retails for $2,495.00. Seats are $150.00 and links are $750.00 each. THIS IS A $3,500.00 VALUE FOR $1,495.00 IF YOU ORDER BY FRIDAY, SEPTEMBER 28. Job Master is designed specifically for small to medium sized manufacturers, and even at our regular price of $2,495.00 costs many thousands of dollars less than any other even remotely comparable software package. If you've been waiting to upgrade your production control and tracking software or to computerize your operation, now is the time. For one more day, $1,495.00 gets you everything-Job Master network version, two user licenses, and a link to your accounting program or to Excel. (To reply by E Mail to this message or be removed from our list, Please go to the bottom of this message for an E Mail link. Please do not respond to us by hitting the "Reply" button. Our phone number is also located at the bottom of this message.) Job Master, a complete, user friendly Windows based software package, can manage and control your operation from sales quote to shipment. Following is a list of features. If you have any questions, would like to discuss the package further, or if you would like to obtain our Web site address for a total walk through of the program, please call me directly at (661) 286-0041. By way of background, we are a software company, which for some years has specialized in the development of custom software, primarily for small to medium sized manufacturers. Job Master is a distillation of over a million and a half dollars of software we have developed to control and manage the production of our manufacturing clients. Job Master contains the following features: 1. QUOTATION MODULE. In this module, quotes are developed, modified, and produced for sending to your client. A history is kept of all quotes for future reference, or modification for other clients. All quotations and revisions are "auto numbered," including versions. The quotes section allows for the entry of parts/processes, and costing of each, including materials, labor, markup, and taxes. Inventory status can be accessed from this section for reference. 2. SALES ORDER. Once a quotation is accepted, the final quotation information can be transformed into a Sales Order for your client's signature on a "point and click" basis. The Sales Order can be modified and re issued if necessary. A history if kept of all Sales Orders for future reference, or modification for other clients. All sales orders and revisions are "auto numbered," including versions. Inventory status can be accessed from this section for reference. 3. CUSTOMER LETTERS can be created from the Quotation and Sales Order sections. 4. SHOP TRAVELER/WORK ORDER. Once a Sales Order is accepted, the sales order information can be transformed into a shop traveler/work order on a "point and click" basis. Each item on the Sales Order becomes a shop traveler/work order, with each step of production of the item then listed on the traveler/work order. Each such traveler/work order is tied back into the Sales Order. The shop traveler/work order allows for the entry of line items, and notes on each line item. The shop traveler/work order contains a "notes" section. The Shop traveler/work order allows for the storing or attachment of drawings to the traveler/work order. The shop traveler/work order also contains a "drop down," from which standard processes can be selected for inclusion on the shop traveler/work order. The shop traveler/work order numbers progress in order of production sequence, and re numbers them if new steps are added. The shop traveler/work order allows for change orders or revisions, and! ! ! ! numbers changes in sequence of the original shop traveler/work order number; i.e., 100, 100-1, 100-2, etc. All shop traveler/work orders and related revisions are retained in memory for future reference. The shop traveler/work order is bar coded for tracking of production step by step, and production of ongoing client status reports. Bar coding includes the ability for an employee to "swipe" their own ID bar code for recording in the system as to who upgraded what step. The shop traveler/work order function also allows for manual update of production status. The shop traveler/work order allows for quality control sign off, and the final production of certifications, either from a "canned" list, or hand typed in on a case by case basis. 5. INVENTORY. The application includes an inventory section, which allows operations to check materials inventory in and out. The inventory section allows for the comparison of inventory received against a P.O., and produces an "overage/underage" report of inventory received as compared against the P.O. The inventory section allows for the setting of minimum (re-order now!) and maximum inventory amounts, and produces reports showing what inventory needs to be ordered, as well as inventory that is at or above the maximum set to have in house. The inventory section also tracks "partially shipped" orders, which are tied in to the shipping function. This section shows how much completed product under a particular order has been actually shipped to a client, and how much remains to be shipped. The balance is adjusted as shipments are made. 6. REQUEST FOR PURCHASE. The application allows operators to produce a Request For Purchase for accounting for any inventory items, which need to be ordered. Inventory items have a drop down of approved vendors for each item. 7. REQUEST FOR BID. The application allows operators to produce a Request For Bid for accounting to send to Vendors for any inventory items, which need to be ordered. Inventory items have a drop down of approved vendors for each item to which Requests For Bid can be sent. 8. INVOICE. The application produces an invoice/invoice detail for all completed items ready to be billed/shipped to clients. 9. PRODUCTION OUTPUT STATUS. The application produces a date range selectable report on how much product, and the value of the product, which was completed during a selected date range. The application also produces a report on how many orders, and the value of those orders, which remain to be completed during a selected date range. 10. The application produces SHIPPING DOCUMENTS as per selected shippers, and produces a PACKING SLIP. 11. The application has a "FIND" FUNCTION in selected sections, allowing for searches by customer name, work order number, etc. 12. The application has "AUTO FILL;" i.e., when an operator starts to type in a name, number, etc. all related information auto fills after the first few letters or numbers are typed in. Job Master is currently being sold in the marketplace for $2,495.00 per package. However, if we receive your order by September 28, your total price will be $1,495.00 INCLUDING a free link to either Peach Tree, QuickBooks or Excel (a $750.00 value) and two free seats (a $300.00 value). Again, if you have any questions at all, or would like to place your order, please call me on my direct line, (661) 286-0041. Thank you! Wayne McFarland Link It Software Corp. ------------------------------------------------------------------------------------------ This message is sent in compliance of the new e-mail bill: SECTION 301. Per Section 301, Paragraph (a)(2)(C) of S. 1618. To REPLY or be REMOVED from this solicitated email list, please click on the E Mail address following this message and type "REMOVE" or "REPLY" in the subject line: jbsptrsft88@yahoo.com ------------------------------------------------------------------------------------------- From nfs4-wg-request@sunroof.eng.sun.com Thu Sep 27 21:44:42 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA18138 for ; Thu, 27 Sep 2001 21:44:41 -0400 (EDT) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id SAA10235; Thu, 27 Sep 2001 18:44:43 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id SAA01692; Thu, 27 Sep 2001 18:44:01 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.0+Sun/8.12.0) with ESMTP id f8S1hf7B023449; Thu, 27 Sep 2001 18:43:41 -0700 (PDT) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id SAA25174; Thu, 27 Sep 2001 18:43:43 -0700 (PDT) From: tpptm@worldmailer.com Received: from lech.wokiss.pl (lech.wokiss.wlkp.pl [195.117.236.34]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id SAA11497; Thu, 27 Sep 2001 18:43:40 -0700 (PDT) Received: from 195.117.236.34 (ts004d40.pro-ri.concentric.net [206.173.11.196]) by lech.wokiss.pl (8.8.8/Mizeria v7.0) with SMTP id DAA14364; Fri, 28 Sep 2001 03:38:50 +0200 (CETDST) Message-Id: <200109280138.DAA14364@lech.wokiss.pl> Date: Thu, 27 Sep 01 20:24:44 EST To: dswq8edn@jdw21k3x.com Subject: Don't delete this! The Program ------------------------------------------------------------------------------------------------------- AS SEEN ON NATIONAL TV --- INCREDIBLE $0 to $50,000 in 90 days!!! ------------------------------------------------------------------------------------------------------- You can earn $50,000 or more in next the 90 days sending e-mail. Seem impossible? Read on for details. This is the letter you've been reading about in the news lately. Due to the popularity of this letter on the Internet, a major nightly news program recently devoted an entire show to the investigation of the program described below to see if it really can make people money. The show also investigated whether or not the program was legal. Their findings proved once and for all that there are absolutely no laws prohibiting the participation in the program. This has helped to show people that this is a simple, harmless and fun way to make some extra money at home. The results of this show have been truly remarkable. So many people are participating that those involved are doing much better than ever before. Since everyone makes more as more people try it out, its been very exciting to be a part of lately. You will understand once you experience it. HERE IT IS BELOW: *** Print This Now For Future Reference *** The following income opportunity is one you may be interested in taking a look at. It can be started with VERY LITTLE investment and the income return is TREMENDOUS!!! $$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$ If you would like to make at least $50,000 in less than 90 days ! Please read the enclosed program...THEN READ IT AGAIN!!! $$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$ THIS IS A LEGITIMATE, LEGAL, MONEY MAKING OPPORTUNITY.It does not require you to come into contact with people, do any hard work, and best of all, you never have to leave the house except to get the mail. If you believe that someday you'll get that big break that you 'vebeen waiting for, THIS IS IT! Simply follow the instructions, andyour dreams will come true. This multi-level e-mail order marketingprogram works perfectly...100% EVERY TIME. E-mail is the sales tool of the future. Take advantage of this non-commercialized method of advertising NOW!!! The longer you wait, the more people will be doing business using e-mail. Get your piece of this action!!! MULTI-LEVEL MARKETING (MLM) has finally gained respectability. It is being taught in the Harvard Business School, and both Stanford Research and the Wall Street Journal have stated that between 50% and 65% of all goods and services will be sold through multi-level methods by the mid to late 1990's. This is a Multi-Billion Dollar industry and of the 500,000 millionaires in the U.S., 20% (100,000) made their fortune in the last several years in MLM. Moreover, statistics show 45 people become millionaires everyday through Multi-Level Marketing. You may have heard this story before, but over the summer Donald Trump made an appearance on the David Letterman show. Dave asked him what he would do if he lost everything and had to start over from scratch. Without hesitating, Trump said he would find a good network marketing company and get to work. The audience started to hoot and boo him. He looked out at the audience and dead-panned his response: "That's why I'm sitting up here and you are all sitting out there!" The enclosed information is something I almost let slip through my fingers. Fortunately, sometime later I re-read everything and gave somethought and study to it. My name is Johnathon Rourke. Two years ago, the corporation I worked at for the past twelve years down-sized and my position was eliminated. After unproductive job interviews, I decided to open my own business. Over the past year, I incurred many unforeseen financial problems. I owed my family, friends and creditors over $35,000. The economy was taking a toll on my business and I just couldn't seem to make ends meet. I had to refinance and borrow against my home to support my family and struggling business. AT THAT MOMENT something significant happened in my life and I am writing to share the experience in hopes that this will change your life FOREVER FINANCIALLY!!! In mid December, I received this program via e-mail. Six month's prior to receiving this program I had been sending away for information on various business opportunities. All of the programs I received, in my opinion, were not cost effective. They were either too difficult for me to comprehend or the initial investment was too much for me to risk to see if they would work or not. One claimed that I would make a million dollars in one year...it didn't tell me I'd have to write a book to make it! But like I was saying, in December of 1997 I received this program. I didn't send for it, or ask for it, they just got my name off a mailing list.THANK GOODNESS FOR THAT!!! After reading it several times, to make sure I was reading it correctly, I couldn't believe my eyes. Here was a MONEY MAKING PHENOMENON. I could invest as much as I wanted to start, without putting me further into debt. After I got a pencil and paper and figured it out, I would at least get my money back. But like most of you I was still a little skeptical and a little worried about the legal aspects of it all. So I checked it out with the U.S. Post Office (1-800-725-2161 24-hrs) and they confirmed that it is indeed legal! After determining the program was LEGAL and NOT A CHAIN LETTER, I decided "WHY NOT." Initially I sent out 10,000 e-mails. It cost me about $15 for my time on-line. The great thing about e-mail is that I don't need any money for printing to send out the program, and because all of my orders are fulfilled via e-mail, my only expense is my time. I am telling you like it is I hope it doesn't turn you off, but I promised myself that I would not "rip-off" anyone, no matter how much money it made me. In less than one week, I was starting to receive orders for REPORT #1 By January 13, I had received 26 orders for REPORT #1. Your goal is to "RECEIVE at least 20 ORDERS FOR REPORT #1 WITHIN 2 WEEKS. IF YOU DON'T, SEND OUT MORE PROGRAMS UNTIL YOU DO!" My first step in making $50,000 in 90 days was done. By January 30, I had received 196 orders for REPORT #2. Your goal is to "RECEIVE AT LEAST 100+ ORDERS FOR REPORT #2 WITHIN 2 WEEKS. IF NOT, SEND OUT MORE PROGRAMS UNTIL YOU DO. ONCE YOU HAVE 100 ORDERS, THE REST IS EASY, RELAX, YOU WILL MAKE YOUR $50,000 GOAL." Well, I had 196 orders for REPORT #2, 96 more than I needed. So I sat back and relaxed. By March 1, of my e-mailing of 10,000, I received $58,000 with more coming in every day. I paid off ALL my debts and bought a much needed new car. Please take time to read the attached program, IT WILL CHANGE YOUR LIFE FOREVER!! ! Remember, it won't work if you don't try it. This program does work , but you must follow it EXACTLY! Especially the rules of not trying to place your name in a different place. It won't work and you'll lose out on a lot of money! In order for this program to work, you must meet your goal of 20+ orders for REPORT #1, and 100+ orders for REPORT #2 and you will make $50,000 or more in 90 days. I AM LIVING PROOF THAT IT WORKS!!! If you choose not to participate in this program, I am sorry. It really is a great opportunity with little cost or risk to you. If you choose to participate, follow the program and you will be on your way to financial security. If you are a fellow business owner and are in financial trouble like I was, or you want to start your own business, consider this a sign. I DID! Sincerely, Johnathon Rourke A PERSONAL NOTE FROM THE ORIGINATOR OF THIS PROGRAM: By the time you have read the enclosed program and reports, you should have concluded that such a program, and one that is legal, could not have been created by an amateur. Let me tell you a little about myself. I had a profitable business for 10 years. Then in 1979 my business began falling off. I was doing the same things that were previously successful for me, but it wasn't working. Finally, I figured it out. It wasn't me, it was the economy. Inflation and recession had replaced the stable economy that had been with us since 1945.I don't have to tell you what happened to the unemployment rate... because many of you know from first hand experience. There were more failures and bankruptcies than ever before. The middle class was vanishing. Those who knew what they were doing invested wisely and moved up. Those who did not, including those who never had anything to save or invest, were moving down into the ranks of the poor. As the saying goes, "THE RICH GET RICHER AND THE POOR GET POORER." The traditional methods of making money will never allow you to "move up" or "get rich", inflation will see to that. You have just received information that can give you financial freedom for the rest of your life, with "NO RISK" and "JUST A LITTLE BIT OF EFFORT." You can make more money in the next few months than you have ever imagined. I should also point out that I will not see a penny of this money, nor anyone else who has provided a testimonial for this program. I have already made over 4 MILLION DOLLARS!I have retired from the program after sending thousands and thousands of programs. Follow the program EXACTLY AS INSTRUCTED. Do not change it in any way . It works exceedingly well as it is now. Remember to e-mail a copy of this exciting report to everyone you can think of. One of the people you send this to may send out 50,000...and your name will be on everyone of them! Remember though, the more you send out the more potential customers you will reach. So my friend, I have given you the ideas, information, materials and opportunity to become financially independent. IT IS UP TO YOU NOW! "THINK ABOUT IT" Before you delete this program from your mailbox, as I almost did, take a little time to read it and REALLY THINK ABOUT IT. Get a pencil and figure out what could happen when YOU participate. Figure out the worst possible response and no matter how you calculate it, you will still make a lot of money! You will definitely get back what you invested. Any doubts you have will vanish when your first orders come in. IT WORKS! Jody Jacobs, Richmond, VA HERE'S HOW THIS AMAZING PROGRAM WILL MAKE YOU THOUSANDS OF DOLLAR$ INSTRUCTIONS: This method of raising capital REALLY WORKS 100% EVERY TIME. I am sure that you could use up to $50,000 or more in the next 90 days. Before you say "BULL... ", please read this program carefully. This is not a chain letter, but a perfectly legal money making opportunity. Basically, this is what you do: As with all multi-level businesses, we build our business by recruiting new partners and selling our products. Every state in the USA allows you to recruit new multi-level business partners, and we offer a product for EVERY dollar sent. YOUR ORDERS COME BY MAIL AND ARE FILLED BY E-MAIL, so you are not involved in personal selling. You do it privately in your own home, store or office. This is the GREATEST Multi-Level Mail Order Marketing anywhere. This is what you MUST do: 1. Order all 4 reports shown on the list below (you can't sell them if youdon't order them). -- For each report, send $5.00 CASH, the NAME & NUMBER OF THE REPORT YOU ARE ORDERING, YOUR E-MAIL ADDRESS, and YOUR NAME & RETURN ADDRESS (in case of a problem) to the person whose name appears on the list next to the report. MAKE SURE YOUR RETURN ADDRESS IS ON YOUR ENVELOPE IN CASE OF ANY MAIL PROBLEMS! -- When you place your order, make sure you order each of the four reports. You will need all four reports so that you can save them on your computer and resell them. -- Within a few days you will receive, via e-mail, each of the four reports. Save them on your computer so they will be accessible for you to send to the 1,000's of people who will order them from you. 2. IMPORTANT DO NOT alter the names of the people who are listed next to each report, or their sequence on the list, in any way other than is instructed below in steps "a" through "f" or you will lose out on the majority of your profits. Once you understand the way this works, you'll also see how it doesn't work if you change it. Remember, this method has been tested,and if you alter it, it will not work. a. Look below for the listing of available reports. b. After you've ordered the four reports, take this advertisement and remove the name and address under REPORT #4. This person has made it through the cycle and is no doubt counting their $50,000! c. Move the name and address under REPORT #3 down to REPORT #4. d. Move the name and address under REPORT #2 down to REPORT #3. e. Move the name and address under REPORT #1 down to REPORT #2. f. Insert your name/address in the REPORT #1 position. Please make sure you COPY ALL INFORMATION, every name and address, ACCURATELY! 3. Take this entire letter, including the modified list of names, and save it to your computer. Make NO changes to the instruction portion of this letter. Your cost to participate in this is practically nothing (surely you can afford $20). You obviously already have an Internet connection and e-mail is FREE! There are two primary methods of building your downline: METHOD #1: SENDING BULK E-MAIL Let's say that you decide to start small, just to see how it goes, and we'll assume you and all those involved send out only 2,000 programs each. Let's also assume that the mailing receives a 0.5% response. Using a good list the response could be much better. Also, many people will send out hundreds of thousands of programs instead of 2,000. But continuing with this example, you send out only 2,000 programs. With a 0.5% response, that is only 10 orders for REPORT #1. Those 10 people respond by sending out 2,000 programs each for a total of 20,000. Out of those 0.5%, 100 people respond and order REPORT #2. Those 100 mail out 2,000 programs each for a total of 200,000. The 0.5% response to that is 1,000 orders for REPORT #3. Those 1,000 send out 2,000 programs each for a 2,000,000 total. The 0.5% response to that is 10,000 orders for REPORT #4. That's 10,000 $5 bills for you. CASH!!! Your total income in this example is $50 + $500 + $5,000 + $50,000 for a total of $55,550!!! REMEMBER FRIEND, THIS IS ASSUMING 1,990 OUT OF THE 2,000 PEOPLE YOU MAIL TO WILL DO ABSOLUTELY NOTHING AND TRASH THIS PROGRAM! DARE TO THINK FOR A MOMENT WHAT WOULD HAPPEN IF EVERYONE, OR HALF SENT OUT 100,000 PROGRAMS INSTEAD OF 2,000. Believe me, many people will do justthat, and more! By the way, your cost to participate in this is practically nothing. You obviously already have an Internet connection and e-mail is FREE!!! REPORT #2 will show you the best methods for bulk e-mailing, tell you where to obtain free bulk e-mail software and where to obtain e-mail lists. METHOD #2 - PLACING FREE ADS ON THE INTERNET Advertising on the internet is very, very inexpensive, and there are HUNDREDS of FREE places to advertise. Let's say you decide to start small just to see how well it works. Assume your goal is to get ONLY 10 people to participate on your first level. (Placing a lot of FREE ads on the Internet will EASILY get a larger response.) Also assume that everyone else in YOUR ORGANIZATION gets ONLY 10 downline members. Follow this example to achieve the STAGGERING results below: 1st level--your 10 members with $5.......................................$50 2nd level--10 members from those 10 ($5 x 100)..................$500 3rd level--10 members from those 100 ($5 x 1,000)...........$5,000 4th level--10 members from those 1,000 ($5 x 10,000).....$50,000 THIS TOTALS ---------->$55,550 Remember friends, this assumes that the people who participate only recruit 10 people each. Think for a moment what would happen if they got 20 people to participate! Most people get 100's of participants! THINK ABOUT IT! For every $5.00 you receive, all you must do is e-mail them the report they ordered. THAT'S IT! ALWAYS PROVIDE SAME-DAY SERVICE ON ALL ORDERS! This will guarantee that the e-mail THEY send out with YOUR name and address on it will be prompt because they can't advertise until they receive the report! AVAILABLE REPORTS *** Order Each REPORT by NUMBER and NAME *** Notes: -- ALWAYS SEND $5 CASH (U.S. CURRENCY) FOR EACH REPORT. CHECKS NOT ACCEPTED. -- ALWAYS SEND YOUR ORDER VIA FIRST CLASS MAIL. -- Make sure the cash is concealed by wrapping it in at least two sheets of paper. On one of those sheets of paper, include: (a) the number & name of the report you are ordering, (b) your e-mail address, and (c) your name & postal address. PLACE YOUR ORDER FOR THESE REPORTS NOW: REPORT #1 "The Insider's Guide to Advertising for Free on the Internet" ORDER REPORT #1 FROM: M. Harnar P.O. Box 3728 New York, NY 10163 REPORT #2 "The Insider's Guide to Sending Bulk E-Mail on the Internet" ORDER REPORT #2 FROM: J. Hogston P.O. Box 241357 Apple Valley, MN 55124-1357 REPORT #3 ""The Secrets to Multi-level Marketing on the Internet" ORDER REPORT #3 FROM: E- Solutions 101 PO Box 6411 Providence, RI 02940 REPORT #4 "How to Become a Millionaire Utilizing the Power of Multi-level Marketing and the Internet" ORDER REPORT #4 FROM: D.Vasicak 479 Bennett street Luzerne, PA 18709 About 50,000 new people get online every month! ******* TIPS FOR SUCCESS ******* -- TREAT THIS AS YOUR BUSINESS! Be prompt, professional, and follow the directions accurately. -- Send for the four reports IMMEDIATELY so you will have them when the orders start coming in because: When you receive a $5 order, you MUST send out the requested product/report. -- ALWAYS PROVIDE SAME-DAY SERVICE ON THE ORDERS YOU RECEIVE. -- Be patient and persistent with this program. If you follow the instructions exactly, your results WILL BE SUCCESSFUL! -- ABOVE ALL, HAVE FAITH IN YOURSELF AND KNOW YOU WILL SUCCEED! ******* YOUR SUCCESS GUIDELINES ******* Follow these guidelines to guarantee your success: If you don't receive 20 orders for REPORT #1 within two weeks, continue advertising or sending e-mails until you do. Then, a couple of weeks later you should receive at least 100 orders for REPORT#2. If you don 't, continue advertising or sending e-mails until you do. Once you have received 100 or more orders for REPORT #2, YOU CAN RELAX, because the system is already working for you, and the cash will continue to roll in! THIS IS IMPORTANT TO REMEMBER: Every time your name is moved down on the list, you are placed in front of a DIFFERENT report. You can KEEP TRACK of your PROGRESS by watching which report people are ordering from you. If you want to generate more income, send another batch of e-mails or continue placing ads and start the whole process again! There is no limit to the income you will generate from this business! Before you make your decision as to whether or not you participate in this program. Please answer one question. DO YOU WANT TO CHANGE YOUR LIFE? If the answer is yes, please look at the following facts about this program: 1. You are selling a product which does not Cost anything to PRODUCE, SHIP OR ADVERTISE. 2. All of your customers pay you in CASH! 3. E-mail is without question the most powerful method of distributing information on earth. This program combines the distribution power of e-mail together with the revenue generating power of multi-level marketing. 4. Your only expense--other than your initial $20 investment--is your time! 5. Virtually all of the income you generate from this program is PURE PROFIT! 6. This program will change your LIFE FOREVER. ACT NOW!Take your first step toward achieving financial independence. Orderthe reports and follow the program outlined above--SUCCESSwill be yourreward. Thank you for your time and consideration. PLEASE NOTE: If you need help with starting a business, registering a business name, learning how income tax is handled, etc., contact your localoffice of the Small Business Administration (a Federal Agency) 1-800-827-5722 for free help and answers to questions. Also, the InternalRevenue Service offers free help via telephone and free seminars aboutbusiness tax requirements. Your earnings are highly dependant on youractivities and advertising. The information contained on this site and in the report constitutes no guarantees stated nor implied. In the event that it is determined that this site or report constitutes a guarantee of any kind, that guarantee is now void. The earnings amounts listed on this site and in the report are estimates only. If you have any questions of the legality of this program, contact the Office of Associate Director for Marketing Practices, Federal Trade Commission, Bureau of Consumer Protection in Washington, DC. ///////////////////////////////////////////////////////////////// Remove at tpptm@netscape.net ///////////////////////////////////////////////////////////////// From nfs4-wg-request@sunroof.eng.sun.com Fri Sep 28 02:58:54 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA05840 for ; Fri, 28 Sep 2001 02:58:53 -0400 (EDT) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id XAA14569; Thu, 27 Sep 2001 23:58:56 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id XAA06299; Thu, 27 Sep 2001 23:58:37 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.0+Sun/8.12.0) with ESMTP id f8S6wQ7B024743 for ; Thu, 27 Sep 2001 23:58:26 -0700 (PDT) Received: from venus.sun.com (venus.EBay.Sun.COM [129.150.69.5]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id XAA02961 for ; Thu, 27 Sep 2001 23:58:29 -0700 (PDT) Received: from mail2.forss.net ([62.119.36.90]) by venus.sun.com (8.9.3+Sun/8.9.3) with SMTP id XAA20683 for ; Thu, 27 Sep 2001 23:58:27 -0700 (PDT) Date: Thu, 27 Sep 2001 23:58:27 -0700 (PDT) Received: (qmail 21139 invoked from network); 28 Sep 2001 06:06:37 -0000 Received: from unknown (HELO star.lotte.com) (62.100.128.7) by mail2.forss.net with SMTP; 28 Sep 2001 06:06:37 -0000 From: "dealsmart1@lotte.com" To: "1116@msn.com" <1116@msn.com> Message-ID: <1001653951.0749251193@star.lotte.com> Subject: Conference Calls For Less MIME-Version: 1.0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Take Control Of Your Conference Calls =

Long Distance Conferencing
Only 18 Cents Per Minute

Connects Up To 100 Participants=21

  • No setup fees
  • No contracts or monthly fees
  • Call anytime, from anywhere, to anywhere
  • International Dial In 18 cents per minute
  • Simplicity in set up and administration
  • Operator Help available 24/7

    • G= et the best quality, the easiest to use, and lowest rate in the industry.

    If you like saving = money, fill out the form below and one of our consultants will contact you.

    Required Input Field*

    Name*
    Web Address*
    Company Name*
    State*
    Business Phone*
    Home Phone
    Email Address*
    Type of Business

    This could be your ad=21
    Click here to e-mail us your contact info.
    This ad is being sent in compliance with Senate Bill 1618= , Title 3, Section 301. You have recently visited our web site, referral or = affiliate sites which indicated you were interested in communication servic= es. If this email is reaching you in error and you feel that you have no= t contacted us, Click here. We sincerely apologize, and assure you will be r= emoved from our distribution list.

     From nfs4-wg-request@sunroof.eng.sun.com Fri Sep 28 08:59:02 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA13105 for ; Fri, 28 Sep 2001 08:59:01 -0400 (EDT) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id GAA11062; Fri, 28 Sep 2001 06:58:54 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id FAA07448; Fri, 28 Sep 2001 05:58:42 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.0+Sun/8.12.0) with ESMTP id f8SCwT7B025667 for ; Fri, 28 Sep 2001 05:58:29 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id FAA28859 for ; Fri, 28 Sep 2001 05:58:31 -0700 (PDT) Received: from a88.lambo.student.liu.se (a88.lambo.student.liu.se [130.236.229.88]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id GAA15064 for ; Fri, 28 Sep 2001 06:59:27 -0600 (MDT) Received: by a88.lambo.student.liu.se (Postfix, from userid 500) id 7A32534CDD; Fri, 28 Sep 2001 14:58:27 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by a88.lambo.student.liu.se (Postfix) with ESMTP id 74651CF39 for ; Fri, 28 Sep 2001 14:58:27 +0200 (CEST) Date: Fri, 28 Sep 2001 14:58:27 +0200 (CEST) From: =?iso-8859-1?Q?Peter_=C5strand?= X-X-Sender: To: Subject: clientaddr4 contents Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=iso-8859-1 Content-Transfer-Encoding: 8BIT Content-Transfer-Encoding: 8BIT What should cb_location contain when a SETCLIENTID call is made? 3010 says: struct clientaddr4 { /* see struct rpcb in RFC 1833 */ string r_netid<>; /* network id */ string r_addr<>; /* universal address */ }; RFC1833 only explains r_netid, not r_addr, and only says: " "a local identification for a network", "based on local conventions". This does not give me much information. How should these components be used? -- Peter Åstrand Telephone: +46-13-29 08 61 Cendio Systems E-mail: peter@cendio.se Teknikringen 3 583 30 Linköping From nfs4-wg-request@sunroof.eng.sun.com Sat Sep 29 02:10:00 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA14150 for ; Sat, 29 Sep 2001 02:09:59 -0400 (EDT) Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id XAA13157; Fri, 28 Sep 2001 23:10:00 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id XAA03842; Fri, 28 Sep 2001 23:09:16 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.0+Sun/8.12.0) with ESMTP id f8T68p7B028580; Fri, 28 Sep 2001 23:08:51 -0700 (PDT) Received: from venus.sun.com (venus.EBay.Sun.COM [129.150.69.5]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id XAA03804; Fri, 28 Sep 2001 23:08:53 -0700 (PDT) From: aaezwppqt@hotmail.com Received: from mail.toshibatr.com ([212.58.19.66]) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id XAA27943; Fri, 28 Sep 2001 23:08:48 -0700 (PDT) Received: from 63.232.112.17 ([63.232.112.17]) by mail.toshibatr.com with Microsoft SMTPSVC(5.0.2195.2966); Fri, 28 Sep 2001 04:02:06 +0300 To: Subject: SHY ABOUT YOUR PACAKGE? MAKE IT BIGGER!!! Date: Thu, 27 Sep 2001 18:54:41 -0400 MIME-Version: 1.0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Priority: 3 X-MSMail-Priority: Normal Errors-To: vig4csftncl@brasilmail.com.br X-Mailer: Microsoft Outlook Express 5.50.4133.2400 Message-ID: X-OriginalArrivalTime: 28 Sep 2001 01:02:11.0262 (UTC) FILETIME=[3427A5E0:01C147B9] Content-Transfer-Encoding: quoted-printable


    It only takes 5-10 MINUTES per day!

    = In a recent survey, 67% of women said that they are unhappy with thei= r lover's penis size.
     

    This is not a magic cure to make your penis grow, these are proven med= ical techniques that you can do RIGHT NOW which we've been studying and= perfecting since 1994.

    Do you want a bigger penis?
    Do you want to be hard as a rock all the time?
    Do you want to pleasure your partner every time?

    These methods are proven, effective, natural, and safe. You will learn guaranteed methods = of increasing penis size that you can do right NOW in the privacy of your = own home. Also many Tips and useful information. Click Here and= check it out. 
    a

    Guaranteed results!! Thousands of men have tried our methods with great success!
    a

    MONEY BACK GUARANTEE! 
    = NOTHING TO LOSE AND INCHES TO GAIN!
    a

    Women Get This For Your Boyf= riend/Husband
    It     REALLY WORKS















    NOTE:  This email was sent to you because your email is part of a targeted = opt-in list.  If you do not wish to receive further mailings, please c= lick below and enter your email at the bottom of the page.  You may = then rest-assured that you will never receive another email from us again=   UNSU= BSCRIBE ME PLEASE #022= 481



    = = From nfs4-wg-request@sunroof.eng.sun.com Sat Sep 29 02:15:34 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA14476 for ; Sat, 29 Sep 2001 02:15:33 -0400 (EDT) Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id AAA19004; Sat, 29 Sep 2001 00:15:23 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id XAA04088; Fri, 28 Sep 2001 23:14:58 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.0+Sun/8.12.0) with ESMTP id f8T6Em7B028623 for ; Fri, 28 Sep 2001 23:14:48 -0700 (PDT) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id XAA05347 for ; Fri, 28 Sep 2001 23:14:51 -0700 (PDT) From: hv@dinos.ch Received: from gdcic.gdjsdomain ([61.140.73.164]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id XAA18646 for ; Fri, 28 Sep 2001 23:14:49 -0700 (PDT) Date: Fri, 28 Sep 2001 23:14:49 -0700 (PDT) Message-Id: <200109290614.XAA18646@saturn.sun.com> Received: from h809 (PPPa48-ResaleFtLauderdaleB1-5R7024.dialinx.net [4.4.49.237]) by gdcic.gdjsdomain with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id TQQLL48C; Sat, 29 Sep 2001 12:57:25 +0800 To: hv@dinos.ch Subject: REVERSE the AGING PROCESS 10-20 Years! HAVE YOU HEARD OF HUMAN GROWTH HORMONE (HGH)??? Released by your own pituitary gland, HGH starts declining in your 20s, even more in your 30s and 40s, eventually resulting in the shrinkage of major organs-plus all other symptoms related to old age. THIS CAN NOW BE REVERSED!!! IN THOUSANDS OF CLINICAL STUDIES, HGH HAS BEEN SHOWN TO ACCOMPLISH THE FOLLOWING: * Reduce Body Fat Without Dieting * Build Lean Muscle WITHOUT EXERCISE! * Enhance Sexual Performance * Remove Wrinkles and Cellulite * Lower Blood Pressure and improve Cholesterol Profile * Improve Sleep, Vision and Memory * Restore Hair Color and Growth * Strengthen the Immune System * Increase Energy and Cardiac Output * Turn back your body's Biological Time Clock 10-20 years in 6 months of usage !!! You don't have to spend thousands of dollars on shots. You don't have to spend the $139.00 per bottle that HGH is selling for at some Clinics in the United States. For the next 30 Days, you can obtain a complete one-month supply of our HGH releaser for our special "New Customers" price of just $69.95 plus $6.00 shipping and handling. To ensure a constant supply and to SAVE EVEN MORE, you can order with confidence 3 bottles of HGH and GET 1 FREE - that's just $209.85 for 4 bottles, plus $6.00 shipping and handling. You SAVE $69.95! ORDER TODAY! Payment Methods You may mail Checks, MasterCard, Visa, & American Express payments or money Orders. Step 1: Place a check by your desired quanity. ______ 1 Bottle of HGH $69.95 ______ 2 Bottles of HGH $131.90 ($65.95 a bottle) ______ 4 Bottles of HGH (Buy 3 get 1 FREE. SAVE $69.95) $209.85 Please add $6 shipping and handling for any size order. [ Total cost including shipping & handling, 1 bottle =$75.95, 2 bottles=$137.90, 4 bottles=$215.85 ] International Orders Please add $35.00 for shipping. Credit Cards and International Money Orders only. Step 2: Place a check by your desired payment method and complete fields if necessary. _____Check _____Money Order _____American Express Account Number______________________ Exp____/____ _____Visa Account Number______________________ Exp____/____ _____MasterCard Account Number______________________ Exp____/____ Please make your check or money order payable to "LSN". Step 3: Please complete and print the following fields clearly. Name ___________________________________________________ Address _________________________________________________ City ____________________________________________________ State ___________________________________________________ Zip _____________________________________________________ E-mail __________________________________________________ Signature _________________________________________________ [required for check and credit card orders] Mail to: LSN 273 S. State Rd. 7 #193 Margate, FL 33068-5727 ______________________________________________________ This is a one time mailing: Removal is automatic and no further contact is necessary. Please Note: HGH is not intended to diagnose, treat, cure or prevent any disease. The FDA has not evaluated these statements. From nfs4-wg-request@sunroof.eng.sun.com Sat Sep 29 03:36:05 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA18012 for ; Sat, 29 Sep 2001 03:36:05 -0400 (EDT) Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id BAA03955; Sat, 29 Sep 2001 01:35:56 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id AAA08171; Sat, 29 Sep 2001 00:34:30 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.0+Sun/8.12.0) with ESMTP id f8T7Xw7B028670 for ; Sat, 29 Sep 2001 00:33:58 -0700 (PDT) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id AAA19331 for ; Sat, 29 Sep 2001 00:34:02 -0700 (PDT) From: totopten347@yahoo.com Received: from budvar.com.pl (pb1.sieradz.sdi.tpnet.pl [213.76.197.1]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id AAA01769 for ; Sat, 29 Sep 2001 00:33:47 -0700 (PDT) Received: from sdn-ar-002riprovP330.dialsprint.net_[168.191.126.236] (sdn-ar-002riprovP330.dialsprint.net [168.191.126.236]) by budvar.com.pl (8.9.3/8.9.3) with SMTP id JAA29827; Sat, 29 Sep 2001 09:38:55 +0200 Received: from BMS-243[212.187.02.211]wx-y_jl6-3 by sdn-ar-002riprovP330.dialsprint.net with ESMTP; Sat, 29 Sep 2001 03:37:29 -0400 Message-ID: <000060024136$00007acd$00006fb2@BMS-243[212.187.02.211]wx-y_jl6-3> To: Subject: Drive Your Web Counter Ballistic!!! 28594 Date: Sat, 29 Sep 2001 03:37:26 -0400 MIME-Version: 1.0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Priority: 1 X-MSMail-Priority: High Reply-To: life_quotes@uole.com Content-Transfer-Encoding: quoted-printable Drive Your Web Counter Ballistic with This

    3D"title.gif

    Drive your Web counter Ballis= tic!

    Learn the secrets of the TOP SEARCH ENGINIES, such as YAHOO= !, GOOGLE, = EXCITE, LYCOS and HOTBOT, and add 2,350 hits a day (or= more) to your site!

    Click Here For More Infomation!

     

    To unsubscribe reply with = the word "Unsubscribe" in Subject of email.
    From nfs4-wg-request@sunroof.eng.sun.com Sat Sep 29 09:06:59 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA20683 for ; Sat, 29 Sep 2001 09:06:58 -0400 (EDT) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA00378; Sat, 29 Sep 2001 07:06:49 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id GAA26802; Sat, 29 Sep 2001 06:06:42 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.0+Sun/8.12.0) with ESMTP id f8TD6N7B028937; Sat, 29 Sep 2001 06:06:23 -0700 (PDT) Received: from venus.sun.com (venus.EBay.Sun.COM [129.150.69.5]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id GAA23418; Sat, 29 Sep 2001 06:06:25 -0700 (PDT) From: cfkvv6wok5cj9@hotmail.com Received: from corp-server.sahara.com.sa ([212.76.68.21]) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id GAA10849; Sat, 29 Sep 2001 06:06:21 -0700 (PDT) Received: from GSISRV01.GSI.COM.SA (GSISRV01 [212.76.72.253]) by corp-server.sahara.com.sa with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id T6G61MHM; Sat, 29 Sep 2001 16:04:32 +0300 Received: from 63.232.117.21 ([63.232.117.21]) by GSISRV01.GSI.COM.SA with Microsoft SMTPSVC(5.0.2195.1600); Sat, 29 Sep 2001 16:02:40 +0300 To: Subject: Life Insurance up to 75% Off. Get a FREE Quote Now! Date: Sat, 29 Sep 2001 21:50:48 -0400 MIME-Version: 1.0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Priority: 3 X-MSMail-Priority: Normal Errors-To: dfmxjjzd8@zipmail.com.br X-Mailer: Microsoft Outlook Express 5.50.4133.2400 Message-ID: X-OriginalArrivalTime: 29 Sep 2001 13:02:42.0078 (UTC) FILETIME=[06246BE0:01C148E7] Content-Transfer-Encoding: quoted-printable Save up to 75% on term life insurance!

    Save up to 75% on Term Life Insurance
    Get FREE quotes inst= antly from top insurance companies

    Best Life Insurance, Lowest Cost!
    Compare y= our rates in 4 easy steps:
    1. get your FREE instant quotes
    2. compare the lowest prices
    3. select the company of your choice
    4. apply online

     

    COMPARE YOUR CURRENT COVERAGE=
    to these sample 10-y= ear level term monthly premiums
    (20 year, 30 year and smoker rates also available)

      $250,000 $500,000 $1,000,000
    Age Male Female Male Female Male Female
    30 $12 $11 $19 $15 $31 $27
    40 $15 $13 $26 $21 $38 $37
    50 $32 $24 $59 $43 $107 $78
    60 $75 $46 $134 $87 $259 $161


    You'll have 15 quotes from the nation's top insurance companies = in less than 1 minute!
    Get a FREE quote now
    From nfs4-wg-request@sunroof.eng.sun.com Sat Sep 29 15:39:23 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA25321 for ; Sat, 29 Sep 2001 15:39:22 -0400 (EDT) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA09398; Sat, 29 Sep 2001 13:39:13 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA18613; Sat, 29 Sep 2001 12:39:06 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.0+Sun/8.12.0) with ESMTP id f8TJcg7B029302; Sat, 29 Sep 2001 12:38:42 -0700 (PDT) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA16598; Sat, 29 Sep 2001 12:38:45 -0700 (PDT) Received: from rs01.singnet.com.sg (rs01.singnet.com.sg [165.21.101.91]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA15045; Sat, 29 Sep 2001 12:38:43 -0700 (PDT) Received: from host (06-032.024.popsite.net [66.19.1.32]) by rs01.singnet.com.sg (8.11.3/8.11.3) with ESMTP id f8TIr3V21291; Sun, 30 Sep 2001 02:53:05 +0800 Message-Id: <200109291853.f8TIr3V21291@rs01.singnet.com.sg> From: "Brad Edwards" Subject: They will Spend More #31F4 To: niere@rs01.singnet.com.sg X-Mailer: Microsoft Outlook Express 4.72.1712.3 X-MimeOLE: Produced By Microsoft MimeOLE VÐßD.1712.3 Mime-Version: 1.0 Date: Sat, 29 Sep 2001 12:42:23 -0500 Content-Type: multipart/mixed; boundary="----=_NextPart_000_007F_01BDF6C7.FABAC1B0" Content-Transfer-Encoding: 7bit This is a MIME Message ------=_NextPart_000_007F_01BDF6C7.FABAC1B0 Content-Type: multipart/alternative; boundary="----=_NextPart_001_0080_01BDF6C7.FABAC1B0" ------=_NextPart_001_0080_01BDF6C7.FABAC1B0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable ***** This is an HTML Message ! ***** ------=_NextPart_001_0080_01BDF6C7.FABAC1B0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable FREE Computer With Merchant Account Setup

    COMPLETE CREDIT CARD PROCESSING SYSTEMS FOR YOUR BUSINESS=2E INTERNE= T - HOME BASED - MAIL ORDER - PHONE ORDER

    Do you accept credit cards? Your competition does!

     

    Everyone Approved - Credit Problems OK!
    Approval in less than 24 hours!
    Increase your sales by 300%
    Start Accepting Credit Cards on your website!
    Free Information, No Risk, 100% confidential=2E
    Your name and information will not be sold to thrid parties!
    Home Businesses OK! Phone/Mail Order OK!
    No Application Fee, No Setup Fee!
    Close More Impulse Sales!

    Everyone Approved!

    Good Credit or Bad!  To= apply today, please fill out the express form below=2E It contains all the information we need to get your account approved=2E For a= rea's that do not apply to you please put "n/a" in the box=2E

    Upon receipt, we'll fax you with all of the all Bank Card Application documents necessary to establish your Merchant Account=2E Once returned we= can have your account approved within 24 hours=2E
     

    Service Industry Standard

    US
    Site Inspection $50 - $75 FREE
    Shipping $50 - $75 FREE
    Warranty $10 Per Month= FREE
    Sales Receipts $10 - $50&nbs= p; FREE
    Fraud Screening

    $=2E50 - $1=2E00
    Per Transaction

    		 FREE
    Amex Set Up $50 - $75 FREE
    24 Hour Help Line $10 Month FREE
    Security Bond $5000- $10,00= 0
    Or More    		 NONE

    This is a No Obligation Qualification Form and is your first step to accepting credit cards=2E By filling out this form you will= "not enter" in to any obligations o= r contracts with us=2E We will use it to determine the best p= rogram to offer you based on the information you provide=2E You will be c= ontacted by one of our representatives within 1-2 business days to go over = the rest of your account set up=2E

    <= font color=3D"#cc0000">Note:  All Information Provided To Us Will Remain= 100% Confidential !! 

    Apply Free With No Risk!

    Pleas= e fill out the express application form completely=2E
    Incomplete information m= ay prevent us from properly processing your application=2E
    Your Full Emai= l Address:
    be sure to use your full address (i= =2Ee=2E user@domain=2Ecom)
    Your Name:
    Business Name:=
    Business Phone= Number:
    Home Phone Num= ber:
    Type of Busine= ss:
    Retail Business
    Mail Order Business
    Internet Based Busines= s
    Personal Credi= t Rating:
    Excellent
    Good
    Fair
    Poor
    How Soon Would= You Like a Merchant Account?


    Your info= rmation is confidential, it will not be sold or used for any other purpose,= and you are under no obligation=2E Your information will be used solely for the purpose of evaluating= your business or website for a merchant account so that you may begin acce= pting credit card payments=2E


    List Removal/OPT-OUT Option
    Click Herem ------=_NextPart_001_0080_01BDF6C7.FABAC1B0-- ------=_NextPart_000_007F_01BDF6C7.FABAC1B0-- From nfs4-wg-request@sunroof.eng.sun.com Sun Sep 30 01:59:27 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA05919 for ; Sun, 30 Sep 2001 01:59:27 -0400 (EDT) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id WAA23655; Sat, 29 Sep 2001 22:59:26 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id WAA00863; Sat, 29 Sep 2001 22:58:12 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f8U5w1ML029795 for ; Sat, 29 Sep 2001 22:58:01 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id WAA14366 for ; Sat, 29 Sep 2001 22:58:03 -0700 (PDT) Received: from fog ([211.116.22.13]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with SMTP id XAA26261 for ; Sat, 29 Sep 2001 23:59:02 -0600 (MDT) Message-Id: <200109300559.XAA26261@lukla.Sun.COM> From: =?ks_c_5601-1987?B?xvex173DvbrF2w==?= To: nfsv4-wg@sunroof.eng.sun.com Subject: =?ks_c_5601-1987?B?W0ZvZ10gsc2758DHIMioxuTAzMH2uKYgMTAwuLi47b+hsNQgvsu3wbXluLO0z7TZLg==?= Date: Sun, 30 Sep 2001 14:57:40 +0900 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0147_01C0F30A.93A57C00" X-Priority: 3 This is a multi-part message in MIME format. ------=_NextPart_000_0147_01C0F30A.93A57C00 Content-Type: text/plain; charset="ks_c_5601-1987" Content-Transfer-Encoding: base64 Ojo6IEludHJvZHVjZSBvZiBGT0cgU1lTVEVNIDo6OiAgICAgICAgICAgICAgICAgICAgICAg IKHhICCh4SANCiAgICAgICAgICAgICAgICAgICAgICAgICAgIA0KIKLAIMClILvnwMzGriwg uLi16bHiuLggx8+46SC1yLTZsO0gu/2wosfPvcq0z7HuPw0KIMfRufi4uCC+srDtILn2uK69 xyCwx7Chv+Q/IDG17sC7IMfPseK6uLTZtMIgMbXuwLsgwfbFsLHisKEgtPUgvu63xrTZtMIg uLvAzCDA1r3AtM+02S4NCiC4uLXpuOkgxevH0bTZLi6+xrTVtM+02S4hDQogu+e+98iutOu4 piDF68fYILT1IMS/wfogu+fAzMauuKYgwKfH0SCx4rndwLi3ziDA2773x9i+3yC1x7TCsMUg vsa9w8HSPw0KIA0KIKLAILGksO20wiDA+sD9t84gtcezqr/kPw0KIL73uau1tSC52bvbtaUg sO2wtLD8uK60wiC0qbChx8+zqr/kPw0KILrxvc6w1Li4ILi4tem46SDBwcC6ILvnwMzGrrCh ILOqv8K02bDtILv9sKLHz73KtM+x7j8NCiANCiCiwCDHz7Dtvc3AuiCwzcC6ILi5sO0guvG/ 68C6ILrOwbfHz7DtLi4uLiANCiCwxsGkx8/B9iC4try8v+QhIMD6t8XH0SCwobDdwLi3ziDD 1rDtwMcgu+fAzMauuKYgsbjD4MfPsNq9wLTPtNkuDQogxvex17+hvK20wiDApbvnwMzGrrim ILCzud/H2CDB1rTCILDNwLi3ziCzobOqwfYgvsq9wLTPtNkuDQogseLIub+hvK0guLbEycbD LCCx17iusO0gsO2wtLD8uK6x7sH2ISEhDQogxvex17+hvK20wiC48LXnILDNwLsgw6XA08H9 tM+02S4NCiANCiA6Ojo6OiDC/MG2sLO537vnwMzGriCi0SDGxLzSs6qx4iAgKHd3dy5mYXNv bmFraS5jb20pIA0KICAgICAgICAgICAgICCh4SAgoeEgICAgICAgICAgDQogwK+89sDHILvn wMzGrrimILCzud/H0SC9x7fCwLsgsKHB+CDG97HXvcO9usXbv6EguMOw3Lq4vLy/5CEhICAg w9aw7cDHILzux8649MC7ILCusNQgtckgsM3A1LTPtNkuDQogsKGw1L+hIMDOxde4rr7uuLgg x9G02bDtILzVtNTAzCC/wLOqv+Q/ICAgvsa01bTPtNkuILzVtNTAuyC60revvt8gv8DB9r/k Lg0KILzVtNS4uCC/wLjpIMD6wP23ziDGyLius6q/5D8NCiDDtsD6x9EgvK268b26v80gv8+6 rsfRILDtsLSw/LiusKEgvvjAzLTCIMD9tOu3ziC8urD4x9IgvPawoSC++L3AtM+02S4NCiAN CiDG97HXv6G8rbTCILzux8649MC7ILCzud/H2CDB1rTCILDNwLi3ziCzobOqwfYgvsq9wLTP tNkuDQogseLIub+hvK0guLbEycbDLCCx17iusO0gsO2wtLD8uK6x7sH2ISEhDQogxvex17+h vK20wiC48LXnILDNwLsgw6XA08H9tM+02S4NCiANCiA6Ojo6OiDC/MG2sLO537vnwMzGriA6 ILG5uc7Eq7XlICC87sfOuPQsILvvvLq49CAgtOXExCAgICAgICAgICAgICAgoeEgIKHhICAg ICAgICAgIA0KIMPrvve758DMxq4sILOytem1tSC02SDA1rTCtaUuLi4gvu62u7DUIMfPwfY/ IMD6yPEgxvex17+hILjDsNzB1ry8v+QuILjFsObD6773u+fAzMauuKYgwabA28fRILHivPq3 wrD6ILDmx+jAuyC52cXBwLi3ziCxzbvnwMcgIA0KIMPrvve758DMxq64piDDpcDTwf20z7TZ Lg0KIA0KIDo6Ojo6IML8wbaws7nfu+fAzMauIDoguMWw5sPrvve758DMxq4gICh3d3cubWtz Y291dC5jb20pICAgICAgICAgICAgIKHhICCh4SAgICAgICAgDQogRk9HtMIuLi4nRmlyZSBv ZiBHZW5pZXMntvO0wiC25sC4t84gwMy0wiDAzsXNs90gsPiwo8DHIMPWsO2woSC1x7DatNm0 wiDAx7nMuKYgs7vG98fPsO0gwNa9wLTPtNkuIMD6yPEgot/G97HXvcO9usXbwLogILG5s7sg w9aw7cDHIA0KILHivPrAuyC52cXBwLi3ziDH0SDApbvnwMzGriwgvO7Hzrj0ILnXIMPrvve7 58DMxq4gsbjD4CDA/LmuIMClv6HAzMGvvcPA1LTPtNkuDQogsc2758DHILnfwPzAuyDA+sjx IMb3sde/zSDH1LKyIMfSILz2IMDWwLi46SC09SDBwbDavcC0z7TZLiC80sHfx9EgvcOwoyCz u8HWvMW8rSCwqLvnx9W0z7TZLiAgICAgIA0KILHNx8/AxyDAzLjewM8gwda80rTCIMD8vcPI uCC51yCw/LfDIMClu+fAzMauILnXILDUvcPGxyC17r+hvK0gvPbB/cfRILDNwLi3ziDAzLje wM8gwda80iAgv9zAxyCws8DOwaS6uLTCILChwfaw7SDA1sH2IL7KvcC0z7TZLg0KIMDMIGUt bWFpbMC6ILnfvcXA/L/rwNS0z7TZLiC53rHiuKYgv/jHz8H2IL7KwLi9w7jpICe89r3FsMW6 zie4piAgtK23ryDB1r3KvcO/wC4NCiANCiCiuSDA/MitufjIoyA6IDAyKTU2My04MjgwICjT 2ykNCiCiuSBFo61NQUlMIDogc2t5MDA3QGZvZy5jby5rcg0KIKK5IMioxuTAzMH2IDogot/G 97HXvcO9usXbICAoaHR0cDovL3d3dy5mb2cuY28ua3IpDQogICAgICAgICAgICAgICAgICAg IA0KIENvcHlyaWdodChjKSAyMDAxIEZPRyBTWVNURU0gQWxsIHJpZ2h0cyByZXNlcnZlZC4g IA0KICAgICAgICA= ------=_NextPart_000_0147_01C0F30A.93A57C00 Content-Type: text/html; charset="ks_c_5601-1987" Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjx0aXRsZT46OjogSW50cm9kdWNlIG9mIEZPRyBTWVNURU0gOjo6 IDwvdGl0bGU+DQo8bWV0YSBodHRwLWVxdWl2PSJDb250ZW50LVR5cGUiIGNvbnRlbnQ9InRl eHQvaHRtbDsgY2hhcnNldD1ldWMta3IiPg0KPGxpbmsgcmVsPSJzdHlsZXNoZWV0IiB0eXBl PSJ0ZXh0L2NzcyIgaHJlZj0iaHR0cDovL3d3dy5mb2cuY28ua3IvZm9nLmNzcyI+DQo8L2hl YWQ+DQoNCjxib2R5IGJhY2tncm91bmQ9Imh0dHA6Ly93d3cuZm9nLmNvLmtyL2ltYWdlcy90 ZW1wL2JhLmdpZiIgdG9wbWFyZ2luPSIwIiBsZWZ0bWFyZ2luPSIwIj4NCjx0YWJsZSB3aWR0 aD0iODAwIiBib3JkZXI9IjAiIGNlbGxzcGFjaW5nPSIwIiBjZWxscGFkZGluZz0iMCIgYWxp Z249ImNlbnRlciIgYmdjb2xvcj0iRkZGRkZGIj4NCiAgPHRyID4gDQogICAgPHRkIGNvbHNw YW49IjQiIGhlaWdodD0iMjAiIGJhY2tncm91bmQ9Imh0dHA6Ly93d3cuZm9nLmNvLmtyL2lt YWdlcy90ZW1wL2JhLmdpZiI+Jm5ic3A7PC90ZD4NCiAgPC90cj4NCiAgPHRyPiANCiAgICA8 dGQgd2lkdGg9IjYwIiBoZWlnaHQ9IjIwIj4mbmJzcDs8L3RkPg0KICAgIDx0ZCB3aWR0aD0i NzQwIj4mbmJzcDs8L3RkPg0KICA8L3RyPg0KICA8dHI+IA0KICAgIDx0ZCBjb2xzcGFuPSIy Ij48YSBocmVmPSJodHRwOi8vd3d3LmZvZy5jby5rciIgdGFyZ2V0PSJfYmxhbmsiPjxpbWcg c3JjPSJodHRwOi8vd3d3LmZvZy5jby5rci9pbWFnZXMvdGVtcC9sb2dvLmdpZiIgd2lkdGg9 IjE2MCIgaGVpZ2h0PSIzMSIgYm9yZGVyPSIwIiBhbHQ9IkZPRyBzeXN0ZW0iPjwvYT4gDQog ICAgPC90ZD4NCiAgPC90cj4NCiAgPHRyPiANCiAgICA8dGQgY29sc3Bhbj0iMiIgYWxpZ249 ImNlbnRlciI+PGltZyBzcmM9Imh0dHA6Ly93d3cuZm9nLmNvLmtyL2ltYWdlcy90ZW1wL2lt Zy5naWYiIHdpZHRoPSI4MDAiIGhlaWdodD0iODUiPjwvdGQ+DQogIDwvdHI+DQogIDx0ciBi Z2NvbG9yPSJFN0U3RTYiPiANCiAgICA8dGQgY29sc3Bhbj0iMiIgaGVpZ2h0PSIyMCI+Jm5i c3A7PC90ZD4NCiAgPC90cj4NCiAgPHRyPiANCiAgICA8dGQgY29sc3Bhbj0iMiIgaGVpZ2h0 PSIxMTAiIGJnY29sb3I9IkU3RTdFNiIgPjxiPjxmb250IGNvbG9yPSIjMDA2NkNDIiBzaXpl PSIxIj48aW1nIHNyYz0iaHR0cDovL3d3dy5mb2cuY28ua3IvaW1hZ2VzL3RlbXAvaWNvbi5n aWYiIHdpZHRoPSI1MyIgaGVpZ2h0PSIyNCIgYWxpZ249ImFic21pZGRsZSI+oeEgDQogICAg ICCh4SA8L2ZvbnQ+PC9iPjxpbWcgc3JjPSJodHRwOi8vd3d3LmZvZy5jby5rci9pbWFnZXMv dGVtcC90aXRsZTEuZ2lmIiB3aWR0aD0iMzExIiBoZWlnaHQ9IjMwIiBhbGlnbj0iYWJzbWlk ZGxlIj48YnI+DQogICAgICAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgPGltZyBzcmM9Imh0dHA6Ly93d3cu Zm9nLmNvLmtyL2ltYWdlcy90ZW1wL3RpdGxlMS0xLmdpZiIgd2lkdGg9IjUwNSIgaGVpZ2h0 PSI5NyI+IA0KICAgIDwvdGQ+DQogIDwvdHI+DQogIDx0cj4gDQogICAgPHRkPiZuYnNwOzwv dGQ+DQogICAgPHRkPiA8YnI+DQogICAgICA8Zm9udCBjb2xvcj0iI0ZGNTQwMCI+osAgwKUg u+fAzMauLCC4uLXpseK4uCDHz7jpILXItNmw7SC7/bCix8+9yrTPse4/PC9mb250Pjxicj4N CiAgICAgIMfRufi4uCC+srDtILn2uK69xyCwx7Chv+Q/IDG17sC7IMfPseK6uLTZtMIgMbXu wLsgwfbFsLHisKEgtPUgvu63xrTZtMIguLvAzCDA1r3AtM+02S48YnI+DQogICAgICC4uLXp uOkgxevH0bTZLi6+xrTVtM+02S4hPGJyPg0KICAgICAgu+e+98iutOu4piDF68fYILT1IMS/ wfogu+fAzMauuKYgwKfH0SCx4rndwLi3ziDA2773x9i+3yC1x7TCsMUgvsa9w8HSPzxicj4N CiAgICAgIDxicj4NCiAgICAgIDxmb250IGNvbG9yPSIjRkY1NDAwIj6iwCCxpLDttMIgwPrA /bfOILXHs6q/5D88L2ZvbnQ+PGJyPg0KICAgICAgvve5q7W1ILnZu9u1pSCw7bC0sPy4rrTC ILSpsKHHz7Oqv+Q/PGJyPg0KICAgICAguvG9zrDUuLgguLi16bjpIMHBwLogu+fAzMausKEg s6q/wrTZsO0gu/2wosfPvcq0z7HuPzxicj4NCiAgICAgIDxicj4NCiAgICAgIDxmb250IGNv bG9yPSIjRkY1NDAwIj6iwCDHz7Dtvc3AuiCwzcC6ILi5sO0guvG/68C6ILrOwbfHz7DtLi4u LiA8L2ZvbnQ+PGJyPg0KICAgICAgsMbBpMfPwfYguLa8vL/kISDA+rfFx9EgsKGw3cC4t84g w9aw7cDHILvnwMzGrrimILG4w+DHz7DavcC0z7TZLjxicj4NCiAgICAgIMb3sde/obyttMIg wKW758DMxq64piCws7nfx9ggwda0wiCwzcC4t84gs6GzqsH2IL7KvcC0z7TZLjxicj4NCiAg ICAgILHiyLm/obytILi2xMnGwywgsde4rrDtILDtsLSw/Liuse7B9iEhITxicj4NCiAgICAg IMb3sde/obyttMIguPC15yCwzcC7IMOlwNPB/bTPtNkuPGJyPg0KICAgICAgPGJyPg0KICAg ICAgPGZvbnQgY29sb3I9IiNENjg2MzUiPjxiPjo6Ojo6IML8wbaws7nfu+fAzMauIDwvYj6i 0SA8YSBocmVmPSJodHRwOi8vd3d3LmZhc29uYWtpLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPjxm b250IGNvbG9yPSIjQzQ2MzAyIj7GxLzSs6qx4iANCiAgICAgICh3d3cuZmFzb25ha2kuY29t KSA8L2ZvbnQ+PC9hPjwvZm9udD48YnI+DQogICAgPC90ZD4NCiAgPC90cj4NCiAgPHRyPiAN CiAgICA8dGQ+Jm5ic3A7PC90ZD4NCiAgICA8dGQ+Jm5ic3A7IDwvdGQ+DQogIDwvdHI+DQog IDx0cj4gDQogICAgPHRkIGJnY29sb3I9IiNBRENGRUUiIGNvbHNwYW49IjIiIGhlaWdodD0i MSI+PC90ZD4NCiAgPC90cj4NCiAgPHRyPiANCiAgICA8dGQgY29sc3Bhbj0iMiIgYmdjb2xv cj0iI0U2RjNGRiIgPjxiPjxmb250IGNvbG9yPSIjMDA2NkNDIj48Zm9udCBzaXplPSIxIj48 aW1nIHNyYz0iaHR0cDovL3d3dy5mb2cuY28ua3IvaW1hZ2VzL3RlbXAvaWNvbi5naWYiIHdp ZHRoPSI1MyIgaGVpZ2h0PSIyNCIgYWxpZ249ImFic21pZGRsZSI+oeEgDQogICAgICCh4Twv Zm9udD4gPGltZyBzcmM9Imh0dHA6Ly93d3cuZm9nLmNvLmtyL2ltYWdlcy90ZW1wL3RpdGxl Mi5naWYiIHdpZHRoPSIyOTgiIGhlaWdodD0iMzAiIGFsaWduPSJhYnNtaWRkbGUiPjwvZm9u dD48L2I+IA0KICAgIDwvdGQ+DQogIDwvdHI+DQogIDx0cj4gDQogICAgPHRkIGJnY29sb3I9 IiNBRENGRUUiIGNvbHNwYW49IjIiIGhlaWdodD0iMSI+PC90ZD4NCiAgPC90cj4NCiAgPHRy PiANCiAgICA8dGQ+Jm5ic3A7PC90ZD4NCiAgICA8dGQ+PGJyPg0KICAgICAgwK+89sDHILvn wMzGrrimILCzud/H0SC9x7fCwLsgsKHB+CDG97HXvcO9usXbv6EguMOw3Lq4vLy/5CEhICZu YnNwOyDD1rDtwMcgvO7Hzrj0wLsgsK6w1CC1ySCwzcDUtM+02S48YnI+DQogICAgICCwobDU v6EgwM7F17iuvu64uCDH0bTZsO0gvNW01MDMIL/As6q/5D8gJm5ic3A7IL7GtNW0z7TZLiC8 1bTUwLsgutK3r77fIL/Awfa/5C48YnI+DQogICAgICC81bTUuLggv8C46SDA+sD9t84gxsi4 rrOqv+Q/PGJyPg0KICAgICAgw7bA+sfRILytuvG9ur/NIL/Puq7H0SCw7bC0sPy4rrChIL74 wMy0wiDA/bTrt84gvLqw+MfSILz2sKEgvvi9wLTPtNkuPGJyPg0KICAgICAgPGJyPg0KICAg ICAgxvex17+hvK20wiC87sfOuPTAuyCws7nfx9ggwda0wiCwzcC4t84gs6GzqsH2IL7KvcC0 z7TZLjxicj4NCiAgICAgIDxmb250IGNvbG9yPSIjRkY1NDAwIj6x4si5v6G8rSC4tsTJxsMs ILHXuK6w7SCw7bC0sPy4rrHuwfYhISE8YnI+DQogICAgICA8Yj7G97HXv6G8rbTCILjwtecg sM3AuyDDpcDTwf20z7TZLjwvYj48L2ZvbnQ+PGJyPg0KICAgICAgPGJyPg0KICAgICAgPGZv bnQgY29sb3I9IiNENjg2MzUiPjxiPjo6Ojo6IML8wbaws7nfu+fAzMauIDogPC9iPjxhIGhy ZWY9Imh0dHA6Ly93d3cucGFzc2NpdHkuY28ua3IiIHRhcmdldD0iX2JsYW5rIj48Zm9udCBj b2xvcj0iI0M0NjMwMiI+sbm5zsSrteUgDQogICAgICC87sfOuPQ8L2ZvbnQ+PC9hPiwgPGEg aHJlZj0iaHR0cDovL3d3dy5zYW1zdW5nbWFsbC5jby5rciIgdGFyZ2V0PSJfYmxhbmsiPjxm b250IGNvbG9yPSIjQzQ2MzAyIj6777y6uPQgDQogICAgICC05cTEPC9mb250PjwvYT48L2Zv bnQ+IDwvdGQ+DQogIDwvdHI+DQogIDx0cj4gDQogICAgPHRkPiZuYnNwOzwvdGQ+DQogICAg PHRkPiZuYnNwOyA8L3RkPg0KICA8L3RyPg0KICA8dHI+IA0KICAgIDx0ZCBiZ2NvbG9yPSIj QURDRkVFIiBjb2xzcGFuPSIyIiBoZWlnaHQ9IjEiPjwvdGQ+DQogIDwvdHI+DQogIDx0cj4g DQogICAgPHRkIGNvbHNwYW49IjIiIGJnY29sb3I9IiNFNkYzRkYiID48Zm9udCBjb2xvcj0i IzAwNjZDQyI+PGZvbnQgc2l6ZT0iMSI+PGI+PGZvbnQgY29sb3I9IiMwMDY2Q0MiPjxmb250 IHNpemU9IjEiPjxpbWcgc3JjPSJodHRwOi8vd3d3LmZvZy5jby5rci9pbWFnZXMvdGVtcC9p Y29uLmdpZiIgd2lkdGg9IjUzIiBoZWlnaHQ9IjI0IiBhbGlnbj0iYWJzbWlkZGxlIj48L2Zv bnQ+PC9mb250PjwvYj6h4SANCiAgICAgIKHhPC9mb250PiA8L2ZvbnQ+PGltZyBzcmM9Imh0 dHA6Ly93d3cuZm9nLmNvLmtyL2ltYWdlcy90ZW1wL3RpdGxlMy5naWYiIHdpZHRoPSIyNjAi IGhlaWdodD0iMzAiIGFsaWduPSJhYnNtaWRkbGUiPiANCiAgICA8L3RkPg0KICA8L3RyPg0K ICA8dHI+IA0KICAgIDx0ZCBiZ2NvbG9yPSIjQURDRkVFIiBjb2xzcGFuPSIyIiBoZWlnaHQ9 IjEiPjwvdGQ+DQogIDwvdHI+DQogIDx0cj4gDQogICAgPHRkPiZuYnNwOzwvdGQ+DQogICAg PHRkPiA8YnI+DQogICAgICDD6773u+fAzMauLCCzsrXptbUgtNkgwNa0wrWlLi4uIL7utruw 1CDHz8H2PyDA+sjxIMb3sde/oSC4w7Dcwda8vL/kLiC4xbDmw+u+97vnwMzGrrimIMGmwNvH 0SCx4rz6t8Kw+iCw5sfowLsgudnFwcC4t84gsc2758DHIA0KICAgICAgPGJyPg0KICAgICAg w+u+97vnwMzGrrimIMOlwNPB/bTPtNkuPGJyPg0KICAgICAgPGZvbnQgY29sb3I9IiNENjg2 MzUiPjxiPjxicj4NCiAgICAgIDo6Ojo6IML8wbaws7nfu+fAzMauIDogPC9iPjxhIGhyZWY9 Imh0dHA6Ly93d3cubWtzY291dC5jb20iIHRhcmdldD0iX2JsYW5rIj48Zm9udCBjb2xvcj0i I0M0NjMwMiI+uMWw5sPrvve758DMxq4gDQogICAgICAod3d3Lm1rc2NvdXQuY29tKTwvZm9u dD48L2E+PC9mb250PiA8L3RkPg0KICA8L3RyPg0KICA8dHI+IA0KICAgIDx0ZD4mbmJzcDs8 L3RkPg0KICAgIDx0ZD48Zm9udCBjb2xvcj0iIzAwNjZDQyI+PGZvbnQgc2l6ZT0iMSI+PGI+ PGZvbnQgY29sb3I9IiMwMDY2Q0MiPjwvZm9udD48L2I+PC9mb250PjwvZm9udD4gDQogICAg PC90ZD4NCiAgPC90cj4NCiAgPHRyPiANCiAgICA8dGQgYmdjb2xvcj0iI0FEQ0ZFRSIgY29s c3Bhbj0iMiIgaGVpZ2h0PSIxIj48L3RkPg0KICA8L3RyPg0KICA8dHI+IA0KICAgIDx0ZCBj b2xzcGFuPSIyIiBiZ2NvbG9yPSIjRTZGM0ZGIiA+PGZvbnQgY29sb3I9IiMwMDY2Q0MiPjxm b250IGNvbG9yPSIjMDA2NkNDIj48Zm9udCBzaXplPSIxIj48Yj48Zm9udCBjb2xvcj0iIzAw NjZDQyI+PGZvbnQgc2l6ZT0iMSI+PGltZyBzcmM9Imh0dHA6Ly93d3cuZm9nLmNvLmtyL2lt YWdlcy90ZW1wL2ljb24uZ2lmIiB3aWR0aD0iNTMiIGhlaWdodD0iMjQiIGFsaWduPSJhYnNt aWRkbGUiPjwvZm9udD48L2ZvbnQ+PC9iPjwvZm9udD48L2ZvbnQ+PGZvbnQgc2l6ZT0iMSI+ oeEgDQogICAgICCh4TwvZm9udD48L2ZvbnQ+PGltZyBzcmM9Imh0dHA6Ly93d3cuZm9nLmNv LmtyL2ltYWdlcy90ZW1wL3RpdGxlNC5naWYiIHdpZHRoPSIxNTUiIGhlaWdodD0iMzAiIGFs aWduPSJhYnNtaWRkbGUiPjwvdGQ+DQogIDwvdHI+DQogIDx0cj4gDQogICAgPHRkIGJnY29s b3I9IiNBRENGRUUiIGNvbHNwYW49IjIiIGhlaWdodD0iMSI+PC90ZD4NCiAgPC90cj4NCiAg PHRyPiANCiAgICA8dGQ+Jm5ic3A7PC90ZD4NCiAgICA8dGQ+PGJyPg0KICAgICAgRk9HtMIu Li4nRmlyZSBvZiBHZW5pZXMntvO0wiC25sC4t84gwMy0wiDAzsXNs90gsPiwo8DHIMPWsO2w oSC1x7DatNm0wiDAx7nMuKYgs7vG98fPsO0gwNa9wLTPtNkuIMD6yPEgot/G97HXvcO9usXb wLogDQogICAgICCxubO7IMPWsO3AxyA8YnI+DQogICAgICCx4rz6wLsgudnFwcC4t84gx9Eg wKW758DMxq4sILzux8649CC51yDD6773u+fAzMauILG4w+AgwPy5riDApb+hwMzBr73DwNS0 z7TZLjxicj4NCiAgICAgILHNu+fAxyC538D8wLsgwPrI8SDG97HXv80gx9SysiDH0iC89iDA 1sC4uOkgtPUgwcGw2r3AtM+02S4gvNLB38fRIL3DsKMgs7vB1rzFvK0gsKi758fVtM+02S4g PC90ZD4NCiAgPC90cj4NCiAgPHRyPiANCiAgICA8dGQgaGVpZ2h0PSIzMCI+Jm5ic3A7PC90 ZD4NCiAgICA8dGQ+PGJyPg0KICAgICAgPGZvbnQgY29sb3I9IiMwMDY2NjYiPrHNx8/AxyDA zLjewM8gwda80rTCIMD8vcPIuCC51yCw/LfDIMClu+fAzMauILnXILDUvcPGxyC17r+hvK0g vPbB/cfRILDNwLi3ziDAzLjewM8gwda80iANCiAgICAgIL/cwMcgsLPAzsGkuri0wiCwocH2 sO0gwNbB9iC+yr3AtM+02S48YnI+DQogICAgICDAzCBlLW1haWzAuiC5373FwPy/68DUtM+0 2S4gud6x4rimIL/4x8/B9iC+ysC4vcO46SA8YSBocmVmPSJtYWlsdG86c2t5MDA3QGZvZy5j by5rciI+J7z2vcWwxbrOJzwvYT64piANCiAgICAgILStt68gwda9yr3Dv8AuPC9mb250Pjxi cj4NCiAgICAgIDxicj4NCiAgICAgIDxmb250IGNvbG9yPSIjYzIxMTExIj6iuSDA/MitufjI oyA6IDAyKTU2My04MjgwICjT2yk8YnI+DQogICAgICCiuSBFo61NQUlMIDogPGEgaHJlZj0i bWFpbHRvOmZvZ0Bmb2cuY28ua3IiPjxmb250IGNvbG9yPSIjRTA0MTQxIj5za3kwMDdAZm9n LmNvLmtyPC9mb250PjwvYT48YnI+DQogICAgICCiuSDIqMbkwMzB9iA6IDxhIGhyZWY9Imh0 dHA6Ly93d3cuZm9nLmNvLmtyIiB0YXJnZXQ9Il9ibGFuayI+PGZvbnQgY29sb3I9IiNFMDQx NDEiPqLfxvex173DvbrF2yANCiAgICAgIChodHRwOi8vd3d3LmZvZy5jby5rcik8L2ZvbnQ+ PC9hPjwvZm9udD48YnI+DQogICAgPC90ZD4NCiAgPC90cj4NCiAgPHRyPiANCiAgICA8dGQg Y29sc3Bhbj0iMiI+Jm5ic3A7PC90ZD4NCiAgPC90cj4NCiAgPHRyPiANCiAgICA8dGQ+Jm5i c3A7PC90ZD4NCiAgICA8dGQgYWxpZ249ImNlbnRlciIgaGVpZ2h0PSI2MyI+PGEgaHJlZj0i aHR0cDovL3d3dy5mb2cuY28ua3IiPjxpbWcgc3JjPSJodHRwOi8vd3d3LmZvZy5jby5rci9p bWFnZXMvMDFmb2cvaW1nX2xvZ28uZ2lmIiB3aWR0aD0iMTI1IiBoZWlnaHQ9IjgwIiBib3Jk ZXI9IjAiPjwvYT4mbmJzcDsgDQogICAgICAmbmJzcDsgPC90ZD4NCiAgPC90cj4NCiAgPHRy PiANCiAgICA8dGQgaGVpZ2h0PSIyMCI+Jm5ic3A7PC90ZD4NCiAgICA8dGQgYWxpZ249ImNl bnRlciI+PGJyPg0KICAgICAgPGZvbnQgY29sb3I9IiM5OTk5OTkiPkNvcHlyaWdodChjKSAy MDAxIEZPRyBTWVNURU0gQWxsIHJpZ2h0cyByZXNlcnZlZC4gDQogICAgICA8YnI+DQogICAg ICA8L2ZvbnQ+IDwvdGQ+DQogIDwvdHI+DQogIDx0cj4gDQogICAgPHRkIGNvbHNwYW49IjQi IGhlaWdodD0iMjAiIGJhY2tncm91bmQ9Imh0dHA6Ly93d3cuZm9nLmNvLmtyL2ltYWdlcy90 ZW1wL2JhLmdpZiI+Jm5ic3A7PC90ZD4NCiAgPC90cj4NCjwvdGFibGU+ICAgDQo8L2JvZHk+ ICAgDQo8L2h0bWw+ICAgDQoNCg== ------=_NextPart_000_0147_01C0F30A.93A57C00-- From nfs4-wg-request@sunroof.eng.sun.com Sun Sep 30 04:55:51 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA19793 for ; Sun, 30 Sep 2001 04:55:51 -0400 (EDT) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id BAA08541; Sun, 30 Sep 2001 01:55:53 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id BAA20329; Sun, 30 Sep 2001 01:55:14 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f8U8t2ML029971 for ; Sun, 30 Sep 2001 01:55:02 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id BAA23052 for ; Sun, 30 Sep 2001 01:55:04 -0700 (PDT) From: hv@dinos.ch Received: from gdcic.gdjsdomain ([61.140.73.164]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id CAA22528 for ; Sun, 30 Sep 2001 02:54:52 -0600 (MDT) Date: Sun, 30 Sep 2001 02:54:52 -0600 (MDT) Message-Id: <200109300854.CAA22528@patan.sun.com> Received: from h809 (PPPa48-ResaleFtLauderdaleB1-5R7024.dialinx.net [4.4.49.237]) by gdcic.gdjsdomain with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id TQQLL48C; Sat, 29 Sep 2001 12:57:25 +0800 To: hv@dinos.ch Subject: REVERSE the AGING PROCESS 10-20 Years! HAVE YOU HEARD OF HUMAN GROWTH HORMONE (HGH)??? Released by your own pituitary gland, HGH starts declining in your 20s, even more in your 30s and 40s, eventually resulting in the shrinkage of major organs-plus all other symptoms related to old age. THIS CAN NOW BE REVERSED!!! IN THOUSANDS OF CLINICAL STUDIES, HGH HAS BEEN SHOWN TO ACCOMPLISH THE FOLLOWING: * Reduce Body Fat Without Dieting * Build Lean Muscle WITHOUT EXERCISE! * Enhance Sexual Performance * Remove Wrinkles and Cellulite * Lower Blood Pressure and improve Cholesterol Profile * Improve Sleep, Vision and Memory * Restore Hair Color and Growth * Strengthen the Immune System * Increase Energy and Cardiac Output * Turn back your body's Biological Time Clock 10-20 years in 6 months of usage !!! You don't have to spend thousands of dollars on shots. You don't have to spend the $139.00 per bottle that HGH is selling for at some Clinics in the United States. For the next 30 Days, you can obtain a complete one-month supply of our HGH releaser for our special "New Customers" price of just $69.95 plus $6.00 shipping and handling. To ensure a constant supply and to SAVE EVEN MORE, you can order with confidence 3 bottles of HGH and GET 1 FREE - that's just $209.85 for 4 bottles, plus $6.00 shipping and handling. You SAVE $69.95! ORDER TODAY! Payment Methods You may mail Checks, MasterCard, Visa, & American Express payments or money Orders. Step 1: Place a check by your desired quanity. ______ 1 Bottle of HGH $69.95 ______ 2 Bottles of HGH $131.90 ($65.95 a bottle) ______ 4 Bottles of HGH (Buy 3 get 1 FREE. SAVE $69.95) $209.85 Please add $6 shipping and handling for any size order. [ Total cost including shipping & handling, 1 bottle =$75.95, 2 bottles=$137.90, 4 bottles=$215.85 ] International Orders Please add $35.00 for shipping. Credit Cards and International Money Orders only. Step 2: Place a check by your desired payment method and complete fields if necessary. _____Check _____Money Order _____American Express Account Number______________________ Exp____/____ _____Visa Account Number______________________ Exp____/____ _____MasterCard Account Number______________________ Exp____/____ Please make your check or money order payable to "LSN". Step 3: Please complete and print the following fields clearly. Name ___________________________________________________ Address _________________________________________________ City ____________________________________________________ State ___________________________________________________ Zip _____________________________________________________ E-mail __________________________________________________ Signature _________________________________________________ [required for check and credit card orders] Mail to: LSN 273 S. State Rd. 7 #193 Margate, FL 33068-5727 ______________________________________________________ This is a one time mailing: Removal is automatic and no further contact is necessary. Please Note: HGH is not intended to diagnose, treat, cure or prevent any disease. The FDA has not evaluated these statements. From nfs4-wg-request@sunroof.eng.sun.com Sun Sep 30 06:19:16 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA20411 for ; Sun, 30 Sep 2001 06:19:15 -0400 (EDT) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id EAA05091; Sun, 30 Sep 2001 04:19:05 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id DAA23655; Sun, 30 Sep 2001 03:18:34 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f8UAILML000068 for ; Sun, 30 Sep 2001 03:18:21 -0700 (PDT) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id DAA25668 for ; Sun, 30 Sep 2001 03:18:22 -0700 (PDT) From: hv@dinos.ch Received: from gdcic.gdjsdomain ([61.140.73.164]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id DAA13632 for ; Sun, 30 Sep 2001 03:18:21 -0700 (PDT) Date: Sun, 30 Sep 2001 03:18:21 -0700 (PDT) Message-Id: <200109301018.DAA13632@saturn.sun.com> Received: from h809 (PPPa48-ResaleFtLauderdaleB1-5R7024.dialinx.net [4.4.49.237]) by gdcic.gdjsdomain with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id TQQLL48C; Sat, 29 Sep 2001 12:57:25 +0800 To: hv@dinos.ch Subject: REVERSE the AGING PROCESS 10-20 Years! HAVE YOU HEARD OF HUMAN GROWTH HORMONE (HGH)??? Released by your own pituitary gland, HGH starts declining in your 20s, even more in your 30s and 40s, eventually resulting in the shrinkage of major organs-plus all other symptoms related to old age. THIS CAN NOW BE REVERSED!!! IN THOUSANDS OF CLINICAL STUDIES, HGH HAS BEEN SHOWN TO ACCOMPLISH THE FOLLOWING: * Reduce Body Fat Without Dieting * Build Lean Muscle WITHOUT EXERCISE! * Enhance Sexual Performance * Remove Wrinkles and Cellulite * Lower Blood Pressure and improve Cholesterol Profile * Improve Sleep, Vision and Memory * Restore Hair Color and Growth * Strengthen the Immune System * Increase Energy and Cardiac Output * Turn back your body's Biological Time Clock 10-20 years in 6 months of usage !!! You don't have to spend thousands of dollars on shots. You don't have to spend the $139.00 per bottle that HGH is selling for at some Clinics in the United States. For the next 30 Days, you can obtain a complete one-month supply of our HGH releaser for our special "New Customers" price of just $69.95 plus $6.00 shipping and handling. To ensure a constant supply and to SAVE EVEN MORE, you can order with confidence 3 bottles of HGH and GET 1 FREE - that's just $209.85 for 4 bottles, plus $6.00 shipping and handling. You SAVE $69.95! ORDER TODAY! Payment Methods You may mail Checks, MasterCard, Visa, & American Express payments or money Orders. Step 1: Place a check by your desired quanity. ______ 1 Bottle of HGH $69.95 ______ 2 Bottles of HGH $131.90 ($65.95 a bottle) ______ 4 Bottles of HGH (Buy 3 get 1 FREE. SAVE $69.95) $209.85 Please add $6 shipping and handling for any size order. [ Total cost including shipping & handling, 1 bottle =$75.95, 2 bottles=$137.90, 4 bottles=$215.85 ] International Orders Please add $35.00 for shipping. Credit Cards and International Money Orders only. Step 2: Place a check by your desired payment method and complete fields if necessary. _____Check _____Money Order _____American Express Account Number______________________ Exp____/____ _____Visa Account Number______________________ Exp____/____ _____MasterCard Account Number______________________ Exp____/____ Please make your check or money order payable to "LSN". Step 3: Please complete and print the following fields clearly. Name ___________________________________________________ Address _________________________________________________ City ____________________________________________________ State ___________________________________________________ Zip _____________________________________________________ E-mail __________________________________________________ Signature _________________________________________________ [required for check and credit card orders] Mail to: LSN 273 S. State Rd. 7 #193 Margate, FL 33068-5727 ______________________________________________________ This is a one time mailing: Removal is automatic and no further contact is necessary. Please Note: HGH is not intended to diagnose, treat, cure or prevent any disease. The FDA has not evaluated these statements.