From sacadmin Tue Jan 31 16:13:04 2006 Received: from sunmail3.sfbay.sun.com (sunmail3.SFBay.Sun.COM [129.149.247.180]) by sac.sfbay.sun.com (8.12.9+Sun/8.12.9) with ESMTP id k110D4IQ009889 for ; Tue, 31 Jan 2006 16:13:04 -0800 (PST) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.149.247.22]) by sunmail3.sfbay.sun.com (8.11.7p1+Sun/8.11.7/ENSMAIL,v2.2) with ESMTP id k110D3a20631; Tue, 31 Jan 2006 16:13:03 -0800 (PST) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0ITZ0050DF9QXS00@nwk-avmta-2.sfbay.sun.com>; Tue, 31 Jan 2006 16:13:02 -0800 (PST) Received: from sfbaymail2sca.sfbay.sun.com ([129.145.155.42]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0ITZ002UGF9O5TA0@nwk-avmta-2.sfbay.sun.com>; Tue, 31 Jan 2006 16:13:00 -0800 (PST) Received: from sac.sfbay.sun.com (sac.SFBay.Sun.COM [129.146.175.66]) by sfbaymail2sca.sfbay.sun.com (8.12.10+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id k110CxLn000664; Tue, 31 Jan 2006 16:12:59 -0800 (PST) Received: from sac.sfbay.sun.com (localhost [127.0.0.1]) by sac.sfbay.sun.com (8.12.9+Sun/8.12.9) with ESMTP id k110CxIQ009884; Tue, 31 Jan 2006 16:12:59 -0800 (PST) Received: (from ss146556@localhost) by sac.sfbay.sun.com (8.12.9+Sun/8.12.9/Submit) id k110Cxob009883; Tue, 31 Jan 2006 16:12:59 -0800 (PST) Date: Tue, 31 Jan 2006 16:12:59 -0800 (PST) From: PSARC-coord@sun.com Subject: New PSARC Materials Submitted 2005/712 Over-the-wire Checksums for NFSv4 To: PSARC@sun.com Cc: Alok.Aggarwal@sun.com, PSARC-coord@sun.com Message-id: <200602010012.k110Cxob009883@sac.sfbay.sun.com> MIME-version: 1.0 Content-type: text/plain Content-transfer-encoding: 7BIT X-PMX-Version: 5.1.2.240295 Status: RO Content-Length: 490 New Materials submitted for PSARC 2005/712 Over-the-wire Checksums for NFSv4 Status: inception scheduled 02/08/2006 Files: /shared/sac/PSARC/2005/712/inception.materials/20Questions /shared/sac/PSARC/2005/712/inception.materials/Checksum.Design /shared/sac/PSARC/2005/712/inception.materials/mount_nfs.1m /shared/sac/PSARC/2005/712/inception.materials/share_nfs.1m /shared/sac/PSARC/2005/712/inception.materials/Why-NFSv4-Checksums.pdf Please let me know if you have questions. - PSARC From sacadmin Mon Feb 13 15:48:08 2006 Received: from sunmail2.sfbay.sun.com (sunmail2.SFBay.Sun.COM [129.149.246.180]) by sac.sfbay.sun.com (8.12.9+Sun/8.12.9) with ESMTP id k1DNm7IQ014697 for ; Mon, 13 Feb 2006 15:48:08 -0800 (PST) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail2.sfbay.sun.com (8.11.7p1+Sun/8.11.7/ENSMAIL,v2.2) with ESMTP id k1DNm7U01375 for <@sunmail1brm.central.sun.com:psarc@sun.com>; Mon, 13 Feb 2006 15:48:07 -0800 (PST) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0IUN00G0DGS6B500@brm-avmta-1.central.sun.com> for psarc@sun.com (ORCPT psarc@sun.com); Mon, 13 Feb 2006 16:48:06 -0700 (MST) Received: from sfbaymail2sca.sfbay.sun.com ([129.145.155.42]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0IUN006HAGS549A0@brm-avmta-1.central.sun.com> for psarc@sun.com (ORCPT psarc@sun.com); Mon, 13 Feb 2006 16:48:06 -0700 (MST) Received: from phys-mpk-1 (phys-mpk-1.SFBay.Sun.COM [129.146.11.81]) by sfbaymail2sca.sfbay.sun.com (8.12.10+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id k1DNm5Ln010986 for ; Mon, 13 Feb 2006 15:48:05 -0800 (PST) Received: from conversion-daemon.mpk-mail1.sfbay.sun.com by mpk-mail1.sfbay.sun.com (iPlanet Messaging Server 5.2 HotFix 1.24 (built Dec 19 2003)) id <0IUN00401GM2YF@mpk-mail1.sfbay.sun.com> (original mail from sherri.shieh@sun.com) for psarc@sun.com; Mon, 13 Feb 2006 15:48:05 -0800 (PST) Received: from [129.150.25.68] (vpn-129-150-25-68.SFBay.Sun.COM [129.150.25.68]) by mpk-mail1.sfbay.sun.com (iPlanet Messaging Server 5.2 HotFix 1.24 (built Dec 19 2003)) with ESMTP id <0IUN0078IGS4B0@mpk-mail1.sfbay.sun.com>; Mon, 13 Feb 2006 15:48:05 -0800 (PST) Date: Mon, 13 Feb 2006 15:48:15 -0800 From: Sherri Shieh Subject: PSARC Meeting Minutes 02/08/2006 Inception: 2005/712; Inception: 2005/745; Commitment: 2005/259 To: psarc@sun.com Cc: Alok Aggarwal , stephen.hahn@sun.com, "Rex G. Martin Jr." , paul.vonbehren@sun.com Reply-to: sherri.shieh@sun.com Message-id: <43F11ABF.9000200@sun.com> MIME-version: 1.0 Content-type: multipart/mixed; boundary="Boundary_(ID_7Dn36adEqll+l/cZo/vl4w)" X-Accept-Language: en-us, en X-PMX-Version: 5.1.2.240295 User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915 Status: RO Content-Length: 22709 This is a multi-part message in MIME format. --Boundary_(ID_7Dn36adEqll+l/cZo/vl4w) Content-type: text/plain; charset=us-ascii; format=flowed Content-transfer-encoding: 7BIT All, Meeting minutes for 02/08/2006 are now available and are attached. Audio files are also available: (1) http://sac.sfbay.sun.com/Archives/Minutes/PSARC/2006/20060208.arcbiz.mp3 (2) http://sac.sfbay.sun.com/Archives/Minutes/PSARC/2006/20060208.2005.712.inception.mp3 (3) http://sac.sfbay.sun.com/Archives/Minutes/PSARC/2006/20060208.2005.259.commitment.mp3 Sum up available at: http://sac.sfbay.sun.com/Archives/Minutes/PSARC/2006/20060208.html If you have any corrections/feedback, please direct them to me. Thanks, Sherri -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Sherri Shieh Program Manager, Systems Architecture Sun Microsystems, Inc. --Boundary_(ID_7Dn36adEqll+l/cZo/vl4w) Content-type: text/plain; name=20060208.txt Content-transfer-encoding: 7BIT Content-disposition: inline; filename=20060208.txt SYSTEM ARCHITECTURE COUNCIL Platform Software ARC --------------------------------- PSARC Regular Meeting time: Wednesdays 10:00-1:00pm in MPK17-3507. 02/08/2006 MEETING MINUTES ============================================================== CORRECTIONS, additions, deletions to sherri.shieh@sun.com. Minutes are archived in sac.Eng:/sac/export/sac/Minutes/PSARC. ATTENDEES - Members: Joseph Kowalski: no (on sabbatical) Glenn Skinner: yes Robert Berube no Andy Rudoff: no (on sabbatical) James Carlson: yes Shudong Zhou: no (out) Bill Sommerfeld: yes Gary Winiger: yes Tim Marsland: no (on sabbatical) Ed Gould: yes David Robinson no (on sabbatical) Sherri Shieh: yes ATTENDEES- Interns: Don Cragun: yes Peter Dennis: no (on sabbatical) Wyllys Ingersoll: no Rick Matthews: yes Alec Muffett: no (on sabbatical) James Falkner: no (on sabbatical) Kais Belgaied: no Phil Harman: no Calum Mackay yes Michael Speer no Ienup Sung no Cecilia Hu: no Brian Utterback yes Michael Haines no Sebastien Roy yes Alan Hargreaves yes Guests: Tom Erikson Alok Aggarwal Dave Poll Stephen Hahn Spencer John Plocher Paul von Behren Mike --------------------------------------------------------------------------- AGENDA ------- 02/08/2006 (Glenn: ARC business only) 10:00-10:10 project id 10:10-10:20 ARC Business 10:20-11:05 Inception: Over-the-wire Checksums for NFSv4 (2005/712) Submitter: Alok Aggarwal Owner: Jim Carlson Intern: Kais Belgaied 11:05-11:50 Inception: SNEEP : Serial Number in EEPROM (2005/745) Submitter: Rex Martin Owner: Ed Gould Intern: Rick Matthews 11:50-11:55 BREAK 11:55-12:40 Commitment: Layered Trusted Solaris Label Interfaces (2005/259) Submitter: Gary Winiger Owner: Gary Winiger Intern: Rick Matthews Interest: lsarc-members@sun.com, rampart-dev-team@sun.com, trusted-jds@sun.com --------------------------------------------------------------------------- Case Anchors: 1) case 1: Over-the-wire Checksums for NFSv4 (2005/712) 2) case 2: SNEEP : Serial Number in EEPROM (2005/745) 3) case 3: Layered Trusted Solaris Label Interfaces (2005/259) =========================================================================== ARC BUSINESS -------------- Fast tracks ----------- 2006/027 Open Kerberos APIs Glenn Barry waiting fast-track 02/09/2006 Wyllys Ingersoll * Still have not heard from MIT - Glenn is trying to get a final word and should hear in a couple of days * push it out another week 2006/053 Public Java classes for Solaris David Powell/Stephen waiting fast-track 02/08/2006 Stephen Hahn * Approved 2006/054 DTrace JNI Binding Tom Erickson waiting fast-track 02/08/2006 Adam Leventhal * Approved 2006/061 xmemfs EOF Eric Lowe waiting fast-track 02/08/2006 Bart Smaalders * Approved 2006/062 CLIP Companion - command line interface David Burrows waiting fast-track 02/09/2006 John Plocher * let it run 2006/063 Debug fp(7d) FCRAW Interface Joel Buckley waiting fast-track 02/09/2006 Paul von Behren * Submitter should alter the IAM file to remove Debug * Approved 2006/070 SO_TIMESTAMP Socket Option Garima Tripathi waiting fast-track 02/13/2006 James Carlson * Approved 2006/073 PF_ROUTE: Include interface name with RT Bill Sommerfeld waiting fast-track 2/13/2006 Bill Sommerfeld * Approved 2006/077 zpool_clear Eric Schrock waiting fast-track 02/13/2006 Jeff Bonwick * Approved 2006/078 DKIOCSETWCE Bill Baker waiting fast-track 02/13/2006 Jeff Bonwick * Approved Other Business -------------- *needing owner for: Name: SFWQuagga: SFW integration of Quagga routing suite (2005/571) Submitter: Paul Jakma Owner: Bill Sommerfeld Intern: Kais Belgaied Interest: quagga-iteam@Sun.COM, alan.maguire@sun.com Status: inception scheduled 02/15/2006 * needing owner/intern for: Name: Clearview: Network Interface Coherence (2005/132) Submitter: Sebastien Roy Owner: Ed Gould Intern: Sebastien Roy Interest: Status: inception scheduled 02/15/2006 Escalating Issues ----------------- * What feedback are we supposed to be getting back from ARC chairs? * Server processors issue? * RBAK issue? * What is the mechanism we have for expressing software requirements to the hardware teams? (all this will be talked about tomorrow in ARC chairs) ============================================================================== Inception: Over-the-wire Checksums for NFSv4 (2005/712) Submitter: Alok Aggarwal Owner: Jim Carlson Intern: Kais Belgaied SUMMARY ======= * Advice - seperate umbrella case for the end-to-end case * Clarify documents and provide more info ISSUES ====== jdc-0 So, wow me with the error statistics. How often are data corrupted in this way? Do we have real-world results? Answer: * Data isn't corrupted very frequently this way, it's very rare infact. But, when it happens it's pretty bad and figuring out where (ethernet controller, the wire or software stack) the corruption is happening is usually very tough. As mentioned in section 3.1 of the one pager, checksums for NFSv4 are motivated by a real world corruption case - one in which the Solaris development community was bitten bitterly by a bad router incriminating the software stack (specifically NFS). If we had this project implemented at that time, we would have caught the corruption right away. * Would like more details about the one case of corruption. * This case dates abck to June of 2003/2004 - this was NFS running over TCP. There was a bad router in one of the labs. Some of the corruption was going past the TCP checksum. However, there is a mechanism that does check the checksum algorithm. jdc-1 Has any of this been discussed with other NFS-speaking vendors? What do they think? (Is there a chance of it becoming a standard extension?) Answer: * I have presented this at the NAS Industry Conference in '05 and discussed this with other NFS vendors, there IS interest in implementing this functionality. I'm 1-2 days away from submitting an Internet Draft on this to the IETF NFSv4 WG and depending upon the feedback there, there are chances this will get adopted by other vendors. jdc-2 Why NFSv4 specifically? Aren't the issues you've outlined also applicable to essentially all networking applications? (Why is NFSv4 special? Is it more vulnerable or fail more regularly than other protocols? Or is the data it carries more valuable?) Answer: * Because NFSv4 is the version of NFS protocol that's undergoing active development and enhancement. NFS v2 and v3 are essentially in maintenance mode (Solaris NFSv2/3 for example is in sustaining currently). The issues outlined are also applicable to other networking protocols as well, yes - I'm not sure what you're getting at here though. If the question is - why not just fix TCP - this has been tried but didn't get any traction amongst the various TCP implementors. * This proposal does not cover the entire request. * This project is just focusing on just the former and none of the underlying issues... jdc-3 Relationship between this project and ZFS: are these the same checksums used by ZFS or is there a transform between the two? Why wouldn't the server side do the ZFS-related integrity check? Are we effectively standardizing ZFS checksumming if we standardize this NFS extension? Answer: * See section 4.4 of the one pager. There is no relationship between this project and ZFS. jdc-4 It seems to me that the checksum still isn't fully end-to-end, as the applications aren't involved. Why is the krb5i RPC level not considered to be enough protection, but NFS level is? Answer: * See slides titled "Why-NFSv4-Checksums.pdf". NFSv4 checksum still isn't end to end but it's a step closer to the end to end data integrity goal. krb5i is great protection but you need to have Kerberos configured to take advantage of it - do we have kerberos configured say inside all of Sun right now? NFS level checksums don't need any a priori kerberos configuration. jdc-5 If it can be controlled with both share(1M) and mount(1M), what's the purpose of the system-wide tunable? Answer: * With ZFS, you'll potentially have thousands of shares. Turning off checksums per share can be cumbersome in that case, this tunable with alleviate some of that pain. jdc-6 Why SHA? Is there an intent to provide some anti-tampering? If so, where are the keys? Answer: * Because SHA is the checksum algorithm that's readily available in the Solaris Kernel. Since this is checksumming we're talking about, I'm not sure of the reference to anti-tampering. * Jim: My concern here is that the compute power is way too strong here. * The project team initially decided to use sha as the algorithm because it was readily available. jdc-7 20q19: if the errors being covered are from design or coding problems, then no retries will help. If they're just carried through from the underlying stable storage, then the answer depends on how the server side does retries (likely no client retry helps). If we're actually checking for alpha particle strikes on main memory or checksum-ok-but-data-bad on the wire, then one or two should be sufficient. Answer: * Agreed jdc-8 20q9: FMA might, someday, be a better answer than syslog, but probably not a requirement of this project. Answer: * Agreed jdc-9 20q5: nit: nfsstat should be in this list. Answer: * Will add this to the list kb-1. the private NFS_CKSUM sideband protocol interoperability with non solaris implementations * The sideband that will be registered and used and will be done before the case is completed. kb-2. any dependency on the future shareadm? * None. However, the project team is aware of it and will change it if issues arise. kb-3. algorithms naming and numbering 3a. how would an administrator know the algorithm to pass to # mount ... -o checksum= ? any option to dislay the supported list? 3b /etc/nfs/nfscksum.conf as a registrar for alorithms number-name mapping why not regular ASN/1 OID numbers, already in use for Kerberos, certs, etc ... in the sideband protocol messages. kb-4. What's the value and need for allowing the checksum algorithm to be changeable for each operation independently, as opposed to be set and remain unchanged as long as the filesystem is mounted, or until a re-negotiation occurs ? kb-5. Recovery from a failed READ. How's the bad checksum error propagated back to the server? How's the server to know about it and re-transmit? does it rely on the RPC layer to handle that? kb-6. interaction with krb5 (section 3.8 of the design), what do you mean by "the checksums would be turned off" ? do you fail the mount in the first place? Do you allow it, but have the WRITE never add the OP_CHECKSUM yet have the READ tolerate and enforce it? * Clarification of the design should be made here. eg-1 20q9 How does reading syslog have anything to do with tuning? * This is an oversight on project team's part. eg-2 20q13 It seems to me that this case exports the new options to share and mount, as well as the new statistics counters. * This will be changed. gw-1 Why do we need another /etc file? (/etc/nfs/nfschksum.conf) Can't we either include the information in the existing one(s), or as smf properties? gw-2 20Q #17, How will this mechanism be flexible with a possible change in the industry? What if alignment doesn't occur? gw-3 Why not checksum at the RPC layer? This sounds a lot like GSSAPI/SPNEGO. Why can't that be used? gw-4 Design #1, Please say more about interaction with ZFS, I'm not sure I understand the comment. gw-5 I believe the data management folk are addressing similar issues, please touch base with them. wes-1 How do you know the design & protocol is actually algorithm-agile unless you have more than one algorithm supported? I strongly recommend implementing multiple checksum algorithms -- sha256 is likely to have a short shelf life. * There will ab another migration after sha256. We would want to see at least 2 algorithms implemented and a test where the availabilities are. * CRC32 was looked at by the p-team - it would be very easy to add this if neccessary. - P-team has had some initial chats with the crypto team. * Any algorithm that the p-team needs should be discussed with the crypto team as well. wes-2 what's the documented threat model? if it's to protect against random/ non-malicious corruption, should clarify this in the man pages since admins who know just enough about crypto to be dangerous may see "sha256" and assume it's good against malicious corruption.. * Tied with jdc-06 * BillS: It doesn't provide any protection against man-in-the-middle attacks. wes-3 opinion fodder/advisory fodder: followon project to generate fma error reports from points in the networking stack (nfs, ip/tcp/udp/sctp/ah/esp/...) where bad checksums are detected. (diagnosis engine may be a research exercise but the in-stack instrumentation should be straightforward). NEXT STEP ========= * Project team will go back and resolve all issues from today's meeting. --Boundary_(ID_7Dn36adEqll+l/cZo/vl4w)-- From sacadmin Thu May 25 14:08:52 2006 Received: from sunmail1brm.Central.Sun.COM (sunmail1brm.Central.Sun.COM [129.147.62.17]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id k4PL8q7D014386 for ; Thu, 25 May 2006 14:08:52 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail1brm.Central.Sun.COM (8.11.7p1+Sun/8.11.7/ENSMAIL,v2.2) with ESMTP id k4PL8oB22971; Thu, 25 May 2006 15:08:50 -0600 (MDT) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0IZU00H05AQPS500@brm-avmta-1.central.sun.com>; Thu, 25 May 2006 15:08:49 -0600 (MDT) Received: from sac.sfbay.sun.com ([129.146.175.66]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0IZU00HGHAQN9S10@brm-avmta-1.central.sun.com>; Thu, 25 May 2006 15:08:47 -0600 (MDT) Received: from sac.sfbay.sun.com (localhost [127.0.0.1]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id k4PL8lLF014381; Thu, 25 May 2006 14:08:47 -0700 (PDT) Received: (from ss146556@localhost) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6/Submit) id k4PL8lPs014380; Thu, 25 May 2006 14:08:47 -0700 (PDT) Date: Thu, 25 May 2006 14:08:47 -0700 (PDT) From: PSARC-coord@sun.com Subject: New PSARC Materials Submitted 2005/712 Over-the-wire Checksums for NFSv4 To: PSARC@sun.com Cc: Alok.Aggarwal@sun.com, PSARC-coord@sun.com Message-id: <200605252108.k4PL8lPs014380@sac.sfbay.sun.com> MIME-version: 1.0 Content-type: text/plain Content-transfer-encoding: 7BIT X-PMX-Version: 5.1.2.240295 Status: RO Content-Length: 559 New Materials submitted for PSARC 2005/712 Over-the-wire Checksums for NFSv4 Status: commitment scheduled 06/07/2006 Files: /shared/sac/PSARC/2005/712/commitment.materials/20Questions /shared/sac/PSARC/2005/712/commitment.materials/Checksum.Design /shared/sac/PSARC/2005/712/commitment.materials/issues.answers /shared/sac/PSARC/2005/712/commitment.materials/mount_nfs.1m /shared/sac/PSARC/2005/712/commitment.materials/share_nfs.1m /shared/sac/PSARC/2005/712/commitment.materials/Why-NFSv4-Checksums.pdf Please let me know if you have questions. - PSARC From sac-owner Wed Jun 7 12:13:51 2006 Received: from sunmail1brm.Central.Sun.COM (sunmail1brm.Central.Sun.COM [129.147.62.17]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id k57JDp50013758 for ; Wed, 7 Jun 2006 12:13:51 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail1brm.Central.Sun.COM (8.11.7p1+Sun/8.11.7/ENSMAIL,v2.2) with ESMTP id k57JDos12157 for <@sunmail1brm.central.sun.com:sac-review@sun.com>; Wed, 7 Jun 2006 13:13:50 -0600 (MDT) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0J0I0070982Z3U00@brm-avmta-1.central.sun.com> for sac-review@sun.com (ORCPT sac-review@sun.com); Wed, 07 Jun 2006 13:13:47 -0600 (MDT) Received: from nwkea-pix-1.sun.com ([10.4.134.5]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0J0I006M082YWU10@brm-avmta-1.central.sun.com> for sac-review@sun.com (ORCPT sac-review@sun.com); Wed, 07 Jun 2006 13:13:47 -0600 (MDT) Received: from d1-sfbay-04.sun.com ([192.18.39.114]) by nwkea-pix-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id k57JDkEC003931 for ; Wed, 07 Jun 2006 12:13:46 -0700 (PDT) Received: from conversion-daemon.d1-sfbay-04.sun.com by d1-sfbay-04.sun.com (Sun Java System Messaging Server 6.2-4.02 (built Sep 9 2005)) id <0J0I00H017JFVL00@d1-sfbay-04.sun.com> (original mail from Sherri.Shieh@Sun.COM) for sac-review@sun.com (ORCPT sac-review@sun.com); Wed, 07 Jun 2006 12:13:46 -0700 (PDT) Received: from [129.150.24.104] by d1-sfbay-04.sun.com (Sun Java System Messaging Server 6.2-4.02 (built Sep 9 2005)) with ESMTPSA id <0J0I00MG582Y4T80@d1-sfbay-04.sun.com> for sac-review@sun.com (ORCPT sac-review@sun.com); Wed, 07 Jun 2006 12:13:46 -0700 (PDT) Date: Wed, 07 Jun 2006 12:13:43 -0700 From: Sherri Shieh Subject: PSARC Case Approved 06/07/2006 - 2005/712 Sender: Sherri.Shieh@Sun.COM To: Sherri Shieh Reply-to: Sherri.Shieh@Sun.COM Message-id: <44872567.8030905@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=us-ascii Content-transfer-encoding: 7BIT X-Accept-Language: en-us, en X-PMX-Version: 5.2.0.264296 User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915 Status: RO Content-Length: 228 PSARC approved 06/07/2006 Case: Over-the-wire Checksums for NFSv4 (2005/712) Incompatible Changes: none Precedent: none If more information is needed, please contact the case owner/intern.