Re: [tsvwg] Process for re-assignment of NS TCP header flag to AccECN

[Bob Briscoe <[e-mail]>]

Michael,

Actually I had first typed "accepted practice", but realized this would 
probably attract argument, so I changed it to "typical practice".
BTW, I think this is completely understandable - one would expect a high 
bar for standards track changes to TCP, esp. changes to the wire protocol.
My point was that, perversely, an "IETF Review" registry policy ought to 
be more characteristic of a protocol that is critical to the Internet, 
like TCP.

Data points about the RFCs on https://tools.ietf.org/wg/tcpm/

11 	INF
1 	BCP
10 	EXP
12 	PS
1 	DS


Of the 12 PSs,
  6 obsolete previous RFCs,
  2 update previous RFCs,
  4 were new (not based on a previous RFC)

None of the 4 new ones update the TCP wire protocol:
  1 was a new TCP option,
  1 was about numbering TCP options
  1 was a crypto algorithm
  1 (RFC5691) was essentially an update to RFC793, but did not formally 
update it



Bob

On 04/07/17 09:23, Scharf, Michael (Nokia - DE/Stuttgart) wrote:
>
> A comment on this statement: “It has become typical practice for the 
> TCP maintenance working group to expect any change to TCP to be 
> documented as an experimental RFC and for the experiment to be 
> deployed and proved in practice before committing technology to the 
> standards track.”
>
>
> TCPM decides on the status of documents case-by-case, by working group 
> consensus.
>
> Nothing prevents TCPM from publishing documents on standards track. 
> The requirements in RFC 2026 Section 4.1.1 may be a bit harder to meet 
> for TCP extensions and algorithms, compared to other IETF protocols, 
> given the wide deployment of TCP in very different environments. And, 
> indeed, the TCPM community consensus for some recent documents was to 
> publish work (first) as experimental. These decisions have always been 
> pretty unanimous, as far as I recall. But clearly if the community 
> consensus is standards track, TCPM will submit documents on standards 
> track…
>
> Michael
>
> *From:*Bob Briscoe [mailto:[e-mail]]
> *Sent:* Monday, July 03, 2017 11:04 PM
> *To:* C. M. Heard <[e-mail]>
> *Cc:* tcpm <[e-mail]>; tcpm-chairs <[e-mail]>; tsvwg 
> <[e-mail]>; tsvwg-chairs <[e-mail]>; tsv-ads 
> <[e-mail]>
> *Subject:* Re: Process for re-assignment of NS TCP header flag to AccECN
>
> Mike,
>
> It may not be so straightforward.
> * It is relatively easy to justify changing the policy for the flag 
> that is released by making the Nonce historic, which 
> ecn-experimentation is already giving rationale for.
> * Strictly it would require text to justify changing the registry 
> policy for the other 2 flags that are still assigned to RFC3168 on the 
> standards track.
>
> This is actually a symptom of a larger problem with the registry for 
> these flags. The registry assigns bits to single RFCs as individual 
> binary flags, but they are not being used like this. AccECN used 
> combinations of the ECN flags and states of the TCP state-machine that 
> had not yet been used together, in order to increase the available 
> state space. RFC 3168 and RFC3540 also did this, and I'm sure people 
> can think of many other TCP-based protocols that have done this.
>
> However, we still imagine that individual flags are assigned to 
> individual RFCs. Option (e) reinforces this delusion, whereas option 
> (f) challenges it. Hence option (e) 'feels' more acceptable, as long 
> as you screw up your eyes and avoid thinking too much.
>
>
>
> I doubt anyone wants to "go there" right now. But here's text that 
> could be used in "an RFC" (TBA) to change the whole TCP flags registry 
> policy to reflect what is actually happening in practice:
>
> option (g)
>
>     It has become typical practice for the TCP maintenance working
>     group to expect any change to TCP to be documented as an
>     experimental RFC and for the experiment to be deployed and proved
>     in practice before committing technology to the standards track.
>
>     RFC3168 assigned the CWR and ECE flags for its own use as single
>     bits and RFC3540 assigned the NS flag for its own use as another
>     single bit. However, during TCP's  handshake both these RFCs use
>     combinations of these bits as codepoints, not independent binary
>     flags. RFC3168 and RFC3540 also give these bits different meanings
>     when used after the handshake. So these three bits are effectively
>     being used in combination with the SYN and ACK flags to increase
>     the available state space in novel ways. Assigning TCP header
>     flags as individual bits wastes all the combinations that these
>     two RFCs and other existing RFCs do not use.
>
>     The present document [ecn-experimentation] recognizes that
>     * assigning TCP flags individually and exclusively to standards
>     track RFCs is no longer typical practice;
>     * the TCP flags are actually being used in novel ways that are not
>     amenable to simple registration by IANA;
>     * current innovation in this space is in spite of the "standards
>     action" registry policy rather than because of it.
>
>     Therefore the registry policy as a whole is changed to "IETF Review".
>
>
>
>
> Bob
>
> On 03/07/17 19:17, C. M. Heard wrote:
>
>     Bob,
>
>     I think that your option (f) is better than option (e) (what I
>     suggested). As an aside, either one patches up an apparent process
>     violation committed by RFC 3540, an experimental RFC that assigned
>     bit 7 in contradiction to the policy in RFC 2780.
>
>     Mike Heard
>
>     On Mon, Jul 3, 2017 at 11:05 AM, Bob Briscoe <[e-mail]
>     <mailto:[e-mail]>> wrote:
>
>         Mike,
>
>         Let's call this option:
>         (e) ecn-experimentation alters the registry policy of bit 7 of
>         the TCP header to "IETF Review".
>
>         Having a different policy for certain bits within a registry
>         might send IANA into a spin, but I am sure they could write
>         suitable text into the registry policy if they had to.
>
>         I quite like this one. Altho unorthodox, it's neat.
>
>
>         Thank you.
>
>
>         Bob
>
>         PS. Strictly RFC3168 used the CWR and ECE flags (bits 8 & 9)
>         as a 2-bit field during the 3-way hand-shake. While the ECN
>         Nonce and AccECN use the three ECN flags (bits 7-9) as a 3-bit
>         field during the 3WHS. AccECN uses the combinations that
>         RFC3168 and the Nonce do not use. So to cover all bases:
>
>         Option (f): ecn-experimentation alters the registry policy for
>         bits 7-9 to "IETF Review".
>
>         On 03/07/17 18:14, C. M. Heard wrote:
>
>             Bob,
>
>             Couldn't the text in the IANA considerations of
>             ecn-experimentation (which needs to be updated in any
>             case) both change the NS flag to Reserved for ECN
>             Experimentation and change the allocation policy for that
>             flag from Standards Action to IETF Review, thereby
>             updating RFC 2780? That would avoid the churn needed to
>             add motivating text for a 4th experiment to
>             ecn-experimentation and would allow AccECN to assign the
>             NS bit itself without a process exception.
>
>             Mike Heard
>
>             On Mon, 3 Jul 2017 10:28:25 +0100, Bob Briscoe wrote:
>
>                 Michael*2, Yoshifumi, Gorry, David, Wes, Mirja,
>                 Spencer, tcpm list, tsvwg list,
>
>                 There has been some offlist discussion (among
>                 different sub-groups) to narrow down the options here.
>                 It is time to see opinions from the two affected WGs
>                 (tcpm and tsvwg) on preferred process, esp. from the
>                 WG chairs and ADs.
>
>                 *==Background to the Process Problem==
>                 *
>                 In tsvwg the process is in motion to make the ECN
>                 nonce [RFC 3540] historic. So, in the most recent rev
>                 of draft-ietf-tcpm-accurate-ecn-03 , we could finally
>                 include IANA assignment of the NS flag
>                     (see
>                 https://tools.ietf.org/html/draft-ietf-tcpm-accurate-ecn-03#section-6 )
>
>                 However, AccECN is EXPerimental, whereas the registry
>                 policy for assigning TCP flags is "Standards Action"
>                 https://www.iana.org/assignments/tcp-header-flags/tcp-header-flags.xhtml
>                 which means "Values are assigned only for Standards
>                 Track RFCs approved by the IESG" [RFC2434].
>
>                 References:
>                     Process for designating RFCs as historic:
>                 https://www.ietf.org/iesg/statement/designating-rfcs-as-historic.html
>                     Current draft text to make RFC 3540 historic:
>                 https://tools.ietf.org/html/draft-ietf-tsvwg-ecn-experimentation-03#section-3
>                     My initial draft for the AD's status change note:
>                 https://github.com/bbriscoe/ecn-experimentation/blob/master/status-change-ecn-nonce-rfc3540-to-historic-00.txt
>
>                 ecn-experimentation has just completed WGLC. It still
>                 has to go through IETF LC (after Prague). it is
>                 deliberately PS in order to be able to relax
>                 pre-existing constraints on ECN experiments in
>                 standards track RFCs. However, if poss, we want to
>                 avoid adding motivating text for a 4th experiment,
>                 which could require another cycle of WGLC and delay
>                 until Nov.
>
>                 RFC 3692 ("Assigning Experimental and Testing Numbers
>                 Considered Useful") could also be relevant, although
>                 it doesn't seem to help here, because it is primarily
>                 aimed at larger codepoint spaces, not single bits.
>
>
>                 *==Process Options==
>                 *
>                 There need to be two parts to the process: 1)
>                 unassignment and 2) reassignment. The first seems
>                 clear-cut. The second is less obvious.
>
>                 1) Unassigning the NS flag from RFC 3540
>                 a) add text to IANA considerations section of
>                 ecn-experientation making the NS flag reserved
>
>                 2) Assigning the NS flag to accurate-ecn (and renaming
>                 it the AE flag).
>                 Process options:
>                 a) ecn-experimentation assigns flag to itself as
>                 reserved for experiments and says initially the AccECN
>                 experiment will use it exclusively
>                 b) ecn-experimentation assigns NS flag exclusively to
>                 AccECN
>                 c) AccECN assigns NS flag to itself, with a process
>                 exception proposed to the IESG to allow an EXP doc to
>                 assign to a Standards Action registry
>                 d) the NS flag is reassigned by "AD review comment" or
>                 "IETF Last Call comment" (quoted from David's suggestions)
>                 e) other?...
>
>                 The difference between (a) and (b) is in the document
>                 that ends up being referenced from the IANA registry:
>                 a)  ecn-experimentation
>                 b) accurate-ecn
>
>                 *==My own preferences==
>                 *
>                 During discussions, I didn't prefer (c) cos I thought
>                 the IESG might question why they are being asked to
>                 make a process exception for an ECN experiment at the
>                 same time as a draft is going through that avoids
>                 raising process exceptions for ECN experiments.
>
>                 Nonetheless, since then, Mirja has said...
>
>                 On 02/07/17 23:40, Mirja Kühlewind wrote:
>
>                     I actually prefer option (c). I don’t think a process exception is a bad thing. If it’s the right thing to do, then that the reason why we have such exceptions. Also I think it’d be the right thing to change the registry policy… but that probably a longer story.
>
>                 I agree that it is outdated that the registry requires
>                 a standards action, because it has become normal tcpm
>                 practice for any change to TCP to have to start on the
>                 experimental track. So this would justify a process
>                 exception.
>
>                 So, in summary, I don't mind (a), (b) or (c). I think
>                 (d) is not sufficiently open and recorded for
>                 assignment of a flag in the main TCP header.
>
>
>                 Bob
>
>         -- 
>
>         ________________________________________________________________
>
>         Bob Briscoe http://bobbriscoe.net/
>
>
>
> -- 
> ________________________________________________________________
> Bob Briscoehttp://bobbriscoe.net/

-- 
________________________________________________________________
Bob Briscoe                               http://bobbriscoe.net/