Subject: [sipcore] [Fwd: Re: Re: Input requested on how to proceed with the essential corrections to RFC 3261]

From: Adam Roach <[email-masked]>
Date: Thu, 25 Jun 2009 21:48:05 -0500

For some reason, the IETF mailing list software misprocessed this
message as a bounce. I'm forwarding it to the list.

/a

-------- Original Message --------
Subject: 	Re: Re: [sipcore] Input requested on how to proceed with the
essential corrections to RFC 3261
Date: 	Fri, 26 Jun 2009 09:39:45 +0900
From: 	[email-masked]
To: 	Vijay K. Gurbani <[email-masked]>
CC: 	Gonzalo Camarillo <[email-masked]>, SIPCORE
<[email-masked]>, [email-masked]

Hi,

As currently, correction of texts for RFC3261 are in different states,
such as some in RFC states, some in WG draft states and others in
Personal draft states.
So, combination of the all may be a unmanageable work. Further, making
the texts in RFC states into a new WG draft/RFC may make people
confusing(especially for citation of such RFCs).

So, I think making them separately might better.
And I think we can using a new text as the list of the currently
correlative active draft/RFCs. Then, people wanting to have a main view
of RFC's correction can refer to that list.

Thanks,

Gao

===================================
Zip : 210012
Tel : 87211
Tel2 :(+86)-025-52877211
e_mail : [email-masked]
===================================

*"Vijay K. Gurbani" <[email-masked]>*
发件人: [email-masked]

2009-06-25 21:58

收件人
	Gonzalo Camarillo <[email-masked]>
抄送
	SIPCORE <[email-masked]>
主题
	Re: [sipcore] Input requested on how to proceed with the essential
corrections to RFC 3261

Gonzalo Camarillo wrote:
[...]
> The concrete decision we have to make is whether it makes sense to merge
> the following drafts in a batch, per the essential corrections process,
> or whether we advance these drafts independently.
>
> http://tools.ietf.org/html/draft-ietf-sip-ipv6-abnf-fix-03
> http://tools.ietf.org/html/draft-sparks-sip-invfix-03
> http://tools.ietf.org/html/draft-camarillo-sipping-reinvite-00
>
> We would appreciate the feedback of the WG on this issue so that we can
> make progress updating RFC 3261.

Gonzalo: I don't have a hard opinion one way or the other.

That said, a quick analysis on the existing corpus of RFCs to
see which RFC has been updated by the most number of RFCs
reveals that rfc1035 has been updated by 20 RFCs (and rfc1035
is a standards track document), followed by rfc1034 (14 updates.)
The next highest distribution bin from there clusters
around 3-5 updates.

So, if the past in the form of rfc1035 is any guide, then
rfc3261 has a way to go, and we should be okay by having each
individual document update rfc3261 independently.

Or alternatively, you can advance the drafts that have
been previously identified as part of the essential corrections
process in a batch, but once that is done, revert back to the
normal mode of operations -- each file updates the base RFC in
its own manner.

- vijay
-- 
Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent
1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60566 (USA)
Email: vkg@{alcatel-lucent.com,bell-labs.com,acm.org}
Web: http://ect.bell-labs.com/who/vkg/
_______________________________________________
sipcore mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/sipcore

--------------------------------------------------------
ZTE Information Security Notice: The information contained in this mail is solely property of the sender's organization. This mail communication is confidential. Recipients named above are obligated to maintain secrecy and are not permitted to disclose the contents of this communication to others.
This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the originator of the message. Any views expressed in this message are those of the individual sender.
This message has been scanned for viruses and Spam by ZTE Anti-Spam system.