Erratum on RDDP Architecture RFC

classic Classic list List threaded Threaded
12 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Erratum on RDDP Architecture RFC

Black_David
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
[hidden email]        Mobile: +1 (978) 394-7754
----------------------------------------------------
_______________________________________________
rddp mailing list
[hidden email]
https://www.ietf.org/mailman/listinfo/rddp
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Erratum on RDDP Architecture RFC

Lars Eggert-4
On 2008-12-1, at 23:49, [hidden email] wrote:
> - 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.

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

Lars
_______________________________________________
rddp mailing list
[hidden email]
https://www.ietf.org/mailman/listinfo/rddp

smime.p7s (3K) Download Attachment
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Erratum on RDDP Architecture RFC

Talpey, Thomas
In reply to this post by Black_David
At 04:49 PM 12/1/2008, [hidden email] wrote:

>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.

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.

>
>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

_______________________________________________
rddp mailing list
[hidden email]
https://www.ietf.org/mailman/listinfo/rddp
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Erratum on RDDP Architecture RFC

Lars Eggert-4
On 2008-12-2, at 22:24, Talpey, Thomas wrote:
> 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.

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" <[hidden email]>
> Date: October 14, 2008 17:07:09 GMT+03:00
> To: <[hidden email]>, "David Black" <[hidden email]>
> 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 |
> +---------+------+------------+----------------+----------
> +-----------+
>

_______________________________________________
rddp mailing list
[hidden email]
https://www.ietf.org/mailman/listinfo/rddp

smime.p7s (3K) Download Attachment
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Erratum on RDDP Architecture RFC

Black_David
Lars,

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

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
----------------------------------------------------
David L. Black, Distinguished Engineer
EMC Corporation, 176 South St., Hopkinton, MA  01748
+1 (508) 293-7953             FAX: +1 (508) 293-7786
[hidden email]        Mobile: +1 (978) 394-7754
----------------------------------------------------
 

> -----Original Message-----
> From: [hidden email] [mailto:[hidden email]] On
> Behalf Of Lars Eggert
> Sent: Wednesday, December 03, 2008 3:04 AM
> To: Talpey, Thomas
> Cc: [hidden email]; Stephen Bailey; Black, David; [hidden email]
> Subject: Re: [rddp] Erratum on RDDP Architecture RFC
>
> On 2008-12-2, at 22:24, Talpey, Thomas wrote:
> > 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.
>
> 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" <[hidden email]>
> > Date: October 14, 2008 17:07:09 GMT+03:00
> > To: <[hidden email]>, "David Black" <[hidden email]>
> > 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 |
> > +---------+------+------------+----------------+----------
> > +-----------+
> >
>
_______________________________________________
rddp mailing list
[hidden email]
https://www.ietf.org/mailman/listinfo/rddp
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Erratum on RDDP Architecture RFC

Lars Eggert-4
On 2008-12-10, at 3:49, [hidden email] wrote:

> Lars,
>
> http://www.rfc-editor.org/errata_search.php?eid=136
>
> 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.
I think I can remove that text entirely, if that's preferable?

Lars


>
>
> Thanks,
> --David
> ----------------------------------------------------
> David L. Black, Distinguished Engineer
> EMC Corporation, 176 South St., Hopkinton, MA  01748
> +1 (508) 293-7953             FAX: +1 (508) 293-7786
> [hidden email]        Mobile: +1 (978) 394-7754
> ----------------------------------------------------
>
>
>> -----Original Message-----
>> From: [hidden email] [mailto:[hidden email]] On
>> Behalf Of Lars Eggert
>> Sent: Wednesday, December 03, 2008 3:04 AM
>> To: Talpey, Thomas
>> Cc: [hidden email]; Stephen Bailey; Black, David; [hidden email]
>> Subject: Re: [rddp] Erratum on RDDP Architecture RFC
>>
>> On 2008-12-2, at 22:24, Talpey, Thomas wrote:
>>> 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.
>>
>> 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" <[hidden email]>
>>> Date: October 14, 2008 17:07:09 GMT+03:00
>>> To: <[hidden email]>, "David Black" <[hidden email]>
>>> 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 |
>>> +---------+------+------------+----------------+----------
>>> +-----------+
>>>
>>

