Re: [Geopriv] On the value of a DIFF -- RE: Virtual interim consensus calls

From: DRAGE, Keith (Keith) ^lt;drage@alcatel-lucent.com>
Date: Fri May 29 2009 - 08:18:03 EDT

#1 please.

> -----Original Message-----
> From: Brian Rosen [mailto:br@brianrosen.net]
> Sent: Thursday, May 28, 2009 10:55 PM
> To: 'Alissa Cooper'; 'Hannes Tschofenig'
> Cc: geopriv@ietf.org; DRAGE, Keith (Keith)
> Subject: RE: [Geopriv] On the value of a DIFF -- RE: Virtual
> interim consensus calls
>
> +1 for #1
>
> > -----Original Message-----
> > From: geopriv-bounces@ietf.org [mailto:geopriv-bounces@ietf.org] On
> > Behalf Of Alissa Cooper
> > Sent: Thursday, May 28, 2009 2:47 PM
> > To: Hannes Tschofenig
> > Cc: geopriv@ietf.org; drage@alcatel-lucent.com
> > Subject: Re: [Geopriv] On the value of a DIFF -- RE:
> Virtual interim
> > consensus 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: geopriv-bounces@ietf.org [mailto:geopriv-bounces@ietf.org]
> > On
> > > Behalf Of Bernard Aboba
> > > Sent: 22 May, 2009 15:37
> > > To: drage@alcatel-lucent.com; acooper@cdt.org; geopriv@ietf.org
> > > 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
> > Geopriv@ietf.org
> > https://www.ietf.org/mailman/listinfo/geopriv
>
>
_______________________________________________
Geopriv mailing list
Geopriv@ietf.org
https://www.ietf.org/mailman/listinfo/geopriv
Received on Fri, 29 May 2009 14:18:03 +0200

This archive was generated by hypermail 2.1.8 : Fri May 29 2009 - 08:19:18 EDT