Mike Kupfer | 29 Jun 23:47 2016
Picon

draft-ietf-nfsv4-versioning-04, Sections 2 and 3

* Section 2

- The term "extensible minor version" is used in several places in the
  spec but I didn't see a definition anywhere.  The main thing I'd
  like to see clarified is that a minor version is extensible because
  the working group says it's extensible, as opposed to being
  something that is derived from the technical details of the version.
  I'd also include a cross-reference to Section 7.4.

- page 5, last paragraph

    In this document, the word "feature" is used , except in the case of

  Delete the extra space before the comma.

- page 5, last paragraph (spilling onto page 6): the last two
  sentences (both starting with "See Section 6") are a jumble.

- page 9, paragraph starting with "Each version variant", sentence
  starting with "For example": change "refer the" to "refer to the"

* Section 3

- The last sentence in the section would be clearer if broken in two:

    Future minor version specification documents should avoid
    specifying minor versioning rules.  Instead, they should reference
    this document in connection with rules for NFSv4 version
    management.

(Continue reading)

internet-drafts | 29 Jun 18:48 2016
Picon

I-D Action: draft-ietf-nfsv4-multi-domain-fs-reqs-09.txt


A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Network File System Version 4 of the IETF.

        Title           : Multiple NFSv4 Domain Namespace Deployment Guidelines
        Authors         : William A. (Andy) Adamson
                          Nicolas Williams
	Filename        : draft-ietf-nfsv4-multi-domain-fs-reqs-09.txt
	Pages           : 16
	Date            : 2016-06-29

Abstract:
   This document provides guidance on the deployment of the NFSv4
   protocols for the construction of an NFSv4 file name space in
   environments with multiple NFSv4 Domains.  To participate in an NFSv4
   mulit-domain file name space, the server must offer a mulit-domain
   capable file system and support RPCSEC_GSS for user authentication.
   In most instances, the server must also support identity mapping
   services.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-nfsv4-multi-domain-fs-reqs/

There's also a htmlized version available at:
https://tools.ietf.org/html/draft-ietf-nfsv4-multi-domain-fs-reqs-09

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-nfsv4-multi-domain-fs-reqs-09

Please note that it may take a couple of minutes from the time of submission
(Continue reading)

The IESG | 28 Jun 17:07 2016
Picon

Last Call: <draft-ietf-nfsv4-scsi-layout-06.txt> (Parallel NFS (pNFS) SCSI Layout) to Proposed Standard


The IESG has received a request from the Network File System Version 4 WG
(nfsv4) to consider the following document:
- 'Parallel NFS (pNFS) SCSI Layout'
  <draft-ietf-nfsv4-scsi-layout-06.txt> as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf <at> ietf.org mailing lists by 2016-07-12. Exceptionally, comments may be
sent to iesg <at> ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract

   The Parallel Network File System (pNFS) allows a separation between
   the metadata (onto a metadata server) and data (onto a storage
   device) for a file.  The SCSI Layout Type is defined in this document
   as an extension to pNFS to allow the use SCSI based block storage
   devices.

The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-nfsv4-scsi-layout/

IESG discussion can be tracked via
https://datatracker.ietf.org/doc/draft-ietf-nfsv4-scsi-layout/ballot/

No IPR declarations have been submitted directly on this I-D.

_______________________________________________
nfsv4 mailing list
(Continue reading)

Spencer Shepler | 25 Jun 00:14 2016
Picon

IETF96 agenda is final - NFSv4 meeting is on July 19th at 10am

 

See following for full schedule:

 

https://datatracker.ietf.org/meeting/96/agenda.html

 

_______________________________________________
nfsv4 mailing list
nfsv4 <at> ietf.org
https://www.ietf.org/mailman/listinfo/nfsv4
"IETF Secretariat" | 24 Jun 18:00 2016
Picon

nfsv4 - Requested session has been scheduled for IETF 96

Dear Spencer Shepler,

The session(s) that you have requested have been scheduled.
Below is the scheduled session information followed by
the original request. 

nfsv4 Session 1 (2:30:00)
    Tuesday, Morning Session I 1000-1230
    Room Name: Charlottenburg I size: 80
    ---------------------------------------------

Request Information:

