Subject: [nfsv4] AD review: draft-ietf-nfsv4-rfc1831bis-09

From: Lars Eggert <[email-masked]>
Date: Mon, 11 Aug 2008 13:47:19 +0300

INTRODUCTION, paragraph 1:
 > Intended status: Draft Standard

   IETF rules don't allow me to progress this before having received the
   interop report that is required when moving from Proposed to Draft
   Standard. Please send that ASAP.

INTRODUCTION, paragraph 12:
 >    This document describes the ONC (Open Network Computing) Remote
 >    Procedure Call (ONC RPC Version 2) protocol as it is currently
 >    deployed and accepted.  It is meant to supersede [RFC1831].

   Suggest to change "is meant to supersede" to "obsoletes", to use the
   normal IETF terminology.

INTRODUCTION, paragraph 13:
 >    The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL  
NOT",
 >    "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in  
this
 >    document are to be interpreted as described in [RFC2119].

   This paragraph is not typically found within the abstract. Suggest to
   move it to the introduction or the terminology section.

Section 2., paragraph 1:
 >    This document is intended to replace RFC 1831 as the authoritative
 >    document describing RPC, without introducing any over-the-wire
 >    protocol changes.

   Change "is intended to replace" to "obsoletes".

Section 13.2., paragraph 1:
 >    Sun has made assignments in both number spaces since the original
 >    deployment of RPC.  The assignments made by Sun Microsystems are
 >    still valid, and will be preserved.  Sun will communicate all  
current
 >    assignments in both number spaces to IANA before final handoff of
 >    number assignment is done.

   If the Sun registry is publicly available, please provide a pointer,
   so that IANA can take a look at what is currently there.

Section 13.3., paragraph 0:
 > 13.3.  RPC Number Assignment

   This section doesn't describe what the registry looks like. Section
   8.3 only contains a table of numbers, but Appendix B asks for a lot
   more information that looks like it should go into the registry
   ("identifier string", assignee, description, etc.) This section also
   doesn't describe what the initial assignments in the registry are.

Section 13.3.5., paragraph 7:
 >    Sub-blocks sized over 1000 numbers must be documented as described
 >    above, however an Internet Draft must be submitted as an
 >    Informational or standards-track RFC.

   This paragraph isn't aligned with the table above, which says that  
the
   assignment method is "IESG Approval". Please check RFC5226 for the
   definitions and pick one.

Section 13.3.5., paragraph 11:
 >    If an individual or entity has under 1000 numbers and later  
requests
 >    an additional set of numbers such that the individual or entity  
would
 >    over 1000 numbers, then the individual or entity will have the
 >    additional request submitted to the IESG.  IESG is free to waive  
the
 >    IESG Action Required assignment method for incremental requests of
 >    less than 1000 numbers.

   RFC5226 doesn't define a policy called "IESG Action Required" - I
   guess what's meant here is "IESG Approval". Also, the IESG giving out
   a waiver is identical to the IESG approving the request, so I don't
   think this needs to be described differently.

Section 13.4., paragraph 0:
 > 13.4.  RPC Authentication Flavor Number Assignment

   This section doesn't describe what the "flavor" registry looks like,
   what it's initial allocations are or what RFC5226 policy IANA should
   use for future assignments.

_______________________________________________
nfsv4 mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/nfsv4