Re: [nfsv4] [FedFS] Meeting Minutes, 7/08/2010

[sfaibish <[e-mail]>]

On Thu, 08 Jul 2010 16:25:03 -0400, James Lentini <[e-mail]>  
wrote:

>
> FedFS Meeting Minutes, 7/08/2010
> --------------------------------
>
> Attendees
> ---------
>
> Craig Everhart (NetApp)
> Sorin Faibish (EMC)
> Chuck Lever (Oracle)
> Paul LeMahieu (EMC)
> James Lentini (NetApp)
> Trond Myklebust (NetApp)
> Renu Tewari (IBM)
> Robert Thurlow (Oracle)
>
> Minutes
> -------
>
> + IETF Note Well Agreement
>
>   This is a reminder that our discussions are governed by the
>   IETF Note Well Agreement. See:
>
>     http://www.ietf.org/NOTEWELL.html
>
>   We will start each week's meeting with this announcement.
>
> + NSDB Draft Update
>
>   We reviewed the changes described in the meeting agenda.
>   http://www.ietf.org/mail-archive/web/nfsv4/current/msg08170.html
>
>   There were no questions or comments on the changes.
>
>   The plan will be to update the official IETF version before July 12.
>
>   Chuck suggested that future revisions provide guidance on
>   the handling of LDAP referrals.
>
> + Admin Draft Update
>
>   We reviewed the changes described in the meeting agenda.
>   http://www.ietf.org/mail-archive/web/nfsv4/current/msg08170.html
>
>   Chuck suggested that two additional error codes be added:
>   FEDFS_ERR_PATH_TYPE_UNSUPP and FEDFS_ERR_DELAY
>
>   We discussed what FEDFS_ERR_DELAY would mean. The idea is that
>   this error would allow the admin server to indicate to the admin
>   client that it was waiting on some other system. For example, the
>   admin server might be waiting on a response from an NSDB or for
>   a hierarchical storage system. It was suggested that the client
>   could recover by waiting and then sending a new procedure call
>   with the same parameters to the server under the assumption that
>   the error was transitory.
>
>   Craig asked if a generic error such as this was necessary. Chuck
>   believes that it is because of RPC retransmission. He pointed out
>   that NFSv4 has an NFS4ERR_DELAY which is used to tell the client
>   to go off and do something else. Trond pointed out that NFS4ERR_DELAY
>   can be abused. He suggested that returning a descriptive error
>   would be more useful for the client.
>
>   We discussed what the text description for this error code would
>   be. Chuck suggested that the text in RFC5661 could be used. There
>   was concern that portions of that text would not be appropriate.
>
>   We agreed to discuss this topic further at a future meeting so
>   that we could adequately review the proposal.
>
>   There were no objectsion to adding the FEDFS_ERR_PATH_TYPE_UNSUPP
>   error code in the next update.
>
> + Admin Protocol topics
> - Listing the NSDB Parameters Database
>
>    Chuck described the proposal he sent to the mailing list:
>    http://www.ietf.org/mail-archive/web/nfsv4/current/msg08171.html
>
>    The purpose of this procedure is to allow administrators to
>    review entries in the NSDB parameters database. This information
>    might be used to check for errors or to populate a graphical UI
>    with the contents of the admin server's database.
>
>    Chuck modeled the procedure on RFC5661's READDIR.
>
>    Rob suggested that the admin client should not need to set NSDB
>    parameters before hand if it will be using SEC_NONE. We will
>    discuss this further next time.
>
>  - Explicit Cache Flush procedure
>
>    There wasn't time to discuss this.
>
>  - i18n text
>
>    Sorin noted that Dave Noveck was drafting text on this topic
>    and would be presenting his proposal at the WG meeting at
>    the end of the month. Sorin will invite Dave to join us
>    next week.
Adding Dave Noveck to the email as a reminder.

>
>    James reiterated that the plan is reference the appropriate
>    i18n sections of the rfc3530bis document in the FedFS drafts.
>
>    Chuck noted that we should review the representation of
>    NSDB names in the Admin protocol and in X.509 certificates.
>    He observed that X.509 certificates are not IDN aware and
>    only contain A-labels. When the IDN text is complete, we will
>    review this area.
>
> + Meeting Schedule
>
>   Due to the upcoming IETF WG meeting, we will shift our meeting
>   schedule around. We will meet on July 15 and then on August 5
>   after the WG meeting.
>
> + Boston Bake-a-thon
>
>   Sorin requested that groups planning to bring equipment to the
>   BAT contact him with their space requirements by the end of
>   August. Several individuals interested in FedFS are planning
>   to attend the BAT. Sorin said he would welcome FedFS testing
>   at the event.
> _______________________________________________
> nfsv4 mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/nfsv4
>
>



-- 
Best Regards

Sorin Faibish
Corporate Distinguished Engineer
Network Storage Group

         EMC²
where information lives

Phone: [phone] x 48545
Cellphone: 617-510-0422
Email : [e-mail]