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

[James Lentini <[e-mail]>]

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.