Subject: RE: Scenarios analysis documents: BCP vs Informational?

From: "Bound, Jim" <[email-masked]>
Date: Thu, 29 Apr 2004 08:01:04 -0400

I support (a).  Reason.  BCPs are more easily updated as we learn
Informational lasts forever.  Caveat is IETF is working on all of this
process so my rationale may be a moot point.  Well I we did replace the
base API info multiple times??   I just like the sound of BCP I guess
:--)

Regards,
/jim 

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of [email-masked]
> Sent: Thursday, April 29, 2004 6:03 AM
> To: [email-masked]
> Subject: RE: Scenarios analysis documents: BCP vs Informational?
> 
> 
> Hi!
> 
> My opinion is c.
> 
> Cheers,
> 	 -Juha W.-
> 
> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]On
> Behalf Of ext Pekka Savola
> 
>  a) continue with BCP category,
> 
>  b) publish 3GPP analysis as Informational and consider the rest in 
>     case-by-case basis (whether Info or BCP).  Some other analysis 
>     documents may or may not fall better under the BCP category, or
> 
>  c) publish 3GPP analysis as Informational; take the rest to 
>     informational as well.
> 
> Opinions?  a), b), or c)?
> 
> 
>

---

From: Pekka Savola <[email-masked]>
Date: Thu, 29 Apr 2004 18:05:31 +0300 (EEST)

> base API info multiple times??   I just like the sound of BCP I guess

Maybe that's because folks get ashamed of out-of-date BCPs but don't 
feel so strongly about Informationals? :)

In any case, Informationals can be updated as well as we gain 
experience; if the deployment is successful, it might actually be 
worth recycling the Informationals to BCPs after some years (if deemed 
necessary).

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

---

From: Alain Durand <[email-masked]>
Date: Thu, 29 Apr 2004 10:07:27 -0700

On Apr 29, 2004, at 8:05 AM, Pekka Savola wrote:
> experience;

This is exactly what we did with

2546 6Bone Routing Practice. A. Durand, B. Buclin. March 1999.
      (Format: TXT=17844 bytes) (Obsoleted by RFC2772) (Status:
      INFORMATIONAL)

2772 6Bone Backbone Routing Guidelines. R. Rockell, R. Fink. February
      2000. (Format: TXT=28565 bytes) (Obsoletes RFC2546) (Updated by
      RFC3152) (Status: INFORMATIONAL)

	- Alain.