Re: [paws] Last Call: (Protocol to Access White Space (PAWS) Database: Use Cases and Requirements) to Informational RFC

Hi SM, I responded inline to your latest comments, below, where I took additional action. Thanks, Tony On Wed, Feb 13, 2013 at 4:33 AM, SM wrote: > Hi Anthony, > > At 17:00 12-02-2013, Anthony Mancuso wrote: > >> In Section 1.1: >> >> "Academia and Indus

Re: [Gen-art] Gen-ART LC Review of draft-bryan-metalinkhttp-19

any > removed parts to be the same as an "Okay" response. > > Thanks! > > Ben. > > On Feb 14, 2011, at 4:43 PM, Anthony Bryan wrote: > > [...] > >> was there supposed to be a comment along with >> >> -- section 2, 4th paragraph: "HTTP mi

Re: Gen-ART LC Review of draft-bryan-metalinkhttp-19

tance Digest from the Metalink server, then the client SHOULD fetch the Metalink/XML (if available) that could contain partial file cryptographic hashes which will allow detection of which mirror server returned incorrect data. Metalink clients SHOULD figure out w

RE: [secdir] [OAUTH-WG] ** OAuth Tutorial & OAuth Security Session **

Cc: Anthony Nadalin; Tschofenig, Hannes; ab...@ietf.org; r...@ietf.org; ietf@ietf.org; sec...@ietf.org; web...@ietf.org; x...@ietf.org; kit...@ietf.org; i...@iab.org Board; i...@ietf.org; oa...@ietf.org Subject: Re: [secdir] [OAUTH-WG] ** OAuth Tutorial & OAuth Security Session ** I would say

RE: [OAUTH-WG] ** OAuth Tutorial & OAuth Security Session **

I was looking for less of an analysis and more of considerations (of the current flows and actors), I'm not sure how to adapt what you have done to actually fit in the current specification, was your thought that you would produce a separate security analysis document? -Original Message

Re: XML related issues in metalink, was: Last Call: draft-bryan-metalink (The Metalink Download Description Format) to Proposed Standard

On Sun, Dec 13, 2009 at 2:39 PM, Julian Reschke wrote: > Anthony Bryan wrote: >>> >>> 3) XML vs whitespace >>> >>> I'm not sure I understand the whitespace treatment. >>> >>> One example has: >>> >>>   >>>

Re: XML related issues in metalink, was: Last Call: draft-bryan-metalink (The Metalink Download Description Format) to Proposed Standard

tegers, or IRIs." > (Note I didn't review the spec, I just did a few XML related checks) Thank you, Julian, for these needed checks! Your fresh eyes picked up things unnoticed. "It takes a whole village to raise a spec" :) F

Re: Last Call: draft-bryan-http-digest-algorithm-values-update (Additional Hash Algorithms for HTTP Instance Digests) to Informational RFC

