Subject: Re: [tsvwg] I-D Action:draft-ietf-tsvwg-ecn-tunnel-05.txt

From: "James M. Polk" <[email-masked]>
Date: Mon, 04 Jan 2010 13:15:51 -0600

Bob

Consider this:

- "reserved" or "reserved for future use" normally (but not 100% of 
the time) means that a specification needs to be written before any 
use of these bits or values are allowed.

Presumably, in this case, this spec would be offered into TSVWG for 
review and feedback - giving this WG (if it still exists then) the 
chance to comment on any future values to be used (to see if they 
make sense or not).

CU might mean these values are up for grabs by anyone, or are free to 
use -- meaning they may leak into the Internet and may become a 
defacto for something TSVWG or the IETF would necessarily believe is best.

What do you think about this?

James
<WG chair hat on>

At 05:40 PM 12/29/2009, Bob Briscoe wrote:
>Tom,
>
>IETF use "reserved for future use" too (eg. see RFC2474). It 
>generally means the same as Currently Unused.
>
>I prefer CU in this particular case, as we are talking about 
>combinations of codepoints in different headers. So, as such, we're 
>not really reserving the combinations for future use, they just 
>don't happen to be arise in practice, because of the way protocols 
>work at the moment.
>
>Cheers
>
>
>Bob
>
>At 09:19 24/12/2009, tom.petch wrote:
>
>>----- Original Message -----
>>From: "Bob Briscoe" <[email-masked]>
>>To: <[email-masked]>
>>Cc: <[email-masked]>; <[email-masked]>; <[email-masked]>
>>Sent: Monday, December 21, 2009 12:42 AM
>>Subject: Re: [tsvwg] I-D Action:draft-ietf-tsvwg-ecn-tunnel-05.txt
>>
>>
>> > David,
>> >
>> > Thanks for your quick response. And indeed for your patience on 
>> this issue.
>> >
>> > Having reached consensus, I'm now going to be a perfectionist and
>> > change the text you are happy with... hopefully you won't object...
>> >
>> > On reflection, I would prefer to use the phrase 'currently unused'
>> > rather than 'invalid' for combinations that shouldn't arise from any
>> > combination of RFCs so far defined. This is more precise IETF
>> > language, because CU implies the combination could become valid in future.
>>
>>Probably too late for this one, but if this were to arise in future, I would
>>suggest
>>'reserved'
>>or
>>'reserved for future use'
>>an idea shamelessly borrowed from another standards body which
>>defines this as something to be ignored for now but which may take on
>>significance later.
>>
>>Tom Petch
>>
>>
>> > I've also re-read the -05 draft I just posted and noticed some minor
>> > errors. I am about to post a corrected -06 draft. I will change
>> > 'invalid' to 'currently unused' in the expectation that you will 
>> not object.
>> >
>> > Cheers
>> >
>> >
>> > Bob
>> >
>> > At 04:09 19/12/2009, [email-masked] wrote:
>> > >Bob,
>> > >
>> > >I think this is acceptable.  We are in agreement on the data
>> > >path treatment of the bits.  Beyond that, the "MAY" requirement
>> > >for raising alarms plus the accompanying discussion of operator
>> > >discretion seem reasonable to me.  I appreciate your patience
>> > >with the time it's taken to work through these concerns.
>> > >
>> > >Thanks,
>> > >--David
>> > >
>> > >
>> > > > -----Original Message-----
>> > > > From: Bob Briscoe [mailto:[email-masked]]
>> > > > Sent: Friday, December 18, 2009 1:12 PM
>> > > > To: Gorry Fairhurst; Black, David
>> > > > Cc: [email-masked]
>> > > > Subject: Re: [tsvwg] I-D Action:draft-ietf-tsvwg-ecn-tunnel-05.txt
>> > > >
>> > > > David, Pls see whether the alarms aspects are acceptable. You will
>> > > > also see all the other functional amendments we agreed.
>> > > >
>> > > > Gorry, I've dealt with all your editorial review comments as
>> > > > requested - thanks - they are good improvements - hope you like them.
>> > > > I cut down the two appendices you requested, but I don't want to cut
>> > > > them down further until after Security Directorate review - they were
>> > > > mainly in there to allow the Security guys to understand the subset
>> > > > of motivations for this draft related to PCN without having to go
>> > > > read all the PCN stuff.
>> > > >
>> > > > There's still a couple of people who volunteered to review this
>> > > > earlier on the hook. I can supply names :)
>> > > >
>> > > > Once David is happy, I feel this is ready for WGLC. You might want to
>> > > > do Security Directorate review in parallel? Up to you.
>> > > >
>> > > >
>> > > > Cheers
>> > > >
>> > > > Have a relaxing holdiay season everyone (assuming you can)!
>> > > >
>> > > >
>> > > >
>> > > > Bob
>> > > >
>> > > >
>> > > > At 16:15 18/12/2009, [email-masked] wrote:
>> > > > >A New Internet-Draft is available from the on-line Internet-Drafts
>> > > > >directories.
>> > > > >This draft is a work item of the Transport Area Working Group
>> > > > >Working Group of the IETF.
>> > > > >
>> > > > >
>> > > > >         Title           : Tunnelling of Explicit Congestion
>> > >Notification
>> > > > >         Author(s)       : B. Briscoe
>> > > > >         Filename        : draft-ietf-tsvwg-ecn-tunnel-05.txt
>> > > > >         Pages           : 41
>> > > > >         Date            : 2009-12-18
>> > > > >
>> > > > >This document redefines how the explicit congestion notification
>> > > > >(ECN) field of the IP header should be constructed on entry to and
>> > > > >exit from any IP in IP tunnel.  On encapsulation it updates RFC3168
>> > > > >to bring all IP in IP tunnels (v4 or v6) into line with RFC4301 IPsec
>> > > > >ECN processing.  On decapsulation it updates both RFC3168 and RFC4301
>> > > > >to add new behaviours for previously unused combinations of inner and
>> > > > >outer header.  The new rules ensure the ECN field is correctly
>> > > > >propagated across a tunnel whether it is used to signal one or two
>> > > > >severity levels of congestion, whereas before only one severity level
>> > > > >was supported.  Tunnel endpoints can be updated in any order without
>> > > > >affecting pre-existing uses of the ECN field (backward compatible).
>> > > > >Nonetheless, operators wanting to support two severity levels (e.g.
>> > > > >for pre-congestion notification--PCN) can require compliance with
>> > > > >this new specification.  A thorough analysis of the reasoning for
>> > > > >these changes and the implications is included.  In the unlikely
>> > > > >event that the new rules do not meet a specific need, RFC4774 gives
>> > > > >guidance on designing alternate ECN semantics and this document
>> > > > >extends that to include tunnelling issues.
>> > > > >
>> > > > >
>> > > > >A URL for this Internet-Draft is:
>> > > >
>> > > >http://www.ietf.org/internet-drafts/draft-ietf-tsvwg-ecn-tunnel-05.txt
>> > > > >
>> > > > >Internet-Drafts are also available by anonymous FTP at:
>> > > > >ftp://ftp.ietf.org/internet-drafts/
>> > > > >
>> > > > >Below is the data which will enable a MIME compliant mail reader
>> > > > >implementation to automatically retrieve the ASCII version of the
>> > > > >Internet-Draft.
>> > > > >
>> > > > >
>> > > >
>> > > ><ftp://ftp.ietf.org/internet-drafts/draft-ietf-tsvwg-ecn-tunnel-05.txt>
>> > > >
>> > > > ________________________________________________________________
>> > > > Bob Briscoe,                                BT Innovate & Design
>> > > >
>> >
>> > ________________________________________________________________
>> > Bob Briscoe,                                BT Innovate & Design
>> >
>
>________________________________________________________________
>Bob Briscoe,                                BT Innovate & Design

