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

From: Jonathan Rosenberg <[email-masked]>
Date: Wed, 01 Nov 2006 17:02:15 -0500

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).

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?

-Jonathan R.

Drage, Keith (Keith) wrote:

> I have recently submitted
> 
> http://www.ietf.org/internet-drafts/draft-drage-sip-essential-correction
> -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: "Drage, Keith \(Keith\)" <[email-masked]>
Date: Mon, 13 Nov 2006 11:20:58 +0100

Having talked directly to Shida.

I obviously need to expand this bit somewhat as it seems to have led to
more confusion that understanding.

The key idea is that at any one time only the RFC and one correction RFC
will exist - we do not directly update the original RFC as that would
lead us into a complete revision which would probably last as long as
the transition from RFC 2543 to RFC 3261.

The idea of allowing individual or related errors to be put into
separate drafts was to allow the less controversial ones to progress
independently of the more controversial ones which would require more
discussion. Thus I think it is still a good idea to do this although we
do have to be pragmatic and essentially make sure we split for the above
reason, rather than for the purpose of creating as many drafts as
possible.

One of the concerns of Shida was that all revisions would be identified
even before they become compiled into correction RFCs. I think we can
use the softarmor website to identify these, and also it would probably
help to include some special part of the draft naming to indicate this.

Regards

Keith

> -----Original Message-----
> From: Shida Schubert [mailto:[email-masked]] 
> Sent: 06 November 2006 00:57
> To: Drage, Keith (Keith)
> Cc: Jonathan Rosenberg; SIP
> Subject: Re: [Sip] Request for views on 
> draft-drage-sip-essential-correction-00.txt
> 
> 
>  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 
> importFrom [email-masked] Mon Nov 13 05:23:36 2006
Content-class: urn:content-classes:message
Subject: RE: [Sip] Request for
	views	on	draft-drage-sip-essential-correction-00.txt
Date: Mon, 13 Nov 2006 11:20:58 +0100
From: "Drage, Keith \(Keith\)" <[email-masked]>
To: "Shida Schubert" <[email-masked]>
Cc: SIP <[email-masked]>

Having talked directly to Shida.

I obviously need to expand this bit somewhat as it seems to have led to
more confusion that understanding.

The key idea is that at any one time only the RFC and one correction RFC
will exist - we do not directly update the original RFC as that would
lead us into a complete revision which would probably last as long as
the transition from RFC 2543 to RFC 3261.

The idea of allowing individual or related errors to be put into
separate drafts was to allow the less controversial ones to progress
independently of the more controversial ones which would require more
discussion. Thus I think it is still a good idea to do this although we
do have to be pragmatic and essentially make sure we split for the above
reason, rather than for the purpose of creating as many drafts as
possible.

One of the concerns of Shida was that all revisions would be identified
even before they become compiled into correction RFCs. I think we can
use the softarmor website to identify these, and also it would probably
help to include some special part of the draft naming to indicate this.

Regards

Keith

> -----Original Message-----
> From: Shida Schubert [mailto:[email-masked]] 
> Sent: 06 November 2006 00:57
> To: Drage, Keith (Keith)
> Cc: Jonathan Rosenberg; SIP
> Subject: Re: [Sip] Request for views on 
> draft-drage-sip-essential-correction-00.txt
> 
> 
>  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
> 
> 
> > Thanks for the comments.
> > Inline below: 
> >> -----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.
> >>
> >> 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.
> >>
> http://www.ietf.org/internet-drafts/draft-drage-sip-essential-correct
> >> i
> >>     
> >>> on
> >>> -00.txt
> >>>
> >>> The idea behind this draft, is to put some management 
> into getting 
> >>> real
> >>> bugfixes:
> >>>
> >>> 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
> >>     
> >>> This list is for NEW development of the core SIP Protocol Use 
> >>> [email-masked] From [email-masked] Mon Nov 13 05:23:36 2006
Content-class: urn:content-classes:message
Subject: RE: [Sip] Request for
	views	on	draft-drage-sip-essential-correction-00.txt
Date: Mon, 13 Nov 2006 11:20:58 +0100
From: "Drage, Keith \(Keith\)" <[email-masked]>
To: "Shida Schubert" <[email-masked]>
Cc: SIP <[email-masked]>

Having talked directly to Shida.

I obviously need to expand this bit somewhat as it seems to have led to
more confusion that understanding.

The key idea is that at any one time only the RFC and one correction RFC
will exist - we do not directly update the original RFC as that would
lead us into a complete revision which would probably last as long as
the transition from RFC 2543 to RFC 3261.

The idea of allowing individual or related errors to be put into
separate drafts was to allow the less controversial ones to progress
independently of the more controversial ones which would require more
discussion. Thus I think it is still a good idea to do this although we
do have to be pragmatic and essentially make sure we split for the above
reason, rather than for the purpose of creating as many drafts as
possible.

One of the concerns of Shida was that all revisions would be identified
even before they become compiled into correction RFCs. I think we can
use the softarmor website to identify these, and also it would probably
help to include some special part of the draft naming to indicate this.

Regards

Keith

> -----Original Message-----
> From: Shida Schubert [mailto:[email-masked]] 
> Sent: 06 November 2006 00:57
> To: Drage, Keith (Keith)
> Cc: Jonathan Rosenberg; SIP
> Subject: Re: [Sip] Request for views on 
> draft-drage-sip-essential-correction-00.txt
> 
> 
>  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 
> importfor questions on current sip Use 
> >>> [email-masked] for new developments on the application of 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
> >
> >
> >   
> 
>