Subject: RE: [Sip] Hitchhikers guide - when is it done?

From: "Michael Hammer \(mhammer\)" <[email-masked]>
Date: Thu, 27 Jul 2006 16:05:13 -0400

Then we will need an RFC to point to the index RFCs that point to the
base RFCs?

A single RFC pointing document would be best.

Mike

> -----Original Message-----
> From: Vijay K. Gurbani [mailto:[email-masked]] 
> Sent: Tuesday, July 25, 2006 5:43 PM
> To: Jonathan Rosenberg (jdrosen)
> Cc: IETF SIP List
> Subject: Re: [Sip] Hitchhikers guide - when is it done?
> 
> Sorry for being the voice out on the left field, but I think 
> 1 is better.  Once the 'core' documents have RFC numbers, it 
> makes sense to go ahed and publish that as an Informational 
> (maybe name it "A Hitchhikers Guide to SIP - Part 1: Core 
> Specification").
> 
> Then deal with the current I-Ds and other work as a separate 
> Informational, probably named "A Hitchhikers Guide to SIP - 
> Part 2: Extensions".  The first RFC will have an informative 
> reference to the second to-be RFC, so readers can be warned 
> that the document is split into to (plus the naming 
> convention of the title is a clue).
> 
> With Part 2 being in flux for a while, I would presume that 
> it would be easier from a process point of view to rev a I-D 
> than it is to obsolete or update a RFC.
> 
> Plus there is some poetic justice in the SIP WG closing doors 
> when the last RFC issued is one that (partially) summarizes 
> what we have done as a WG.  Too bad RFC number 4242 is already taken.
> 
> Thanks.
> 
> Jonathan Rosenberg wrote:
> > During the IETF meeting, I discussed the one current open 
> issue in the 
> > Hitchhikers guide. The issue is: when does the document 
> finish? When 
> > do we send to IESG to issue an RFC?
> > 
> > There were two approaches:
> > 
> > 1. split the document in two. One part contains only the 
> core specs, 
> > and issues relatively soon. The other part has everything else, and 
> > basically ends up being the last RFC produced by the SIP WG 
> before it 
> > shuts its doors (which has always been 1.5 years from now 
> for the last 
> > 5 years).
> > 
> > 2. keep it as one document. Issue an RFC at some point, and then 
> > revise it a few times as needed. We need to decide when to issue it.
> > 
> > 
> > I'd like to propose option 2. I think people get more value 
> from it as 
> > a consolidated document. Furthermore, I'd propose that we send the 
> > document to IESG for consideration as informational at the 
> instant all 
> > of the documents listed as 'core' have RFC numbers issued by RFC-ed.
> > 
> > Comments?
> 
> - vijay
> --
> Vijay K. Gurbani  vkg@{lucent.com,research.bell-labs.com,acm.org}
> Bell Laboratories, Lucent Technologies, Inc.
> 2701 Lucent Lane, Rm. 9F-546, Lisle, Illinois 60532 (USA)
> 
> _______________________________________________
> Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
> This list is for NEW development of the core SIP Protocol Use 
> [email-masked] for questions on current sip 
> Use [email-masked] for new developments on the application of sip
> 

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [email-masked] for questions on current sip
Use [email-masked] for new developments on the application of sip

---

From: "Vijay K. Gurbani" <[email-masked]>
Date: Thu, 27 Jul 2006 17:36:12 -0500

> Then we will need an RFC to point to the index RFCs that point to the

Nah, it's not as bad as that.  We are talking about 2 RFCs at
most, really.

> A single RFC pointing document would be best.

If we go the single RFC route, then that means obsoleting that
RFC at least once, or maybe twice.  Now, while you and I are
adept at making our way through how IETF numbers their RFCs
and what happens when one RFC is obsoleted, and so on ... I
think the majority of the people using our specifications may
not have this context.  They grab an RFC -- obsolete or not --
and run with it.

To take this to the absurd, I am aware of products based on
*expired* I-Ds, not to mention obsolete RFCs!

In summary, my preference is for (1), with two RFCs produced
at most.  But, if the WG decides to go with (2), then that
is fine...

Thanks,

- vijay