Re: Comments for Humorous RFCs or uncategorised RFCs or dated April the first
If the date is special then thoes RFCs SHOULD be *historical*. I thought they should be classified as hysterical. - Wes
Re: RFC 6921 on Design Considerations for Faster-Than-Light (FTL) Communication
Or use the FTL to predict the company stock price so that you get rich without implementing anything. - Wes On 4/5/13 5:12 AM, Adrian Farrel adr...@olddog.co.uk wrote: So instead of asking the community do you have an intention to implement and deploy? we should ask have you already been going to have implemented and deployed yet? thinking about this and assuming that the FTL Communication are deployed in a not too far distant future, wouldn't we have started to receive packets that was sent in the future already now? Indeed, and this tells us that publication of this was important, since we'll need to be in a position to handle the issues that will occur much sooner than deployment, and for that matter development of the technology.
RE: Fwd: Broadband Forum liaison to IETF on IPv6 security
The key is that the access router (which is the only router that knows this is an NBMA link and not a BMA link) can selectively decide to send ND messages (either NA's or NS(DAD) messages) when the access router detects that there is a duplicate on the link. This is the minimum requirement to support DAD on an NBMA link. This would need to specified in an NBMA-specific document and probably doesn't need to be mentioned in a document like RFC 4861. - Wes -Original Message- From: owner-v6...@ops.ietf.org [mailto:owner-v6...@ops.ietf.org] On Behalf Of Dunn, Jeffrey H. Sent: Friday, November 06, 2009 2:18 PM To: Antonio Querubin Cc: Thomas Narten; Fred Baker (fred); 6man-...@tools.ietf.org; SAVI Mailing List; william.allen.simp...@gmail.com; Hesham Soliman; i...@core3.amsl.com; Erik Nordmark; savi-...@tools.ietf.org; IPv6 Operations; Susan Thomson (sethomso); v6ops-...@tools.ietf.org; Robin Mersh; Mailing List; su...@core3.amsl.com; JINMEI Tatuya / 神明達哉; Dunn, Jeffrey H. Subject: RE: Fwd: Broadband Forum liaison to IETF on IPv6 security Antonio, Regardless of whether the ISP bridges the NBMA links or not, the CPE router will not propagate the ND or NS messages onto these links. The Ethernet and Wi-Fi BMA LAN segments are separate logical links from each other and the ISP link(s). How will the CPE router be convinced to bridge these link-local scoped messages off link? Best Regards, Jeffrey Dunn Info Systems Eng., Lead MITRE Corporation. (301) 448-6965 (mobile) -Original Message- From: Antonio Querubin [mailto:t...@lava.net] Sent: Friday, November 06, 2009 1:35 PM To: Dunn, Jeffrey H. Cc: Thomas Narten; Fred Baker; 6man-...@tools.ietf.org; SAVI Mailing List; william.allen.simp...@gmail.com; Hesham Soliman; i...@core3.amsl.com; Erik Nordmark; savi-...@tools.ietf.org; IPv6 Operations; Thomson; v6ops-...@tools.ietf.org; Robin Mersh; Mailing List; su...@core3.amsl.com; JINMEI Tatuya / 神明達哉 Subject: RE: Fwd: Broadband Forum liaison to IETF on IPv6 security On Fri, 6 Nov 2009, Dunn, Jeffrey H. wrote: The problem is IMHO the following: How to assign an IPv6 UGA to CPE hosts attached to a BMA LAN (usually Ethernet or Wi-Fi) that is in turn connected via a CPE router through an NBMA link (cable modem or DSL) to an ISP router that provides Internet access. Currently, there are two And what happens when there are multiple CPE routers a) connected via a BMA LAN to the DSL or cable modem and/or b) 'connected' via separate NBMA links but are on the same WAN subnet (assigned by the ISP) I think in the latter, if the ISP decides to silo the individual NBMA links then they need to adjust for that in how they do the sub-delegation which is I think what the issue is. But if the ISP actually bridges the separate NBMA links, then there's no silo issue and the CPE can pretend they're in 'a'. Antonio Querubin 808-545-5282 x3003 e-mail/xmpp: t...@lava.net ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: [TLS] Last Call: draft-ietf-tls-extractor (Keying MaterialExporters for Transport Layer Security (TLS)) to Proposed Standard
Many patents are filed for defensive reasons. Ie. If I don't patent it, then someone else will, and then I won't be able to use the idea I came up with. The other defensive reason is so that if company A tries to sue company B for infringing patents, then company B can threaten to sue company A back - and the end result of the mutual assured destruction is that no one ends up suing anyone else. In other words, patents can actually reduce the number of law suits out there. In many cases, patents are filed long before the technology is standardized - and, if disclosed properly through the IETF process, can be weighed when determining whether to adopt a standard. In some cases, the IETF may choose to adopt a patent-encumbered standard simply because it's technically superior to other options - and because the encumberence is not judged to be too much of a barrier to adoption. One great way to find out if the patent is too much of a barrier would be to label the technology as Experimental with the experiment being whether anybody would implement it given the patent encumberence, and if enough people can implement it, striking the right deals, then the technology can move onto the standards track. - Wes -Original Message- From: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On Behalf Of Richard Stallman Sent: Thursday, July 23, 2009 9:38 PM To: Nicolas Williams Cc: t...@ietf.org; d...@av8.com; ietf-hon...@lists.iadl.org; ietf@ietf.org Subject: Re: [TLS] Last Call: draft-ietf-tls-extractor (Keying MaterialExporters for Transport Layer Security (TLS)) to Proposed Standard The operative word here is uncertainty. A patent-holder creates uncertainty. How should an SDO respond? I'm not sure. I'm only sure that I don't like getting DoSed, either into dropping a standard or into not implementing it for fear of infringing. That's the nature of software patents: each one denies people the freedom to write and run certain kinds of software. This is why we must abolish software patents. Until we succeed in doing that, we can resist in certain ways. One of them is to refuse to establish standards that encourage their use. Generally speaking, standards are useful, because they enable people to converge what they are doing. But that ceases to be true when the use of the standard is patented. It is better to have no standard than have a standard that invites people into danger. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: xml2rfc is OK ( was: Re: XML2RFC must die, was: Re: Two different threads - IETF Document Format)
I created an xml2rfc template, like those available on xml.resource.org, which I copy and modify for new drafts, and use the web version of the tool - and everything works well enough for me. I'm decidedly not picky about formatting, because I want to spend my time contributing content. Because sometimes the error messages can be cryptic, when modifying the XML tags, I frequently submit the document and generate HTML in order to bound the number of XML tags that can contribute to a problem. - Wes -Original Message- From: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On Behalf Of Tim Bray Sent: Tuesday, July 07, 2009 12:26 AM To: Lars Eggert Cc: Iljitsch van Beijnum; IETF Discussion Mailing List Subject: Re: xml2rfc is OK ( was: Re: XML2RFC must die, was: Re: Two different threads - IETF Document Format) On Mon, Jul 6, 2009 at 12:18 AM, Lars Eggertlars.egg...@nokia.com wrote: since you asked: I have absolutely no problems with xml2rfc. I used to edit in nroff, which wasn't compatible with my brain, and I used Joe's Word template, which works OK, but I prefer something ASCII-based for collaborative editing (for svn, diff, etc.) I'm fully open to trying something new once someone creates a different (better) tool, but until then, xml2rfc is OK. What Lars said. -T ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: Changes needed to Last Call boilerplate
Note also that e-mails sent to ietf+draft-n...@ietf.org would not be sent to the general list of i...@ietf.org. I think this is potentially dangerous. I use the ietf@ietf.org list to find out about work that's going on that I wouldn't know to tune into. Sometimes the issues presented are not just relevant to the draft being discussed, but have some broader community impact. It is indeed this broader community impact that is often decided in an IETF Last Call, otherwise we would only have Working Group Last Calls and no IETF Last Call... - Wes -Original Message- From: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On Behalf Of Willie Gillespie Sent: Thursday, February 12, 2009 9:34 PM To: David Morris Cc: ietf@ietf.org Subject: Re: Changes needed to Last Call boilerplate David Morris wrote: Seems like a unique mailbox per lastcall would be very helpful all around. Right now, gathering and evaluating comments must be a nightmare. An alternative, would be a single LC mailbox as suggested, but require EVERY subject line to carry the last call ID, preferable in a form sensible to current mail clients. In the case of unique lists per lastcall, provide an opt-in metasubcribe to make it easy for folks who generally want to follow last call discussions to just be subscribed. *AND* require subscribe to post ... no cute confirm reply to bypass. I strongly believe that anyone who wants to provide feedback should want to see the comments on their feed back. [If the cute confirm created an automatic 48 hour subscription as per my next point, that would work too.] *AND* no unsubscribe or post only for 48 hours after initial subscription. For real participants, this wouldn't be an issue and for email campaigns, well they just need to experience the same disrruption their campaign causes. David Morris Not a bad idea. In fact, it may be useful to have a unique list per draft, so every comment relating to a particular draft can be tracked historically. This example is how I understand your suggestion: ietf+housley-tls-authz-ex...@ietf.org will automatically be set up with the initial ID submission. E-mails sent to it will be regarded as discussion pertaining to the draft. Individuals interested in following the draft may subscribe to that list simply by sending an e-mail to it. (However, e-mails with simply the word subscribe in the body or subject line won't be forwarded to everyone.) They are also allowed to unsubscribe (perhaps following the 48-hour waiting period of initial subscription as David suggested). Note also that e-mails sent to ietf+draft-n...@ietf.org would not be sent to the general list of i...@ietf.org. I doubt this sort of functionality currently exists in Mailman, but perhaps it could be implemented. Willie ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: Last Call for Comments: Proposed work-around to the Pre-5378 Problem
When will http://xml.resource.org/ and xml2rfc be updated to include this? Are there any changes we need to make to our input xml files? - Wes From: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On Behalf Of Ed Juskevicius Sent: Thursday, February 12, 2009 7:53 PM To: ietf@ietf.org; ietf-annou...@ietf.org; wgcha...@ietf.org; i...@iab.org; i...@ietf.org; rfc-edi...@rfc-editor.org Cc: Trustees; Contreras,Jorge Subject: Re: Last Call for Comments: Proposed work-around to the Pre-5378 Problem I am pleased to announce that the IETF Trustees have just finished work on a revision to our Legal Provisions Relating to IETF Documents policy. The revision includes optional new legend text in Section 6.c.iii of the policy to serve as a work-around for people experiencing the pre-5378 problem. Please note the newly approved policy is dated 2009-02-12. Please also note that the Effective Date of this revised policy has been set to 2009-02-15. The old policy (effective from November 10, 2008) remains in force until 00h00 UTC on February 15th. The approved text is available now on IETF Trust website at http://trustee.ietf.org/policyandprocedures.html Please look for the document dated 2009-02-12, just below the heading labeled DRAFT Policy and Procedures Being Developed. On or shortly after February 15th, the Trust website will be updated so as to archive all of the recent draft versions of the new policy, and to make it easier to navigagte to the newly approved policy. Please review the new policy so you are aware of the latest copyright statements and other boilerplate legend text that will be required on all contributions to the IETF starting on February 15, 2009. Regards, and Thanks in advance, Ed Juskevicius, on behalf of the IETF Trustees edj@gmail.com ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: Blue Sheet Change Proposal
Regarding the legal issues - if the sessions are broadcast over the Internet, and freely downloadable (w/o specifying or tracking who was downloading them), how can you be certain that someone was NOT aware of certain IPR? Also, if someone was in the room, how can you be certain they WERE aware of certain IPR? The only thing that the IETF can say is that every contribution to the IETF is considered to be publically disclosed, and this is indeed what the Note Well says. It seems to me that the IPR concerns are a red herring. - Wes -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Eric Burger Sent: Thursday, April 03, 2008 8:07 PM To: IETF Discussion Subject: Re: Blue Sheet Change Proposal Two purposes for Blue Sheets: 1. Redundant data entry: Quite often, the name is illegible, while the e-mail is legible. We don't care about the e-mail address, what we really care about is who was there. IMHO, this is the important use for capturing the e-mail address. 2. Legal issues: When the inevitable patent dispute happens, we WILL get served to report who was in the room when a particular subject was discussed. Other standards bodies have had this problem, if we haven't had it, it means our time is near :-( On 4/3/08 4:22 PM, Mark Andrews [EMAIL PROTECTED] wrote: All, We are considering changing the meeting Blue Sheet by eliminating the need to enter an email address to avoid spam concerns. Is there any good reason to retain that info bit? Ray ___ IETF mailing list IETF@ietf.org https://www.ietf.org/mailman/listinfo/ietf It's is the only unique token on the blue sheets. This assumes no shared email accounts which is a pretty reasonable assumption in this case. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: [EMAIL PROTECTED] ___ IETF mailing list IETF@ietf.org https://www.ietf.org/mailman/listinfo/ietf Notice: This email message, together with any attachments, may contain information of BEA Systems, Inc., its subsidiaries and affiliated entities, that may be confidential, proprietary, copyrighted and/or legally privileged, and is intended solely for the use of the individual or entity named in this message. If you are not the intended recipient, and have received this message in error, please immediately return this by email and then delete it. ___ IETF mailing list IETF@ietf.org https://www.ietf.org/mailman/listinfo/ietf ___ IETF mailing list IETF@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: IETF Last Call for two IPR WG Dcouments
I would think that any license for RFC code should meet two requirements: 1) It should be usable by anyone in the open source community (compatible with any open source/free software license). 2) It should be usable by anyone in any corporation who sells a closed source product. That way, we can ensure interoperability between open source and closed source implementations. Note that these requirements greatly constrain the form that the license should take. - Wes -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Margaret Wasserman Sent: Friday, March 28, 2008 2:30 PM To: Ray Pelletier Cc: Simon Josefsson; Joel M. Halpern; ietf@ietf.org Subject: Re: IETF Last Call for two IPR WG Dcouments Ray Pelletier wrote: The Trustees adopted the Non-Profit Open Software License 3.0 in September 2007 as the license it would use for open sourcing software done as work-for-hire and that contributed to it, at that time thinking of code contributed by IETF volunteers. See: http:// trustee.ietf.org/licenses.html Is it clear that the contributions contemplated by these documents would require a different treatment? Disclaimer: IANAL, and I apologize if I am misunderstanding something about the license you referenced, but... It seems to me that the Non-Profit Open Software License 3.0, while fine for the source code to IETF tools, places more restrictions and more burden on someone who uses the code than we would want to place on someone who uses a MIB, XML schema or other code from our RFCs. For example, the license places an obligation on someone using the source code to distribute copies of the original source code with any products they distribute. Effectively, this means that anyone who distributes products based on MIBs, XML schemas or other code from RFCs would need to put up a partial RFC repository. Why would we want that? Margaret ___ IETF mailing list IETF@ietf.org https://www.ietf.org/mailman/listinfo/ietf ___ IETF mailing list IETF@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: [Ltru] Possible RFC 3683 PR-action
The closest I could find was: Working groups SHOULD ensure that their associated mailing list is manageable. For example, some may try to circumvent the revocation of their posting rights by changing email addresses; accordingly it should be possible to restrict the new email address. from page 5 of RFC 3683. Misrepresented identities may fall under the same banner as changing email addresses for the purposes of RFC 3683. - Wes Beebee -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Russ Housley Sent: Monday, March 24, 2008 11:36 AM To: Christian Huitema Cc: ietf@ietf.org Subject: RE: [Ltru] Possible RFC 3683 PR-action I cannot find one. It seem to be a hole than needs filled. Russ At 11:45 AM 3/23/2008, Christian Huitema wrote: Does the IETF have a policy regarding misrepresented identities? In the particular incident, it is assumed that the person using the name of a famous French aviation pioneer is in fact someone else. On the one hand, using pseudonyms is a form of free speech. But on the other hand, in a standard setting body, hiding identities is not necessarily something we want to encourage. What are the implications for our standard process? What about copyrights and patents? -- Christian Huitema ___ IETF mailing list IETF@ietf.org https://www.ietf.org/mailman/listinfo/ietf ___ IETF mailing list IETF@ietf.org https://www.ietf.org/mailman/listinfo/ietf