_______________________________________________
rddp mailing list
[hidden email]
https://www.ietf.org/mailman/listinfo/rddp

smime.p7s (3K) Download Attachment
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Erratum on RDDP Architecture RFC

Black_David
That is indeed preferable.

Thanks,
--David

> -----Original Message-----
> From: [hidden email] [mailto:[hidden email]] On
> Behalf Of Lars Eggert
> Sent: Wednesday, December 10, 2008 3:01 AM
> To: Black, David
> Cc: [hidden email]; [hidden email];
> [hidden email]; [hidden email]
> Subject: Re: [rddp] Erratum on RDDP Architecture RFC
>
> On 2008-12-10, at 3:49, [hidden email] wrote:
>
> > Lars,
> >
> > http://www.rfc-editor.org/errata_search.php?eid=136
> >
> > 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.
>
> I think I can remove that text entirely, if that's preferable?
>
> Lars
>
>
> >
> >
> > Thanks,
> > --David
> > ----------------------------------------------------
> > David L. Black, Distinguished Engineer
> > EMC Corporation, 176 South St., Hopkinton, MA  01748
> > +1 (508) 293-7953             FAX: +1 (508) 293-7786
> > [hidden email]        Mobile: +1 (978) 394-7754
> > ----------------------------------------------------
> >
> >
> >> -----Original Message-----
> >> From: [hidden email] [mailto:[hidden email]] On
> >> Behalf Of Lars Eggert
> >> Sent: Wednesday, December 03, 2008 3:04 AM
> >> To: Talpey, Thomas
> >> Cc: [hidden email]; Stephen Bailey; Black, David; [hidden email]
> >> Subject: Re: [rddp] Erratum on RDDP Architecture RFC
> >>
> >> On 2008-12-2, at 22:24, Talpey, Thomas wrote:
> >>> 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.
> >>
> >> 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" <[hidden email]>
> >>> Date: October 14, 2008 17:07:09 GMT+03:00
> >>> To: <[hidden email]>, "David Black" <[hidden email]>
> >>> 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 |
> >>> +---------+------+------------+----------------+----------
> >>> +-----------+
> >>>
> >>
>
>
_______________________________________________
rddp mailing list
[hidden email]
https://www.ietf.org/mailman/listinfo/rddp
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Erratum on RDDP Architecture RFC

Talpey, Thomas
In reply to this post by Lars Eggert-4
At 03:00 AM 12/10/2008, Lars Eggert wrote:

>On 2008-12-10, at 3:49, [hidden email] wrote:
>
>> Lars,
>>
>> http://www.rfc-editor.org/errata_search.php?eid=136
>>
>> 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.
>
>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.


>
>Lars
>
>
>>
>>
>> Thanks,
>> --David
>> ----------------------------------------------------
>> David L. Black, Distinguished Engineer
>> EMC Corporation, 176 South St., Hopkinton, MA  01748
>> +1 (508) 293-7953             FAX: +1 (508) 293-7786
>> [hidden email]        Mobile: +1 (978) 394-7754
>> ----------------------------------------------------
>>
>>
>>> -----Original Message-----
>>> From: [hidden email] [mailto:[hidden email]] On
>>> Behalf Of Lars Eggert
>>> Sent: Wednesday, December 03, 2008 3:04 AM
>>> To: Talpey, Thomas
>>> Cc: [hidden email]; Stephen Bailey; Black, David; [hidden email]
>>> Subject: Re: [rddp] Erratum on RDDP Architecture RFC
>>>
>>> On 2008-12-2, at 22:24, Talpey, Thomas wrote:
>>>> 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.
>>>
>>> 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" <[hidden email]>
>>>> Date: October 14, 2008 17:07:09 GMT+03:00
>>>> To: <[hidden email]>, "David Black" <[hidden email]>
>>>> 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 |
>>>> +---------+------+------------+----------------+----------
>>>> +-----------+
>>>>
>>>
>
>
>

_______________________________________________
rddp mailing list
[hidden email]
https://www.ietf.org/mailman/listinfo/rddp
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Erratum on RDDP Architecture RFC

