Subject: [rddp] Erratum on RDDP Architecture RFC

From: [email-masked]
Date: Mon, 1 Dec 2008 16:49:10 -0500

A pair of sharp eyes caught a couple of related issues
in the RDDP Architecture RFC:

http://www.rfc-editor.org/errata_search.php?eid=136

In summary, the first prototype for rdma_read is:

  rdma_read(socket_t s, ddp_addr_t s, ddp_addr_t d);

and the second prototype doesn't match:

  rdma_read(socket_t s, ddp_addr_t s, length_t l, ddp_addr_t d)

plus the second prototype has two arguments that are both
named "s".  Oops ...

I believe that the correct fix is that the length argument
from the second prototype needs to be in both prototypes,
and the DDP buffer argument "s" (source) should be renamed
to "rs" (remote source) in both prototypes in order to
avoid a name conflict with the socket argument.

If anyone disagrees, please respond.

Assuming this approach is ok, I propose to carry it out
as follows: 
- I will file a new erratum with the above two changes
- I will then ask the RFC Editor to reject the original
	erratum, as it contains a correction for only one
	of the two problems that it identifies.

Thanks,
--David
----------------------------------------------------
David L. Black, Distinguished Engineer
EMC Corporation, 176 South St., Hopkinton, MA  01748
+1 (508) 293-7953             FAX: +1 (508) 293-7786
[email-masked]        Mobile: +1 (978) 394-7754
----------------------------------------------------
_______________________________________________
rddp mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/rddp

---

From: Lars Eggert <[email-masked]>
Date: Tue, 2 Dec 2008 08:54:43 +0200

>        of the two problems that it identifies.

If you give me the errata ID, I can reject the existing one when I  
approve this one.

Lars

---

From: "Talpey, Thomas" <[email-masked]>
Date: Tue, 02 Dec 2008 15:24:21 -0500

>If anyone disagrees, please respond.

Yes, the authors agreed on the first matter when it was pointed out
to us back in 2006.

The first prototype is indeed missing a "length". The second prototype is
correct, and the first needs to be changed, per the existing rfc-editor note.

The second change, however, is unnecessary. As the authors pointed out in
our original response:

"As for the duplicated argument name, this is a minor issue. As the
 document states in section 1 (Introduction):
     "This document uses C language notation as a shorthand to
   describe the architectural elements of DDP and RDMA protocols.  The
   choice of C notation is not intended to describe concrete protocols
   or programming interfaces."

 Because there are no further references to these arguments by
 name, this apparent inconsistency is merely a detail. The text
 would have the same meaning without the "s" parameter names
 altogether."

Our position that this second issue is not an erratum, has not changed.

The first should in any case be executed. Has the RFC editor been waiting
for some confirmation from the Working Group or authors on #136? We would
be happy to give the latter, if so.

Tom.

---

From: Lars Eggert <[email-masked]>
Date: Wed, 3 Dec 2008 10:04:02 +0200

> be happy to give the latter, if so.

The errata process has changed now such that the IESG (= your AD) is  
responsible for accepting, rejecting or holding erratas for a document  
update. (After checking with the authors, chairs or the WG.)

Please indicate which of the three you recommend to happen for each  
errata. I'm attaching my original email to the chairs below, which has  
more details FYI.

Lars

