Subject: [PCN] Fwd: [ADs] AUTH48 [MF]: RFC 6040 <draft-ietf-tsvwg-ecn-tunnel-10.txt> NOW AVAILABLE

From: Bob Briscoe <[email-masked]>
Date: Mon, 08 Nov 2010 10:28:31 +0800

PCN folks,

Just to let you know, 
<draft-ietf-tsvwg-ecn-tunnel-10.txt> has been 
through the RFC editor and is awaiting Dave 
Harrington's sign-off. If approved, it would become RFC 6040.

I believe this tunnelling issue held back PCN 
considerably. Even with RFC6040, it would require 
vendors to implement it in order to simplify our PCN encoding choice.

Bob

>Date: Thu, 28 Oct 2010 00:08:46 +0100
>To: Megan Ferguson <[email-masked]>
>From: Bob Briscoe <[email-masked]>
>Subject: Re: [ADs] AUTH48 [MF]: RFC 6040 
><draft-ietf-tsvwg-ecn-tunnel-10.txt> NOW AVAILABLE
>Cc: <[email-masked]>, 
><[email-masked]>, <[email-masked]>
>Bcc: ƒ\In 2009
>
>Megan,
>
>Thanks.
>
>Altho you've already accepted my approval, this 
>is just to confirm I've checked it again, and I approve again.
>
>
>Bob
>
>At 16:04 27/10/2010, Megan Ferguson wrote:
>>Hi Bob and *ADs,
>>
>>Thank you for your reply.  We have updated our 
>>files as requested below.  These updates are viewable at:
>>
>>http://www.rfc-editor.org/authors/rfc6040.xml
>>http://www.rfc-editor.org/authors/rfc6040.txt
>>http://www.rfc-editor.org/authors/rfc6040-lastdiff.html
>>
>>For your convenience, we have posted a diff 
>>file highlighting all changes to date at:
>>
>>http://www.rfc-editor.org/authors/rfc6040-diff.html
>>
>>Please review the document carefully to ensure 
>>satisfaction as we do not make changes once the 
>>document has been published as an RFC.  Note 
>>that it may be necessary for you to refresh 
>>your browser to view the most recent version of the document.
>>
>>Upon careful review, please contact us with any 
>>further updates.  As you indicated your 
>>approval of the text in this form in your 
>>previous message, we have updated your AUTH48 status to "Approved" at:
>>
>>http://www.rfc-editor.org/auth48/rfc6040
>>
>>*ADs,
>>
>>Please review and approve the changes viewable at:
>>
>>http://www.rfc-editor.org/authors/rfc6040-lastdiff.html
>>
>>Thank you.
>>
>>RFC Editor/mf
>>
>>On Oct 26, 2010, at 3:03 PM, Bob Briscoe wrote:
>>
>> > RFC Editor,
>> >
>> > Thank you for this.
>> >
>> > I'm more than happy with everything you have 
>> changed, excepting for one or two that I have 
>> 'improved' in the attached XML. All changes 
>> should be self-explanatory, except in a few 
>> cases where the points below may help justify my changes:
>> >
>> > 1) Abstract & Introduction:
>> > In both cases I prefer
>> >  "previously unused combinations of inner and outer headers" to
>> >  "previously unused combinations of the inner and outer header".
>> > Otherwise the addition of the definite 
>> article changes the sense from "combinations 
>> of various settings of each header" to 
>> "combinations of one particular inner header and one particular outer header."
>> >
>> > 2) I noticed you had changed "cater for an 
>> historic security concern" to "cater to an historic security concern".
>> > This grates to a British ear. For the sense 
>> of "pander to", Collins Dictionary says the 
>> latter is American English, while the former 
>> is British. Given you have allowed the 
>> document spelling to remain in British 
>> English, it would be consistent to use British 
>> wording too. See: <http://bbs.chinadaily.com.cn/viewthread.php?tid=575192>
>> >
>> > 3) On the subject of British vs American, I 
>> notice standardization with a 'z' in the 
>> boilerplate is inconsistent with the British 
>> English 'standardisation' spelling in the body of the document.
>> >
>> > A also noticed a couple of my own errors 
>> while reading through. I assume Gorry, as 
>> shepherd, can verify that these changes are acceptable:
>> >
>> > 4) In early drafts we sometimes used the 
>> word 'inner' ambiguously for  'incoming' (at 
>> ingress) and 'outgoing' (at egress). I 
>> corrected a number of instances where this 
>> ambiguity remained - all but one were in the 
>> appendices that fewer people have reviewed.
>> >
>> > 5) To avoid confusion with the defined terms 
>> outgoing (at egress) and incoming (at ingress) 
>> I changed 'outgoing' (at ingress) and 
>> 'incoming' (at egress) to respectively 'departing' and 'arriving'.
>> >
>> > 6) I corrected 'PCN excess-rate marking' to 
>> 'PCN excess-traffic-marking', which was the term finally agreed on in RFC5670.
>> >
>> >
>> > Thank you.
>> >
>> >
>> > Bob
>> >
>> > At 20:43 25/10/2010, [email-masked] wrote:
>> >
>> >> Bob,
>> >>
>> >> While reviewing this document during 
>> AUTH48, please resolve (as necessary) the 
>> following questions, which are also in the XML file.
>> >>
>> >> 1) <!--[rfced] Please note that after you have approved the document,
>> >> post-xml2rfc changes will be made to update the header and
>> >> boilerplate as described in RFC 5741.
>> >> -->
>> >>
>> >>
>> >> 2) <!--[rfced] Does "Section 5" apply to both RFC 3168 and RFC 4774?
>> >>
>> >> Original:
>> >>   If these defaults do not meet a particular requirement, an alternate
>> >>   ECN tunnelling scheme can be introduced as part of the definition of
>> >>   an alternate congestion marking scheme used by a specific Diffserv
>> >>   PHB (see section 5 of [RFC3168] and [RFC4774]).
>> >>
>> >> If not, perhaps:
>> >>   If these defaults do not meet a particular requirement, an alternate
>> >>   ECN tunnelling scheme can be introduced as part of the definition of
>> >>   an alternate congestion marking scheme used by a specific Diffserv
>> >>   PHB (see RFC 4774 and Section 5 of RFC 3168).
>> >> -->
>> >>
>> >>
>> >> 3) <!-- [rfced] RFC 4306 was obsoleted by RFC 5996.
>> >> How may this text be updated to include mention of RFC 5996?
>> >>
>> >> Current:
>> >>      For instance, IPsec tunnel endpoints compatible with RFC 4301
>> >>      invariably use Internet Key Exchange Protocol version 2 (IKEv2)
>> >>      [RFC4306] for key exchange, which was introduced alongside RFC
>> >>      4301.
>> >>
>> >> Perhaps:
>> >>      For instance, IPsec tunnel endpoints compatible with RFC 4301
>> >>      invariably use Internet Key Exchange Protocol version 2 (IKEv2)
>> >>      [RFC4306] for key exchange, which was introduced alongside RFC
>> >>      4301.  (Note: [RFC4306] has been obsoleted by [RFC5996].)
>> >> -->
>> >>
>> >>
>> >> 4) <!-- [rfced] Please clarify this 
>> sentence, especially "8b per datagram covert channel".
>> >>
>> >> Original:
>> >>   Of course, an
>> >>   administrator considering copying of the DS field has to take into
>> >>   account that it could be concatenated with the ECN field giving an 8b
>> >>   per datagram covert channel.
>> >>
>> >> Perhaps:
>> >>   Of course, an
>> >>   administrator that considers copying the DS field has to take into
>> >>   account that it could be concatenated with the ECN field, giving an
>> >>   eight-bit covert channel for each datagram.
>> >> -->
>> >>
>> >>
>> >> Thank you.
>> >>
>> >> RFC Editor/ah
>> >>
>> >>
>> >> On Oct 25, 2010, at 3:42 PM, [email-masked] wrote:
>> >>
>> >>
>> >> *****IMPORTANT*****
>> >>
>> >> Updated 2010/10/25
>> >>
>> >> RFC Author(s):
>> >> --------------
>> >>
>> >> Instructions for Completing AUTH48 in XML
>> >>
>> >> This is your last chance to make changes to your RFC-to-be:
>> >> draft-ietf-tsvwg-ecn-tunnel-10.txt.
>> >> Once the document is published as an RFC, we will not make changes.
>> >> Please follow the instructions below to complete the AUTH48 process.
>> >>
>> >> 1) Review the edited document completely.  The files are available here:
>> >>
>> >>  http://www.rfc-editor.org/authors/rfc6040.txt
>> >>  http://www.rfc-editor.org/authors/rfc6040-diff.html
>> >>
>> >>  We recommend reviewing the entire document, not just the diff file.
>> >>  The placement of page breaks will be handled during the final stages of
>> >>  publication (typically post-xml2rfc processing).
>> >>
>> >> 2) Review and resolve (as necessary) any questions raised by the RFC
>> >>  Editor.  The questions (if any) have been included in the XML file as
>> >>  comments marked <!-- [rfced] ... --> and 
>> will be sent in a subsequent email.
>> >>
>> >>  Retrieve the edited XML file here:
>> >>
>> >>     http://www.rfc-editor.org/authors/rfc6040.xml
>> >>
>> >>  (Note that you may need to view the page source to save the file.)
>> >>
>> >> 3) Send us your changes or respond with your approval for publication.
>> >>  Please use 'Reply All' so that [email-masked] and the parties
>> >>  CC'ed on this message receive your 
>> response. Note that your document will
>> >>  not move forward until we have received approvals from each of the
>> >>  authors listed on the front page.
>> >>
>> >>  If sending changes, please do one of the following:
>> >>
>> >>  a. Update the provided XML file, then email us the revised XML file.
>> >>     You may use any filename for the revised file; we will rename it
>> >>     before posting it.
>> >>
>> >>  --OR--
>> >>
>> >>  b. Provide us with an explicit list of changes in the this format.
>> >>
>> >>     Section # (or indicate Global)
>> >>
>> >>     OLD:
>> >>     old text
>> >>
>> >>     NEW:
>> >>     new text
>> >>
>> >>  Be sure to pay particular attention to these areas of the document:
>> >>  - IANA Considerations updates (if applicable)
>> >>  - Contact information
>> >>  - Copyright notice and legends (see item 5 for more details)
>> >>
>> >> 4) Review changes submitted by your coauthors.  We assume that you
>> >>  will speak up if you do not agree with the proposed changes. That is,
>> >>  your silence is your assent to changes submitted by your coauthors.
>> >>  Note that any changes that are beyond editorial will be sent to the
>> >>  relevant body for approval.
>> >>
>> >>  Additional diff files will be posted as authors send updates for the
>> >>  document.  We recommend viewing these  later diff files to identify and
>> >>  review changes submitted by your coauthors.
>> >>
>> >> 5) Review the copyright notice and legends as defined in RFC 5378 and
>> >>  the Trust Legal Provisions (TLP -- 
>> http://trustee.ietf.org/license-info/).
>> >>
>> >>  If your document was approved for publication with a pre-RFC-5378
>> >>  copyright notice, we have applied the text from section 6.c.iii of the
>> >>  TLP.  Please consider whether this text is required (note that the
>> >>  6.c.iii text is not applicable to Independent Stream RFCs).  See item
>> >>  4.5 of the "Copyright FAQ" at http://trustee.ietf.org/faqs.html for
>> >>  guidance on whether this text applies to your document.
>> >>
>> >> 6) Please reply, as the document will not be published until we receive
>> >>  approvals from each author.  The details of the AUTH48 status of your
>> >>  document are here:
>> >>
>> >>  http://www.rfc-editor.org/auth48/rfc6040
>> >>
>> >> Thank you for your cooperation,
>> >>
>> >> RFC Editor
>> >>
>> >> --------------------------------------
>> >> RFC6040 (draft-ietf-tsvwg-ecn-tunnel-10)
>> >> --------------------------------------
>> >> Title            : Tunnelling of Explicit Congestion Notification
>> >> Author(s)        : B. Briscoe
>> >> WG Chair(s)      : James Polk, Gorry Fairhurst
>> >> Area Director(s) : David Harrington, Lars Eggert
>> >
>> > ________________________________________________________________
>> > Bob 
>> Briscoe,                                BT Innovate & Design <rfc6040_b.xml>
>
>________________________________________________________________
>Bob Briscoe,                                BT Innovate & Design

________________________________________________________________
Bob Briscoe,                                BT Innovate & Design

---

From: "Toby Moncaster" <[email-masked]>
Date: Mon, 8 Nov 2010 09:46:31 -0000

Brilliant! Well done Bob... Not only will this make life much easier for PCN
(as it makes 3-in-1 the obvious encoding choice), it will also be pretty
useful generally since it retrieves (or allows additional use of) a valuable
bit of header space in IP...

Toby

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Bob Briscoe
> Sent: 08 November 2010 02:29
> To: PCN IETF list
> Subject: [PCN] Fwd: [ADs] AUTH48 [MF]: RFC 6040 <draft-ietf-tsvwg-ecn-
> tunnel-10.txt> NOW AVAILABLE
> 
> PCN folks,
> 
> Just to let you know,
> >> wording too. See:
> <http://bbs.chinadaily.com.cn/viewthread.php?tid=575192>
> >> >
> _______________________________________________
> PCN mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/pcn