Re: [codec] Last Call: <draft-ietf-codec-oggopus-10.txt> (Ogg Encapsulation for the Opus Audio Codec) to Proposed Standard

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Wednesday, February 03, 2016 04:05:46 PM Ron wrote:
> On Tue, Feb 02, 2016 at 08:19:16PM -0800, Timothy B. Terriberry wrote:
> > Ron wrote:
> > >And we are specifically not proposing to give *anyone*, open source or
> > >otherwise, "the option to take an RFC and “run with it”" ...
> > >
> > >We're trying to find consensus on the best way to apply BCP 78 and the
> > >options outlined in RFC 5377 to the needs of this document, in a way
> > >that best matches the needs of its intended users to the best interests
> > >of the IETF.
> > 
> > It seems to me like putting a BSD copyright header in an XML comment at
> > the
> > top of the XML source file and dropping Section 13 from the draft would
> > resolve all of the issues, if everyone agrees that is an acceptable thing
> > to do. Ron?
> 
> It leaves us with the issue of creating a perverse incentive for some
> parties to prefer distributing the "non-rfc" version over the official
> RFC - even when they themselves have not modified it and don't have
> any direct plans to.  And in some cases, will force their hand, making
> that the only version they can redistribute ...
> 
> But aside from that, I think it would cover the practical problems
> which we currently see for implementors needing to use this in their
> own work.  Which is the most immediate issue here.
> 
> It's not my first preference, and not what I think serves the IETF's
> interest best, for all of the reasons I've outlined earlier in this
> thread -- but if we can't get consensus for adding a RFC 5377 4.3
> exception to add the "Rights Granted for Implementing" to it, and
> nobody has a better suggestion, then I can accept this option as the
> pragmatic way we should proceed here.
> 
> 
> I think both options are in the scope of current recommendations to
> allow, but I'll defer to peer review on that.

I don't understand what is better about this than what was in the previous 
draft, but I agree it has some utility.

I've had to review code before which, due to the restrictive licensing of 
RFCs, only had comments like "Implements RFC XXYY Section 5.4.2, paragraph 3".  
This can get painful, so the ability to include literal text elements is an 
improvement.  It would be nice to cite RFC text and location together and, of 
course, the section/paragraph numbers aren't in the XML.

Scott K





[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]