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

From: Bob Briscoe <[email-masked]>
Date: Sun, 24 Jul 2016 15:18:06 +0100

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/

---

From: Spencer Dawkins at IETF <[email-masked]>
Date: Mon, 25 Jul 2016 11:57:13 -0500

Hi, Bob,

> https://tools.ietf.org/html/draft-briscoe-tsvwg-rfc6040bis

As a RIPW (my own words, FWIW), I don't think incontrovertible advice
exists for this. A variety of IESGs have had a variety of opinions about
Updates over time, and even with every IESG there's likely a range of
opinions. I am told in another e-mail that the RFC Series Advisory Group
was talking about the definition of Updates (and the even more dreaded
Obsoletes) in Berlin last week, so , this is not an exact science.
But, since you ask me, I'm the responsible AD and I have an opinion.

My opinion is that you can say Updates for RFC FOO if you want everyone who
implements RFC FOO to implement your draft, too. But rather than leave you
with my vague opinion, I'd say that if you Tell The Reader what your draft
is updating in RFC FOO and why, it will be a lot easier for reviewers to
figure out whether the Updates header is legit.

Sometimes that's obvious. Maybe you're correcting something that has
already resulted in an Errata being accepted - RFC FOO says "meat" when it
should have said "potato".

Sometimes it's less obvious, especially when (as I believe the case is
here) RFC FOO didn't say anything about "potato" at all, but anyone
implementing RFC FOO needs to know whether to add potatoes.

So, your explanation, that RFC FOO said "cook dinner" and didn't give all
the details an implementer needs, would be very helpful, no matter what the
Updates header turns out to say.

Does that help?

Thanks,

Spencer

> 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.
> not an optional addition to these RFCs (as I said in response to Mirja in
> tsvwg on Friday).
>
> L2TPv3 could no longer claim to comply with the L2TPv3 spec [RFC3931] until
> it had implemented ECN propagation compliant with RFC6040.
>
> Cheers
>
>
> Bob
>
> 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.
>
> --

---

From: "Black, David" <[email-masked]>
Date: Mon, 25 Jul 2016 21:17:04 +0000

Bob,

As one of your WG chairs, and shepherd for this draft,  I think the important consideration is this (from your email):

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