---

From: Bob Briscoe <[email-masked]>
Date: Tue, 05 Jan 2010 12:11:10 +0000

James,

I /thought/ I agreed with that, based on an intuition for the subtle 
distinction between the English meaning of the words. Indeed 
orginally I started to write a reply to Tom saying that... However, 
before I posted it to the list, I did a search of RFCs for the two 
phrases, and the first one I looked at (RFC2474 Diffserv) used the 
two interchangeably. And the second one (RFC3168 ECN) pointed to a 
number of other RFCs that use CU to describe a MBZ (must be zero) 
field reserved for future use. So I scrubbed the text I was going to send :|

But you're probably right. We ought to distinguish between the two in 
the way you describe, but we don't 100% of the time.

Another example going through tsvwg now: <draft-manner-tsvwg-gut-00> 
contains the phrase "The 24-bit reserved field is currently unused".

Would there be an IETF doc anywhere that defines these phrases? I 
can't find one.

Returning to the doc in hand (ecn-tunnel), CU seems the most 
appropriate even based on your distinction, because it's being used 
to describe a combination of two fields, both of which are already in 
use separately, but the combination doesn't happen to be possible 
given the current behaviour of protocols in the RFC series.

Cheers

Bob

At 19:15 04/01/2010, James M. Polk wrote:
>CU might mean these values are up for grabs by anyone, or are free 
>to use -- meaning they may leak into the Internet and may become a 
>>> > 'invalid' to 'currently unused' in the expectation that you 
>>> will not object.
>>> >
>>> > Cheers
>>> >
>>> >
>>> > Bob
>>> >