Re: [nfsv4] [FedFS] Meeting Minutes, 10/14/2010

[Spencer Shepler <[e-mail]>]

In case you don't make it to the end of James' minutes,
a question of future FedFS conference calls arose in the
context of future work.

I have a couple of comments. These "design calls" have served
their purpose extremely well and I appreciate everyone's involvement
to move the work forward. Very effective.  If there are topics
that fall outside of the current scope of these FedFS design calls,
they should certainly be discussed but I might suggest that initially
some of those ideas would be posed to the WG alias in the form of
regular email or internet drafts.  I suggest this because there may
be interested parties that don't participate in the FedFS calls
and don't read to the end of the wonderful minutes that James does
so well at posting (thanks, James).

In any event, please discuss ideas.  Don't wait.  If there is 
interest, a home will be found to move them forward.

Spencer

> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]] On Behalf Of
> James Lentini
> Sent: Thursday, October 14, 2010 12:44 PM
> To: [e-mail]
> Subject: [nfsv4] [FedFS] Meeting Minutes, 10/14/2010
> 
> 
> FedFS Meeting Minutes, 10/14/2010
> ---------------------------------
> 
> Attendees
> ---------
> 
> Andy Adamson (NetApp)
> Steve Dickson (Red Hat)
> Sorin Faibish (EMC)
> James Lentini (NetApp)
> Chuck Lever (Oracle)
> Trond Myklebust (NetApp)
> Spencer Shepler (Microsoft)
> Renu Tewari (IBM)
> 
> 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.
> 
> + Admin Draft Update
> 
>   Draft -07 was posted on 10/10. There were not questions or
>   comments about the changes in the draft.
> 
> + XDR encoding of "/"
> 
>   We discussed the issue raised in this thread:
> 
>   http://www.ietf.org/mail-archive/web/nfsv4/current/msg08573.html
> 
>   Sorin reported that the ESX implementation uses the 0
>   component encoding.
> 
>   We agreed that the FedFS text should describe the two
>   different encoding for "/".
> 
>   We agreed that implementations MUST accept both encodings.
> 
>   There was debate about RECOMMENDING an encoding.
> 
>   Trond didn't see a reason to prefer one encoding over another.
>   He noted that one saved a few bytes, but the differences were
>   minimal.
> 
>   Renu pointed out that if implementations MUST accept both,
>   recommending an encoding wouldn't eliminate the need to
>   support both formats.
> 
>   We decided not to recommend an encoding.
> 
>   With that resolved, Trond asked a related question: What
>   if an arbitrary path component has 0 length?
> 
>   Chuck reported that his tools eliminate double '/'
>   characters (e.g. "/a/path//list/this/").
> 
>   James reported that the SNSDB tools prohibit double '/'
>   characters. The user receives an error if he/she attempts
>   to enter a path containing them.
> 
>   We discussed possible conventions for handling path arrays
>   with 0-length components: ignore the null components, attempt
>   to lookup them up, etc.
> 
>   Trond pointed out that a (naive?) client might walk through
>   the components doing lookups. Such a client could call lookup
>   with a 0-length string when processing a 0-length component4
>   value.
> 
>   Chuck noted that some implementations will process the components
>   in this manner to detect junctions, etc.
> 
>   Trond agreed to post a message about this to the WG email alias.
>   We expect discussion on this topic in the context of RFC3530bis.
> 
>   James said that the FedFS documents will include notes on these
>   issues that is either in sync or references the 3530bis text.
> 
> + Procedure for generating UUID values in Section 4.2.1.1 of NSDB draft
> 
>   Rob may have some suggestions for implementers on choosing UUID values.
>   James will follow up with him.
> 
>   We reviewed the sentence on "test" UUIDs:
> 
>      It MAY also be useful, for purposes of debugging or annotation, to
>      permit a fedfsUuid to include members of a more general class of
>      strings.
> 
>   Chuck noted that the ONC RPC Admin protocol's FedFsUuid type is
>   defined to take binary UUID values (16 bytes). This means that
>   "test" UUIDs cannot be passed over the Admin protocol.
> 
>   James suggested removing this sentence.
> 
>   No objections from Chuck. We'll discuss on the WG reflector.
> 
> + Definition of a fedfsAnnotation
> 
>   The fedfsAnnotation LDAP attribute is defined in Section 4.2.1.12 of
>   draft-ietf-nfsv4-federated-fs-protocol-09.
> 
>   Chuck identified a typo in the text (extra 'may') on page 24:
> 
>   "KEY and VAL MAY may... "
> 
>   Upon reviewing the description in 4.2.1.12, James felt that the
>   sentence about white space (begins on page 23) needs to be
>   clarified. It pertains to white space between the tokens, not
>   within the KEY and VAL fields.
> 
>   Finally, Chuck asked if the NUL character could occur within
>   a fedfsAnnotation value.
> 
>   James had researched this and had not found anything in the
>   LDAP attribute syntax inherited by fedfsAnnotation to
>   prohibit it. James noted that the intention was not to allow
>   NUL characters.
> 
>   Chuck said that the question about NUL characters only
>   pertains to the fedfsAnnotation and fedfsDescr attributes.
>   There is no ambiguity with the other FedFS LDAP attributes.
> 
>   James was unaware of any LDAP tools that would allow a user to
>   input a NUL character via their UI (either text or graphical).
> 
>   Chuck noted that a C client could encode such a
>   value using the C LDAP API. He had not tested to see if an
>   LDAP directory would accept such a value for a fedfsAnnotation.
> 
>   Chuck suggested that if this is an issue, there could there
>   be another more appropriate attribute that fedfsAnnotation (fedfsDescr)
>   could inherit from.
> 
> + Any other WG last call issues?
> 
>   No issues were raised.
> 
> + Meeting schedule
> 
>   Our next meeting will be on October 28. Along with other items, we'll
>   review the updated draft-adamson-nfsv4-multi-domain-access-03 I-D.
>   Andy will send an updated email with questions to the WG list.
>   He is also aware of a related draft (draft-sorce-krbwg-general-pac-00)
>   that may be related to his work.
> 
>   What should future meeting schedule be? Dependent on WG last call?
> 
>   Chuck can think of two ongoing architectural questions that
>   we might want to discuss: NFSv4.2 features for FedFS and/or
>   anything beyond the current FedFS drafts.
> 
>   Trond suggested that it would be interesting to have the admin
>   protocol integrated into NFSv4.2 rather than a sideband protocol.
> 
>   Chuck suggested discussing ways to implement the replication
>   protocol that could be triggered by FEDFS_*_REPLICATION.
> 
>   We'll keep the topic of meeting schedules and topics on the agenda
>   for next time.
> _______________________________________________
> nfsv4 mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/nfsv4