Subject: RE: [Sip] Request for views on draft-drage-sip-essential-correction-00.txt

From: "Drage, Keith \(Keith\)" <[email-masked]>
Date: Thu, 2 Nov 2006 13:50:32 +0100

Thanks for the comments.

Inline below: 

Regards

Keith

> -----Original Message-----
> From: Jonathan Rosenberg [mailto:[email-masked]] 
> Sent: 01 November 2006 22:02
> To: Drage, Keith (Keith)
> Cc: SIP
> Subject: Re: [Sip] Request for views on 
> draft-drage-sip-essential-correction-00.txt
> 
> Keith,
> 
> I agree with the final step here, but I'm not so sure about 
> your details of the intermediate steps.
> 
> In particular, I think it is too onerous to require one I-D 
> per issue. 
> FOr example it would be nice for someone to go through the 
> bugzilla database and submit one I-D with all of the things 
> in it that we need to put into the corrections spec. THis is 
> more palatable than having to submit 30 separate documents, 
> each 6 pages in length (5.5 pages overhead and 1/2 page for 
> the useful content).

I think flexibility is needed here. Grouping of related issues, are a
number of well understood and non-controversial (but otherwise
essential) corrections is probably OK.

What we don't want to do is group things that require lots of discussion
time in the WG (SIPS fixes?) with those that don't. Nor do we want to
present two issues together such that one confuses the understanding and
WG discussion of the other.
> 
> Also we need to discuss what happens when more bugs get 
> reported after the correction RFC is published. DO we revise 
> that RFC? Or issue another corrections document?
> 
The idea was that the reader only need read the original RFC plus 1
correction RFC. Thus as more corrections are discovered, we take the
contents of the original correction RFC, the new fixes, and produce a
new RFC that obsoletes the first correction RFC, but which still updates
the original RFC. Remember however that the draft replacement correction
RFC can still be rapidly put together - and it only needs IESG review
and approval, as all the individual components have been WGLC
separately. Therefore I see this process as being reasonably quick (in
IETF terms).

Note that in terms of the normal RFC process we would lose the
correction RFC if we ever take any SIP documents from proposed standard
to draft standard, i.e. the proposed standard RFC would obsolete the 

> -Jonathan R.
> 
> Drage, Keith (Keith) wrote:
> 
> > I have recently submitted
> > 
> > 
> http://www.ietf.org/internet-drafts/draft-drage-sip-essential-correcti
> > on
> > -00.txt
> > 
> > The idea behind this draft, is to put some management into getting 
> > real
> > bugfixes:
> > 
> > -	into one place where people can find it
> > -	give it standards track RFC status so that people know they have
> > to implement it.
> > 
> > If people not already consulted have views on this process, then 
> > please let them be known.
> > 
> > The idea would be to start this process (taking into 
> account any input 
> > from the WG) after the next IETF meeting.
> > 
> > Regards
> > 
> > Keith
> > 
> > Keith Drage
> > [email-masked]
> > tel: +44 1793 776249
> > 
> > _______________________________________________
> > 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
> > 
> 
> -- 
> Jonathan D. Rosenberg, Ph.D.                   600 Lanidex Plaza
> Cisco Fellow                                   Parsippany, NJ 
> 07054-2711
> Cisco Systems
> [email-masked]                              FAX:   (973) 952-5050
> http://www.jdrosen.net                         PHONE: (973) 952-5000
> http://www.cisco.com
> 

_______________________________________________
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: Shida Schubert <[email-masked]>
Date: Sun, 05 Nov 2006 16:57:18 -0800

I generally agree with Jonathan here. I don't think we should produce a
document per error. Rather, can't we take an approach that we are 
considering
for the hitch-hiker's guide? Where a single document will be updated
at certain frequency. I think from the people looking for these 
information it is
important that one can find all the errors and potential fixes in one place.
 Another approach is to have the document produced in the way it is 
mentioned
in the draft but have another document that references all the fixes in 
a similar
fashion that hitch-hiker's guide does for all the core-SIP related 
RFC/drafts.

 Regards
  Shida