ines values for digest algorithms used by Instance Digests in HTTP. Note: This is unrelated to HTTP Digest Authentication. Instance Digests in HTTP provide a digest, also known as a checksum or hash, of an entire representation of the current state of a resource. -- (( Anthony Bryan ... Metalink

Re: Last Call: draft-bryan-http-digest-algorithm-values-update (Additional Hash Algorithms for HTTP Instance Digests) to Informational RFC

; the reason why we have them and make them more useful for other use cases? > > I am just looking for clarifications. > > EHL > > >> -Original Message- >> From: Anthony Bryan [mailto:anthonybr...@gmail.com] >> Sent: Friday, December 04, 2009 5:21 PM >

Re: Last Call: draft-bryan-http-digest-algorithm-values-update (Additional Hash Algorithms for HTTP Instance Digests) to Informational RFC

of >> the Subject line to allow automated sorting. >> >> The file can be obtained via >> http://www.ietf.org/internet-drafts/draft-bryan-http-digest-algorithm- >> values-update-03.txt >> >> >> IESG discussion can be tracked via >> https://data

DRAFT-IETF-GEOPRIV-RADIUS-LO-23

t RADIUS accounting data that includes location information cannot be re-transmitted to another realm? If so, then this document would disrupt the transmission of accounting data which is legally required to be maintained by statues such as Sarbanes Oxley. Thanks, Antho

RE: several messages

systems, so you can ensure that everyone can use them. My $.02 Regards, Anthony On Thu, 13 Nov 2008 06:43:17 -0800, "Hallam-Baker, Phillip" <[EMAIL PROTECTED]> wrote: > This is a somewhat silly discussion, pretty much the ONLY real reason to > use your own domain rather th

Last Call: draft-ietf-hokey-erx to Proposed Standard

mponent ensuring that even the most diligent of engineers will miss/misinterpret a required or optional behavior. References: [1] https://drum.umd.edu/dspace/bitstream/1903/3038/1/interauth.pdf [2] http://tools.ietf.org/html/draft-clancy-eap-rekeying-00 Thanks, -Anthony Leibovitz _

Last Call: draft-ietf-hokey-erx to Proposed Standard

mponent ensuring that even the most diligent of engineers will miss/misinterpret a required or optional behavior. References: [1] https://drum.umd.edu/dspace/bitstream/1903/3038/1/interauth.pdf [2] http://tools.ietf.org/html/draft-clancy-eap-rekeying-00 Thanks, -Anthony Leibovitz _

Re: Last Call: 'Proposed Experiment: Normative Format in Addition to ASCII Text' to Experimental RFC (draft-ash-alt-formats)

Clement Cherlin writes: > It's true that Unicode font support is somewhat spotty. It's worse than spotty; it is quite poor. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf

Re: Why not PDF: Last Call: 'Proposed Experiment: Normative Format in Addition to ASCII Text' to Experimental RFC (draft-ash-alt-formats)

Peter Dambier writes: > Just try this good example: > > http://www.nasa.gov/pdf/133654main_ESAS_charts.pdf > > It is a nice promotion for the successor to the space shuttle. > Best store it localy before viewing. > > It is a nice document with wonderful pictures. But building > the screens takes m

Re: Image attachments to ASCII RFCs (was: Re: Last Call: 'Proposed Experiment: Normative Format in Addition to ASCII Text' to Experimental RFC (draft-ash-alt-formats))

Hallam-Baker, Phillip writes: > Try a bank of flashing LEDS. Even banks of flashing LEDs are rare these days. I recall mainframes with large control panels that were awash in LEDs (or small neon lamps, earlier on), and I thought they were exceedingly cool (and still do). But they were very expe

Re: Reality (was RE: Stupid NAT tricks and how to stop them.)

Peter Sherbin writes: > It is worth about the same as a postal address that comes > naturally when they build a new house. In a similar way when a new > device comes to existence it gets an address out of infinite > universe of 0 and 1. That would only be true if IP addresses were geographically

Re: Reality (was RE: Stupid NAT tricks and how to stop them.)

John C Klensin writes: > So, let's assume that I'm an ISP and (i) I discover that I've > switched to IPv6 to avoid needing to use private addressing in my > core network, (ii) I discover that it is now costing me more to > support IPv4 customers (because they require protocol and address > transla

Re: Reality (was RE: Stupid NAT tricks and how to stop them.)

Iljitsch van Beijnum writes: > That's the popular view. In reality, people deployed NAT mostly for > reasons that have little to do with the global IPv4 address > depletion. They deployed it mainly because getting an IPv4 address costs money, and involves considerable red tape. Mainly because

Re: Copyright status of early RFCs

Carl Malamud writes: > RFCs are for all practical purposes in the public domain and it would > be a very gutsy RFC author that went to court and tried to show that > they had systematically defended their copyright over the last X years > and were thus entitled to assert copyright this year. Whil

Re: Stupid NAT tricks and how to stop them.

Peter Dambier writes: > http://www.manitu.de/ > > They offer you: > > fixed IPv4 address with reverse lookup at 9.99 Euros per month. I don't live in Germany. The exception does not disprove the rule. ___ Ietf mailing list Ietf@ietf.org https://www

Re: Stupid NAT tricks and how to stop them.

John Calcote writes: > I'll just jump in here for a second and mention also that vendors > offer what they have to, not what they can. They want to provide the > most "bang for the buck", so to speak. These companies don't offer > the multiple-static-ip-address option today because most ISP's don'

Re: 128 bits should be enough for everyone, was: IPv6 vs. Stupid NAT tricks: false dichotomy? (Was: Re: StupidNAT tricks and how to stop them.)

Iljitsch van Beijnum writes: > And in reaction to other posts: there is no need to make the maximum > address length unlimited, just as long as it's pretty big, such as > ~256 bits. But there isn't much reason to not make it unlimited, as the overhead is very small, and specific implementations

Re: 128 bits should be enough for everyone, was:

Dave Cridland writes: > I do understand your argument, and you're correct in all its > assertions, but not the conclusion. I suspect that's the case for > everyone at this point. Not as long as I still see people claiming that 128 bits will provided 2^128 addresses _and_ that it can still be div

Re: 128 bits should be enough for everyone, was:

Theodore Ts'o writes: > You've been making the same point over and over (and over) > again. To some, perhaps. I'm not so sure that it has yet been made even once to others. > It's probably the case that people who will be convinced by your > arguments, will have accepted the force of your argum

Re: 128 bits should be enough for everyone, was: IPv6 vs. Stupid NAT tricks: false dichotomy? (Was: Re: StupidNAT tricks and how to stop them.)

Stephen Sprunk writes: > An IPv4/6 address is both a routing locator and an interface identifier. And so engineers should stop saying that n bits of addressing provides 2^n addresses, because that is never true if any information is encoded into the address. In fact, as soon as any information i

Re: 128 bits should be enough for everyone, was: IPv6 vs. Stupid NAT tricks: false dichotomy? (Was: Re: StupidNAT tricks and how to stop them.)

Stephen Sprunk writes: > And sequential assignments become pointless even with 32-bit > addresses because our routing infrastructure can't possibly handle > the demands of such an allocation policy. They are pointless for the reasons you state, but they are also the only way to get 2^128 addresse

Re: 128 bits should be enough for everyone, was:

Austin Schutz writes: > But this has been known all along. It's a feature, not a bug. Yeah, right. > If we "throw away" the last 64 bits we are left with 2**64 addresses, > which is obviously what was intended from the beginning. And when you allocate bit fields in the remaining 64 bits, you ex

Re: Stupid NAT tricks and how to stop them.

Keith Moore writes: > I find myself wondering, don't they get support calls from customers > having to deal with the problems caused by the NATs? Sure, and the reply is "I'm sorry, but we don't support multiple computers on residential accounts." ___

Re: 128 bits should be enough for everyone, was:

Steve Silverman writes: > The problem with allocating numbers sequentially is the impact on > routers and routing protocols. The problem with not doing so is that a 128-bit address doesn't provide anything even remotely close to 2^128 addresses. You have to choose what you want. > I have heard

Re: 128 bits should be enough for everyone, was: IPv6 vs. Stupid NAT tricks: false dichotomy? (Was: Re: Stupid NAT tricks and how to stop them.)

Iljitsch van Beijnum writes: > When I first learned about IPv6 I felt strongly that 128 bits was too > much, especially since all those bits have to be carried in every IP > packet twice, once as a source address and once as a destination > address. When I first learned about IPv6 I started wor

Re: Stupid NAT tricks and how to stop them.

Andrew McGregor writes: > Not if you don't live in the US. There are no options here that are > at all cheap. Usually you get a flat "we don't do that". And they > don't do v6 either. True. > And people wonder why NATs proliferate... much of the world has no > option but to live with them. T

Re: 128 bits should be enough for everyone, was: IPv6 vs. Stupid NAT tricks: false dichotomy? (Was: Re: Stupid NAT tricks and how to stop them.)

Iljitsch van Beijnum writes: > So how big would you like addresses to be, then? It's not how big they are, it's how they are allocated. And they are allocated very poorly, even recklessly, which is why they run out so quickly. It's true that engineers always underestimate required capacity, but

Re: IPv6 vs. Stupid NAT tricks: false dichotomy? (Was: Re: Stupid NAT tricks and how to stop them.)

Scott Leibrand writes: > Well, in the case of IPv6 we're currently playing in a sandbox 1/8 the > size of the available address space. So the lifetime of IPv6 will be 8 times its current age, since the remaining 7/8 will probably be blown just as quickly. > So if what you say is true, and we man

Re: IPv6 vs. Stupid NAT tricks: false dichotomy? (Was: Re: Stupid NAT tricks and how to stop them.)

Thomas Narten writes: > This is FUD. Care to back up your assertions with real analysis? Sure. The consistent mistake engineers make in allocating addresses is that they estimate capacity in terms of sequential and consecutive assignment of addresses--but they _assign_ addresses in terms of bit

Re: IPv6 vs. Stupid NAT tricks: false dichotomy? (Was: Re: Stupid NAT tricks and how to stop them.)

Mark Andrews writes: > Which was why IPv6 when to 128 bits rather than 64 bits. That won't help. It will add perhaps 25% to the lifetime of the address space, no more. > 64 bits of address space would have been fine to give > everyone all the addresses they would need. 128 bits gives > them al

Re: IPv6 vs. Stupid NAT tricks: false dichotomy? (Was: Re: StupidNAT tricks and how to stop them.)

Joel Jaeggli writes: > I find it interesting that our vision is frequently so short-sighted that > we can't even envision in the course of an arguement the applications that > are possible today let alone the ones that people will want in the future. And one consequence of this is that we cannot

Re: IPv6 vs. Stupid NAT tricks: false dichotomy? (Was: Re:StupidNAT tricks and how to stop them.)

Hallam-Baker, Phillip writes: > My point was that even if we do run out of /64s at some point the > last few remaining /64s can be made to go one heck of a long way. So the address space will ultimately be managed in crisis mode, because it was so badly mismanaged to begin with. Why does that so

Re: IPv6 vs. Stupid NAT tricks: false dichotomy? (Was: Re: StupidNAT tricks and how to stop them.)

Hallam-Baker, Phillip writes: > That is not a real problem. I've lost count of the number of times I've heard _that_. Eight bits, sixteen bits, thirty-two bits, sixty-four bits, and now 128 bits ... they are all "good for eternity" for at least a few years, and then suddenly they are out of spac

Re: Stupid NAT tricks and how to stop them.

Scott Leibrand writes: > They could do so (when they implement IPv6) by running dual-stack routers. Ah, so they aren't doing it _now_. They'll probably be doing it Real Soon Now. > My ISP doesn't yet provide IPv6 support. But at some point they (or > another ISP) will. I guess that's when you

Re: IPv6 vs. Stupid NAT tricks: false dichotomy? (Was: Re: Stupid NAT tricks and how to stop them.)

Scott Leibrand writes: > We definitely will have to see how it shapes up in the US. In Japan, > where they actually have IPv6 deployed to end users, it looks like most > ISPs are giving out /64's to home users, and /48's to business users: Looks like IPv6 will be exhausted even sooner than I pre

Re: Stupid NAT tricks and how to stop them.

Scott Leibrand writes: > Um, have you heard of dual stack? My Windows XP does it quite > transparently (after I enable IPv6 at the command line), and presumably > Vista will do IPv4/IPv6 dual stack transparently without any command-line > enabling. How does your ISP handle this? How much extra

Re: IPv6 vs. Stupid NAT tricks: false dichotomy? (Was: Re: Stupid NAT tricks and how to stop them.)

Scott Leibrand writes: > They can charge for IPv4 addresses because they're perceived to be scarce. > With IPv6 they may be able to charge for allowing me a /48 instead of a > /56 or /64, but IMO they won't be able to assign me a /128 by default and > charge me if I want a /64. They will charge y

Re: Stupid NAT tricks and how to stop them.

Keith Moore writes: > true. people do all kinds of evil things that break the net. Yeah ... like charging for IP addresses that should be free. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf

Re: Stupid NAT tricks and how to stop them.

Keith Moore writes: > don't think upgrade; think coexistence. How do IPv4 and IPv6 coexist? Like ASCII and EBCDIC, perhaps? > As an engineer, the right thing to do is to transition away from NAT > (along with IPv4), so that eventually it can be discarded. I'm not aware of a smooth transition o

Re: Stupid NAT tricks and how to stop them.

Keith Moore writes: > and at some delta-T in the future, some things will be different. it > might (or might not) be that lots more hosts run v6, it might (or might > not) be that NATs are discredited, it might (or might not) be that the > Internet mostly exists to connect walled gardens. Probabl

Re: Stupid NAT tricks and how to stop them.

Keith Moore writes: > NAT is a dead end. If the Internet does not develop a way to obsolete > NAT, the Internet will die. I hardly think so, but in any case, the solution is pretty simple: give out IP addresses for free, instead of charging an arm and a leg for anything other than a single addre

Re: IPv6 vs. Stupid NAT tricks: false dichotomy? (Was: Re: Stupid NAT tricks and how to stop them.)

Scott Leibrand writes: > NAT (plus CIDR) was the short-term solution, and is realistic as a > medium-term solution. In the long term, though, I don't think it will be > the only solution. It will be if ISPs continue to charge for extra IP addresses, as they probably always will. > And if someda

Re: Call for input: draft-hartman-mailinglist-experiment-00.txt

Sam Hartman writes: > I'm interested in feedback on the following issues: > > * Is 18 months too long for the experiment. I don't think so but have > received one comment requesting 12 months. > > * Are there limits that need to be placed on the IESG's authority? My > preference is to grant th

Re: Fairness and changing rules

Sam Hartman writes: > I'd like to understand why changing the rules in the middle of a > process is a bad idea. They aren't rules if they can be changed even as they are being applied. If you want to make rules, you have to be willing to abide by them. Changing the rules even as they are applie

Re: I-D ACTION:draft-ash-alt-formats-01.txt

Joel M. Halpern writes: > First and foremost, if the input format is PDF, how will the RFC Editor > edit the document? PDF documents are not editable. PDF is designed to be uneditable. It's for final versions of a document, and the difficulty involved in trying to edit it is one of its most use

Re: IAB Response to Appeal from Jefsey Morfin

Harald Tveit Alvestrand writes: > Thank you for the processing of this request. > > However, this mailing list maintainer is now completely uncertain about > what his marching orders are with regards to continuing to administer the > ietf-languages list. > > The IAB seems to have decided that it's

Re: I-D ACTION: draft-ash-alt-formats-01.txt

John Levine writes: > Among valid PDFs, do you include PDFs that are coded to prohibit text > extraction? How about PDFs that are just bitmap scans of printed > documents, like the PDF versions of some early RFCs from the 1970s? Use the most conservative (and thus probably the earliest) version

Re: "too many notes" -- a modest proposal

Theodore Ts'o writes: > As a gentle suggestion from one of the Sargeant-At-Arms. If > you were to keep track of how many messages you have been posting > compared to others, I think you would find that you are one of the > more prolific posters on this thread. And if you were to look at the tota

Re: Weekly posting summary for ietf@ietf.org

Thomas Narten writes: > [note: I find this type of summary to be a useful tool for > highlighting certain aspects of list traffic. With Brian Carpenter's > blessing, I plan on making this a regular feature for the ietf list.] > > Total of 312 messages in the last 7 days ending midnight January 25.

Re: "too many notes" -- a modest proposal

Gray, Eric writes: > This is simply not true. All one needs to do is publish a > crucial document relevant to the working groups charter, > and important to understanding the rest of the work, and > one will be inundated with questions. Then maybe message traffic is not a reliable indicator of

Re: "too many notes" -- a modest proposal

Noel Chiappa writes: > In that case, there's no harm in the rest of us deciding we don't need the > dubious "assistance" of few of the most troublesome, and least productive, is > there? Actually there is, because there's very little correlation between being "troublesome" on a mailing list and b

Re: "too many notes" -- a modest proposal

Andy Bierman writes: > If we did this, our mailing lists would be bombarded with SPAM > from non-subscribers. Then accept e-mail only from subscribers. > There is an appeals process (of that we are too painfully aware) > that can be used for people who are told by a WG Chair that > they are usin

Re: "too many notes" -- a modest proposal

Brian E Carpenter writes: > Exactly. If a WG group is discussing a dozen separate issues in parallel, > an active participant can easily send several dozen *constructive* > messages in a day. Our problem with disruptive messages can't be solved > by counting bytes. Set a rolling monthly quota, th

Re: Questions for those in favor of PR-Actions in general

Randy Presuhn writes: > A more accurate restatement is that some good people have > already left because participation in the IETF was sufficiently > unpleasant for them, and that other productive people are on the > verge of leaving for the same reason. Well, if they can't stand the heat in the

Re: "too many notes" -- a modest proposal

Andy Bierman writes: > I think you missed my point. > I should have said "enforce or abide by draconian rules". > Automating the process is even worse. > Then stupid scripts disrupt WG activity on a regular basis. > Inappropriate mailing list use should be dealt with by the > WG Chair(s) in a more

Re: "too many notes" -- a modest proposal

Andy Bierman writes: > I do not share your regulatory zeal. > As a WG Chair and WG participant, I have enough rules to follow already. > The last thing I want to do is count messages and bytes, and enforce > draconian rules like this. But counting messages and bytes happens to be something that c

Re: "too many notes" -- a modest proposal & Re: Proposal for keeping "free speech" but limitting the nuisance to the working group (Was: John Cowan supports 3683 PR-action against Jefsey Morfin)

Jeroen Massar writes: > Limiting to less than 3 per day would be the same as suspending for X > hours. They would both be the same only if they were carried out in the same way. If either method is applied to specific users, it's still just arbitrary censorship. If it is applied equally to ever

Re: "too many notes" -- a modest proposal

Steve Silverman writes: > It seems to me that limiting users to 3 messages / day (perhaps with > a maximum number of bytes) would be a minimal impact on free speech > but would limit the damage done by overly productive transmitters. > This could be limited to users who are nominated to a "limit"

Re: Questions for those in favor of PR-Actions in general

Michael StJohns writes: > Now the IETF environment of 1990 is quite different than the one > today. How? And why? ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf

Re: "too many notes" -- a modest proposal

Michael Thomas writes: > Perhaps we should take a lesson from TCP and set a receive window > on IETF mailing lists in the face of conjestion. The sender is thus > obligated to keep the transmission within the window, and as a side > effect to consider the quality of the, um, quantity. Just this si

Re: Free speech? Re: Against "PR-action against Jefsey Morfin"

grenville armitage writes: > Must admit I always thought it was constructive speech (in the sense > of attempting to engineer solutions, new architectures, protocols or > clarity of understanding) that was at the core of discussions at IETF. Then I suppose that threads such as "Meeting Survey Res

Re: Against "PR-action against Jefsey Morfin"

Harald Tveit Alvestrand writes: > thanks for informing us that you're discussing that the IETF Last Call > that started this debate was concerned with behaviour on the ietf-languages > and ltru lists, not the IETF list. Read the Last Call: > >

Re: Against "PR-action against Jefsey Morfin"

Noel Chiappa writes: > OK, I'll bite. How do you reconcile this principle with defending someone who > has tried to get people penalized for saying what they think? It seems to me > that there's a logical contradiction there: Jefsey gets to say whatever he > wants, but others can't? > > I refer yo

Re: posting privileges vs receiver-side filtering

Brian E Carpenter writes: > The IETF standards process requires us to archive WG mailing lists. > For good reasons: open process requires a public record, and prior art > claims can be checked. How much of an open process can there be if some input is censored? > Not true. When one receives a fe

Re: John Cowan supports 3683 PR-action against Jefsey Morfin

Pekka Savola writes: > Why must each and every WG member be required to filter a person's > postings? Much more convenient to do so in one place. Because each and every WG member is an individual, with his own ideas of what he does or doesn't want to read, and imposing the same rules upon everyo

Re: junior lawyers, was List archives and copyright

John Levine writes: > Can I politely encourage people who are not lawyers to refrain from > expressing legal opinions here, or even worse stating legal opinions > as though they were facts? Why? IP litigation is usually a roll of the dice, anyway. > I know just enough about copyright law to kno

Re: John Cowan supports 3683 PR-action against Jefsey Morfin

Joel M. Halpern writes: > Assuming I have properly understood Mr. Morfin's email, the best argument I > have seen for permitting all IETF email list adminsitrators to ban him as > they deem necessary is his own description of his behavior. > > Mr. Morfin appears to have stated that if he feels an

Re: posting privileges vs receiver-side filtering

grenville armitage writes: > - protects agains dilution of a WG's historical record (archives > that soak up all posts to the WG's mailing list) Stop blindly archiving every message, and this ceases to be a problem. > - improves the 'signal to distraction' ratio of traffic on the list > (particu

Re: IETF Last Call under RFC 3683 concerning JFC (Jefsey) Morfin

Dave Crocker writes: > There is a basic difference between preventing the expression of an opinion, > idea or the like, versus preventing what is effectively a denial of service > attack on the conduct of group business. Yes. A denial of service attack is a technical attack on a server or networ

Re: John Cowan supports 3683 PR-action against Jefsey Morfin

Theodore Ts'o writes: > The problem with the "just filter" approach is that if you then fail > to respond to something of substance that got inadvertently filtered > out, it is trivially easy to claim rough consensus. The problem with prior restraint, such as a ban, is that nobody ever gets to re

Re: List archives and copyright [WAS Re: John Cowan supports 3683 PR-action against Jefsey Morfin]

Jeroen Massar writes: > IANAL but one really doesn't have to bother with US law, that really > doesn't apply to many folks (fortunately :) The laws of other developed countries are frequently even more restrictive when it comes to copyright. > There is a much better thing > than US law, it's cal

Re: List archives and copyright [WAS Re: John Cowan supports 3683 PR-action against Jefsey Morfin]

Michael Froomkin - U.Miami School of Law writes: > If you post to a list with a publicly announced public archive -- and even > more so if you are informed about the archive at the time you join the > list (hint: you usually are) -- then I think it's pretty clear under US > law (and, I'd imagine b

Re: OT: The case of sysop twit

Frank Ellermann writes: > Are you sure that you have read and understood > ? I'm sure that I'm not interested in it. It has nothing to do with the IETF. ___ Ietf mailing list Ietf@ietf.org https://www1.

Re: suggestion on distributed systems

Steven M. Bellovin writes: > Nonsense. Tanenbaum has forgotten more about operating systems than > most of us will ever know. He has apparently forgotten a lot of things that I remember, or, more likely, he just has never been exposed to them. In his book he writes about the things he knows, wh

Re: John Cowan supports 3683 PR-action against Jefsey Morfin

Stephane Bortzmeyer writes: > It is not just a matter of personal inconvenience: if the filtering is > done at the edges and not in the IETF mailing list engine, it also > means that public email archives (which are a very important tool for > the IETF) are polluted by the useless messages sent by

Re: John Cowan supports 3683 PR-action against Jefsey Morfin

Jeroen Massar writes: > And then suddenly somebody makes a seriously good contribution and your > filter accidentally filters out that message which does have a lot of > value and thus importance for the working group. Banning someone has the same effect, if that person has ever made any useful c

Re: John Cowan supports 3683 PR-action against Jefsey Morfin

John Cowan writes: > Filtering him out individually, as I do, is insufficient: one still must > read the polite or exasperated responses of others. I am almost at the > point where I will filter any posting that so much as *mentions* him. Why don't you do that, then, so that he need not be banne

Re: suggestion on distributed systems

Peter Dambier writes: > "Operating Systems, Design and Implementation" by > Andrew S. Tannanbaum and Albert S. Woodhull, > ISBN 0-13-638677-6 Prentice Hall > > Not only do the discuss every aspect of an operating system but > they include as an example and for homework practice the complete > Mini

Re: how to declare consensus when someone ignores consensus

[EMAIL PROTECTED] writes: > Can you imagine if during every murder trial they had a debate on > the humanity of capitol punishment? Can you imagine if, in every business meeting, people who disagreed decided to sue each other? > Please, if you don't have an opinion specifically related to > Jefs

Re: how to declare consensus when someone ignores consensus

John Loughney writes: > Now we're close to side veering off into process issues, but > rather than going into that rat-hole, I'll just pose a question: do > you think p2p protocol authors would have any motiviation to create > a Security Considerations section that would pass IESG review? Do you

Re: how to declare consensus when someone ignores consensus

Robert Sayre writes: > I suspect the IESG will find that the folks actually trying to get > work done in the presence of JFC's emails all feel the same way. Most > of the objections seem to be coming from people concerned with > designing the perfect bureaucratic process. In any WG, there are > im

Re: how to declare consensus when someone ignores consensus

John Loughney writes: > People who suggest ignoring or hitting delete don't seem to > really get it ... People who insist that this doesn't work don't seem to really get it. It has worked for me for decades. The reality is that some people are irritated by the need to do anything they don't want

Re: IETF Last Call under RFC 3683 concerning JFC (Jefsey) Morfin

Adrian Farrel writes: > If those who would exclude Jefsey from certain lists feel that repeated 30 > day bans are too much work, I suggest they draft a new process that would > allow them to create longer bans on specific lists. An alternative would be for them to find new jobs that don't include

Re: FW: IETF Last Call under RFC 3683 concerning JFC (Jefsey) Morfin

John Levine writes: > I cannot tell you how many lists I've been on that have been in > exactly our situation, paralyzed by one or two people who skate along > the edge of being kicked off, choking the list with clouds of > irrelevant smoke. There's always the same arguments, if we were > discipl

Re: FW: IETF Last Call under RFC 3683 concerning JFC (Jefsey) Mor fin

[EMAIL PROTECTED] writes: > [EMAIL PROTECTED] I take a look at the IETF email after four months and > it's still the same discussion as when I left! I notice the same thing. The Harper Valley PTA is still very much at work, but technical issues seem to be few and far between. > What, are you g

Re: IETF Last Call under RFC 3683 concerning JFC (Jefsey) Morfin

Tim Bray writes: > Ban him. Openness and inclusiveness are virtues, but not absolutes. They are only virtues when they are absolute. > This ban seems to me an expression of respect for the time and energy > of many dedicated and talented participants here, which are currently > being wasted by

Re: IETF Last Call under RFC 3683 concerning JFC (Jefsey) Morfin

Are people on this list still arguing about this? I thought members of this list were supposed to be grown-ups (?). ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf

Re: The rights of email senders and IETF rough consensus

wayne writes: > The definition of "unacceptably high false positive rate" can *only* > be defined by the receiver of the email. It's difficult to do that if the intended receiver of the e-mail never sees the e-mails that are rejected. The false-positive rate will then appear to be perpetually ze

Re: RFCs should be distributed in XML (Was: Faux Pas -- web publi cation in proprietary formats at ietf.org

Juergen Schoenwaelder writes: > Every little open source software project uses version control systems > these days. The IETF does not. And interestingly, the IETF even likes > to standardize this stuff (look at the WebDAV RFCs). Personally, I > liked CVS and I do even more appreciate SVN these da

Re: Diagrams (Was RFCs should be distributed in XML)

Stewart Bryant writes: > However these are not taken as normative, so you have to > produce an ASCII equivalent, which fundamentally limits the > complexity of any normative diagram. Depends. If the ASCII document is large enough, in theory you can represent any monochrome image with an arbitrar

Re: Diagrams (Was RFCs should be distributed in XML)

Joe Touch writes: > XML is modern? Where's the modern, WYSIWYG, outline-mode capable > editor? And does one exist that's free? XML is fashionable, not necessarily functional. There's a difference. > (I'd love to work in XML, but it seems like a 20-yr step backwards > to manually edit the source

Re: Diagrams (Was RFCs should be distributed in XML)

Randy.Dunlap writes: > SVG was mentioned (as spec'd by w3.org IIRC). > > So check out Inkscape: > "using the W3C standard Scalable Vector Graphics (SVG) file format." > > Available for multiple platforms. > > http://www.inkscape.org/ Using an open format that requires people to install spec

Re: Faux Pas -- web publication in proprietary formats at ietf.org

Hallam-Baker, Phillip writes: > Because they are your customers. The reader/author relationship is only very rarely comparable to the customer/vendor relationship. For many authors, money is not that important. > No, the author can not possibly know the needs of the reader. The reader can pick

  1   2   3   4   5   >