Subject: [Tsvwg] IETF process concerning missed RFC dependencies?

From: Bob Briscoe <[email-masked]>
Date: Mon, 11 Jun 2007 19:54:40 +0100

Magnus, Lars,

I'm preparing an initial I-D to tidy up the contradictions between 
different RFCs concerning ECN tunnelling (I mentioned I planned to do this 
some time ago on the list).

My question: If an RFC has been published in the past that updates another 
RFC, but the dependency wasn't noticed at the time, can the dependency 
'just' be added to the RFC index?

Specifically, the question is about RFC4301 (IPsec architecture) which 
updates RFC3168 (ECN) but the RFC Index doesn't flag this. Unfortunately 
the new IPsec architecture referenced ECN as only informative, even though 
it updated it.

This is also a cross-area question - if the cross-area dependency had been 
identified at the time, should the transport area have been consulted about 
the change to ECN? (which it might have been? tho I can't find any evidence 
from a careful search) And if it wasn't consulted what happens?

It's actually more complicated because RFC4301 hasn't been written so that 
it is clear exactly which parts of RFC3168 it updates and which it doesn't. 
But that's the rats' nest that my proposed I-D is designed to unpick. So 
let's leave aside that question for now.

BTW, I'm not trying point the finger - we're all trying to do the best we 
can - these things happen.

Bob

____________________________________________________________________________
Notice: This contribution is the personal view of the author and does not 
necessarily reflect the technical nor commercial direction of BT plc.
____________________________________________________________________________
Bob Briscoe,                           Networks Research Centre, BT Research
B54/77 Adastral Park,Martlesham Heath,Ipswich,IP5 3RE,UK.    +44 1473 645196

---

From: Lars Eggert <[email-masked]>
Date: Tue, 12 Jun 2007 16:55:06 +0300

Hi,

On 2007-6-11, at 21:54, ext Bob Briscoe wrote:
> different RFCs concerning ECN tunnelling (I mentioned I planned to  
> do this some time ago on the list).
>
> My question: If an RFC has been published in the past that updates  
> another RFC, but the dependency wasn't noticed at the time, can the  
> dependency 'just' be added to the RFC index?

I don't think so. That information is simply extracted out of the  
"Updates" or "Obsoletes" header in the RFC itself. So you'd need to  
change the content of the RFC itself to change this data, which  
typically means a revision.

(Hm, I wonder if this could be done with an errata? Not clear. But an  
errata of this magnitude would need some consensus. IMO this is not  
something that the RFC Editor can just do on its own.)

Another way forward would be a new RFC that updates both RFC4301 and  
RFC3168 and contains the corrections. That will flag both of these  
RFCs with an "updated by" in the database and on the RFC Editor web  
page (but unfortunately not in the published RFC text).

> Specifically, the question is about RFC4301 (IPsec architecture)  
> which updates RFC3168 (ECN) but the RFC Index doesn't flag this.  
> Unfortunately the new IPsec architecture referenced ECN as only  
> informative, even though it updated it.
>
> This is also a cross-area question - if the cross-area dependency  
> had been identified at the time, should the transport area have  
> been consulted about the change to ECN? (which it might have been?  
> tho I can't find any evidence from a careful search) And if it  
> wasn't consulted what happens?

Yes, TSV should have been consulted.

> It's actually more complicated because RFC4301 hasn't been written  
> so that it is clear exactly which parts of RFC3168 it updates and  
> which it doesn't. But that's the rats' nest that my proposed I-D is  
> designed to unpick. So let's leave aside that question for now.

A TSV review would have probably caught that.

> BTW, I'm not trying point the finger - we're all trying to do the  
> best we can - these things happen.

Understood, and it is never too late to correct past mistakes.

Lars

---

From: Bob Briscoe <[email-masked]>
Date: Tue, 12 Jun 2007 17:03:20 +0100

Lars,

>typically means a revision.

I assume (by parsing your para below as well), when you say "Updates" or 
"Obsoletes" headers in the RFC itself, you don't mean in the visible 
published RFC text, but in the RFC database.

>page (but unfortunately not in the published RFC text).

Tx for clarification.

I've now done a 'quick' I-D to update both which I'm getting reviewed 
before posting.

By 'quick' I mean I've tried to write it in such a way that it doesn't 
raise any new security concerns or backward compatibility issues. Given it 
updates IPsec and ECN that's a tough call! I may be wrong and quick may 
turn into slow. But so far it doesn't update any security feature of IPsec, 
it just points out exceptions to the new ECN processing rules they set, 
which they hadn't noticed. However, it does materially update RFC3168 
(given IPsec now contradicts it, something had to move).

Bob

____________________________________________________________________________
Bob Briscoe, <[email-masked]>      Networks Research Centre, BT Research
B54/77 Adastral Park,Martlesham Heath,Ipswich,IP5 3RE,UK.    +44 1473 645196

---

From: Bob Braden <[email-masked]>
Date: Tue, 12 Jun 2007 09:23:00 -0700

>typically means a revision.

Actually, the information in the RFC index is NOT extracted from the RFC 
headers,
it is maintained separately.  In the case of "obsoleted by", for example, the
information can ONLY be in the index, since published RFCs are never
changed.

The intent is to keep the most current and correct information in the
index, so the answer to the question is "yes", a dependency noted
later can and should be added to the index.  Just send email to
the RFC Editor.

And yes, there could also be an erratum, since it is in effect a later
correction to a published RFC.

>Understood, and it is never too late to correct past mistakes.

Amen.

Bob Braden

---

From: Bob Briscoe <[email-masked]>
Date: Tue, 12 Jun 2007 18:17:04 +0100

Bob,

At 17:23 12/06/2007, Bob Braden wrote:
>>>Bob Briscoe:

That's useful to know.

It will possibly complicate matters even further to just baldly say RFC4301 
(IPsec) updates RFC3168 (ECN), as RFC4301 doesn't clarify what bits of 
RFC3168 it updates and what it doesn't.

So, rather than emailing the RFC Editor to say this right now, I'll post 
the I-D describing the contradiction between the two RFCs first, then we 
can have a discussion on the list about what to do, and also in Chicago.

However, we could certainly tell the RFC Editor that both RFC3168 and 
RFC4301 update RFC2003 (IP in IP tunneling), a dependency which I also 
noticed isn't identified in the RFC Index. Anyone see any objection to that?

Two Bob