Begin forwarded message:
> From: "ext Lars Eggert" <[email-masked]>
> Date: October 14, 2008 17:07:09 GMT+03:00
> To: <[email-masked]>, "David Black" <[email-masked]>
> Subject: errata processing for TSV area RFCs
>
> Hi,
>
> attached to this email you'll find a list of all errata that have been
> reported on documents produced by the transport area, or on documents
> that are otherwise related to the transport area (documents that pre-
> date the current IETF structure or individual submissions).
>
> I'd like to ask the chairs of the WGs that produced the respective
> documents to please lead the effort to determine whether each listed
> errata is valid or not. Here's the process you should follow:
>
> (1) Make note of the "id" for each errata posted against one of your
> WG documents
>
> (2) Go to http://www.rfc-editor.org/errata_search.php?eid=XXX where
> XXX is that errata ID
>
> (3) Copy the results of that page in to an email to the document
> authors and ask them to comment on the validity of the errata. CC your
> ADs. You may also CC the WG list if you feel that broader community
> input would be helpful and/or if the original authors are
> unresponsive. Give them a deadline of a two weeks or so.
>
> (4) The purpose of this discussion is to determine that (a) the
> indicated errata type (technical/editorial) is correct, and (b) to
> decide how the errata should be handled. For the latter, there are
> three options:
>
>    o Approved - The erratum is appropriate under the criteria below  
> and
>      should be available to implementors or people deploying the RFC.
>
>    o Rejected - The erratum is in error, or proposes a change to the
>      RFC that should be done my publishing a new RFC that replaces the
>      current RFC. In the latter case, if the change is to be
>      considered for future updates of the document, it should be
>      proposed using channels other than the errata process, such as a
>      WG mailing list.
>
>    o Hold for Document Update - The erratum is not a necessary update
>      to the RFC. However, any future update of the document might
>      consider this erratum, and determine whether it is correct and
>      merits including in the update.
>
> (5) After that deadline, judge the consensus on the errata, and
> conclude the discussion phase by sending an email summarizing your
> decision to the recipients of the original email. CC your ADs. The ADs
> will then update the posted errata in the RFC Editor's database.
>
> In order to help you determine the correct handling for the errata in
> step (4), the IESG has come up with a few guidelines:
>
>    1. Only errors that could cause implementation or deployment
>    problems or significant confusion should be Approved.
>
>    2. Things that are clearly wrong but could not cause an
>    implementation or deployment problem should be Hold for Document
>    Update.
>
>    3. Errata on obsolete RFCs should be treated the same as errata on
>    RFCs that are not obsolete where there is strong evidence that
>    some people are still making use of the related technology.
>
>    4. Trivial grammar corrections should be Hold for Document Update.
>
>    5. Typographical errors which would not cause any confusions to
>    implementation or deployments should be Hold for Document Update.
>
>    6. Changes which are simply stylistic issues or simply make things
>    read better should be Hold for Document Update.
>
>    7. Changes that modify the working of a protocol to something that
>    might be different from the intended consensus when the document
>    was approved should be either Hold for Document Update or
>    Rejected. Deciding between these two depends on judgment.
>    Changes that are clearly modifications to the intended consensus,
>    or involve large textual changes, should be Rejected. In unclear
>    situations, small changes can be Hold for Document Update.
>
>    8. Changes that modify the working of a process, such as changing  
> an
>    IANA registration procedure, to something that might be different
>    from the intended consensus when the document was approved should
>    be Rejected.
>
> Also note that you should involve your AD at any time when you feel
> the discussion would benefit from this.
>
> All that said, below are our current errata, for your processing
> pleasure. Please contact Magnus and me if you have any questions about
> this process.
>
> Lars
>
> PS: It'd be great if we managed to process some of these by  
> Minneapolis!
>
> PPS: In the future, we'll forward newly posted erratas directly to the
> appropriate WG chairs. The procedure for processing these is the same
> as above. (Save this email.)
>
>
> Documents coming out of a former or current TSV WG:
> +---------+------+-------------+-----------------+-------- 
> +-----------+
> | doc-id  | id   | submit_date | submitter_name  | wg     |  
> type      |
> +---------+------+-------------+-----------------+-------- 
> +-----------+
> | RFC5128 | 1403 | 2008-03-31  | Alfred Hoenes   | behave |  
> Editorial |
> | RFC5135 | 1318 | 2008-02-14  | Alfred Hoenes   | behave |  
> Editorial |
> | RFC5135 | 1319 | 2008-02-14  | Alfred Hoenes   | behave |  
> Technical |
> | RFC5135 | 1320 | 2008-02-14  | Alfred Hoenes   | behave |  
> Technical |
> | RFC4171 |  175 | 2006-06-23  | Hannes Reinecke | ips    |  
> Editorial |
> | RFC4173 |  174 | 2005-10-17  | Alfred Hoenes   | ips    |  
> Editorial |
> | RFC4544 |   61 | 2006-07-04  | Alfred Hoenes   | ips    |  
> Technical |
> | RFC4545 |   60 | 2006-06-29  | Alfred Hoenes   | ips    |  
> Technical |
> | RFC4939 | 1026 | 2007-09-14  | Alfred Hoenes   | ips    |  
> Technical |
> | RFC4506 |   76 | 2006-05-24  | Alfred Hoenes   | nfsv4  |  
> Editorial |
> | RFC4230 |  976 | 2007-05-16  | Alfred Hoenes   | nsis   |  
> Technical |
> | RFC4230 |  977 | 2007-05-16  | Alfred Hoenes   | nsis   |  
> Technical |
> | RFC4296 |  136 | 2006-01-06  | Alfred Hoenes   | rddp   |  
> Technical |
> | RFC5044 | 1427 | 2008-05-21  | Zem Green       | rddp   |  
> Editorial |
> | RFC3926 |  698 | 2004-11-10  | Alfred Hoenes   | rmt    |  
> Technical |
> | RFC3816 |  737 | 2005-02-23  | Alfred Hoenes   | rohc   |  
> Technical |
> | RFC4995 | 1256 | 2008-01-11  | Alfred Hoenes   | rohc   |  
> Editorial |
> | RFC4995 | 1257 | 2008-01-11  | Alfred Hoenes   | rohc   |  
> Editorial |
> | RFC4996 | 1288 | 2008-01-21  | Alfred Hoenes   | rohc   |  
> Technical |
> | RFC4996 | 1289 | 2008-01-21  | Alfred Hoenes   | rohc   |  
> Technical |
> | RFC4996 | 1290 | 2008-01-21  | Alfred Hoenes   | rohc   |  
> Editorial |
> | RFC4996 | 1291 | 2008-01-21  | Alfred Hoenes   | rohc   |  
> Technical |
> | RFC4996 | 1292 | 2008-01-21  | Alfred Hoenes   | rohc   |  
> Technical |
> | RFC4996 | 1293 | 2008-01-21  | Alfred Hoenes   | rohc   |  
> Technical |
> | RFC4996 | 1294 | 2008-01-21  | Alfred Hoenes   | rohc   |  
> Technical |
> | RFC4996 | 1295 | 2008-01-21  | Alfred Hoenes   | rohc   |  
> Technical |
> | RFC4996 | 1296 | 2008-01-21  | Alfred Hoenes   | rohc   |  
> Editorial |
> | RFC4996 | 1297 | 2008-01-21  | Alfred Hoenes   | rohc   |  
> Technical |
> | RFC4996 | 1298 | 2008-01-21  | Alfred Hoenes   | rohc   |  
> Technical |
> | RFC4996 | 1299 | 2008-01-21  | Alfred Hoenes   | rohc   |  
> Technical |
> | RFC4996 | 1300 | 2008-01-21  | Alfred Hoenes   | rohc   |  
> Technical |
> | RFC5225 | 1421 | 2008-05-13  | Alfred Hoenes   | rohc   |  
> Technical |
> | RFC4804 |  972 | 2007-05-16  | Alfred Hoenes   | tsvwg  |  
> Editorial |
> | RFC4820 |  897 | 2007-04-09  | Alfred Hoenes   | tsvwg  |  
> Technical |
> | RFC4895 |  995 | 2007-09-27  | Frank Ellermann | tsvwg  |  
> Editorial |
> +---------+------+-------------+-----------------+-------- 
> +-----------+
>
> Documents otherwise related to these current TSV WGs:
> +---------+------+------------+----------------+---------- 
> +-----------+
> | doc-id  | id   | date       | submitter_name | wg       |  
> type      |
> +---------+------+------------+----------------+---------- 
> +-----------+
> | RFC0793 |  784 | 2006-09-22 | Ian D. Allen   | tcpm     |  
> Technical |
> | RFC0793 | 1283 | 2008-01-14 | Pei-chun Cheng | tcpm     |  
> Editorial |
> | RFC0793 | 1496 | 2008-08-27 | Yin Shuming    | tcpm     |  
> Technical |
> | RFC0951 |  569 | 2006-02-18 | "Yin Shuming"  | tsvwg?   |  
> Technical |
> | RFC2347 | 1258 | 2008-01-13 | Edwin Groothuis| tsvwg?   |  
> Technical |
> | RFC2544 |  422 | 2006-11-05 | Al Morton      | ippm?    |  
> Editorial |
> | RFC2544 | 1484 | 2008-08-08 | Nikolai Malykh | ippm?    |  
> Editorial |
> | RFC2544 | 1488 | 2008-08-15 | Nikolai Malykh | ippm?    |  
> Editorial |
> | RFC2544 | 1490 | 2008-08-19 | Nikolai Malykh | ippm?    |  
> Editorial |
> | RFC2597 |  413 | 2005-05-24 | Bud            | tsvwg    |  
> Editorial |
> | RFC2663 | 1432 | 2008-05-29 | Harald Hubich  | behave   |  
> Technical |
> | RFC2679 |  398 | 2002-11-18 | Andrew Main    | ippm     |  
> Technical |
> | RFC2680 | 1528 | 2008-09-24 | Wenxia Dong    | ippm     |  
> Editorial |
> | RFC2681 |  397 | 2002-11-18 | Andrew Main    | ippm     |  
> Technical |
> | RFC2861 | 1303 | 2008-01-23 | Sally Floyd    | tcpm     |  
> Editorial |
> | RFC2988 | 1308 | 2008-02-05 | Michael Scharf | tcpm     |  
> Editorial |
> | RFC3331 | 1425 | 2008-05-16 | Alfred Hoenes  | tsvwg?   |  
> Technical |
> | RFC3331 | 1426 | 2008-05-16 | Alfred Hoenes  | tsvwg?   |  
> Technical |
> | RFC4380 |  107 | 2006-03-16 | Alfred Hoenes  | behave?  |  
> Technical |
> | RFC4410 |   97 | 2006-08-14 | Alfred Hoenes  | rmt?     |  
> Technical |
> +---------+------+------------+----------------+---------- 
> +-----------+
>