---------------------------------------------------------
Working Group Name: Network File System Version 4
Area Name: Transport Area
Session Requester: Spencer Shepler

Number of Sessions: 1
Length of Session(s):  2.5 Hours
Number of Attendees: 20
Conflicts to Avoid: 

Special Requests:
  Please consider scheduling the meeting between July 20-22.

We have a key working group member that will not be available at the IETF until July 19th 
---------------------------------------------------------

_______________________________________________
nfsv4 mailing list
nfsv4 <at> ietf.org
https://www.ietf.org/mailman/listinfo/nfsv4

David Noveck | 23 Jun 20:30 2016
Picon

Fwd: New Version Notification for draft-dnoveck-nfsv4-extension-00.txt

There has been some discussion of the possibility of making the versioning document
informational.  I think we will follow up on that at IETF96 and hopefully make a
decision.  Bill S. made the point that each RFC was free to ignore previous RFCs
making the concept of standards-track rules regarding extensions futile, in some sense.

While that position is logical, we have been living for the last years with the minor versioning
rules in RFC5661 and, if we were free, to ignore those, it never mattered.  So my 
conclusion is that if some part of draft-ietf-nfsv4-versioning is to become informational,
not all of it can be.

This new I-D represents my view of the part of the current versioning draft that needs to
be standards-track, if only to negate the existing standards-track statement that doesn't
allow extensions outside minor versions.

In any case we can discuss possible ways to go forward as regards extension models at
IETF96.   One of those might be to convert this I-D into a standards-track working group
document and revise draft-ietf-nfsv4-versioning to take out that material and then made it 
into an Informational document..


---------- Forwarded message ----------
From: <internet-drafts <at> ietf.org>
Date: Thu, Jun 23, 2016 at 2:16 PM
Subject: New Version Notification for draft-dnoveck-nfsv4-extension-00.txt
To: David Noveck <davenoveck <at> gmail.com>



A new version of I-D, draft-dnoveck-nfsv4-extension-00.txt
has been successfully submitted by David Noveck and posted to the
IETF repository.

Name:           draft-dnoveck-nfsv4-extension
Revision:       00
Title:          Rules for NFSv4 Extensions and Minor Versions.
Document date:  2016-06-23
Group:          Individual Submission
Pages:          21
URL:            https://www.ietf.org/internet-drafts/draft-dnoveck-nfsv4-extension-00.txt
Status:         https://datatracker.ietf.org/doc/draft-dnoveck-nfsv4-extension/
Htmlized:       https://tools.ietf.org/html/draft-dnoveck-nfsv4-extension-00


Abstract:
   This document describes the rules relating to the extension of the
   NFSv4 family of protocols.  It covers the creation of minor versions,
   the addition of optional features to existing minor versions, and the
   correction of flaws in features already published as Proposed
   Standards.  The rules relating to the construction of minor versions
   and the interaction of minor version implementations that appear in
   this document supersede the minor versioning rules in RFC5661.




Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat


_______________________________________________
nfsv4 mailing list
nfsv4 <at> ietf.org
https://www.ietf.org/mailman/listinfo/nfsv4
internet-drafts | 22 Jun 21:23 2016
Picon

I-D Action: draft-ietf-nfsv4-multi-domain-fs-reqs-08.txt


A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Network File System Version 4 of the IETF.

        Title           : Multiple NFSv4 Domain Namespace Deployment Guidelines
        Authors         : William A. (Andy) Adamson
                          Nicolas Williams
	Filename        : draft-ietf-nfsv4-multi-domain-fs-reqs-08.txt
	Pages           : 16
	Date            : 2016-06-22

Abstract:
   This document discusses issues relevant to the deployment of the
   NFSv4 protocols in situations allowing for the construction of an
   NFSv4 file namespace supporting the use of multiple NFSv4 domains and
   utilizing multi-domain capable file systems.  Also described are
   constraints on name resolution and security services appropriate to
   the administration of such a system.  Such a namespace is a suitable
   way to enable a Federated File System supporting the use of multiple
   NFSv4 domains.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-nfsv4-multi-domain-fs-reqs/

There's also a htmlized version available at:
https://tools.ietf.org/html/draft-ietf-nfsv4-multi-domain-fs-reqs-08

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-nfsv4-multi-domain-fs-reqs-08

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