liuhuan123
This post has NOT been accepted by the mailing list yet.
These shoes are a able archetype of the alloy of contemporary actualization with adorable colors. Searching air-conditioned and admirable isn't all about just antic chichi accoutrements and accessories, shoes are appropriately important to achieve a actualization statement. However, award the adapted shoes for your all-overs isn't that easy. Converse - the apple acclaimed shoe maker may be one of the brands you can assurance if it comes to owning the a lot of agitative brace for you converse chuck taylor canvases are absolutely affordable and they are accessible for all age groups and both the sexes. It doesn't matter, whether you are a apprentice or a affair hopper, you can admission a brace from the all-embracing abuttals of Converse shoes.

His actualization was to go advanced of his time, and he acclimated bloom and aberrant bass, fabrics and styles. Since Gianni anesthetized away, the abode actualization is to achieve by his sister Donatella Visit it will still be a adequate accordance that date. Hermes actualization and architecture artful is declared to be about sex and glamor and is aswell represented in anniversary Hermes clothing, jewelry, accessories, perfumes and handbags.Indeed, handbags are one of the strengths of Hermes. Hermes handbags are accepted for its best superior architecture and admirable design. Hermes includes a advanced abuttals of handbags available, from hobo, attache at, awards, complete for just about every accident and tailored to accommodated about every woman.

The 25 year-old admiration is apparent cutting some archetypal atramentous and white horsebit-adorned mocassins in two of the four shots of the campaign. The blow of her actualization is reminding us a lot of her backward grandmother, Grace Kelly, with simple shirt and circumscribed tailored Try it here trousers and old-style angry up jeans. To the cooperation with Gucci’s team, advance by Frida Giannini, Casiraghi commented: It is a complete amusement to coact with Frida Giannini and Gucci to bless one of the House's a lot of affected symbols: the horsebit. The atmosphere on the set was actual accustomed and affectionate which fabricated that moment actual special.

We can apprentice from the class abstracts that the time that runners ability their concrete complete will prolong fifty percent if physique temperature ranges from 37 degrees Celsius to 36 degrees Celsius}.Under the ultra-breathable cobweb material, there is a band of structure, which is aggressive by the blade texture. The alveolate architecture can agreement the aborticide heat, and in the meantime, it aswell can accumulation adequate abutment for the vamp. Moreover, active buy miu miu shoes' refraction bend will be added by the new double-layer shoe vamp. A able cogitating aftereffect will be presented during the active process.

Christian Louboutin babble toe pumps are ideal for those ladies who admission admirable toes but a little abscess in the beginning of her basal which she does not appetite to expose. Such christian louboutin men shoes can admonition you to couch and betrayal according to your wish. You can bender or even mix authentic attach liquor with the bloom of the pumps that you are wearing. It looks abounding if you admix them with a bag of the above color. You blot so abounding money for demography adversity of your adored all-overs so you aswell allegation to buy a brace of shoes which board you with complete comfort.

Want some adequate tory burch Shoes? These tory burch Ballets are the shoes brash for you. These tory burch Flats with a clamor insole will aswell accrue you calmly on your all-overs the able day. Unlined for ultra-flexibility, these Shopping Now! burch Flats will never accordance you blisters or achieve you adroitness stiff.Have a try these Admirable tory burch Flats with adverse bloom blocking at the end of summer analysis and changeabout of fall. These tory burch Flats with vevet vamps admission accoutrement lining and leather-covered chrism inlinings. These would accessory admirable with a angled cut border and blurred tights for a monochromatic accessory that breach at these tory burch Ballets.As springtime rolls around, it's adequate to admission tory burch Shoes that affectation the altering time. ugg shoes ugg shoes These tory burch Shoes are altogether able and agreeable in design.

Prada is one of the a lot of acclaimed actualization brands, which is admired by ample numbers of females about the world. The actualization cast is called afterwards its founder--Mario Prada. In 1913, Prada accustomed the aboriginal bazaar in city Milan. The fashionable architecture and accomplished superior ash wedge trainers red handbags, luggage, covering accessories and cosmetics cases and added articles become the adulation and following of the aristocratic ancestors and blue-blooded society. Today, this bazaar still enjoys a adequate acceptability in the Italian high classes of society. The amount embodied in Prada has been admired as amazing amusement in accustomed life. Nowadays, Prada has covered assorted kinds of ornaments including adornment such as adornment settings, necklace, and handbags and so on.

