RE: IETF66 - Recommendations for travel from airport to hotels?
> Aerobus shuttle bus service runs from the downtown bus > terminal (514-842-2281) with several stops before taking > the highway. Fares are lower than taxis: $12 to or from > Trudeau. And from the bus terminal to the hotel? Presumably taxi or city bus? Any other alternatives? Are they any shuttle busses from the airport that make stops at the downtown hotels? ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: netwrk stuff
Dave Crocker writes... > The key point is having a status that is determined by > market penetration, rather than technical details. Proposed > is for the technical work. Full is for market success. That sounds reasonable. > By way of providing some incentive, I suggest that Proposed > have a limit, such as 3 or 5 years (and, yes, we can quibble > about that, too.) If the work cannot gain sufficient adoption > by the end of that time, it has failed and warrants moving to > Historic. I think that may be too harsh, if there has been some adoption in the market but less than "sufficient" adoption (however we define that). Perhaps moving to Informational would be more appropriate, in those cases. Regards, Dave Nelson ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: Why cant the IETF embrace an open Election Process
Noel Chiappa writes... > ...I think perhaps the most useful one in practise is > another one which I mentioned earlier: > > >> Rather than having everyone spend ten minutes on > >> deciding who to select, a subset (which the random > >> draw hopefully makes reasonably representative of > >> the group as a whole) does a more in-depth and > >> thought-through selection. I agree. Since this thread has been going done the path of civic governance models, let me elaborate one that supports the current NOMCOM model. In my area, many towns govern themselves via Town Meeting, in which all voters are invited to a deliberative session to pass budgets, ordinances and the like. When all goes according to plan, there is an open exchange of information and a reasoned debate on the issues prior to each vote. Many claim this to be the "true democracy". Other towns have decided that the population has grown too large for Town Meeting to be practical and effective. One alternative is Representative Town Meeting. The electorate chooses (by election) a tractable number of representatives to attend the Town Meeting on their behalf. These representatives debate the issues and vote them up or down. I think NOMCOM is like a Representative Town Meeting, in which the representatives are chosen by a random selection process, rather than by election. The outcome, which supports in-depth consideration and substantial, informed debate, is much the same. Quite frankly, I don't see a need to substantially change this model. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: [Nea] UPDATED: WG Review: Network Endpoint Assessment (nea)
Keith Moore writes... > what the WG charter says and how the WG output is used are > different things. IMHO we need to consider the potential > unintended consequences of our efforts in IETF, not just what > we intend. network operators do not limit their use of > technology to what we write in applicability statements. Should I infer from this sentiment that you believe that the IETF ought to refrain from standardizing any technology that could be used by public or private network operators to discriminate against certain classes of clients, based on the "posture" of their hosts? I'll point out that only certain kinds of discrimination are undesirable, i.e. discrimination against protected classes. Other kinds of discrimination, e.g. helping to maintain a "safe computing" environment within a network, are highly desirable. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: DNS Choices: Was: [ietf-dkim] Re: Last Call: 'DomainKeys
Phillip Hallam-Baker writes... > I agree that this demonstrates that the 'charge per email' > schemes that people have don't work. I'm not so sure about that. The fact that there is a real cost certainly changes the dynamics of unsolicited mail, as well as the business model of the purveyors. Cost factors will not eliminate it, but it might improve the "quality" of the offers and reduce the quantity of messages. > But if postal mail recipients could impose filters they would. Indeed. > And there is in point of fact an entire police force tracking > down scam artists using the postal mail. Right. One additional distinction is that most unsolicited mail in the US (typically called junk mail) is mailed at discounted bulk postage rates. In order to mail at bulk rates, an organization needs a permit from the post office. This involves some level of "authentication". Of course, mail sent at first class or second class postage rates can be sent anonymously. However, I get very (very) few pieces of junk mail sent at first or second class rates. It's all bulk rate mail. This is another example of the cost of mailing driving the behavior set. A second distinction is that the US Postal System (in the US) is a government sanctioned monopoly, and in many countries the postal system is still a government agency. When you have a single entity acting as the receiver of all outgoing mail, it makes it much easier to enforce policies regarding cost and "authentication". In that regard, snail-mail is not a very good analogy for e-mail discussions. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: DNS Choices: Was: [ietf-dkim] Re: Last Call: 'DomainKeys
Peter Sherbin writes... > > policies regarding cost and "authentication". In that regard, > > snail-mail is not a very good analogy for e-mail discussions. > > The basic premise is all the same: user -> need to send -> > delivery charge. > Fee collector does not matter: US Post, UPS, FedEx, DHL, > Purolator or ISP. Yes, but my point was that it would be relatively difficult to subvert a post office employee or insert mail into the postal system by bypassing the post office. I'm not so sure that the analogous properties hold for ISPs and the Internet. There are just too many ways to get attached, and inject traffic. Assuming that all ISPs would comply with both the spirit and letter of the rule, in this regard, is perhaps naive. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: Tracking resolution of DISCUSSes
Good issues are being raised. Certainly there needs to be openness about any substantive changes in drafts during the IESG review process. I'm not enamored of the idea of yet more mailing lists to subscribe to, however. Why can't we rely on the PROTO Shepherds to do the right thing with regard to posting DISCUSS issues to the WG mailing list and collecting WG feedback into the IESG review? After all, we rely on the WG Chairs to do the right thing in declaring consensus on WGLC prior to submitting the documents to the IESG with a request for publication. Regards, Dave Nelson ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: IETF 63 On-line Survey
James M. Polk writes... > Few people talk during sessions, and those that do, know to sit where they > can readily get to a mic to make a point. Yes, but sometimes there's a choice to be made between sitting where there is easy access to a mic and sitting where there are open power strip outlets. :-) ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: BCPs and STDs
> *> ;) I'm a DNS person, I only do lookups, not searches. > > I am not sure what the distinction is, ... A lookup typically returns either a single, exact match or a failure message. A search typically returns a [large] number of matches, of varying degrees of exactitude. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: ISMS working group and charter problems
Daniel Senie writes... > Based on your email, the consensus of the group is that TCP is good > enough, since it'll only be interesting to manage networks that are > operating cleanly. I can't imagine that's what the WG really > concluded, but that's how your email reads. It seems to me that the existing USM, SNMP over UDP, and a local user account would be sufficient as a fallback network management method when the network is experiencing a meltdown. Just as you have a local /etc/passwd file on your UNIX workstations, for those occasions when the NIS server is unreachable. I don't think anyone believes that ISMS will obviate the need for at least one local account on managed entities, to cover this type of situation. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: ISMS working group
Let's assume, for the sake of discussion, that SNMP must always work across Firewalls and NATs. The original objection to the proposed charter was that it did not include support for "Call Home" functionality. I can see how Call Home would solve the NAT problem, at least on a sporadic basis. The managed entity could initiate an "outgoing" NAT session to the management station, and the management station could use that connection as needed. I don't see how this allows the management station to later initiate an "incoming" connection to the NAT'ed managed entity. Nor do I see how it would enable firewalls to safely pass through only the desired SNMP traffic. Clarification would be helpful. Thanks. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: [Isms] ISMS charter broken- onus should be on WG to fix it
Juergen Quittek writes... > It [call home] looks like a good topic for a BoF session in the > OaM area. > There we could find out the relevance of the problem and discuss > requirements for potential solutions. Also there we can identify > which working group would be the right one to deal with the issue. > > But until then, I propose that we let the ISMS group work on solving > its original problem. I agree that specifying Call Home functionality in SNMP should be out of scope for ISMS, which is attempting to solve a different, well-defined problem. I also agree with Dave Harrington's suggestion that the SSH transport mechanism for ISMS should be designed such that the initiation and termination of SSH sessions, and the use of such sessions by the command generator and command responder, would not preclude another WG from specifying Call Home functionality using the ISMS work, unless that requirement overly complicated the ISMS design work. I would call this division of labor an appropriate "separation of concerns". ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: Anyone not in favor of a PR-Action against Jefsey Morfin
For those who suggest that PR action is never appropriate to take against any person, let me suggest that rights of free expression are not unlimited. Any human right has practical limits when it comes into direct conflict with the rights of another. For example, consider two college roommates. One wishes to exercise his freedom of expression by listing to music until 3 AM in the morning (without the benefit of headphones, of course!). The other wishes to exercise his right to get sufficient sleep so as to be well rested for the big exam the following morning. Clearly, each roommate, taken individually, is exercising a reasonable freedom, but in this case they have come into conflict. While I have no opinion on the current case, it seems to me that the basis for any such PR decision has to be based on the balance of rights. Does the right of the allegedly abusive poster to express himself come into conflict with the rights of the other mailing list participants to conduct an orderly discourse? If such a conflict exists, then is the imposition on the many sufficiently large to justify limiting the rights of the one? ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: On PR-actions, signatures and debate
Anthony G. Atkielski writes... > There are no objective standards for obnoxious, abusive, or > disrespectful speech. I think that this is not so hard to distinguish as you suggest. There are two general cases: (a) overly insistent and (b) overly personal. The overly insistent poster will almost always attempt to have the last word in any thread, repeats positions frequently on the premise that if you say something often enough it become true, and inserts "pet peeve" issues into otherwise unrelated threads. The overly personal poster makes comments about other posters, for example making assertions about their lack of clear thinking, their failure to understand the issue, their unspoken motivations, their stubbornness, and so forth. While there are no standards, I think that case (a) can be usually be recognized by sheer volume of postings and case (b) is easily detected because the subject of argument ceases to be about the technical details of the protocol, and becomes about the other correspondents. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: On PR-actions, signatures and debate
Anthony G. Atkielski writes... > Then it should be straightforward to automate it in the form of a > robot that emotionlessly evaluates each post. No. I did not claim that the evaluation was objective. It is in fact subjective. I do claim that the "reasonable man" (and I use that term in the sense that the legal profession uses it) can fairly easily recognize abuse when he sees it. I suppose this is akin to one US Supreme Court Justice's opinion on the definition of pornography: "I can't define it, but I know it when I see it." ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: On PR-actions, signatures and debate
Eric Gray writes... > To one person, the mere fact that another person disgrees > with them is conclusive proof that they don't understand. To > another person, the mere statement that they don't understand > clearly implies some impairment. > > It's possible that both of these people might be taking > things a lot more personally than either of them should. I agree. I think the threshold for personal abuse ought not to include clarifications (e.g. "I think you misunderstand my point.") but rather more explicit assessment of impairments (e.g. "You are totally clueless."). ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: from the horse's mouth
JFC (Jefsey) Morfin writes... > Describing this way the key societal matters at hand > certainly shows the IETF is not interested/competent and does not > intend to invest in them. I agree, and I see others who seem to concur, that human behavior is of legitimate concern in systems design, and therefore in protocol design. When we consider typical, individual human behavior it is often called Human Factors Design, or more generally user-friendly design. Consideration of human behavior in the aggregate, i.e. social issues, is different. While I haven't followed this general thread (the IETF is ignorant, insensitive and ethnocentric) carefully, it seems that the subjects of debate surround what natural languages we support in our protocols, and who gets to own or control what set of Internet resources (addresses, names, bandwidth, access, etc). This is more in the realm of international geo-politics. I think that the IETF SHOULD be concerned with Human Factors Design issues in its work products, as well as some level of support for multiple natural languages (or at least providing for a level playing field). As to all the other issues, which I lump into the categories of international politics and national strategic interests, I don't think the IETF is the right place to address these issues. Good engineering discipline is largely orthogonal to these political concerns, IMHO. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Human Factors Design (was RE: from the horse's mouth)
Eliot Lear writes... > I guess what I'm saying is that who develops the running code and who > actually knows how the code should be developed to interact with humans > can be very different... Indeed. No argument there. :-) > ... and while we at the IETF have the expertise in > writing code, we probably have very little on the CHI side, and probably > cannot, with the rare exception of the person who has transitioned > careers. Or we do the best with the expertise available. Without wishing to in any denigrate the value of CHI subject matter experts, PhD level or otherwise, alternatives are sometimes available. One of my former employers had a formal Human Factors Design group. In other cases, we have relied on the Documentation Group (technical writers) to provide insight. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: Please make sure that you do not run your WLAN in ad hoc mode
Phillip Hallam-Baker writes... > I think that what we should do is to send the IEEE 801.b/g group a > polite letter pointing out that if our people here at the IETF cannot > figure this stuff out then their less technically astute customers might > be having some trouble as well. I don't believe this is an 802.11 problem. That group standardizes PHY and MAC (up to Layer 2) protocols. The usability problems with 802.11 networks are in the device drivers, operating systems and configuration applications. It would be more effective to send mail to Microsoft, Apple, et. al. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: Please make sure that you do not run your WLAN in ad hoc mode
Dave Singer writes... > Some testing and robustness guidelines from the 802.11 group > would also help. While you may believe that IEEE 802.11 should provide these services, I will note that the Wi-Fi Alliance (WFA) currently fills that gap. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: Please make sure that you do not run your WLAN in ad hoc mode
Phillip Hallam-Baker writes... > You sound like a 1950s British trades unionist calling his men out on > strike over demarcation. Insult me, if it makes you feel better. I stand by my advice. This is a product usability problem, not a technical shortcoming of the underlying standards. My observation was as to the most effective way to raise the issue. IEEE 802 doesn't do product testing, but the Wi-Fi Alliance does. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: I-D file formats and internationalization
Ole Jacobsen writes... > This is a good point. It even applies to the IETF secretariat. It used to > be impossible to register with your "real name" if it contained non-ASCII > characters. I think that has changed, I recall having Seen Olafur > Gudmundson's badge with the real Icelandic "curly d" (or whatever it is > called in English) at a recent meeting. I have not seen Japanese or > Chinese or Korean, which I guess would be the next logical step... While this is a bit of a digression, the purpose of IETF badges is (at least) two-fold. First, to show that the bearer has paid the registration fee, and second, to allow other attendees to address the bearer by name during sessions and informal conversations. If badges were in non-Latin character sets, it would make it difficult for me to address the bearer in English. It seems that there are parallels for RFCs and I-Ds. If the official language of these documents is English, then should we have portions of those documents represented in other languages, and more at issue, other character sets? In the attributions sections, one could, of course, provide a Latin character set representation in addition to the native national character set, for names, addresses, etc. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
IETF vs. global politics (was RE: I-D file formats and internationalization)
Phillip Hallam-Baker writes... > Ah here you make the mistake of thinking that the IETF community is the > Internet community. Perhaps forty years ago, but certainly not today. > > The IETF does not make any effort to be representative of the Internet > community. I beg to differ. I think the IETF makes a very reasonable effort by its extraordinary attempts at openness and inclusiveness: no formal membership requirements, no voting status, no government-appointed delegates, freely available work-in-progress and final documents, decisions made on the mailing lists, no requirement to travel to face-to-face meetings to participate, streaming audio of meeting sessions, jabber rooms, and the list goes on. It seems to me that the primary objections of those who feel disenfranchised surround a specific set of existing IETF behaviors: conducting all its business in English and using US-ASCII for documents (instead of something that supports non-Latin character sets), and a set of alleged IETF behaviors: being somehow insensitive to the economic, social, political and cultural aspirations of non-native English speakers, and having some hidden agenda to retain US hegemony of the Internet. I think that's a lot of stuff and nonsense. Certainly there is room for inclusion of non-Latin character sets in documents for items such as names and addresses of contributors. If the suggestion is effectively that the IETF needs to conducts its business like the UN, with simultaneous translation into six languages, I think that's impractical, and probably detrimental. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
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
RE: Normative figures
Stewart Bryant writes... > If linearised formulas were a good idea mathematicians would use them :) > Translation to ASCII representation should surely be the final step in > implementation not something imposed during the understanding and > description phase. If symbolic formulas were useful in protocol implementations, then programming languages like C or C++ would accept them. IMHO, if it's good enough for the implementation, it's good enough for the specification. Academic and scholarly articles often make extensive use of symbolic mathematical expressions, because that's the language of mathematics, and the accepted format for those publications. I would not like to see these formats used in protocol specifications, as a general rule. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: Last Call: draft-ietf-pana-framework-06
Bob O'Hara writes... > I can't forecast what an official interpretation > response might say, but the text in clause 5 is taken from the overview > section of the standard. The text prohibiting non-802.1X frames from > passing on the uncontrolled port is taken from clause 6, the description > of the Data SAP. My opinion would be that the text in clause 6 would be > given precedence, both because of its placement and because of its > specificity. I offer a little historical perspective on the text under debate in this thread. I am responsible for the text in Clause 5 that appears to allow other protocols besides 802.1X/EAPOL, which terminate in the AP, i.e. do not allow forwarding to the DS, to run over the 802.1X uncontrolled port in the AP. I added this text to one of the 802.11i drafts specifically to address a letter ballot comment on the previous draft. I was quite active in TGi at the time, including the comment resolution work. TGi voted to accept this comment resolution. It was arguably my mistake to leave the apparent conflict with the text of Clause 6, but the comment was probably only against Clause 5. Whether this comment resolution was a good idea, in the long run, is of course open to debate. The intent at the time was to allow operations such as those proposed in PANA, at least to the extent that I understand them based on this thread. I'm not sure this will help in resolving the issue, but at least it explains the apparent conflict. Regards, Dave Nelson ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
