[nfsv4] FedFS Meeting Minutes, 01/22/2009

---------------------------------

Attendees
---------

Dan Ellard (BBN)
Craig Everhart (NetApp)
Paul Lemahieu (EMC)
James Lentini (NetApp)
Renu Tewari (IBM/ARC)
Rob Thurlow (Sun)
Mario Wurzl (EMC)

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 weeks meeting with this announcement.

+ Review Action Items

	[AI] For the group: In the second week of February we will 
	     pick a time to hold the FAST BOF. Wednesday is a likely
	     candidate.

	Close. See below.

	[AI] James Lentini will request 4 RPC program numbers for 
	     FedFS using the procedure outlined in
	     draft-ietf-nfsv4-rfc1831bis-10.txt

	Complete. We were granted the range 100418 - 100421.

+ Upcoming events

  - Connectathon

  - FAST '09 BOF

	Dan Ellard reserved a meeting time for the BOF: 
	Wednesday, Feb. 25, 8-9 PM following the NFSv4.1/pNFS BOF.

+ NSDB Protocol Document Updates

  A visual diff of the new and old draft can be produced using this tool:

  http://tools.ietf.org/rfcdiff

  Here is a brief list of things that changed:
	- new IETF IPR boilerplate
	- global replace of "interface" with "protocol"
	- re-wording of introduction
	- replacement of short requirements paragraph with a pointer to the 
	  requirement document
	- removal of root fileset sections, these will be specified in a new 
	  document
	- local NSDB terminology cleaned up
	- junction key removed
	- ONC RPC error codes removed
	- LDAP schema added

  While reviewing the document, please consider
	- How to clarify section 5.3
 	- FSL schema modification to group fs_locations[_info] fields
	  (currency, info) into a single field (called referral_info?). 
	  The format of this field would be dictated by the type of the 
	  FSL (NFSv4, NFSv4.1, CIFS, ....).

  [AI] James Lentini will check the IANA considerations

  Dan described the history of the annotations field. The idea was for 
  this field to have a standard format eventually. After a while,
  that idea was put on hold. The intention was not to use this field for
  the fs_locations[_info] data. This field could be used for the administrator 
  to make notes, for future fields, or some other use.

  Dan also commented on the second idea above, moving the FSL's referral
  specific fields into a single field. Dan pointed out that since this field 
  will be opaque it cannot be interpreted by LDAP. This would be a disadvantage.
  It might end up (possibly) resulting in more accesses to an NSDB because a query will 
  return more info and a query cache will be filled faster.
_______________________________________________
nfsv4 mailing list
nfsv4@ietf.org
https://www.ietf.org/mailman/listinfo/nfsv4