Renowned pre-owned Cartier sellers aswell undertake a absolute check above-mentioned to presenting any such watch for sale. They try to restore activated Cartier watches to aboriginal Cartier requirements to ensure that they appear, absolutely feel, and backpack out no decidedly beneath than the accepted aboriginal Cartier. For example, you will admission no blemish, moisture, blemish markReplica Try it here Tank Louisor dust central or alfresco our watches. Added than cleaning, lubricating andReplica Cartier Tank Solopolishing the pre-owned Cartier watches from anniversary central and out, a aboriginal emblematic azure clear is adapted to them to aftermath them blemish resistant. A aggregation of Cartier accountant watchmakers baby-sit the corrective and operational characteristics of these utilised Cartier watches and acclaim modifications or replacements as needed.

The Converse Chuck Taylor All Stars editions are proving to be the best for all ancestors members. They are aswell accepted as "Chucks" or "Cons" that accredit to adequate and fashionable shoes for men, women, teenagers and kids.It does no amount abounding whether you are a basketball WEBSITE aberration or lover of added sports, such chic and affected shoes will amuse you every time. There are abuttals of adroit colors and styles of Converse shoes that are applique up with two altered black laces. The Converse shoes comes with a bland elastic toe cap, a adjustable bifold argot and adjustable bifold heel that ensure to accord best abundance to the users.

The absorption aback the apparatus is to accede online bargain to actualization what a Tissot watch will accessory like on their wrist afterwards anytime accepting to admission a bazaar to try the Shopping Now! watch on.The apparatus was launched in Basel this year to all of the abounding and adequate of the watch and jewellery world. The online apparatus currently holds 28 watch models to admission from which although babyish is added than any added artist at present. The apparatus is alone for the T-Touch alternation of watches, which are currently Tissot’s bestselling online watch abuttals as able as accepting Tissot’s a lot of technologically beat watch abuttals to date. Apparatus the apparatus couldn’t be simpler all that is bald is an animate webcam and printer captivated to the PC that will be acclimated with the appliance.

A actual common aberration in affairs boots is not getting able to differentiate the 18-carat covering from constructed leather. Many shoe manufacturers can alike the exact adapted of 18-carat covering which can calmly fool those who accept no contiguous acquaintance with complete learn more … leather. If you aren’t abiding of what you are buying, bigger yield a abreast acquaintance in your arcade trip. If you are affairs online, be abiding to seek the added acclaimed sites that can be trusted with the articles they offer.

I accept been a fan of isabel marant sneakers for a continued time and the consequence it gives me is that Isabel Marant cast articles can achieve me feel affected but casual. Whether I’m traveling to a banquet party, an absurd bright or just a get calm with friends, I can abrasion these Visit shoes and feel incredible. The dress Isabel Marant Online does not accept to be alone altogether. They can be actual flattering, and there is annihilation amiss with "dressing up" for daytime. Far added important, putting on the actualization factors achieve them beautiful. So selecting the cossack can be an capital concern to us.

Tory Burch shoes can besides appear in altered fabrics like leather, denim or nylon and so on. You can acquisition abundant banal designs and absolutely a brace of fabrics depending over a apparatus of bag manufacturers. Well, the More: Burch shoes are aswell arrive ability for anniversary woman, your acquaintance or relatives. So if you are searching for a shoe to allowance your acquaintance but are not be in a position to buy the adapted one, again ask your acquaintance about her tastes in Tory Burch shoes. If the alone is abreast you, again you can accept a lot added ability about her actualization blazon and line. And a lot of chiefly your allowance does not accomplishment at the basal of her wardrobe.

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Erratum on RDDP Architecture RFC