Getting to the point where such approval  is a good possibility requires (IMHO) significant outreach to the affected WGs & Areas in advance, and a strong rationale for why imposing RFC 6040 compliance is important enough to break compliance of a lot of implementations.  I see no such rationale in your draft (https://tools.ietf.org/html/draft-briscoe-tsvwg-rfc6040bis) - I suggest adding that rationale, starting with a pointer to  Section 5.3 of  RFC 6040, although I don’t think the PCN-based discussion there is likely to provide sufficient motivation.

Thanks, --David

From: tsvwg [mailto:[email-masked]] On Behalf Of Spencer Dawkins at IETF
Sent: Monday, July 25, 2016 12:57 PM
To: Bob Briscoe
Cc: tsvwg IETF list
Subject: Re: [tsvwg] Wanted: recovering IETF process wonk to explain the "Updates:" header

Hi, Bob,

On Sun, Jul 24, 2016 at 9:18 AM, Bob Briscoe <[email-masked]<mailto:[email-masked]>> wrote:
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

As a RIPW (my own words, FWIW), I don't think incontrovertible advice exists for this. A variety of IESGs have had a variety of opinions about Updates over time, and even with every IESG there's likely a range of opinions. I am told in another e-mail that the RFC Series Advisory Group was talking about the definition of Updates (and the even more dreaded Obsoletes) in Berlin last week, so , this is not an exact science. But, since you ask me, I'm the responsible AD and I have an opinion.

My opinion is that you can say Updates for RFC FOO if you want everyone who implements RFC FOO to implement your draft, too. But rather than leave you with my vague opinion, I'd say that if you Tell The Reader what your draft is updating in RFC FOO and why, it will be a lot easier for reviewers to figure out whether the Updates header is legit.

Sometimes that's obvious. Maybe you're correcting something that has already resulted in an Errata being accepted - RFC FOO says "meat" when it should have said "potato".

Sometimes it's less obvious, especially when (as I believe the case is here) RFC FOO didn't say anything about "potato" at all, but anyone implementing RFC FOO needs to know whether to add potatoes.

So, your explanation, that RFC FOO said "cook dinner" and didn't give all the details an implementer needs, would be very helpful, no matter what the Updates header turns out to say.

Does that help?

Thanks,

Spencer

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.

---

From: Bob Briscoe <[email-masked]>
Date: Tue, 26 Jul 2016 09:18:50 +0100

Spencer,

Thanks. Applying this advice to this particular draft confirms (for me 
at least) that we are updating these tunnel RFCs.

Writing the specific text updates for each one is proving to be a useful 
exercise. For instance with L2TPv3, it is specified as a generic 
encapsulation of many different L2 protocols that may in turn 
encapsulate IP or any other L3 protocol. And the outer is also a generic 
packet switched network header, with IP as just one possibility. So 
there isn't really a place that talks about the specific case where the 
outer is IP, and the encapsulated L3 is also IP. Even though that is by 
far the most common case. Whatever, I'm gradually working it all out.

Bob

On 25/07/16 17:57, Spencer Dawkins at IETF wrote:
>     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:
> exists for this. A variety of IESGs have had a variety of opinions 
> about Updates over time, and even with every IESG there's likely a 
> range of opinions. I am told in another e-mail that the RFC Series 
> Advisory Group was talking about the definition of Updates (and the 
> even more dreaded Obsoletes) in Berlin last week, so , this is not an 
> exact science. But, since you ask me, I'm the responsible AD and I 
> have an opinion.
>
> My opinion is that you can say Updates for RFC FOO if you want 
> everyone who implements RFC FOO to implement your draft, too. But 
> rather than leave you with my vague opinion, I'd say that if you Tell 
> The Reader what your draft is updating in RFC FOO and why, it will be 
> a lot easier for reviewers to figure out whether the Updates header is 
> legit.
>
> already resulted in an Errata being accepted - RFC FOO says "meat" 
> when it should have said "potato".
>
> So, your explanation, that RFC FOO said "cook dinner" and didn't give 
> all the details an implementer needs, would be very helpful, no matter 
> what the Updates header turns out to say.
>
> Does that help?
>
> Thanks,
>
> Spencer
>
>     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).
>
>     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
>
>     {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.
>
>     --

---

From: Spencer Dawkins at IETF <[email-masked]>
Date: Tue, 26 Jul 2016 10:23:35 -0500

Hi, Bob,

On Jul 26, 2016 03:18, "Bob Briscoe" <[email-masked]> wrote:
>
> Spencer,
>
> Thanks. Applying this advice to this particular draft confirms (for me at
least) that we are updating these tunnel RFCs.
exercise. For instance with L2TPv3, it is specified as a generic
encapsulation of many different L2 protocols that may in turn encapsulate
IP or any other L3 protocol. And the outer is also a generic packet
switched network header, with IP as just one possibility. So there isn't
really a place that talks about the specific case where the outer is IP,
and the encapsulated L3 is also IP. Even though that is by far the most
common case. Whatever, I'm gradually working it all out.

Excellent. Clarity is good :-)

Spencer

>>> I'm looking for incontrovertible advice on whether I am correct to
place various long-standing tunnelling RFCs in the updates header of this
>>
>> My opinion is that you can say Updates for RFC FOO if you want everyone
who implements RFC FOO to implement your draft, too. But rather than leave
you with my vague opinion, I'd say that if you Tell The Reader what your
draft is updating in RFC FOO and why, it will be a lot easier for reviewers
to figure out whether the Updates header is legit.
>> So, your explanation, that RFC FOO said "cook dinner" and didn't give
all the details an implementer needs, would be very helpful, no matter what
the Updates header turns out to say.
>>> 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.
could be updated.
> -- ________________________________________________________________ Bob
Briscoe http://bobbriscoe.net/