---

From: [email-masked]
Date: Tue, 9 Dec 2008 20:49:41 -0500

Lars,

I believe the recommendation is to Approve the erratum as
submitted, as the first function prototype clearly needs to
be changed and is a potential source of confusion, BUT ...

... as part of the approval, please add a note that the
"Additionally ..." commentary in the Notes is not part of
the approval because the different types of the two "s"
arguments make it clear that the arguments are distinct,
and that  suffices, as these function prototypes are
described as not intended for implementation usage.

Thanks,
--David

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Lars Eggert
> Sent: Wednesday, December 03, 2008 3:04 AM
> To: Talpey, Thomas
> Cc: [email-masked]; Stephen Bailey; Black, David; [email-masked]
> Subject: Re: [rddp] Erratum on RDDP Architecture RFC
> 
> > for some confirmation from the Working Group or authors on 
> #136? We  
> > would

---

From: Lars Eggert <[email-masked]>
Date: Wed, 10 Dec 2008 10:00:33 +0200

> described as not intended for implementation usage.

I think I can remove that text entirely, if that's preferable?

Lars

---

From: "Talpey, Thomas" <[email-masked]>
Date: Wed, 10 Dec 2008 08:40:10 -0500

>I think I can remove that text entirely, if that's preferable?

Removing that text would restrict the erratum to cover only the
actual defect, which is the best approach for this informational
document.

So yes, delete the "Additionally" text, and preserve the missing
length_t defect erratum report. The word "Presumably" can be
deleted from the last paragraph, to make this explicit!

The erratum's Notes section would then read:

>>"This is inconsistent with the detailed description of that primitive
>> given subsequently on page 15 (2nd-to-last list paragraph), which
>> specifies four (4) arguments.
>>
>> The latter, detailed spec is the appropriate version."

Tom.

---

From: [email-masked]
Date: Wed, 10 Dec 2008 08:40:06 -0500

That is indeed preferable.

Thanks,
--David 

> Sent: Wednesday, December 10, 2008 3:01 AM
> To: Black, David
> Cc: [email-masked]; [email-masked]; 
> [email-masked]; [email-masked]
> >>> (2) Go to 
> http://www.rfc-editor.org/errata_search.php?eid=XXX where
> >>> XXX is that errata ID
> >>>