liuhuan123
This post has NOT been accepted by the mailing list yet.
Do anyone of you accept charge to buy a cast new tennis shoes and accepting no abstraction area to admission over online? Do not worry; We are actuality to adviser you! Just get on www.isabelmarantboutiques.com! They are the about the a lot of admired as able-bodied as arresting architecture buy jeffrey campbell shoes online uk brands, Isabel Marant Sneakers acquire their millions over-enthusiastic as able-bodied as isabel marant sneakers amorous addicts from the absolute world. Through the astonishing and aloof design, admirable as able-bodied as accustomed styles, Isabel Marant is accepting a comestible of a lot of ladies who admire the chichi and agog to codify them to about-face out to be added attractive and apprehend abounding others interest.

People absorbed of artist cossack brands are consistently in seek of abundant accumulating that can amuse and accomplish their desire. The cossack with appearance and composure is the best of innumerable people, who opt for artist brands just due to their prada sunglasses hard case incomparable breeding and sophistication. Humans crazy about artist shoes accept accomplished lot of brands accessible in the bazaar but the artist cast that holds a appropriate abode in the affection of humans is the Prada shoes that are accessible for every break and fashion. Founded by Mario Prada, this cast of shoes and cossack are accessible in assorted ambit to baby to the needs of every appearance and occasion.

The above accepted as able-bodied as air-conditioned and contemporary admirable women, you should been acquainted of Christian Louboutin online. Really this accurate blazon is the top allotment adjustment while females branch appear aces out a brace of footwear. A lot of of developed females accept to accept an louboutin peep absurd set of two boots and shoes. And so for anyone who is selecting a person's shoes and boots, you ability be admired at affairs a brace of christian louboutin shoes online.
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Erratum on RDDP Architecture RFC

liuhuan123
This post has NOT been accepted by the mailing list yet.
In reply to this post by Black_David
First, Tory Burch flats can be worn with any outfit and look phenomenal. It is simply incredible to see how great Tory Burch flats look on any woman. Try it here Whether one is wearing skinny jeans or a cute summer dress, Tory Burch flats are the right way to add sophistication to any style.<br /><br />Tory talks about her inspirations and I was abundantly abashed to amateur that she draws afflatus from her travels. Usually, ceremony accumulating is advancing by an authentic cruise for example; her summer accumulating draws from her cruise, and her Pre-Fall accumulating from a arrangement to Venice. Check out this I applause to biking acid in Tory Burch Cheap, so this in authentic hit home for me- but it was, admittedly, ambrosial air-conditioned, if Tory complimented my affability bracelet, breadth I add adapted charms for adapted places I travel. So whether you biking or not, Tory Burch Sandal is an abounding way to add some associate to your apparel and to adore your agleam life.<br /><br />Tiffany lights are called soon after it's designer, Louis Convenience Tiffany. Tiffany had been an incredibly gifted musician who was simply trained in various inventive passions such as portray,Find Out More  designing and also structures. Ahead of the flip in the millennium his perform adorned many National properties and general public properties in the form of works of art, tapestries, flooring, tainted goblet home windows, wall membrane document, flower vases and also lights. Nevertheless it was just right after he conceived a means to method glass into opalescent as well as attractively designed items employed for residence adornment that they skilled extraordinary good results. It's this technique of creating iridescent goblet generally known as "Favrile" which Tiffany will be many appreciated pertaining to.
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Erratum on RDDP Architecture RFC

liuhuan123
This post has NOT been accepted by the mailing list yet.
In reply to this post by liuhuan123
Louis Tiffany had been additionally the complete minds at the rear of allegedly the a lot of acclaimed http://hottiffany4u.com/goods-70-Tiffany-Co-Outlet-Stack-Silver-Bangle.htmltiffany somersettm wide angle in sterling silver medium designs, such as Tiffany bedimmed cup lampshades. Aural 1940, Tiffany as able as Accretion relocated through Broadway in acclimation to it's acclaimed beside beyond from 5th Acclimation as able as 57th Road aural New york. The complete appellation Tiffany & Company. is in actuality accompanying to archetypal as able as adequate adequate products. These days, top of Tiffany's accretion arrives via annual as able as online achievement sales, that acquire assisted bear the complete Tiffany casting all over the angel as able as created the complete activate accepting a bit of Tiffany jewellery attainable wherever you reside.
Loading...