Last Call Comments: 'A Process Experiment in Normative Reference Handling' to Experimental RFC (draft-klensin-norm-ref)
I do not support approval of this experiment. I opine that most of the "publication delay" is due to WG/author choice, not the downref rule. I also offer an alternative cure which keeps in place the downref rule in published RFCs. If a WG or individual is pursuing publication of a Standard Track RFC, they should consider the impact of normatively referencing documents of lessor maturity in the Standard Track on their document's progression. Consider the case where authors are revising an existing Standard Track protocol and their document normatively references a specification currently at Proposed. Today, authors have three choices: 1) Submit their document for Propose - no ref wait, 2) Submit their document for Draft - wait on the downref to reach Draft 3) Submit their document at Draft with a request for variance from the downref rule - no ref wait. Authors can avoid the downref wait simply by requesting publication at a lower maturity (option 1). When the reference is promoted, the authors can request a promotion of their document. Now, what might be interesting is to establish a (experimental) practice that an I-D (the target) is approved at Draft Standard that normatively references existing Proposed Standards can initially be published as a Proposed Standard. When the referenced RFCs are approved and announced at Draft, the target will be automatically announced at Draft. That is, no need to seek a separate IESG action. (Likewise for Internet Standard approved documents referencing Proposed and/or Draft Standards (published at the lessor maturity of the normative references).) I do not support allowing RFCs (on or off the standard track) to normatively reference Internet-Drafts and/or works in progress. As the proposal excludes all but approved I-Ds from the experiment, I will limit my comments to approved I-Ds (or 'RFC-to-be's). I believe the RFC-to-be (the target) wait on another RFC-to-be is not so great as to risk that a change to a referenced RFC-to-be negatively impacts implementor of the target RFC-to-be. There is, I believe (based on my experience in making last minute changes to RFC-to-bes), significant risk. I also believe the wait is minimal. It appears the practice of the RFC Editor to schedule work on referenced RFC-to-be based upon the queue position of the target RFC-to-be. For instance, the revised LDAP TS (over a dozen documents submitted over many months (years?)) was processed soon after the last normative reference was approved. But more important, if we would have published the early RFC-to-be as soon as the later RFC-to-be had been approved, we would have many bad section cites in these documents. This would have lead to significant reader confusion. The wait is not without purpose. I also do not support an experiment allowing Standard Track RFCs to normatively reference non-Standard Track RFCs (or other non-standard documents). I believe the RFC 3978 practice and the RFC 2026 variance process provides adequate means publishing documents with such references. I believe the RFC-to-be (the target) wait on another RFC-to-be is not so great as to risk that a change to a referenced RFC-to-be negatively impacts implementor of the target RFC-to-be. There is, I believe (based on my experience in making last minute changes to RFC-to-bes), significant risk. I also believe the wait is minimal. It appears the practice of the RFC Editor to schedule work on referenced RFC-to-be based upon the queue position of the target RFC-to-be. For instance, the revised LDAP TS (over a dozen documents submitted over many months (years?)) was processed soon after the last normative reference was approved. But more important, if we would have published the early RFC-to-be as soon as the later RFC-to-be had been approved, we would have many bad section cites in these documents. This would have lead to significant reader confusion. The wait is not without purpose. I also do not support an experiment allowing Standard Track RFCs to normatively reference non-Standard Track RFCs (or other non-standard documents). I believe the RFC 3978 practice and the RFC 2026 variance process provides adequate means publishing documents with such references. Regards, Kurt ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Comments on draft-iab-rfc-editor: IETF control
*> *> I think there is a middle ground that can exist - a contract between *> IAOC representing IETF and ISI representing RFC Editor where RFC Editor *> agrees to publish documents submitted to it by IETF (i.e. they'll not *> be able to say no to IETF request to publish document even if RFC Editor *> believes its not ready) and for that RFC Editor receives a funding for *> its operations (which includes ability to publish documents that did not *> go through IETF process). *> Which exactly describes the current situation, I believe. Bob Braden ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Comments on draft-iab-rfc-editor: IETF control
At 04:09 PM 6/9/2006, Leslie Daigle wrote: Mike, Michael StJohns wrote: At 03:04 PM 6/9/2006, Leslie Daigle wrote: Mike, I am not going to engage in a public debate about what constitutes the complete set of facts here: I love it when discussions start out with throw away the facts. That's a mischaracterization of what I said, and I'll accept an apology. You said "I'm not going to engage in a public debate about what constitutes the complete set of facts here". Which I took to mean that "What I believe are the facts are indeed the facts and I won't be trying to integrate other views of the facts into my world view nor will I do you the courtesy of trying to understand your point of view on the facts". Perhaps my flippant comment was a mis-characterization and for that I apologize, but it was much milder than I was thinking. The RFC Editor through agreement with the IAB and with funding from the ISOC publishes the Internet Standards series under the banner of the RFC Series. No, ISI publishes (all) RFCs under contract from ISOC. Fact. This can mean either: "ISOC owns the RFC series and is paying ISI as their agent to publish such a series" or "ISI owns the RFC series and ISOC is paying them to publish additional documents under that imprint". I believe the latter is correct absent any offer of proof of transfer of rights. You asked for constructive comment. I provided it. You ignored it. Interesting method for gaining consensus. Leslie. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Comments on draft-iab-rfc-editor: IETF control
Mike, Michael StJohns wrote: At 03:04 PM 6/9/2006, Leslie Daigle wrote: Mike, I am not going to engage in a public debate about what constitutes the complete set of facts here: I love it when discussions start out with throw away the facts. That's a mischaracterization of what I said, and I'll accept an apology. The RFC Editor through agreement with the IAB and with funding from the ISOC publishes the Internet Standards series under the banner of the RFC Series. No, ISI publishes (all) RFCs under contract from ISOC. Fact. Leslie. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Comments on draft-iab-rfc-editor: IETF control
At 03:04 PM 6/9/2006, Leslie Daigle wrote: Mike, I am not going to engage in a public debate about what constitutes the complete set of facts here: I love it when discussions start out with throw away the facts. The IAB document is consistent with the operational facts that have governed operation at least in the years since ISOC has been funding the RFC Editor effort, and offers a way forward to ensure a continued funded independent series which respects that history. No, actually it is not consistent. And I'd bet not legally consistent either. Two organizations: IAB and RFC Editor Two document series: Internet Standards and RFCs The RFC Editor through agreement with the IAB and with funding from the ISOC publishes the Internet Standards series under the banner of the RFC Series. The IAB may at any time choose to select and gain agreement with another organization for the publication of the Internet Standards series, either under the imprint of that new organization or under its own imprint (e.g. "ISOC's Internet Standards Series"). It could even ask the current RFC Editor to publish such an imprint. "In the publishing business, an imprint is a brand name under which a work is published. " What the IAB can't do is direct the RFC Editor what it can and cannot publish under the RFC imprint. The RFC Editor can (and has) agree to limit what it publishes under the imprint (e.g. the RFC editor won't publish competing standards as a way of subverting the process). I understand you are disagreeing with that proposal; No - you understand wrong. I'm disagreeing with the characterization of this document as a charter for the RFC editor. Change the words so that it refers simply to the Internet Standards series, note that the series is currently published under the RFC imprint by the RFC editor at ISI and that the funding for the RFC editor comes from ISOC and I'll be fairly happy. This should be a requirements document for how you want the Internet Standards publication process to work, not a whip to the back of the RFC editor. Keep in mind that at the end of this the requirements for the publication of Internet Standards may be disjoint with the requirements for the publication of RFCs. I am not hearing a viable alternative proposal that respects the governing operational reality. I believe pursuing this line of argument overlooks the intervening history (e.g., *all* RFCs since approx 2000 bear ISOC copyright; the RFC Editor work was done under contract as "work for hire"). ISOC retains the copyright to the work published - this is true. But the mere fact that ISOC paid for the publication within the RFC series does not translate to ISOC owning the RFC series. If the RFC series had come into being as a result of the 2000 agreement the series might belong to ISOC. If the RFC series had only published Internet Standards since 2000 the series might belong to ISOC. Neither of these are the case and its doubtful ISOC can claim ownership of the series regardless if its "ownership" of copyright of contents. For example, at one point in time the IETF considered publication of its standards series with ISO and with IEEE. Had we done that I'm pretty sure we wouldn't today be claiming we owned "IEEE Transactions in Internet Standards". Worse, I believe pursuing this line of argument can only lead to a future where the RFC series is split (IETF documents and not), and the RFC Editor function expires for lack of financial support. (I haven't heard your proposal for how that doesn't happen?). And again - this may happen, but its not for the IAB or IETF to be trying to specify what the RFC editor can and can't do under its own imprint. You need to step back, separate the publication of Internet Standards from the organization actually doing the publication. Re-write the document in a form the describes the requirements the IAB has for this one specific task. If you want the RFC editor to do those tasks, get their agreement and more get it written into the contract. If they decide they're done with the process, be prepared to start a new series that isn't the RFCs. The RFC name is not magical - its just historic. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Comments on draft-iab-rfc-editor: IETF control
At 02:48 PM 6/9/2006, william(at)elan.net wrote: On Fri, 9 Jun 2006, Eliot Lear wrote: Mike, Are you suggesting that the ISOC pull RFC Editor funding and invest in another series where the community has more say? Otherwise one person can override the will of the community, as Jon did on more than one occasion. I don't think we want that any more. I certainly don't. No we don't want that, but we also don't want RFC Editor as directly part IETF structure or answerable to it for everything it does. I think there is a middle ground that can exist - a contract between IAOC representing IETF and ISI representing RFC Editor where RFC Editor agrees to publish documents submitted to it by IETF (i.e. they'll not be able to say no to IETF request to publish document even if RFC Editor believes its not ready) and for that RFC Editor receives a funding for its operations (which includes ability to publish documents that did not go through IETF process). Such contract can in itself be considered as describing RFC Editor operations as they relate to IETF and be published as an RFC. But it would not be an exclusive description of all that RFC Editor does. And this is exactly what I believed to be the current relationship between the RFC editor and the IETF/IAB/ISOC. Apparently, the small amount of editorial oversight the RFC editor is currently placing on the Internet Standards series is perceived as too much by some. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Comments on draft-iab-rfc-editor: IETF control
At 02:31 PM 6/9/2006, Eliot Lear wrote: Mike, Are you suggesting that the ISOC pull RFC Editor funding and invest in another series where the community has more say? Otherwise one person can override the will of the community, as Jon did on more than one occasion. I don't think we want that any more. I certainly don't. Eliot I'm saying that may actually be the right answer for what seems to be a desire for control. Without knowing the specifics of Jon's overrides - I can only say that those I know of involved poorly written or unclear documents that Jon was exercising reasonable editorial control over. If you're saying that we don't want an editor for the series - e.g. just publish what the IESG approves - let's just shut down the RFC series and open up an Internet Standards series that gets published by placing it on the website - e.g. closer to what we do with the ID series. If we want an editor (a real editor that is - not just someone with the title but just does administrative stuff), then that editor needs to have some measure of control over the series and YES a veto for publication within that series when the submissions don't meet the standards for publication. I really don't care which at this point, but the IETF can't have it both ways. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Comments on draft-iab-rfc-editor: IETF control
On Fri, 9 Jun 2006, Leslie Daigle wrote: Mike, I am not going to engage in a public debate about what constitutes the complete set of facts here: there is no dispute (afaict) that the RFC Editor series started before the IETF, or that it has had a broader mandate than IETF standards. What do you mean "has had"? The way I see it, that "mandate" is still there! -- William Leibzon Elan Networks [EMAIL PROTECTED] ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Comments on draft-iab-rfc-editor: IETF control
Mike, I am not going to engage in a public debate about what constitutes the complete set of facts here: there is no dispute (afaict) that the RFC Editor series started before the IETF, or that it has had a broader mandate than IETF standards. The IAB document is consistent with the operational facts that have governed operation at least in the years since ISOC has been funding the RFC Editor effort, and offers a way forward to ensure a continued funded independent series which respects that history. I understand you are disagreeing with that proposal; I am not hearing a viable alternative proposal that respects the governing operational reality. I believe pursuing this line of argument overlooks the intervening history (e.g., *all* RFCs since approx 2000 bear ISOC copyright; the RFC Editor work was done under contract as "work for hire"). Worse, I believe pursuing this line of argument can only lead to a future where the RFC series is split (IETF documents and not), and the RFC Editor function expires for lack of financial support. (I haven't heard your proposal for how that doesn't happen?). In short -- the draft is a best effort proposal for establishing a viable future that respects the history of this function and gives it a future. *Please* contribute to making this proposal better, don't just say it ain't so! BTW, the discussion of that independent submission stream is at [EMAIL PROTECTED] . Leslie. Michael StJohns wrote: Brian - In absolute seriousness, I could publish an ID/RFC or other document that says that I'm the king of the Internet - doesn't make it so. These are the facts as I understand them. 1) The RFC Series has always been at ISI, originally under Jon Postel the "RFC Editor", but more recently under Bob Braden's direction. 2) The RFC Series was first begun in 1969 and was for the most part a commentary on the ARPANet experiment until the late 1970's. 3) The RFC editor function was paid for in its entirety by the US Government from 1969 until sometime in 1997-98. 4) The IETF didn't begin until 1986. 5) The first lists of "IAB" standards didn't appear until 1988 (RFC1083) and that document made it clear that standards were only a part of what the RFC Editor did. Note that at that time the author of 1083 was listed as "Defense Advanced Research Projects Agency, Internet Activities Board " It wasn't for another few years (approx 1991 I believe) that the split of standards into Draft/Proposed/Standard began to be reflected in the successor documents to 1083 6) The RFC Editor has been either a defacto or dejure member of the IAB going back pretty much to its inception (I don't know exactly how far) so saying the IAB was responsible for the RFC series was correct, but to more properly state it "The IAB [in the person of the RFC editor] is responsible for editorial management..." brackets mine. Jon was a polite guy and didn't like a lot of disharmony in his life - I'm not surprised the language stood as it did - he didn't see its as a distinction with a difference. 7) The standards RFC STD 1 describes the standardization process. It is not and has never been inclusive of the other work done by the RFC Editor. 8) I've seen no mention of the transfer of the term of art "RFC Editor" or "RFC Series" to either the IAB, IETF, or ISOC. E.g. the mere fact the ISOC pays for the publication of RFCs does not necessarily give them ownership of that term or the series itself. Conclusions: 1) The RFC Editor is not just the Internet Standards process. 2) The RFC Series, while it is currently the archival series for the Internet Standards, is broader than just that process. 3) The Internet Standards series could be published by another channel. 4) The terms RFC Editor and the right to publish the RFC series probably vest with ISI absent of any other agreement between ISI and some other entity. These facts and conclusions lead me to the conclusion that the RFC Editor is currently the publisher of Internet Standards, the publisher of Internet Standards is not necessarily the RFC Editor. The IETF/IABs interest in the RFC Editor must be limited to those specific roles we ask him to take on for us and must not bleed over into to trying to control other aspects of the RFC Editor organization. With respect to your question of how to make the RFC Editor answerable to the community - I wouldn't. I'd make the publisher of Internet Standards answerable for the publication of Internet standards and not interfere in the other work they're doing. E.g. if you don't like what the RFC editor is doing with your standards, move the standards series someplace else. If you do move it someplace else, don't expect to constrain what else they do. If you want that series to be the RFC series - ask ISI nicely for the transfer of rights to the IAOC. Once that happens I'll shut up about the need to keep in mind that the RFC Editor and the
Re: Comments on draft-iab-rfc-editor: IETF control
On Fri, 9 Jun 2006, Eliot Lear wrote: Mike, Are you suggesting that the ISOC pull RFC Editor funding and invest in another series where the community has more say? Otherwise one person can override the will of the community, as Jon did on more than one occasion. I don't think we want that any more. I certainly don't. No we don't want that, but we also don't want RFC Editor as directly part IETF structure or answerable to it for everything it does. I think there is a middle ground that can exist - a contract between IAOC representing IETF and ISI representing RFC Editor where RFC Editor agrees to publish documents submitted to it by IETF (i.e. they'll not be able to say no to IETF request to publish document even if RFC Editor believes its not ready) and for that RFC Editor receives a funding for its operations (which includes ability to publish documents that did not go through IETF process). Such contract can in itself be considered as describing RFC Editor operations as they relate to IETF and be published as an RFC. But it would not be an exclusive description of all that RFC Editor does. -- William Leibzon Elan Networks [EMAIL PROTECTED] ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Comments on draft-iab-rfc-editor: IETF control
Mike, Are you suggesting that the ISOC pull RFC Editor funding and invest in another series where the community has more say? Otherwise one person can override the will of the community, as Jon did on more than one occasion. I don't think we want that any more. I certainly don't. Eliot ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Comments on draft-iab-rfc-editor: IETF control
Brian - In absolute seriousness, I could publish an ID/RFC or other document that says that I'm the king of the Internet - doesn't make it so. These are the facts as I understand them. 1) The RFC Series has always been at ISI, originally under Jon Postel the "RFC Editor", but more recently under Bob Braden's direction. 2) The RFC Series was first begun in 1969 and was for the most part a commentary on the ARPANet experiment until the late 1970's. 3) The RFC editor function was paid for in its entirety by the US Government from 1969 until sometime in 1997-98. 4) The IETF didn't begin until 1986. 5) The first lists of "IAB" standards didn't appear until 1988 (RFC1083) and that document made it clear that standards were only a part of what the RFC Editor did. Note that at that time the author of 1083 was listed as "Defense Advanced Research Projects Agency, Internet Activities Board " It wasn't for another few years (approx 1991 I believe) that the split of standards into Draft/Proposed/Standard began to be reflected in the successor documents to 1083 6) The RFC Editor has been either a defacto or dejure member of the IAB going back pretty much to its inception (I don't know exactly how far) so saying the IAB was responsible for the RFC series was correct, but to more properly state it "The IAB [in the person of the RFC editor] is responsible for editorial management..." brackets mine. Jon was a polite guy and didn't like a lot of disharmony in his life - I'm not surprised the language stood as it did - he didn't see its as a distinction with a difference. 7) The standards RFC STD 1 describes the standardization process. It is not and has never been inclusive of the other work done by the RFC Editor. 8) I've seen no mention of the transfer of the term of art "RFC Editor" or "RFC Series" to either the IAB, IETF, or ISOC. E.g. the mere fact the ISOC pays for the publication of RFCs does not necessarily give them ownership of that term or the series itself. Conclusions: 1) The RFC Editor is not just the Internet Standards process. 2) The RFC Series, while it is currently the archival series for the Internet Standards, is broader than just that process. 3) The Internet Standards series could be published by another channel. 4) The terms RFC Editor and the right to publish the RFC series probably vest with ISI absent of any other agreement between ISI and some other entity. These facts and conclusions lead me to the conclusion that the RFC Editor is currently the publisher of Internet Standards, the publisher of Internet Standards is not necessarily the RFC Editor. The IETF/IABs interest in the RFC Editor must be limited to those specific roles we ask him to take on for us and must not bleed over into to trying to control other aspects of the RFC Editor organization. With respect to your question of how to make the RFC Editor answerable to the community - I wouldn't. I'd make the publisher of Internet Standards answerable for the publication of Internet standards and not interfere in the other work they're doing. E.g. if you don't like what the RFC editor is doing with your standards, move the standards series someplace else. If you do move it someplace else, don't expect to constrain what else they do. If you want that series to be the RFC series - ask ISI nicely for the transfer of rights to the IAOC. Once that happens I'll shut up about the need to keep in mind that the RFC Editor and the publisher of Internet Standards are two distinct roles. To be blunt - this is a grab for power. Certain persons don't like the independence of the RFC Editor and want total control over the editorial process. I'm at times minded of state control over newspapers in some of our less progressive countries. I'm pretty disgusted we've fallen to this point. At 03:37 AM 6/7/2006, Brian E Carpenter wrote: Michael StJohns wrote: ... In the doc " It is the responsibility of the IAB to approve the appointment of an organization to act as RFC Editor and the general policy followed by the RFC Editor." This is incorrect. Mike, in absolute seriousness, the time to make that comment was in 1999/2000 when the draft that became RFC 2850 was under consideration, because that is the authority for this text. [Truth in advertising: I was the editor of RFC 2850.] It was expanded from earlier text in RFC 1601 (published in 1994): The IAB is responsible for editorial management and publication of the Request for Comments (RFC) document series... which was modified from RFC 1358 (published in 1992): [IAB] responsibilities shall include: ... (2) The editorial management and publication of the Request for Comments (RFC) document series, which constitutes the archival publication series for Internet Standards and related contributions by the Internet research and eng
icalendar feeds for network/tech meeting calendar
This is not especially on-topic here, but since (a) there are probably more people here who have an interest in debugging/reviewing RFC 2445 documents than anywhere else and (b) there are probably more people here for whom a maintained calendar of meetings is a wildly useful thing, I thought I'd forward it. Hervey Allen is the programmer responsible for the code, and I know he would love to receive feedback. I believe all testing to date has been done with Apple's iCal and Mozilla Sunbird. The calendar is provided by ISOC and NSRC. Begin forwarded message: From: Hervey Allen <[EMAIL PROTECTED]> Date: 9 June 2006 11:35:52 EDT (CA) To: [EMAIL PROTECTED] Subject: [net-meeting-coord] iCal feeds for Network Training Events Calendar available Reply-To: [EMAIL PROTECTED] The Network Education and Training Calendar of Events located here: http://ws.edu.isoc.org/calendar/ Now has several iCal feeds available. You can choose from all events (past and future), upcoming or previous. The feeds are available here: http://ws.edu.isoc.org/calendar/ical/ In addition, if you are interested in adding an event to the calendar that you think belongs you can create an account on the site and then add an event using this page: http://ws.edu.isoc.org/organizers/create-event.php All this is linked off the main calendar page. Questions or comments can be sent to myself or [EMAIL PROTECTED] - Hervey Allen -- - Hervey Allen Network Startup Resource Center [EMAIL PROTECTED] GPG Key Fingerprint: AC08 31CB E453 6C65 2AB3 4EDB CEEB 5A74 C6E5 624F __ __ archive: http://ws.edu.isoc.org/archive/net-meeting-coord/index.html calendar: http://ws.edu.isoc.org/calendar/ ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: IETF Sites Support IPv6
Iljitsch van Beijnum wrote: Ray, On 6-jun-2006, at 16:31, Ray Pelletier wrote: I am pleased to report this 6th day of June 2006 that IETF FTP, Mail & Web support IPv6. I was wondering: would it be possible to publish statistics about IPv4 vs IPv6 traffic for these services? I have asked NeuStar Secretariat to look into it. I'll get b ack with what I learn. Ray Iljitsch (And this time the headers should have IPv6 in them...) ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Best practice for data encoding?
So how about concluding that there is no single right answer to Iljitsch's question, but there may be scope for defining considerations for the choice of data encoding? Brian ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: RFC Author Count and IPR
Unfortunately the genesis of some IP is not that easily dealt with - In fact EACH and EVERY contributor must be named, since their rights to the core genesis are something that are either defined in an agreement or somethign for resolution before a trier of fact in some form. Todd - Original Message - From: "Vijay Devarapallli" <[EMAIL PROTECTED]> To: "Bob Braden" <[EMAIL PROTECTED]> Cc: ; ; <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>; ; Sent: Wednesday, May 24, 2006 11:50 AM Subject: Re: RFC Author Count and IPR > On 5/24/06, Bob Braden <[EMAIL PROTECTED]> wrote: > > > > > > *> That means if you have unlisted authors who have contributed > > *> significant chunks of text, you still need to get their clearance to > > *> do anything interesting with that text. > > *> > > > > Who decides what constitutes a "significant chunk"? > > the primary author (there is always one person who maintains the > XML source) and the WG chairs? > > Vijay > > ___ > Ipr-wg mailing list > Ipr-wg@ietf.org > https://www1.ietf.org/mailman/listinfo/ipr-wg > ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: I-D ACTION:draft-iab-rfc-editor-00.txt
Eliot Lear wrote: Brian E Carpenter wrote: Although I'm an IAB member, I'd rather make my one comment on this draft in public. I think it misses one point that should be mentioned. The easiest way to explain it is to suggest new text: 4.4. Avoiding interference between publication streams Nice as this sounds, apparently the IESG seems to have no problem approving documents within a stream that interfere with each other. Well, that gets a bit complicated. I was going to say that we wouldn't do that *intentionally*, but we might - if there was in fact IETF consensus to develop alternative solutions for the same problem. But we certainly shouldn't approve two different uses for the same TLV, for example. Perhaps we could have some guidance there as well? Like, the IESG should apply common sense? ;-) Seriously, I find it hard to see what words would help here. Brian ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Acknowledgements section in a RFC (Was: Last Call: 'Matching of Language Tags' to BCP (draft-ietf-ltru-matching)
Jeffrey Hutzelman wrote: Disclaimer: IANAL, and this message is not intended as legal advice. Please, read RFC3979 for yourself, and if you have concerns as to what your obligations are or what you can get away with, consult a lawyer. On Wednesday, June 07, 2006 02:22:06 PM -0400 "Gray, Eric" <[EMAIL PROTECTED]> wrote: The Note Well is not clear because it makes sweeping statements about the way in which BCP 78 and 79 may apply to "contributions". Eric, there is no "may" about it. It states very clearly that *all* contributions are covered. The definition of "contribution" is spelled out in BCP 79 as Definition 1.c. I see no ambiguity whatever. The "Note Well" is a notification that if you contribute, you have certain obligations. It is not a normative description of those obligations; for that, you need to refer to BCP 78 and 79. Those documents make it quite clear that you are obligated to disclose certain IPR if you make a contribution in _any_ form, including comments made in a meeting or on a mailing list, or to an IESG or IAB member, or to a "portion" of any working group, which is intended to cover a variety of ways in which people provide input outside the context of a formal meeting. BCP79 requires you to make disclosures of your or your employers IPR in a contribution you make, and normally in contributions you don't make but are aware of, even if you become aware of the IPR after the contribution is made. Not becoming aware of the IPR until after the document is published does not relieve you of the obligation to disclose it. Nor does having the contribution be made by someone else, even if they don't work for your company and/or are unaware of the IPR. participating in the work, I may not be held accountable for IPR I may know of but which did not enter into the text until sometime after I stopped looking at it. You're only obligated to make an IPR disclosure if the IPR is owned by you or your company and either (1) you made the contribution, or (2) the contribution was made in a discussion in which you are participating. If you stop participating in a discussion, you no longer have the responsibility to make IPR disclosures related to contributions made after you stop participating. Also, BCP 79 does not require a patent search - it applies explicitly to IPR of which the contributor is reasonably and personally aware. So it isn't an onerous obligation; you don't have to worry about unknowns. Brian Similarly, if I object to work that has been done, you may not attach my name to it against my objections - unless either the Note Well, and the BCPs, both explicitly include a provision for implied consent. If that is the case, now, then it is most certainly not "clear" that it is. Certainly, no one should be represented as supporting work which they do not support. It is entirely reasonable to request that your name be removed from the list of authors, if you no longer wish to perform the duties of an author, or from the list of contributors, if you did not make a contribution or don't want your contribution noted. Acknowledgements are more of a "thanks for your input", and it's not really reasonable to tell authors that he can't acknowledge people whose input they found helpful - as long as an acknowledgement does not imply endorsement on the part of the person who is acknowledged. On the other hand, IMHO it would be even _more_ unreasonable for an author to refuse to remove the name of a person who did not want to be acknowledged. This is the negative side of the discussion going on. People are focusing on reasons why someone might want to be included in acknowledgements. I am merely pointing out that it is also possible that someone might not want this. And John's point is this: There may be legitimate reasons for not wanting to be acknowledged or listed as an author or contributor. However, having your name removed from the document does not change the fact of your contribution, or relieve you of your obligations with respect to that contribution. Now, you made specific reference to the IPR disclosure acknowledgement which is required by RFC3978 section 5.1 to be present in all I-D's. Your argument seems to be that this statement imposes an additional burden upon anyone listed as an author, and that one might want to be removed from the author list in order to be relieved of this burden. But if you read the acknowledgement carefully, the representation being made by the authors is that they are in compliance with BCP 79 section 6(*). Since compliance with that section is required for _anyone_ making a contribution to the IETF, being removed from the author list does _not_ relieve you of that burden - it simply allows you to avoid preiodically representing that you are meeting it. I completely agree that anyone who no longer wishes to be listed as an author of an I-D should be
