RE: AD review of draft-ietf-hubmib-mau-mib-v3-02.txt

OK, what I got back when talking to IESG (Specifically 
Scott, since he is our process guru) is that in fact
Obsoleted and Historic are equivalent.

When a document obsoletes and earlier one, then that is 
effectively the same as making old one historic. The doc
normally just keeps the tag obsoleted.

When an old doc needs to be obsoleted, but we have no new 
document that actually replaces (obsoletes) such a doc, 
then we typically write a informational RFC in which we 
document and recommend why to make the old document historic.

So it seems that we do not need to make 2668 and such Historic.
What would be our motivation to do so?

Thanks,
Bert 

> -----Original Message-----
> From: Romascanu, Dan (Dan) [mailto:[email protected]]
> Sent: zondag 17 november 2002 19:07
> To: Wijnen, Bert (Bert); John Flick (E-mail)
> Cc: Hubmib Mailing List (E-mail)
> Subject: RE: [Hubmib] AD review of draft-ietf-hubmib-mau-mib-v3-02.txt
> 
> 
> > 
> > - Sect 3.1 claims/states that rfc2668 will go to historic.
> >   Well, you can recommend that in this document, but the WG cannot
> >   just declare it. Maybe it is best to write a small doc that
> >   recommends this action, similar to the way it was done for
> >     draft-ietf-hubmib-1643-to-historic-01.txt
> >   And maybe at the same time you can ask to make 2239 Historic
> >   (instead of claiming so in sect 3.2) And are you also trying
> >   to get 1515 to historic per sect 3.3?
> 
> Cannot we avoid the need to issue two Internet-Drafts each 
> time when we release a document that obsoletes a previous RFC 
> to the point of making it Historical? Something like a clause 
> like 'Impact on other Standard Tracks Documents' in the 
> Internet-Draft?  The IESG could debate both actions by the 
> time they approve the new RFC.
> 
> Dan
> 
> > 
>