Subject: Re: [Geopriv] On the value of a DIFF -- RE: Virtual interimconsensus calls

From: "Roger Marshall" <[email-masked]>
Date: Mon, 1 Jun 2009 19:18:06 -0700

I'll take #2.

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Alissa Cooper
> Sent: Thursday, May 28, 2009 11:47 AM
> To: Hannes Tschofenig
> Cc: [email-masked]; [email-masked]
> Subject: Re: [Geopriv] On the value of a DIFF -- RE: Virtual
> interimconsensus calls
> 
> Let's put aside the idea of retaining diff utility for a moment, since
> the main proponent of that idea has said that he's willing to
> compromise if necessary to achieve rough consensus.
> 
> With that idea aside, there are still two mutually exclusive -bis
> options:
> 
> 1) -bis using the original RFC text and only changing what needs to be
> changed for the fixes, with the inclusion of a sub-section that lists
> the changes
> 2) -bis that makes the substantive changes needed for the fixes,
> includes a sub-section that lists the changes, and makes other textual
> edits that improve the text but do not impact the protocol design
> 
> I've seen one person supporting #1 and one person supporting #2. Does
> anyone else have an opinion?
> 
> Alissa
> 
> 
> On May 23, 2009, at 1:01 PM, Hannes Tschofenig wrote:
> 
> > I do not really understand the desire to have a minimum number of
> > document
> > changes (with respect to output caused by a DIFF tool) raised by
> > Keith would
> > be important for a tiny document like this.
> >
> > I don't think that new implementers care about this aspect given
> > that they
> > should only read the new document anyway. Someone who wants to
> > update their
> > implementation will have to read the new document anyway and would
> > probably
> > appreciate a more implementation focused description.
> >
> > We should listen more to people who either implemented the mechanism
> > or plan
> > todo so.
> >
> > Ciao
> > Hannes
> >
> > PS: I agree what Bernard says below as well.
> >
> > ________________________________
> >
> > 	From: [email-masked] [mailto:[email-masked]]
> On
> > Behalf Of Bernard Aboba
> > 	Sent: 22 May, 2009 15:37
> > 	To: [email-masked]; [email-masked]; [email-masked]
> > 	Subject: Re: [Geopriv] Virtual interim consensus calls
> >
> >
> > 	> On 1) The key guidance to the draft editor (when selected) is
> to
> > ensure that the IETF tools diff programs generate meaningful results
> > against
> > the published RFC 3825 for any new version.
> >
> > 	This doesn't make sense.  -bis documents are supposed to include
> a
> > section listing the changes from the original document.  That is
> > sufficient.
> > There is virtually no -bis document in existence today that would
> > satisfy
> > such a requirement (trying doing a diff of RFC 3261 with RFC 2543),
> > and
> > there is no practical way to enforce such a requirement all the way
> > through
> > to RFC Editor publication.
> >
> >
> >
> >
> >
> 
> 
> 
> 
> 
> 
> 
> 
> 
> _______________________________________________
> Geopriv mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/geopriv

CONFIDENTIALITY NOTICE: The information contained in this message may be privileged and/or confidential. If you are not the intended recipient, or responsible for delivering this message to the intended recipient, any review, forwarding, dissemination, distribution or copying of this communication or any attachment(s) is strictly prohibited. If you have received this message in error, please notify the sender immediately, and delete it and all attachments from your computer and network.

---

From: Richard Barnes <[email-masked]>
Date: Tue, 02 Jun 2009 10:51:21 -0400

Ok, given that there seems to be no clear direction on this thread, and 
that the distinction is fairly minor (basically, substantive vs. 
substantive+editorial changes), I'm going to propose that we table this 
issue until we have a draft (which will be soon now).

--Richard

Alissa Cooper wrote:
> the main proponent of that idea has said that he's willing to compromise 
> if necessary to achieve rough consensus.
> 
> With that idea aside, there are still two mutually exclusive -bis options:
> 
>> changes (with respect to output caused by a DIFF tool) raised by Keith 
>> would
>> I don't think that new implementers care about this aspect given that 
>> they
>> should only read the new document anyway. Someone who wants to update 
>> their
>>     > On 1) The key guidance to the draft editor (when selected) is to
>>     This doesn't make sense.  -bis documents are supposed to include a
>> There is virtually no -bis document in existence today that would satisfy
>> such a requirement (trying doing a diff of RFC 3261 with RFC 2543), and

---

From: "Alexander Mayrhofer" <[email-masked]>
Date: Tue, 2 Jun 2009 17:08:14 +0200

Sorry for being late. My vote goes to #2, because i fear that "only
changing what needs to be changed for fixes" evolves into a completely
new text pretty soon anyway.

Alex