[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[nfsv4] AD review: draft-ietf-nfsv4-rfc1831bis-09
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-wirFrom nfsv4-bounces at ietf.org Mon Aug 11 03:53:11 2008
Return-Path: <nfsv4-bounces at ietf.org>
X-Original-To: nfsv4-archive at megatron.ietf.org
Delivered-To: ietfarch-nfsv4-archive at core3.amsl.com
Received: from [127.0.0.1] (localhost [127.0.0.1])
by core3.amsl.com (Postfix) with ESMTP id 23E543A6AFD;
Mon, 11 Aug 2008 03:53:11 -0700 (PDT)
X-Original-To: nfsv4 at core3.amsl.com
Delivered-To: nfsv4 at core3.amsl.com
Received: from localhost (localhost [127.0.0.1])
by core3.amsl.com (Postfix) with ESMTP id E325C3A69F2
for <nfsv4 at core3.amsl.com>; Mon, 11 Aug 2008 03:53:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.575
X-Spam-Level:
X-Spam-Status: No, score=-6.575 tagged_above=-999 required=5 tests=[AWL=0.024,
BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32])
by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024)
with ESMTP id 2oyg+0mXffd5 for <nfsv4 at core3.amsl.com>;
Mon, 11 Aug 2008 03:53:08 -0700 (PDT)
Received: from mgw-mx06.nokia.com (smtp.nokia.com [192.100.122.233])
by core3.amsl.com (Postfix) with ESMTP id 8E1283A681B
for <nfsv4 at ietf.org>; Mon, 11 Aug 2008 03:53:08 -0700 (PDT)
Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213])
by mgw-mx06.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id
m7BAqSEM006212 for <nfsv4 at ietf.org>; Mon, 11 Aug 2008 13:52:46 +0300
Received: from vaebh103.NOE.Nokia.com ([10.160.244.24]) by
esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959);
Mon, 11 Aug 2008 13:52:28 +0300
Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by
vaebh103.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959);
Mon, 11 Aug 2008 13:47:26 +0300
Received: from net-115.nrpn.net ([10.241.184.208]) by esebh102.NOE.Nokia.com
over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959);
Mon, 11 Aug 2008 13:47:24 +0300
Message-Id: <6B7E1321-5818-43FF-A1C4-10F1E1E40A2F at nokia.com>
From: Lars Eggert <lars.eggert at nokia.com>
To: NFSv4 <nfsv4 at ietf.org>
Mime-Version: 1.0 (Apple Message framework v926)
Date: Mon, 11 Aug 2008 13:47:19 +0300
X-Mailer: Apple Mail (2.926)
X-OriginalArrivalTime: 11 Aug 2008 10:47:25.0030 (UTC)
FILETIME=[A4063060:01C8FB9F]
X-Nokia-AV: Clean
Subject: [nfsv4] AD review: draft-ietf-nfsv4-rfc1831bis-09
X-BeenThere: nfsv4 at ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: NFSv4 Working Group <nfsv4.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/nfsv4>,
<mailto:nfsv4-request at ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/pipermail/nfsv4>
List-Post: <mailto:nfsv4 at ietf.org>
List-Help: <mailto:nfsv4-request at ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/nfsv4>,
<mailto:nfsv4-request at ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes"
Sender: nfsv4-bounces at ietf.org
Errors-To: nfsv4-bounces at ietf.org
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
nfsv4 at ietf.org
https://www.ietf.org/mailman/listinfo/nfsv4
e
> 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
nfsv4 at ietf.org
https://www.ietf.org/mailman/listinfo/nfsv4