[tsvwg] Wanted: recovering IETF process wonk to explain the "Updates:" header

[Bob Briscoe <[e-mail]>]

Spencer,

I searched for " recovering IETF process wonk" and a link to your 
biography was ranked top {Note 1}.

I'm looking for incontrovertible advice on whether I am correct to place 
various long-standing tunnelling RFCs in the updates header of this draft:
https://tools.ietf.org/html/draft-briscoe-tsvwg-rfc6040bis

I believe it cannot be claimed that these RFCs did not already specify 
how to process the ECN field, because it is not possible to encapsulate 
a packet with a new IP header without creating a new ECN field.
Therefore, to my mind, definition of ECN field propagation is an update 
not an optional addition to these RFCs (as I said in response to Mirja 
in tsvwg on Friday).

To be clear about the implications of this decision, if the IESG 
eventually approves rfc6040bis as an RFC, if it states that it updates 
L2TPv3 (for instance), I believe it would mean that an implementation of 
L2TPv3 could no longer claim to comply with the L2TPv3 spec [RFC3931] 
until it had implemented ECN propagation compliant with RFC6040.

Cheers


Bob

PS. Thanks for the advice to state explicitly how the text of each RFC 
could be updated.
Will do.

{Note 1}: I was initially worried that an RFC I co-authored was ranked 
second, but I was relieved to discover that we had used all those words 
in a purely technical context: the RFC talked about packet *process*ing 
and *recovering* keys and C.K. *Wong* was a cited author.

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