Re: Hugh Daniel has passed away
Paul Wouters p...@cypherpunks.ca writes: Hugh Daniel passed away on June 3rd after what appears to have been a heart attack. I remember many interesting moments and conversations within the times that I talked with him. He was a very memorable person. But certainly the one that stands out in my mind the most was our first encounter. He wrote me over email as we were arranging a time and place to meet and ended it with I'll be wearing a red shirt; you won't miss me. I thought at the time that was quite a declaration. And indeed I did not miss him that day. I do now, however. -- Wes Hardaker Parsons
Re: STEAM: BOF proposal for Berlin
Tony Hansen t...@att.com writes: I'm thinking the enhanced RFC format proposed below should be dubbed STEAM/PUNC. And anyone that participates in said work would be STEAMed. -- Wes Hardaker SPARTA, Inc.
Re: request to make the tools version of the agenda the default
Richard Barnes rbar...@bbn.com writes: Ever try writing an XML app? Half your time is spent writing a .xml parser. No, see... you're expecting good xml. use XML::Simple $x = xmlIn(file.xml); It's the easiest thing in the world to use. But it doesn't parse complex without more pain (but who wants that) and it's still perl (and who wants that?) -- Wes Hardaker SPARTA, Inc.
Re: request to make the tools version of the agenda the default
Michael Richardson m...@sandelman.ca writes: There is .csv and obviously there is .ics too already. Didn't know about the CSV; that'd be just fine. .ics is 'too much' in general though. -- Wes Hardaker SPARTA, Inc.
Re: request to make the tools version of the agenda the default
John C Klensin john-i...@jck.com writes: I think changing the default is fine. I'd also be reluctant to see the normal HTML version go away immediately but would be especially reluctant to see the plain text version go away or even become less accessible (require more clicks or searching to navigate too). I suspect we can all agree that this would be optimal: 1) have the tools version be the default (my original statement) 2) have the html version still present 3) have the text version still present 4) produce an xml version for better parsing (ever try and write an agenda app? Half your time is spent writing a .txt or .html parser) 5) have each of the above have links between them I'd assume that this is difficult (aside from #4 which would take the most time as it's not just a switch-flip); although it's possible someone has done it already and I just haven't learned of it. -- Wes Hardaker SPARTA, Inc.
request to make the tools version of the agenda the default
So, the 'tools version' with all the wonderful spiffy links to helpful things (the materials, the etherpad, the ...) and the spiffy highlighting ability (Dark Red! I love dark red!) has been very stable and highly useful for quite a while now. But the default link on the web page still points to the less-useful HTML version (which has a link at the top to get to the tools version). I'd argue this is backwards at this point, and the tools version is so much more useful (and just as stable) as the plain-html version that it should be the default. Can we do that for March+? [I know, we just *ended* a face-to-face meeting so why am I bringing up face-to-face meeting topics so far before the next one? That's unheard of! Call me crazy...] -- Wes Hardaker SPARTA, Inc.
Re: Recall petition for Mr. Marshall Eubanks
Olafur Gudmundsson o...@ogud.com writes: If you agree with this petition please either comment on this posting, With regret, if you still need more signatures, you can add my name to the list and I am nomcom eligible. -- Wes Hardaker SPARTA, Inc.
Re: Steven Bellovin appointed FTC CTO
Steven Bellovin s...@cs.columbia.edu writes: Yes, for the next year I'll be at the Federal Trade Commission, advising on security, privacy, and other technical issues. Because I'm still doing technology and not just policy, I will not have to put the technical part of my brain into storage while I'm here. It's rare, these days, to see people with a clue appointed to important positions where a difference can be made. I'm very happy that it happens occasionally; your appointment proves it can. -- Wes Hardaker SPARTA, Inc.
Re: [IAB] IETF 92 in Dallas!
Behcet Sarikaya sarikaya2...@gmail.com writes: It was a natural event that happens rarely in Dallas, in fact since 2006, it has not happened again. That's because we haven't been back yet. -- Wes Hardaker SPARTA, Inc.
Re: WG Review: Recharter of Hypertext Transfer Protocol Bis (httpbis)
On Tue, 21 Feb 2012 23:01:09 +, Stephen Farrell stephen.farr...@cs.tcd.ie said: The approach we're advocating for this WG is to solicit well-formed proposals, select one and develop it. If there isn't one for HTTP authentication, how are you advocating we proceed? SF Right now, I'm interested in what others reviewing the SF draft charter think about this topic. That's the point SF of having this discussion in the open like this. IMHO, if you want security to be well integrated into the next version of the protocol, then it should be thought about up front. The IETF doesn't have a great track record of adding security later to protocols in a way that is seamless and integrated. And if you don't put thinking about security in the solicitation request charter version, then you may well end up in the state that Mark is worried about: none of the answers have security considered. I think the charter should definitely have a requirement indicating that proposals must explain how security techniques would fit into it in the future, even if they don't fully define the solution/extension itself. -- Wes Hardaker SPARTA, Inc. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Plagued by PPTX again
On Tue, 15 Nov 2011 09:23:56 -0800, todd glassey tglas...@earthlink.net said: tg PPTX is Office 2007 format and there are formal readers and format tg API's for office so that this is a no brainer. Great. I do note that .odp is no where on the accepted list that people have been posting (granted, I'm lazy, so I haven't checked the list myself). Can we get the OO suite formats accepted too? It seems silly we're allowing .pptx and similar MS branded files, but not accepting .odp and other files. OO/Libre has been around far longer than recent 2007 and even older MS updates, so lets accept them as valid document types as well. They certainly work on more platforms that the .ppt and similar formats. So, IMHO *either* we accept only .pdf or we accept a whole lot more. Yes, I could go down the road of ok, then we can use magic point, and all sorts of other ones too. Yes, we could... but they're not nearly as popular. But I'd argue .odp is certainly as popular in this crowd, if not more so, than .ppt. -- Wes Hardaker SPARTA, Inc. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Fwd: [81all] Quick Meeting Survey
On Tue, 20 Sep 2011 09:09:52 -0800, Melinda Shore melinda.sh...@gmail.com said: MS So, I'm looking at the results and see that -9 people skipped MS the birth year question. It was worded poorly too. It should have read: Do you have a Gray Beard? A) Yes B) No -- Wes Hardaker SPARTA, Inc. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Queen Sirikit National Convention Center
On Mon, 08 Aug 2011 12:58:32 +0700, Glen Zorn g...@net-zen.net said: GZ In any case, a taxi from any of the hotels on the list would today GZ cost $3 (probably closer to $2) one way. I'd argue that group shuttles, as has been done in the past, is probably a better option than trying to have 1000 people even share taxi rides. -- Wes Hardaker SPARTA, Inc. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Drafts Submissions cut-off
On Mon, 1 Aug 2011 16:27:55 -0700, Paul Hoffman paul.hoff...@vpnc.org said: PH Or, (3), specify somewhere that the submission window opens at the PH beginning of the meeting and allow WG chairs to decide what they PH want to do about new drafts. In the case last week, the draft was PH turned in and posted to the mailing list on Monday ahead of the PH meeting on Friday; the chairs seemed to like that. It all comes down to how to best get information to those that need it (as fast as possible). I too, read the older version of the draft that being discussed and didn't realize there was a new one because I rarely get to *all* of my mail during IETF weeks (I'm too busy talking in the hallways to read email). That being said, I think forward progress on drafts are most likely to happen *during* IETF meetings in hallways and thus it's impossible to enter a WG meeting and assume that no thinking has changed in the 3 weeks since the last draft was published. IE, this has nothing to do with the drafts themselves. It has to do with communication of changebars. In the case where significant changes have taken place in thinking (documented or not) because of conversations or work that has commenced since the cut-off date, it should be the responsibility of the authors to give a quick summary early in the meeting about recent progress, as it's indeed unfair to assume everyone in the audience hasn't printed and read everything only an hour before the meeting and were present in every conversation that occurred over the cookie table (regardless of whether there were actually cookies or just crumbs there). It should also be up to the chairs to bug the authors about making sure that any recent changes are, in fact, at least listed or presented in detail depending on what's best for the meeting. You can't hold a discussion half the participants have only half the information. It doesn't matter who's fault it was. It only matters that it's a problem. -- Wes Hardaker SPARTA, Inc. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Confidentiality notices on email messages
On Mon, 18 Jul 2011 14:41:35 +0200, Harald Alvestrand har...@alvestrand.no said: HA Content-disposition: noise. Or: Content-disposition: delete -- Wes Hardaker SPARTA, Inc. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Confidentiality notices on email messages
On Thu, 14 Jul 2011 14:39:17 -0400, John C Klensin john-i...@jck.com said: Ooh, I like this proposal. We can also have noise-types for exhortations to not print the email. JCK If one starts down that path, there is a real possibility for a JCK semantically-rich environment. For example, consider a noise JCK type for flaming, repetitive, responses to a topic on the IETF JCK list. One could also very efficiently reflect what I assume was JCK the intent of a recent observation on the list with JCK noise-type=hitler :-( Obviously we need to take a typical step back first and determine the scope of the problem. We need to commission a requirements for noise ID first. -- Wes Hardaker SPARTA, Inc. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Second Last Call: rfc5953 (Transport Layer Security (TLS) Transport Model for the Simple Network Management Protocol (SNMP)) to Draft Standard
On Tue, 10 May 2011 23:28:59 -0700, SM s...@resistor.net said: Changing the references also means the downref call needs to be updated, as follows: This specification contains eight normative references to standards track documents of lower maturity: RFCs 1123, 3584, 4347, 4366, 5246, 5280, 5890, and 5952. S RFC 1123 is an Internet Standard (STD 3). The normative reference is S not a downref. Good point; When the reference changed from the previous RFC to this one, it should have been removed (not changed) in the downref list. S P.S. I am not asking for a third Last Call. Heh. Yeah, I don't think that's required for an upref. -- Wes Hardaker Cobham Analytic Solutions ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Fisking vs Top-Posting
On Mon, 20 Sep 2010 14:20:03 -0400, Phillip Hallam-Baker hal...@gmail.com said: PH One of the problems I have seen emerge on many IETF mailing lists is the PH habit of fisking. This could all be solved by moving IETF discussions to Google Wave. Then I could start responding to your thought even before you finished typing it. -- Wes Hardaker Cobham Analytic Solutions ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
review of draft-saintandre-tls-server-id-check-09
by a human user. But the odd case that I couldn't figure out what it mapped to was references from an original source. EG, images or javascript elements in a web page aren't provided by the user, but a web-browser is certainly interactive. This sort of snow ball domain list probably should be discussed at least in brief. Section 5.1, Service Delegation: I read the last paragraph (which is one sentence) multiple times and I only barely feel that I understand what it's saying. I'd suggest rewording it for clarity and splitting it into multiple sentences. I'd offer suggestive text, but then I'd prove that I really didn't understand it. General: Some of the possible combinations and options that may exist could really use an examples section or something that had example info from a certificate combined with example list of expected reference indenties. Though this would be nice, it's not at all critical. -- Wes Hardaker Cobham Analytic Solutions ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Gen-ART review of draft-ietf-isms-dtls-tm-09
SD Summary: This specification is almost ready for publication as a SD Proposed Standard. I do have some (late Last Call) questions, almost SD all of which are around either 2119 language or clarity. Thanks for the review Spencer! I'll look at addressing your comments today. -- Wes Hardaker Cobham Analytic Solutions ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Gen-ART review of draft-ietf-isms-dtls-tm-09
. (FYI, note that DTLS also runs over both SCTP and DCCP). How does the following wording sound as a replacement: When run over a connectionless transport such as UDP, DTLS is more vulnerable to denial of service attacks from spoofed IP addresses 9 WONTDO 9.3. MIB Module Security ~~~ SNMP versions prior to SNMPv3 did not include adequate security. Even if the network itself is secure (for example by using IPsec), even then, there is no control as to who on the secure network is allowed to access and GET/SET (read/change/create/delete) the objects in this MIB module. + Spencer (nit): I don't think you need even then, in this sentence, which already has one Even at the beginning. + WH: I agree, but this is functionally template text that is required from the mib boiler plate. In fact it's so common place that the exact phrasing above exists in 145 other published RFCs ;-) 10 DONE 10. IANA Considerations ~ + Spencer (minor): Is this a note to remind the editor (not the RFC-Editor) to replace text during AUTH48? Not sure I've ever seen one like it before :D + WH: Ha! Good point; thanks (and fixed). -- Wes Hardaker Cobham Analytic Solutions ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Gen-ART review of draft-ietf-isms-dtls-tm-09
On Wed, 14 Apr 2010 15:57:56 -0500, Spencer Dawkins spen...@wonderhamster.org said: 2 WONTDO 3.1.1. Threats ~ SD Oh, I agree that you shouldn't delete it, especially since you SD confirmed that it's normative. I was hoping for something a little SD more precise (like, naming a mandatory-to-implement non-NULL SD encryption cipher suite :-) and I'm now wondering why it's not a SD MUST/MUST unless X. But do the right thing ;-). The idea was to leave algorithm requirements up to the base-protocols. SNMP has a long history of not mandating encryption (for reasons that are historic and probably no longer valid), and we didn't want to change that. Hence the SHOULD. Anyway, I'll leave it as is and consider this closed. Thanks! [similarly for the 2119 issue] 6 DONE 2) continued: ~ If the connection is being established for reasons other than configuration found in the SNMP-TARGET-MIB then configuration and procedures outside the scope of this document should be followed. Configuration SD I'm easily confused, but isn't this sentence word-for-word what the SD original text said? :D Um, whoops. Wrong copy/paste apparently. I should have quoted this: If the connection is being established from configuration based on SNMP-TARGET-MIB configuration, then the snmpTlstmAddrTable DESCRIPTION clause describes how the verification is done (using either a certificate fingerprint, or an identity authenticated via certification path validation). Which spells out more clearly configuration based on instead of reasons. SD If this is clear to those skilled in the art, no problem. I'm just SD telling you I can't parse it! No, I'm sure it's confusing to anyone without a strong background in how the SNMP-TARGET-MIB works in SNMP. We've tried to make it clean but I'm more than certain to someone without knowledge of how the SNMP-TARGET-MIB works you'd get quickly lost. -- Wes Hardaker Cobham Analytic Solutions ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Review of draft-ietf-isms-dtls-tm-09.txt
BA I reviewed the document draft-ietf-isms-dtls-tm-09.txt in general BA and for its operational impact. Bernard, Thanks for your review and comments on the draft! -- Wes Hardaker Cobham Analytic Solutions ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-ietf-isms-dtls-tm (Transport Layer Security (TLS) Transport Model for SNMP) to Proposed Standard
On Wed, 10 Mar 2010 16:52:25 -0500, Robert Story robert.st...@cobham.com said: RS I think that the inconsistent use of 'Client' and 'Server' in the RS object names is confusing. Both snmpTlstmSessionOpens and RS snmpTlstmSessionOpenErrors are client-side only objects, and RS snmpTlstmSessionAccepts is a server-side only object. Putting RS Client/Server back in the object names will make it much easier to RS understand the output of a snmpwalk without having to refer to the RS description clause in the MIB. This naming scheme was the result of a previous discussion (that I lost!) and the decision at the time was that the words client and server weren't needed in objects that were already only useful for that type of entity. IE: ServerAccepts is redundant since only a server can accept new connections. Because this is already a closed issue I don't see a need to revisit the discussion. -- Wes Hardaker Cobham Analytic Solutions ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: OpenDNS today announced it has adopted DNSCurve to secure DNS
On Wed, 24 Feb 2010 09:56:30 -, Dearlove, Christopher (UK) chris.dearl...@baesystems.com said: CD Actually (since I have access via my own resources) the only CD content beyond the subject line above is s bit.ly link. Anyone who's posting a link to a twitter message to an email message and seriously couldn't cut-n-paste a 140 character message into the email body is certainly doing so to attract followers as there is certainly no other motivation to make things more difficult for the reader. -- Wes Hardaker Cobham Analytic Solutions ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Corporate email attachment filters and IETF emails
On Wed, 09 Dec 2009 17:38:51 +0100, Julian Reschke julian.resc...@gmx.de said: JR I would hope that the ID actually points out a specific IETF mailing JR list for comments, and the author is reading it. I'd say most do not. Most just list author addresses and do not list the WG mailing list. -- Wes Hardaker Cobham Analytic Solutions ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Corporate email attachment filters and IETF emails
On Tue, 08 Dec 2009 19:16:04 +0200, Jari Arkko jari.ar...@piuha.net said: JA But its good that Bob's IT person has promised to figure this out. The JA filters seem simply too sensitive. I have not heard of other people JA having a similar issue, at least not beyond an extent experienced for JA all autogenerated e-mail (travel reservations etc). That's all well and good if all you're concerned about is the posting verification message from the automated servers. But consider the fact that: half the purpose of posting an ID is to get comments about it sent to you. Consider then that if you have any sort of aggressive filtering in place that's blocking your receipt of the verification messages then the chances are very very high that you'll also block comments from some random person out there that happens to look questionable to your companies blocking algorithms. I've found large numbers of companies, for example, that assume that all their traffic is internal to their particular company and start running spam assassin with very high scores against mail arriving from outside their local bubble. This doesn't work well with comments about an IETF document. -- Wes Hardaker Cobham Analytic Solutions ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
IETF Flickr Group
There are enough photographers within the crowd that I figured we should have a flickr group for documenting the work and meetings in a NON-ascii way for once. http://www.flickr.com/groups/ietf Feel free to join the group and add pictures if you're interested! After reading the requirements first, of course :-) -- Wes Hardaker Cobham Analytic Solutions ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Request for community guidance on issue concerning a future meeting of the IETF
On Wed, 23 Sep 2009 14:48:36 -0400, Michael StJohns mstjo...@comcast.net said: MS If your answer is - because there's some benefit to the IETF - I MS would then ask what else should we be willing to give up for other MS benefits and where should we draw the line? If we give up our normal level of free speech then we should expect darn nice cookies in trade! -- Wes Hardaker Cobham Analytic Solutions ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Request for community guidance on issue concerning a future meeting of the IETF
On Sun, 20 Sep 2009 18:42:36 -0700, Randall Gellens ra...@qualcomm.com said: RG (1) The law and associated hotel rule Marshall quoted could be RG violated by what may appear to IETF participants as technical RG discussion. For example, the manipulation/censorship of Internet RG traffic by or under orders of the Chinese government is well known. If RG this were to be mentioned or discussed during the IETF, perhaps in the RG context of encryption, tunneling, web proxy, DNS, or some other RG technical area, we could run be violating the law and hence the RG rule. I've had similar thoughts: what happens when the lines are blurred? Where are the lines exactly in the first place? I think many potential technical conversations will be conversations that could be viewed as anti-government because the IETF frequently develops technology to get around middle-box impediments. What would happen to those discussions? 1) they would happen anyway, and nothing would happen (yay!) (regardless of whether they went unnoticed or weren't offensive) 2) thew would happen anyway, and would get shut down 3) they wouldn't happen because of fear The problem isn't just one of can we have it. The mere existence of the policy may prevent people from voicing a comment they might in another venue. A single missing comment or discussion due to fear would be a bad thing. -- Wes Hardaker Cobham Analytic Solutions ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: secdir review of draft-ietf-netconf-partial-lock-09.txt
On Thu, 13 Aug 2009 08:26:54 -0700, Andy Bierman i...@andybierman.com said: AB discard-changes only works because authorization is ignored, AB otherwise the agent would be deadlocked. Huh why would discard-changes be authorization ignorant??? That's just as unsafe (unless you're only discarding your own changes). AB Only the global lock operation defined in RFC 4741 AB can prevent this problem. The global lock has different issues. The problem isn't with the locking. Locking, and partial locking are good. It's with the global-level commit operation. -- Wes Hardaker Cobham Analytic Solutions ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: secdir review of draft-ietf-netconf-partial-lock-09.txt
On Thu, 13 Aug 2009 13:55:15 -0700, Andy Bierman i...@andybierman.com said: AB Oherwise the agent would deadlock. AB discard-changes does not affect the running configuration. No, but it does affect the other users notion of changes. You should never be allowed to discard changes that another user has made. AB It just resets the scratchpad database. AB Why bother applying the ACLs before the edit operation AB is attempted for real? user 1: add new important policy configuration user 2: discard-changes user 1: commit Granted, user 1 should be using locks of some kind. To undo changes it's rather important that someone with proper authorization to the everything changed (IE, an admin) performs the discard. Or are you suggesting that one shouldn't ever have access control applied to the candidate store in the first place? (I hope not). AB Requiring small embedded devices to serve as robust AB database engines may be more expensive than AB the rest of the code combined. We are coming from AB an operational environment based on humans using the CLI, AB which has no locking at all. The globally locked AB candidate edit, validate, and commit model AB is way better than anything we ever had in SNMP or CLI. If you look at history of operating just about anything, after it gets to a point where multiple operators need to scale things up you'll find that eventually stuff gets put into a multi-user revision database type system. We are far beyond the point where operators are editing single flat-files using vi and hitting save without any form of revision control. After that point, then went to locking version control systems (sccs? I'm forgetting the early version-control system names). Then people realized that caused huge headaches because the global file locking, although it prevented some types of problems, caused a bunch of other problems. Eventually more modern version control systems were developed that allowed people to simultaneously edit things and only get bothered when conflicts happen. This was a huge win, ask anyone who works with version control systems. But now, in this space, we're going back to the older methodologies of editing a single file and hoping that two people don't conflict (with or without a lock). I've said this before, but I'll repeat it now: netconf, from a protocol-operation point of view, is designed to work in a single-operator type environment. The instant you add multiple-users with or without different roles all these problems come up. This is actually just fine, but it needs to either: 1) be fixed so that these problems go away. 2) stop being advertised as a multi-operator type solution. I think being fixed is a great long term goal. But for right now, I'd suggest we simple say this is version 1 at the moment and it is currently designed for use by single-operator systems. (And it doesn't prevent an external version-control system for being the master and pushing the config down. It just doesn't work on the device itself). -- Wes Hardaker Cobham Analytic Solutions ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: xml2rfc is OK ( was: Re: XML2RFC must die, was: Re: Two different threads - IETF Document Format)
On Mon, 6 Jul 2009 10:18:14 +0300, Lars Eggert lars.egg...@nokia.com said: LE I'm fully open to trying something new once someone creates a LE different (better) tool, but until then, xml2rfc is OK. I'd even argue that the xml2rfc language is pretty good and fairly flexible. I've run into a number of things I'd like to force it to do that are mildly difficult, but in the end I've been happy with the language. It's the tool that needs a rewrite, IMHO. Don't get me wrong, it's taken us a long way and we wouldn't be as far forward in interoperable ID authorship if it weren't for the existing tool. However, like all good prototypes eventually you need to take what you've learned and rewrite it to fix the problems. I've been tempted to take on the task myself, but don't have the allocated time to make it happen. (and it certainly wouldn't be in TCL, as that's about my least preferred language of the large number of languages I've written code in; no offense to TCL lovers). -- Wes Hardaker Cobham Analytic Solutions ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: IETF and open source license compatibility
On Thu, 12 Feb 2009 22:03:39 +0100, Simon Josefsson si...@josefsson.org said: SJ The IETF Trust sub-license third parties rights to code components in SJ (new) IETF documents under the BSD license, see section 4 of: SJ http://trustee.ietf.org/docs/IETF-Trust-License-Policy.pdf Thanks! Does anyone else feel that the IETF likes to document things in ways that reflect a maze of twisty passages? We're very good at making many rooms (all 5686 of them) but not so good at marking the passageways between them. -- Wes Hardaker Sparta, Inc. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: It's time for some new steps
On Mon, 9 Feb 2009 20:21:23 -0500, Scott Brim s...@employees.org said: Normally, I advocate entirely ignoring silliness, but the current version of it is more than silly. Particularly since mail to the -request address bounces, and using the web interface to unsubscribe apparently has no effect. SB worked for me ... but enough on this. FYI, I unsubscribed twice. The first method (logging in with my assigned password and hitting unsubscribe) failed even though it told me it succeeded. So I tried the second approach which was to simple enter my address and hit the unsubscribe button to have it mail me a confirmation URL. Visiting the confirmation URL did seem to work, so I'd suggest people try this method for unsubscribing if the login method fails for you like it did me. -- Wes Hardaker Sparta, Inc. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: how to contact the IETF
On Tue, 10 Feb 2009 07:20:39 -0500, Andrew Sullivan a...@shinkuro.com said: AS I'm not sure I agree with that claim. It's true that decisions are AS not made by counting votes. Decisions _are_ supposed to be made, AS during consensus call, by weighing the arguments and the apparent AS support for the document. And the question is: did all those people writing in read and understand the draft and fully understand the issue? Or are they just regurgitating a do this announcement. How do you weigh a bunch of uninformed responses against a fewer number of informed ones. Personally, I'm not sure I agree the draft is good to go precisely because I haven't read enough information on both the draft, the potential patent and the pseudo-grant so I haven't voiced my opinions about it (until now... whooops). We ask all the time in the IETF meetings who's read the draft. We rarely follow up low-number responses with questions of who believes it's ready for publication when the number of readers is very low. That's the situation we're in now: a lot fewer people have read and understand the various documents than are weighing in on the subject. Do we consider consensus based on +1 comments or based on the opinions of only the more informed readers. And what do we do when it becomes impossible to determine who is who? -- Wes Hardaker Sparta, Inc. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: 5378: A Worked Example
On Wed, 17 Dec 2008 07:40:30 -0800, Eric Rescorla e...@networkresonance.com said: ER That list contains 14 names. Let's say that I have a 95% chance of ER getting any one of those people to give consent. The joint probability ER that I will obtain all the required consents is .95^14, less than 1/2. ER I imagine the situation is similar for other large, old ER documents such as RFC 3261 (SIP) or 2616 (HTTP). The problem with both open processes and open source is that when they hit issues like this the tendency is to be either: 1) too loose 2) too strict We're now switching from #1 to #2. And switch is what's going to bite us. I'm sure that some of the contributors to some past documents aren't even alive which will make some of this paperwork really interesting. The only thing you can adjust in the above math is the success rate of your contacts. That means you need to improve your accuracy a bit Eric or you'll certainly fail! Maybe the IETF needs to hire a private investigator? The problem is that when it comes signing paperwork like that, I'd assume (not being a lawyer I'm good at assuming) that it's the company paying the individual that has to authorize at the least or more likely sign the paperwork. If the company and the individual are not on good terms or if the company doesn't exist any longer or has no recollection of even sending someone to the IETF because their strategic directions have changed that 95% may seem a bit too generous. Maybe it would be easier to start from scratch on everything and do a complete rewrite (by fresh people that have never read the previous documents and thus can't be influenced by the text). As far as actually operating in a too strict mode: some open-source projects require signing copyright assignment papers before they can contribute to the project (FSF does this, for example, before contributing to Emacs (or nearly everything else)). The downside, of course, is reduced contribution. The upside is you've successfully pulled of the strictness quite effectively. The downside of the IETF, however, is that contributions occur at the microphone and on public mailing lists. You could, I suppose, require everyone attending the IETF to sign a legal document assigning their contributions away. However, how many people have you all met that have come to the IETF (promising not to eat the cookies) without paying because they had no sponsor and couldn't afford it and gotten up to speak at the microphone? How many people contribute only on the mailing list without ever attending an IETF? How many chairs show the note-well screen at the start of each meeting long enough so that people actually could read it? How many chairs have forgotten to show it? How many people have read RFC5378 vs those that have not? I'm sure the overlap is a very non-zero. Until we get rfid chips that turn on the microphone and X.509 certs that state we're authorized to contribute to mailing lists I fail to see how all this helps. I suspect others are in the same boat of confusion. As I mentioned, I'm not a lawyer. But I don't see how publishing one document in a list of documents that currently numbers more than 5400 and expecting that everyone will abide by it will solve the issue. But what do I know? I'm not a layer so I don't understand the rules. I'm just somehow supposed to abide by the rules I don't understand. -- Wes Hardaker Sparta, Inc. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: WG Review: NETCONF Data Modeling Language (netmod)
On Wed, 23 Apr 2008 07:45:02 -0700, Eric Rescorla [EMAIL PROTECTED] said: ER I remain concerned that this is the wrong technical approach; it ER appears to me to be unnecessary and overcomplicated. However, it's ER clear that's a minority opinion, so I'll drop my objection to this ER charter. At the risk of getting things thrown at me: 1) I too actually have issues with the YANG proposal as it stands. 2) But I do think it's a slightly better starting place than the other proposals, and thus don't take issue with letting the WG start there. In particular, I strongly believe (and said this at a mic) that the result has to optimized for people that don't understand complex languages like with hard to read syntaxes like XSD, etc. I think a different language, like YANG, is necessary as the existing languages simply don't meet that goal. YANG does meet this goal better than others but I don't think it goes far enough. But I don't think the creation of the working group will mean changes can't be made to the results of a design team. Generically speaking, a design team is tasked with doing the best they can but it is still up to working group consensus to say that'll do or that'll do with these modifications. -- Wes Hardaker Sparta, Inc. ___ IETF mailing list IETF@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: udp source address change
On Sat, 11 Feb 2006 10:13:53 +0900, Masataka Ohta [EMAIL PROTECTED] said: Protocols and implementations should generally respond using the address to which the request packet was sent. That being said, there are sometimes protocol reasons not to do this and sometimes implementations don't necessarily handle things properly internally. But, I doubt most protocols ever specify the legality of what address is used to respond to a request. Masataka RFC1035 says it a bug. So, it should be illegal. It does say it's a bug but doesn't exactly say illegal. And 1035 only applies to DNS. There is no general statement about UDP (unfortunately). -- In the bathtub of history the truth is harder to hold than the soap, and much more difficult to find. -- Terry Pratchett ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: udp source address change
On Tue, 7 Feb 2006 10:20:37 -0800 (PST), mharrima101 (sent by Nabble.com) [EMAIL PROTECTED] said: mharrima Is the behavior of the HP switch legal under UPD? It seems mharrima to me as though this should not be allowed. Protocols and implementations should generally respond using the address to which the request packet was sent. That being said, there are sometimes protocol reasons not to do this and sometimes implementations don't necessarily handle things properly internally. But, I doubt most protocols ever specify the legality of what address is used to respond to a request. Thus, what should happen is what you want. In reality, as you noticed, some implementations fail to do this. -- Wes Hardaker Sparta, Inc. ___ 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
Eliot Wes received the obvious feedback that operators find SNMP Eliot unusable with the USM model because they cannot integrate it Eliot with their existing security infrastructures and there is no Eliot denying that this is a real problem. But this is NOT the only Eliot problem operators face with SNMP. FYI, there was a other comments field in the survey that the operators filled out. I just went back and reviewed everything entered into that space and no one asked for anything like the CH functionality, nor did they even mention NATs or firewalls at all. That being said, that wasn't the point of the survey and I do think the problem shouldn't be forgotten. I think we'd be stupid to let the work go forward and do something that deliberately prevented CH functionality from being usable in the ISMS/SSH draft. However, everything needs to be weighed and I do think we should make sure it's possible till we run into a problem. At that time we'd have to evaluate the choices to decide which was more important (the potential problem being unknown at this time of course). I'm not sure the charter needs to explicitly state that we must consider call home support. It sounds like there is enough energy to make sure we don't blow it. I would strongly object to anything that says we must support it, because as has been stated many times that's not the point of the WG. At the same time, I think we'd be idiots not to at the very least leave room for it (but then, I think we're not being wise for dropping the consideration of a UDP solution too, so...) -- Wes Hardaker Sparta, Inc. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: ISMS working group
On Mon, 12 Sep 2005 14:52:39 +0200, Eliot Lear [EMAIL PROTECTED] said: If you really believe that this solution is needed, I think you would do best to write a draft and _then_ try to get it adopted by an appropriate WG. Eliot I (amongst others) *did*. draft-kaushik-isms-btsm-01.txt. Eliot What had been missing up until this point was an SSH draft. Eliot And the working group developed consensus on this non-existent Eliot draft. You've got to be impressed. Elliot, sorry to hear that you wrote a draft that the WG didn't want. It happens. In fact, it happened to me in this WG, no less. In fact, if you want to play the game of I had a draft written first and thus I should win, then I think mine would trump yours ;-) Wouldn't the best thing to do be to help the SSH draft authors ensure your needs are met rather than complain about your draft not being the choice the WG went with? Just because CH functionality isn't in the charter doesn't mean you can't analyze the resulting SSH draft for problems with (future or now) CH functionality. That would mean either CH would be possible now or it would leave room for an easy addition for support for it in the future. Obviously, the WG has chosen not to make it their top priority but I doubt anyone would complain about leaving room for it unless the suggestions dramatically affected the agreed upon architecture or solution. -- Wes Hardaker Sparta, Inc. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: ISMS working group and charter problems
On Wed, 7 Sep 2005 09:42:33 -0400, Margaret Wasserman [EMAIL PROTECTED] said: I believe that the ISMS WG's proposal is about ADDING the possibility of SNMP over TCP, not about CHANGING SNMP to use TCP. UDP will still work. Margaret That is correct. UDP and the current SNMPv3 USM security Margaret mechanisms will still work. They will also remain mandatory Margaret parts of SNMPv3. Though it's important to note that the reason for the creation of the WG was that although the security features in SNMPv3 definitely worked, they were hard to use. Thus operators didn't always deploy SNMPv3 because it was a pain to set up the user base. By saying that we're going to now allow SNMPv3 over TCP to use their existing user infrastructures, I agree that you are not saying you can't use SNMPv3/USM over UDP as you've always been able to. However, since many don't want to use that today I think their choice will still boil down to SNMPv3/ISMS/TCP or nothing if they're unwilling to take the deployment hit that was already preventing wider adoption of SNMPv3/USM in the first place. Yes, SNMPv3/USM/UDP will still be just as usable as it was before. But it still won't be used as much as it should be. -- Wes Hardaker Sparta, Inc. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: anti-climatic odometer sighting
On Tue, 15 Feb 2005 21:33:35 -0500, Michael Richardson [EMAIL PROTECTED] said: Michael So, I noticed that RFC4003 was issued. Michael Wow, so we passed the 4000 mark. Michael I went to find out what rfc4000 was. Michael Aha... not yet issued. Michael That's kind of anti-climatic. Oh well. Michael Maybe 4096 will be more fun :-) I think you'd find that it's always reserved for listing purposes and not for standards themselves. Thus: # rfcfind -n 3.00 3000 Internet Official Protocol Standards. J. Reynolds, R. Braden, S. Ginoza, L. Shiota. November 2001. (Format: TXT=115207 bytes) (Obsoletes RFC2900) (Obsoleted by RFC3300) (Status: STANDARD) 3100 Not Issued. 3200 Not Issued. 3300 Internet Official Protocol Standards. J. Reynolds, R. Braden, S. Ginoza, A. De La Cruz. November 2002. (Format: TXT=127805 bytes) (Obsoletes RFC3000) (Obsoleted by RFC3600) (Status: STANDARD) 3400 Not Issued. 3500 Not Issued. 3600 Internet Official Protocol Standards. J. Reynolds, Ed., S. Ginoza, Ed.. November 2003. (Format: TXT=134338 bytes) (Obsoletes RFC3300) (Obsoleted by RFC3700) (Also STD0001) (Status: STANDARD) 3700 Internet Official Protocol Standards. J. Reynolds, Ed., S. Ginoza, Ed.. July 2004. (Format: TXT=148273 bytes) (Obsoletes RFC3600) (Also STD0001) (Status: STANDARD) So if you want to look for something new in the 4000+ range, look at 4001 as being special. -- Wes Hardaker Sparta ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: namedroppers mismanagement, continued
On Wed, 27 Nov 2002 09:55:49 -0800 (PST), Randy Presuhn [EMAIL PROTECTED] said: Randy As someone who has maintained a couple of WG mailing lists for Randy several years, I'd object to the imposition of such a Randy requirement. The amount of spam, especially *large* (megabyte Randy or more) viral messages, directed at WG mailing lists makes Randy keeping all the trash a highly unattractive proposition. I think the proper solution here is to use proper tools rather than to impose another burden on the list administrators. Mailing management has come a long way in the last few years. The easiest package I've seen for administrative purposes is probably the mailman package, which is being used by a very very wide range of Internet groups. As an example, all of the SourceForge mailing list software is managed by mailman. I strongly encourage the use of a more intuitive mail package like mailman. I've managed many mailing lists with it, ranging in size from a few people to 5000 and I must say that it makes administration easy. Moderated lists, or subscriber-only lists are more easily taken care of because list administrators just have to click on a button that says reject or accept or discard. The nice thing about the reject action is that it sends back text to the user saying what the problem was and how they can likely correct it. IE, the complaint that started this huge thread (dropped problems as opposed to a properly worded response going back) are generally taken care of by the software, not the administrator, which is important. It's so easy to use that my Dad can and does use it, who knows nothing about SMTP, sendmail, aliases, unix, postfix, ... I'm sure Randy Bush will have no trouble with it. It's only disadvantage is that it's heavily web based, which will probably make a few people groan. However, it would be rather trivial to write a mail-based, script-based, or other wrapper around it if that was the only problem with it. IMHO, it's long past the time that the IETF should have a centralized mail management system where lists can be (not forced to be, of course) centrally created and yet still managed by individual list authors. The ops area has been doing this for a while, but I think it makes sense for the main organization to host this instead if possible (yes, I do realize that a server and bandwidth would have to be donated to the cause). It's all the small administrative issues like this that detract us from real work on real protocols. Let's fix this at the global level, please. Sourceforge hosts 51,700 projects most of which have multiple mailing lists associated with them. We should learn from their experiences. -- Wes Hardaker Network Associates Laboratories
Re: Regarding MIBs
On Thu, 13 Jun 2002 17:47:37 +0530, Chandra Shekar Reddy Challagonda [EMAIL PROTECTED] said: Chandra We have register our MIB to get the OID. What my question Chandra was that, where I can register that. Hope you got my Chandra question. http://www.iana.org will let you register a enterprise number, which will then give you the mib tree below .1.3.6.1.4.1. -- Wes Hardaker NAI Labs Network Associates
Re: snmp
On Tue, 31 Jul 2001 08:05:47 +0300, BUGRA GUMUS [EMAIL PROTECTED] said: BUGRA Sorry I disturb all of you! But I need detail information about BUGRA SNMP source codes. How I can get RFCs of snmp and does anybody BUGRA know how I can find snmp source code (C;C++; or java ... etc) BUGRA to examine them. See RFCs 2570-2576 (at least) from ftp://ftp.ietf.org/pub/rfc/ For source code, there are lots of packages. See www.snmplink.org for some. -- Wes Hardaker NAI Labs Network Associates
Re: basic question on SNMPv1
On Thu, 08 Mar 2001 00:29:38 +0530, "Shivendra Kumar" [EMAIL PROTECTED] said: Shivendra Can we have multiple IP addresses associated with a Shivendra community string in SNMP v1( snmp v1 agent )? Also, can we Shivendra have multiple community string associated with a single IP Shivendra address? How is the trap reporting supposed to behave in Shivendra each of the above cases? Yes. There is not a required relationship between community strings and agents that mandates a one to one mapping. Some implementations, however, may implement it that way but its not specified by the protocol to do so. Trap reporting is implementation dependent as well, but typically the list of trap destinations would be configured with the community string they wish to use when sending traps to that destination. -- Wes Hardaker NAI Labs Network Associates
