RE: draft-kolkman-appeal-support
Sam, et al, I doubt that noting an appeal has been determined to have merit is especially useful. As Sam implies below, it is possible to have controversy over this point, and any controversy is likely to mean no annotation of merit will occur in many cases. Ignoring for the moment the potential for recursion (do we need to have supporters for the merit of an appeal after the fact?), it seems to me that it might be more useful to treat any appeal for which there was not an absolute consensus that no merit could be ascribed to the appeal, as an appeal with merit. -- Eric -- -Original Message- -- From: Sam Hartman [mailto:[EMAIL PROTECTED] -- Sent: Tuesday, October 17, 2006 11:11 AM -- To: Michael Thomas -- Cc: John C Klensin; Ned Freed; ietf@ietf.org; Eliot Lear -- Subject: Re: draft-kolkman-appeal-support -- -- Michael == Michael Thomas [EMAIL PROTECTED] writes: -- -- Michael John C Klensin wrote: -- (1) The supporter procedure/requirement should be triggered -- only is someone shows symptoms of being a vexatious -- appellant. -- People who are entering their first appeals don't trigger it. -- People whose last appeal was successful, even in part (that -- would need to be defined, of course, and that might not be -- easy) don't trigger it. The only folks who need to look for -- supporters are those who have appealed before and -- whose appeals -- have been rejected as without merit. -- -- -- -- Michael Can an appeal be rejected with merit? -- -- Yes. I think Robert's recent appeal was rejected that way. I -- personally think that Jefsey's appeal against the LTRU registry doc -- set was a reasonable appeal although we declined to make -- any changes. -- I suspect many people may disagree with me and argue that -- this appeal -- was without merit. -- -- I think the SPF and Sender ID appeals clearly had merit. -- I'm not sure -- whether we rejected them though. -- -- -- ___ -- Ietf mailing list -- Ietf@ietf.org -- https://www1.ietf.org/mailman/listinfo/ietf -- ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: draft-kolkman-appeal-support
This reply was inadvertently blind copied to the ietf mailing list. I meant to have it plain copied, but dropped it a line to low... -- Eric -- -Original Message- -- From: Gray, Eric -- Sent: Monday, October 16, 2006 2:04 PM -- To: 'Olaf M. Kolkman' -- Subject: RE: draft-kolkman-appeal-support -- -- I think, to address the comment, you would have to change the phrase to -- end with there are not sufficient qualified supporters. -- -- David wrote: -- Perhaps Olafur might even be convinced to produce text in his draft -- that encourages individuals to provide their support in proxy, or to -- allow IAB/IESG members to waive. -- -- _Olaf_ :-) wrote in the I-D: --Note that the appeal body may choose to consider an appeal even when -- there are not sufficient supporters. -- -- -- -- -Original Message- -- -- From: Olaf M. Kolkman [mailto:[EMAIL PROTECTED] -- -- Sent: Monday, October 16, 2006 1:20 PM -- -- To: ietf@ietf.org -- -- Subject: Re: draft-kolkman-appeal-support -- -- -- -- ___ -- -- Ietf mailing list -- -- Ietf@ietf.org -- -- https://www1.ietf.org/mailman/listinfo/ietf -- -- -- ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: [Nea] WG Review: Network Endpoint Assessment (nea)
I completely agree with Noel on every detail of these comments. And, no, I was not one of the complainers either. :-) -- Eric -- -Original Message- -- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] -- Sent: Wednesday, October 11, 2006 11:26 AM -- To: ietf@ietf.org -- Cc: [EMAIL PROTECTED] -- Subject: Re: [Nea] WG Review: Network Endpoint Assessment (nea) -- -- From: Steven M. Bellovin [EMAIL PROTECTED] -- -- it is better that we aren't copied because to do so -- would be unfair to -- the complainer(s). -- -- As much as I've sparred with Glassey in the past ... -- I think he's right -- in this case. In my opinion, any sort of disciplinary -- action needs to -- be *perceived* as fair. ... I think we do need to -- follow due process. -- -- I'm going to disagree with you on this. My reasoning is -- that the decision of -- whether or not to suspend should be based almost entirely -- on the target -- person's posts, so the identity (and, indeed, the number) of people -- complaining is basically irrelevant. -- -- The whole concept of facing your accuser came about -- because the accusers -- usually made factual claims (I saw Joe steal Frank's -- car). Traditionally, -- people wanted to be able to weigh the truthfulness of such claims by -- observing the person making the assertion, and observing -- their response to -- questioning. In addition, the target might know of some -- grudge that led the -- accuser to make a false accusation. In this case, however, there is -- absolutely no probative value coming from knowing *who* complained. -- -- To put it another way, I would hope if several people -- complained about some -- reasonable post, the SaA(s) would independently review the -- post, and if they -- thought it was reasonable, would take no action, the number -- or identity of -- the complainers notwithstanding. The issue is not who -- complained - the issue -- is the content of the posts - and that's all. -- -- Indeed, any miniscule probative value in knowing who -- complained is entire -- outweighed, IMO, by the possibility that making their -- identities public would -- result in a campaign of harrassment against them. -- -- And no, I was not one of the people who complained privately. -- -- -- I do agree that the Sergeants-at-Arms can act on -- their own volition, -- but if they do they should say so -- -- I have no probem with the SaA(s) disclosing whether or not -- they acted -- entirely on their own bat, in response to complaints, or -- both. In addition, I -- have no problem with them disclosing the number (if any) of -- complainters. -- -- However, I strenuously oppose making the names public, -- because the potential -- harm in that (possibility for harassment, and also the -- possibility that -- less-forthcoming people will sit on their hands rather than -- complain, if -- their names have to be made public) far outweighs any -- possible value in in -- mking them public. Indeed, it turns out that most police -- departments actually -- have anonymous tip lines, for precisely these reasons (and others). -- -- -- If the community decides to do elsewise, I offer myself up -- as an anonymizing -- agent for any complaints to the SaA(s); i.e. I will forward -- any complaints -- sent to me, as if they were my own, after removing the -- identity of the -- former. If I can recruit a few other people to do the same, -- that will suffice -- to avoid any issue with one person not being able to -- complain more than once. -- -- Noel -- -- ___ -- Ietf mailing list -- Ietf@ietf.org -- https://www1.ietf.org/mailman/listinfo/ietf -- ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: Proceeding CDs
It makes sense now, but will it make sense in 10 years? With today's DVD technology, is it completely unlikely that ISO CD formats may not be supported by then? Is it not possible that CDs will go the way of 8-track tapes, beta-max, and 3.25 floppy and 100 Mega-byte Zip drives? I can store more data on a memory stick than I can on a CD. In 10 years, I expect I'll be able to store as much as 20 times the data of a CD on a stick - and I don't think the stick uses the ISO format. It would be a shame to have to support an ISO format converter in 10 years so that people could access the older IETF documents and proceedings... -- Eric -- -Original Message- -- From: Michael C. StJohns [mailto:[EMAIL PROTECTED] -- Sent: Friday, October 06, 2006 2:14 PM -- To: Andy Bierman; [EMAIL PROTECTED] -- Cc: ietf@ietf.org -- Subject: Re: Proceeding CDs -- -- At 01:57 PM 10/6/2006, Andy Bierman wrote: -- If I really wanted to have a CD of the proceedings, -- then I would want to retrieve a .iso file from the archive. -- -- Actually, I *like* this option a lot. -- -- I don't see any reason to continue to produce the CDs, but -- I do see a -- need for a permanent archival form and having an ISO I -- could download -- and burn (or mount for that matter) makes a lot of sense. -- -- Mike -- -- -- ___ -- Ietf mailing list -- Ietf@ietf.org -- https://www1.ietf.org/mailman/listinfo/ietf -- ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: Facts, please, not handwaving [Re: Its about mandate RE: Why cant the IETF embrace an open Election Process]
Eliot/Brian, This, I think, is part of the problem. To say that it is well understood that the Internet mainly runs on Proposed Standards, is to indulge in over-simplification. And to say we are not actually following our documented process - is to focus on the meta-issues when the problem is with what is documented in the RFCs themselves, in many cases. One of the useful features of the current process is that it means the community has one or two opportunities to insist that what is technically documented is in alignment with reality. For many of the most important RFCs, it takes more than competence and an RFC to implement what's actually going to work in the Internet. A significant amount of the time it either takes lab testing, some snooping on what goes on the wire, some reverse engineering and at least one more iteration of lab testing - or it takes being on the inside track in dominant (or early) implementation. One of the reasons why it _looks_ like the Internet mainly runs on Proposed Standards, is that the people who know about the difference between what's technically done, and what's technically documented, have no real incentives to get involved in efforts to document what they know - thus letting future competitors have the information for free. This is - I believe - a key factor in why most Proposed Standards do not progress to Draft Standard. This factor has come up repeatedly in the efforts to advance Proposed Standards that I've been involved in, and it usually adds years to the process. But another factor is that we (as in the IETF) aren't usually satisfied with just documenting what is really being done. For one reason or another, many of us would like to fix the Standard to - for example - make it consistent with protocols and specifications we've developed since then, even if that means documenting protocol behaviors that are inconsistent with what is really being done. These factors just adds to the burden. Because it is not easy to progress along the standards track, many (if not most) Proposed Standards only roughly document what the Internet runs on. I would argue that Proposed Standard as the end-of-the-line in our standardization process is just wrong. I certainly can see an argument for merging Proposed and Draft - but there are lots of indications that even the simplified one-step process of moving from Draft to full Standard would not get done much of the time. There are examples of ways to deal with this difficulty from other standards groups. The issue we need to decide as a group is whether we're happy with our (slightly) imperfect process, or we would like to adopt (and/or modify) someone else's. -- Eric -- -Original Message- -- From: Eliot Lear [mailto:[EMAIL PROTECTED] -- Sent: Monday, September 18, 2006 4:13 AM -- To: Brian E Carpenter -- Cc: ietf@ietf.org -- Subject: Re: Facts, please, not handwaving [Re: Its about -- mandate RE: Why cant the IETF embrace an open Election Process] -- -- Brian E Carpenter wrote: -- Phill, -- -- As a result the IETF is a standards body with 2000 active -- participants that produces on average less than 3 -- standards a year -- and typically takes ten years to produce even a specification. -- -- It is well understood that the Internet mainly runs on Proposed -- Standards, -- so the appropriate metric is how many Proposed Standards the IETF -- produces -- a year. I think you will find that is more than three. -- -- I have to agree. Going back to the numbers I posted to -- NEWTRK in March: -- -- Status 1999200020012002200320042005 -- - -- PS 102 119 71 105 103 131 169 -- -- -- -- This represents a tremendous amount of work by many people. And so -- while I *do* believe we have process problems, they are -- largely of the -- form that we are not actually following our documented -- process. I also -- believe that we need to be more nimble when it comes to changing our -- processes. I would like to see both of those problems -- corrected in due -- course. -- -- I have not done the work to review velocity from -00 to -- RFC, but perhaps -- Bill Fenner has. -- -- Eliot -- -- ___ -- Ietf mailing list -- Ietf@ietf.org -- https://www1.ietf.org/mailman/listinfo/ietf -- ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: security features.... (Re: Facts, please)
Harald, The below is an easy mis-construction to make - from discussion within the IETF, involving security experts. What I believe I've actually seen is along the lines of we don't want your favorite security/authentication because it is likely to be mis-represented as having resolved security issues it has already been determined it does not resolve. One case where this has come up, is in discussions of the use of TCP/MD5 - where the problem is not so much that anyone mis-represents it as almost anybody can use it with little - or no - work to be done. There's certainly a degree of legitimacy in the concerns about possible misrepresentation. If it's for free - then it is really tempting to try to represent it as adequate (unless you're selling a product that does something better). From that, it is not hard to see how someone might get the idea that ease of use might be a problem with a security/authentication mechanism. It's certainly easy to see how this would be doubly true in any easy to use solution someone might wish to propose that is already known to be less than perfect... -- Eric --- [SNIP] --- -- The requirements needed to be satisfactory depend very much on your -- viewpoint; last week I talked to the guy who implemented Freenigma -- (PGP for web mailers, http://www.freenigma.com), and he commented that -- this will never get past the security gurus in the IETF because it's -- so simple, people might actually use it. -- -- That says something frightening about the kind of impression we give -- to people who work on making usable security. Usable needs to be an -- important component of satisfactory. -- -- (He's quite aware of the obvious security defects of his scheme, btw. -- It's a tradeoff.) -- --Harald --- [SNIP] --- ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: Last Call: 'A Lightweight UDP Transfer Protocol for the the I nternet Registry Information Service' to Proposed Standard (draft-ietf-cr isp-iris-lwz)
Sam, I thought the Security Area Directorate was limited to determining if the description of security risks is adequate and that determination of whether security is adequate - for adequately described security risks - would be up to the end consumer. Is that not correct? Certainly it will be the case that - if product consumers disagree with a finding within the IETF - they may very well go ahead and buy products that the IETF has determined not to have adequate security. In that case, what the IETF has rejected on the basis of security concerns, will become a defacto standard without the blessing of the IETF. I'm sure this is an old, often rehashed, argument - but I just wanted to be sure about your comments... -- Eric -- -Original Message- -- From: Sam Hartman [mailto:[EMAIL PROTECTED] -- Sent: Thursday, August 17, 2006 11:03 AM -- To: Mark Townsley -- Cc: ietf@ietf.org; iesg@ietf.org -- Subject: Re: Last Call: 'A Lightweight UDP Transfer -- Protocol for the the Internet Registry Information Service' -- to Proposed Standard (draft-ietf-crisp-iris-lwz) -- -- Mark == Mark Townsley [EMAIL PROTECTED] writes: -- -- Mark Sam Hartman wrote: -- I notice that this transport provides no -- authentication of the -- data that is retrieved. -- -- The security considerations needs to discuss the potential -- attacks if an attacker modifies this public data. -- The security -- considerations section also needs to point to best -- practice for -- avoiding UDP reflection attacks. It is not good -- enough to say -- Do what other people do. -- -- s/reflection/amplification sorry -- -- Mark 1. If a request requires authentication, -- confidentiality, -- Mark or other security, use another transfer protocol. -- -- Mark It seems to me that the intent is to not provide -- Mark authentication here. This seems more fundamental -- than a fix -- Mark by reference. -- -- Sure. What I'm asking for is that they explain what the -- consequences -- of providing no authentication are. I'll then evaluate those -- consequences and either conclude that authentication is not required -- for this data for an Internet deployment or come back with another -- comment that the security is inadequate. But the first step of -- determining whether the security is adequate is to -- determine the risk. -- -- ___ -- Ietf mailing list -- Ietf@ietf.org -- https://www1.ietf.org/mailman/listinfo/ietf -- ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: [INDEP] Re: RFC Editor RFP Review Request
Yaakov, It might be me, but it seems (to me) that - if you think through what you've said - it is not consistent. Maybe it's simply an issue of relative time scales. Your last statement - that a break in the series would invalidate it - argues very forcibly that no such gap can be allowed to occur going forward (unless you are of the opinion that IP, TCP, UDP etc. are done evolving). Hence, something would have to take the place of the IETF and the RFC series practically immediately. Don't you agree? -- Eric -- -Original Message- -- From: Yaakov Stein [mailto:[EMAIL PROTECTED] -- Sent: Tuesday, August 08, 2006 2:41 AM -- To: Keith Moore; Joe Touch -- Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED]; ietf@ietf.org; -- [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED]; -- [EMAIL PROTECTED]; [EMAIL PROTECTED]; independent@ietf.org -- Subject: [INDEP] Re: RFC Editor RFP Review Request -- -- -- That vast number does not establish the credibility of -- the series; the -- -- original ones do. -- -- IP, TCP, UDP, etc would not cease to be used -- if either the IETF or the RFC editor disappeared, -- or even if their original RFCs forgotten. -- -- The main importance of the RFC series is the -- demonstration of continuity -- from the early roots and the present IETF work. -- -- The credibility of the original standards (not the series) is -- important, -- but were there a gap between then and now, -- the series would be rendered useless. -- -- Y(J)S -- -- -- ___ -- INDEPENDENT mailing list -- INDEPENDENT@ietf.org -- https://www1.ietf.org/mailman/listinfo/independent -- ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: [Fwd: I-D ACTION:draft-carpenter-rescind-3683-00.txt]
Harald, Especially this simile. The way I read this draft, it suggests that the IETF in general has found the choice between fixed length suspensions and indefinite suspension altogether too restraining. The explicit wording of the 2 paragraphs of substantive text is that the IESG was implicitly allowed to use progressively longer suspensions for repeat offenders - prior to our arriving at the present combination of implicit and explicit interpretations of existing documents - and suggests that a return to this model is actually better in the short term than a continuation of the current highly controversial and inneffective situation. I can - by no stretch of the imagination - make this conform to your weather analogy. The current situation is felt by many to be worse than the previous situation. Even if there is a proposal on the table right now that seems likely to be better than either, it still makes sense to revert to the previous situation as soon as we can possibly do so. -- Eric -- -Original Message- -- From: Harald Alvestrand [mailto:[EMAIL PROTECTED] -- Sent: Thursday, August 10, 2006 5:23 PM -- To: Frank Ellermann -- Cc: ietf@ietf.org -- Subject: Re: [Fwd: I-D ACTION:draft-carpenter-rescind-3683-00.txt] -- -- Frank Ellermann wrote: -- Harald Alvestrand wrote: -- -- -- Don't throw away the umbrella because you're buying a -- raincoat next week. It's still raining. -- -- -- If the umbrella is Sam's experiment, and the raincoat -- Brian's draft, then the latter didn't propose to throw -- away the former. Are you talking about something else ? -- -- 3683 = umbrella against a hail of messages -- Long term suspensions under draft-hartman = raincoat -- -- Brian's draft = throwing away. -- -- Similes are hard -- -- -- ___ -- Ietf mailing list -- Ietf@ietf.org -- https://www1.ietf.org/mailman/listinfo/ietf -- ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: Minutes and jabber logs
List of attendees? Surely that is actually independent of the minutes... -- -Original Message- -- From: Brian E Carpenter [mailto:[EMAIL PROTECTED] -- Sent: Tuesday, July 18, 2006 6:14 AM -- To: David Harrington -- Cc: ietf@ietf.org -- Subject: Re: Minutes and jabber logs -- -- Just a reminder of what our process rules (RFC 2418) say: -- -- All working group sessions (including those held -- outside of the IETF -- meetings) shall be reported by making minutes available. These -- minutes should include the agenda for the session, an -- account of the -- discussion including any decisions made, and a list of -- attendees. The -- Working Group Chair is responsible for insuring that -- session minutes -- are written and distributed, though the actual task may -- be performed -- by someone designated by the Working Group Chair. The -- minutes shall -- be submitted in printable ASCII text ... -- -- We don't insist on the list of attendees when that is in -- the blue sheets, -- but it's clear that the minutes have to be readable (an -- account of the -- discussion including any decisions made) and that is not usually -- the state of a raw jabber log. It's important, since the -- decisions taken -- in a meeting have to be confirmed on the list - if the minutes are -- properly written, it's enough to ask for agreement on the minutes. -- -- A carefully edited jabber log can of course be just fine. -- -- (All of this applies equally to meetings at IETF sites, -- interim meetings, -- WG conference calls, and WG jabber conferences - readable -- minutes must be -- agreed on the list.) -- -- Brian -- -- -- David Harrington wrote: -- Hi, -- -- I would not like to see raw jabber logs included as part of the -- minutes. The signal-to-noise ratio is way too low in many -- meetings. -- -- Jabber logs written by a scribe do not do a good job -- representing the -- body language and the nuances of speech that may be important to -- really understand what a person said. I would also be -- concerned that -- there are side-discussions in jabber that are not relayed -- to the whole -- room; including those side conversations as a reflection -- of what was -- said in the meeting is simply misleading. -- -- It is the chair's job to provide a summary of the meeting for the -- mailing list to see what was discussed and decided. I -- do not think -- the chair should be allowed to evade this responsibility by simply -- posting a quick summary and the raw jabber logs to the -- mailing list as -- the official minutes. -- -- David Harrington -- [EMAIL PROTECTED] -- [EMAIL PROTECTED] -- [EMAIL PROTECTED] -- -- -- -- -Original Message- -- From: Spencer Dawkins [mailto:[EMAIL PROTECTED] -- Sent: Monday, July 17, 2006 11:18 AM -- To: ietf@ietf.org -- Subject: Re: Meetings in other regions -- -- -- That said, and given the difficulties of balancing competing -- priorities in site location, it seems reasonable to me to make -- a decent, good-faith effort without getting overly bogged down -- in where should we meet? discussions, and really try to get -- the remote participation thing nailed down a little better. The -- ratio of good to bad remote meeting input has improved a lot -- over the past year or so but there are still too many working -- groups without a Jabber scribe in the room (which prevents remote -- listeners from providing inputs), etc. -- -- OK, this is only a thought, and I'm out of the process -- improvement business -- anyway, but I've been seeing a consistent improvement in the -- quality of -- jabber logs for at least two years, and I'm wondering if -- there are working -- groups who would be willing to try minutes = chair summary -- plus jabber -- logs for a few IETFs (without what we usually think of -- as detailed -- -- -- minutes), and see if this is actually workable. -- -- I'm a many-time repeat offender as WG note-taker, and am -- watching my notes -- look more and more like a jabber log with only one jabberer; -- the advantages -- of jabber (in my experience) are -- -- - it's nice for the note-taker to be able to participate in -- the meeting - as -- an extreme case, in the SIPPING Ad Hoc on Friday, Gonzalo and -- Mary handed me -- the mike about twenty times, but very litte of what I said -- appeared in the -- notes, and it's worse when someone is already talking when I -- stop talking. -- That's typical in my experience. With Jabber, people can type -- until I get -- back to my seat. -- -- - It's really nice when I misquote, or mis-attribute, -- something that was -- said and another jabberer corrects it right away. This is SO -- much better -- than the WG chair having to listen to the audio stream to -- check my notes -- after some number of days has elapsed (and sometimes all the -- chair can tell -- from the audio is that I got it wrong, without knowing
RE: The IETF 66 Attendees Alias
Ray, May I make a suggestion for the next time around? How about if the registration page asks if you want to be subscribed to this list? As I understood it, this experiment was performed at the request of people on the ietf discussion mailing list. That list is _not_ the appropriate place to talk about cookie shortages, mail and netowrk problems and issues with the hotel, _either_. Since the registration page already has a number of questions it ask about things we might or might not want to do. Why not add one more - and assume the default answer is no? I like the idea of having a separate list because it allows me to decide quickly what I can safely ignore most of the time. -- Eric -- -Original Message- -- From: Ray Pelletier [mailto:[EMAIL PROTECTED] -- Sent: Monday, July 10, 2006 10:53 PM -- To: [EMAIL PROTECTED] -- Cc: ietf@ietf.org -- Subject: Re: The IETF 66 Attendees Alias -- -- Alan, et al. -- Message received. -- I agree. -- Changes being made. -- Experiment provided valuable information. -- Sorry for the pain. -- Ray -- IAD -- -- -- Alan Hawrylyshen wrote: -- -- Folks; -- -- I understand the utility and need for the administrative -- staff to have -- a mailing alias for all registered delegates for the 66th -- IETF event. -- However, in all the meetings I have attended - which is -- more than a -- few, but less than most of you - I have never been -- deluged with such a -- volume of non-critical announcements in my main inbox. -- -- I hope that people will understand my strong desire and sympathize -- with my point of view when I request that all general -- IETF messages be -- posted uniquely to the IETF general list and that this address be -- reserved only for the critical or emergency announcements by the -- administrative staff. One step better would be for this -- address to be -- moderated so we no longer receive various complaints about water -- closets and wifi unless we seek them out on the IETF -- discussion lists. -- :-) -- -- Perhaps if there is a strong desire to have a 'hallway or -- watercooler -- style' list for discussions pertaining uniquely to IETF -- 66 attendees, -- we could create a NEW mailing list that is OPT-IN called -- 66attendees-chat (or similar) at ietf.org. I'd even -- volunteer to set -- one up (at a different domain of course) for the duration -- of IETF 66. -- -- My sincere apologies if I have misunderstood the purpose of the -- 66attendees address but my BlackBerry is going crazy with -- things that -- I would not normally choose to have in my commercial, -- corporate email -- box. -- -- Respectfully, -- -- Alan Hawrylyshen -- -- ___ -- Ietf mailing list -- Ietf@ietf.org -- https://www1.ietf.org/mailman/listinfo/ietf -- -- -- ___ -- Ietf mailing list -- Ietf@ietf.org -- https://www1.ietf.org/mailman/listinfo/ietf -- ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: are we willing to do change how we do discussions in IETF?
Are you sure about this? There are a significant number of people in this forum who are so convinced of the infallibility of their own logic that to be in the not agreeing set - from their perspective - MUST be the inevitable result of being also in the not listening set... :-) -- Eric -- -- There's quite a difference between not listening vs. not -- agreeing. -- ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: are we willing to do change how we do discussions in IETF? (w as: moving from hosts to sponsors)
Tom, This would be a bad idea as a general rule - though it is (I believe) one of the things that ADs look at. The problem is that there are good examples of WGs where the chair was a key author as well and it worked just fine. In addition, there are also examples where a chair has had to step in because (as is often the case when dealing with volunteers) nobody else would step up to the task. -- Eric --[SNIP]-- -- -- I think that the single change most likely to keep WGs on track is to ensure -- that they do not have a single dominant participant, eg one who is both chair -- and author of key I-Ds. The WGs I see most at risk of going round in circles -- and/or producing output that falls short of what is needed are ones such. -- --[SNIP]-- ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: Image attachments to ASCII RFCs (was: Re: Last Call: 'Propose d Experiment: Normative Format in Addition to ASCII Text' to Experimental RFC (draft-ash-alt-formats))
Ned, What would be useful - in even more than this context - would be if there was a peer-level directory where source for all RFCs would be kept adjacent to the RFCs derived from them. In addition to giving us some concrete evidence of how many RFCs use each source format, it would greatly simplify the process of writing new drafts... -- Eric --[SNIP]-- -- The thing I'd like to have that isn't already there is a way to get -- the xml2rfc sources the RFC editor used back for comparison purposes. -- ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: Last Call: 'Proposed Experiment: Normative Format in Addition to ASCII Text' to Experimental RFC (draft-ash-alt-formats)
Thomas, This is a different discussion, however, you are right on target with that discussion - at least for IDs in general. Wouldn't this be subject to a DoS attack, if applied to individual ID submissions? -- Eric -- -Original Message- -- From: Thomas Narten [mailto:[EMAIL PROTECTED] -- Sent: Thursday, June 15, 2006 11:12 AM -- To: Ash, Gerald R (Jerry), ALABS -- Cc: Bob Braden; ietf@ietf.org -- Subject: Re: Last Call: 'Proposed Experiment: Normative -- Format in Addition to ASCII Text' to Experimental RFC -- (draft-ash-alt-formats) -- -- It is quite reasonable to last call this draft at this -- point. It has -- been reviewed for ~6 months. This version posted to the list for -- comments more than 3 weeks ago, plenty of time for more -- comments, but no -- comments were posted to the list on this version. -- -- Maybe reviewer fatigue? -- -- One thing missing from this discussion (that I think would have been -- helpful) is running all the previous comments through an issue -- tracker, so folk could go review the history, and most important of -- all, those who raised issue can go see if they believe their issues -- have been dealt with appropriately. One of the most frustrating and -- demoralizing aspects of IETF participation is spending time doing a -- careful review, and then feeling like your comments have been blown -- off. Trackers make it much harder for that to happen, which in my -- experience is a very good thing for all involved. -- -- Thomas -- -- ___ -- Ietf mailing list -- Ietf@ietf.org -- https://www1.ietf.org/mailman/listinfo/ietf -- ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: Last Call: 'A Process Experiment in Normative Reference Handl ing' to Experimental RFC (draft-klensin-norm-ref)
Brian, I had responded to Eric Rosen's note earlier (see my mail of Thu 6/1/2006 12:07 PM EDT) - in particular concluding: I - for one - see nothing either false or misleading in the proposed note. I also find that addition of such a note is substantially less onerous than alternatives we have now... In the event that this was not clear, I support this experiment. I think it is worth adding that we might not know the outcome of such an experiment for many years - because it may take that long to determine whether or not this approach is more or less painful than the current process. -- Eric -- -Original Message- -- From: Brian E Carpenter [mailto:[EMAIL PROTECTED] -- Sent: Monday, June 12, 2006 6:20 AM -- To: C. M. Heard -- Cc: iesg@ietf.org; ietf@ietf.org -- Subject: Re: Last Call: 'A Process Experiment in Normative -- Reference Handling' to Experimental RFC (draft-klensin-norm-ref) -- -- C. M. Heard wrote: -- On Thu, 1 Jun 2006, Eric Rosen wrote: -- -- There are also other reasons why I find this -- proposed experiment -- disheartening. -- -- For one thing, it really misses the point. We -- need to simplify our -- processes, not make them more complicated. Either we -- need the downref rule -- or we don't. If we want to experiment, let's -- experiment with eliminating -- the rule entirely, not with fine tuning it. -- -- The real underlying problem of course is the the -- multi-stage standards -- process is just a relic from another time, and makes no -- sense at all in the -- current environment. Experiments in fine tuning the -- process are nothing but -- a distraction. -- -- -- For the record, I completely agree with the above -- sentiments (and have so -- stated on the newtrk mailing list). -- -- I'd like to ask people who *don't* agree with the above sentiments -- (i.e. who support this experimental process change) to say -- so, before -- the Last Call ends in two days. (Obviously, people who *do* -- agree are welcome -- to say so too, but a problem with Last Calls is that it's -- very hard to -- judge whether silence means consent.) -- -- Brian -- -- -- -- ___ -- Ietf mailing list -- Ietf@ietf.org -- https://www1.ietf.org/mailman/listinfo/ietf -- ___ 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)
Spencer, This opens up yet another can of worms. Suppose that everybody who makes a comment on a draft (substantive, or otherwise) has to be listed and every one listed is bound by BCPs relating to IPR, copyright, etc. in RFC content. What happens if someone - perhaps having suggested that a word was misspelled - would prefer not to be bound by the BCPs (or perhaps is not permitted to be so bound)? Can they request to be left out? If they do, can an editor leave them out? It occasionally happens now that a draft departs from the original direction that some of the contributors wanted it to go, and - slightly less often - those that disagree with the outcome ask to be de-listed. There are good and reasonable reasons to allow this - especially as there may be very strong reactions from a particular employer that is seen as advocating something they do not intend to do. In such cases, these early contributors provided much of the content - even if the over-all outcome is not in line with their intentions. So, again, would we be able to omit their names? -- Eric -- -Original Message- -- From: Spencer Dawkins [mailto:[EMAIL PROTECTED] -- Sent: Wednesday, June 07, 2006 7:48 AM -- To: ietf@ietf.org -- Subject: Re: Acknowledgements section in a RFC (Was: Last -- Call: 'Matching of Language Tags' to BCP (draft-ietf-ltru-matching) -- -- Perhaps I lead a sheltered life, but on two of these points... -- -- - Appendix A - some names seem to be missing. I could -- quote a small -- score of them? -- -- I do not know if there are written rules about the -- Acknowledgements -- or Credits section in a RFC. It seems quite variable between the -- RFCs. I am mentioned in draft-ietf-ltru-matching-14 for -- what I regard -- as a very small contribution and not in RFC 4408 where I -- feel that my -- contribution is more substantive. -- -- Dear Stephane, -- This may seem trivial, but IMHO quoting every contributor -- is important for -- several key reasons. -- -- - the IETF is made of paid and free volunteers. The -- reward of the free -- participants is their exposure. If we want top quality -- participants we -- must acknowledge their contributions. -- -- This is a real concern (I am a working group draft editor -- for a draft where -- probably 30 percent of the e-mail I've received on the -- draft has been about -- acknowledgements). I thought it was a more serious concern -- for academics and -- consultants, but am now seeing the same concerns from -- corporate standards -- types and development engineers in other working groups. I -- have expressed -- this as a concern in private e-mail, but don't know what -- the answer is. -- -- - the IPR is to all the co-authors. Every person having -- contributed a -- word, a concept, a change, positively or negatively is a -- co-author. This -- also has some importance to show the document is not the -- work of an -- affinity group (as discussed in RFC 3774) but of a true WG. -- -- In my limited SDO experience, beyond IETF I am most familar -- with IEEE 802.1 -- practice, which is to list participants (at least, this -- is what appears in -- the most recent IEEE 802.1 standard appearing on Getieee802 at -- http://standards.ieee.org/getieee802/download/802.1AB-2005.p -- df), where the -- list is membership at the time of approval, and balloted -- at various -- times. -- -- Since we have no clue who the membership of an IETF -- working group is, I -- don't know how to do the equivalent thing here. -- -- Spencer -- -- -- -- ___ -- Ietf mailing list -- Ietf@ietf.org -- https://www1.ietf.org/mailman/listinfo/ietf -- ___ 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)
John, I disagree both in the belief that the Note Well is clear on this and the sense of your argument that anyone participating in any part of a discussion can be made retroactively responsible for the entire discussion. The Note Well is not clear because it makes sweeping statements about the way in which BCP 78 and 79 may apply to contributions. The obvious (but not clear) intent is that what you contribute is now subject to provisions of these BCPs that apply to contributions. What is both more subtle and not clearly excluded is that _only_ what you've contributed applies and that contributing to a work is not the same as authoring it. I refer directly to the required RFC inclusions that specifically use the word author and their rights and responsibilities with respect to IPR and copyrights. If I make a comment about a rev -01 version of a draft and stop 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. 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. 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. -- Eric -- -Original Message- -- From: John C Klensin [mailto:[EMAIL PROTECTED] -- Sent: Wednesday, June 07, 2006 1:53 PM -- To: Gray, Eric; Spencer Dawkins -- Cc: ietf@ietf.org -- Subject: RE: Acknowledgements section in a RFC (Was: Last -- Call: 'Matching of Language Tags' to BCP (draft-ietf-ltru-matching) -- -- -- -- --On Wednesday, 07 June, 2006 12:33 -0400 Gray, Eric -- [EMAIL PROTECTED] wrote: -- -- Spencer, -- --This opens up yet another can of worms. Suppose that -- everybody who makes a comment on a draft (substantive, or -- otherwise) has to be listed and every one listed is bound by -- BCPs relating to IPR, copyright, etc. in RFC content. -- -- They are so bound... read the Note Well. Whether they should be -- so listed is a separate issue. -- --What happens if someone - perhaps having suggested that -- a word was misspelled - would prefer not to be bound by the -- BCPs (or perhaps is not permitted to be so bound)? Can they -- request to be left out? If they do, can an editor leave them -- out? -- -- Too bad. If they participate in the IETF at the level of either -- attending meetings or saying anything, they are stuck. While -- there are guidelines now (see Bob Braden's note) and guidelines -- can always be further tuned, I think we need to give some -- discretion to document editors about who should be listed --at -- least until and unless we have a clear definition of, e.g., WG -- membership. -- --It occasionally happens now that a draft departs from -- the original direction that some of the contributors wanted -- it to go, and - slightly less often - those that disagree -- with the outcome ask to be de-listed. There are good and -- reasonable reasons to allow this - especially as there may -- be very strong reactions from a particular employer that is -- seen as advocating something they do not intend to do. -- --In such cases, these early contributors provided much -- of the content - even if the over-all outcome is not in line -- with their intentions. So, again, would we be able to omit -- their names? -- -- I have often dealt with that issue in acknowledgements by being -- very explicit that all contributors may not agree with the -- conclusions reached as a consequence of their suggestions (or -- with their suggestions included). An even more extreme case -- exists than the ones that you mention: someone raises an issue -- and preference and the document is ultimately clarified to -- reflect exactly the opposite preference. In some of these -- cases, the document would not have addressed the topic at all -- had the issue not been raised. The person who raised the issue -- may still have made a contribution significant enough to justify -- acknowledgement but may have always been in violent disagreement -- with the conclusion reached by the IETF process about how to -- deal with it. -- -- The underlying problem here is not unique to the IETF. And -- people who don't want to contribute or be bound by the rules -- should avoid participation -- there isn't any whoops, I don't -- like the results so the rules should retroactively not apply to -- me and the fact that I participated at all should be erased -- option. Having such an option with regard to rule-conforming -- would result in chaos. Again, the Note Well is very clear about
RE: Acknowledgements section in a RFC (Was: Last Call: 'Matching of Language Tags' to BCP (draft-ietf-ltru-matching)
John, Agree. -- -Original Message- -- From: John C Klensin [mailto:[EMAIL PROTECTED] -- Sent: Wednesday, June 07, 2006 3:04 PM -- To: Gray, Eric -- Cc: ietf@ietf.org -- Subject: RE: Acknowledgements section in a RFC (Was: Last -- Call: 'Matching of Language Tags' to BCP (draft-ietf-ltru-matching) -- -- -- -- --On Wednesday, 07 June, 2006 14:22 -0400 Gray, Eric -- [EMAIL PROTECTED] wrote: -- -- John, -- --I disagree both in the belief that the Note Well is -- clear on this and the sense of your argument that anyone -- participating in any part of a discussion can be made -- retroactively responsible for the entire discussion. -- -- I think were we disagree is about the notion that inclusion of -- one's name in an acknowledgement implies responsibility for -- any part of the discussion, much less all of it. -- --The Note Well is not clear because it makes sweeping -- statements about the way in which BCP 78 and 79 may apply -- to contributions. The obvious (but not clear) intent is -- that what you contribute is now subject to provisions of -- these BCPs that apply to contributions. What is both more -- subtle and not clearly excluded is that _only_ what you've -- contributed applies and that contributing to a work is not -- the same as authoring it. -- -- To the extent to which you believe that the Note Well is unclear -- or defective, please take that to the IPR WG. -- --I refer directly to the required RFC inclusions that -- specifically use the word author and their rights and -- responsibilities with respect to IPR and copyrights. If I -- make a comment about a rev -01 version of a draft and stop -- 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. -- -- I believe that is true. I also do not believe that an -- acknowledgement constitutes an assertion of accountability. -- But those are matters for counsel -- I will assert my beliefs -- about what ought to be happening here, but not about the legal -- implications of particular text. In particular, I do not -- believe that inclusion or exclusion from an acknowledgement -- implies an IPR claims or responsibilities at all: to do so would -- confound many centuries of publications history. An exception -- might(and probably would) arise if the contribution were -- identified in very specific terms, but those terms would bind -- that particular author/ contributor only to that text. As far -- as I recall, we have never included text in acknowledgements -- that says, e.g., Joe Blow contributed section 1.2.3.4 in its -- entirety and it is used with his permission, so the -- implications of that form are not relevant. -- --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. -- -- It would clearly be inappropriate to list you as an author. -- Given our current peculiar definition of Contributor in the -- RFC sense, it would probably be inappropriate to include you as -- one of those, at least without permitting you to include a -- statement of dissent. It seems to me that you have no standing -- to object to the inclusion of your name in an acknowledgement if -- you, in fact, did something that the author thought was -- appropriate to acknowledge. I'd hope that, in normal -- circumstances, the author would honor your request to remove -- your name, but I can also see circumstances in which removing -- your name would be inappropriate. -- -- As one specific example, suppose the acknowledgements said -- Significant contributions to the topics discussed in this -- document came from an ad hoc group consisting of list of -- participants in that group. Now, adding a not all members of -- the group agree with the final conclusions represented in this -- document would be appropriate if true. But removing a name -- from the list of people who participated in the group, -- especially the name of someone who could be clearly determined -- from the group's mailing list to have actively participated, -- would simply be a lie and, IMO, completely inappropriate. -- --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. -- -- Understood. But that is precisely why listing in an -- acknowledgement must not have implications of responsibility -- for the whole document. -- -- And this discussion really belongs in the IPR WG. -- -- john -- ___ Ietf mailing list Ietf@ietf.org https://www1
RE: Best practice for data encoding?
Steven, I'm not sure what you mean by saying that a problem that is highly complex should not be solved (or, at least, that we should consider not solving it). That seems like a cop-out. Minimally, every problem we've ever faced, we've tried to solve (where we refers to us weak-kneed Homo Sapiens) - no matter how hard it was to do so - and I like to think that is the right thing to do. In fairness, I am reasonably sure that point 3 in RFC 1925 refers to making a complex solution work, even if a simpler answer might be found, simply because enough people want that solution. It does not - IMO - rule out solving complex problems using as simple a solution as possible, however complex that might be. -- Eric -- -Original Message- -- From: Steven M. Bellovin [mailto:[EMAIL PROTECTED] -- Sent: Monday, June 05, 2006 8:21 PM -- To: David Harrington -- Cc: ietf@ietf.org -- Subject: Re: Best practice for data encoding? -- -- On Mon, 5 Jun 2006 20:07:24 -0400, David Harrington -- [EMAIL PROTECTED] wrote: -- -- Hi -- -- The security problems identified in -- http://www.cert.org/advisories/CA-2002-03.html Multiple -- Vulnerabilities in Many Implementations of the Simple Network -- Management Protocol (SNMP) are not caused by the -- protocol choice to -- use ASN.1, but by vendors incorrectly implementing the -- protocol (which -- was made worse by vendors using toolkits that had the problems). -- -- If Multiple Vulnerabilities in Implementations were -- used to condemn -- the encoding methods of protocols that have been incorrectly -- implemented, then we would have to condemn an awful lot of IETF -- protocols as being very (security) bug prone: -- -- -- Works for me -- -- More precisely -- when something is sufficiently complex, -- it's inherently -- bug-prone. That is indeed a good reason to push back on a -- design. The -- question to ask is whether the *problem* is inherently -- complex -- when the -- complexity of the solution significanlty exceeds the -- inherent complexity of -- the problem, you've probably made a mistake. When the -- problem itself is -- sufficiently complex, it's fair to ask if it should be -- solved. Remember -- point (3) of RFC 1925. -- -- I'll note that a number of the protocols you cite were -- indeed criticized -- *during the design process* as too complex. The objectors -- were overruled. -- -- --Steven M. Bellovin, http://www.cs.columbia.edu/~smb -- -- ___ -- Ietf mailing list -- Ietf@ietf.org -- https://www1.ietf.org/mailman/listinfo/ietf -- ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: Last Call: 'A Process Experiment in Normative Reference Handl ing' to Experimental RFC (draft-klensin-norm-ref)
John, In your choices below, choice i and ii are not quite separable. In the do nothing mode i, eventual advancement required to de-queue the would-be Draft Standard will only happen if choice ii is in effect. In other words, choice ii is effectively the same as choice i except that the duration of the do nothing phase is shorter (by an arbitrary amount). -- Eric Gray --- [SNIP] --- -- (From Eric Rosen) -- -- Frankly, I think this wavier procedure is outrageous, -- and entirely unacceptable. The fact The fact that the -- referenced document has not gone through some bureaucratic -- process does not mean that it is any less stable, or that any -- more caution is required in its use. Inserting this -- derogatory language about technology which may be well-proven -- and widely deployed will be extremely misleading to the -- industry. -- -- (your response) -- -- If a WG agrees with you about a particular piece of technology, -- they have three choices: -- -- (i) Do nothing, in which case their would-be Draft -- Standard will sit in queue until that well-proven and -- widely -deployed technology is, itself, advanced to -- Draft Standard (or to not try to advance their Proposed -- Standard to Draft Standard at all). -- -- (ii) Pick up the obviously well-documented definition of -- the well-proven and widely deployed technology and -- advance it to Draft Standard. -- -- (iii) Invoke the RFC 3967 procedure for downrefs, which -- is more burdensome in terms of processing than the new -- proposal, but does not involve disclaimers. You can -- think of the RFC 3967 procedure as requiring a community -- determination that the referenced technology is stable -- enough to be referenced in a document of a given -- maturity level. -- -- So the proposed new rule adds one option to the three that are -- there already. It is up to the WG (or individual submitter) -- which one to use. This one is intended to be much more -- lightweight and quick than any of the existing options, but no -- one is forcing its use. And I assume that, if it is found too -- unpleasant or derogatory, then no one will use it and it will -- disappear after a year. Personally, that wouldn't bother me one -- bit -- you will recall that I have proposed and/or backed much -- more radical and extensive solutions to this type of problem -- -- but that is a rather different discussion. -- -- I think that any rule which requires us to insert false -- and misleading statements in the documents should be strongly -- opposed. -- -- But there is no requirement that this procedure be used at all. -- If I writing a document that needed to reference a specification -- that was as well-defined, mature, and stable as you posit, I'd -- first try to get that specification advanced to the right -- maturity level or, if there was some bar to doing so, I'd invoke -- the RFC 3697 procedure. Or I might try to build consensus for -- some serious discussion and action on -- draft-ietf-newtrk-promotion-00.txt, which essentially proposes -- fast-tracking the advancement of such specifications on the -- basis of their marketplace acceptance (and which is showing -- signs of vanishing without a trace). -- -- Even worse: -- -- The IESG may, at its discretion, specify the exact text -- to be used -- -- Great, not only is the WG required to denigrate its own -- technology, but the IESG is given free rein to insert whatever -- derogatory remarks they feel like putting in. -- -- First, this seemed appropriate for an experiment of the type -- specified. In addition, like it or not, current procedures, as -- practiced, essentially give the IESG free rein to insert -- whatever remarks (derogatory or otherwise) they feel like -- inserting in anything. They are prevented from doing so by some -- combination of good sense and the presence of the appeals -- procedure, which is exactly what the paragraph you complain -- about below says... -- -- Of course, we'll be told not to worry, since: -- --If members of the community consider either the -- downward reference or the annotation text to be -- inappropriate, those issues can be raised at any time -- in the document life cycle, just as with any other text -- in the document. -- -- Great. Another useless thing to argue about in the WG, and -- another useless thing to argue about with the IESG. -- -- But the assertion you are making about a (e.g.) Proposed -- Standard specification being stable, mature, well-defined, -- widely-deployed, etc., is one that presumably should get some -- community review, rather than simply being accepted as the -- result of the divine rights of the author/editor. And that -- brings us back to the three existing choices above, which the WG -- presumably needs to argue about today. The WG's only choice -- without such an argument is
RE: Last Call: 'A Process Experiment in Normative Reference Handl ing' to Experimental RFC (draft-klensin-norm-ref)
Eric (Rosen), Irrespective of opinions about the nature of the current process, if one RFC is advanced significantly ahead of another one that it has a normative dependency on, it is possible that the state of the art will migrate between one advancement, and the other. In the event that this occurs, the documents will be out of synch - irregardless of the actual state of the art. It is simple to fix that - either advance both at the same time, or allow them to be out of synch based on a speculative assertion that de-synchronization will not occur. In the latter case, it is certainly reasonable to allow that de-synchronization may occur - and that appears to be the intent of the note in this draft proposed process experiment. The risk is that - if the normative reference is advanced, and this produces a de-synchronization of the documents, then the referring Draft Standard will have to be updated as well. Consequently, I - for one - see nothing either false or misleading in the proposed note. I also find that addition of such a note is substantially less onerous than alternatives we have now... -- Eric (Gray) Your mail included [paraphrased]: --- [SNIP] --- -- -- Frankly, I think this [waver] procedure is outrageous, and entirely -- unacceptable. The fact [...] that the referenced document has not -- gone through some bureaucratic process does not mean that it is any -- less stable, or that any more caution is required in its use. -- -- Inserting this [language] about technology which may be well-proven -- and widely deployed will be extremely misleading to the industry. -- -- I think that any rule which requires us to insert false and misleading -- statements in the documents should be strongly opposed. -- --- [SNIP] --- ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: LC on draft-mankin-pub-req-08.txt
Joel, Please see my comments below... -- Eric -- -Original Message- -- From: Joel M. Halpern [mailto:[EMAIL PROTECTED] -- Sent: Wednesday, May 24, 2006 4:11 PM -- To: ietf@ietf.org -- Subject: Re: LC on draft-mankin-pub-req-08.txt -- -- Reading this, a few items caught my eye. -- -- The POSTEDIT requirements seem to be worded as if it is desirable -- to minimize the changes that the document editor makes, or even the -- changes the document editor can make. The general tone of don't -- mess with the words we have carefully honed is understandable. -- However, in practice many of the words have not been carefully -- honed. And they need to be. For example, there is a document I -- just reviewed to which my personal reaction is this needs massive -- editing. It is not technically wrong. But the language use makes -- it hard for the reader to understand what is intended. I would -- sincerely hope that if it is approved as-is by the IESG that the RFC -- Editor would edit the document. -- I believe that people are leaning in the direction of requiring authors to do a better job before gaining approval required to put the remainder of the job on the RFC Editor's desk. As worded now, it seems as if the cases to which higher numbered requirements (in the series under discussion - i.e. - requirements Req-POSTEDIT-3, 4 and 5) have progressively (or incrementally) greater restrictions on their applicability to documents generally. I think this is as it should be and it may well be the case that future IESG approvals may include a note as to which levels of editing may be applied to a given draft document. -- -- In general the editor has little or no way to tell which words are -- carefully crafted. I would hate to have a presumption that all -- the words a sacrosanct. -- I am reasonably sure that this is not as difficult as it sounds. For one thing, if the current draft revision is -23, we can be reasonably sure that tweaking anything that is not clearly a typo or spelling error will be a case of modifying carefully crafted wording. On the other hand, modifying wording of a revision -02 (or lower) document that is laced with typos, spelling and grammatical errors from end to end (the massive editing example you gave) is unlikely to fall in the same category. I believe we can expect a technical editor to use their own judgement between these two extremes - at least in most cases. -- -- I realize that the text calls out the special case of don't touch a -- letter of this, and even acknowledges that it is a rare case. But -- the wording of the earlier text is not in line with that. -- Specifically, POSTEDIT-4 reads The IETF Technical editor should -- refrain from changes to improve readability that may change -- technical and consensus wording. This appears to be a directive -- that prohibits almost all changes, since in a formal sense all the -- words in an WG and IETF LC approved document are consensus wording. -- That leads to what I consider a bad situation where we have -- essentially prohibited the editor from editing. -- Bearing in mind that asking someone to refrain from doing something is a far cry from prohibiting it, see my comment above. -- -- On a related note, POSTEDIT-3 seems to be inadvertently worded too -- strongly. It prohibits changes which introduce a substantial -- review load but only provides incremental increase in the clarity -- of the specification. However, by definition any change at all, -- even a significant change that transforms a document from -- unintelligible to highly readable, is always an incremental -- increase in the clarity of the specification. -- Here I must confess to some sympathy. Like me, you probably cringe when you here the phrase more granular because this usage is just wrong. However, in this case, one of the established definitions of incremental is: A slight, often barely perceptible augmentation. It might be better to choose a less ambiguous word, but I believe the meaning is clear. -- -- With regard to the metrics, [...] --- [SNIP] --- I agree with your other observations and suggestions. -- -- Yours, -- Joel M. Halpern -- -- -- ___ -- Ietf mailing list -- Ietf@ietf.org -- https://www1.ietf.org/mailman/listinfo/ietf -- ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: LC on draft-mankin-pub-req-08.txt
Bob, Weirdness? No part of the RFC Editor's job has ever involved deliberate modification of text that reflects a carefully crafted compromise position. In the past, when any such modification has occurred inadvertently, it would usually have been reversed during an Auth48. I believe what we're trying to do is define what the RFC Editor does already in terms that might allow us to off-load part of that task. So, NO I am not saying Don't do your job most of the time - what I am saying is that restraint should be used in this task to avoid doing more than the task requires. To make this something we can look at more objectively, let's look at a different example of the same usage. Surely, you would agree that a statement such as - People should refrain from allowing their passion for precise terminology usage to prevent essential communication from ever taking place - is a far cry from - Nit-picking is prohibited. -- Eric -- -Original Message- -- From: Bob Braden [mailto:[EMAIL PROTECTED] -- Sent: Thursday, June 01, 2006 5:17 PM -- To: [EMAIL PROTECTED]; [EMAIL PROTECTED] -- Cc: ietf@ietf.org -- Subject: RE: LC on draft-mankin-pub-req-08.txt -- -- -- -- * -- *Bearing in mind that asking someone to refrain from -- * doing something is a far cry from prohibiting it, see my -- * comment above. -- * -- -- Sorry, I don't get that fine distinction. Are you saying, Don't -- do your job most of the time? Wierdness abounds here. -- -- Bob Braden -- ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: LC on draft-mankin-pub-req-08.txt
Bob, To me, this is a perfectly sensible discussion, and my analogy was perfectly reasonable. Joel suggested that refraining from making changes that might result in altering phraseology that was carefully arrived at was effectively prohibiting the technical editor from doing the editing job. I say that the editing job can be done - as it is being done now - within the bounds of this constraint. I think this makes a lot of sense. The Editor makes it very clear what his/her specific requirements and standards of acceptability are and these are certainly taken into account in the process of word-smithing key phraseology - in many cases if not necessarily all (especially by the time IESG approval occurs). At the same time, the people writing a specification would not normally like to feel that the Editor must be a party to word-smithing of this same key phraseology - except from the stand-point of readability and clarity within the context of the purpose of the document. The concern I see being expressed in the draft is that we want to ensure that the current practice of reasoned prudence in making editorial changes is continued. This is a perfectly valid concern. As for emotional charge in the term nit-picking - I see none. As anyone who knows me can assure you, I am the last one in the world who will throw stones in that glass house. Since the term derives from the practice of de-lousing, I can hardly imagine it to be necessarily a bad thing. Finally, ambiguity is sometimes precisely what has been negotiated into a specification and this should be legitimate if the effect of the ambiguity is irrelevant to the purpose of the document. An instance of this is an example, provided not to instruct but to illustrate functionality in the abstract. -- Eric -- -Original Message- -- From: Bob Braden [mailto:[EMAIL PROTECTED] -- Sent: Thursday, June 01, 2006 6:43 PM -- To: [EMAIL PROTECTED]; [EMAIL PROTECTED] -- Cc: [EMAIL PROTECTED]; ietf@ietf.org -- Subject: RE: LC on draft-mankin-pub-req-08.txt -- -- -- * -- * People should refrain from allowing their passion for precise -- * terminology usage to prevent essential communication from -- * ever taking place -- * -- -- That statement incorporates an assumption that is not true. -- I vaguely -- recall that you can prove anything starting from a false premise. -- -- Bob Braden -- -- * - is a far cry from - -- * -- * Nit-picking is prohibited. -- -- Your choice of the emotion-packed word nit-picking -- reveals that you and -- I cannot have a sensible discussion. Is a bug in a -- programs a nit? Is -- bad English grammar a nit? Is ambiguous prose or terminology a nit? -- -- Bob Braden -- ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: The Emperor Has No Clothes: Is PANA actually useful?
Lucy, Thanks! -- E -- -Original Message- -- From: Lucy E. Lynch [mailto:[EMAIL PROTECTED] -- Sent: Friday, May 26, 2006 2:31 PM -- To: Gray, Eric -- Cc: Narayanan, Vidya; Sam Hartman; Bernard Aboba; ietf@ietf.org -- Subject: RE: The Emperor Has No Clothes: Is PANA actually useful? -- -- On Fri, 26 May 2006, Gray, Eric wrote: -- -- For those of us that are just trying to follow this discussion, -- what does the word posture mean in this context? -- -- according to draft-thomson-nea-problem-statement-02.txt -- -- Posture: Posture refers to the hardware or software -- configuration of -- an endpoint as it pertains to an organization's security policy. -- Posture may include knowledge about the types of hardware and -- software installed and their configurations, e.g. OS name and -- version, application patch levels, and anti-virus signature file -- version. -- -- -- -- -- -- Eric -- -- -- -Original Message- -- -- From: Narayanan, Vidya [mailto:[EMAIL PROTECTED] -- -- Sent: Friday, May 26, 2006 2:05 PM -- -- To: Sam Hartman; Bernard Aboba -- -- Cc: ietf@ietf.org -- -- Subject: RE: The Emperor Has No Clothes: Is PANA -- actually useful? -- -- -- -- -- -- Bernard == Bernard Aboba -- [EMAIL PROTECTED] writes: -- -- -- -- My question is more why do they need EAP in -- -- situations where -- -- they are not running at the link layer than why do -- -- they want or -- -- not want PANA. -- -- -- -- Bernard The simple answer is that there are -- -- situations which IEEE -- -- Bernard 802.1X cannot handle on wired networks. As -- -- specified, -- -- Bernard IEEE 802.1X is network port control, which -- -- means that -- -- Bernard authorization is controllable only at the -- -- port level. If -- -- Bernard there is more than one host connected to a -- -- switch port, -- -- Bernard then that model no longer applies. -- -- -- -- Yeah. I guess I wonder whether you are actually getting -- -- network access authenticatino at that point or whether you -- -- are getting a service that allows you to check posture. It -- -- seems that a service that simply allows you to check posture -- -- should be not EAP. -- -- -- -- -- -- -- -- I fully agree. As far as I can tell, using EAP in -- this manner merely -- -- reduces it to a posture transport protocol. The level -- of security -- -- provided by EAPoUDP does not seem to be any greater than a -- -- kerberos-based authentication done today in most enterprise -- -- networks, -- -- considering the presence of switched ethernet. Hence, the -- -- only reason to -- -- move to EAPoUDP would be to check posture and I agree -- with Sam that -- -- making EAP the posture transport protocol is a bad idea. -- -- -- -- Vidya -- -- -- -- -- -- ___ -- -- Ietf mailing list -- -- Ietf@ietf.org -- -- https://www1.ietf.org/mailman/listinfo/ietf -- -- -- -- -- -- ___ -- -- Ietf mailing list -- -- Ietf@ietf.org -- -- https://www1.ietf.org/mailman/listinfo/ietf -- -- -- -- ___ -- Ietf mailing list -- Ietf@ietf.org -- https://www1.ietf.org/mailman/listinfo/ietf -- -- -- -- -- Lucy E. Lynch Academic User Services -- Computing CenterUniversity of Oregon -- llynch @darkwing.uoregon.edu (541) 346-1774 -- ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: The Emperor Has No Clothes: Is PANA actually useful?
Sam, Thanks! -- E -- -Original Message- -- From: Sam Hartman [mailto:[EMAIL PROTECTED] -- Sent: Friday, May 26, 2006 5:20 PM -- To: Gray, Eric -- Cc: Narayanan, Vidya; Bernard Aboba; ietf@ietf.org -- Subject: Re: The Emperor Has No Clothes: Is PANA actually useful? -- -- Gray, == Gray, Eric [EMAIL PROTECTED] writes: -- -- Gray, For those of us that are just trying to follow this -- Gray, discussion, what does the word posture mean in this -- Gray, context? -- -- Assertions about your OS state--things like patch levels, -- configuration of security settings, etc. -- ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: Comments on draft-iab-rfc-editor: IETF control
Eliot, I am not sure where the disagreement between what you're saying and what Sam said earlier is - unless you're saying that it is not necessary for the IETF to have an over-ride ability on specific issues. It would be nice if the IETF had a direct appeal to the community (by some definition) for IAB activities. That would likely require a somewhat more concrete definition than we have at present, and would probably require some for of voting. But we do have an appeals process that usually takes into account reaction from the community. I think the strongest point of agreement is that - if the IAB appears too thick-skinned in terms of its reaction to the commmunity - then the NOMCOM function will eventually shake it out. But surely you would not argue that the NOMCOM is the way to address short-term, or issue specific, community disagreement with the IAB, are you? -- Eric -- -Original Message- -- From: Eliot Lear [mailto:[EMAIL PROTECTED] -- Sent: Tuesday, May 30, 2006 11:36 AM -- To: Sam Hartman -- Cc: Pete Resnick; [EMAIL PROTECTED]; ietf@ietf.org -- Subject: Re: Comments on draft-iab-rfc-editor: IETF control -- -- Sam, -- -- However there needs to be a way for a member of this -- community--whatever it is--to make a proposal, to get -- enough support, -- and to have that proposal be adopted. -- -- I.E. it is fine if the IAB of whomever can do a lot of -- things on their -- own. However the community needs the ability to either -- guide the IAB -- or override the IAB if there is disagreement. -- -- -- I disagree. Just as I expect you to use your judgment on the IESG I -- expect the IAB to use their judgment. Community oversight -- comes in the -- form of the NOMCOM. If you believe that oversight is not effective, -- then let's discuss that instead. -- -- Eliot -- -- ___ -- Ietf mailing list -- Ietf@ietf.org -- https://www1.ietf.org/mailman/listinfo/ietf -- ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: RFC Author Count and IPR
Sam, et al, There are so many things tied up in this, that I am afraid it is bound to turn into a rat-hole. For one thing, I thought Russ was talking about the complication that arise from whether or not the BCP 78/79 stuff applies to people who made some contribution but are not listed as Authors. I may have missed his point, but this probably is an issue as there are other things in IPR than copyrights. For another, there is a clear distinction between attribution and being listed as an author. Most drafts I've seen acknowledge the people making contributions. Also, RFCs are not (at least usually) a compilation of related works by separate authors. An RFC typically requires some unification and typically this is performed by one or more editors. Because of churn-and-merge complexity, it is usually the case that there is only one editor at any given moment, and the list of token holders is both well defined and small - consequently is is quite reasonable to ask that a long list of authors be replaced by a shorter list of the people who actually took turns as editors. I think the biggest issue is that the RFC Editor has established guidelines that use a fixed number. This can lead to rather arbitrary decisions about who is an editor, author or contributor. Probably a better approach would be to explicitly define what the RFC Editor means by the terms contributor, author, editor and - perhaps - something even more specific that that (e.g. - final editor?) and then saying that some number of names MAY be listed on the first page and that the approach to determining what names should be included is to pick the category that has no more than that many in the list. I was pretty much under the impression that this is the informal approach used now. -- Eric -- -Original Message- -- From: Sam Hartman [mailto:[EMAIL PROTECTED] -- Sent: Wednesday, May 24, 2006 2:06 PM -- To: Russ Housley -- Cc: rfc-editor@rfc-editor.org; ietf@ietf.org; -- techspec@ietf.org; ipr-wg@ietf.org -- Subject: Re: RFC Author Count and IPR -- -- Russ == Russ Housley [EMAIL PROTECTED] writes: -- -- Russ I am concerned that the current RFC Editor practice that -- Russ limits the number of authors is in conflict with the IETF -- Russ IPR policies. The RFC Editor currently limits the author -- Russ count to five people. Recent IPR WG discussions make it -- Russ clear to me that authors retain significant copyright. -- -- [There is this concept in US copyright law called a joint work. I'm -- ignoring that concept for the moment basically because I don't -- understand how it applies to either software or text developed using -- an open process. As far as I can tell, no one else understands it -- either. Please be aware that this may be a huge gap in my advice.] -- -- So, here we have a conflicting definitions problem. -- -- The author of a work retains the copyright interest. That's true if -- if I'm listed as an author or not. -- -- If I write text and do not assign the copyright to someone, I retain -- copyright interest in that text. -- -- So the sixth person still owns the copyright interest in -- the text they -- write even if they are not listed. -- -- 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. -- -- ___ -- Ietf mailing list -- Ietf@ietf.org -- https://www1.ietf.org/mailman/listinfo/ietf -- ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: RFC Author Count and IPR
Henning, IRT BCP 78/79 IPR statements, it's actually worse than you indicate. The issue is that (because of the Note Well) you can't effectively take back a contribution and (because of the need for proper attribution) you really cannot de-list someone who has made any significant contribution to the document. Because of the wording in current IPR BCPs, however, any author is not only agreeing to be responsible for IPR that he (or she) may have in their contribution, but also any IPR they may know of that relates to other contributions made in an RFC for which they are a listed author. One seriously detrimental effect of these considerations is that this actively discourages an RFC author (and possibly any other contributor) from trying to determine if his (or her) employer actually has any IPR in the technology about which they are writing - and, thus, encouraging a separation between those who do things and those who write about it... -- Eric -- -Original Message- -- From: Henning Schulzrinne [mailto:[EMAIL PROTECTED] -- Sent: Wednesday, May 24, 2006 2:43 PM -- To: Vijay Devarapallli -- Cc: rfc-editor@rfc-editor.org; Sam Hartman; -- ipr-wg@ietf.org; techspec@ietf.org; ietf@ietf.org -- Subject: Re: RFC Author Count and IPR -- -- Authorship discussions have a long history in the sciences. I'm not -- aware of any other scientific or technical publication that -- limits the -- number of authors. (Indeed, I have had to extend the maximum author -- count on a largish conference management system I run -- [edas.info] a few -- times.) The current limit of 5 seems to be motivated by formatting -- constraints and maybe by the notion that vanity -- publishing should be -- prevented. It is not clear to me that these motivations have legal -- standing and essentially, for practical purposes, force -- authors to give -- up their rights. In the past, I know that for some drafts, -- this limit -- has been extended when the AD made the right noises to the -- RFC editor, -- so it is not universally observed. -- -- My understanding is that contributors generally have -- inferior rights, -- not much different from those individuals acknowledged in the -- acknowledgment section of technical papers and RFCs. -- -- After some of the recent science scandals, there also seems to be a -- movement afoot (e.g., for Science and Nature) to force all -- authors to -- take responsibility for the paper and its content. That's a -- flip-side, -- also from an IPR perspective: If somebody can plausibly -- claim that they -- just got added to the author list without their consent, they could -- weasle out of the IPR disclosure rules. At least from my -- experience, it -- is not uncommon that I-D authors add others as a courtesy and, -- currently, nobody seems to check whether these authors consented to -- being an author... -- -- Henning -- -- Vijay Devarapallli wrote: -- On 5/24/06, Sam Hartman [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. -- -- typically the unlisted authors are ignored. -- -- also during the AUTH48 period, the RFC Editor contacts -- only the listed -- authors. -- -- Vijay -- -- -- -- -- -- -- ___ -- Ietf mailing list -- Ietf@ietf.org -- https://www1.ietf.org/mailman/listinfo/ietf -- -- ___ -- Ietf mailing list -- Ietf@ietf.org -- https://www1.ietf.org/mailman/listinfo/ietf -- ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: Stupid NAT tricks and how to stop them.
Noel, I think the street address analogy is not close enough - anymore than longitude and latitude numbers or any other description of physical location. The problem with physical location portability is that the location remains even if you're not in it. So someone else might need to describe their own physical location using the same description. Number assignments, however are substantially more portable. It is certainly possible for an IPv6 address pool manager to allocate personalized IPv6 addresses from an IPv6 address pool that they manage and thereby assume responsibility for end-delivery (by any means possible) - thus providing for indefinite address portability. In this sense, this is more analogous to phone number portability or tax identifiers. -- Eric -- -Original Message- -- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] -- Sent: Tuesday, March 28, 2006 10:06 AM -- To: ietf@ietf.org -- Cc: [EMAIL PROTECTED] -- Subject: RE: Stupid NAT tricks and how to stop them. -- -- From: Michel Py [EMAIL PROTECTED] -- -- Tim Chown wrote: -- If you deploy IPv6 NAT, you may as well stay with IPv4. -- -- You're the one who convinced me some three years ago -- that there will -- be IPv6 NAT no matter what, what's the message here? -- -- I think Tim's point is that the only realistic options are: -- -- i) IPv4+NAT -- ii) IPv6 without NAT. -- -- The IPv6+NAT option makes little (no?) economic/technical -- sense - it has all -- the operational downsides of IPv4+NAT, plus to which you -- have the cost/hassle -- of deploying v6. -- -- -- and possibly allocate PI to everybody which is -- another pre-requisite -- to get rid of NAT. -- -- We aren't *ever* going to give everyone PI space (at least, -- PI space in -- whatever namespace the routers use to forward packets), any -- more than we are -- going to let them take their street addresses with them -- when they move. -- -- Routing (i.e. path-finding) algorithms simply cannot cope -- with tracking 10^9 -- individual destinations (see prior message). -- -- Noel -- -- ___ -- Ietf mailing list -- Ietf@ietf.org -- https://www1.ietf.org/mailman/listinfo/ietf -- ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: Stupid NAT tricks and how to stop them.
Noel, Delivering IP packets _always_ involves a translation service. Usually, more than one, but - assuming we start with IP addresses - there is at least one MAC (or other L2) lookup that must occur before the packets can be delivered. We should be careful not to assert layer dependent statements in a world in which layering is only locally unambiguous. The problem with the road-network analog is that I have no intrinsic requirement to relinquish my network address because I've become mobile. The same thing could - in theory - be said about street addresses, but the current binding/interpretation of street addresses is entrenched in centuries of usage that prevents this from (probably) ever becoming practical. That is not only NOT true in theory for IP(v4/v6) addresses, it is not true in practice. -- Eric -- -Original Message- -- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] -- Sent: Tuesday, March 28, 2006 1:17 PM -- To: ietf@ietf.org -- Cc: [EMAIL PROTECTED] -- Subject: RE: Stupid NAT tricks and how to stop them. -- -- From: Gray, Eric [EMAIL PROTECTED] -- -- I think the street address analogy is not close -- enough - anymore -- than longitude and latitude numbers or any other -- description of -- physical location. -- -- No, it's a very good analogy, because the road network is a -- very good analog -- to the data network. To see how, let's do a though-experiment. -- -- Embed the road-network, not on the surface of a solid -- sphere, but on the -- surface of a flexible hollow spherical surface. Now, -- distort that surface -- arbitrarily. The location (in spatial coordinates) of any -- place on that road -- network has changed totally - but the set of directions -- you'd use to get -- from one point in the road network to another (go down -- road A until you -- meet the junction with B, and turn onto B in the direction -- of C, etc, etc) -- remains unchanged. -- -- What is most important about both the data network, and the -- road network, is -- the *connectivity pattern* - what connects to what. That's -- because packets -- are (usually) constrained to travel down links, and -- vehicles are (usually) -- constrained to travel down roads. -- -- The problem with physical location portability is -- that the location -- remains even if you're not in it. -- -- But the exact same thing is true of a network - Port #0 on -- ISP A's router R -- is the same place in the network (i.e. you use the same -- directions to get to -- it - see above) whether company X or company Y is plugged -- in there - just as -- 126 Main Street is the same building, whether company X or -- company Y is -- housed there. -- -- Number assignments, however are substantially more portable. -- -- Saying that doesn't make it so. You can easily (sic) change -- street names -- too, to make a street name portable. -- -- -- It is certainly possible for an IPv6 address pool -- manager to allocate -- personalized IPv6 addresses from an IPv6 address pool -- that they manage -- and thereby assume responsibility for end-delivery -- -- That's just a translation service from *virtual* addresses -- to real ones - -- those IPv6 addresses aren't the names of locations in the -- network: if the -- pool manager *actually wants to get packets* to those -- entities, it is going -- to have to translate those addresses into the real -- addresses at which -- those entities can be found. -- -- Noel -- ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: Moving from hosts to sponsors
Dave, Certainly there are organizations that do this. Those organizations are significantly different from the IETF. For one thing, the first thing we would have to do in the IETF - if we adopted a model like this - is to establish a marketing over-sight function to ensure fair and equitable disposition of sponsorship funds. -- Eric -- -Original Message- -- From: Dave Crocker [mailto:[EMAIL PROTECTED] -- Sent: Thursday, March 23, 2006 7:45 PM -- To: Michael StJohns -- Cc: Keith Moore; ietf@ietf.org; [EMAIL PROTECTED] -- Subject: Moving from hosts to sponsors -- -- Michael StJohns wrote: -- What I think Jordi is saying is that he wants the US sponsors to -- subsidize the cost of the overseas meetings. At least -- that's what it -- works out to be -- -- This view can be mapped to a classic model that would have -- significant benefits -- for the IETF: -- -- -- A host gets all sorts of marketing leverage out of the -- role in producing an -- IETF. -- -- There is nothing that requires that the event site -- management effort be coupled -- with a particular host's venue. -- -- If we moved to a model of having companies provide -- sponsorship funds, in return -- for which they get appropriate marketing presence, then we -- could have meeting -- venue management move to the sort of predictable and timely -- basis -- ie, far -- enough ahead of time -- that has been a concern for many years. -- -- -- d/ -- -- -- -- -- Dave Crocker -- Brandenburg InternetWorking -- http://bbiw.net -- -- ___ -- Ietf mailing list -- Ietf@ietf.org -- https://www1.ietf.org/mailman/listinfo/ietf -- ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: Venue requirements - canoe?
Sounds to me like this comes under the Transport Area - at least as far as flooding control is concerned. Avoidance of flooded paths, on the other hand, might be a routing Area problem. -- -Original Message- -- From: Steven M. Bellovin [mailto:[EMAIL PROTECTED] -- Sent: Monday, March 20, 2006 11:09 AM -- To: Tim Chown -- Cc: ietf@ietf.org -- Subject: Re: Venue requirements - canoe? -- -- We clearly need to tell the Routing Area to work on better flooding -- algorithms. -- -- --Steven M. Bellovin, http://www.cs.columbia.edu/~smb -- -- ___ -- Ietf mailing list -- Ietf@ietf.org -- https://www1.ietf.org/mailman/listinfo/ietf -- ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: Last Call comment on draft-hartman-mailinglist-experiment-01. txt
Ted, It does not make sense to propose a change to a referenced document in order to help explain the need for the referencing document. In addition, an indefinite period of time is - by itself - a more than sufficient difference. Usually, a suspension of any privilege for an indefinite period of time (as opposed to any definite period of time) means there are (or should be) explicit steps to take to have the lost privilege re-instated. In the absence of an explicitly defined re-instatement process, indefinite period of time is effectively forever. A suspension for a definite time period means that the privilege is automatically re-instated after the defined period of time has elapsed - whether it is months, years or decades. A manual re-instatement process typically means applying to the same body that suspended a privilege in the first place for a re-instatement. This is a stark distinction. -- Eric -- -Original Message- -- From: Ted Hardie [mailto:[EMAIL PROTECTED] -- Sent: Tuesday, March 14, 2006 7:03 PM -- To: [EMAIL PROTECTED] -- Cc: ietf@ietf.org; iesg@ietf.org -- Subject: Last Call comment on -- draft-hartman-mailinglist-experiment-01.txt -- -- The document currently says: -- -- RFC 3683[RFC3683] provides a procedure for banning named -- individuals --from posting to an IETF mailing list for an indefinite period of --time. However once such a ban is put in place for one -- mailing list, --the individuals responsible for other IETF mailing lists can --unilaterally remove the posting rights of that individual. -- -- RFC 3683 says: -- -- A PR-action identifies one or more individuals, citing messages --posted by those individuals to an IETF mailing list, -- that appear to --be abusive of the consensus-driven process. If approved -- by the IESG, --then: -- --o those identified on the PR-action have their posting rights to -- that IETF mailing list removed; and, -- --o maintainers of any IETF mailing list may, at their discretion, -- also remove posting rights to that IETF mailing list. -- --Once taken, this action remains in force until -- explicitly nullified --and SHOULD remain in force for at least one year. -- -- I believe that the draft should clarify that the -- indefinite period of time -- is expected to be one year or longer. One of the primary -- points being -- made is that the contrast between the 3683 posting rights -- removal period -- and the 3934 period is stark, but if 3683 were truly -- indefinite it could -- be a period much shorter than a year. Defining the gap would help -- explain the need for the doucment. -- -- The document notes the IESG statement on moderation; an -- update to include -- the IESG statement on disruptive posting: -- -- http://www.ietf.org/IESG/STATEMENTS/statement-disruptive-posting.txt -- -- seems as if it would be valuable. -- -- Section 4 does not seem to me to define an experiment. It -- seems to assert that -- during this 18 month period that the IESG may run one or -- more experiments with -- a more limited form of documentation than is present in an -- RFC 3933 experiment. -- RFC 3933 already notes that experiments are a middle ground -- between statements -- made by the IESG and BCPs approved by the community. But -- can an experimental -- document itself define a middle ground between RFC 3933 -- experiments and -- statements made by the IESG, or would it have to be a BCP -- to do so? Since policy -- statements by the IESG can make changes here, I don't know -- that this is a -- practical problem for this issue, but the structure of -- Section 4 did concern me. -- -- -- The document states: -- -- Sanctions made under this memo may be appealed using the procedures --outlined in [RFC2026]. -- -- One, I would prefer if the document used the term -- decisions, as I do not believe -- these should be seen as sanctions or punitive; they are -- mechanisms to ensure mailing lists -- remain an effective tool for getting the work of the IETF done. -- -- -- I also note that the RFC 3683 notes that a PR-Action may be -- appealed: -- -- Of course, as with all IESG actions, the appeals process outlined -- in [4] may be invoked to contest a PR-action approved by the IESG. -- -- By the use of the term unilaterally above and as a result of -- private conversation, I believe the author interprets RFC 3683 -- to mean that maintainers of any IETF list may remove posting rights -- for the individual *without appeal*. While I agree that 3683 -- does not call out the appeal path for it, I believe that any action -- taken by someone acting for the IETF in this way is subject -- to appeal. -- A statement by the IESG on whether it believes that mailing -- list maintainer -- actions under 3683 are subject to appeal would be welcome (as would -- an overhaul of 3683 in general). -- --
RE: Weekly posting summary for ietf@ietf.org
Marshall, Actually - assuming it has any effect at all - it would be worse than that. Not only will value adding posters be discouraged, but they will most likely handle the input process using another means (hallway conversations, off-line exchanges, etc.). This has the effect of diminishing the extent to which a few people are willing to involve others in the real processes of the IETF. However, I doupt very much that is the intent of giving this information out. It is useful - in general - to know who is talking a lot. It is then up to us to each decide on our own who is contributing and who is just making noise. I believe (or at least sincerely hope) that people adding value to a discussion will not decide that they themselves are just making noise. On the positive side, seeing yourself listed toward the top can make you think about the value of letting other people have a chance to say something. Especially if you're - like - third from the top... :-) -- Eric -- -Original Message- -- From: Marshall Eubanks [mailto:[EMAIL PROTECTED] -- Sent: Friday, February 24, 2006 2:34 PM -- To: Adrian Farrel -- Cc: Thomas Narten; ietf@ietf.org -- Subject: Re: Weekly posting summary for ietf@ietf.org -- -- Based on my experience, it will tend to discourage value -- adding posters, -- and encourage others. That may or may not be the desired response. -- -- Regards -- Marshall -- -- -- On Feb 24, 2006, at 11:25 AM, Adrian Farrel wrote: -- -- Thomas, -- -- Fascinating though I find these summaries to be, I wonder: -- - what relevance is there to the ordering in the list? -- - how do you pick which weeks to publish summaries for? -- -- [copy of your message snipped to keep down my byte count :-)] -- -- Adrian -- -- ___ -- Ietf mailing list -- Ietf@ietf.org -- https://www1.ietf.org/mailman/listinfo/ietf -- -- -- ___ -- Ietf mailing list -- Ietf@ietf.org -- https://www1.ietf.org/mailman/listinfo/ietf -- ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: IESG Statement on disruptive posting
Brian, Thanks for the clarification! -- Eric -- -Original Message- -- From: Brian E Carpenter [mailto:[EMAIL PROTECTED] -- Sent: Tuesday, February 21, 2006 12:57 PM -- To: Gray, Eric -- Cc: 'Sam Hartman'; ietf@ietf.org -- Subject: Re: IESG Statement on disruptive posting -- -- Eric, -- -- Gray, Eric wrote: -- ... --... there is a need to define who -- is what, he has a valid point. I moderate the MPLS -- mailing list, but -- there are others who are authorized to do so as well - -- including the -- ADs and WG Chairs. I assume this is true of other -- mailing lists as -- well, and I do not think that it is obvious to everyone -- who is on the -- list of people with authority to manage each list. -- -- That is the reason for the specific reference to the administrators -- listed at https://datatracker.ietf.org/public/nwg_list.cgi. -- --... the comment that Brian's terminology use -- is not consistent (Brian says the moderators or -- maintainers of IETF -- mailing lists that are not WG mailing lists in the -- beginning of his -- message and where the administrators are listed later on), -- -- It's not *my* terminology, it's an IESG statement. -- The inconsistent language in the two parts of the statement has -- been noted. -- -- ... reasonable in saying that a decision -- should name the AD consulted -- -- Reasonable and should, yes. -- https://datatracker.ietf.org/public/nwg_list.cgi lists the -- Areas, which gets you to a choice of two ADs at most, so the -- responsible AD is not hard to find. -- --I believe that at least a formal notification must occur and it -- must list those people involved in making the decision. -- -- Yes, I agree. -- --It would also be good from the list administrator's perspective -- if the notification was at least backed up by the -- consulted AD - if it -- does not in fact come from the consulted AD(s). -- -- Not sure I see why, but I'd certainly expect the AD to be -- copied. -- -- ... if there are lists that are -- maintained by the IETF site that do not properly belong under IESG -- authority, -- -- Those would not be at -- https://datatracker.ietf.org/public/nwg_list.cgi, -- so would be out of scope. -- -- or if there are lists maintained elsewhere that are kept on -- behalf of the IETF, but do not fall under IESG authority. -- I don't know -- that such lists exist, but it is possible that they do. -- -- If they do, they *are* are at -- https://datatracker.ietf.org/public/nwg_list.cgi -- --Would BoF mailing lists fall into this category? -- -- If they are listed at -- https://datatracker.ietf.org/public/nwg_list.cgi. -- -- ... there should -- be an announcement that such-and-such list now falls under the -- IESG authority -- -- Ideally yes, but since the list of such lists is public -- at https://datatracker.ietf.org/public/nwg_list.cgi, -- this is low on my list of change requests to the secretariat. -- -- Brian -- -- ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: 'monotonic increasing'
Tom, I'm sorry to disagree, but I feel that the term monotonic has a much better defined meaning than most terms in general (including - for example - the term term). There are definitely applications for the phrase monotonically increasing where the terminology is exactly correct and very hard to word-smith around. There are also cases in which the appropriate phrase might have been strictly monotonically increasing, and for one reason or another the word strictly was omitted. In such cases, it either was clear what was meant at the time, or it has become clear in the mean time. I really do not see why we need to get quite so retentive about terminology when we have the ability to ask questions about anything we don't understand completely. Nor do I believe that there is any way that we could avoid the need to ask questions strictly as a result of using perfect terminology (or phraseology). -- Eric -- -Original Message- -- From: Tom.Petch [mailto:[EMAIL PROTECTED] -- Sent: Wednesday, February 22, 2006 3:50 PM -- To: ietf; Frank Ellermann -- Subject: Re: 'monotonic increasing' -- -- - Original Message - -- From: Frank Ellermann [EMAIL PROTECTED] -- To: ietf@ietf.org -- Sent: Tuesday, February 21, 2006 3:57 PM -- Subject: Re: 'monotonic increasing' -- -- Marshall Eubanks wrote: -- -- a RFC-2119 type RFC to define mathematical terms ? -- -- Maybe more like some glossaries (Internet, security, -- I18N, ...), informational RFCs. But I think that's -- unnecessary. There are online math. dictionaries, -- authors can provide references for unlear terms, or -- say what they mean. -- -- Otherwise this thread is unlikely to do much to -- change the situation. -- -- It highlights why clear terms in RFC are good, -- defined by reference or inline. In some groups -- saying 'header' instead of 'header field', 'byte' -- instead of 'octet', or 'charset' instead of IIRC -- 'encoded character repertoire' is enough to start -- a thread. And 'monotonic increasing' instead of -- 'strictly (monotonic) increasing' is apparently a -- similar issue. --Bye, Frank -- -- -- What I see from this thread is that there are two common -- interpretations to -- the phrase 'monotonic increasing', either a sequence in -- which each number is -- greater than or equal to its predecessor, or one in which -- each number is -- strictly greater than its predecessor, with the former -- meaning having somewhat -- the greater support (at least amongst those with access to -- text books): which, -- of itself, makes it a risky term to use in a specification. -- -- I still think that it is sometimes used in RFC and I-D in a -- third sense, of a sequence of integers increasing by one -- each time, not a -- meaning anyone has supported. But only the editor can know -- what is really -- intended. -- -- So, the next time I see it used, perhaps in a Last Call of -- a pkix, kink or secsh -- I-D, I will seek further clarification. -- -- Tom Petch -- -- -- ___ -- Ietf mailing list -- Ietf@ietf.org -- https://www1.ietf.org/mailman/listinfo/ietf -- ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: IESG Statement on disruptive posting
Sam, I re-inserted JFC's original text below. Just to be clear, it looks as if JFC has some misunderstanding of IETF mailing lists, or - perhaps - knows of IETF mailing lists I am not aware of. Also, most of the formality he points out is both reasonable, and not in disagreement with your later reply to JFC's apparent response to you (I have not seen his response, so either it did not get to the list, or it was off-line). For example, when JFC says that there is a need to define who is what, he has a valid point. I moderate the MPLS mailing list, but there are others who are authorized to do so as well - including the ADs and WG Chairs. I assume this is true of other mailing lists as well, and I do not think that it is obvious to everyone who is on the list of people with authority to manage each list. Later, when JFC makes the comment that Brian's terminology use is not consistent (Brian says the moderators or maintainers of IETF mailing lists that are not WG mailing lists in the beginning of his message and where the administrators are listed later on), I think he is providing a reasonable example of how this might not be clear. If Brian is in fact talking about listed adminstrators, then JFC's comment is already addressed. In talking about a decision to suspend anyone for disruptive posting, it seems JFC is being reasonable in saying that a decision should name the AD consulted - assuming that the decision is formally announced or that a formal notification is required (since the Brian explicitly states that an AD would be consulted). Otherwise, it would be possible for any list manager to act unilaterally and he/she would only get caught if their decision is appealed. I believe that at least a formal notification must occur and it must list those people involved in making the decision. Otherwise, a decision such as this 1) may be in effect for some time before the individual becomes aware of it and 2) be completely non remediable in the case of wrong doing. It would also be good from the list administrator's perspective if the notification was at least backed up by the consulted AD - if it does not in fact come from the consulted AD(s). Finally, in making his point about formal delegation, I think JFC believes that there may be IETF mailing lists to which this set of rules should not apply. He may be right, if there are lists that are maintained by the IETF site that do not properly belong under IESG authority, or if there are lists maintained elsewhere that are kept on behalf of the IETF, but do not fall under IESG authority. I don't know that such lists exist, but it is possible that they do. Would BoF mailing lists fall into this category? In any case, asssuming that JFC is not making an incorrect assumption, then he is correct in his assertion that there should be an announcement that such-and-such list now falls under the IESG authority and a similar one - but with reversed sense - should any list stop being under the IESG authority, at least within the context of Brian's announcement. I do not think that such lists properly exist, but their (non) existence is what is at issue - rather than the formality of a list management process. I believe the default assumption should be that any mailing list maintained at the IETF site falls naturally and formally under IESG authority. However, how does this work for lists not actually maintained at the IETF mailing list site? In your later reply to JFC's (invisible) mail, you said: The IAB said that we need to have clear and public documentation of what we're doing. So people need to know what the rules are and need to know how to appeal decisions and how to disagree with rules. I do not see a fundamental difference between what you say and what JFC said previously. -- Eric -- -Original Message- -- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] -- On Behalf Of Sam Hartman -- Sent: Friday, February 17, 2006 9:19 PM -- To: Jefsey Morfin -- Cc: IETF Chair; ietf@ietf.org -- Subject: Re: IESG Statement on disruptive posting -- -- I think we disagree significantly on the level of formality needed -- here. -- Dear Brian, Comments embedded. According to RFC 2418 as updated by RFC 3934, WG chairs have the power to suspend disruptive posters on WG mailing lists for periods of 30 days. However, this power is not documented for the moderators or maintainers of IETF mailing lists that are not WG mailing lists. There is a need for a definition of who is what. Typically a list may have several moderators ignored by its members. In the absence of a BCP or RFC 3933 procedure to cover this case, and as part of its responsibility under RFC 2026 to organize and manage the Internet Standards process, the IESG has decided as follows: The administrators of such lists are authorized
RE: Last Call: 'TLS User Mapping Extension' to Proposed Standard
Russ, et al, There is a precedent that may need to be established here that is not relevant to the TLS Working Group (therefore their omission in the CC list above). The text to that Bill refers to actually says the following: These notices may not be used with any standards-track document or with most working group documents, except as discussed in Section 7.3 below, since the IETF must retain change control over its documents and the ability to augment, clarify and enhance the original IETF Contribution in accordance with the IETF Standards Process. Further, in section 7.3, RFC 3978 says the following: Occasionally a Contributor may not want to grant publication rights or the right to produce derivative works before finding out if an IETF Contribution has been accepted for development in the IETF Standards Process. In these cases the Contributor may include the Derivative Works Limitation described in Section 5.2 and the Publication Limitation described in Section 5.3 in their IETF Contribution. A working group can discuss the Internet-Draft with the aim to decide if it should become a working group document, even though the right to produce derivative works or to publish the IETF Contribution as an RFC has not yet been granted. If the IETF Contribution is accepted for development the Contributor must then resubmit the IETF Contribution without the limitation notices before a working group can formally adopt the IETF Contribution as a working group document. Because this document has not been accepted by any working group, the authors are perfectly within their rights to make changing wording of the derivative rights section contingent on the outcome of the IETF last call. -- Eric -- -Original Message- -- From: Russ Housley [mailto:[EMAIL PROTECTED] -- Sent: Sunday, February 19, 2006 5:22 PM -- To: Bill Fenner; Steven M. Bellovin -- Cc: iesg@ietf.org; [EMAIL PROTECTED]; ietf@ietf.org -- Subject: Re: Last Call: 'TLS User Mapping Extension' to -- Proposed Standard -- -- I misunderstood the original question. I'll get it fixed -- or withdraw -- the Last Call. -- -- Russ -- -- -- At 12:38 AM 2/19/2006, Bill Fenner wrote: -- -- Can we have a Proposed Standard -- without the IETF having change control? -- -- No. RFC3978 says, in section 5.2 where it describes the derivative -- works limitation that's present in draft-santesson-tls-ume, These -- notices may not be used with any standards-track document. -- --Bill -- -- -- ___ -- Ietf mailing list -- Ietf@ietf.org -- https://www1.ietf.org/mailman/listinfo/ietf -- ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: appeal to the IESG against an IESG decision
JFC, This appears to be an appeal in response to an action that - as far as I can tell - has not yet occurred. Scott's posting of the intent to consider does not appear to be any thing to which an appeal is appropriate, the dead-line for submission of comments was last Friday and - again as far as I know - no decision has yet been made. Therefore, your posting of information relating to an appeal seems to be both premature and inappropriate. In addition, several of the points you make in the site at which you post information relating to the appeal are both inappropriate to the process in this case and non-flattering to yourself. Surely you do not believe yourself to be accused of a criminal offense? -- Eric -- -Original Message- -- From: JFC (Jefsey) Morfin [mailto:[EMAIL PROTECTED] -- Sent: Sunday, February 19, 2006 11:27 PM -- To: ietf@ietf.org -- Subject: appeal to the IESG against an IESG decision -- -- FYI Isent an appeal to the IESG against an IESG decision on 17 Feb -- 2006 (at 17:59 GMT). -- You will find the text at http://jefsey.com/iesg-lc-appeal.pdf. -- jfc -- -- -- ___ -- Ietf mailing list -- Ietf@ietf.org -- https://www1.ietf.org/mailman/listinfo/ietf -- ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: 'monotonic increasing'
Tom/Yaakov, Getting back to the slightly related field of specification of standard protocols, the term monotonically increasing is used in many cases because that is all that really needs to be said. This is because the intent in the specification is to allow implementations to detect a roll-over or restart event by the simple process of checking to see if a new value is less than a prior value. Since this is the test that the implementations actually need to be able to perform in many cases, it is often sufficient to say exactly monotonically increasing and not necessary to say more than that. -- Eric -- -Original Message- -- From: Yaakov Stein [mailto:[EMAIL PROTECTED] -- Sent: Monday, February 20, 2006 11:12 AM -- To: Tom.Petch -- Cc: ietf -- Subject: RE: 'monotonic increasing' -- -- -- -- But just to be clear, if you saw a reference to -- 'monotonic increasing' -- in an American journal, -- say of applied mathematics, would you be sure you -- understood what was -- meant? -- -- -- That would depend on the subject matter. -- If the article was on real analysis (where the domain is -- nondenumerable), -- then it would most probably mean =. -- If the article's subject matter was concrete mathematics (i.e. -- discrete values) -- then increasing would probably mean and only -- nondecreasing would -- mean =. -- -- So in the case you raise, monotonic increasing would -- usually be strictly -- interpreted as x_n x_n-1, -- and if you want to include the case where the sequence -- doesn't actually -- increase -- you should say nondecreasing . -- -- However, since the Godel failure of Principia Mathematica -- even mathematicians have lost faith in consistent definitions : -- -- Y(J)S -- -- ___ -- Ietf mailing list -- Ietf@ietf.org -- https://www1.ietf.org/mailman/listinfo/ietf -- ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: IETF 65 BOF Announcement: Digital Identity Exchange (DIX)
Steven, There's a certain (very much non-zero) cost associated with announcing _anything_ very widely. Generally it means the person making the announcement has to subscribe to the list (and hope the list manager does not filter the announcement anyway) - in part so that it will actually get posted and in part to capture comments made on each list that do not also get posted to an appropriate list (no matter what the announcement says, this will happen). In addition, there have been complaints in the past to the general use of cross-posting, and some list managers may even be actively filtering (for moderation in any case) on the basis of these prior complaints. I suspect that posting it to the IETF mailing list must be considered sufficient, with the understanding that people who care are subscribed to this list. Better to expect people to subscribe to this list to find out about stuff like BoFs and new mailing lists than to declare open season on all mailing lists. If others, who already subscribe to additional lists, want to repost these on those other lists (as an FYI, because they feel they are relevant), that would take care of widening of the potential audience. -- Eric -- -Original Message- -- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] -- On Behalf Of Steven M. Bellovin -- Sent: Sunday, February 12, 2006 9:11 PM -- To: Hollenbeck, Scott -- Cc: Ted Hardie; [EMAIL PROTECTED]; ietf@ietf.org -- Subject: Re: IETF 65 BOF Announcement: Digital Identity -- Exchange (DIX) -- -- In message -- [EMAIL PROTECTED] -- .com, Hollenbeck, Scott writes: -- -- -- What sort of manner is that, Dave? That's a serious -- question. There is -- an open mailing list on which discussion has been taking -- place since the -- Vancouver meeting. There is still a month to continue -- discussion before -- Dallas. If something is too broad or not clear, please share your -- thoughts on the dix list so that appropriate changes can -- be considered. -- -- -- I think Dave has a point. It's not that there should be an active -- mailing list first -- ADs generally require a list and an -- I-D first, -- per RFC 2418 (a pointer to which should be in -- http://www.ietf.org/ietf/1bof-procedures.txt). The problem is that -- most people don't know about BoFs. I might be interested -- in tracking -- this one, but I learned of it only through John's voluntary -- posting to -- the IETF list. I agree with Dave -- BoFs should indeed be -- posted to -- the ietf-announce list as soon as they're approved. (By the same -- token, people proposing BoFs should announce their mailing -- lists quite -- widely. This one, for example, should have been sent to -- the SAAG list, -- among many other places, given the strong interest many -- security folks -- have in such issues.) -- -- --Steven M. Bellovin, http://www.cs.columbia.edu/~smb -- -- -- -- ___ -- Ietf mailing list -- Ietf@ietf.org -- https://www1.ietf.org/mailman/listinfo/ietf -- ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: I-D ACTION: draft-ash-alt-formats-01.txt
Yaakov, While I support the general idea behind the experiment advocated in this draft, in fairness, your statement below is just your version of what John said. To see how complex a set of equations might be easily shown in text, see http://www.ksc.nasa.gov/facts/faq04.html. Rocket science, I believe they call it. :-) So your statement boils down to extremely inelegant which is just another way to say uglier. -- Eric -- -Original Message- -- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] -- On Behalf Of Yaakov Stein -- Sent: Thursday, February 02, 2006 3:34 AM -- To: John Levine; ietf@ietf.org -- Subject: RE: I-D ACTION: draft-ash-alt-formats-01.txt -- -- -- If the goal is to allow prettier output while still -- maintaining the -- stability and reusability of plain text, that practically demands an -- input format that is plain text underneath -- -- No, the goal (as stated in the ID) is to enable normative -- drawings and -- equations that are -- not possible or extremely inelegant in plain text. -- -- Y(J)S -- -- ___ -- Ietf mailing list -- Ietf@ietf.org -- https://www1.ietf.org/mailman/listinfo/ietf -- ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: IAB Response to Appeal from Jefsey Morfin
Bernard, The way I interpret your statement is that you feel that replacement of the existing set of documents - possibly with a single new document - is preferred to writing one or more new documents with the intent to just glue the current set back together. Is that a correct interpretation? -- Eric -- -Original Message- -- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] -- On Behalf Of Bernard Aboba -- Sent: Tuesday, January 31, 2006 2:59 PM -- To: [EMAIL PROTECTED]; [EMAIL PROTECTED] -- Cc: [EMAIL PROTECTED]; iesg@ietf.org; ietf@ietf.org -- Subject: Re: IAB Response to Appeal from Jefsey Morfin -- -- My personal perspective is that on a subject as sensitive -- as banning, it is -- very important to have clear, well documented procedures -- dictating the -- process and who is allowed to initiate the ban. Creation -- of more documents -- may not be the solution to this problem, particularly since the -- applicability and overlap of the existing documents is -- already somewhat -- unclear. -- -- -- From: Leslie Daigle [EMAIL PROTECTED] -- To: Sam Hartman [EMAIL PROTECTED] -- CC: IAB [EMAIL PROTECTED], Iesg (E-mail) iesg@ietf.org, -- ietf@ietf.org -- Subject: Re: IAB Response to Appeal from Jefsey Morfin -- Date: Tue, 31 Jan 2006 14:42:24 -0500 -- -- Sam, -- -- One IAB member's perspective: no, the expectation is not -- BCP upon BCP upon BCP. -- -- The devil is, of course, in the details. Even community commented -- on published operational procedures should not be at odds with -- our general or specific process documents, or else that seems -- to suggest the process documents need updating. And we have -- a community-defined process for that (which seems to result -- in a BCP). -- -- Again -- that's just one person's perspective. -- -- Leslie. -- -- Sam Hartman wrote: -- -- So, a clarification request: -- -- Am I correctly understanding that the clear and public requirement -- does not always imply a process RFC? In particular, John -- Klensin has -- made an argument that there are a wide variety of matters that are -- better handled by operational procedures made available -- for community -- comment than by BCP document. -- -- It's my reading that the IAB is interested in making sure that the -- processes and rules are clear and public, not that they are all -- codified in BCP. -- -- -- I'm not looking for a formal response from the IAB but would -- appreciate comments from its members. -- -- --Sam -- -- -- -- -- -- -- ___ -- Ietf mailing list -- Ietf@ietf.org -- https://www1.ietf.org/mailman/listinfo/ietf -- ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: IETF65 hotel location
David, As I understand it, it would be a man-in-the-middle attack if you sat at a table and ordered a Burrito from a person you thought was a waiter. That person then goes to the counter, orders two burritos and a large coffee, to go. They then deliver one Burrito to you, along with the bill, and takes the other Burrito and the coffee with them. What you describe is more like high-jacking the transport mechanism... -- Eric -- -Original Message- -- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] -- On Behalf Of David B Harrington -- Sent: Saturday, January 28, 2006 1:12 PM -- To: 'Spencer Dawkins'; ietf@ietf.org -- Subject: RE: IETF65 hotel location -- -- Hi, -- -- This conversation of the IETF65 location started with an issue of -- security. -- -- I'd like to get this discussion back on track. -- What are the security requirements for a distributed burrito -- processing protocol? -- If you are traveling from the conference hotel to a -- restaurant and are -- mugged, is that considered a man-in-the-middle attack? -- -- dbh -- -- -Original Message- -- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On -- Behalf Of Spencer Dawkins -- Sent: Friday, January 27, 2006 3:26 PM -- To: ietf@ietf.org -- Subject: Re: IETF65 hotel location -- -- Hi, Mike, -- -- If we could morph it into a signup system that -- distributed people -- according to restauant capacity and avoided the problem -- that someone -- says I hear there's a burrito place on X street and a herd of -- 300 -- IETFers shows up there, since they don't know any other -- places to go, -- then you'd really have something. -- -- I'm afraid it's beyond IETF's expertise to come up with -- distributed burrito processing protocols. -- -- Mike -- -- If you think about this for a minute, you would realize that -- (1) we not only -- have protocols for this, but we have running code, and (2) -- too much focus -- on distributed burrito processing might explain a lot about -- where we are -- and how we got here! :-) -- -- Thanks, -- -- Spencer, who is wondering what a dining protocol designers -- multitasking -- algorithm might look like, with a burrito between every pair -- of protocol -- designers (with apologies to the dining philosophers) -- -- -- -- ___ -- Ietf mailing list -- Ietf@ietf.org -- https://www1.ietf.org/mailman/listinfo/ietf -- -- -- -- -- ___ -- Ietf mailing list -- Ietf@ietf.org -- https://www1.ietf.org/mailman/listinfo/ietf -- ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: too many notes -- a modest proposal
Anthony, ... -- -- Set a rolling monthly quota, then. Nobody constantly sends a long -- stream of consistently productive messages. -- -- 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. The most productive way to deal with questions in a working group is to answer them publicly on the list. To avoid the trip wire, however, most people woul simply answer specific questions off-line. That would be BAD. Debate on work in progress is critical, must be in public at least much of the time and will usually involve a small number of people - authors in particular - who simply must participate. On several occasions, I have seen productive debate on critical drafts take more than a month in some working groups. -- Eric ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: Free speech? Re: Against PR-action against Jefsey Morfin
Anthony, I actually feel that meeting summaries and - occasionally surveys - can be a critical constructive part of the process. -- Eric -- -Original Message- -- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] -- On Behalf Of Anthony G. Atkielski -- Sent: Tuesday, January 24, 2006 9:55 PM -- To: ietf@ietf.org -- Subject: 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 Results, which -- have nothing to do with these goals, are out of order? -- -- Decisions as to what counts as constructive are -- subjective, unfortunately. -- -- -- ___ -- Ietf mailing list -- Ietf@ietf.org -- https://www1.ietf.org/mailman/listinfo/ietf -- ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: Against PR-action against Jefsey Morfin
Noel, I think you may have bitten into a bear-trap. :-) First, the site you cite speculates that someone is the author of this note. That may be the case, but there is no evidence - contained at that site - to support that speculative assertion. It certainly is possible, maybe even very likely, that the letter originated at that someone's direct request or complaint. It may even have been the case that the same someone had a direct hand in the phrasing the words used in the letter - but all of that is speculative. We need more direct evidence that this someone actually did author the letter in question, before we should act as if we are convinced. Second, the letter complains not about something that someone else said, but something that someone else was doing. Specifically, it appears to me, that someone else is accused of trying to effectively silence the original someone. I believe that responding to a specific action of this sort is absolutely consistent with a belief in the right to be heard. Which is a good segue into one of your other points: I absolutely agree that the IETF is not here to provide free speech. However, the IETF MUST be an open forum in which people from different cultural and corporate backgrounds can be heard (as long as they can make even a weak case for the relevance of what they are saying) - when it comes to how we write protocols and how this process and effort is going to impact on them. We can't just create a cluster of good guys and go off into hall-way meetings to make decisions that affect many millions of people and many billions of dollars in the businesses and economies of the whole world. The bad guys also have a right to be heard - at least to the extent that they only want to be heard. I think the problem is that a lot of people want to send a message to a specific individual that they have heard him enough. And the only hammer lying near-by that is big enough to send that message is RFC 3683. In this case, this is definitely not the right thing to do. Use the tool that was intended for this purpose. If it doesn't work, then fix it. Don't just pick up the next bigger hammer without regard for the message that everyone else is going to get. -- Eric -- -Original Message- -- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] -- On Behalf Of [EMAIL PROTECTED] -- Sent: Tuesday, January 24, 2006 6:18 PM -- To: ietf@ietf.org -- Cc: [EMAIL PROTECTED] -- Subject: Re: Against PR-action against Jefsey Morfin -- -- From: william(at)elan.net [EMAIL PROTECTED] -- -- Free speech is at the core of discussions at IETF and those -- representing minority positions should not be prevented from -- expressing it -- -- 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 you to the most interesting: -- -- http://article.gmane.org/gmane.ietf.ltru/1033 -- -- especially where it says things like Reuters, my employer, -- received the -- following message today and 'We will contact tomorrow the -- Reuters legal -- department in Paris we will then copy and ask an -- acknowledgment from.' (And -- anyone who thinks that message to Reuters was not an -- attempt to create trouble -- for someone with their employer is being deliberately obtuse.) -- -- Noel -- -- PS: The IETF is *not* here to provide free speech. It's -- here to write -- protocols. Speech is subsidiary to that goal. -- -- ___ -- Ietf mailing list -- Ietf@ietf.org -- https://www1.ietf.org/mailman/listinfo/ietf -- ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: I-D ACTION:draft-palet-ietf-meeting-venue-selection-criteria- 04.txt
Brian, This seems to me to be somewhere on the continuum from no brainer to rocket science - with a high likelihood of not being too near the rocket science end. It would be good to caution the IETF Secretariat and meeting sponsors to consider the potential for difficulty in getting into and out of a specific meeting venue. It is also a good idea for would-be IETF meeting attendees to take time in advance of meetings to discover for themselves whether there has been in the past - or is likely to be in the future - any difficulty in getting into or leaving some specific meeting location. This applies to a lot of different considerations, including political, medical and physical issues with entry into and exit from any location. Many companies (and other organizations) maintain travel advisory status on a number of places. And sponsor organizations are most likely aware of the potential for embarrassment if the meeting location they sponsor causes a lot of grief for many of the wanna-be attendees (roughly equivalent to not having thought to offer T-shirts). There are plenty of reasons why people who might wish to - or even need to - attend a meeting are unable to do so, and we have been able to deal with it in the past. That's one reason why there is redundancy in the AD and WG Chair positions. About the only thing that really ought to be done is to add a caution to the web page under each IETF meeting, that would be where people could look to find out about any known issues relating to the meeting venue. Worst case scenarios are the ones where someone gets to a venue and finds out about serious problems that require them to immediately leave, or is turned around en-route because of - for example - border entry issues. -- Eric -- -Original Message- -- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] -- On Behalf Of Brian E Carpenter -- Sent: Sunday, January 22, 2006 4:01 AM -- To: ietf@ietf.org -- Subject: Re: I-D -- ACTION:draft-palet-ietf-meeting-venue-selection-criteria-04.txt -- -- Joe Abley wrote: -- -- On 20-Jan-2006, at 11:55, Wijnen, Bert (Bert) wrote: -- -- Well said Barry! -- -- From: Barry Leiba -- -- My biggest concern is in sections 2.3. Freedom of -- Participation -- and 2.5. Attendance Limitation and Visas, in that -- I'm not sure -- how realistic they are. Without getting overly into -- politics (let's -- please not), I think they reflect a somewhat naïve view -- of some of -- the political realities. Specifically... -- -- Meetings should not be held in countries where some -- attendees could -- be disallowed entry or where freedom of speech is not -- guaranteed for -- all participants. -- -- -- Indeed. Applied with vigour, this restriction implies -- that no country -- is suitable to meet in. That leaves us with parts of -- Antarctica, a -- floating venue located in international waters, or zero-g -- bar BOFs in -- outer space. I favour the latter. -- -- A slightly more realistic approach might be to hold -- meetings regularly -- in different countries with (ideally) divergent security/ -- immigration -- policies, in the hope that successive meetings might at -- least exclude -- different sets of people. -- -- This is a very important issue as we consider visiting -- countries we've never -- visited before and as visa regulations change in countries -- we have been -- to often. It would be very useful to know how more people -- feel we should -- tune these criteria. -- -- Brian -- -- -- ___ -- Ietf mailing list -- Ietf@ietf.org -- https://www1.ietf.org/mailman/listinfo/ietf -- ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: IETF Last Call under RFC 3683 concerning JFC (Jefsey) Morfin
Eliot, Plenty of time to ask why, once it becomes clear what the prevalent opinion is. I personally find the question a bit on the obnoxious side prior to that. When seeking consensus, it is usually necessary only to determine what the issues are in the minority opinion, and largely nosy-ness and distraction to ask the basis of the opinion among majority opinion holders. Consequently, people should first determine what direction the group is leaning before hosing the discussion with a bunch of questions about the why's and wherefore's of opinions. -- Eric -- -Original Message- -- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] -- On Behalf Of Eliot Lear -- Sent: Sunday, January 22, 2006 7:25 AM -- To: Marshall Eubanks -- Cc: Scott Hollenbeck; ietf@ietf.org; -- ietf-announce@ietf.org; iesg@ietf.org -- Subject: Re: IETF Last Call under RFC 3683 concerning JFC -- (Jefsey) Morfin -- -- Marshall, -- I do not support approval of this PR-action. -- -- Because.?? -- -- -- ___ -- Ietf mailing list -- Ietf@ietf.org -- https://www1.ietf.org/mailman/listinfo/ietf -- ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: how to declare consensus when someone ignores consensus
Ned, It is certainly fair to say that implementors do participate in mailing list discussions, and that their participation is very valuable. However, many times the number of participants that are active (read - vocal) are those that lurk and it is my opinion - supported by observation of, and discussion with, implementors at a number of different companies - that the proportion of lurkers that are implementors is somewhat higher than the proportion of active participants that are also implementors. I am also of the opinion that for each participant (either lurker or active), there are many implementors that participate vicariously through those others in their organization who are more disposed to participate. The number of implementors that do not - therefore - actively particpate in IETF working groups is many times the number that do - and this would clearly look to many people (especially to an out- sider) as if implementors are too busy implementing to participate in mailing list discussions. -- Eric -- -Original Message- -- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] -- On Behalf Of Ned Freed -- Sent: Monday, January 23, 2006 9:41 AM -- To: Anthony G Atkielski -- Cc: ietf@ietf.org -- Subject: 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 -- implementers whose support is valuable. The rest of the -- participants -- are valuable when they fix bugs. JFC doesn't seem to -- fix many bugs, -- and drives implementers away in droves, from what I can see. -- -- Which implementers are those? -- -- Implementers don't spend their time jabbering on -- discussion groups; -- they are too busy implementing. -- -- Gee, it's nice to know I don't exist - that will save me -- tons of time... -- -- As it happens I'm actively involved in the implementation -- of almost all of the -- protocol specifications I work on. I typically write the -- code myself for SMTP -- and sieve stuff, IMAP stuff is usually done by other -- people on my team. And -- this code usually ends up in commercial products used at -- lots of sites to -- support many millions of users - it is hardly an academic exercise. -- -- I know lots of other IETF participants who are involved in -- specification -- implementation. Quite a few of them write the code -- themselves. Some work on -- open source, others on propietary implementations, and -- there are even some that -- appear to do it just to make sure things really are -- implementable. In fact -- there are entire WGs (e.g., sieve) where almost all of the -- active participants -- appear to be implementors. -- -- Analyze, specific, code, test, -- release. No need for chewing the fat on a mailing list in that -- process. -- -- How very wrong you are. This sort of interaction is HUGELY -- valuable to -- implementors. -- -- And there are only so many hours in a day, so one can spend -- them doing things or spend them talking about doing -- things, but it's -- hard to manage both. -- -- This, at least, is true. But hard to manage != -- imposssible to manage. -- -- It has been suggested that I be placed under RFC 3683 -- sanctions in the -- past, though I suppose the offending messages have -- always been in -- response to misconduct (not a justification). I don't -- think the IETF -- is in any danger of developing a trigger finger here. -- -- If all the time spent discussing this most useless of RFCs were -- dedicated to actually addressing real problems, what might be -- accomplished? -- -- Aside from providing comic relief, exactly what does your -- your ridiculous -- assertion that implmentors don't particulate in the IETF -- accomplish? -- -- Ned -- -- ___ -- Ietf mailing list -- Ietf@ietf.org -- https://www1.ietf.org/mailman/listinfo/ietf -- ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: IETF Last Call under RFC 3683 concerning JFC (Jefsey) Morfin
Eliot, Ideally, nobody is just some person with a random opinion and the implication associated with asserting that someone stands out because of this is disingenuous - to say the least. If we do in fact learn anything from the reply you elicited, it is that there is more than one reason why the question is not appropriate - for this kind of question and at this point in the discussion. I do not doubt that you asked the question out of a sincere desire to find out what the answer is. However, there are plenty of people - here in the IETF as well as everywhere else in the world - who ask why for no other reason than to put the person expressing their opinion on the defensive. Consequently, I believe it is innappropriate to publicly question - or otherwise challenge - the opinions being sought in a discussion like this. As the announcement said, the IESG will be making a decision, it was the IESG that solicited comment and it should be up to the IESG to determine what level of detail is required with those comments and when additional information is needed. I suspect that the IESG will solicit additional input if they feel that there is a large minority opinion that they feel should be analyzed in detail. If people genuinely want to know what the basis for any individuals comments are - or wants to know more than a person was willing to say initially, then they should ask privately. If the individual in question receives enough private questions, perhaps they will - as in this case - choose to give a public answer. Or perhaps not. -- Eric -- -Original Message- -- From: Eliot Lear [mailto:[EMAIL PROTECTED] -- Sent: Monday, January 23, 2006 1:23 PM -- To: Gray, Eric -- Cc: Marshall Eubanks; Scott Hollenbeck; ietf@ietf.org; -- ietf-announce@ietf.org; iesg@ietf.org -- Subject: Re: IETF Last Call under RFC 3683 concerning JFC -- (Jefsey) Morfin -- -- Marshall's not just some person with a random opinion, but -- the ombudsman -- for the IETF list. And so he speaks with some authority. Also, he -- doesn't come to rash conclusions, and so I for one value -- his considered -- opinion. And that's why I prodded him for more. And I'm more -- enlightened because of it. -- -- Eliot -- ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: I-D ACTION:draft-palet-ietf-meeting-venue-selection-criteria- 04.txt
Marshall, RFCs are living documents as well, though the process for change is somewhat cumbersome. There are examples of RFCs that have been updated many times in the last few years. -- Eric -- -Original Message- -- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] -- On Behalf Of Marshall Eubanks -- Sent: Thursday, January 19, 2006 9:27 PM -- To: [EMAIL PROTECTED] -- Cc: ietf@ietf.org -- Subject: Re: I-D -- ACTION:draft-palet-ietf-meeting-venue-selection-criteria-04.txt -- -- Speaking just for myself : -- -- I think that there is a strong benefit to having an agreed -- upon set -- of parameters -- for new meeting locations. -- -- Having said that, this may not be appropriate for an RFC. Maybe it -- should be a living document on a web page -- or wiki, as is being done / considered for mailing list anti-SPAM -- suggestions. Maybe a new class of -- IETF document publication is needed. -- -- Regards -- Marshall Eubanks -- -- On Jan 19, 2006, at 8:53 PM, JORDI PALET MARTINEZ wrote: -- -- Hi Paul, -- -- I guess we can question ourselves the same way in many other -- documents ... -- -- The importance of having documents is part of the IETF working -- mode. Is -- our way to say, here there is a consensus on this specific topic. -- -- I guess is not my final decision if it will become and -- RFC or not, -- but it -- will not be fair not following the same path for this -- document as -- for many -- others. -- -- That said, the original idea has been, since I was -- pointed out for -- editing -- this document, to follow exactly the same process as with -- many other -- documents, technical and administrative. -- -- Regards, -- Jordi -- -- -- -- -- De: Paul Hoffman [EMAIL PROTECTED] -- Responder a: [EMAIL PROTECTED] -- Fecha: Thu, 19 Jan 2006 12:43:42 -0800 -- Para: Richard Shockey [EMAIL PROTECTED], IETF list -- ietf@ietf.org -- Asunto: Re: FW: I-D -- ACTION:draft-palet-ietf-meeting-venue-selection-criteria-04.txt -- -- At 2:28 PM -0500 1/19/06, Richard Shockey wrote: -- It's a classic example of the current IETF fashion for -- process over -- substance. -- -- Fully agree. What is the justification for this becoming an RFC? -- -- --Paul Hoffman, Director -- --VPN Consortium -- -- ___ -- Ietf mailing list -- Ietf@ietf.org -- https://www1.ietf.org/mailman/listinfo/ietf -- -- -- -- -- ** -- The IPv6 Portal: http://www.ipv6tf.org -- -- Barcelona 2005 Global IPv6 Summit -- Slides available at: -- http://www.ipv6-es.com -- -- This electronic message contains information which may be -- privileged or confidential. The information is intended -- to be for -- the use of the individual(s) named above. If you are not the -- intended recipient be aware that any disclosure, copying, -- distribution or use of the contents of this information, -- including -- attached files, is prohibited. -- -- -- -- -- ___ -- Ietf mailing list -- Ietf@ietf.org -- https://www1.ietf.org/mailman/listinfo/ietf -- -- -- ___ -- Ietf mailing list -- Ietf@ietf.org -- https://www1.ietf.org/mailman/listinfo/ietf -- ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: IETF Last Call under RFC 3683 concerning JFC (Jefsey) Morfin
In my opinion, this action is not appropriate in this case. -- Eric -- -Original Message- -- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] -- On Behalf Of Scott Hollenbeck -- Sent: Wednesday, January 18, 2006 7:35 AM -- To: ietf@ietf.org; ietf-announce@ietf.org -- Cc: iesg@ietf.org -- Subject: IETF Last Call under RFC 3683 concerning JFC -- (Jefsey) Morfin -- -- The IESG has received a request from Harald Alvestrand to -- approve an RFC -- 3683 PR-action (posting rights action) for JFC (Jefsey) -- Morfin as a -- result of a pattern of prior warning and posting rights -- suspensions for -- off-topic postings to the LTRU working group and -- ietf-languages mailing -- lists that have not produced a change in behavior. This -- behavior has been -- characterized as a denial-of-service attack to disrupt the -- consensus-driven process as described in Section 1 of RFC -- 3683. A timeline -- of warnings and posting rights suspensions related to this -- request is -- included below. -- -- The IESG will consider this request. If approved, the -- PR-action described -- in Section 2 of RFC 3683 includes provisions to allow list -- administrators to -- suspend Mr. Morfin's posting rights to the LTRU working group and -- ietf-languages mailing list for at least one year. -- Maintainers of other -- IETF mailing lists may also remove posting rights to their -- mailing lists at -- their discretion. -- -- The IESG plans to make a decision in the next few weeks, -- and solicits final -- comments on this action. Please send any comments to the -- iesg@ietf.org or -- ietf@ietf.org mailing lists by 17 February 2006. -- -- For the IESG, -- Scott Hollenbeck -- Applications Area Director -- -- -- -- Private warnings sent for LTRU working group mailing list postings: -- 7 July 2005 -- 16 July 2005 -- 23 September 2005 -- 26 October 2005 -- -- Public warnings and suspensions for LTRU working group and -- ietf-languages -- mailing list postings: -- -- 17 March 2005 (ietf-languages warning) -- http://www.alvestrand.no/pipermail/ietf-languages/2005-March -- /003236.html -- -- 5 April 2005 (LTRU warning) -- http://www1.ietf.org/mail-archive/web/ltru/current/msg00564.html -- -- 12 May 2005 (LTRU suspension) -- http://www1.ietf.org/mail-archive/web/ltru/current/msg01737.html -- -- 26 May 2005 (LTRU warning) -- http://www1.ietf.org/mail-archive/web/ltru/current/msg01897.html -- (Used as basis for 4 July suspension.) -- -- 15 June 2005 (ietf-languages suspension) -- http://www.alvestrand.no/pipermail/ietf-languages/2005-June/ -- 003474.html -- -- 4 July 2005 (LTRU suspension) -- http://www1.ietf.org/mail-archive/web/ltru/current/msg02532.html -- (Appealed to AD, appeal upheld, new warning given.) -- -- 5 July 2005 (LTRU warning) -- http://www1.ietf.org/mail-archive/web/ltru/current/msg02548.html -- -- 15 September 2005 (ietf-languages suspension) -- http://www.alvestrand.no/pipermail/ietf-languages/2005-Septe -- mber/003585.html -- -- 26 September 2005 (LTRU warning) -- http://www1.ietf.org/mail-archive/web/ltru/current/msg03755.html -- -- 7 October 2005 -- PR-Action request sent to IESG -- http://www1.ietf.org/mail-archive/web/ietf/current/msg38183.html -- -- 15 October 2005 (LTRU warning) -- http://www1.ietf.org/mail-archive/web/ltru/current/msg03941.html -- -- 8 November 2005 (LTRU suspension) -- http://www1.ietf.org/mail-archive/web/ltru/current/msg04032.html -- (Appealed to AD, appeal denied by AD.) -- -- 20 November 2005 (ietf-languages suspension) -- http://www.alvestrand.no/pipermail/ietf-languages/2005-Novem -- ber/003811.html -- (Appealed to AD/IESG, appeal denied by IESG, appealed to the IAB.) -- -- 13 January 2006 (ietf-languages suspension) -- http://www.alvestrand.no/pipermail/ietf-languages/2006-Janua -- ry/003854.html -- -- -- ___ -- Ietf mailing list -- Ietf@ietf.org -- https://www1.ietf.org/mailman/listinfo/ietf -- ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: FW: IETF Last Call under RFC 3683 concerning JFC (Jefsey) Mor fin
Sam, Clearly we should be thinking about some way to charge participants for potentially abusing the IETF appeals process in general. There is some minimal processing time associated with any appeal for everyone who has anything to do with it. I don't think posting rights is the way to do this. For one thing, it is obvious that this too can be appealed. Perhaps the appeal process should require that a token cash amount must be deposited with some ISOC general fund - with the provision that the deposit would be reimbursed if the appeal is found to have merit? -- Eric -- -Original Message- -- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] -- On Behalf Of Sam Hartman -- Sent: Friday, January 20, 2006 4:14 PM -- To: Frank Ellermann -- Cc: ietf@ietf.org -- Subject: Re: FW: IETF Last Call under RFC 3683 concerning -- JFC (Jefsey) Morfin -- -- Frank == Frank Ellermann [EMAIL PROTECTED] writes: -- -- Frank Unrelated, I'm not sure why it was published -- _there_ , the -- Frank IAB has its own directory for appeals. -- -- It's an appeal to the IESG. -- -- Jefsey's been a bit active in the appeal front lately: -- -- 1) He appealed a typo correction in RFC 3066bis to the area -- director. -- -- 2) He appealed the rejection in 1 above to the IESG. -- -- 3) He appealed his posting suspension from ietf-languages -- to the area -- director, but the area director believed the IESG as a whole -- needed to rule so we did. -- -- 4) He appealed 3 above to the IAB. -- -- 5)He appealed the approval of RFC3066bis to the IESG. That -- appeal is ongoing. -- -- -- ___ -- Ietf mailing list -- Ietf@ietf.org -- https://www1.ietf.org/mailman/listinfo/ietf -- ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: Last Call: 'A Roadmap for TCP Specification Documents' to In formational RFC
If we can make positive comments, I think this is a really useful document to have... -- Eric -- -Original Message- -- From: [EMAIL PROTECTED] -- [mailto:[EMAIL PROTECTED] On Behalf Of The IESG -- Sent: Wednesday, January 18, 2006 4:39 PM -- To: IETF-Announce -- Cc: [EMAIL PROTECTED] -- Subject: Last Call: 'A Roadmap for TCP Specification -- Documents' to Informational RFC -- -- The IESG has received a request from the TCP Maintenance -- and Minor Extensions -- WG to consider the following document: -- -- - 'A Roadmap for TCP Specification Documents ' --draft-ietf-tcpm-tcp-roadmap-05.txt as an Informational RFC -- -- The IESG plans to make a decision in the next few weeks, -- and solicits -- final comments on this action. Please send any comments to the -- iesg@ietf.org or ietf@ietf.org mailing lists by 2006-02-01. -- -- The file can be obtained via -- http://www.ietf.org/internet-drafts/draft-ietf-tcpm-tcp-road -- map-05.txt -- -- -- ___ -- IETF-Announce mailing list -- IETF-Announce@ietf.org -- https://www1.ietf.org/mailman/listinfo/ietf-announce -- ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: Binary Choices?
Ted,
I think we disagree on fine points and agree on the bigger
points.
As Melinda Shore aptly put it ('objection to proposed change
to consensus' on Saturday, 1/7/2006, at 10:15 AM Eastern Time):
'Consensus process leads to decisions being made through synthesis
and restatement, and by the time that the question is asked Do we
have consensus? we should pretty much have consensus already.'
While the point at which a question can be asked that is likely to
engender consensus is not always going to be quite this binary, it
is often the case that people will not try to 'call' for consensus
until there are no more than three choices - and usually it will be
when there are no more than two.
--
Eric
-- -Original Message-
-- From: Theodore Ts'o [mailto:[EMAIL PROTECTED]
-- Sent: Monday, January 09, 2006 10:43 PM
-- To: Gray, Eric
-- Cc: 'Sam Hartman'; Sandy Wills; IETF General Discussion Mailing List
-- Subject: Re: Binary Choices?
--
-- On Mon, Jan 09, 2006 at 12:57:56PM -0500, Gray, Eric wrote:
--
-- Usually, before you can actually seek consensus, you must have an
-- essentially binary choice. It is hard enough to reach consensus
-- on simple choices without turning up the process noise by having a
-- plethora of possible choices.
--
--
-- I disagree here. The process of seeking consensus means you have to
-- sort *through* the plethora of possible choices, and see which ones
-- meets the needs and requirements of the stakeholder. If you have a
-- binary choice, all you can really do is force a vote. So
-- hopefully by
-- the time that you come up to your last two choices, they hopefully
-- aren't binary in the sense of 0 and 1 being diametric opposites.
-- Hopefully the two or three final choices are pretty closely
-- except for
-- a few minor details (and then we end up spending huge amount of time
-- arguing over those tiny details :-)
--
-- - Ted
--
___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf
RE: Normative figures
Stewart, Yes, you are correct. But, if you had correctly understood the comment you quote below, you would realize that we're clearly in agreement already - at least on that aspect of the discussion. :-) My point is that we make inclusion of elaborate figures more difficult because elaborate figures don't necessarily make for a better understanding - any more than complicated equations do. If people generally agree that complicated diagrams, tables, figures or equations is necessary to understanding a specification - then it is quite possible to do so. The fact that this makes it (at least slightly) harder to write a specification if it must include complex art, does not impact on the difficulty in reading the resulting specification. However, as pointed out several times, making it trivially easy to include complex art MAY make reading specifications that do not require it much harder. Since the vast majority of documents produced by the IETF do not appear to require complex art, our process is optimized for the normal case - just as it should be... -- Eric -- -Original Message- -- From: Stewart Bryant [mailto:[EMAIL PROTECTED] -- Sent: Monday, January 09, 2006 11:40 PM -- To: Gray, Eric -- Cc: ietf@ietf.org -- Subject: Re: Normative figures -- -- -- We write specifications so that they are easier to read, validate -- and understand, not so that they are easier to write. -- -- -- -- -- Eric -- -- We write specs so that they will be correctly implemented. -- Anything that makes a specification easier to correctly understand -- surely makes it more likely that it will be correctly implemented? -- -- The cost of incorrect implementation is so high that we can -- can afford to pay a relatively high cost in the effort and -- technology needed to read and write the specification. -- -- - Stewart -- -- -- -- -- ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: Normative figures
Stewart, You address this to me - though I do not make these rules. However, I will do my best to answer your question. In the case you pose below, almost incomprehensible is the key phrase. Had you not qualified incomprehensible, the answer would be no, at least IMO. Moreover, I believe there is evidence to this effect, as pointed out previously, in the fact that at least one RFC is essentially only available in PS and PDF format. However, as long as a text version is comprehensible, it should be the normative version - simply because, however hard it might be to overcome the difficulty in comprehending it for the average reader, it is not sufficient to justify making it absolutely impossible to comprehend for any specific minority of readers (at least among those minorities that are likely to be required to understand it). Minorities in this context inclide anyone who does not have the ability to use the needed document display tools - either because they do not have them or because they are otherwise prevented from using them. However, as must be apparent from other discussion in various related threads, this is only a minority consideration. -- Eric -- -Original Message- -- From: Stewart Bryant [mailto:[EMAIL PROTECTED] -- Sent: Tuesday, January 10, 2006 12:01 AM -- To: Gray, Eric -- Cc: ietf@ietf.org -- Subject: Re: Normative figures -- -- -- Yes. And, if we're talking about wanting to make the figures -- normative, I assume we are talking about a specification. In -- that case, it is far more important that the description MUST -- be precise, than it is that it MAY be convenient. -- -- -- -- Please can we clarify the existing rules: -- -- For a standards track document is it technically acceptable -- to provide: -- -- A .pdf that is complete (but is non-normative under current rules) -- -- plus -- -- An ASCII text in which the background material refers to -- figures in the -- .pdf but which contains the essential normative statements. -- -- i.e. Is a standards track RFC approvable when it is correct in the -- technical -- sense, even if it is almost incomprehensible without the -- text, figures and -- equations from its non-normative twin. -- -- - Stewart -- ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: Working Group chartering
Eric, --- [SNIP --- -- IMHO, *way* too many I*E*TF work groups get chartered based on -- an idea. We then spend tons of resources on figuring out if the -- idea will work. We produce lots of half-baked documents with -- little basis in working code. Then folks try implementing -- what's been spec'ed, find it doesn't work, but then find a ton -- of resistance to change, because the specs are three years old -- and we don't want to break draft-mumble-05 implementations. -- -- If something is an idea, let's make it politically acceptable -- for the work to be done in the I*R*TF first. -- --- [SNIP] --- I think this is a gross mischaraterization of current practice in the IETF generally - however many exceptions we might find. Usually - at least among those of us that work for a living - we would not bring something to the IETF unless we were already in the process of implementing it and we have been encouraged by our employers (or - indirectly - by our customers) to bring it to the IETF. When people bring ideas to the IETF that seem like a good thing but aren't practical or implementable at the current time, they are usually encouraged to take those ideas to the IRTF. -- Eric ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: Binary Choices?
Sam/Sandy, See below... -- Eric --- [SNIP] --- -- Sandy Unfortunately, there seems to be a religious dogma -- Sandy among the long-time IETF participants that they never take -- Sandy votes. All they do is judge rough or smooth concensus, and -- Sandy that reduces our options to simple binary choices. -- -- I'm very confused here; as far as I can tell judging consensus works -- much better with things in the middle than any sort of votes. Ultimately, you're both right. Usually, before you can actually seek consensus, you must have an essentially binary choice. It is hard enough to reach consensus on simple choices without turning up the process noise by having a plethora of possible choices. However, the process of seeking consensus does tend to solicit the reasons and feelings involved in making choices and this can lead to solution searches in the gray-areas between proposals. -- -- --Sam -- -- -- ___ -- Ietf mailing list -- Ietf@ietf.org -- https://www1.ietf.org/mailman/listinfo/ietf -- ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: Normative figures
Stewart, There's a joke that goes something like this: there are three kinds of people in this world - those that are good at Math and those that are not. Funny thing is that there are at least three ways in which people approach mathematical expressions: 1) Some see a nice, clean, symbolic expression and mentally reject it out of hand (for these people, a summation symbol terminates a line of readable text); 2) Some see a symbolic expression, look at it briefly and become (as one person said earlier about figures) convinced they understand it while actually they do not (this can be established by a simple search for published material in which non-sensical mathematical expressions were included without comment in peer reviews); 3) Some people see any symbolic expression and play with it until either they understand it or they know what is wrong with it. In the first two cases - in which, I think we can agree, most people would fall - it is much better to have made the effort to put the expression in plain English - however much prettier it would have been in symbolic representation. -- Eric -- -Original Message- -- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] -- On Behalf Of Stewart Bryant -- Sent: Monday, January 09, 2006 2:22 PM -- To: Bob Braden -- Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED]; -- ietf@ietf.org; sbrim@cisco.com -- Subject: Re: Normative figures -- -- Bob Braden wrote: -- -- * -- * Normative figures perhaps. Normative equations definitely. -- -- Scott, -- -- How about Sections 4.2.3.3 and 4.2.3.4 of RFC 1122 (1889), -- for examples -- of readable equations in ASCII? I my experience, -- normative protocol -- technical specifications rarely need equations much more -- complex than -- these examples. The only significant exception I can -- think of is the -- NTP spec. -- -- People who REALLY use equations generally prefer LaTeX. -- -- Bob Braden -- -- -- -- -- The draft has expired so I need to point to an external -- version. This draft -- which is looking at the properties of a routing network -- under conditions of -- failure would have been much clearer if it could have used -- mathematical -- notation rather than ASCIIised equations -- -- http://www.faqs.org/ftp/pub/internet-drafts/draft-atlas-ip-l -- ocal-protect-uturn-02.txt -- -- Of course the diagrams could have also been clearer, as is seen by -- comparing them to the ones that Alia used in her presentatons on the -- subject. -- -- - Stewart -- -- -- ___ -- Ietf mailing list -- Ietf@ietf.org -- https://www1.ietf.org/mailman/listinfo/ietf -- ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: Normative figures
Stewart, You realize that the text example you gave is meaningless - without making some (potentially non-obvious) assumptions, right? -- -Original Message- -- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] -- On Behalf Of Stewart Bryant -- Sent: Monday, January 09, 2006 2:47 PM -- To: Sam Hartman -- Cc: Harald Tveit Alvestrand; ietf@ietf.org -- Subject: Re: Normative figures -- -- Sam Hartman wrote: -- -- Hi. With the exception of packet diagrams, I think all -- the examples -- you bring up benefit significantly from clear textual description. -- -- Sam -- -- I am not saying that clear text is not needed to accompany -- a diagram. -- However a diagram allows a lot less text to be written producing a -- shorter clearer draft with less clutter. -- -- For example you could say the following in text : router A connects to -- router B and D, the cost from A to B is 2, and the cost from A to D is 4. A --(2)-- B | +---(4)-- D -- Router B connects to router C. The cost to router A is 6, and -- the cost to router C is 10. + A --(6)--+ | | | | +--(2)-- B --(10)-- C | +--(4)-- D (Assumes cost is from router B in both cases) -- Router C connects to router D. The cost to router B is 9 -- and the cost to router D is 8. + A --(6)--+ | | | | +--(2)-- B --(9)---+ | | | | +--(10)-- C | | +--(4)-- D (8)---+ (Assumes cost is from router C in both cases) -- The cost from router D to router A is 16 and ... +--+ | | | +- A --(6)--+ | | | | | | +--(2)-- B --(9)---+ | | | | | +--(16)+ +--(10)-- C | | | +--(4)-- D (8)+ -- -- ... the cost to router A is 99. ? (Assuming you meant the cost from D to C - not A) +--+ | | | +- A --(6)--+ | | | | | | +--(2)-- B --(9)---+ | | | | | +--(16)+ +--(10)-- C -+ | | | | +--(4)-- D (8)+ | | | +-(99)+ (Figure foo?) -- -- In fact you would probably need a table to make sure that -- you did not make a mistake. In either case it is hard for -- most people to figure out the what the topology is much -- less imagine packet actions. Actually, you need a figure to make sure that you did not make a mistake, and a second set of eyes to compare what you said to what you apparently meant. -- -- Now compare this to: -- -- The network and costs are as shown in figure foo. -- Is the above actually figure foo? The reality is that it would be better to break it this way: In the network in figure foo, the link costs are as follows: A - B = 2 B - A = 6 +- A B -+ A - D = 4 || D - A = 16 +- D C -+ B - C = 10 C - B = 9 Figure foo C - D = 8 D - C = 99 -- Simple text and the visualisation is already done for you -- so you can focus on the problem. -- The reality is that putting things entirely in pictures means that less validation of the intent of the picture is possible. Keeping pictures as simple as possible is, therefore, a goal since it is far easier to make mistakes in complex figures and far more difficult to determine that a mistake has been made. Using a mixture of text and figure(s), tables or - possibly - equations makes it both more understandable and easier to be certain of conveying the idea(s). For example, in the above, I could verify that I understand your intent by asking: From this it is apparent that the link cost (D-C) is 99, but the actual minimum cost of getting from D to C given by the formula: (D-A) + (A-B) + (B-C) = 16 + 2 + 10 = 28 Is that correct? If we choose to use a simple combination of representations, rather than strictly expecting a figure to explain it all, the figure is likely to be far simpler. For example, using an approach similar to the above, you could probably describe a much more complex network than 13, or 20 or maybe even 30 nodes using ASCII art. The purpose of the picture is to be a simplified referent. -- -- Now I realise the above could be done in ascii art, but we -- have problems that need 13 or more nodes to set up. -- -- I believe I'd think that even if I could see the diagrams -- and I believe I have enough experience with visualization -- (although not sight) to be confident in that belief. -- -- -- -- As such, I don't believe these diagrams should be normative. -- -- -- I actually thin that many of the tunnel overlay network documents -- (PWE3, L2VPN, L3VPN) could benefit significantly from more focus on -- the text of the descriptions of situations being described. -- --
RE: Normative figures
Stewart, See below... -- Eric -- -Original Message- -- From: Stewart Bryant [mailto:[EMAIL PROTECTED] -- Sent: Monday, January 09, 2006 6:50 PM -- To: Gray, Eric -- Cc: ietf@ietf.org -- Subject: Re: Normative figures -- -- Eric -- -- You are missing the point. -- Out of politeness, let's consider the possibility that I am not missing the point. -- -- I was picking an example out of thin air, but it is the -- type of construct that we use all the time in fast-reroute. -- I follow that discussion in each WG in which it has come up. -- -- The example was four routers connected together in a -- square with some randomly chosen asymetric costs. Such a -- network is trivial, but FRR need to cope with arbitary -- network fragments with arbitary costs, so there are lots -- of fragments that we have created for study the properties -- of. -- Yes. And, if we're talking about wanting to make the figures normative, I assume we are talking about a specification. In that case, it is far more important that the description MUST be precise, than it is that it MAY be convenient. As I indicated in my response, it is possible to represent a lot of different topologies in simplistic figures with textual descriptions and - potentially other means of helping readers to understand _and_ verify the specification. -- -- One of the ways to operate on the fragment is to draw it and -- then to figure out the packet flows, consequences of failure etc -- etc. -- -- Now the question is why should the examples in our drafts be forced -- by our ability to describe them, rather than being the example that -- most clearly illustrates the problem and its solution? -- There are two issues built into this question: 1) Are the available tools preventing completion of the task, or do they merely constrain the ways in which it can be done? 2) Is the purpose of the task to describe, or to illustrate, the specified solution? I believe these two questions - taken separately - have been beaten utterly to death. In the first issue, it is clear that a number of people feel that the current tools merely constrain the specification process. To many of those people, this is a good thing. In addition, nobody has yet been able to demonstrate an example of a case where the tools - as they are (and including the potential for PDF use) are preventing the completion of any specification task. In the second issue, it SHOULD be clear that the task is to give as precise a description as possible. Most everyone agrees that figures, tables and equations MAY help. Most everyone agrees that they MAY occasionally be necessary for correct understanding of a specification. And most people agree that text MUST be precise and complete for specification wherever it is possible to do so. Figures help to understand. In many cases, they are not required. The fact that an accurate description in text may not be easy to produce is not nearly as important as the fact that a description in text is easier to test for correctness. We write specifications so that they are easier to read, validate and understand, not so that they are easier to write. -- -- - Stewart -- -- -- Gray, Eric wrote: -- -- Stewart, -- --You realize that the text example you gave is meaningless - -- without making some (potentially non-obvious) assumptions, right? -- -- -- -Original Message- -- -- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] -- -- On Behalf Of Stewart Bryant -- -- Sent: Monday, January 09, 2006 2:47 PM -- -- To: Sam Hartman -- -- Cc: Harald Tveit Alvestrand; ietf@ietf.org -- -- Subject: Re: Normative figures -- -- -- -- Sam Hartman wrote: -- -- -- -- Hi. With the exception of packet diagrams, I think all -- -- the examples -- -- you bring up benefit significantly from clear textual -- description. -- -- -- -- Sam -- -- -- -- I am not saying that clear text is not needed to accompany -- -- a diagram. -- -- However a diagram allows a lot less text to be written -- producing a -- -- shorter clearer draft with less clutter. -- -- -- -- For example you could say the following in text : -- router A connects to -- -- router B and D, the cost from A to B is 2, and the -- cost from A to D is -- 4. -- --A --(2)-- B -- | -- +---(4)-- D -- -- -- Router B connects to router C. The cost to router A is 6, and -- -- the cost to router C is 10. -- -- + A --(6)--+ -- | | | -- | +--(2)-- B --(10)-- C -- | -- +--(4)-- D -- -- (Assumes cost is from router B in both cases) -- -- -- Router C connects to router D. The cost to router B is 9 -- -- and the cost to router D is 8. -- -- + A --(6)--+ -- | | | -- | +--(2)-- B --(9)---+ -- | | | -- | +--(10)-- C -- | | -- +--(4)-- D (8)---+ -- -- (Assumes cost is from router C in both cases) -- -- -- The cost from
RE: objection to proposed change to consensus
-- -- I think we have reached substantial agreement on the following -- statement: ASCII text was good enough for my Grandfather, and it's -- going to be good enough for my grandchildren. Please reply to this -- CfC if you object. -- I object. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: objection to proposed change to consensus
Spencer, -- -- It shouldn't be a vote (we don't vote - I know you know this, because you -- put vote in quotes), but if we had some way to let people say you know, -- I just don't care, that would help, too. -- I agree, and it could also be very useful should we ever start to realize that it is important to gauge who is paying attention as well as who is subscribed. -- Spencer -- -- -- -- ___ -- Ietf mailing list -- Ietf@ietf.org -- https://www1.ietf.org/mailman/listinfo/ietf -- ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: objection to proposed change to consensus
Randy, Nosey, aren't we? :-) If you must know, let's see: one grandfather worked in a machine shop during WWII, retired in the late 50s; the other was in the Army for WWI and a farmer, sawyer, moon-shiner and road worker the rest of his life (being a farmer isn't a living, it's a hobby). I doubt ASCII figured much into either of their lives. ASCII isn't good enough for me, but PDF is useful where the problem is really bad. Between them (counting PS as a variation of PDF - especially since I have to convert PS to PDF to read it) they are what there is. I don't even pretend to know what will be good for my own grandchildren because - so far - I don't even know that I will ever have any. My point in making a terse response was that all that was asked for was objections. Sometimes, reasons are neither asked for nor needed. I suspect that - now that you know the reasons - you might agree that this was one of those times... -- Eric -- -Original Message- -- From: Randy.Dunlap [mailto:[EMAIL PROTECTED] -- Sent: Friday, January 06, 2006 1:21 PM -- To: Gray, Eric -- Cc: 'Sandy Wills'; Ken Raeburn; IETF General Discussion Mailing List -- Subject: RE: objection to proposed change to consensus -- -- On Fri, 6 Jan 2006, Gray, Eric wrote: -- -- -- I think we have reached substantial agreement on -- the following -- -- statement: ASCII text was good enough for my -- Grandfather, and it's -- -- going to be good enough for my grandchildren. Please -- reply to this -- -- CfC if you object. -- -- IMO an objection should be required to also have an explanation. -- -- I object. -- -- Why? to which parts? the grandfather/grandchildren? -- -- -- -- ~Randy -- ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: objection to proposed change to consensus
Sam, It is useful sometimes to differentiate those who have no stake in a particular issue from those who are not paying attention. Sometimes (maybe most of the time) it is not a very important distinction, and the IETF treats it this way all of the time. Maybe that's the right way to go. Maybe not. -- Eric -- -Original Message- -- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] -- On Behalf Of Sam Hartman -- Sent: Friday, January 06, 2006 10:51 AM -- To: Spencer Dawkins -- Cc: IETF General Discussion Mailing List -- Subject: Re: objection to proposed change to consensus -- -- Spencer == Spencer Dawkins [EMAIL PROTECTED] writes: -- -- Spencer So... here's the problem. -- Personally, I object to the suggestion that my -- vote should be -- counted one way or another if I am silent. At most, -- it should -- be counted as no strong opinion. Or should I now start -- responding to all the Last Calls with I don't care -- about this, -- so please don't count me as supporting it? -- -- Spencer Our technology support for do we have consensus -- Spencer stinks. We ask for feedback to a mailing list, knowing -- Spencer that me, too postings are (and should be) discouraged -- Spencer in most shared e-mail environments. What we get is -- Spencer exactly what you described - postings from a non-random -- Spencer subset of participants, and then we try to figure out -- Spencer what the sampling error is, and in which -- direction, based -- Spencer on not a lot more information. There is a safety -- Spencer mechanism, because when we REALLY miscount we can be -- Spencer appealed, but we don't use it often, and it's really an -- Spencer expensive mechanism to use. -- -- I'm not sure I consider this very broken. If I'm reading a -- last call -- and I have opinions that differ from the way the discussion -- is going, -- I'm certainly going to speak up. It seems to work fairly well in -- practice at determining rough consensus when there is a rough -- consensus to be determined. It gives questionable results in cases -- where the results are questionable; I'm not sure this a bug. -- -- Spencer some way to let people say you know, I just -- don't care, -- Spencer that would help, too. -- -- And what do we do with those people anyway? How would it help me to -- know there are 30 people who don't care? -- -- -- ___ -- Ietf mailing list -- Ietf@ietf.org -- https://www1.ietf.org/mailman/listinfo/ietf -- ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: objection to proposed change to consensus
Bob, State Diagrams is a bad example. State machines can, and should always be, described definitively in text. State machine diagrams must be derived from textual description. Consequently, if we want to create a document with a pictorial representation, that document could contain normative references to a document containing a textual description and not the other way around. Being able to put both in the same document and have that document be authoritative would be a plus, provided we could be sure that everyone could read that document. Perhaps a better example might be complex functional block diagrams. Or mathematical expressions as someone else pointed out earlier. If your point is that there are things that are painfully hard to represent in text, obviously that is true - although we have had several people argue that this is a good thing, most of the time. -- Eric -- -Original Message- -- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] -- On Behalf Of Bob Braden -- Sent: Friday, January 06, 2006 1:57 PM -- To: [EMAIL PROTECTED] -- Cc: ietf@ietf.org -- Subject: RE: objection to proposed change to consensus -- -- -- * -- * -- -- * -- I think we have reached substantial agreement -- on the following -- * -- statement: ASCII text was good enough for my -- Grandfather, and it's -- * -- going to be good enough for my grandchildren. -- Please reply to this -- * -- CfC if you object. -- * -- -- * -- -- Are we all in favor of Motherhood and Apple Pie? Well, mostly. -- -- No one (well, the IETF is a big tent, so that's probably -- too strong... -- almost no one) questions the desirability of a better format for -- publishing RFCs than pure ASCII text. This has been the subject of -- repeated discussions over the last 20 years. Will the same -- discussion -- be taking place 20 years from now? I, for one, certainly hope not. -- -- However, simply wishing we had a better solution is not enough. We -- need to have such a reasonable solution in hand before we agree to -- adopt it. We believe we want vendor neutrality, ubiquity, -- convenience, -- searchability, editability, etc.. The obvious, simple -- suggestions have -- all failed on one criterion or another, and ASCII has -- continued to be -- the best (if flawed) compromise. -- -- For many years, PS and PDF files have been allowed as -- secondary formats -- for RFCs. (You can find them by searching rfc-index.txt for the -- strings 'PS=' and 'PDF=', respectively). This provision does not -- handle things like state diagrams, which are presumably -- normative. In -- practice, creating the PS/PDF forms has been a major pain, -- because the -- documentswere created by the authors using a wide variety of -- different editors and tools. -- -- On the other hand, it does appear that the availability of ASCII -- support as a common denominator is decreasing over time. -- As has been -- observed, some software vendors seem to go out of their way to make -- simple ASCII hard to use. So there is increasing pressure to find -- a (truly) better solution. -- -- Bob Braden -- -- ___ -- Ietf mailing list -- Ietf@ietf.org -- https://www1.ietf.org/mailman/listinfo/ietf -- ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: objection to proposed change to consensus
Title: RE: objection to proposed change to "consensus" Yaakov, Here's the text that says "all that"... "It is much more likely to hear from the veryvocal people who are opposed to the change. That is, assuming 1000s of participants on the IETF discussion list, perhaps 20 expressed 'nays', even strong nays, could be considered a clear consensus in favor of change." The clear implication here is that we could choose to regard the 20 expressed 'nays', evenstrong nays, as atypical among the silent majority - if that assumption suits our purpose. Or, we could assume the reverse... The current process requires weighing of voices, not weighing of the supposed opinions of the silent. -- Eric From: Yaakov Stein [mailto:[EMAIL PROTECTED] Sent: Wednesday, January 04, 2006 11:25 PMTo: Gray, Eric; Brian E CarpenterCc: ietf@ietf.orgSubject: RE: objection to proposed change to "consensus" However, the text objected to in this case argues thatthis process should be extended by a process of counting thepeople who don't publicly participate in the discussion, eitherway, as having tacitly given their approval to whatever side ofthe argument the authors, the WG chairs or the IESG choose.Wow, did we say all that? All we are saying is that for the issue we are discussing there is no WG. The only list that is open to its discussion is the general list, where there is no support. However, quite a large number of people who actively participate inIETF WGs (people who are interested in working on technical topics, but not on the internal workings of the IETF) who want the process changed. We proposed gauging interest by a show of hands at a plenary meeting, rather than by the number of yes votes on this list. Yes, even that is not optimal since there are people who prefer working in the terminal room or touring in the evenings, but it certainly seems to be a better way of finding out what MOST IETF participants want than only reading this list. I fail to see how this is equivalent to allowing authors or chairs to decide for themselves what should be done. Y(J)S ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: Engineering our way out of a brown paper bag [Re: Consensus b ased on reading tea leaves]
Brian, I think it is somewhat unfair to say that we have not tried the steps you outline below. Where we run into trouble is when different sets of people disagree as to which of the steps we are currently working on. Quite frankly, I believe we can address the second step (which of the requirements are not met today?) with a firm none. This is - IMO - the basis for the apparent stodgy resistance to change. -- Eric -- -Original Message- -- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] -- On Behalf Of Brian E Carpenter -- Sent: Thursday, January 05, 2006 7:36 AM -- To: Harald Tveit Alvestrand -- Cc: ietf@ietf.org -- Subject: Engineering our way out of a brown paper bag [Re: -- Consensus based on reading tea leaves] -- -- Harald Tveit Alvestrand wrote: -- -- -- --On mandag, januar 02, 2006 18:10:15 +0200 Yaakov Stein -- [EMAIL PROTECTED] wrote: -- -- The only thing I am sure about is -- that -- consensus on this list is for keeping everything exactly -- as it is. -- -- -- I'm pretty sure there's no such consensus. -- -- I do, however, see a rather strong -- consensus-of-the-speakers against -- using MS-Word document format for anything official. -- -- I think we need to tackle this whole issue, if we do decide to -- tackle it, in a much more systematic way. -- -- - what are our functional requirements? -- - which of them are not met today? -- - what are the possible solutions, and what is their practical --and operational cost? -- - which, if any, solutions should we adopt, on what timescale? -- -- I believe that if we took a systematic approach like that, the issue -- of how we determine consensus would be broken into enough small -- steps that it really wouldn't be an issue. -- -- Brian -- -- -- ___ -- Ietf mailing list -- Ietf@ietf.org -- https://www1.ietf.org/mailman/listinfo/ietf -- ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: Baby Steps (was RE: Alternative formats for IDs)
Jerry, And this is a déjà vu over and over again as well. We could - in theory - allow draft versions in any format an author chooses. It would make quite a mess of the draft repository and - eventually - the RFC library. But we need to agree on one or more versions that can be (more or less) viewed by anyone, if we expect that everyone will actually read and use them. I believe the current practice allows for multiple formats, but requires that at least one is in ASCII text. And, in cases where the document is expected to be of an authoritative nature, the authoritative version is the one in the common (ASCII text) format. If that were acceptable to everyone, we could stop there, rather than taking the next baby step off the top stair. :-) However, there are a number of people who feel that complex figures are required to understand authoritative text in at least some cases - and this is a good argument for making a version that contains these complex figures authoritative. At this point, all agreement breaks down. The only way to go forward (assuming that change is part of the definition of going forward) is through arbitration. I am certain that (déjà vu, yet again) arbitration has been tried again and again... -- Eric -- -Original Message- -- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] -- On Behalf Of Ash, Gerald R (Jerry) -- Sent: Thursday, January 05, 2006 9:26 AM -- To: Yaakov Stein; ietf@ietf.org -- Cc: Ash, Gerald R (Jerry) -- Subject: Baby Steps (was RE: Alternative formats for IDs) -- -- Happy New Year to all! -- -- Many thanks to Yaakov for his excellent handling of the -- list discussion. I'm not very surprised with the way it -- has gone. Déjà vu all over again :-) -- -- The challenge is to focus the discussion to try to reach -- consensus on moving forward with a process change, i.e., we -- need to take baby steps to make progress. -- -- I'd suggest we try to reach consensus first on the following: -- Alternative format(s) for IDs, in addition to ASCII text, -- should be allowed. -- -- One requirement/motivation for this change (as set forth in -- the ID) is to be able to include drawings and diagrams with -- something much more flexible than ASCII art. -- -- Based on the prior discussion of 'ASCII art', and the -- current discussion, I see few people arguing that ASCII -- text is all we need and that no other formats should ever -- be allowed. -- -- Let's set aside for now which format(s), and take that as a -- later step if we can take this first step. -- -- Thanks, -- Regards, -- Jerry -- -- -- -- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] -- On Behalf Of Yaakov Stein -- Sent: Sunday, January 01, 2006 12:37 AM -- To: ietf@ietf.org -- Subject: Alternative formats for IDs -- -- Happy new year to everyone. -- -- I would like to call your attention to a new ID -- http://www.ietf.org/internet-drafts/draft-ash-alt-formats-00.txt. -- -- This ID is the result of discussions here on the general list, -- and proposes the use of formats other than plain ASCII -- for IDs and RFCs. In particular, it proposes the allowance -- of diagrams other than ASCII-art as normative. -- -- The authors felt that further discussion on the list would -- not be productive, -- but that the writing of an ID might force more serious -- consideration. -- We furthermore suggest that this ID be advanced as a BCP -- under the process for process change. -- -- Y(J)S -- -- ___ -- Ietf mailing list -- Ietf@ietf.org -- https://www1.ietf.org/mailman/listinfo/ietf -- ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: Baby Steps (was RE: Alternative formats for IDs)
John, I believe - for the record - that Post-Script is also allowed. -- Eric -- -Original Message- -- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] -- On Behalf Of John C Klensin -- Sent: Thursday, January 05, 2006 11:28 AM -- To: Ash, Gerald R \(Jerry\); Yaakov Stein; ietf@ietf.org -- Subject: Re: Baby Steps (was RE: Alternative formats for IDs) -- -- -- -- --On Thursday, 05 January, 2006 08:25 -0600 Ash, Gerald R -- \\(Jerry\\) [EMAIL PROTECTED] wrote: -- -- Happy New Year to all! -- -- Many thanks to Yaakov for his excellent handling of the list -- discussion. I'm not very surprised with the way it has gone. -- Déjà vu all over again :-) -- -- The challenge is to focus the discussion to try to reach -- consensus on moving forward with a process change, i.e., we -- need to take baby steps to make progress. -- -- I'd suggest we try to reach consensus first on the following: -- Alternative format(s) for IDs, in addition to ASCII text, -- should be allowed. -- -- One requirement/motivation for this change (as set forth in -- the ID) is to be able to include drawings and diagrams with -- something much more flexible than ASCII art. -- -- Based on the prior discussion of 'ASCII art', and the current -- discussion, I see few people arguing that ASCII text is all we -- need and that no other formats should ever be allowed. -- -- Even those of us who are strongly supportive of ASCII as our -- primary base format and those who believe that the effort needed -- to simplify illustrations and diagrams sufficiently that they -- can be accurately represented in ASCII artwork is helpful in -- forcing clarity are reluctant to say never. -- -- Let's set aside for now which format(s), and take that as a -- later step if we can take this first step. -- -- Jerry, one of the nice things about baby steps is that you -- sometimes discover that the baby learned to take the steps -- without any instruction. -- -- Unless the IESG has changed the rules while I was not looking, -- it has been permitted to post I-Ds in PDF in addition to ASCII -- for some years. I find it interesting that it has not been taken -- advantage of more often (and, for the record, I'm one of those -- who has taken advantage of it). When it has been done for -- artwork purposes, the artwork in the ASCII version has sometimes -- been pretty rudimentary. In practice, whether it is good -- enough has been made on a case by case basis by WG Chairs and -- WGs or, for non-WG documents, by whether or not the relevant -- people are willing to read and consider those documents. -- Similarly, when PDF has been posted in order to exhibit -- non-ASCII characters, it has proven helpful to have Unicode -- character offsets (i.e., U+ representations) in both the -- ASCII and PDF forms to ensure complete precision even though the -- character-glyphs themselves appear only in the PDF form. -- -- So, consider the first baby step to have been taken: nothing -- prevents you from posting an I-D in both ASCII and PDF today, -- and the relevant sub-community will sort out, on a case by case -- basis, whether the ASCII is good enough. If you do more of it, -- perhaps we can move some of the interoperability problems into -- the realm of actual IETF experience and out of the realm of -- extrapolation from other situations mixed with pure speculation. -- -- Free advice: if and when you want to move beyond that point, -- drop (or isolate into separate documents): -- -- (1) Recommendations for IETF process change or specific -- ways to determine consensus. They should be separate so -- they can be considered separately, using an appropriate -- process. -- -- (2) Distinguish clearly between what is required or -- tolerable for I-Ds and what is required or tolerable for -- RFCs. RFCs, in general, put a less strong requirement -- on easy extraction and modification of text than I-Ds. -- And, since I-Ds in theory expire after six months, you -- might be able to convince the community that the be -- sure it can be read twenty years later requirement for -- archival documents should not be taken as seriously for -- I-Ds. -- -- (3) Recommendations to permit any format that is (i) -- proprietary, or (ii) dependent on particular software -- for processing where that software carries either high -- costs, onerous licensing requirements, or licensing -- requirement that attempt to prohibit the development of -- independent tools to work with the format, or (iii) -- significantly operating-system dependent, or (iv) -- significantly version-dependent in the sense that the -- documents are not forward and backward compatible. -- -- I would suggest to you that the fact that Word hits a jackpot by -- satisfying all of the negative criteria in that third suggestion -- is the reason why it has been regularly rejected for IETF
RE: Baby Steps (was RE: Alternative formats for IDs)
Stewart, You bring up a good point. I have been assuming that - since IDs can be submitted in multiple formats - that the additional formats would also become part of the RFC library on publication. I just took a quick peek at the RFCs and there does not appear to be a single example of a version that is not in text format. I don't know if that is because they are not stored in the same place, or they are not carried forward as part of the publishing process. Frankly, if the process of getting an ID published as an RFC seems to require (or at least encourage) use of at least one additional format, then the additional format(s) should also be incorporated in the RFC library. In other words, if there was a non-ASCII version of the ID, there should also be a non-ASCII version of the RFC. For some reason I thought this at least used to be the case. If it is not, then that should be fixed - for exactly the reasons you point out. Irrespective of questions about the legitimacy of using a non-ASCII version as normative or authoritative, the fact that a non-ASCII version might contain useful explanatory material is more than sufficient cause to keep it. -- Eric From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Stewart Bryant Sent: Thursday, January 05, 2006 12:01 PM To: John C Klensin Cc: Ash, Gerald R \(Jerry\); ietf@ietf.org Subject: Re: Baby Steps (was RE: Alternative formats for IDs) John C Klensin wrote: --On Thursday, 05 January, 2006 08:25 -0600 Ash, Gerald R \\(Jerry\\) [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: Happy New Year to all! Many thanks to Yaakov for his excellent handling of the list discussion. I'm not very surprised with the way it has gone. Déjà vu all over again :-) The challenge is to focus the discussion to try to reach consensus on moving forward with a process change, i.e., we need to take baby steps to make progress. I'd suggest we try to reach consensus first on the following: Alternative format(s) for IDs, in addition to ASCII text, should be allowed. One requirement/motivation for this change (as set forth in the ID) is to be able to include drawings and diagrams with something much more flexible than ASCII art. Based on the prior discussion of 'ASCII art', and the current discussion, I see few people arguing that ASCII text is all we need and that no other formats should ever be allowed. Even those of us who are strongly supportive of ASCII as our primary base format and those who believe that the effort needed to simplify illustrations and diagrams sufficiently that they can be accurately represented in ASCII artwork is helpful in forcing clarity are reluctant to say never. Let's set aside for now which format(s), and take that as a later step if we can take this first step. Jerry, one of the nice things about baby steps is that you sometimes discover that the baby learned to take the steps without any instruction. Unless the IESG has changed the rules while I was not looking, it has been permitted to post I-Ds in PDF in addition to ASCII for some years. BUT the pdf is not allowed to be normative. Changing that rule alone would be sufficient to allow modern graphics to be called up in normative texts. I find it interesting that it has not been taken advantage of more often (and, for the record, I'm one of those who has taken advantage of it). When it has been done for artwork purposes, the artwork in the ASCII version has sometimes been pretty rudimentary. In practice, whether it is good enough has been made on a case by case basis by WG Chairs and WGs or, for non-WG documents, by whether or not the relevant people are willing to read and consider those documents. Please
RE: objection to proposed change to consensus
Sandy, What you say is correct, as far as it goes. However, the implication in the wording is that people disagreeing with a proposal will post and people disagreeing with them will not. This is the case - as you suggest - when there is a clear default outcome. In fact, contrary to what we observe in nature, change is not the default outcome in most human organizations. That is because - as a careful analysis of this discussion over the years will disclose - there are as many ways to go with a change as there are people prepared to make changes. Consequently, it is at least as valid to assume that - particularly when a proposal represents a departure from status quo - that people may not be responding because they agree with the _objections_ already made and _also_ do not want to add to the general hub-bub. Consequently, if we see 10-20 people posting in favor of a _specific_ proposal and similar numbers posting against that same _specific_ proposal, then it is out of line for us to assume that any particular opinion is indicated by silence. Note that it is _very_ important to distinguish support for a particular change from support for the idea that some change is required. For example, if you have well over 100 people who all agree that change is required, and only 20 who argue that no change is required, you have to evaluate the agreement for a specific change (or at least a specific change direction) rather than a general discontent with status quo. If no more than 5 or 10 people agree to a specific proposal, then the net effect is a consensus for the status quo (better the devil you know). As one of the people arguing for status quo, I can tell you that it is not that I am happy with it. It is because I do not see a reasonably well supported alternative to status quo being proposed. In fact, a big part of the discussion right now stems from the fact that a lot of people have not really understood exactly what the status quo is. People who believe that they cannot submit an ID containing complex graphics in some form other than text, clearly do not realize that this is not the case. I like the quote about coffee, by the way... -- Eric -- -Original Message- -- From: Sandy Wills [mailto:[EMAIL PROTECTED] -- Sent: Thursday, January 05, 2006 12:48 PM -- To: Gray, Eric -- Cc: 'Yaakov Stein'; ietf@ietf.org -- Subject: Re: objection to proposed change to consensus -- -- Gray, Eric wrote: -- -- It is much more likely to hear from the very vocal -- people who are -- opposed to the change. That is, assuming 1000s of participants -- on the IETF discussion list, perhaps 20 expressed 'nays', even -- strong nays, could be considered a clear consensus in favor of -- change. -- -- While I can't speak for everyone else, this seems correct -- to me. Do I -- have anything useful or enteresting to add? and Do I -- think that my -- input will change the output? must both evaluate to Yes -- before I post -- to any discussion. I occasionally post for humor or interest, but -- generally I follow the discussion and stay out of it unless -- I believe it -- to be going badly awry. -- --To be blunt, do we want every question to be answered by several -- thousand AOL Me too's? The silent masses are silent because they -- don't have anything useful to add, and believe that an -- endless stream of -- agreements would do nothing useful except test our bandwidth. -- --We do, on the other hand, chime in when necessary. So, -- it is good -- and right and fair to assume that a public question -- with a default -- answer has concensus, if the only response is a minor -- negative one. I, -- and I believe many others, will simply move on to the next -- post when we -- see the question, if we agree with the default answer. -- --A simple mental experiment: If we have, say, 2000 -- readers, and we -- post the question -- --Will the sun rise tomorrow? We think yes. -- -- then we can expect a small number of disagreements, a -- small number of -- arguments from readers who didn't understand the question, a small -- number of AOL's, a small number of Of course, you twit! -- Why are you -- wasting our time with this? and nothing else. The vast -- majority of the -- readers will not reply, because they agree with the default -- answer, and -- they have other things to do. --If there is a reader who disagrees in his mind, but is -- constrained by -- cultural conditioning or natural manners from speaking out, -- how are we -- supposed to coax his better way from this reader? We -- have already -- posited that he/she/it won't speak up. --I submit that the IETF culture should, by policy, assume -- that anyone -- subscribed to an IETF list will speak out on any question -- if he/she/it -- thinks it right. -- -- The current process requires weighing
RE: Engineering our way out of a brown paper bag [Re: Consensus b ased on reading tea leaves]
Stewart, Of course it is. I think virtually everyone would like to live in a perfect world and most of us recognize that this is not it. Therefore, it is clear that - whatever we might say in any particular argument - we all want things to get better. Consequently, proposals to change what is will always be a recurring event. The question we really have to ask - as dissected by Brian in some detail - is whether or not a specific proposal is enough better than what we have already (assuming that what we have already is both under- stood and used appropriately) to overcome the steady-state friction typically used to prevent change for the sake of marginal gain with an unquantifiable risk for unanticipated side effects. -- Eric From: Stewart Bryant [mailto:[EMAIL PROTECTED] Sent: Thursday, January 05, 2006 1:22 PM To: Eliot Lear Cc: Gray, Eric; Harald Tveit Alvestrand; ietf@ietf.org Subject: Re: Engineering our way out of a brown paper bag [Re: Consensus b ased on reading tea leaves] Eliot Lear wrote: I agree. As usual we seem to be stuck in an infinite loop on this mailing list with the cycle being somewhere between 6 months and 3 years. The fact that we keep coming back to this topic may be a message in itself! - Stewart Eliot Gray, Eric wrote: Brian, I think it is somewhat unfair to say that we have not tried the steps you outline below. Where we run into trouble is when different sets of people disagree as to which of the steps we are currently working on. Quite frankly, I believe we can address the second step (which of the requirements are not met today?) with a firm none. This is - IMO - the basis for the apparent stodgy resistance to change. -- Eric -- -Original Message- -- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] -- On Behalf Of Brian E Carpenter -- Sent: Thursday, January 05, 2006 7:36 AM -- To: Harald Tveit Alvestrand -- Cc: ietf@ietf.org -- Subject: Engineering our way out of a brown paper bag [Re: -- Consensus based on reading tea leaves] -- -- Harald Tveit Alvestrand wrote: -- -- -- --On mandag, januar 02, 2006 18:10:15 +0200 Yaakov Stein -- [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: -- -- The only thing I am sure about is -- that -- consensus on this list is for keeping everything exactly -- as it is. -- -- -- I'm pretty sure there's no such consensus. -- -- I do, however, see a rather strong -- consensus-of-the-speakers against -- using MS-Word document format for anything official. -- -- I think we need to tackle this whole issue, if we do decide to -- tackle it, in a much more systematic way. -- -- - what are our functional requirements? -- - which of them are not met today? -- - what are the possible solutions, and what is their practical --and operational cost? -- - which, if any, solutions should we adopt, on what timescale? -- -- I believe that if we took a systematic approach like that, the issue -- of how we determine consensus would be broken into enough small -- steps that it really wouldn't be an issue. -- -- Brian -- -- -- ___ -- Ietf mailing list
RE: Engineering our way out of a brown paper bag [Re: Consensus b ased on reading tea leaves]
Stewart, I didn't want to go through all the RFCs to find a specific example, but I distinctly recall seeing an RFC at one point that had figures which contained only the text see associated PS version. However, I know I can't expect anyone to take my word for it. However, there was an easy way to get around that. I simply ftp'd all 48 of the RFCs that are available in PS format. I am still somewhat at a loss to understand why there are none in PDF, but the observation that other formats may be used obviously still stands. The very first RFC available in PS was RFC 1119. Surprisingly enough, the entire contents of the ASCII version is as follows: 'RFC-1119 Network Time Protocol (Version 2) Specification and Implementation is available only in PostScript form in the file RFC1119.PS' So, what exactly are we arguing about? :-) -- Eric -- -Original Message- -- From: Stewart Bryant [mailto:[EMAIL PROTECTED] -- Sent: Thursday, January 05, 2006 1:19 PM -- To: Gray, Eric -- Cc: 'Brian E Carpenter'; Harald Tveit Alvestrand; ietf@ietf.org -- Subject: Re: Engineering our way out of a brown paper bag -- [Re: Consensus b ased on reading tea leaves] -- -- Gray, Eric wrote: -- -- Brian, -- --I think it is somewhat unfair to say that we have -- not tried the steps you outline below. Where we run into -- trouble is when different sets of people disagree as to -- which of the steps we are currently working on. -- --Quite frankly, I believe we can address the second -- step (which of the requirements are not met today?) with -- a firm none. -- -- -- -- That is not true, we don't address the need to include diagrams. -- -- - Stewart. -- --This is - IMO - the basis for the apparent stodgy -- resistance to change. -- -- -- -- Eric -- -- -- -Original Message- -- -- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] -- -- On Behalf Of Brian E Carpenter -- -- Sent: Thursday, January 05, 2006 7:36 AM -- -- To: Harald Tveit Alvestrand -- -- Cc: ietf@ietf.org -- -- Subject: Engineering our way out of a brown paper bag [Re: -- -- Consensus based on reading tea leaves] -- -- -- -- Harald Tveit Alvestrand wrote: -- -- -- -- -- -- --On mandag, januar 02, 2006 18:10:15 +0200 Yaakov Stein -- -- [EMAIL PROTECTED] wrote: -- -- -- -- The only thing I am sure about is -- -- that -- -- consensus on this list is for keeping everything exactly -- -- as it is. -- -- -- -- -- -- I'm pretty sure there's no such consensus. -- -- -- -- I do, however, see a rather strong -- -- consensus-of-the-speakers against -- -- using MS-Word document format for anything official. -- -- -- -- I think we need to tackle this whole issue, if we do decide to -- -- tackle it, in a much more systematic way. -- -- -- -- - what are our functional requirements? -- -- - which of them are not met today? -- -- - what are the possible solutions, and what is their practical -- --and operational cost? -- -- - which, if any, solutions should we adopt, on what timescale? -- -- -- -- I believe that if we took a systematic approach like -- that, the issue -- -- of how we determine consensus would be broken into enough small -- -- steps that it really wouldn't be an issue. -- -- -- -- Brian -- -- -- -- -- -- ___ -- -- Ietf mailing list -- -- Ietf@ietf.org -- -- https://www1.ietf.org/mailman/listinfo/ietf -- -- -- -- ___ -- Ietf mailing list -- Ietf@ietf.org -- https://www1.ietf.org/mailman/listinfo/ietf -- -- -- -- -- ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: objection to proposed change to consensus
Sandy, My point - as may be clearer in other posts - is that the first question do we want change is a no-op at best. Change is natural and inevitable whether we want it or not. The first useful question is - paraphrasing what Brian said - what do we need that we do not already have? All of us have needs that are not satisfied by what we have - hence the inevitability of change. But it is not useful, nor realistic, for any of us to assume that everyone else is going to drop what they're doing to help us satisfy our individual needs. So the question becomes Is there a common subset of our collective individual needs that a large subset of affected people agree on, that cannot be satisfied by what we have now? IMO, that is the question we keep coming back to... -- Eric -- -Original Message- -- From: Sandy Wills [mailto:[EMAIL PROTECTED] -- Sent: Thursday, January 05, 2006 3:34 PM -- To: Gray, Eric -- Cc: ietf@ietf.org -- Subject: Re: objection to proposed change to consensus -- -- Gray, Eric wrote: -- -- Sandy, -- --In fact, contrary to what we observe in nature, change -- is not the default outcome in most human organizations. -- That is because - as a careful analysis of this discussion -- over the years will disclose - there are as many ways to go -- with a change as there are people prepared to make changes. -- -- I think that there is also a very strong element of emotional -- attachment to any system or solution, from those people who -- had a hand -- in creating it (Certainly, I'm just as guilty of this as -- the next guy!). -- Any job is harder if you have to change your tools every -- time you get -- used to them. -- It's also true that some people will object to anything -- in front of -- them, simply because it was done by someone else. -- We also have the religious responses, both pro and con, where -- someone either approves (or disapproves) of it simply -- because of the -- source. We've all seen It's gotta be good, Jon Postel -- wrote it, as -- well as I'll cut my wrists before I use MS software -- -- It appears that, if we want to judge solution-quality -- by mob volume, -- we need to find some way to separate the emotional -- responses from the -- reasoned responses. Unfortunately, I don't have one handy. -- --Note that it is _very_ important to distinguish support -- for a particular change from support for the idea that some -- change is required. For example, if you have well over 100 -- people who all agree that change is required, and only 20 who -- argue that no change is required, you have to evaluate the -- agreement for a specific change (or at least a specific change -- direction) rather than a general discontent with status quo. -- If no more than 5 or 10 people agree to a specific proposal, -- then the net effect is a consensus for the status quo (better -- the devil you know). -- --As one of the people arguing for status quo, I can tell -- you that it is not that I am happy with it. It is because I -- do not see a reasonably well supported alternative to status -- quo being proposed. -- -- ...And we are back to what has been said many times -- already. Do we -- want to change? Answer yes/no and What do we want to -- change to? are -- _not_ completely separable. You admit that you aren't -- happy about the -- status quo, but will still answer No to the first -- question because you -- don't trust us as a community to come up with a sane answer to the -- second question. -- -- The only quick and easy solution I see would be a -- multiple-choice -- question, perhaps on a web site, with options like: -- --A) The world is perfect. Change nothing. --B) I hate our system, but don't trust you bozos. Change nothing. --C) Change to cunieform-and-clay, for everything. --D) Change to marble for ID submission, and MS Word '95 for RFC -- publication. --etc, etc, etc. -- --I choose to _NOT_ volunteer to write and host this website. -- -- --I like the quote about coffee, by the way... -- -- Thanks! While it's not original with me, I certainly still -- remember the -- pain involved with the source Unable to locate COMMAND.COM -- - Processor -- halted -- -- -- -- Unable to locate coffee. -- Operator halted. -- ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: objection to proposed change to consensus
Brian, Yours is sort of a general reply to a question which has very specific relevance in this case. Yes, the current process allows for getting around a few nay-sayers. However, the text objected to in this case argues that this process should be extended by a process of counting the people who don't publicly participate in the discussion, either way, as having tacitly given their approval to whatever side of the argument the authors, the WG chairs or the IESG choose. If we suppose that this might be the ongoing model for determining consensus, it will never be necessary for anyone other than the authors, WG chairs and IESG to agree on some choice to declare consensus - even if the proposal is the most ghastly nonsense to ever see the light of day - since it will always be the case that the majority of people lurking on the mailing list will not actively participate in list discussion. The text argues for this extreme interpretation of the current process - where the proponents of an idea consist almost entirely of its authors, and they need only get the IESG behind it to make it happen. I've seen this done once before, where a WG chair and AD jointly declared consensus against a continuous stream of objections. It wasn't pretty then, and it wouldn't be pretty now. -- Eric -- -Original Message- -- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] -- On Behalf Of Brian E Carpenter -- Sent: Wednesday, January 04, 2006 11:02 AM -- To: Jeffrey Hutzelman -- Cc: ietf@ietf.org -- Subject: Re: objection to proposed change to consensus -- -- Jeffrey Hutzelman wrote: -- -- -- On Monday, January 02, 2006 09:56:15 PM -0800 Randy Presuhn -- [EMAIL PROTECTED] wrote: -- -- Hi - -- -- In -- http://www.ietf.org/internet-drafts/draft-ash-alt-formats-00.txt -- section 3 says: -- -- | Furthermore, the authors propose that the IESG -- carefully consider -- | declaring consensus in support of the change even if -- a large number -- | of 'nays' are posted to the IESG discussion list. -- -- I object to this text, as it might (mis)lead the reader -- into thinking -- that the methods for declaring consensus were being modified, -- particularly -- if this document somehow became a BCP. To deal with -- this issue, I -- suggest -- the removal of the following material from section 3: -- -- -- Agree. If the authors actually wish to propose a change -- to the way -- consensus is determined in the IETF, then they should do so in a -- separate document. Naturally, like any process change in any -- organization, such a change would have to be made under -- the _existing_ -- process before it could take effect. -- -- Speaking for myself, I agree. The whole point of rough -- consensus is to -- leave scope for some nay-sayers, but it's for the WG Chairs -- (if relevant) -- and the IESG to judge whether the number of objections is -- significant. -- That's not going to change any time soon, and certainly not -- as a side effect. -- -- Brian -- -- -- ___ -- Ietf mailing list -- Ietf@ietf.org -- https://www1.ietf.org/mailman/listinfo/ietf -- ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: Alternative formats for IDs
Ted, If that happens, don't you think that we would be obliged to object to their claims? IMO, such claims would be easily defeated on the same basis as most look feel claims have been beaten in the past. In fact, I am not aware of issues with any sort of rights assertion relative to existing converters for MS (or Adobe) document formats. -- Eric -- -Original Message- -- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] -- On Behalf Of Theodore Ts'o -- Sent: Wednesday, January 04, 2006 12:03 PM -- To: John C Klensin -- Cc: ietf@ietf.org -- Subject: Re: Alternative formats for IDs -- -- On Tue, Jan 03, 2006 at 02:59:34PM -0500, John C Klensin wrote: --(2) Development of a converter between the MS-XML output --of Word Pro 2003 and the XML input of RFC 2629bis so --that xml2rfc and its friends could take responsibility --for final formatting. Note that, if the converter were --two-way, you could edit happily in Word and others could --edit happily in XML and both could interwork. However, --as with the above, I think this solution would rapidly --deteriorate into uselessness unless there were a --commitment to produce new versions as new versions of --Office appeared -- at least until Microsoft stabilizes --and documents their XML formats. -- -- And even when Microsoft stablizes their XML formats, each person who -- wants to use the converter will have to apply individually to -- Microsoft for a patent license, for which Microsoft has apparently -- reserved the right to deny in the future for any reason. Sweet -- -- - Ted -- -- ___ -- Ietf mailing list -- Ietf@ietf.org -- https://www1.ietf.org/mailman/listinfo/ietf -- ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: Alternative formats for IDs
Yaakov, Yes, that would be most of what I meant by publicly available. Since we're trying to be very precise, I also include the notion of readily available documentation in the broader concept to publicly available where readily may be implied in your use of open - and essentially means that I can get a copy without signing another mortgage. -- Eric -- -Original Message- -- From: Yaakov Stein [mailto:[EMAIL PROTECTED] -- Sent: Wednesday, January 04, 2006 1:15 AM -- To: Gray, Eric -- Cc: ietf@ietf.org -- Subject: RE: Alternative formats for IDs -- -- -- -- Clarifying that publicly known means well defined and publicly -- available, I would answer no... -- -- and if it is restricted to mean -- open description so that you could write your own editor -- to read and -- write this format ? -- -- ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: Alternative formats for IDs
-- Lets go ahead and ask then - -- Does anyone else think that IETF should allow documents which -- format/structure is not publicly known as one of the ways to -- distribute IETF specifications? Clarifying that publicly known means well defined and publicly available, I would answer no... ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: Pro SPAM WG: How security could benefit from high volume spam
You'll need to work very hard to get the WG action items completed by April 1, 2006. -- -Original Message- -- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] -- On Behalf Of Peter Dambier -- Sent: Friday, December 16, 2005 5:32 AM -- To: JFC (Jefsey) Morfin -- Cc: ietf@ietf.org; Hadmut Danisch -- Subject: Pro SPAM WG: How security could benefit from high -- volume spam -- -- A WG? -- -- Karin and me are interested. -- -- JFC (Jefsey) Morfin wrote: -- At 23:10 14/12/2005, Hadmut Danisch wrote: -- -- On Wed, Dec 14, 2005 at 04:46:42PM +0100, Frank Ellermann wrote: -- -- The best way to hide a signal is noise, is that's your idea ? -- Makes sense from my POV. -- -- -- Not necessarily the _best_ way, but one that works under many -- circumstances. -- Some questions are: -- How do we deal with the total surveillance? -- Do anti-spam measures make surveillance easier? -- -- No, I dont want to bash the one and only root again, but never did I -- receive any SPAM an my [EMAIL PROTECTED] address. -- -- This too could improve our position. Which root does the -- guy use - or -- has he simply freaked his /etc/hosts? -- -- Hadmut, I agree with your idea and I switched my spam -- filter off from all -- my GMX mail accounts. They are worthless anyhow, because I -- permanently -- have to read the spam folder to find lost emails. I still -- have to fight -- sorbs, because they dont even accept my own emails from my host -- echnaton.serveftp.com wich has a dynamic ip. -- -- -- -- Hadmut, -- not much success with your suggestion! Too much European -- centric at the -- moment. Your proposition is of real interest as part of a -- picture to -- study the noise as a general protection (conflicting -- information, spam, -- revamping web sites 1000 times a day, meta-spam, tags, -- EUCD, civilrights -- protection, bandwidth cost, site legal registration, -- multiligualism, -- debate orientation, etc.). The French law related debate -- make it very -- interesting, and important, however too complex for -- current users at -- this time. This fits the interests I have in the -- emergence of an over -- the ISO layers Internet through a grassroots process. -- How to use the -- Internet? But the IAB discuss list leads to nothing. -- -- The French law made me move the sources from IASON -- -- http://iason.site.voila.fr/ -- http://www.kokoom.com/iason/ -- -- to sourceforge. I dont want to fight the music industry -- with a law I dont -- even understand. IASON has nothing to do with music but it -- has to do with -- copyright. -- -- -- Why not to try to shape a WG Charter on this? I do not -- believe the IESG -- is able to follow. But when I see all the ICANN, IETF, -- Unicode, etc. -- meetings, publications, etc. etc. about -- internationalization, partly -- to oppose my long enough opposition which permitted me to -- reach Tunis. -- One could expect that Brussels could be interested at the -- end of the -- day. And if the IESG does not follow, we will have made -- our duty, before -- going elsewhere? I do not think that the balkanization -- they impose on us -- is a good thing. -- -- jfc -- -- -- Karin and me helped building two balkan DNS roots. Why not -- do something -- serious now :) -- -- Cheers -- Peter and Karin -- -- -- -- -- Peter and Karin Dambier -- The Public-Root Consortium -- Graeffstrasse 14 -- D-64646 Heppenheim -- +49(6252)671-788 (Telekom) -- +49(179)108-3978 (O2 Genion) -- mail: [EMAIL PROTECTED] -- mail: [EMAIL PROTECTED] -- http://iason.site.voila.fr -- http://www.peter-dambier.de -- http://peter-dambier.site.voila.fr -- -- -- ___ -- Ietf mailing list -- Ietf@ietf.org -- https://www1.ietf.org/mailman/listinfo/ietf -- ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: The IETF Trust License is too restricted
Simon, As I understand it, the IETF has negotiated for nominal control of IPR vested in other organizations that was developed through IETF activities. Perhaps I misunderstand the purpose of the trust. However, if that is the situation, two things are easily apparent: 1) the IETF is not in a power-position to decide unilaterally what rights it will obtain in negotiation and 2) a favorable negotiation position should be cemented as quickly as possible. It is difficult for those of us that were not involved in the negotiations to determine whether or not the position now represented is the most favorable position obtainable, but it does seem likely. Personally, I am inclined to trust that the people negotiating for the IETF have been doing, and continue to do the right things. -- Eric -- -Original Message- -- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] -- On Behalf Of Simon Josefsson -- Sent: Tuesday, December 06, 2005 9:17 AM -- To: Brian E Carpenter -- Cc: IAOC; ietf@ietf.org -- Subject: Re: The IETF Trust License is too restricted -- -- Brian E Carpenter [EMAIL PROTECTED] writes: -- -- Simon Josefsson wrote: -- Hallam-Baker, Phillip [EMAIL PROTECTED] writes: -- -- -- -- From: Brian E Carpenter [mailto:[EMAIL PROTECTED] -- -- Its purpose is to give the IETF control of its own -- IPR, which has -- previously been held by 3rd parties. (That's not the legal -- statement of purpose in the formal Trust Agreement.) -- -- What we then do once we have such control is then -- something we can -- discuss and reach consensus on. Part of that -- discussion is already -- happening in the IPR WG. -- -- That is an interesting approach. -- -- The reason I raised the point was that I suspect that -- there will be many -- members of the IETF community who would prefer to have -- the debate on use -- before they have surrendered control. -- I agree. -- -- As I already pointed out, the rights we will get when the Trust -- is signed into existence are only the rights that the Settlors -- currently have; they will be moving from two bodies over which -- the IETF has *no* control (CNRI and ISOC) to a body whose Trustees -- are appointed according to RFC 4071. -- -- That is true, but irrelevant to my point. -- -- The IETF Trust should be allowed to grant licenses to their IPR -- without requiring the licensee to grant back all rights to -- derivative -- works. The IETF Trust doesn't have to use that ability. For most -- licenses, requiring the licensee to contribute back all rights to -- derivative works would be useful. -- -- It seems this process is being rushed through before all -- issues are -- settled or even discussed. -- -- I imagine we'll be discussing IPR issues for the next twenty years -- at least. What we are doing *now* is moving some of the IPR into -- the IETF's control. -- -- No, some of the IPR that is moved into the IETF Trust will, -- under the -- updated IETF Trust license, not be under IETF's control. -- For example, -- the IETF cannot grant a third party the right to use IETF -- IPR without -- giving up all rights to derivative works. I know RFC/I-D's are -- excepted now, but there are other material which the IETF may decide -- to grant third parties rights to. -- -- I'd feel more comfortable if the outbounds right issue -- was settled, -- before all IPR is signed away to some external body -- that, to me, it -- seem unclear whether the IETF has total control over. -- -- That is completely wrong. We are moving *some* IPR, not -- all, from bodies -- where the IETF has no control to a body that exists only -- for the benefit -- of the IETF. -- -- Right. And the license in which the IETF Trust should permit all -- things the IETF may decide to do. Otherwise we lose the -- control over -- the IPR. -- -- The license text that went out for final review was clearly -- insufficient, and would have made it impossible for the -- IETF community -- to fix things later on. The IETF would not have been in -- control of -- the IPR if that license would have passed. -- -- That isn't a license, it is a Trust Agreement that sets boundary -- conditions. -- -- That's hair splitting. The boundary conditions imply what -- flexibility -- the license can have. If the boundary conditions are too -- narrow, all -- licenses are not possible. That restrict the IETF's ability chose -- some licenses. -- -- The community objected to one of the boundary conditions, and we -- fixed it. That was the purpose of the community review. -- -- Right. -- -- I stress this: All past IETF IPR would appear to have -- been lost and -- out of control for the IETF community if the initial -- legal document -- had passed. -- -- Absolutely not. That is completely untrue. There was an -- unintended side -- effect on derivative works, and we fixed it. If we hadn't -- been able to -- fix it in the Trust
RE: Examples of translated RFCs
See below... -- -Original Message- -- From: Gray, Eric -- Sent: Tuesday, December 06, 2005 11:04 AM -- To: 'Nelson, David' -- Cc: ietf@ietf.org -- Subject: RE: Examples of translated RFCs -- -- David, -- -- Never-the-less, it can happen. Normative references - -- at least by some definitions of the term - can be to types -- of documents than RFCs. -- s/documents than/documents other than/ -- However, it is usually the case that papers and other -- documents written in French, Russian, German, etc. are made -- available in - or can be made available in - English for -- use in references from documents written in English. -- -- This is - indeed - the reason why the IETF allows for -- translations of RFCs: so that they can, in turn, be used as -- references in documents written in other languages. -- -- -- -- Eric -- -- -- -Original Message- -- -- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] -- -- On Behalf Of Nelson, David -- -- Sent: Tuesday, December 06, 2005 10:55 AM -- -- To: ietf@ietf.org -- -- Subject: RE: Examples of translated RFCs -- -- -- -- JFC (Jefsey) Morfin writes... -- -- -- -- So , IMHO, the IETF urgency is today the other way around: -- -- incorporating into RFC standards, practices or tables -- -- authoritatively -- -- written or thought in another language than English, -- or in English -- -- using normative non-ASCII art drafts or using term in -- a meaning -- -- foreign to the IETF. -- -- -- -- If all RFCs are written in English, basically so that there -- -- is at most -- -- one additional language in which one must be fluent to -- -- understand and -- -- implement the protocols described therein, wouldn't it -- defeat the -- -- purpose to have normative references written in other languages? -- -- -- -- -- -- ___ -- -- Ietf mailing list -- -- Ietf@ietf.org -- -- https://www1.ietf.org/mailman/listinfo/ietf -- -- -- ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: Examples of translated RFCs
David, Never-the-less, it can happen. Normative references - at least by some definitions of the term - can be to types of documents than RFCs. However, it is usually the case that papers and other documents written in French, Russian, German, etc. are made available in - or can be made available in - English for use in references from documents written in English. This is - indeed - the reason why the IETF allows for translations of RFCs: so that they can, in turn, be used as references in documents written in other languages. -- Eric -- -Original Message- -- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] -- On Behalf Of Nelson, David -- Sent: Tuesday, December 06, 2005 10:55 AM -- To: ietf@ietf.org -- Subject: RE: Examples of translated RFCs -- -- JFC (Jefsey) Morfin writes... -- -- So , IMHO, the IETF urgency is today the other way around: -- incorporating into RFC standards, practices or tables -- authoritatively -- written or thought in another language than English, or in English -- using normative non-ASCII art drafts or using term in a meaning -- foreign to the IETF. -- -- If all RFCs are written in English, basically so that there -- is at most -- one additional language in which one must be fluent to -- understand and -- implement the protocols described therein, wouldn't it defeat the -- purpose to have normative references written in other languages? -- -- -- ___ -- Ietf mailing list -- Ietf@ietf.org -- https://www1.ietf.org/mailman/listinfo/ietf -- ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: I-D file formats and internationalization
Ted, -- -- The IETF does not make any effort to be representative of the Internet -- community. -- -- 1) They do too. -- -- Hmmm. I would have thought proof by assertion would be more fun. -- -- Seriously, you can argue that the IETF is failing to reach the -- stakeholders it claims to represent, but I think it's disingenuous to say -- that the group doesn't try to reach them. There are low barriers to -- entry for interested parties, and concentrated efforts to find and -- coordinate with other networking standards bodies. Those aren't the -- actions of a group of ostriches. It is true that the barriers to entry are low. But, then, ostriches were not born with their heads in the sand. How is the IETF process of driving new people away because they say stuff nobody wants to hear, different from burying its head in the sand? -- -Original Message- -- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] -- On Behalf Of Ted Faber -- Sent: Friday, December 02, 2005 11:25 PM -- To: Hallam-Baker, Phillip -- Cc: ietf@ietf.org -- Subject: Re: I-D file formats and internationalization -- -- ___ -- Ietf mailing list -- Ietf@ietf.org -- https://www1.ietf.org/mailman/listinfo/ietf -- ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: I-D file formats and internationalization
Robert, See below... -- -Original Message- -- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] -- On Behalf Of Robert Sayre -- Sent: Thursday, December 01, 2005 5:38 PM -- To: Hallam-Baker, Phillip -- Cc: [EMAIL PROTECTED]; Keith Moore; Tim Bray; ietf@ietf.org -- Subject: Re: I-D file formats and internationalization -- -- On 12/1/05, Hallam-Baker, Phillip [EMAIL PROTECTED] wrote: -- -- On a point of information, most of the references I see -- in existing RFCs are to sections in any case. -- -- I suspect this is because almost everyone refers to an HTML -- version in informal communication. Actually, at least for my own part, the reason is simply that I am creating the text without any awareness of page numbers. Whether you use nroff or XML, the document is not broken into pages until you process it. Consequently, for ar least some people, the only reasonable references are to section numbers - and even that gets messy if you need to re-organize text. -- But, I actually agree with Keith that keeping the format as -- a text file is the right thing to do. I agree with Tim about -- internationalization and printing reality, but think UTF-8 -- text files would be the best route. -- -- I don't like the idea of using HTML, because it breaks up -- the document and allows bitmap illustrations. I think Keith -- is spot-on when he says the text format encourages clear -- thinking. Unfortunately, as many of us are aware, not everybody thinks - or even comprehends - the same way. For some people, text is explicitly problematic; however, most anybody is able to understand simple diagrams - at least, once they are explained. -- In the WG I frequent, I've found that the worst and most -- complicated ideas usually come with elaborate illustrations. Yes, but sometimes this is not causal in the way that you think it is. In some cases, an elaborate illustration is justified by the complicated ideas it helps to explain and not the other way around. -- -- Anyway, I'm still not clear on the what must-have software is -- preventing the IETF from using UTF-8. My linux systems allow me to -- write Thai and Katakana in vi. Guess it must be the printing. I -- haven't owned a printer since 1998, so I find it hard understand why -- some consider printing to be a frequent and important task. :-) -- -- -- -- -- Robert Sayre -- -- I would have written a shorter letter, but I did not have -- the time. I love this quote. Too bad it's not attributed. Did you make it up yourself? I'd like to use it sometime... -- -- ___ -- Ietf mailing list -- Ietf@ietf.org -- https://www1.ietf.org/mailman/listinfo/ietf -- ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: I-D file formats and internationalization
Phillip, Two things: 1) Robert was speculating as to the reason why people use chapter and verse rather than pages in their references, and 2) He said informal communication. There is something a bit informal about referring to an informal communication as authoritative. There is something equally casual about inferring that what people read is necessarily authoritative. Usage is that typically it is what people refer to when they have a question, that is considered authoritative. Otherwise, Executive Summaries would be considered to be authoritative and this would beg the questions - why bother including the rest? -- Eric -- -Original Message- -- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] -- On Behalf Of Hallam-Baker, Phillip -- Sent: Thursday, December 01, 2005 6:07 PM -- To: Robert Sayre -- Cc: [EMAIL PROTECTED]; Keith Moore; Tim Bray; ietf@ietf.org -- Subject: RE: I-D file formats and internationalization -- -- -- -- -Original Message- -- From: Robert Sayre [mailto:[EMAIL PROTECTED] -- Sent: Thursday, December 01, 2005 5:38 PM -- To: Hallam-Baker, Phillip -- Cc: Tim Bray; Keith Moore; [EMAIL PROTECTED]; ietf@ietf.org -- Subject: Re: I-D file formats and internationalization -- -- On 12/1/05, Hallam-Baker, Phillip [EMAIL PROTECTED] wrote: -- -- On a point of information, most of the references I see -- in existing -- RFCs are to sections in any case. -- -- I suspect this is because almost everyone refers to an HTML -- version in informal communication. -- -- Why do you consider the TXT version to be authoritative if -- as you admit -- the HTML version is the one that is read by reviewers and readers? -- -- Meaning is the result of usage. -- -- -- ___ -- Ietf mailing list -- Ietf@ietf.org -- https://www1.ietf.org/mailman/listinfo/ietf -- ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: EARLY submission deadline - Fact or Fiction?
Scott, Interesting thoughts. One thing I can see as being possibly a bit of a problem is that this approach - as opposed to the present one - would most likely impose a different sort of problem on a lot of people (the Secretariat, the host sponsor and the meeting Hotel - just to name a few). Making your - admittedly optimistic - assumption and following it to a conclusion leads me to suspect that many (possibly most) WG meetings would likely be subject to last-minute cancellation if all remaining issues are resolved immediately before the meetings. In many ways, this would be a good result. The possibility of being able to avoid the trip would add incentives to resolve issues before the meeting. People who can't make it to a meeting would miss less if even a few issues were resolved on the mailing list before the meetings. In other ways, however this would be not so good. Hotels that lost as many as 2,500 bookings on the Saturday or Sunday before the meeting would black-list the IETF making it very difficult to set up future meetings. The host sponsor(s) would not be able to guess how much equipment and resources would be required. The Secretariat will be in a walking nightmare simply trying to juggle room bookings to accommodate meeting cancellations and rescheduling. Attendees will most likely not know if and when meetings will be held. People will have made travel plans around meetings that may or may not happen. And so on. And don't for a minute think that Employers would fail to note that issues got resolved prior to a trip to Iceland but not before a similar meeting in Hawaii. I think things would eventually settle out. For example, the IETF currently has enough going on that statistical methods should find some applicability (how many will actually end up coming, how many rooms will be needed and for how long). But the transition would be _tough_. -- Eric -- -Original Message- -- From: Scott W Brim [mailto:[EMAIL PROTECTED] -- Sent: Wednesday, November 30, 2005 8:33 AM -- To: Joel M. Halpern; Gray, Eric -- Cc: ietf@ietf.org -- Subject: Re: EARLY submission deadline - Fact or Fiction? -- -- The reason we have the deadline is to protect the Secretariat from -- having to be heroes. However, best would be if the need for such -- protection didn't arise. -- -- Instead of assuming that things to be discussed in the meetings will -- be written just before the meeting, and creating complexity and -- bureaucracy around that assumption, institute a policy that nothing -- *will* be discussed in the meeting unless it has already been -- discussed on the mailing list and the WG has failed to -- reach agreement -- on the issue (note this is about issues, not documents). This will -- reduce the number of drafts which must get out just before -- the meeting -- to only those which capture the result of ongoing discussion. The -- others won't get discussed anyway. OK, I'm optimistic, but -- I see all -- this discussion of mechanisms to elaborate a situation we don't want -- to be in in the first place. -- -- swb -- ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: EARLY submission deadline - Fact or Fiction?
Scott, Hmmm. I thought your optimistic assumption was that people would try to resolve issues before the meetings. It may be that I misunderstood, or simply that I am not aware of much of what goes on in the background at meetings. At most meetings, the usual procedure is for people to talk about the information most listeners would know already if they read the draft and paid attention to the mailing list. Then the usual questions are: 1) do we accept the draft as a WG document or 2) is the draft ready for last call? After the WG (co-)chair(s) tally hands, or hum-levels, the question then goes to the mailing list. This is the procedure for about 5 out of 6 presentations, almost all the time. These questions rarely (if ever) get asked before the meeting and - in many cases - the information people have after the meeting is not any different than they had before the meeting. Since the majority of not particularly contentious stuff gets resolved this way, I would suspect that merely asking the question before the meeting - rather than after the meeting - might eliminate much of the work that currently takes up time during each WG meeting. Of course this is based on optimistic assumptions like people read the drafts before the meeting and people would aggressively try to resolve at least the easily resolved issues. At a minimum, this would result in a lot of half-hour or one hour meetings instead of one and two hour meetings. But in other cases (where - for example - the only thing discussed during the meeting is document status) - there would be little point in having the meeting if the inforamtion was simply put out on the mailing list before the meeting and there were no questions about it. I believe that making less optimistic assumptions would mean no change in any respect. I tend to believe this, more pessimistic, view is more likely. -- Eric -- -Original Message- -- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] -- On Behalf Of 'Scott W Brim' -- Sent: Wednesday, November 30, 2005 10:36 AM -- To: ietf@ietf.org -- Subject: Re: EARLY submission deadline - Fact or Fiction? -- -- On Wed, Nov 30, 2005 10:07:27AM -0500, Gray, Eric allegedly wrote: --Making your - admittedly optimistic - assumption and following -- it to a conclusion leads me to suspect that many -- (possibly most) WG -- meetings would likely be subject to last-minute -- cancellation if all -- remaining issues are resolved immediately before the meetings. -- -- You're even more optimistic than I am. Essentially every WG has -- problems that are not resolved by e-mail (and are rarely -- resolved even -- in person). I wouldn't expect any change in who meets, just in the -- meeting logistics. Those that are free of these problems need never -- meet in person. -- --And don't for a minute think that Employers would fail to note -- that issues got resolved prior to a trip to Iceland but -- not before a -- similar meeting in Hawaii. -- -- :-). There you go, another criterion for venue selection. Out of curiosity, are you suggesting that meetings should be scheduled in inhospitable climates so that the incentive for resolving issues is higher, or are you suggesting the obverse? -- -- swb -- -- ___ -- Ietf mailing list -- Ietf@ietf.org -- https://www1.ietf.org/mailman/listinfo/ietf -- ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: EARLY submission deadline - Fact or Fiction?
Dave, One of your comments seems to apply to the effectiveness of having an early submission deadline. What is the point of monkeying around with early submission deadlines when they are not very effective anyway? There seems to be two elements to your argument: that the rule does not seem to apply in every case and that exceptions seem to favor inappropriate submissions while enforcement tends to impede submission of legitimate late postings. I have to admit that I agree with the sentiment that they are not very effective - at least not always. Sometimes a WG chair schedules time to talk about an ID that doesn't exist at the time of the schedule announcement and - sometimes - still has not been submitted by the time of the meeting. Being used to somewhat firmer guidelines, that sort of thing catches me by surprise, unless - like some people - I have grown inured to this sort of exception within a specific WG. So, one question is whether or not it is appropriate to allow this practice to continue. That question needs to be answered - one way or the other - before we can really address your concern about playing around with submission deadlines. However, the bit about exceptions favoring innappropriate late submissions and enforcement impeding legitimate submissions depends on how we define appropriate and legitimate. IMHO, I think the common - usage-based - definition is that WG chairs get to arbitrate the meaning of these terms as it applies to ID submissions for their own WG, especially when submissions are late. If _we_ don't like the way that a specific WG chair does this, then we can individually complain about it and - if enough complaints are heard - something will most likely be done about it. If _we_ don't like the practice in general, then we can complain about it in this venue. But - as long as the usage definition is that it is up to the WG chair to define what is an appropriate or legitimate ID submissions - then (by that definition) whatever the chair allows to be discussed is both appropriate and legitimate. If we - as individuals - disagree, then it is up to us to say so during the highly traditional agenda bashing period at each WG meeting. On the other hand, if someone wants to reduce the WG chair's role in arbitrating the legitimacy of an ID submission, then it is up to them to make sure that their submission is in compliance with formal submission deadlines, format, etc. - so that no exception is required. How wide-spread the practice of ignoring the deadlines is in practice and how much the IETF as a whole may have come to accept that this is something that is occasionally done (by any definition of occasionally we care to use), is only relevant if you would argue that there should be no deadlines. This, then, is an implication of your argument and - for the reasons Harald, and others, stated - this is unacceptable. -- Eric ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: EARLY submission deadline - Fact or Fiction?
Marshall, This would work reasonably well, if we could be sure that the planetary alignment case was unlikely. Unhappily, it is not. What happens to the credibility of this approach when the ID submitter, WG chair and AD are all from the same company? -- Eric -- -Original Message- -- From: Marshall Eubanks [mailto:[EMAIL PROTECTED] -- Sent: Tuesday, November 29, 2005 1:23 PM -- To: [EMAIL PROTECTED] -- Cc: Gray, Eric; ietf@ietf.org -- Subject: Re: EARLY submission deadline - Fact or Fiction? -- -- It would seem to me that this could be pushed to a degree onto the -- AD's - -- -- late submissions (up to the point allowed by the machinery) -- would be -- accepted on the request -- of the WG Chair and the concurrence of one of the WG AD's. -- -- I have certainly seen cases where such flexibility would have been -- useful. Getting two people to concur in the -- request will make it a lot harder to abuse the process. -- -- Regards -- Marshall Eubanks -- -- On Nov 29, 2005, at 1:10 PM, Dave Crocker wrote: -- -- Eric, -- -- One of your comments seems to apply to the effectiveness -- of having an early submission deadline. What is the point of -- monkeying around with early submission deadlines when they are -- not very effective anyway? -- -- 1. They add administrative hassle to working groups. -- -- 2. They lead to having the authoritative version of documents be -- outside the Internet-Drafts mechanism, at least for awhile. -- -- -- Sometimes a WG -- chair schedules time to talk about an ID that doesn't exist at -- the time of the schedule announcement and - sometimes - -- still has -- not been submitted by the time of the meeting. ... -- So, one question is whether or not it is appropriate to -- allow this practice to continue. -- -- The broad question is how much freedom a working group -- should have -- to formulate its own procedures. In the not-so-distant -- past, the -- IETF was quite friendly to wildly different working group -- choices. -- More recently our respond to cases (or, yes, patterns) of -- misbehavior has been to make a rule that restricts everyone with -- respect to procedural details. -- -- My own view is that we need to facilitate working group progress -- while ensuring working group legitimacy (fairness, -- timeliness and -- relevance). I believe that progress is facilitated by letting a -- working group do as much self-organizing as it can, while -- keeping -- the working under pressure to be productive. We need to -- do this by -- watching for a working group going astray, rather than by -- imposing -- micro-managing, rigid rules. -- -- I believe this view is compatible with the core of yours: -- -- IMHO, -- I think the common - usage-based - definition is that WG chairs -- get to arbitrate the meaning of these terms as it applies to ID -- submissions for their own WG, especially when submissions are -- late. ... -- -- -- I suspect we differ on: -- -- On the other hand, if someone wants to reduce the WG -- chair's role in arbitrating the legitimacy of an ID submission, -- then it is up to them to make sure that their submission is in -- compliance with formal submission deadlines, format, etc. - so -- that no exception is required. -- -- If I understand correctly, you want to retain a deadline, -- but give -- the wg chair authority to override it. This certainly is -- reasonable, but I think it is not practical because it adds -- administrative overhead (and probably delay) in the -- Internet-Drafts -- processing mechanism. -- -- A simpler rule is that the working group gets to decide its -- deadlines and what will be discussed at the meeting. -- (All of this -- is predicated on moving towards fully automated I-D issuance.) -- -- -- d/ -- -- -- -- Dave Crocker -- Brandenburg InternetWorking -- http://bbiw.net -- -- ___ -- Ietf mailing list -- Ietf@ietf.org -- https://www1.ietf.org/mailman/listinfo/ietf -- ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: EARLY submission deadline - Fact or Fiction?
Dave, Having a general deadline attempts to address (at least) two problems: 1) Allow the Secretariat time to post all on-time submissions; 2) Allow for some time to read the IDs before the meeting. The last time I submitted an ID, it was accepted as is and still took almost a week to make it to the list. The process allows for minor editorial corrections as a result of idnit hits, but when submitting and earlier draft prior to the dead-line, I was unable to determine if it had been posted until jut before the meeting - simply because of a nit picked up by idnits. Consequently, I feel that: A) the current deadline is not actually all that arbitrary since it barely is sufficient to address problem 1 above, and B) offering to stretch the deadline one way or the other based on a presumption of lower processing overhead for a given submission type is also not arbitrary as it can be shown that the reduction in processing overhead for such an ID submission may more than account for deadline differences. Allowing the WG chair to make exceptions prevents the WG from being blocked as a result of processing overhead. However, the WG chair - or whatever person or persons it is that makes this decision - should aggressively discourage late submissions for 2 very good reasons: 1) on-time submissions do not generate random discussions about the arbitrariness of any exceptions that have to be made and 2) making exceptions erodes the credibility of the entire process. -- Eric -- -Original Message- -- From: Dave Crocker [mailto:[EMAIL PROTECTED] -- Sent: Tuesday, November 29, 2005 1:11 PM -- To: Gray, Eric -- Cc: ietf@ietf.org -- Subject: Re: EARLY submission deadline - Fact or Fiction? -- -- Eric, -- --One of your comments seems to apply to the effectiveness -- of having an early submission deadline. What is the point of -- monkeying around with early submission deadlines when they are -- not very effective anyway? -- -- 1. They add administrative hassle to working groups. -- -- 2. They lead to having the authoritative version of -- documents be outside the -- Internet-Drafts mechanism, at least for awhile. -- -- -- Sometimes a WG -- chair schedules time to talk about an ID that doesn't exist at -- the time of the schedule announcement and - sometimes - still -- has not been submitted by the time of the meeting. ... -- --So, one question is whether or not it is appropriate to -- allow this practice to continue. -- -- The broad question is how much freedom a working group -- should have to -- formulate its own procedures. In the not-so-distant past, -- the IETF was -- quite friendly to wildly different working group choices. -- More recently our -- respond to cases (or, yes, patterns) of misbehavior has -- been to make a rule -- that restricts everyone with respect to procedural details. -- -- My own view is that we need to facilitate working group -- progress while -- ensuring working group legitimacy (fairness, timeliness and -- relevance). I -- believe that progress is facilitated by letting a working -- group do as much -- self-organizing as it can, while keeping the working under -- pressure to be -- productive. We need to do this by watching for a working -- group going astray, -- rather than by imposing micro-managing, rigid rules. -- -- I believe this view is compatible with the core of yours: -- -- IMHO, -- I think the common - usage-based - definition is that WG chairs -- get to arbitrate the meaning of these terms as it applies to ID -- submissions for their own WG, especially when submissions are -- late. ... -- -- -- I suspect we differ on: -- --On the other hand, if someone wants to reduce the WG -- chair's role in arbitrating the legitimacy of an ID submission, -- then it is up to them to make sure that their submission is in -- compliance with formal submission deadlines, format, etc. - so -- that no exception is required. -- -- If I understand correctly, you want to retain a deadline, -- but give the wg -- chair authority to override it. This certainly is -- reasonable, but I think -- it is not practical because it adds administrative overhead -- (and probably -- delay) in the Internet-Drafts processing mechanism. -- -- A simpler rule is that the working group gets to decide its -- deadlines and -- what will be discussed at the meeting. (All of this is -- predicated on moving -- towards fully automated I-D issuance.) -- -- -- d/ -- -- -- -- Dave Crocker -- Brandenburg InternetWorking -- http://bbiw.net -- ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: EARLY submission deadline - Fact or Fiction?
Dave, The WGs really can't determine what the reading time is unless we assume that over-riding the submission deadline is a given in many/most cases. In order to satisfy the processing requirements, an ID must be submitted weeks in advance of the meeting. An ID that is submitted weeks in advance is early enough for people to have a chance to read it. It would certainly be aberrant if a WG decided on an earlier submission date, though I personally would not mind - as long as there is advance notification to potential ID submitters allowing them to plan their work accordingly. However, for a WG to decide that a later submission date applies to them is essentially the same as deciding that they will always make exceptions to the submission deadline. This sort of policy would certainly impose strange sorts of hardships on draft submission, draft processing, and - most probably - the WG. As result, I can't imagine a WG establishing such a policy - at least not as a result of a formal consensus. And informally established policies on a per-WG basis is the stuff of which nightmares are made... -- Eric -- -Original Message- -- From: Dave Crocker [mailto:[EMAIL PROTECTED] -- Sent: Tuesday, November 29, 2005 2:30 PM -- To: Gray, Eric -- Cc: ietf@ietf.org -- Subject: Re: EARLY submission deadline - Fact or Fiction? -- -- -- --1) Allow the Secretariat time to post all on-time submissions; -- -- As I recall, this was the primary reason for originally -- imposing the limit. -- -- That is why I explicitly stated the requirement that automated I-D -- processing be supported. -- -- --2) Allow for some time to read the IDs before the meeting. -- -- A working group can decide what the limit for this. As -- with so many other -- potential abuses by a working group, the cognizant AD can -- decide when the -- working group is misbehaving on this matter. -- -- -- Note: -- -- I think folks often miss the costs of specifying particular -- procedures. Having an approval hierarchy is an enormously -- expensive design -- and we have ADs that are already vastly overworked. (The -- Secretariat also -- is not exactly twiddling its thumbs.) -- -- d/ -- -- -- -- Dave Crocker -- Brandenburg InternetWorking -- http://bbiw.net -- ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: EARLY submission deadline - Fact or Fiction?
Dave, I think we're close to agreement here, however there are (at least) two levels/kinds of enforcement involved in what we are talking about. One - the enforcement of policy regarding posting to the Internet Draft depository - has to be done by the Secretariat. The other - enforcement of what gets discussed in the WG meeting - is not even an option for the Secretariat. I suppose they could put spies in the meetings and schedule a much smaller room at the next meeting, if they don't like what is being discussed in any meeting - but I frankly doubt the have time, or inclination, to do that. What tends to happen in practice (that I've observed) is that the posting policy usually guides the discussion policy. Otherwise, there are too many variations in policy and no common place to find out which one applies where. If we agree that having the WG chair - possibly with some form of guidance from the AD - decide when exceptions may apply to the discussion policy, then we have essentially agreed to what is already status quo. Nice chatting with you. :-) -- Eric -- -Original Message- -- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] -- On Behalf Of Dave Crocker -- Sent: Tuesday, November 29, 2005 3:05 PM -- To: ietf@ietf.org -- Subject: Re: EARLY submission deadline - Fact or Fiction? -- -- -- -- If I understand the two choices you present are: -- -- 1) the wg has to decide to overrule a default deadline; -- 2) the wg has to decide on all of its own deadlines. -- -- It seems to me (granted I have limited experience) that -- the administrative -- overhead is actually higher in the second case -- -- frequently it is simplifies -- things to just have a default case. -- -- -- The question is who enforces a deadline. -- -- Having the Secretariat enforce it means that the -- Secretariat must be -- involved in exceptions. That's high overhead and delay. -- -- The alternative is to move both policy and enforcement to -- the working group. -- -- Given the amount of agenda-bashing, document-negotiation, -- etc. that already -- must (and should) take place within a working group, I -- think that the matter -- of deciding submission deadlines is a small increment. -- -- That said, it can't hurt to have a guideline for a 2-week -- deadline, or the -- like, so that a chair can declare that to be in effect as -- the default. -- -- d/ -- -- -- -- -- Dave Crocker -- Brandenburg InternetWorking -- http://bbiw.net -- -- ___ -- Ietf mailing list -- Ietf@ietf.org -- https://www1.ietf.org/mailman/listinfo/ietf -- ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: XML2RFC submission (was Re: ASCII art)
Dave, It looks - to me - as if Bob's post is in response to Bob's own earlier post. That should make it difficult to construe his more recent post as an attack. At worst, it's a quick response indirectly aimed at another quick response. One issue with to quickly responding to Bob's earlier questions is that the XML version - as Christian has already said - cannot be the authoritative/normative version of an RFC. I would qualify that someone by allowing that an XML version cannot be authoritative/normative unless it is completely self contained. And, by self contained, I mean there MUST be an absolute, positively concrete guarantee that every time we process it, it will always produce exactly the same text. If that is the conditions under which it may be useful, then it is simpler to retain the text. The reason for this - as someone else pointed out - is that the version on which people have agreed is the text version that they read at the time when they agreed. Even if the text version was directly produced at that time from XML, it is that text that they read at the time that they agreed to. An analogy of why this is an issue can be seen in why it is that a pre-merge version of a slew of nearly identical contracts has no legal value - even if archived with an exact image of the data used in the merge. Only a signed contract has the enforceability of a signed contract. -- Eric -- -Original Message- -- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] -- On Behalf Of Dave Crocker -- Sent: Tuesday, November 29, 2005 3:59 PM -- To: Bob Braden -- Cc: ietf@ietf.org -- Subject: Re: XML2RFC submission (was Re: ASCII art) -- -- -- -- Bob Braden wrote: -- It is easy to give glib answers to the following -- questions, ignoring -- many detailed issues. Easy, but suspect. -- -- -- Bob, it is also easy to ask a set questions and then -- dismiss answers to -- them. Easy but suspect. -- -- First of all, if you did not feel that your questions were -- sufficient, it -- would have been nice for you to have said so. Evidently -- you were looking -- for something other than responses, but there is no way to -- tell what. -- -- Second of all, if you feel that simple answers to your -- directed questions is -- not sufficient, perhaps you will respond in a manner that -- encourages -- exploration, rather than attack. -- -- d/ -- -- -- -- -- Dave Crocker -- Brandenburg InternetWorking -- http://bbiw.net -- -- ___ -- Ietf mailing list -- Ietf@ietf.org -- https://www1.ietf.org/mailman/listinfo/ietf -- ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: EARLY submission deadline - Fact or Fiction?
Joel, I agree with your observation completely. One essential problem with allowing WGs to independently determine their own deadlines is that this tries to assert that impact on people's scheduling needs in a WG is independent of similar needs for other working groups. Because all of the working groups meet in a single week and the mix of WGs that each individual wants/needs to participate in is not the same for all participants, it is best if all working groups use a single common deadline, posted - as is currently the case - in each meeting's important meeting dates. Perhaps in the fully automated processing Dave posits for our future, it will be sufficient for the automated processing to flag a submission as being beyond the cut-off - both to the submitter and to the targetted WG(s). This would certainly be an improvement over the current process that results in an apparent hold on processing anything that is beyond the cut-off - thus making it very difficult for a WG to effectively make an exception. Also, there would be no more of an enforcement element in this approach than there is in enforcement of template and other formatting requirements in the proposed automated processing. But - as Dave said - all this is predicated on the existence of a fully automated submission process. That's an important dependency, because it will never - quite - happen. There will always be a need for manual intervention and - assuming a largely automated process - the resources available to handle manual intervention would likely become scarce. Consequently, with an automated submission process, it will usually be the case that a draft submission can be made independent of processing delays - but - it will occasionally be the case that an arbitrarily large delay will be incurred in processing a specific submission. I am not sure that this would necessarily be an improvement - however - in such a case, an early submission date that takes into account the possible processing requirement will help. -- Eric -- -Original Message- -- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] -- On Behalf Of Joel M. Halpern -- Sent: Tuesday, November 29, 2005 4:35 PM -- To: ietf@ietf.org -- Subject: Re: EARLY submission deadline - Fact or Fiction? -- -- There is an aspect of the deadline that is helpful for me, -- even when the deadline is not rigidly enforced. -- -- The presence of the deadline means that the bulk of I-Ds -- are in by the deadline, and are out by not too long after -- the deadline. -- -- This means that I can collect announcements for I-Ds of -- interest and have time to read the I-Ds across most of the -- range of working groups that I try to stay current on. -- -- If working groups as a matter of course published I-Ds -- within a few days of the meeting, it would be almost -- impossible for me to read most of what I need to in order -- to be an informed participant. -- -- Yours, -- Joel -- -- At 01:10 PM 11/29/2005, Dave Crocker wrote: -- ... -- A simpler rule is that the working group gets to decide -- its deadlines and what will be discussed at the meeting. -- (All of this is predicated on moving towards fully -- automated I-D issuance.) -- -- -- d/ -- -- -- -- Dave Crocker -- Brandenburg InternetWorking -- http://bbiw.net -- -- ___ -- Ietf mailing list -- Ietf@ietf.org -- https://www1.ietf.org/mailman/listinfo/ietf -- -- -- ___ -- Ietf mailing list -- Ietf@ietf.org -- https://www1.ietf.org/mailman/listinfo/ietf -- ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: DHCID and the use of MD5
Russ, Sorry, but what kind of options? Looking at my key board, I can't tell whether you meant to type available or avoidable... -- Eric -- -Original Message- -- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] -- On Behalf Of Russ Housley -- Sent: Tuesday, November 29, 2005 5:08 PM -- To: Sam Hartman -- Cc: ietf@ietf.org; [EMAIL PROTECTED] -- Subject: Re: DHCID and the use of MD5 -- -- Sam: -- -- Perhaps I was being too terse. I think we are in agreement -- about the -- most important parts. I was trying to say that once you are forced -- to deploy new code, protocol changes and algorithm changes are both -- avaioable options. -- -- Russ -- -- -- At 12:51 PM 11/29/2005, Sam Hartman wrote: -- Russ == Russ Housley [EMAIL PROTECTED] writes: -- -- Russ At 11:44 AM 11/29/2005, Sam Hartman wrote: -- Honestly though the authors seem more upset about -- agility than -- about md5. I think we're certain we want agility. -- -- Russ There are two kinds of algorithm agility: - -- build it into -- Russ the protocol - update the protocol each time -- you want to use -- Russ a new algorithm -- -- I disagree that you always have the second. In particular -- you may not -- have behavior that allows you to change the protocol. For -- example the -- SMIME verifier behavior of requiring all (instead of one) -- signature to -- validate makes the change the protocol approach harder. -- -- I think this is an example of a case where you don't have -- the second -- kind of agility without changing the protocol. In -- particular you need -- clients and hcp servers to expect there to be more than one record -- available. -- -- Russ Everyone always has the second. The author -- already made an -- Russ argument against the first, but other seem to -- be supporting -- Russ the other form. I do not understand the impact on the -- Russ current deployment. Do you? -- -- so, the deployed code will have to change somewhat -- already. They are -- currently using txt records; they will need to transition -- to this new -- RR. -- -- -- However the update behavior if you add agility is more complicated. -- -- -- ___ -- Ietf mailing list -- Ietf@ietf.org -- https://www1.ietf.org/mailman/listinfo/ietf -- ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
