Subject: RE: Question about Obsoleted vs. Historic

From: [email-masked]
Date: Mon, 11 Jul 2005 13:22:44 +0300

Nick,

> The way I understand it, an RFC is only historic(al) if the technology it
> defines is no longer in use.

Well, as Iljitsch mail pointed out, some things (3152 Delegation of IP6.ARPA)
are moved to Historic when the IETF wants people to stop using them ...'

> An obsolete RFC means the technology is still being used, but some part of
> the specification (obsolete RFC) has been updated.  An obsolete RFC can
> still be a standard as the RFC that obsoletes it may not change the protocol
> at all.  One example of this is RFC 3912 which is the RFC that obsoletes
> your example (RFC 954) - read 3192's abstract for more detail.
> 
> This is of course only my understanding.

If only part has been updated, then the RFC doing the update should say 'Updates
RFC xyz', I think ...

John

_______________________________________________
Ietf mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ietf

---

From: "Nicholas Staff" <[email-masked]>
Date: Mon, 11 Jul 2005 04:38:43 -0700

John,
 
> > The way I understand it, an RFC is only historic(al) if the 
> technology 
> > it defines is no longer in use.
> 
> Well, as Iljitsch mail pointed out, some things (3152 
> Delegation of IP6.ARPA) are moved to Historic when the IETF 
> wants people to stop using them ...'

I think his email read "(Obsoleted by RFC3596)" not historic,  which I
confirmed at the rfc-editor site.  I have read several RFC's that requested
historic status for other rfc's and the primary reason given every time was
that the technology was no longer in use.  See RFC 1360 section 4.1.6. for a
definition of historic.
 
> > An obsolete RFC means the technology is still being used, but some 
> > part of the specification (obsolete RFC) has been updated.  An 
> > obsolete RFC can still be a standard as the RFC that 
> obsoletes it may 
> > not change the protocol at all.  One example of this is RFC 
> 3912 which 
> > is the RFC that obsoletes your example (RFC 954) - read 
> 3192's abstract for more detail.
> > 
> If only part has been updated, then the RFC doing the update 
> should say 'Updates RFC xyz', I think ...

But that's what it means to be obsolete - that you've been updated.  It
doesn't mean broken or wrong, it means older version - so the RFC's are
already doing what you suggest because "obsoleted by RFC 808" is the same as
"updated by RFC 808".

Nick

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Mon, 11 Jul 2005 21:56:56 +0200

On 11-jul-2005, at 12:22, [email-masked] wrote:

>> technology it

> are moved to Historic when the IETF wants people to stop using  

For the record:

RFC 3152 basically just says "we now use ip6.arpa rather than ip6.int  
for IPv6 reverse DNS" and points to RFC 2874.

RFC 2874 wants us to use bit labels for the reverse DNS (which is  
very cool but unfortunately isn't backward compatible and requires  
not just a new resource record but a partial rewrite of the software  
used in pretty much all DNS servers). RFC 2874 is "experimental" but  
that's just pretense, as there aren't currently, nor have there ever  
been any bitlabel delegations under ip6.arpa, as far as my research  
has been able to uncover.

(RFC 1886 specified the "nibble" format with ip6.int, which looks  
like d.e.a.d.b.e.a.f.1.0.0.2.ip6.int.)

So RFC 3152 was never "practice", the alleged practice isn't  
"current", and I'll refrain from commenting on "best".

RFC 3596 ("draft standard") finally cleans the whole mess up for the  
most part by saying in so many words that people should use the  
nibble method with ip6.arpa for the IPv6 reverse DNS, but  
unfortunately it claims that RFC 3152 was mainly about s/ip6.int/ 
ip6.arpa/g, ignoring the whole bitlabel/nibble thing.