[Gen-art] draft-ietf-nfsv4-pnfs-obj-10 OK [Re: NFSv4 documents on the Dec 4 telechat]

[Brian E Carpenter <[e-mail]>]

I'm happy with draft-ietf-nfsv4-pnfs-obj-10, thanks.

(subject to the ongoing copyright license discussion)

   Brian

On 2008-12-03 06:30, Benny Halevy wrote:
> On Dec. 02, 2008, 11:13 +0200, Lars Eggert <[e-mail]> wrote:
>> On 2008-11-29, at 3:59, Brian E Carpenter wrote:
>>> Thanks. All your responses re pnfs-obj look fine to me.
>> Great - authors, please make these changes.
> 
> Lars, I've uploaded draft-10 that addresses the last call comments.
> 
> Summary of changes made:
> 
> Re-wrote abstract
> 	Borrowed some text from pnfs-bloc and added some more
> 	explanatory text for first-time/occasional readers.
> 
> Scrubbed references.
> 	Removed URL's that refer to draft documents
> 	Changed references to the OSD standard from
> 	  SNIA T10/1355-D to the formal ANSI INCITS 400-2004 name.
> 	Moved NFSv4.1, NFSv4.1 XDR Description, iSNS, and EUI to
> 	  from the Informative to the Normative References section.
> 	Add [[RFC Editor: ...]] comments for required RFC number
> 	  back-patching.
> 
> Rewrote "Client Fencing" to clearly define when the server MAY
> fence the client off.
> 
> Fixed a couple spelling mistakes.
> 
>>> You really
>>> are pioneers for the new copyright stuff, so I'd suggest that
>>> should be taken out of the IESG decision path and resolved
>>> during editing. If it was me, I'd ask the IETF Trust to take
>>> a look and see what they think their own rules mean in this case.
>> I suggest you make the copyright change Brian points out below and  
>> then ask the trust to take a look at the revised document.
> 
> Done.
> What's the best way to contact the IETF Trust?
> 
> Benny
> 
>> Thanks,
>> Lars
>>
>>>   Brian
>>>
>>> On 2008-11-29 11:06, Halevy, Benny wrote:
>>>> Both David and Brian commented on the XDR code copyright message
>>>> and Brian suggested the following instead:
>>>>   /// * This code was derived from IETF RFC
>>>>   /// * [[RFC Editor: please insert RFC number]].
>>>>   /// * Please reproduce this note if possible.
>>>>
>>>> However, according to http://trustee.ietf.org/docs/IETF-Trust-License-Policy.pdf
>>>> it seems like using the BSD license in section 4.
>>>> "License to Code Components." might be more appropriate.
>>>>
>>>>> From: Brian E Carpenter [mailto:[e-mail]]
>>>>> Sent: Thu 2008-11-27 23:18
>>>>> To: General Area Review Team; Lars Eggert; [e-mail] 
>>>>> ; [e-mail]
>>>>> Subject: Gen-ART review of draft-ietf-nfsv4-pnfs-obj-09.txt
>>>>>
>>>>> I have been selected as the General Area Review Team (Gen-ART)
>>>>> reviewer for this draft (for background on Gen-ART, please see
>>>>> http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html).
>>>>>
>>>>> Please wait for direction from your document shepherd
>>>>> or AD before posting a new version of the draft.
>>>>>
>>>>> Document: draft-ietf-nfsv4-pnfs-obj-09.txt
>>>>> Reviewer: Brian Carpenter
>>>>> Review Date:  2008-11-28
>>>>> IESG Telechat date: 04 Dec 2008
>>>>>
>>>>> Summary: Almost ready, some queries and nits (no response to Last  
>>>>> Call review sent 2008-10-22)
>>>>>
>>>>> Comments:
>>>>>
>>>>> My understanding is that the current specification of OSD is
>>>>> expected to be updated in a big way for Version 2 of OSD,
>>>>> and that there is very little deployment of OSDv1.
>>>>> I can't judge the utility of defining a pNFS to OSDv1 mapping
>>>>> at this time, but I do wonder whether this is really appropriate
>>>>> for the standards track rather than Experimental (or Informational,
>>>>> if it documents current practice).
>>>> This is a valid point.
>>>> pnfs-obj can be implmented and deployed over OSDv1
>>>> which is an ANSI INCITS standard but we do need to support
>>>> OSDv2 when it becomes a standard which will happen "soon"
>>>> (looks like in the 2009 time frame).  I see nothing substancial
>>>> changing when this happens other than updating the reference
>>>> and deleting the comment in section 5.1. pnfs_osd_deltaspaceused4.
>>>> I'm not sure how does that should exactly affect pnfs-obj's status,
>>>> but I'd like to be able to easily davance it in the standards track  
>>>> when
>>>> OSDv2 does eventually become an official stadard.
>>>>
>>>>> I don't see any goal or milestone in the WG charter for this work,
>>>>> but the charter hasn't been updated since 2003 anyway.
>>>>>
>>>>> It is impossible to review this in detail for technical content  
>>>>> unless
>>>>> the reviewer is an expert on NFSv4 and OSD, which I am not. So  
>>>>> these are
>>>>> mainly comments on form rather than content. The document is  
>>>>> generally
>>>>> of good quality.
>>>>>
>>>>>> 11.  Client Fencing
>>>>>>
>>>>>>  In cases where clients are uncommunicative and their lease has
>>>>>>  expired or when clients fail to return recalled layouts in a  
>>>>>> timely
>>>>>>  manner the server MAY revoke client layouts and/or device address
>>>>>>  mappings and reassign these resources to other clients.
>>>>> What does "in a timely manner" mean? Is there a specific timer  
>>>>> specified
>>>>> for this, in which case there should be a cross-reference? If not,
>>>>> there should be a statement about what determines the timeout and
>>>>> what the default value should be.
>>>> Hmm, there's actually a pretty good reference by now.
>>>> I'll refer to NFSv4.1 section 12.5.5.  Recalling a Layout
>>>>   Once a layout is recalled, a server MUST wait one
>>>>   lease period before taking further action.  As soon as a lease  
>>>> period
>>>>   has past, the server may choose to fence the client's access to the
>>>>   storage devices if the server perceives the client has taken too  
>>>> long
>>>>   to return a layout.
>>>>
>>>>> _________________________________________________
>>>>> Normative reference issues:
>>>>>
>>>>>>   [2]   Weber, R., "SCSI Object-Based Storage Device Commands",
>>>>>>         July 2004, <http://www.t10.org/ftp/t10/drafts/osd/osd-r10.pdf 
>>>>>>> .
>>>>> This looks like it's a draft, so could be a problem as a normative  
>>>>> reference.
>>>> The link to the latest draft was there just for convenience.
>>>> the actual standard is ANSI/INCITS 400-2004
>>>> providing a link to INCITS's online store
>>>> http://www.techstreet.com/cgi-bin/detail?product_id=1204555
>>>> doesn't seem too polite to me :-/
>>>>
>>>>>>   Note that the XDR code contained in this document depends on  
>>>>>> types
>>>>>>   from the NFSv4.1 nfs4_prot.x file ([8]).
>>>>> IMHO [8] should therefore be a normative reference.
>>>> Yup. agreed.
>>>> I didn't put it there since it was just an I-D at the time.
>>>> I'd put [[RFC Editor: please insert RFC number]]
>>>> comments then for refrences [8] and [9]
>>>>
>>>>>>             The deviceid4 data
>>>>>>   type is defined in NFSv4.1 draft [9].
>>>>> Ditto for [9]
>>>> ditto
>>>>
>>>>>>             The client MAY still use other
>>>>>>   discovery mechanisms such as iSNS [16] to locate the device
>>>>> Ditto for [16] I think, despite the "such as".
>>>> No problem.
>>>>
>>>>> _________________________________________________
>>>>> Nits:
>>>>>
>>>>>> Abstract
>>>>> ...
>>>>>>                           Internet Draft,
>>>>>> which is currently draft-ietf-nfsv4-minorversion1-23.
>>>>> Needless to say this is out of date, and it will be an RFC by the  
>>>>> time
>>>>> the present document is an RFC itself. Just delete the phrase?
>>>> Agreed.  There's a formal reference for NFSv4.1
>>>>
>>>>> The XDR code includes
>>>>>
>>>>>   /// *
>>>>>   /// * Copyright (C) The IETF Trust (2007-2008)
>>>>>   /// * All Rights Reserved.
>>>>>   /// *
>>>>>   /// * Copyright (C) The Internet Society (1998-2006).
>>>>>   /// * All Rights Reserved.
>>>>>
>>>>> I believe this is inconsistent with the latest (draft)  
>>>>> requirements of the
>>>>> IETF Trust. This may be a test case, but according to
>>>>> http://trustee.ietf.org/policyandprocedures.html ,
>>>>> I believe that the code should simply say:
>>>>>
>>>>>   /// * This code was derived from IETF RFC
>>>>>   /// * [[RFC Editor: please insert RFC number]].
>>>>>   /// * Please reproduce this note if possible.
>>>> See discussion above.
>>>>
>>>>> [5]   IBM, IBM, Cisco Systems, Hewlett-Packard Co., and IBM,
>>>>>         "Internet Small Computer Systems Interface (iSCSI)", RFC  
>>>>> 3720,
>>>>>         April 2004, <http://www.ietf.org/rfc/rfc3720.txt>.
>>>>>
>>>>> [7]   Hewlett-Packard Co., Hewlett-Packard Co., and Hewlett-Packard
>>>>>      Co., "T11 Network Address Authority (NAA) Naming Format for
>>>>>      iSCSI Node Names", RFC 3980, February 2005,
>>>>>      <http://www.ietf.org/rfc/rfc3980.txt>.
>>>>>
>>>>> These should be cited by author names like any other RFC.
>>>> Agreed.  Bug in my xml ref definition will be fixed in next revision.
>>>> (already fixed in my copy...)
>>>>
>>>> Thanks for the review!
>>>>
>>>> Benny
>>>>
>>>>
>>>>
>>>> ________________________________
>>>>
>>>> From: Lars Eggert [mailto:[e-mail]]
>>>> Sent: Fri 2008-11-28 21:42
>>>> To: [e-mail]; [e-mail] 
>>>> ; [e-mail]; [e-mail] 
>>>> ; [e-mail]
>>>> Subject: Re: NFSv4 documents on the Dec 4 telechat
>>>>
>>>>
>>>>
>>>> The reviews I have seen are attached.
>>>>
>>>>
>>>>
>>>>
>>>> Begin forwarded message:
>>>>> From: "[e-mail]" <[e-mail]>
>>>>> Date: November 25, 2008 23:29:02 GMT+02:00
>>>>> To: "Eggert Lars (Nokia-NRC/Espoo)" <[e-mail]>
>>>>> Cc: "[e-mail]" <[e-mail]>,
>>>>> "[e-mail]" <[e-mail]>, "[e-mail]" <[e-mail]
>>>>>> , "[e-mail]" <[e-mail]>, "[e-mail]" <[e-mail]
>>>>>>
>>>>> Subject: NFSv4.1 drafts - XDR copyrights are wrong
>>>>>
>>>>> Lars,
>>>>>
>>>>> I found an unfortunate issue in the NFSv4.1 drafts that needs
>>>>> your attention.  The dot-x file draft, pNFS blocks draft, and
>>>>> pNFS object draft all contain an extractable XDR source file
>>>>> with embedded copyrights.
>>>>>
>>>>> The problem is that the copyrights read:
>>>>>
>>>>> /// *  Copyright (C) The IETF Trust (2007-2008)
>>>>> /// *  All Rights Reserved.
>>>>> /// *
>>>>> /// *  Copyright (C) The Internet Society (1998-2006).
>>>>> /// *  All Rights Reserved.
>>>>>
>>>>> "All Rights Reserved" looks very wrong - the intent is
>>>>> for people to extract and use these XDR files to develop
>>>>> implementations.
>>>>>
>>>>> Unfortunately, it's not immediately clear what's right
>>>>> because the existence of two copyright statements above
>>>>> is an example of Sam Hartman's plenary question about
>>>>> documents that exist under more than one version of the
>>>>> IETF IP Policies (for which there wasn't a clear answer).
>>>>>
>>>>> Can you figure out what's correct and write an RFC Editor
>>>>> Note to that effect to correct the copyright statements
>>>>> in all three drafts?
>>>>>
>>>>> Thanks,
>>>>> --David
>>>>> ----------------------------------------------------
>>>>> David L. Black, Distinguished Engineer
>>>>> EMC Corporation, 176 South St., Hopkinton, MA  01748
>>>>> [phone]             FAX: [phone]
>>>>> [e-mail]        Mobile: [phone]
>>>>> ----------------------------------------------------
>>>> Begin forwarded message:
>>>>> From: Brian E Carpenter <[e-mail]>
>>>>> Date: November 27, 2008 23:18:31 GMT+02:00
>>>>> To: General Area Review Team <[e-mail]>, "Eggert Lars  
>>>>> (Nokia-
>>>>> NRC/Espoo)" <[e-mail]>, "[e-mail]
>>>>> " <[e-mail]>, "[e-mail]
>>>>> " <[e-mail]>
>>>>> Subject: Gen-ART review of draft-ietf-nfsv4-pnfs-obj-09.txt
>>>>>
>>>>>
>>>>>
>>>>
> 
_______________________________________________
Gen-art mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/gen-art