_______________________________________________
nfsv4 mailing list
nfsv4 <at> ietf.org
https://www.ietf.org/mailman/listinfo/nfsv4

Adamson, Andy | 20 Jun 20:34 2016
Picon

Re: rfc7861 - new rpcsec gss3 text for IANA registry of structured privilege names text

Backgroung: The rp_name is used to identify the RPC application defined structured privilege, so we need
some more text describing the rp_name namespace. Two means were proposed: IANA registry, or an
SSHv2-like naming scheme.

The working group has had some time to look at this issue.

The summary of WG comments to date:

1) IANA registry for structured privilege rp_names vrs SSHv2 - like scheme. The comments I’ve received:

Nico: SSHv2-like scheme.

Tom Haynes, Chuck Lever, Dave Novec, Andy Adamson: IANA registry.

             - D. Novec: Base structured privilege rp_name IANA registry on Section 20.1 of rfc7530 and use a "standards
action" rather than "specification required” registry.

The WG has chosen to use an IANA registry.

2) IANA registry in separate document vrs add to existing document.

It would be best to have the IANA registry in rfc 7861. Does this delay the RFC process in an unacceptable way?
 
3) If IANA registry in a separate document, mention this in rfc 7861.

How would this work - wouldn’t we need to have a resolved document to reference?

—>Andy






> On Jun 16, 2016, at 10:46 AM, Thomas Haynes <loghyr <at> primarydata.com> wrote:
> 
> 
>> On Jun 16, 2016, at 10:42 AM, Adamson, Andy <William.Adamson <at> netapp.com> wrote:
>> 
>> 
>>> On Jun 16, 2016, at 2:59 AM, Nico Williams <nico <at> cryptonector.com> wrote:
>>> 
>>> Yes, this change would have to be confirmed with the WG.  I'm ok with making no change here and publishing
another RFC later to correct this.  Inserting a note about this now would be ok, however.
>> 
>> 
>> The WG comments so far support an IANA registry.
>> I’m also ok with having a separate document to describe the IANA registry, or another solution that the
WG agrees on, and to note this in RFC 7861.
>> 
> 
> I would say a separate document to describe the IANA registry.
> 
> I don’t care about the note one way or the other.
> 
> 
>> Is this the way forward?
>> 
>> —>Andy
> 

_______________________________________________
nfsv4 mailing list
nfsv4 <at> ietf.org
https://www.ietf.org/mailman/listinfo/nfsv4
Spencer Shepler | 17 Jun 19:57 2016
Picon

ietf96 proposed agenda has been published - NFSv4 is on Tuesday morning 10-12:30 CEST - July 19th

 

Full agenda is here…

 

https://datatracker.ietf.org/meeting/96/agenda.html

 

 

_______________________________________________
nfsv4 mailing list
nfsv4 <at> ietf.org
https://www.ietf.org/mailman/listinfo/nfsv4
spencer shepler | 17 Jun 19:08 2016
Picon

Re: Specification for session trunking connection loss


Martin,

This is question best taken up by the NFSv4 Working Group to receive broad coverage / exposure to the topic.

Spencer


On Fri, Jun 17, 2016 at 4:22 AM, Martin Houry <martinhoury <at> gmail.com> wrote:
Dear Mr Shepler and  Mr. Dawkins,

During my reading of the RFC 5661, I noticed on the point 2.10.13.
Session Mechanics - Recovery there is no specification about the loss
of one connection who is not the last connection of the session.

Can I ask you if the RFC 5661 specify this kind of connection loss and
is there a mecanism specified to explain the following steps after
this connection loss?

Thank you,
Martin Houry

_______________________________________________
nfsv4 mailing list
nfsv4 <at> ietf.org
https://www.ietf.org/mailman/listinfo/nfsv4
Spencer Shepler | 16 Jun 23:41 2016
Picon

IETF 96 draft agenda (v 0.1)

 

The draft agenda has been posted here:

https://www.ietf.org/proceedings/96/agenda/agenda-96-nfsv4

 

Let me know what changes need to be made.

_______________________________________________
nfsv4 mailing list
nfsv4 <at> ietf.org
https://www.ietf.org/mailman/listinfo/nfsv4

Gmane