Re: Call for Consensus: IETF Administrative Restructuring
--On tirsdag, oktober 26, 2004 21:52:12 -0700 Lee <[EMAIL PROTECTED]>
wrote:
I seem to have missed the consensus agreement somewhere along the line,
could someone please state what the statement is that we are suppose to
be consenting to before I agree or disagree. As it stands now, as one of
the silent members, I disagree.
To quote from the message:
We believe that the IETF community opinion has converged on a rough
consensus to restructure our administrative support activity as described
in this recommendation ("Scenario O").
The document describing the recommendation is:
draft-iab-iesg-adminrest-rec-00.txt
I've been burned a little too many times by trying to summarize a document
and have people argue with my summarization rather than what is in the
document so I will just recommend that you read the document, and then
answer based on that - whether you agree that we should follow this
recommendation, or whether you disagree that we should follow this
recommendation.
Harald
___
Ietf mailing list
[EMAIL PROTECTED]
https://www1.ietf.org/mailman/listinfo/ietf
Re: Call for Consensus: IETF Administrative Restructuring
I seem to have missed the consensus agreement somewhere along the line, could someone please state what the statement is that we are suppose to be consenting to before I agree or disagree. As it stands now, as one of the silent members, I disagree. If you disagree with our determination of IETF consensus, or if you have any other comments on this consensus call or on the document describing the recommendation, please send them to the IETF mailing list ([EMAIL PROTECTED]) by Monday, November 8, 2004. ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
Re: Re: A new technique to anti spam
Hi,Dave Aronson, > (BTW, those two characters before the ! just show up as empty boxes > here.) These words are in Chinese. I\'m not good at E > I would certainly hope so. Otherwise it would be worse than useless. Thankyou > > And in the case we are concerned with, that of the spammer, what is to > prevent the sender smtp server from claiming zero percent chance? Or, > if the white-hats realize \"zero means it must be from a spammer\", > spammers could claim some random very low percentage. A). 1.We must be sure the purpose of spammers making spam-pointer is they wish the receivers download the email-content. 2.Where the receivers download is \"Email-content server\". 3.The authority database guarantee all \"Email-content servers\" are related with legal ESPs. 4.legal ESPs don\'t wish their users be spammers 5.those spammer who making spam-pointer aren\'t belong to legal ESPs. 6.Their \"Email-content servers\" are illegal. 7.the receivers won\'t download the email-content from illegal servers. B). This tech can work together with \"SenderID\" to confirm the sender ID C) The spammer can create a lot of spam-pointer point to ONE email which is on a legal server. How to prevent it? The legal \"Email-content servers\" provides \"retr\" and \"top\" command to let users download the content. \"retr\" can only be used once. \"top\" can be used more than once. \"retr\" is more popular than \"top\". So only the first receiver can download the junk-mail from the legal server through the spam-pointer,and the second receiver can\'t download it if he use \"retr\" command. D)It\'s difficult to confirm the qualification of \"Email-content servers\". But I think CA can works,it can works too. > welcome! ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
Re: Re: A new technique to anti spam
Hi,Harald Tveit Alvestrand, First,this tech is an \"anti-spam by macroeffect\" and also based \"human psychological warfare\", it may not work right-now. Then,it\'s a more complex system but only on server-side,simple on client-side.What we think is if users need it?Maybe the answer is no!Who knows? > Worrisome side effect: > > I can now only read the mail as long as the sender\'s mail server remains > online. > > If the evaluation happens at read-time, not at fetch-time, this also means > that if I use \"file-and-forget\", as I do with many mailing lists, and > return to my archive a year later, many of the messages won\'t be there, > since I didn\'t read them, and the senders have later moved on. > > So in practice, I have to let my computers evaluate the request and fetch > the message with no human interaction. Some bandwidth may be saved, but the > email infrastructure became more complex. > > Worth it? > > Harald > > welcome! ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
re: Call for Consensus: IETF Administrative Restructuring
> If you disagree with our determination of IETF consensus, or if you have any > other comments on this consensus call or on the document describing the > recommendation, please send them to the IETF mailing list ([EMAIL PROTECTED]) by > Monday, November 8, 2004. I trust its also OK to say that I agree Scott ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
Re: I-D ACTION:draft-lyons-proposed-changes-statement-01.txt
--On tirsdag, oktober 26, 2004 15:50:07 -0400 Patrice Lyons <[EMAIL PROTECTED]> wrote: Thanks for sharing your thoughts about this. As I recall, at a meeting with you and Leslie in January 2004, you told me about a proposal under consideration that involved the donation of a patented architecture to the IETF. You mentioned a group that wanted to donate the technology, but I don't know if that has progressed in the interim. By donation, I mean such things as pooling patents in order to give technology to the IETF at little or no cost (whether or not under license). ISOC was mentioned in this context. This came up again informally during a coffee break at the ISOC Advisory Comm. meeting in Barcelona where I recall some discussion of possible interoperability testbeds for purposes of IETF architecture deliberations. Thank you for the clarification - I had understood this mechanism to be a granting of licenses under common terms to the members of the IETF community, with the IPR owners keeping all ownership rights - but I've never built a patent pool, so it's entirely too possible that I misunderstood. Harald ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
Re: I-D ACTION:draft-lyons-proposed-changes-statement-01.txt
Harald, Thanks for sharing your thoughts about this. As I recall, at a meeting with you and Leslie in January 2004, you told me about a proposal under consideration that involved the donation of a patented architecture to the IETF. You mentioned a group that wanted to donate the technology, but I don't know if that has progressed in the interim. By donation, I mean such things as pooling patents in order to give technology to the IETF at little or no cost (whether or not under license). ISOC was mentioned in this context. This came up again informally during a coffee break at the ISOC Advisory Comm. meeting in Barcelona where I recall some discussion of possible interoperability testbeds for purposes of IETF architecture deliberations. It was my understanding that one motivating factor in the admin. restructuring process was the need to have a corporate entity to receive such donations of patents; ISOC also has some interest in this. While this notion hasn't been developed to any extent, as far as I am aware, there is an important kernel of thought here that needs to be addressed. Since the late 1980s when I first became involved in considering IPR policies for the IETF, I have been well aware of the need to be flexible with respect to copyright, patent and other rights and interests in an IETF context. Again, checks and balances are essential here. Regards, Patrice - Original Message - From: "Harald Tveit Alvestrand" <[EMAIL PROTECTED]> To: "Patrice Lyons" <[EMAIL PROTECTED]>; "Joel M. Halpern" <[EMAIL PROTECTED]> Cc: <[EMAIL PROTECTED]> Sent: Thursday, October 21, 2004 10:54 AM Subject: Re: I-D ACTION:draft-lyons-proposed-changes-statement-01.txt> --On torsdag, oktober 21, 2004 08:10:07 -0400 Patrice Lyons <[EMAIL PROTECTED]> wrote: In this context, there has been some talk of donation recently of patents for IETF, particularly a group of patents, for IETF purposes at little or no cost. could you give a little more pointer here, please? All the talk I've heard recently is about free/no-paperwork licensing of patents for use in implementing IETF protocols - I haven't heard anything about giving patents to the IETF. But then, I am not party to all conversations. Harald ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
objections: draft-ietf-enum-epp-e164-06.txt
Hi All, I would like to raise an issue with this draft which is currently in "Last Call" in regards to the storage of the extension element: Currently: 3.1.2 EPP Command . . The element contains one or more elements that contain the following child elements: . . 3.2.1 EPP Command . . The element contains one or more elements that contain the following child elements: . . 3.2.5 EPP Command . . The element contains one or more or elements. Each and element contains an element that contains the following child elements: . . Objection: The mandatory inclusion of one or more elements is the major point of contension. By way of using the current epp schema for domain mapping, elements may be used to point to external DNS servers which will host the owning NAPTR records. Thus creating a "thin" enum registry while still accepting and generating "referral" e164 domains. This allows the registry to host the native NAPTR records and all the personal details that come along with that data or allow an external name service to host these dynamic NAPTR records. As a further extension to the current support for is the ability to allow or support. These would work much like the above approach, in that the zone generated by the registry would point to an external DNS that would then resolve the actual NAPTR records for public use. While these are more experimental additions, they are a valuable addition to the draft, while enum trials are taking place to see how usability case studies perform in the real world. To ensure the integrity of the e164 domain, only one of the four types may be associated with an e164 domain at a time. The four types are , , and . This way the zone generated for the e164 domain names will have a deterministic output each and every time. frank thompson Afilias Canada Inc. ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
