Last Call: (Updated Security Considerations for the MD5 Message-Digest and the HMAC-MD5 Algorithms) to Informational RFC
forwarding comments as per last call request. Lloyd Wood http://tinyurl.com/lloydwood-ccsr From: Wood L Dr (Electronic Eng) Sent: 01 December 2010 07:56 To: turn...@ieca.com; lily.c...@nist.gov; alexey.melni...@isode.com Cc: Wood L Dr (Electronic Eng) Subject: Last Call draft-turner-md5-seccon-update http://datatracker.ietf.org/doc/draft-turner-md5-seccon-update/?include_text=1 says The attacks on HMAC-MD5 do not seem to indicate a practical vulnerability when used as a message authentication code. or, when used for error detection, which is not discussed. MD5 is still perfectly acceptable in non-security contexts, for detecting e.g. file corruption, as in checking that the .iso disk image downloaded is good to use. I've spent a lot of time in the IETF dealing with security types who believe that, because MD5 has flaws that affect security use, it should therefore not be used at all in any context -- although it's fine in a reliability-only context and very useful for detecting errors. (This topic has derailed protocol development, and has also been the subject of more than one IETF talk.) The document should imo indicate that MD5 remains acceptable in non-security contexts, and indicate clearly and verbosely that the document is limiting its scope to security applications only, not non-security applications. Security Fear, Uncertainty and Doubt should not be allowed to spill over into non-security contexts. I understand that this issue has been raised with the authors privately previously by others, but has not been addressed. Lloyd Wood l.w...@surrey.ac.uk http://sat-net.com/L.Wood The IESG has received a request from an individual submitter to consider the following document: - 'Updated Security Considerations for the MD5 Message-Digest and the HMAC-MD5 Algorithms' 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 substantive comments to the ietf@ietf.org mailing lists by 2010-12-22. Exceptionally, comments may be sent to i...@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: (Updated Security Considerations for the MD5 Message-Digest and the HMAC-MD5 Algorithms) to Informational RFC
> means to me that using MD5 for anything that requires collision > resistance (2 of the 7 uses) is bad but if they're using it for the > other 5 they're okay. > > Do you think that's too many dots for people to connect? > > I'm not in favor or repeating everything in RFC 4270 (i.e., I'd rather > not be verbose). > > spt Lloyd Wood l.w...@surrey.ac.uk http://sat-net.com/L.Wood ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: (Updated
On 3 Dec 2010, at 21:40, Martin Rex wrote: > l.w...@surrey.ac.uk wrote: >> >> I also take issue with RFC4270's claim that: >> >> The Internet protocol community needs to >> migrate in an orderly manner away from SHA-1 and MD5 -- especially >> MD5 -- and toward more secure hash algorithms. >> >> which is rather broad, and entirely without the context and qualifiers >> we're discussing. RFC4270 was not written for a general audience, >> but for a security audience. The Internet _security protocol_ community >> may well need to migrate from these for certain uses (despite there not >> yet being obvious things to move _to_), but RFC4270 and your draft's >> sum take-away message that MD5BADDONOTUSE overstates the case. > > I agree that the above wording of rfc-4270 is BAD. > > It should have said: > > The Internet community needs to migrate in an orderly manner away from > SHA-1 and MD5 -- especially MD5 -- and toward more secure hash algorithms > for all security-related usages of hash functions in all protocols. That wording is better, though I would also add a qualifier on the front by saying 'away from reliance for security purposes on SHA-1 and MD-5...'. This should imo be filed as an erratum on RFC4270. >> Despite the fact that, as you say, it's still good for five of seven uses, >> including integrity protection (which gets a mere sentence in 4270 as the >> last of the seven - it's imo an area that is often neglected in protocol >> design). > > IMHO there is a serious defect in rfc-4270. The "integrity protection" > bullet ought to be bullet three, The list isn't explicitly ranked. But putting the reliability point last does say something interesting about the security mindset... if it's not a deliberate attack, it's just not interesting or worthy of note. > and MD5 is definitely _NOT_ suitable > for anything with the term "integrity" in it. That depends imo on whether "integrity" is used as a term in a security context by a security person, or by anyone else. (I am not using the term as a security person, but have been forced to use it when talking to security people who have little notion of protection against errors or of reliability.) > Integrity protection is terminology that is used in the > security&cryptographic area and this defect of rfc-4270 is going > to create misunderstandings. Yes. We've actually run into this problem previously, and had to carefully use the terms when talking to those who focus on terminology used, rather than the overall point that is trying to be made. This leads to verbal gyrations and a degree of doubletalk. 'Integrity' and 'protection' do have meanings outside security, and were used long before their specific use in a security context (cf database integrity, system integrity, even integrity protection in chemical plants). From context here and the rest of the sentence, it's imo clear that reliability is what is being referred to. I don't think this is necessarily a second erratum, but then I'm not a security type, and think that this is an example of why mathematicians often invent new terms, rather than overloading old ones. > MD5 (and SHA-1) are hash functions, and as such, they exhibit probabilistic > collisions for different inputs. MD5 is still useful for detection of > "accidental" errors due to noise or distortion, or segmentation/reassembly overwriting bugs or... it can be used to support the the end-to-end-principle. > but it is not suited > to protect against intentional modification of data by an attacker. agreed. > There are other algorithms for detecting "accidental" errors, like > "ECC bits", or CRCs of various sizes, e.g. > http://en.wikipedia.org/wiki/Cyclic_redundancy_check > > Think of MD5 as an alternative to CRC128. Well, MD5 is not a cyclic code, and CRC128 wouldn't cope well with checking across anywhere near the sizes that MD5 can support; 128-bit MD5 has been compared in error-detection strength (nb not crypto strength!) to CRC2048++, which would be a rather complex polynomial. But I'm not so much of a purist that I would stall at nitpicking your terminology here. Instead, I agree that the overall point that you're making here is expressing exactly the point about MD5 that I've been trying to make, in relatively simple language for laymen. To come back to where we came in, MD5 is fine for detecting errors in a non-security context - but readers of RFC4270 and draft-turner-md5-seccon-update are not going to pick that up from a casual read, and will come away with 'MD5 bad, do not use' (and what's the alternative?). draft-turner-md5-seccon-update needs to be much, much clearer on this and in setting scope for use of MD5. regards, L. > > > > -Martin Lloyd Wood l.w...@surrey.ac.uk http://sat-net.com/L.Wood ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: (Updated
On 4 Dec 2010, at 03:23, Martin Rex wrote: > Although the attacks against MD5 published so far are practical only > for creating collision pairs, there has not been published a practical > preimage attack against MD5. But the practical collision attack alone > is devastating for several integrity protection usage scenarios. I am wondering how the authors of RFC4270 wound up misusing the 'integrity protection' term to cover both intentional (attack) and unintentional modifications, whereas reliability checking covers only the latter. But, to the security mindset, everything is an attack. I've now filed two errata on RFC4270. regards, L. Lloyd Wood l.w...@surrey.ac.uk http://sat-net.com/L.Wood ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: Last Call: ('Headers-Not-Recognized' HTTP Header Field) to Experimental RFC
This draft does not discuss the Content-* rule. Content-* headers are special,
in that they may not be ignored (section 9.6 of [RFC2616]). Recipients not
understanding Content-blah: will generate a "501 (Not Implemented)" error code.
That overrides the proposal below, I think.
The proposal in the draft doesn't appear to work with proxies, which often may
be passing through headers that they themselves don't understand.
This draft does not appear to be associated with a working group. I suggest
discussing this on the hybi mailing list; it's a little offtopic, but a bunch
of http experts do read that list and can offer comments.
-Original Message-
From: ietf-announce-boun...@ietf.org [mailto:ietf-announce-boun...@ietf.org] On
Behalf Of The IESG
Sent: 13 December 2010 13:28
To: IETF-Announce
Subject: Last Call:
('Headers-Not-Recognized' HTTP Header Field) to Experimental RFC
The IESG has received a request from an individual submitter to consider the
following document:
- ''Headers-Not-Recognized' HTTP Header Field'
as an Experimental RFC
The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive comments to the ietf@ietf.org
mailing lists by 2011-01-14. Exceptionally, comments may be sent to
i...@ietf.org instead. In either case, please retain the beginning of the
Subject line to allow automated sorting.
The file can be obtained via
http://datatracker.ietf.org/doc/draft-yevstifeyev-http-headers-not-recognized/
IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-yevstifeyev-http-headers-not-recognized/
No IPR declarations have been submitted directly on this I-D.
___
IETF-Announce mailing list
ietf-annou...@ietf.org
https://www.ietf.org/mailman/listinfo/ietf-announce
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf
Re: IETF Challenges - DTN and the Internet of Stuff
Stephen Farrell wrote: > > Cool. As it happens, DTNRG folks agreed last summer to start > work on a bis version of the bundle protocol (RFC5050), and > now that we've gotten a few other things out of the way, we > should be starting in on that real soon now. So if that > does happen, then I'd say now's a great time to get involved > in DTN stuff. Revising the bundle protocol, a protocol that: - has no concept of ensuring end-to-end reliability, yet is intended to be used in challenging environments which affect reliability - insists on having synchronised real-time system clocks and can't tolerate offsets between them, so clock drift kills communications would be great ideas - except such revisions addressing those significant showstopper problems have been proposed before in that research group, and have not progressed beyond drafts over the course of five years under the co-chairs' stewardship due to complacency, lack of interest, and lack of understanding of the problems. Coupled with repeated denial that these are, in fact, problems. (The size and complexity of bundle protocol implementations prevents their use in the embedded system arena, as well.) A great time to get involved in DTN bundle protocol work was when it was getting funded, with the promise of it solving the communication problems it proved unable to address. That time has passed. (some technical background: A Bundle of Problems, IEEE Aerospace 2009. See: http://personal.ee.surrey.ac.uk/Personal/L.Wood/publications/index.html#bundle-problems http://dx.doi.org/10.1109/AERO.2009.4839384 ) Lloyd Wood http://sat-net.com/L.Wood/dtn
RE: congestion control? - (was Re: Appointment of a Transport Area Director)
The problem with the congestion/interference and corruption problem is that error notification does not percolate up the stack. If a MAC driver could say 'this frame is corrupt, failed CRC' and that information percolated up the layers into the flow to the endpoints, TCP or similar might have more to go on. But that information is hard to convey, multiple links may be affected, it gets lost... first hops benefit most. in other words, Explicit Corruption Notification would fail for the same reasons that Explicit Congestion Notification does. And this is presuming that enough of the frame is recoverable to know which higher-layer flow it is associated with reliably, ie some header check passes, but overall frame check fails so there's a discard, and state is around to signal the right flow. And to make the header checks pass with a chance of decoding the headers have to be coded better than the payloads - and this applies at each layer, recursively. um. But there's a paucity of cross-layer signalling, and a paucity of higher layers even sanity-checking their header with checksums. And a paucity of available state to track and associate with flows. Lloyd Wood http://sat-net.com/L.Wood/ From: ietf-boun...@ietf.org [ietf-boun...@ietf.org] On Behalf Of Dearlove, Christopher (UK) [chris.dearl...@baesystems.com] Sent: 05 March 2013 11:55 To: m...@sap.com; bra...@isi.edu Cc: ietf@ietf.org Subject: RE: congestion control? - (was Re: Appointment of a Transport Area Director) I've no idea about the example quoted, but I can see some of their motivation. TCP's assumptions (really simplified) that loss of packet = congestion => backoff aren't necessarily so in a wireless network, where packets can be lost without congestion. This means that TCP into, out of, or across, a MANET using TCP can be bad. It then tends to happen that the MANET people don't fully understand TCP, and the TCP people don't fully understand MANETs. I don't have a single good reference for what I say above, in particular have things got better (or worse) as TCP evolves, and therefore which references are still valid? But the obvious Google search (TCP MANET) throws up various discussions. -- Christopher Dearlove Senior Principal Engineer, Communications Group Communications, Networks and Image Analysis Capability BAE Systems Advanced Technology Centre West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK Tel: +44 1245 242194 | Fax: +44 1245 242124 chris.dearl...@baesystems.com | http://www.baesystems.com BAE Systems (Operations) Limited Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Centre, Farnborough, Hants, GU14 6YU, UK Registered in England & Wales No: 1996687 -Original Message- From: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On Behalf Of Martin Rex Sent: 05 March 2013 00:42 To: bra...@isi.edu Cc: ietf@ietf.org Subject: Re: congestion control? - (was Re: Appointment of a Transport Area Director) Bob Braden wrote: > On 3/4/2013 10:20 AM, Roger Jørgensen wrote: > > I'll ask a rather basic question and hope someone will answer in an > > educational way - Why is congestion control so important? And where > > does it apply? ... :-) > > Ouch. Because without it (as we learned the hard way in the late 1980s) \ > the Internet may collapse and provide essentially no service. It is PR like this one: http://www.fujitsu.com/global/news/pr/archives/month/2013/20130129-02.html That gets me worried about folks might try to "fix" the internet mostly due to the fact that they really haven't understood what is already there any why. -Martin This email and any attachments are confidential to the intended recipient and may also be privileged. If you are not the intended recipient please delete it from your system and notify the sender. You should not copy it or use it for any purpose nor disclose or distribute its contents to any other person.
RE: Appointment of a Transport Area Director
Ah, the 'but security, unlike transport, is actually important' argument. Having seen subscribers to that philosophy unsuccessfully attempt to design transport protocols (and raise the MD5 issue repeatedly, because it's considered a security issue, and they're at home with security), I would argue that there is a lack of appreciation and understanding of the nuances of transport protocol issues in the IETF. Reliability, implications of the end-to-end protocol, feedback loops... Today's crypto hash is tomorrow's probably-not-a-collision error detection, with no claims to security or protection against deliberate attacks. MD5 has made that transition, just because some collisions can be calculated. Better protocols will follow, because collisions will eventually be found. Considering entropy suggests this. Ethernet CRCs have collisions, but they have a useful role in error detection. Checksums are not secure, but that is not what they are used for. And they suffice for that purpose. No-one complains about Ethernet CRCs or one's complement checksums (OMG you can swap entire bvtes in TCP and just swap addresses and the echo server still works!) being insecure. Perhaps they still should. Being adequate for purpose is not enough if they're not secure! I find it difficult to care about the digest function fashion of the day. (For MD5, see RFC6151.) But watching security people make a hash of transport protocol design really isn't fun. That and the lack of transport expertise concerns me. Lloyd Wood http://sat-net.com/L.Wood/dtn > Congestion control is essential else we have congestive collapse, which > I have had to find and fix in my time; but I am positing that for most > of the IETF, congestion control is a solved topic and little expertise > is needed, in contrast to Security which is for ever changing (SHA2 or > SHA3 or will MD5 still suffice?). Yes, a high-level of skill exists, > especially in the ICCRG (and I struggle to follow it) but I wonder if we > need that skill in the IETF ie a basic familiarity with what TCP offers > and UDP does not will serve most of our work.
RE: congestion control? - (was Re: Appointment of a Transport Area Director)
3GPP has to never drop a packet because it's doing zero-header compression. Lose a bit, lose everything. And ROHC is an IETF product. I'm pretty sure the saving on headers is more than made up for in FEC, delay, etc. Not the engineering tradeoff one might want. Lloyd Wood http://sat-net.com/L.Wood/ From: ietf-boun...@ietf.org [ietf-boun...@ietf.org] On Behalf Of Masataka Ohta [mo...@necom830.hpcl.titech.ac.jp] Sent: 06 March 2013 11:37 To: ietf@ietf.org Subject: Re: congestion control? - (was Re: Appointment of a Transport Area Director) Cameron Byrne wrote: > In the 3GPP case of GSM/UMTS/LTE, the wireless network will never drop > the packet, by design. According to the end to end argument, that's simply impossible, because intermediate equipments holding packets not confirmed by the next hop may corrupt the packets or suddenly goes down. > It will just delay the packet as it gets > resent through various checkpoints and goes through various rounds of > FEC. The result is delay, Even with moderate packet drop probability, it means *A LOT OF* delay or connection oriented communication, either of which makes 3GPP mostly unusable. Masataka Ohta
RE: Thoughts from a past experimental Nomcom selection for TSV Area Director
David, Kudos on writing this up. The community would imo benefit from this experience being put into an internet draft with a view to informational RFC, for wider visibility. Lloyd Wood http://sat-net.com/L.Wood On Tue, Mar 12, 2013 at 04:41:43PM -0400, David Harrington wrote: > Hi, > > Many suggestions have been made about ways to resolve the issue of finding > suitable candidates for TSV Area Director, or adjusting the job to fit > available candidates. > > In 2010, I started as TSV AD, after the Nomcom had serious trouble filling > the TSV AD spot. I was encouraged to put my name in as a candidate since I > had solid IETF experience, even though I had no experience with the TSV > area. Interviewing for the position really confirmed for me how little I > knew about transport, so I was very surprised when I was nominated. > > After two years in that specific role, I have some insights I would like to > impart to the Nomcom and the community, and especially to any candidates for > the role who have never served on IESG. I'll repeat some of what has already > been suggested, but I'll try to put these things together to help explain > some contextual relationships that exist. > > I. the overall workload > > I found IESG/AD work to be a fulltime position, as in 100%. My first year, I > worked anywhere from 60 to 90 hours per week. Of course, I had a lot of > remedial learning to do; honestly, technical on-the-job training for a whole > area while working to perform your IESG review work and other AD tasks is a > tremendous burden. You won't do this in 50% of a normal work week. My second > year, I cut back the number of hours to 50-60 hours a week and took some > vacation time, so I could have a life beyond IESG, and the quality of my > work and my queue management suffered seriously as a result. YMMV. My main > concern is that a candidate with no area background can fall behind quickly, > and possibly never catch up fully within a two-year term. > > The workload has two parts - the IESG/steering/approval part, and the area > directing/managing part. I learned over time to split this generally by week > - one week IESG, the next week AD. Otherwise it becomes hard to prioritize > because it is very difficult to prioritize both (time-competing) parts > simultaneously, without favoring one or the other. The job requires you to > do both. > > II. workload - IESG > > IESG work requires review of about 15 documents every two weeks; those > documents come from anywhere in the IETF. Many of those documents require > the reviewer to understand the normative references upon which the document > is built. Internet standardization is now quite mature, and much of the new > standards work is dependent on older standards. I came from the SEC area and > the NM side of the OPS area, and those can be somewhat isolated from TSV, > INT, RAI, and routing. If your background has been limited to working in one > or two areas, you may need to learn a LOT about the technical developments > and the existing standards in the other areas. If you have been an active > reviewer in one or more directorates, and/or have previous IESG experience, > that should help a lot, but I still found it a challenge even after > experience in multiple directorates; when you do a security review of a > congestion control document, you look for security issues, not congestion > control issues. > > You'll need enough understanding of the TSV issues to be able to spot bad > transport-related decisions in documents coming from elsewhere in the IETF. > You (and your co-AD) are effectively the reviewer of last resort for TSV > issues. If you don't understand control loops, congestion control > techniques, etc., you will NEED to rely on your directorate for assistance > in this role. > > If you pride yourself on the thoroughness of your reviews, as I did, get > over it; you won't have time for thorough reviews. > > Some have commented on the "extra" stuff related to IESG work, such as > cross-SDO coordination, process tweaking, and so on. These definitely take > time, and they are important because that is part of the job. But other IESG > members can handle the bulk of this extra work while you're still learning > the area. > > III. workload - AD > > The AD for an area becomes the spokesman/shepherd for all documents coming > from their area. When you bring it to the IESG, you will be asked about the > quality of the document, the technical content, whether certain questions > were considered, what impact this might have to existing networks, how well > the document follows established guidelines for security, management, > operations, IANA assignments, XML usage, and so on. Y
RE: Getting rid of the dot
There's always some excuse as to why multi-homing is never done properly. On 03/19/13 20:38, Michael Richardson allegedly wrote: > Actually, I'd just settle for a badge that wasn't always > backwards. It costs a lot more to get lanyards that attach at two corners.
RE: Less Corporate Diversity
An ad-hominem argument, Melinda? really? Lloyd Wood http://sat-net.com/L.Wood/ From: ietf-boun...@ietf.org [ietf-boun...@ietf.org] On Behalf Of Melinda Shore [melinda.sh...@gmail.com] Sent: 21 March 2013 01:01 To: m...@sap.com Cc: ietf@ietf.org Subject: Re: Less Corporate Diversity On 3/20/13 4:51 PM, Martin Rex wrote: > I'm having difficulties to follow (but I'm also new to diversity discussions). > It is my understanding that work in the IETF is done by individual > participants within Working Groups or as individuals. Review seems to > happen within WGs, and the review work(load) seems to have significantly > shifted from ADs to Directorates. With all due respect, I can't find any RFCs you've authored or working groups you've chaired. Or, for that matter, any current internet drafts. I absolutely could have missed something and I hope that if I'm wrong you'll correct me. However, if I'm not wrong, you haven't been through the process of bringing work into the IETF, socializing it, and trying to get it published or adopted, in which case you're missing a lot. Melinda
RE: Less Corporate Diversity
Joel, the small shops you worked for were in the US, right? Lloyd Wood http://sat-net.com/L.Wood/ From: ietf-boun...@ietf.org [ietf-boun...@ietf.org] On Behalf Of Joel M. Halpern [j...@joelhalpern.com] Sent: 23 March 2013 03:24 To: Mark Prior Cc: John C Klensin; ietf@ietf.org Discussion; Eric Burger Subject: Re: Less Corporate Diversity I would have to disagree with: On 3/22/2013 11:17 PM, Mark Prior wrote: ... > > Hi John, > > I think that any small shop (whatever that means) would be put off if > they sent someone to an IETF as it appears that it is dominated by the > big vendors pushing their own agendas. Given that impression I imagine > the small shop has better things to do with its resources. > > Mark. > > While I work for a very large shop now, for most of my career I have worked for small or mid-size shops. Even startups. And all saw value in sending me to IETF meetings. Yours, Joel
RE: On the tradition of I-D "Acknowledgements" sections
Abusallam, if you want namecheck credit on an internet draft, may I suggest simply writing an internet draft yourself? (I would also recommend leaving writing drafts until after a PhD is complete; for the PhD, it's academic papers that matter.) Lloyd Wood http://sat-net.com/L.Wood/ _ From: ietf-boun...@ietf.org [ietf-boun...@ietf.org] On Behalf Of Abdussalam Baryun [abdussalambar...@gmail.com] Sent: 25 March 2013 06:02 To: melinda.shore Cc: ietf Subject: Re: On the tradition of I-D "Acknowledgements" sections Hi Melinda I like what we have so far, but are those connected processes/information reflected into the produced document? Why ignoring names of volunteers? I suggest to fix this, AB + We have the mailing list archives, we've got the document shepherd writeups, we've got the IESG evaluation record, we've got the IESG writeups, we've got meeting minutes, we've got jabber session archives, we've got audio recordings of meetings, and we've got the document history. Melinda >> So when I read a RFC I may go through the document process and its >> draft versions, while going through the drafts related I see >> acknowledged names so I may find the input on the list for such name. >> In this way we have connections between inputs otherwise the IETF >> system has no connection between its important information. >> >> AB >> >
RE: On the tradition of I-D "Acknowledgements" sections
RFCs say how, but rarely why. Lloyd Wood http://sat-net.com/L.Wood/ Elwyn said > As regards 'history': RFCs record 'state' and not history. That isn't
RE: On the tradition of I-D "Acknowledgements" sections
Actually, as there's already a five-author limit on RFCs, acks are already subject to guidance... Did rfc2223bis expire? Section 2.12 there. Lloyd Wood http://sat-net.com/L.Wood/ From: ietf-boun...@ietf.org [ietf-boun...@ietf.org] On Behalf Of Melinda Shore [melinda.sh...@gmail.com] Sent: 25 March 2013 16:20 To: Scott Brim Cc: John C Klensin; dcroc...@bbiw.net; ietf Subject: Re: On the tradition of I-D "Acknowledgements" sections On 3/25/13 8:17 AM, Scott Brim wrote: > or a statement that acknowledgments is not a required section and not > subject to IETF guidance. Excellent. Melinda
RE: It's a personal statement (Re: On the tradition of I-D "Acknowledgements" sections)
You mean going 'Chatham House rule'? (i'm just commenting on this thread so that when it results in an I-D recommending how to write acks, I get acked...) Lloyd Wood http://sat-net.com/L.Wood/ From: ietf-boun...@ietf.org [ietf-boun...@ietf.org] On Behalf Of Joel M. Halpern [j...@joelhalpern.com] Sent: 25 March 2013 16:35 To: Abdussalam Baryun Cc: Carsten Bormann; Paul Hoffman; ietf Subject: Re: It's a personal statement (Re: On the tradition of I-D "Acknowledgements" sections) It seems to me that you are setting up by assertion a standard that has never applied to this community. Having said that, if we want to go down this path, then we could do what groups like IEEE do. Remove all authors names, all personal acknowledgements, etc. The work is simply the product of the committee. I would prefer not to go down that path. But if the alternative is copying every name from every person reported to have commented on the draft in the minutes or shown in the archive to have sent an email about the draft into a meaningless acknowledgements section, then the pure committee view would seem more sensible. Yours, Joel On 3/25/2013 8:36 AM, Abdussalam Baryun wrote: > Hi Carsten, > > In general, I agree we don't force authors/owners of documents, as > tradition in the world and in all reasonable organisation, we never > force any author to be thankful. But don't forget the situation in > IETF is different and the documents are different as well. > > The document is a IETF document (not individual) and the authors are > not the only owners of the I-D as in other documents outside IETF (we > name them editors because IETF works/documents are shared for its > better publication not the authors' publication). The documents were > called for volunteers in IETF to participate and review, why the IETF > request that if it does not include them. > > In any I-D it is a personal statement for the IETF not the authors, > this is my beleive, otherwise why I should participate/volunteer if i > am not dealing with IETF business (don't want to participate in > private or public companies business), > > AB > > On 3/25/13, Carsten Bormann wrote: >>> Further, the IETF should acknowledge that the contents of Acknowledgments >>> sections varies widely between RFCs. Some are fairly complete, some are >>> fairly vague and incomplete, and some are between. >> >> Bingo. It is up to the sole discretion of the document authors what they >> want to list in the Acknowledgements section. >> >> Trying to force people to thank other people strikes me as completely >> misguided. >> >> (That said, as a contributor, I have certain expectations of document >> authors here, but these are *not* actionable in any sense.) As an author, I >> sometimes have forgotten to include people who made contributions worth a >> mention, and I would have been spared the shame if the contributor would >> have alerted me to that at the right occasion. As a contributor, I have >> never felt the need to pressure an author to include me, though. >> >> It does make sense to relay some common sense of what is expected in an >> Acknowledgements section to new authors. >> I don't know we do this at the moment. >> >>> If you feel like you should be listed in the Acknowledgements section of a >>> WG document due to your contribution, and you're not listed in WG Last >>> Call, ask the WG to be included. 'Nuff said. >> >> I'd modify this to "ask the authors". >> Ask, as in "shouldn't the Acknowledgement section be updated", not demand as >> in "I have an **g right to be in there". >> >> The contents of the Acknowledgment section is about as much subject to WG >> consensus as the authors' street addresses. >> >> Grüße, Carsten >> >>
RE: RFC 6921 on Design Considerations for Faster-Than-Light (FTL) Communication
Kids! Remember, if we're not bright enough to do physics, we can always do engineering, the slow younger brother of physics! But if engineering is too difficult, there's always computer science, where terms like "bandwidth" mean what we want them to mean. And if even that's too hard, there's always the arts-and-crafts knitted-my-own-shawl-or-at-least-drew-an-okay-pattern-for-it trade of 'Internet Engineering', and writing RFCs. And we can achieve that RFC goal easily by getting in the back door with an April 1 RFC! Every April 1 there's a reminder and inspiration to us all! Lloyd Wood http://sat-net.com/L.Wood/ Time's arrow is written >
RE: Comments for Humorous RFCs or uncategorised RFCs or dated April the first
All April 1 RFCs should not be categorised historical but Category: CLASSIFIED TOP SECRET EYES ONLY NEED TO KNOW SIPRNET COBRA VATICAN FNORD KNITTING PATTERN Distribution: Unlimited. We should also start a December 25 series. With something on SOCKS. Lloyd Wood http://sat-net.com/L.Wood/ From: ietf-boun...@ietf.org [ietf-boun...@ietf.org] On Behalf Of Elwyn Davies [elw...@dial.pipex.com] Sent: 06 April 2013 21:26 To: Stewart Bryant (stbryant) Cc: ietf; Abdussalam Baryun Subject: Re: Comments for Humorous RFCs or uncategorised RFCs or dated April the first Right.. they are mind expanding drugs. Essential for keeping us sane. /Elwyn Sent from my ASUS Pad "Stewart Bryant (stbryant)" wrote: > > >Sent from my iPad > >On 6 Apr 2013, at 14:04, "Abdussalam Baryun" >wrote: > >> >> If the date is >> special then thoes RFCs SHOULD be *historical*. >> > >Surely the correct requirement is : > >If the date is special then those RFCs MUST be *hysterical*. > >- Stewart > > > >
RE: Comments for Humorous RFCs or uncategorised RFCs or dated April the first
There's a lot of hysteresis... because calling it funny is often a stretch. Lloyd Wood http://sat-net.com/L.Wood/ From: ietf-boun...@ietf.org [ietf-boun...@ietf.org] On Behalf Of Scott Brim [s...@internet2.edu] Sent: 08 April 2013 20:34 To: Lucy Lynch Cc: ietf; Abdussalam Baryun Subject: Re: Comments for Humorous RFCs or uncategorised RFCs or dated April the first On 04/08/13 13:35, Lucy Lynch allegedly wrote: > On Mon, 8 Apr 2013, Wes Beebee (wbeebee) wrote: > >> >>> If the date is special then thoes RFCs SHOULD be *historical*. >> >> I thought they should be classified as "hysterical". > > there is an echo (echo) ((echo) ) in here (here) ((here)) IETF humor has lots of hysteresis.
RE: Purpose of IESG Review
+1 to Joe's comment. Example: the existence of the extensibility bit in multipath tcp, which i understand came out of a review by the iesg member responsible for security. In that context, that would be outside the scope of any security review, and the comments weren't raised in a personal capacity years earlier on the relevant mailing list. Sure, getting past iesg only cost multipath tcp a bit. But iesg members exceeding their bounds as reviewers and leaving a personal mark seems commonplace. iesg members are there for expertise in their area and to provide that expertise in focused reviews, not to block until a protocol is redesigned to suit their personal tastes. (That transport expertise is lacking on iesg last I looked and everyone believes they're an expert in transport - 'hey, why can't we just turn off udp checksums for sctp over udp? It's faster!' - another iesg redesign attempt overriding considered expertise of a workgroup - isn't helping here.) There are two examples I know of, off the top of my head, telated to transport because that's my area of interest. Can others provide further examples? Lloyd Wood http://sat-net.com/L.Wood/ From: ietf-boun...@ietf.org [ietf-boun...@ietf.org] On Behalf Of Paul Hoffman [paul.hoff...@vpnc.org] Sent: 11 April 2013 19:55 To: Joe Touch Cc: IETF discussion list Subject: Re: Purpose of IESG Review On Apr 11, 2013, at 10:54 AM, Joe Touch wrote: > As an author who has had (and has) multiple documents in IESG review, I've > noticed an increasing trend of this step to go beyond (IMO) its documented > and original intent (BCP 9, currently RFC 2026): > > The IESG shall determine whether or not a specification submitted to > it according to section 6.1.1 satisfies the applicable criteria for > the recommended action (see sections 4.1 and 4.2), and shall in > addition determine whether or not the technical quality and clarity > of the specification is consistent with that expected for the > maturity level to which the specification is recommended. > > Although I appreciate that IESG members are often overloaded, and the IESG > Review step is often the first time many see these documents, I believe they > should be expected to more clearly differentiate their "IESG Review" (based > on the above criteria) - and its accompanying Position ballot, with their > personal review. > > My concern is that by conflating their IESG position with their personal > review, the document process is inappropriately delayed and that documents > are modified to appease a small community that does not justify its position > as representative. > > How do others feel about this? That it is too vague to comment on? Please point to specific examples where you feel an IESG member's review went beyond determining the technical quality or clarity of the specification. That would help make the sure-to-be ensuing flamefest more light-filled. --Paul Hoffman
RE: Purpose of IESG Review
If you think security and congestion are arcane, you have... problems. This was an actual ietf working geoup, and not some e.g. W3c thing? Lloyd Wood http://sat-net.com/L.Wood/ From: ietf-boun...@ietf.org [ietf-boun...@ietf.org] On Behalf Of t.p. [daedu...@btconnect.com] Sent: 12 April 2013 21:52 To: Arturo Servin; ietf@ietf.org Subject: Re: Purpose of IESG Review - Original Message - From: "Arturo Servin" To: Sent: Friday, April 12, 2013 8:28 PM > > Not answering any particular post. Just a comment. > > The IESG should be there to attest that the IETF procedure was followed > and the document reached consensus in the WG and in the IETF LC and it > was successfully reviewed by the Gen-ART. If it wasn't then this > particular process should be reviewed and take actions accordingly (e.g. > returning the document to the wg). > > But if a single individual of the IESG can technically challenge and > change the work of a whole WG and the IETF, then we have something wrong > in our process because that means that the document had a serious > problem and we didn't spot it in the process or an IESG member is using > its power to change a document according to its personal beliefs. My experience has been the former, where the IESG has raised concerns about arcane topics, such as security and congestion, of which the WG had limited expertise. This might be caught by a directorate review, but those seem patchy; it might be caught by IETF Last Call, but if you are an expert at an arcane topic then you are probably too busy to follow them. So I do see the IESG DISCUSSing, when it would have been lovely to have had, but it is hard to see quite how, it resolved earlier. We just do not have the breadth of knowledge of arcane topics. Tom Petch > Just a thought, > as > > On 4/11/13 2:54 PM, Joe Touch wrote: > > Hi, all, > > > > As an author who has had (and has) multiple documents in IESG review, > > I've noticed an increasing trend of this step to go beyond (IMO) its > > documented and original intent (BCP 9, currently RFC 2026): > > > >The IESG shall determine whether or not a specification submitted to > >it according to section 6.1.1 satisfies the applicable criteria for > >the recommended action (see sections 4.1 and 4.2), and shall in > >addition determine whether or not the technical quality and clarity > >of the specification is consistent with that expected for the > >maturity level to which the specification is recommended. > > > > Although I appreciate that IESG members are often overloaded, and the > > IESG Review step is often the first time many see these documents, I > > believe they should be expected to more clearly differentiate their > > "IESG Review" (based on the above criteria) - and its accompanying > > Position ballot, with their personal review. > > > > My concern is that by conflating their IESG position with their personal > > review, the document process is inappropriately delayed and that > > documents are modified to appease a small community that does not > > justify its position as representative. > > > > How do others feel about this? > > > > Joe >
RE: IETF Diversity Question on Berlin Registration?
> Just think how much real-world networking and Internet work actually is > being done around the world still in small companies, for instance, in > addition to our large companies. Well, yes. I'm typing this in Tarawa where I've been upgrading the island's internet, and my chances of attending an IETF are rather slim. I'll just have to leave it to all you first-world western northern-hemisphere types, no matter how much diversity you lack, and how much transport perspective you need. Lloyd Wood http://sat-net.com/L.Wood/
RE: IETF Diversity Question on Berlin Registration?
I am deeply offended by your '5 continents' and lack of inclusiveness. Lloyd Wood http://sat-net.com/L.Wood/ I come from a land down under. From: ietf-boun...@ietf.org [ietf-boun...@ietf.org] On Behalf Of Abdussalam Baryun [abdussalambar...@gmail.com] Sent: 17 April 2013 05:51 To: ietf Subject: Re: IETF Diversity Question on Berlin Registration? >> My own feeling is that if we were to find that the >> numbers supported the notion that there's bias >> present in the system we probably couldn't do anything >> about it without tearing the organization apart, so, > > Is there a way to increase #countries #small companies #women etc? Be > it about the participants or the leadership. Could we set a goal that > we'll increase some aspect every year, 2014 to be better than 2013? > IMO we can do many thing about it, if we discuss these issues into an I-D. - There is a way to increase #women when they decide together as a group what is missing, and what should be done, - There is a way to increase #small companies when they are accepted/involved in IETF WGs documents. If individuals are encouraged then SMEs will be as well, - There is a way to increase #countries/states when each have their accepted access to the IETF WG system. I may suggest that each WG system to not only have two chairs, but also 5 administrated participants (for each continent, they may give chance to SMEs access and new I-Ds) that should look into the implementation/running-code of the IETF WG standards in real life. They can look into countries/states challenges/involvement in such work of the WG, to be documented if available. Countries will only increase-in/use IETF if their SMEs are using IETF systems. Now it seems that there are influences/directions from the industry/countries to IETF WGs' work but not seen/clear to others. For women, I think there must be at least 10% of women in the IETF leadership, as we should not ignore that many research/SMEs in industry are directed by women. They should publish an I-D related if they are interested. Is IETF still directed by men or both? AB
RE: The Purpose of WG participants Review (was Re: Purpose of IESG Review)
Not sure about the recognition for technical work. To progress technical work, you have to go to meetings. To progress in the IETF (chair, AD, IESG) you have to go to meetings. Keep turning up and don't be too obviously completely abysmal technically, and you can get a status dot on your badge. The IETF is run by goers, and goers like goers. Lloyd Wood http://sat-net.com/L.Wood/ From: ietf-boun...@ietf.org [ietf-boun...@ietf.org] On Behalf Of Dale R. Worley [wor...@ariadne.com] Sent: 17 April 2013 21:38 To: ietf@ietf.org Subject: Re: The Purpose of WG participants Review (was Re: Purpose of IESG Review) > From: Ted Lemon > > On Apr 16, 2013, at 11:51 AM, Dale R. Worley wrote: > > I've advocated the equivalent of the following opinion before > > (http://www.ietf.org/mail-archive/web/ietf/current/msg77479.html), but > > in the current context it bears repeating: Here in the IETF we accept > > that low-status people may argue regarding technical matters, but > > reserve for high-status people having opinions about our procedures. > > I thought your original message (the one you cite above) was very > good, but I'm not sure I like the terms "low-status" and > "high-status," simply because tey could be easily taken to mean > something other than what I think you intend them to mean. We do have a status system within the IETF and generally one gains status within that system by recognized technical work. And on certain sorts of issues, particularly changes in processes, we don't listen well to people who don't have high status within that system. In that regard, the IETF is far from egalitarian. In regard to diversity issues, it is important to ask whether position in the status system is directly affected by factors other than just technical contribution. Probably more important for diversity issues is that factors in a person's life other than their outright technical ability can strongly affect their ability to contribute to our technical work, and thus achieve the status needed to be influential. A more subtle problem is whether technical contribution correlates well the skills needed for leadership positions -- does being a quality technical contributor demonstrate the skills needed to be an effective IAB member? Although given the discussion around "IESG review", it seems that the reward for gaining the leadership position of IESG membership is becoming an extremely busy technical reviewer of standards... Dale
RE: The Purpose of WG participants Review (was Re: Purpose of IESG Review)
I've written RFCs without attending meetings; easy to do if the work is a aligned with a workgroup. That's fine if you're happy to be a technical resource with skills to be drawn upon for problems set by others. However, if you're sufficiently technical that you can set new technical directions that are outside the scope of existing wgs -- well, the political enters the technical, and you need to fake being a goer to build interest and support for the direction, eg by holding a bof. Many existing "managers" have run wgs, but have they even attempted to establish new technical directions? If not, they're just bureaucrats. Safe pairs of hands. And probably not that technical. Lloyd Wood http://sat-net.com/L.Wood/ From: Yoav Nir [y...@checkpoint.com] Sent: 18 April 2013 10:02 To: Wood L Dr (Electronic Eng) Cc: ; Subject: Re: The Purpose of WG participants Review (was Re: Purpose of IESG Review) Not entirely true. It is true that getting "management positions" (chairs, AD, NomCom) requires meeting attendance. But a non-attender can get recognition for quality technical points, and can even progress technical work. RFC 4478 was published long before I attended my first meeting. My own working group (WebSec) has document authors who never attend meetings. In other areas there are frequent and prolific contributors, who either never attended a meeting or have quit attending them years ago. Even the directorates have such people. So no, you probably can't get a dot for your badge without actually having one, but you can become "prominent" in the sense that people might say "this document hasn't had enough review. Let's ask so-and-so to read it", or "I'm putting together a design team for foo. Let's see if we can get so-and-so to join" Yoav On Apr 18, 2013, at 11:31 AM, l.w...@surrey.ac.uk wrote: > > Not sure about the recognition for technical work. > > To progress technical work, you have to go to meetings. To progress in the > IETF (chair, AD, IESG) you have to go to meetings. > > Keep turning up and don't be too obviously completely abysmal technically, > and you can get a status dot on your badge. > > The IETF is run by goers, and goers like goers. > > Lloyd Wood > http://sat-net.com/L.Wood/ > > > > From: ietf-boun...@ietf.org [ietf-boun...@ietf.org] On Behalf Of Dale R. > Worley [wor...@ariadne.com] > Sent: 17 April 2013 21:38 > To: ietf@ietf.org > Subject: Re: The Purpose of WG participants Review (was Re: Purpose of IESG > Review) > >> From: Ted Lemon >> >> On Apr 16, 2013, at 11:51 AM, Dale R. Worley wrote: >>> I've advocated the equivalent of the following opinion before >>> (http://www.ietf.org/mail-archive/web/ietf/current/msg77479.html), but >>> in the current context it bears repeating: Here in the IETF we accept >>> that low-status people may argue regarding technical matters, but >>> reserve for high-status people having opinions about our procedures. >> >> I thought your original message (the one you cite above) was very >> good, but I'm not sure I like the terms "low-status" and >> "high-status," simply because tey could be easily taken to mean >> something other than what I think you intend them to mean. > > We do have a status system within the IETF and generally one gains > status within that system by recognized technical work. And on > certain sorts of issues, particularly changes in processes, we don't > listen well to people who don't have high status within that system. > In that regard, the IETF is far from egalitarian. > > In regard to diversity issues, it is important to ask whether position > in the status system is directly affected by factors other than just > technical contribution. > > Probably more important for diversity issues is that factors in a > person's life other than their outright technical ability can strongly > affect their ability to contribute to our technical work, and thus > achieve the status needed to be influential. > > A more subtle problem is whether technical contribution correlates > well the skills needed for leadership positions -- does being a > quality technical contributor demonstrate the skills needed to be an > effective IAB member? Although given the discussion around "IESG > review", it seems that the reward for gaining the leadership position > of IESG membership is becoming an extremely busy technical reviewer of > standards... > > Dale > > Email secured by Check Point
RE: The Purpose of WG participants Review (was Re: Purpose of IESG Review)
and the point of your ad-hominem argument is what, exactly? Lloyd Wood http://sat-net.com/L.Wood/publications/internet-drafts From: Yoav Nir [y...@checkpoint.com] Sent: 18 April 2013 15:18 To: Wood L Dr (Electronic Eng) Cc: wor...@ariadne.com; ietf@ietf.org Subject: RE: The Purpose of WG participants Review (was Re: Purpose of IESG Review) Looking in Jari's statistics site, you have three RFCs. One of those has several co-authors that I recognize as current "goers". You also have a current draft with several co-authors, but I have no idea whether they're "goers" or not. Anyway, you are not a hermit. Through the RFCs and drafts that you have co-authored, you know people who do attend.
RE: IETF Diversity Question on Berlin Registration?
A statistician? This entire thread is basically arguing that the IETF needs a human resources department. Lloyd Wood http://sat-net.com/L.Wood/ From: ietf-boun...@ietf.org [ietf-boun...@ietf.org] On Behalf Of Brian E Carpenter [brian.e.carpen...@gmail.com] Sent: 18 April 2013 16:43 To: Pete Resnick Cc: ietf@ietf.org Subject: Re: IETF Diversity Question on Berlin Registration? On 18/04/2013 16:28, Pete Resnick wrote: ... > That's a factor of between 4 and 7 difference between an "eyeball" guess > and a rough calculation. I think that's likely an unintentional sampling > bias of your (and many other folks) eyeballs. And I think it's because > we have a tendency to subconsciously discount the numbers of people who > do not appear in leadership, or even simply don't behave "the way the > rest of us do". > > This isn't to say that we should spend all of our time on this question > by collecting statistics; that's just navel gazing. But we do want to > understand the nature of the problem and not let our guesses and > subconscious biases get in the way. Indeed. Ideally, though, we need a statistician to look at the historical ratios (e.g. M/F ratios) in the attendee lists vs the I* membership, to see whether there is a statistically significant bias in the selection process over the years. Brian
RE: IETF Diversity Question on Berlin Registration?
Female ADs include Allison Mankin, whose bio recently appeared on this list in relation to her new appointment. There's now a diversity discussion list, where this discussion should move to. http://www.ietf.org/blog/2013/04/diversity/ Does what you think matter, when you clearly don't know anything? Lloyd Wood http://sat-net.com/L.Wood/ From: ietf-boun...@ietf.org [ietf-boun...@ietf.org] On Behalf Of Abdussalam Baryun [abdussalambar...@gmail.com] Sent: 19 April 2013 10:37 To: a...@anvilwalrusden.com Cc: ietf Subject: Re: IETF Diversity Question on Berlin Registration? Andrew >Because some people report that they experience a chilly environment, and we respect those people for their other contributions and would like more people like them to contribute in similar ways, and therefore we want to make the environment less chilly. I'm sort of surprised that that problem, which has been stated in my view quite plainly more than once in this thread, isn't evident to anyone participating. The environment may not be chilly, but may be unaware of experience (did we experience a woman as AD?). The IETF culture can be defined IMO as a argumental experience (firstly) plus technical (secondly), mostly men argue for long (may get unsensitive) but women may not fancy that. The participants' bias is not in technical experience it is in argumental, which is not true that all discussions on the IETF lists are technical, most of the time just men arguing and when they get lost in technical they get backed up with the consensus procedural argument. I don't think women were given a chance to proof their ability to lead the IETF, so men can be aware of new experience. AB
RE: The Purpose of WG participants Review (was Re: Purpose of IESG Review)
And the technology that my team is pushing would be Saratoga: http://saratoga.sf.net which has interoperable implementations that can do 50Mbps in perl, a decade of operational experience in its application domain, and mature drafts. But this is in the transport area, and TSV has somewhat limited resources, so it's outside the span of attention from a wg. But still worth documenting as experimental. Lloyd Wood http://sat-net.com/L.Wood/ From: Yoav Nir [y...@checkpoint.com] Sent: 19 April 2013 10:02 To: Wood L Dr (Electronic Eng) Cc: ; Subject: Re: The Purpose of WG participants Review (was Re: Purpose of IESG Review) Only that you know enough people so that you could push a new technology even without attending, although you would need to collaborate with some people who do go. But pushing a new technology requires team building anyway. The same should apply to other non-attenders who have gained some reputation. On Apr 19, 2013, at 11:23 AM, l.w...@surrey.ac.uk wrote: > > and the point of your ad-hominem argument is what, exactly? > > Lloyd Wood > http://sat-net.com/L.Wood/publications/internet-drafts > > > > From: Yoav Nir [y...@checkpoint.com] > Sent: 18 April 2013 15:18 > To: Wood L Dr (Electronic Eng) > Cc: wor...@ariadne.com; ietf@ietf.org > Subject: RE: The Purpose of WG participants Review (was Re: Purpose of IESG > Review) > > Looking in Jari's statistics site, you have three RFCs. One of those has > several co-authors that I recognize as current "goers". You also have a > current draft with several co-authors, but I have no idea whether they're > "goers" or not. Anyway, you are not a hermit. Through the RFCs and drafts > that you have co-authored, you know people who do attend.
RE: The Purpose of WG participants Review (was Re: Purpose of IESG Review)
Yoav, Yes, Saratoga started as a draft in the DTNRG (draft-wood-tsvwg-saratoga). We carried the first bundles from space in 2008, and used our experience to analyse failings in the bundle protocol. (See our "A bundle of problems" paper.) Unfortunately, DTNRG wasn't chartered to do DTN research. It was chartered to do only development of the bundle protocol as the one true solution to DTNs, whick it wasn't. In any case, IRTF groups can't standardise anything, just produce experimental RFCs (though CCSDS was pushing for standardising bundling for itself last I looked.) Lloyd Wood http://sat-net.com/L.Wood/dtn From: Yoav Nir [y...@checkpoint.com] Sent: 22 April 2013 16:15 To: Wood L Dr (Electronic Eng) Cc: ; Subject: Re: The Purpose of WG participants Review (was Re: Purpose of IESG Review) Well, there isn't a delay tolerant networks working group, but the IRTF has a DTNRG ( http://irtf.org/dtnrg ). At least one of the chairs is a "goer". If you really wanted to standardize this, wouldn't you be able to find 1-2 people on the DTNRG list who would be willing to "do the BoF thing"? I'm not saying this is definitely what you should do. There are plenty of reasons to bring something to the IETF and to not bring it. I'm only saying that it is possible. Yoav On Apr 22, 2013, at 3:12 PM, l.w...@surrey.ac.uk wrote: > And the technology that my team is pushing would be Saratoga: > http://saratoga.sf.net > which has interoperable implementations that can do 50Mbps in perl, a decade > of operational experience in its application domain, and mature drafts. > > But this is in the transport area, and TSV has somewhat limited resources, so > it's outside the span of attention from a wg. But still worth documenting as > experimental. > > Lloyd Wood > http://sat-net.com/L.Wood/ > > > > From: Yoav Nir [y...@checkpoint.com] > Sent: 19 April 2013 10:02 > To: Wood L Dr (Electronic Eng) > Cc: ; > Subject: Re: The Purpose of WG participants Review (was Re: Purpose of IESG > Review) > > Only that you know enough people so that you could push a new technology even > without attending, although you would need to collaborate with some people > who do go. But pushing a new technology requires team building anyway. > > The same should apply to other non-attenders who have gained some reputation. > > > On Apr 19, 2013, at 11:23 AM, l.w...@surrey.ac.uk wrote: > >> >> and the point of your ad-hominem argument is what, exactly? >> >> Lloyd Wood >> http://sat-net.com/L.Wood/publications/internet-drafts >> >> >> >> From: Yoav Nir [y...@checkpoint.com] >> Sent: 18 April 2013 15:18 >> To: Wood L Dr (Electronic Eng) >> Cc: wor...@ariadne.com; ietf@ietf.org >> Subject: RE: The Purpose of WG participants Review (was Re: Purpose of IESG >>Review) >> >> Looking in Jari's statistics site, you have three RFCs. One of those has >> several co-authors that I recognize as current "goers". You also have a >> current draft with several co-authors, but I have no idea whether they're >> "goers" or not. Anyway, you are not a hermit. Through the RFCs and drafts >> that you have co-authored, you know people who do attend. > > > Email secured by Check Point
RE: Language editing
http://labs.apnic.net/blabs/?p=309 an excellent detective story on badly-written, poorly edited, standards track RFCs leading to interop problems. Enjoy. Lloyd Wood http://sat-net.com/L.Wood/ Technical writer and editor, native English speaker, IELTS score of 9.0, vaguely appalled by this discussion. From: ietf-boun...@ietf.org [ietf-boun...@ietf.org] On Behalf Of John C Klensin [john-i...@jck.com] Sent: 05 May 2013 19:32 To: Brian E Carpenter; Yaron Sheffer Cc: ietf@ietf.org Subject: Re: Language editing --On Saturday, May 04, 2013 10:04 +1200 Brian E Carpenter wrote: > On 04/05/2013 09:22, Yaron Sheffer wrote: >> GEN-ART is a good example, but actual document editing is >> much more work and arguably, less rewarding than a review. So >> I think this can only succeed with professional (=paid) >> editors. > > I think I disagree, if we can find the knack of effective > crowd-sourcing. We do after all have several hundred native > English speakers active in the IETF, which would mean each one > would have to volunteer for less than one draft per year and > we'd be done. And what we have found more times than I care to think about -- and I've found even more times than that when trying to read undergraduate papers -- is that "native English speaker" does not imply "ability to write good, clear, coherent technical English". In addition, the IETF includes a reasonable number of people whose first language is not English but whose ability to write high-quality technical documents in English generally exceeds that of our typical native speaker. So my first concern is that we not start making plans based on the population of native speakers -- if we are going to find volunteers to pretend to be technical editors, or assess the population of such people, we had better base our assumptions on the right set of skills. > I don't know how much experience you have with professional > editors. Apart from the RFC Editor crew, my experience has > been "mixed". Somebody a year or three ago (the last time we > had this exact same discussion) pointed out the differences > between copy-editors and technical editors. One difference is > that the latter are much more expensive. Copy-editors tend to > be rule-driven; technical editors are supposed to understand > the material. To be a little more precise, technical editors are supposed to understand the nature of technical documents, to have good intuitions about what is clear and precise and what isn't, and so on. Specific subject-matter expertise is yet another layer of requirement and something we would be unlikely to find far outside the relevant WG or Area. I think the distinction between copy editors and technical editors is very significant (and I might have been the one who made the comment to which you refer). But one should not confuse that distinction with the observation that there are probably as large a proportion of poor editors who can't deal with material that requires some skill (in either subcategory) in the world as there are poor engineers who can't competently handle actual systems design issues. Having shepherded (and kicked, clawed, and dragged) a number of documents through the system in the last few years that were written by people whose engineering and protocol design skills far exceeded their [English] technical writing skills, I'm less optimistic about volunteer editing than several others seem to be. If a WG has surplus people with good technical editing skills to pair with authors who may be better about the technical details or tracking the WG discussions and getting them into to document, then that is great. But I have certainly worked in or chaired WGs when there are no such people to spare or who will volunteer. In addition, it is really hard for someone who cares enough about the subject matter of the WG to be able to edit or translate a draft into good, clear, technical English without injecting their own opinions about areas where the original I-D may be unclear -- perhaps it is even harder than writing the document with careful attention to WG consensus. My guess is that we are going to need a mixed strategy that involves volunteer (and adequately skilled) editors where we can find them, professional technical editors where necessary (and a good model for how they get paid), and oversight of the whole process by the RFC Editor as well as relevant WG Chairs, ADs, and the IESG. We are also going to need to be much more clear about what level of quality we, as a community (not just the IESG), want and will insist on before a document goes into Last Call. I've always hoped that the standard could be "absolutely clear about what is being specified, but everything else can be fixed by the RFC Editor after approval". But that req
RE: Gather Profiles/Resumes [was Re: call for ideas: tail-heavy IETF process]
You want resumes? You've got linkedin for that. The sort of thing Doug describes is actually quite common. For example, I once had a group chair threaten to have me disciplined by the company I worked for, for pointing out the technical failings of his pet protocol. The IETF isn't a lovey-dovey bunch of hippies working in harmony for humanity. The IETF is hardball. Lloyd Wood http://sat-net.com/L.Wood/ From: ietf-boun...@ietf.org [ietf-boun...@ietf.org] On Behalf Of Doug Ewell [d...@ewellic.org] Sent: 15 May 2013 22:28 To: ietf@ietf.org Subject: Re: Gather Profiles/Resumes [was Re: call for ideas: tail-heavy IETF process] John C Klensin wrote: > I think it is all very well to ask for affiliations in principle > and, also in principle, I agree that it is a good idea. But, in > practice, I think there are a lot of clarifications and other > changes that would be required and that might or might not be > practical. I used the term "Consultant" in RFCs 4645 and 5645, instead of revealing the name of my company (which was different each time, and neither of which contributed any time or money to my WG effort). I did this because the WG at the time included a malicious contributor who had already contacted the HR department of another contributor's employer, asking them to professionally discipline the employee, because he had supported an RFC 3683 PR-action against the first contributor. Full disclosure can be a dangerous thing. -- Doug Ewell | Thornton, CO, USA http://ewellic.org | @DougEwell
RE: Is this an elephant? [Was: call for ideas: tail-heavy IETF process]
> I already requested before that all WGs SHOULD > discuss their milestones and update it in each > meeting or on the list. No-one cares what you requested. Didn't you get banned from the MANET list for lack of useful content? Lloyd Wood http://sat-net.com/L.Wood
RE: IETF Meeting in South America
> Any sense of why that didn't happen with Australians after > the Adelaide meeting? The centres for networking industry in Australia are Melbourne and Sydney, in that order. It's a bit like IETF 51 being held in Grimsby, not London or Cambridge. Lloyd Wood http://sat-net.com/L.Wood
RE: IETF Meeting in South America
Melinda, can you confine yourself to disagreeing with something I actually said? Thanks so much! Lloyd Wood http://sat-net.com/L.Wood/ From: ietf-boun...@ietf.org [ietf-boun...@ietf.org] On Behalf Of Melinda Shore [melinda.sh...@gmail.com] Sent: 29 May 2013 03:47 To: ietf@ietf.org Subject: Re: IETF Meeting in South America On 5/28/13 6:27 PM, Arturo Servin wrote: > Going to Buenos Aires, Sao Paulo, Mexico City or Santiago will always > split audiences as these are the major tech hubs in the region (also add > Bogota, Lima, San Jose and other cities). So, I think it is not > comparable with Australia. I actually don't agree with Lloyd that the reason that the Australian meeting didn't lead to increased Australian participation was that it was because it was in Adelaide. I don't expect a South American meeting in any South American city to lead to an increase in Latin American participation, either. Melinda
RE: Participation per Region of Authoring IETF documents vs Marketing
http://www.arkko.com/tools/recrfcstats/d-contdistr.html (Jari, what time period is that across? Oceania doesn't rate a mention...) 11 RFCs (0.73%) have authors from South America. http://www.arkko.com/tools/allstats/fernandogont.html This author is in Argentina (as of 2013) Fernando has the following 12 RFCs This suggests that itr would be efficient for the IETF to fund travel and support for Fernando, who I've met at IETF meetings, rather than fund an IETF meeting in Fernando's neighbourhood (consistently Haedo, Provincia de Buenos Aires - address is a better guide than affiliation). Lloyd Wood http://sat-net.com/L.Wood/ From: ietf-boun...@ietf.org [ietf-boun...@ietf.org] On Behalf Of Mark Nottingham [m...@mnot.net] Sent: 30 May 2013 01:45 To: Abdussalam Baryun Cc: ietf Subject: Re: Participation per Region of Authoring IETF documents vs Marketing I would take those numbers with a HUGE grain of salt (as Jari documents). For example, I've lived in Australia since 2006, and yet am only listed as producing RFCs in the USA. Regards, On 30/05/2013, at 10:39 AM, Abdussalam Baryun wrote: > Hi Lars, > > It was for Asia region, I thought its rate is between (5 - 50) > rfc/year for last 3 years. Basing on; The first figure of RFCs is the > Comparison of countries over the year [1], the second, is the > Distribution of number of RFCs per continent [2], the third is > publication rate per year [3]. For the I-Ds going in IETF is seen from > the distribution of drafts according to the countries of their authors > [4] and [5]. All figures make together the below conclusions, even > though some of them need more details for readers to understand. > > As from Figure [1] always one region (North America) is doing about > 200 rfc/year and the each of others may do between 5 - 50 rfc/year or > 50-100, but all together other regions do 150 rfc/year, so total > ietf-participation can be about 350 rfc/year. The Figure [2] is not > reasonable, not showing of years or period of such numbers. > > So my understanding is that for Europe-region and Asia-region, the > number of I-Ds rates are high compared to North America, but not the > rate of RFCs. I see that the total RFCs ietf-output rate (RFC/year) as > in Figure [3] for the last three years is about 350 rfc/year, so if > North America is having 200, the all others only will have about 150 > rfc/year. The total RFCs produced per countries is in Figure [6] is > reasonable but if compared with Figure [2] I get lost. > > From Figure [5] (also [4]) the number of I-Ds (now currently 2013 > outstanding) from Asia and Europe are about 600 and 1200 respectively > (let us add them up so =1800 ids), which I think only about 150 will > succeed (non-North America drafts). Furthermore, for North America the > I-Ds are 1500 ids and only 200 ids will succeed to become RFCs. I > think that Asia and Europe should have together about 250/year rfc not > 150 rfc/year. If we do more MARKETING effort we can make that rfc-rate > of other regions increase, but we already tried to increase North > America rate but it is stable for about 200 rfc/years. > > [1] http://www.arkko.com/tools/rfcstats/countrydistrhist.html > [2] http://www.arkko.com/tools/recrfcstats/d-contdistr.html > [3] http://arkko.com/tools/rfcstats/pubdistr.html > [4] http://www.arkko.com/tools/stats/d-countrydistr.html > [5] http://www.arkko.com/tools/stats/d-countryeudistr.html > [6] http://www.arkko.com/tools/rfcstats/d-countrydistr.html > > This lower participation from regions like Asia will continue because > most meeting are in North America, or most participants from North > America prefer to have face-face meeting locally, than to be remote to > other regions (not reasonable because they are writers in English very > well). Also other regions participants prefer to participate in > meetings not remotely (but that is reasonable because they are not > good in English Language Writting). It is also important that some > IETF management visit the other region participants for the progress > of their I-Ds. > > Please note that I don't claim that my analysis is all correct, but > trying to discuss it and get others to analyse as well or comment on > the figures/statistics. If you disagree or have any comment please > reply/advise. Thanking you, > > AB > > > On Wed, May 29, 2013 at 10:53 AM, Eggert, Lars wrote: >> >> Hi, >> >> On May 28, 2013, at 19:46, Abdussalam Baryun >> wrote: >>> by looking into the statistics of I-Ds and RFCs, it is strange that we get >>> sometimes high rate in the I-D going in IETF from some regions but the >>> success rate of I-Ds to become RFCs is very low (5- 50). >> >> which IDs and RFCs are you basing this statement on? >> >> Thanks, >> Lars -- Mark Nottingham http://www.mnot.net/
RE: [IETF] Re: Issues in wider geographic participation
Melinda Shore, all at sea: > Here in Alaska was the first time I'd worked in an environment > that had technologists at a considerably less than elite skill > level, and I'd previously had no idea the extent to which > average operators/data centers rely on vendors (worse: VARs > and consultants) to solve their technical problems. You'd love the Pacific. Few IETFers get exposed to these kinds of environments. Lloyd Wood http://sat-net.com/L.Wood/
RE: Time in the Air
clearly, all IETF meetings should be in Cape Town, Wellington, or Perth, because more time in the air means more time without interruption where drafts can be read before the meeting. quiet time on a plane can be productive time. Lloyd Wood http://sat-net.com/L.Wood/ From: ietf-boun...@ietf.org [ietf-boun...@ietf.org] On Behalf Of Mark Nottingham [m...@mnot.net] Sent: 31 May 2013 10:59 To: ietf Discussion Subject: Time in the Air In an attempt to inject some data into the discussion, I wrote a bit of code that figures out how much time, given your home city, you would have spent in the air if you'd attended all IETF meetings since IETF74 (i.e., from 2009 onwards). The first column is the "home" airport. The second column is the great circle time between the home airport and the nearest large airport to the IETF meeting, hhh:mm. This doesn't count things like transit time, taxiing, takeoff and landing overhead, indirect routing, etc. As such, this is an ideal number; the only way to achieve anything close to it is to have a private jet (with exceptional range). The third column is the time (hhh:mm) using the shortest-time routing on a travel booking engine. This is first-takeoff-to-last-landing time. Both numbers assume round trip between "home" and the IETF airports. SFO 204:10 282:04 // San Francisco BOS 197:42 297:38 // Boston ATL 205:44 297:28 // Atlanta ANC 197:12 345:54 // Anchorage LHR 198:02 249:44 // London FRA 202:10 255:22 // Frankfurt FCO 223:52 283:04 // Rome SVO 211:28 287:14 // Moscow TLV 264:12 334:22 // Israel DXB 293:26 344:34 // Dubai NRT 259:00 314:38 // Tokyo HKG 296:38 359:22 // Hong Kong BLR 332:28 448:24 // Bangalore MEL 450:28 556:04 // Melbourne AKL 442:24 569:04 // Auckland JNB 414:30 498:22 // Johannesburg EZE 411:10 522:56 // Buenos Aires GIG 381:56 488:32 // Rio de Janeiro Draw your own conclusions, of course. One observation is that there's a 3+ days-in-the-air per year variance if you're a full-time participant, depending on where you live. I.e., more than one day-per-meeting difference, on average. In the air alone. Another is that, perhaps surprisingly, the "closest" homes to all meetings are in Europe, not the US (at least by shortest-time routing). I can run other airports upon request, as well as make source available, but will do so conservatively, so as not to incur the ire of the services I'm (ab)using. Regards, P.S. The IETF airports chosen were: IETF_airports: [ "ORL", "ATL", "YVR", "CDG", "TPE", "YQB", "PRG", "PEK", "AMS", "LAX", "HIJ", "ARN", "SFO" ], -- Mark Nottingham http://www.mnot.net/
RE: Time in the Air
"Always Europe gets better results because it is the favoriate meeting-location
for ALL
businesses"
{{citation needed}}
Lloyd Wood
http://sat-net.com/L.Wood/
From: ietf-boun...@ietf.org [ietf-boun...@ietf.org] On Behalf Of Abdussalam
Baryun [abdussalambar...@gmail.com]
Sent: 01 June 2013 11:18
To: Mark Nottingham
Cc: ietf Discussion
Subject: Re: Time in the Air
Thanks Mark,
This is very interesting results, it is ok if not 100% correct which I
think the error can be less than 10%, but I may have different
analysis of results. You concluded that homes in Europe had better
shortest distances to IETF meetings (assuming that thoes homes have
full participation of all meeting from 2009). Always Europe gets
better results because it is the favoriate meeting-location for ALL
businesses, but hope that IETF changes most of its meetings in Europe
which will serve all. I will post in future another message of my
opinion of a best practice of meeting locations which may become a
good I-D start (but need your assistance and your data results)
My analysis will discover that the past locations of IETF meetings
(from 2009 until now) does not serve-best the majority of full
attendance-participants of IETF from all regions. Thoes past locations
serve only regional-meeting-participants.
My analysis discovers that there is not close air-time-results when
comparing between homes/regions, the results variances between home
cities are large.
Overall, I suggest to consider the number of participants that are
full time attendance in all most meetings 90% attendance (not 75%).
Also to consider the number of past attendance of meetings in Europe
and Asia (there are large differents I think). These two
considerations will show that past locations of meetings did not serve
better the IETF but served some regional-interests. IMHO, two meetings
in Europe per year is a better practice for IETF activities.
AB
On 5/31/13, Mark Nottingham wrote:
> In an attempt to inject some data into the discussion, I wrote a bit of code
> that figures out how much time, given your home city, you would have spent
> in the air if you'd attended all IETF meetings since IETF74 (i.e., from 2009
> onwards).
>
> The first column is the "home" airport.
>
> The second column is the great circle time between the home airport and the
> nearest large airport to the IETF meeting, hhh:mm. This doesn't count things
> like transit time, taxiing, takeoff and landing overhead, indirect routing,
> etc. As such, this is an ideal number; the only way to achieve anything
> close to it is to have a private jet (with exceptional range).
>
> The third column is the time (hhh:mm) using the shortest-time routing on a
> travel booking engine. This is first-takeoff-to-last-landing time.
>
> Both numbers assume round trip between "home" and the IETF airports.
>
> SFO 204:10 282:04 // San Francisco
> BOS 197:42 297:38 // Boston
> ATL 205:44 297:28 // Atlanta
> ANC 197:12 345:54 // Anchorage
> LHR 198:02 249:44 // London
> FRA 202:10 255:22 // Frankfurt
> FCO 223:52 283:04 // Rome
> SVO 211:28 287:14 // Moscow
> TLV 264:12 334:22 // Israel
> DXB 293:26 344:34 // Dubai
> NRT 259:00 314:38 // Tokyo
> HKG 296:38 359:22 // Hong Kong
> BLR 332:28 448:24 // Bangalore
> MEL 450:28 556:04 // Melbourne
> AKL 442:24 569:04 // Auckland
> JNB 414:30 498:22 // Johannesburg
> EZE 411:10 522:56 // Buenos Aires
> GIG 381:56 488:32 // Rio de Janeiro
>
> Draw your own conclusions, of course.
>
> One observation is that there's a 3+ days-in-the-air per year variance if
> you're a full-time participant, depending on where you live. I.e., more than
> one day-per-meeting difference, on average. In the air alone.
>
> Another is that, perhaps surprisingly, the "closest" homes to all meetings
> are in Europe, not the US (at least by shortest-time routing).
>
> I can run other airports upon request, as well as make source available, but
> will do so conservatively, so as not to incur the ire of the services I'm
> (ab)using.
>
> Regards,
>
> P.S. The IETF airports chosen were:
>
> IETF_airports: [
> "ORL",
> "ATL",
> "YVR",
> "CDG",
> "TPE",
> "YQB",
> "PRG",
> "PEK",
> "AMS",
> "LAX",
> "HIJ",
> "ARN",
> "SFO"
> ],
>
> --
> Mark Nottingham http://www.mnot.net/
>
>
>
>
RE: I-D Action: draft-crocker-id-adoption-02.txt
I'd argue that the draft also needs to discuss IRTF processes, such as they are. though the IRTF groups are sufficiently similar to IETF WGs that you might think the same processes apply, having a draft being adopted by an IRTF group means far less, for example, and there appear to be other differences. At the very least, a 'this doesn't cover IRTF research groups, where practices very widely' is needed. Lloyd Wood http://sat-net.com/L.Wood/ From: ietf-boun...@ietf.org [ietf-boun...@ietf.org] On Behalf Of Brian E Carpenter [brian.e.carpen...@gmail.com] Sent: 03 June 2013 00:27 To: IETF discussion list Subject: Re: I-D Action: draft-crocker-id-adoption-02.txt Hi, My main positive comment is that it's a good idea to document guidelines in this area, and that (viewed as guidelines) I largely agree with the draft. My main negative comment is that although the draft says it's not a formal process document, its language in many places belies that. For example: > 2. Adoption Process > > > 2.1. Formal Steps > > >To adopt a new working group document, the chairs need to: would be better phrased as: 2. Adoption Guidelines 2.1. Typical Steps To adopt a new working group document, the chairs often: I'd suggest a careful pass through the text, removing instances of words like "process", "formal" and "need", and emphasising words like "guideline" and "typical" and "might". Now some minor comments: >The convention for >identifying an I-D formally under the ownership of a working group is >by the inclusion of "ietf" in the second field of the I-D filename >and the working group name in the third field, It's a useful convention but *not* a requirement afaik. >Note >that from time to time a working group will form a design team to >produce the first version of a working group draft. I think that's slightly wrong. A design team draft is *not* automatically a WG draft. I think this is more accurate: Note that from time to time a working group will form a design team to produce the first version of a document that may be adopted as a working group draft. That's an important difference - we've seen cases where design teams falsely believed that they had been delegated authority by the WG. > * Is there strong working group support for the draft? I think that's going a bit far. Actually a WG might adopt a draft because there is support for the *topic* but not for the details of the draft as it stands. Indeed, one objective of adopting a draft is so that the WG as a whole obtains control of the contents - so that they can change it. > * What is the position of the working group chairs, concerning > the draft? > > [[editor note: I am not sure this is relevant. Indeed is > might be specifically not relevant. /a]] Actually I'd go the other way: the WG chairs' job at that point is to judge the WG's opinion of the draft, not their own opinion. (At least once, as a WG chair, I had to declare adoption of a draft to which both I and my co-chair were strongly opposed.) > 5.1. Individual I-Ds Under WG Care ... OK, but there are in fact four possible outcomes for such a draft 1. As you describe; 2. The document proceeds as an individual submission to the IESG without continued WG discussion; 3. The document proceeds as an Independent Submission to the RFC Editor; 4. The document is abandoned. Regards Brian
RE: Call for Review of draft-iab-rfc4441rev-04.txt, "The IEEE 802 / IETF Relationship"
> Is the IETF a task force of the Internet Society? RFC2031 documented the takeover. Snuck through on informational... Lloyd Wood http://sat-net.com/L.Wood/ From: ietf-boun...@ietf.org [ietf-boun...@ietf.org] On Behalf Of SM [s...@resistor.net] Sent: 06 June 2013 02:07 To: i...@iab.org Cc: ietf@ietf.org Subject: Re: Call for Review of draft-iab-rfc4441rev-04.txt, "The IEEE 802 / IETF Relationship" At 11:50 05-06-2013, IAB Chair wrote: >This is a call for review of "The IEEE 802 / IETF Relationship" >prior to potential approval as an IAB stream RFC. In Section 1: "This document contains a set of principles and guidelines that serves as the basis for establishing collaboration between Project 802 of the Institute of Electrical and Electronics Engineers (IEEE 802) and the Internet Engineering Task Force (IETF) of the Internet Society (ISOC)" Is the IETF a task force of the Internet Society? In Section 3.1.2: "4. Appointment of RFC Series and Internet Assigned Number Authority (IANA) roles" What is the meaning of IANA roles in the above? In Section 3.1.4 "Voting: Both organizations use voting as a decision-making tool, but IEEE 802 uses voting within working groups, while IETF working groups do not use voting. Working group chairs may ask for a "show of hands" or "take a hum" to judge backing for a proposal, but this is not considered to be "voting" - The IESG does ballot documents when considering them for publication. This balloting is a final approval for publication." The first part of the text says that the IETF uses voting whereas the "hum" is not considered as "voting". "Decision-making" might be a better label. Regards, -sm
RE: Call for Review of draft-iab-rfc4441rev-04.txt, "The IEEE 802 / IETF Relationship"
> Asking IETF WG chairs to deal with passwords is a bit silly. Maybe they could be emailed a monthly reminder of their personal subscription password on the first of each month. Lloyd Wood http://sat-net.com/L.Wood/ From: ietf-boun...@ietf.org [ietf-boun...@ietf.org] On Behalf Of Stephen Farrell [stephen.farr...@cs.tcd.ie] Sent: 06 June 2013 14:12 To: IAB Chair Cc: IAB; IETF Subject: Re: Call for Review of draft-iab-rfc4441rev-04.txt, "The IEEE 802 / IETF Relationship" A couple of minor comments: - For some unfathomable reason IEEE people seem to call mailing lists "reflectors" - that might be worth a mention. Section 4 otherwise seems repetitive. - 3.3.1.4 says: Since it is possible to participate in IETF without attending meetings, or even joining a mailing list, IETF WG chairs will provide the information to anyone who requests it. However, since IEEE 802 work-in-progress is copyrighted, incorporating material into IETF documents or posting the username/password on mailing lists or websites is not permitted. That's a pretty bogus setup. I would think that if IEEE do want to share some or all drafts with us they could much more easily create a web page when those drafts are available without access control. Or we could if they didn't mind. (Or I could do it if there's no "we" that wants to:-) Asking IETF WG chairs to deal with passwords is a bit silly. I'm not objecting to this, but am suggesting someone ask IEEE if they'd like to consider the silliness here and fix it. S. On 06/05/2013 07:50 PM, IAB Chair wrote: > This is a call for review of "The IEEE 802 / IETF Relationship" > prior to potential approval as an IAB stream RFC. > > The document is available for inspection here: > https://datatracker.ietf.org/doc/draft-iab-rfc4441rev/ > > The Call for Review will last until 20 June 2013. > Please send comments to i...@iab.org. > > On behalf of the IAB, > Russ Housley > IAB Chair > >
RE: Best list for IETF last calls [was: Weekly posting summary for ietf@ietf.org]
I believe that last calls must stay on this ietf list. Any last-call-only list must be *in addition* to the ietf list, with all announcements crossposted, and anyone sensitive to general discussion can subscribe to that instead. Last calls need wide exposure. (I'm acked in at least one RFC as a result of discussion on this list as a result of last call.) I'd go further and say that if you're contributing to an ietf workgroup, subscribing to ietf and ietf-announce should be mandatory for posting rights in that group. Sure, you can filter the mails to /dev/null, but getting a broad idea of what's going on is a good thing, no? I'm willing to bet that at least half of our design problems have resulted from people doing narrowly-focused work in only one group or area... Lloyd Wood http://sat-net.com/L.Wood/ From: ietf-boun...@ietf.org [ietf-boun...@ietf.org] On Behalf Of Glen Zorn [glenz...@gmail.com] Sent: 08 June 2013 07:31 To: ietf@ietf.org Subject: Re: Best list for IETF last calls [was: Weekly posting summary for ietf@ietf.org] On 06/08/2013 02:52 AM, Brian E Carpenter wrote: > Rule 1 for complex and divergent mail threads is to change the > Subject header when the subject changes. If you don't do that, > your mail is rather likely to get junked. > > I think that IETF last call threads should stay on the main IETF > discussion list. That is exactly the right place for them. Since I've requested (read "begged" ;-) for such threads to be moved to their own list on several occasions, I disagree again. > It's rather trivial to filter them into a dedicated folder; > I have one called 'lastcallsin', that also picks up most > WG Last Call threads, although those have less standardised > subject headers. This would appear to work consistently only as long as 'Rule 1' above is not followed. > > Brian > > On 08/06/2013 06:17, Juliao Braga wrote: >> +1 >> >> Em 07/06/2013 15:09, Ulrich Herberg escreveu: >>> I like the idea of a separate list for last calls. It would not solve >>> the issue of noise for all of us (and not reduce the overall amount of >>> emails), but it would separate general discussions from IETF LCs. I >>> have IETF emails filtered by mailing list into different IMAP folders, >>> and thus a separation could be useful for me. >>> >>> Ulrich >>
RE: Content-free Last Call comments
We have to know, not that you have read the document, but that you have -understood- it. Lloyd Wood http://sat-net.com/L.Wood/ From: ietf-boun...@ietf.org [ietf-boun...@ietf.org] On Behalf Of Randy Bush [ra...@psg.com] Sent: 11 June 2013 09:51 To: Mark Nottingham Cc: Pete Resnick; ietf@ietf.org Subject: Re: Content-free Last Call comments so now i am expected to do a write-up of why i show simple support of a document i have read? may i use carbon paper for the triplicate, or will a copier suffice? surely we can find a way to waste more time and effort. randy
RE: Content-free Last Call comments
Ad-hominem arguments are not good arguments. Peer review depends on what the peer says, not who the peer is - something any academic should know. Lloyd Wood http://sat-net.com/L.Wood/ From: ietf-boun...@ietf.org [ietf-boun...@ietf.org] On Behalf Of Stephen Farrell [stephen.farr...@cs.tcd.ie] Sent: 11 June 2013 01:36 To: Pete Resnick Cc: ietf@ietf.org Subject: Re: Content-free Last Call comments Hi Pete, I think you err when you say this: > A statement such as the above is almost entirely useless to me as an > IESG member trying to determine consensus. It is content-free. In fact, you do know Russ. If you did not, then the above would be far closer to correct. But in reality you do know a lot more than you claim below. With overwhelming probability, your choice #2 applies and I'm very surprised you don't also think that. If it made a significant difference and I wasn't sure I'd ask Russ to clarify. For me, I read Russ' mail and I concluded he meant #2. And I'm confident in that conclusion. So I'm really bemused when you say that you don't know how to interpret Russ' mail. Declaring that mail problematic also seems quite purist to me. And insisting on purity seems to me worse than being slightly but harmlessly ambiguous. At the same time I agree we do not want a procession of +1 mails. But then we won't get that for this draft. And if we did get that for any draft, some IETF participants (probably incl. you and I) would notice that and query it or object. So perhaps you're also being a tad trigger-happy on jumping on this message. Lastly, I think evaluating IETF LC messages only in terms of how they help the IESG evaluate consensus or not is wrong. Those messages are for and from the IETF community. So if e.g. some renowned NFS person who's hardly known to the IESG were to have sent an equivalent message, that might have been quite good input that Martin or Spencer could have translated for you. And that's just fine. And it would be fine if Russ' mail had been directed not at the IESG but at some other part of the community. So bottom line, I think you're wrong, Russ' mail was not content-free. S. PS: Yes, this is a not-very-good academic accusing an employee of an industrial behemoth of excess purity. Go figure:-) On 06/10/2013 09:37 PM, Pete Resnick wrote: > Russ, our IAB chair and former IETF chair, just sent a message to the > IETF list regarding a Last Call on draft-ietf-pkix-est. Here is the > entire contents of his message, save quoting the whole Last Call request: > > On 6/10/13 1:45 PM, Russ Housley wrote: >> I have read the document, I a support publication on the standards track. >> >> Russ > > A month ago, we had another very senior member of the community post > just such a message (in that case directly to the IESG) in response to a > different Last Call. I took that senior member of the community to task > for it. But apparently Russ either disagrees with my complaint or didn't > notice that discussion on the IESG list, so I think it's worth airing > here in public: > > A statement such as the above is almost entirely useless to me as an > IESG member trying to determine consensus. It is content-free. > > We don't vote in the IETF, so a statement of support without a reason is > meaningless. We should not be encouraging folks to send such things, and > having the IAB chair do so is encouraging bad behavior. Had I not known > Russ and his particular expertise, I would have no reason to take it > into consideration *at all*. We should not have to determine the > reputation of the poster to determine the weight of the message. Even > given my background knowledge of who Russ is, I cannot tell from that > message which one of the following Russ is saying: > > - This document precisely describes a protocol of which I have been an > implementer, and I was able to independently develop an interoperable > implementation from the document. > - This document is about a technology with which I have familiarity and > I have reviewed the technical details. It's fine. > - I've seen objection X to the document and I think the objection is > incorrect for such-and-so reasons. > - My company has a vested interest in this technology becoming a > standard, and even though I know nothing about it, I support it becoming > a standards track document. > - My Aunt Gertrude is the document editor and she said that she needs > statements of support, so here I am. > - I have a running wager on when we're going to reach RFC 7000 and I > want to increase my odds of winning. > > I take it I am supposed to presume from my friendship and knowledge of > Russ that one of the first three is true and that the la
RE: Content-free Last Call comments
How many RFCs describe things that are implemented? How many RFCs describe things that are deployed? Lloyd Wood http://sat-net.com/L.Wood/ From: ietf-boun...@ietf.org [ietf-boun...@ietf.org] On Behalf Of Dave Cridland [d...@cridland.net] Sent: 11 June 2013 12:36 To: Pete Resnick Cc: ietf@ietf.org Discussion Subject: Re: Content-free Last Call comments On Mon, Jun 10, 2013 at 9:37 PM, Pete Resnick mailto:presn...@qti.qualcomm.com>> wrote: A statement such as the above is almost entirely useless to me as an IESG member trying to determine consensus. It is content-free. I think this is, in part, due to the question asked. The IETF's Last Call announcement presumes much on the part of those reading it. You're aiming to solicit something that's not asked for. Compare and contrast with the XSF's Last Call announcements, in particular the questionnaire at the end. Note that in this thread, almost all respondents are actually filling it in, and further note that at least some of those are experienced IETF participants, suggesting that even the jaded IETF folk might join in. http://jabber.996255.n3.nabble.com/LAST-CALL-XEP-0308-Last-Message-Correction-td14079.html I'd suggest that putting together a set of five questions you're hoping to have answered would be sensible and useful. Perhaps: 1) Do you believe this document is needed? 2) Is the document ready for publication as-is? 3) Are you intending to, or have you already, implemented and/or deployed this specification? 4) Does the document adequately explain the risks involved in implementing and/or deploying this specification? 5) Is the document sufficiently clear to allow unambiguous understanding of how to implement and/or deploy the specification? Dave.
Renaming RFC
RFC should be renamed to Resulted From Comments. It's now the endpoint of the process; Request For Comments dated from when it was the start. (Though RFCs through workgroups are arguably Resulted from Collaboration/Consensus/Chairing). If you're going to alter the process in any way, start here. Lloyd Wood http://sat-net.com/L.Wood/
RE: Content-free Last Call comments
Are the IESG people who disagree with you speaking for the IESG, or for themselves? I've noticed a tendency for IESG weight to be (inadvertently?) thrown around, lending more weight to comments than would otherwise be given. Lloyd Wood http://sat-net.com/L.Wood/ From: ietf-boun...@ietf.org [ietf-boun...@ietf.org] On Behalf Of Pete Resnick [presn...@qti.qualcomm.com] Sent: 12 June 2013 20:17 To: Bob Hinden Cc: ietf@ietf.org Subject: Re: Content-free Last Call comments On 6/12/13 10:33 AM, Bob Hinden wrote: > Please describe the context of your email. Are you speaking for the IESG, > yourself as an AD, or an individual? Oh, crap. And given that I'm usually the one giving people a hard time about *this* issue, I feel especially bad about not being clearer. This is Pete, hatless individual talking. There are (as you've seen) IESG people, past and present who disagree with me. Nothing I've said is anything we've come to an IESG consensus around. Insofar as I think that only saying "I support this document" is a bogus thing to say, I am revealing something about how I behave as an AD in the face of such statements, and my further explanations that I value reviews and take them seriously also indicates my views as an AD, but that doesn't indicate some policy that I'm instituting with WGs for which I am responsible. I am terribly sorry about not making this clear up front. My sincere apologies. I hope nobody took this as a other than my commentary. Sheepishly, pr -- Pete Resnick<http://www.qualcomm.com/~presnick/> Qualcomm Technologies, Inc. - +1 (858)651-4478
RE: Comments For I-D: draft-moonesamy-nomcom-eligibility-00 (was Re: The Nominating Committee Process: Eligibility)
-1 Lloyd Wood http://sat-net.com/L.Wood/ From: ietf-boun...@ietf.org [ietf-boun...@ietf.org] On Behalf Of Noel Chiappa [j...@mercury.lcs.mit.edu] Sent: 29 June 2013 13:28 To: ietf@ietf.org Cc: j...@mercury.lcs.mit.edu Subject: RE: Comments For I-D: draft-moonesamy-nomcom-eligibility-00 (was Re: The Nominating Committee Process: Eligibility) > From: j...@mercury.lcs.mit.edu (Noel Chiappa) > Yet. PS: I probably should have added a ":-)" to that. Sorry, it's early, the brain's not firing on all cylinders yet, and I was so entranced by the chance to set the record for the shortest ever IETF list e-mail... :-) Noel
RE: Appeal Response to Abdussalam Baryun regarding draft-ietf-manet-nhdp-sec-threats
Do we have any statistics on how many appeals to the IESG fail and how many succeed? If I knew that 97% of appeals get rejected, I wouldn't even bother writing one... (On the other hand, that might simply be because 97% of the appeals are written by loons. Statistics can't tell us everything.) Lloyd Wood http://sat-net.com/L.Wood/ From: ietf-announce-boun...@ietf.org [ietf-announce-boun...@ietf.org] On Behalf Of The IESG [i...@ietf.org] Sent: 02 July 2013 23:24 To: abdussalambar...@gmail.com Cc: ietf-annou...@ietf.org Subject: Appeal Response to Abdussalam Baryun regarding draft-ietf-manet-nhdp-sec-threats The IESG has reviewed the appeal of Abdussalam Baryun dated June 19, 2013 on the subject of inclusion in the acknowledgments section of draft-ietf-manet-nhdp-sec-threats: http://www.ietf.org/iesg/appeal/baryun-2013-06-19.txt This is a dispute about a matter in a working group. The same matter has previously been raised with the working group chairs and responsible Area Director, as specified in RFC 2026 Section 6.5.1. Writing acknowledgments sections is largely a matter of editorial discretion, where good sense and general attribution practices are the primary guidelines, although RFC 2026 Section 10.3.1 has some specific rules regarding acknowledgment of major contributors, copyright, and IPR. After reviewing the appeal, including the associated list discussion and draft revisions, the IESG concludes that the authors made a reasonable editorial choice that was well within their discretion and that none of the messages at issue fall under the required acknowledgment rules of RFC 2026 Section 10.3.1 and RFC 5378 Sections 5.6a and 1c. The IESG finds that the chairs and responsible AD handled complaints about the matter appropriately.
RE: [IETF] Re: [IETF] Re: Appeal Response to Abdussalam Baryun regarding draft-ietf-manet-nhdp-sec-threats
> C: does my appeal look more like the club of 3, or the club of 11? I think there's a new club of one. Lloyd Wood http://sat-net.com/L.Wood/
RE: IETF 87 Registration Suspended
It strikes me that 'membership fees' as opposed to 'entrance fees' could work around this payment issue. Or incur a different tax... Lloyd Wood http://sat-net.com/L.Wood/ From: ietf-boun...@ietf.org [ietf-boun...@ietf.org] On Behalf Of Martin Rex [m...@sap.com] Sent: 05 July 2013 02:06 To: "Martin J. Dürst" Cc: i...@ietf.org; Barry Leiba; IETF discussion list; IAB; Working Group Chairs Subject: Re: IETF 87 Registration Suspended "Martin J. Dürst" wrote: > >On 2013/07/04 9:39, Barry Leiba wrote: >>> Registration for IETF87 in Berlin has been suspended to consider the impact >>> of a change in the VAT rules on Registration Fees. We expect registration >>> to open as soon as this matter has been clarified. >> >> I don't understand what the effect of VAT rules is on money collected >> in the U.S. in U.S. Dollars. > > It's usual in the U.S. that taxes on goods bought and sold are levied as > a consumption tax, at the place (i.e. in the state) where the object is > bought (and therefore presumably consumed/used). > > However, that's not a given, and VAT stands for value added tax, and the > value addition/consumption can be presumed to happen at the meeting in > Berlin (and there's no need for consensus here, it's the opinion of the > local tax authority that counts :-(). If the money that is collected is an entrance/participation fee for the venue itself, then the local tax authority might require the local VAT for _all_ visitors, even those that pay in advance or in a different country. While it might be possible to make the necessary tweaks about the fee (maybe not for this meeting, but for future meetings) for the WG sessions themselves, this would be more difficult to argue for the breakfast/buffet/brownies/beverages (I assume that still exists) and the access to the terminal room, where some form of badge checking is usually done in order to protect the resources. -Martin
RE: Final Announcement of Qualified Volunteers
Email to noncom-chair-2...@ietf.org appears to fail - bounce below. If Allison hasn't received any feedback, that's why. Lloyd Wood http://sat-net.com/L.Wood/ Delivery has failed to these recipients or distribution lists: noncom-chair-2...@ietf.org The recipient's e-mail address was not found in the recipient's e-mail system. Microsoft Exchange will not try to redeliver this message for you. Please check the e-mail address and try resending this message, or provide the following diagnostic text to your system administrator. The following organization rejected your message: mail.ietf.org. Diagnostic information for administrators: Generating server: server-7.bemta-5.messagelabs.com noncom-chair-2...@ietf.org mail.ietf.org #: Recipient address rejected: User unknown in virtual alias table> #SMTP# Original message headers: Return-Path: Received: from [85.158.136.51:38926] by server-7.bemta-5.messagelabs.com id D5/8B-21002-69498D15; Sat, 06 Jul 2013 22:05:10 + X-Env-Sender: l.w...@surrey.ac.uk X-Msg-Ref: server-6.tower-49.messagelabs.com!1373148309!23609644!2 X-Originating-IP: [131.227.200.43] X-StarScan-Received: X-StarScan-Version: 6.9.9; banners=-,-,- X-VirusChecked: Checked Received: (qmail 2287 invoked from network); 6 Jul 2013 22:05:10 - Received: from exht022p.surrey.ac.uk (HELO EXHT022P.surrey.ac.uk) (131.227.200.43) by server-6.tower-49.messagelabs.com with AES128-SHA encrypted SMTP; 6 Jul 2013 22:05:10 - Received: from EXMB01CMS.surrey.ac.uk ([169.254.1.180]) by EXHT022P.surrey.ac.uk ([131.227.200.43]) with mapi; Sat, 6 Jul 2013 23:05:10 +0100 From: To: Date: Sat, 6 Jul 2013 23:05:08 +0100 Subject: RE: Final Announcement of Qualified Volunteers Thread-Topic: Final Announcement of Qualified Volunteers Thread-Index: Ac56k3eMACmjfPaISkGziW3QAHNMiwAAHRGQ Message-ID: <290e20b455c66743be178c5c84f12408223f494...@exmb01cms.surrey.ac.uk> References: <20130706215330.8850.38261.idtrac...@ietfa.amsl.com> In-Reply-To: <20130706215330.8850.38261.idtrac...@ietfa.amsl.com> Accept-Language: en-US, en-GB Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-GB Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 From: ietf-announce-boun...@ietf.org [ietf-announce-boun...@ietf.org] On Behalf Of NomCom Chair 2013 [nomcom-chair-2...@ietf.org] Sent: 06 July 2013 22:53 To: IETF Announcement List Subject: Final Announcement of Qualified Volunteers I am pleased to announce that we have 140 qualified individuals who have generously volunteered to serve as voting members of this year's Nomcom. Please take a look and get in touch before July 13 if you think your name should be here and it isn't (or possibly I've mis-typed it...), or if you have any other questions. Allison Mankin 2013-14 Nomcom Chair nomcom-chair-2...@ietf.org 001 John Scudder, Juniper 002 Stephen Hanna, Juniper 003 Wassim Haddad, Ericsson 004 Russ White, VTE 005 Stephan Wenger, Vidyo 006 ZHAO Yi, Huawei 007 Eric Gray, Ericsson 008 Steve Kent, BBN 009 Toerless Eckert, Cisco 010 Alia Atlas, Juniper 011 Victor Kuarsingh, Rogers 012 Yizhou LI, Huawei 013 Gonzalo Salgueiro, Cisco 014 Gang CHEN, China Mobile 015 Ning KONG,CNNIC 016 Marcelo Bagnulo, UC3M 017 SHEN Shuo 沈烁 (Sean), CNNIC 018 Fernando Gont, SI6 Networks 019 Glen Zorn, Network Zen 020 Reinaldo Penno, Cisco 021 Klaas Wierenga, Cisco 022 Pascal Thubert, Cisco 023 Mehmet Ersue, Nokia Siemens 024 Ole Troan, Cisco 025 Jouni Korhonen, Renesas Mobile 026 Giles Heron, Cisco 027 Gunter Van de Velde, Cisco 028 Arturo Servin, LACNIC 029 Eric Vyncke, Cisco 030 Cullen Jennings, Cisco 031 Tina Tsou, Huawei 032 Dhruv Dhody, Huawei 033 Hongyu LI (Julio), Huawei 034 Scott Mansfield, Ericsson 035 John Drake, Juniper 036 Andrew McLachlan, Cisco 037 Derek Atkins, Mocana 038 Suhas Nandakumar, Cisco 039 Eric Rescorla, RTFM 040 Karen Seo, BBN 041 Stig Venaas, Cisco 042 Stan Ratliff, Cisco 043 Ignas Bagdonas, Cisco 044 Peter Yee, AKAYLA 045 Donald Eastlake, Huawei 046 ZHOU Qian (Cathy), Huawei 047 Sam Hartman, Painless Security 048 Lixia Zhang, UCLA 049 Teemu Savolainen, Nokia 050 Alvaro Retana, Cisco 051 Terry Manderson, ICANN 052 Bill VerSteeg, Cisco 053 Melinda Shore, No Mountain 054 IJsbrand Wijnands, Cisco 055 Karen O'Donoghue, ISOC 056 Benson Schliesser, Juniper 057 Ari Keränen, Ericsson 058 Fangwei HU, ZTE 059 Mach CHEN, Huawei 060 Hui Deng, China Mobile 061 LIU Dapeng, China Mobile 062 Jaap Akkerhuis, NLNET Labs 063 Magnus Westerlund, Ericsson 064 Zehn CAO, China Mobile 065 Zaheduzzaman Sarker, Ericsson 066 Bhumip Khasnabish, ZTE USA 067 Andrew Chi, BBN 068 Thomas Nadeau, Juniper 069 Steven C (Craig) White, Alcatel-Lucent 070 Orit Levin, Microsoft 071 Sam Aldrin, Huawei 072 Paul Ebersman, Infoblox 073 Christopher Liljenstolpe, BigSwitch 074 Uma
RE: Final Announcement of Qualified Volunteers
Gah. Am idiot misspelling it, sorry. Lloyd Wood http://sat-net.com/L.Wood/ From: ietf-boun...@ietf.org [ietf-boun...@ietf.org] On Behalf Of l.w...@surrey.ac.uk [l.w...@surrey.ac.uk] Sent: 08 July 2013 08:38 To: ietf@ietf.org; noncom-chair-2...@ietf.org Subject: RE: Final Announcement of Qualified Volunteers Email to noncom-chair-2...@ietf.org appears to fail - bounce below.
RE: Final Announcement of Qualified Volunteers
Ah, Allison actually misspelled it in setting her reply-to. So all replies would bounce. Seriously guys, nom-com is the way to go to reduce this confusion. Needs a minus. Lloyd Wood http://sat-net.com/L.Wood/ On plus side, I didn't make the typo, only copied it and couldn't spot it. Go me! From: Wood L Dr (Electronic Eng) Sent: 08 July 2013 08:55 To: l.w...@surrey.ac.uk; ietf@ietf.org; noncom-chair-2...@ietf.org Subject: RE: Final Announcement of Qualified Volunteers Gah. Am idiot misspelling it, sorry. Lloyd Wood http://sat-net.com/L.Wood/ From: ietf-boun...@ietf.org [ietf-boun...@ietf.org] On Behalf Of l.w...@surrey.ac.uk [l.w...@surrey.ac.uk] Sent: 08 July 2013 08:38 To: ietf@ietf.org; noncom-chair-2...@ietf.org Subject: RE: Final Announcement of Qualified Volunteers Email to noncom-chair-2...@ietf.org appears to fail - bounce below.
RE: Final Announcement of Qualified Volunteers
I do recall a case where both chairs of a WG belonged to a Major Organization. World domination was thwarted, however, because the chairs couldn't actually agree on anything; the organization was big enough that competing views were widespread within it. Much to the frustration of other members of the Major Organization. And the members of the working group. This suggests that we can't produce viable committees _anyway_. Lloyd Wood http://sat-net.com/L.Wood/ From: ietf-boun...@ietf.org [ietf-boun...@ietf.org] On Behalf Of Dave Crocker [d...@dcrocker.net] Sent: 09 July 2013 21:53 To: ietf@ietf.org Cc: nomcom-chair-2...@ietf.org Subject: Re: Final Announcement of Qualified Volunteers > Should we consider changing it to "not more than one" in view > of today's data? On it's face, that sounds like an absolutely Draconian rule. However stepping back a bit, it should prompt a simple question: Is the IETF so reliant on a tiny number of companies that we cannot produce viable committees if we require each member of a committee to be affiliated with a different company? In other words, are we really incapable of requiring extensive corporate diversity? d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net
RE: IETF registration fee?
This neglects to mention that the IETF is really an activity of the Internet Society - see RFC2301 for takeover details. As such, the IETF is a business unit of ISOC, which is a non-profit (charitable organization) and which can subsidize the IETF, allowing different conference/payment models to be tried out. (I've never really understood the IETF business model. I understand ISOC's model even less.) Lloyd Wood http://sat-net.com/L.Wood/ From: ietf-boun...@ietf.org [ietf-boun...@ietf.org] On Behalf Of Phillip Hallam-Baker [hal...@gmail.com] Sent: 11 July 2013 15:34 To: Simon Pietro Romano Cc: Keith Moore; ietf@ietf.org Subject: Re: IETF registration fee? There are several interlocking issues with the day passes and cross area participation. One issue is the fact that the IETF chose a business model in which profits from the conferences fund the organization and the IETF has no ability to reconsider or change decisions of that sort. I can see that as being an existential threat to the IETF in a decade or two since the demand for (unpaid) external participation is going to grow and the technologies for supporting external participation will eventually not suck. Using paid conferences as a profit center is a risky long term prospect at best. Refusing to adapt the format of the conferences to protect the profit center worse. And in the case of the IETF the whole purpose of the organization is to develop the technologies that are undermining the paid conference model. We are sawing the board we are standing on. Cross area participation is a good thing but the way the IETF supports this is terrible. I won't be coming to Berlin because there is only one WG that I have a reason to attend in person and it is not worth making the flight for a two hour meeting, much of which is summaries. I much prefer the OASIS or W3C model for plenary meetings where my WG session will be doing one or two solid days of design work and the plenary sessions are on the Wednesday and consist of a series of presentations designed to inform people about the work going on in each area. Sitting in watching other WGs is not a good way to find out what is going on. Area meetings are more useful.
RE: IETF registration fee?
oops. RFC2031. Lloyd Wood http://sat-net.com/L.Wood/ From: ietf-boun...@ietf.org [ietf-boun...@ietf.org] On Behalf Of l.w...@surrey.ac.uk [l.w...@surrey.ac.uk] Sent: 12 July 2013 01:08 To: hal...@gmail.com; sprom...@unina.it Cc: mo...@network-heretics.com; ietf@ietf.org Subject: RE: IETF registration fee? This neglects to mention that the IETF is really an activity of the Internet Society - see RFC2301 for takeover details. As such, the IETF is a business unit of ISOC, which is a non-profit (charitable organization) and which can subsidize the IETF, allowing different conference/payment models to be tried out. (I've never really understood the IETF business model. I understand ISOC's model even less.) Lloyd Wood http://sat-net.com/L.Wood/ From: ietf-boun...@ietf.org [ietf-boun...@ietf.org] On Behalf Of Phillip Hallam-Baker [hal...@gmail.com] Sent: 11 July 2013 15:34 To: Simon Pietro Romano Cc: Keith Moore; ietf@ietf.org Subject: Re: IETF registration fee? There are several interlocking issues with the day passes and cross area participation. One issue is the fact that the IETF chose a business model in which profits from the conferences fund the organization and the IETF has no ability to reconsider or change decisions of that sort. I can see that as being an existential threat to the IETF in a decade or two since the demand for (unpaid) external participation is going to grow and the technologies for supporting external participation will eventually not suck. Using paid conferences as a profit center is a risky long term prospect at best. Refusing to adapt the format of the conferences to protect the profit center worse. And in the case of the IETF the whole purpose of the organization is to develop the technologies that are undermining the paid conference model. We are sawing the board we are standing on. Cross area participation is a good thing but the way the IETF supports this is terrible. I won't be coming to Berlin because there is only one WG that I have a reason to attend in person and it is not worth making the flight for a two hour meeting, much of which is summaries. I much prefer the OASIS or W3C model for plenary meetings where my WG session will be doing one or two solid days of design work and the plenary sessions are on the Wednesday and consist of a series of presentations designed to inform people about the work going on in each area. Sitting in watching other WGs is not a good way to find out what is going on. Area meetings are more useful.
RE: Sunday IAOC Overview Session at the Berlin IETF
AB How many IETFs have you attended? How many professional meetings have you organised? Lloyd Wood http://sat-net.com/L.Wood/ From: ietf-boun...@ietf.org [ietf-boun...@ietf.org] On Behalf Of Abdussalam Baryun [abdussalambar...@gmail.com] Sent: 16 July 2013 12:26 To: Pat Thaler Cc: Bob Hinden; ietf@ietf.org Subject: Re: Sunday IAOC Overview Session at the Berlin IETF Hi Pat, Thanks. My concerns is that do we have a plan for disaster recovery/management in IETF or IEEE802. Including meetings which is the important time we come together for. Usually now organisations are looking into defining plans so the staff/participants are aware of procedures. I was thinking if I was to go to any organisation these days I will ask is there a plan and alternatives. Usually communication and information is the key to a better solution per person or per organisation. As IETF and IEEE802 standard communication technology then it is good if we have the best practice in the world. AB On Tue, Jul 16, 2013 at 9:33 AM, Pat Thaler mailto:ptha...@broadcom.com>> wrote: One can't 100% protect against disruption from emergency situations. I'm Vice Chair of IEEE 802 and there was a case where a venue became unavailable due to a disaster. In that case it was enough before the meeting that it worked as Bob described - the hotel chain worked with us to identify and contract an acceptable alternative. On the other hand, the tsunami hit Japan just before the IEEE 802 Singapore meeting - close enough to it that some folks were in the air on the way to the meeting when it hit. Many attendees had travel disrupted and arrived late. Some even were unable to attend due to problems getting an alternative routing. Fortunately, enough were able to arrive so that we had an effective meeting, but it was difficult. There are also cases where a wide spread weather disruption has caused problems for meeting effectiveness - e.g. a blizzard on the east coast of the USA. Pat -Original Message- From: ietf-boun...@ietf.org<mailto:ietf-boun...@ietf.org> [mailto:ietf-boun...@ietf.org<mailto:ietf-boun...@ietf.org>] On Behalf Of Bob Hinden Sent: Monday, July 15, 2013 12:56 PM To: Abdussalam Baryun Cc: Bob Hinden; ietf@ietf.org<mailto:ietf@ietf.org> Subject: Re: Sunday IAOC Overview Session at the Berlin IETF AB, > - Is there an alternative venue if the venue was closed for any > emergency reason at any time? or only one plan so if the plan changes > there can be problems with the communities expected plan because they > were not aware of the needed information per time. No, there is not an alternative venue under contract. It isn't practical to have two venues under contract, build two networks, etc. It is technically feasable, but would cause the registration fee to go up significantly to cover the extra costs. If there was, for example, a fire at a venue months before the the meeting we would look for an alternate, but what happens would depend on availability of alternative venues. We have good relationships with the hotel chains we use and they would work very hard to find an alternative venue, as would the effected venue.
RE: Remote participants, newcomers, and tutorials
> I would be very sorry to see IETF *working* meetings turned into > something closer to conferences, with poster sessions! Lloyd Wood http://sat-net.com/L.Wood/
RE: Anonymity versus Pseudonymity (was Re: [87attendees] procedural question with remote participation)
AB, You write "Some people prefer to be anonymous so they try to save their self reputation" Are you pursuing this line of argument because, after - campaigning for but failing to achieve the abolition of April 1 RFCs - campaigning for but failing to achieve an acknowledgement in a MANET draft you didn't write. - campaigning for changes to the posting summary that now regularly lists you as Number One poster on this list You believe that your reputation is harmed, would require saving for meaningful interaction, and that you need pseudonymity? Lloyd Wood http://sat-net.com/L.Wood/ From: ietf-boun...@ietf.org [ietf-boun...@ietf.org] On Behalf Of Abdussalam Baryun [abdussalambar...@gmail.com] Sent: 03 August 2013 07:41 To: Adam Roach Cc: Olle E. Johansson; ietf@ietf.org Subject: Re: Anonymity versus Pseudonymity (was Re: [87attendees] procedural question with remote participation) Hi Adam, I don't agree with you. I am a remote participant (2 years and never attended meetings) in the IETF organisation, do you think that IETF is fare in treating remote participants? I think the current IETF direction is in favor of attended-meeting participants, so IMHO one reason of some hidding their name is because the IETF still is not yet able to control wrong behaviour of participants who think they are well known. Thoes wrong behavior abuse peoples rights in IETF. If some are well known, the reason is because they got better opportunity in going to meetings, or that majority of participants are from two regions (North America+Europe). For me the IETF reputation is about 40% (evaluated by asking close friends that did not participate and including the way I was treated within 2 years), still needs more work to build its reputation (e.g. I think some old participants need guidance to IETF visions). For me participants' good reputation depend on their reactions: if I get a nice reply from them, or if they don't only respond to known people, or if they acknowledge efforts, or if they encourage other into IETF visions, or if they provide good ideas/inputs, or if they manage work/WG/IETF well, etc. In IETF volunteers' reputations SHOULD always be high and respected, but seems like the IETF give chance for abuse so its reputation makes some people prefer to be anonymous so they try to save their self reputation. We in IETF SHOULD not focus on people's reputation, we SHOULD focus on ideas, reasons, work-quality, documents/RFCs reputations and process-procedures reputations. We are here to document IETF reputation but not to document a person reputation or even his/her name. A person's name for me is only important when I want to refer to his/her review, draft, idea, etc. Don't forget that in procedure; any input into IETF is own also by IETF no matter what was the name given, so bad behaviour makes IETF reputation bad and then some people leave, or make anonymous names, or don't participate just listen. IMO, the majority of subscribers (in WGs) are listeners with zero participation. AB On 8/2/13, Adam Roach wrote: > Moving to ietf@ietf.org, since I think this is not in any way specific > to Berlin. > > > On 8/2/13 12:24, Olle E. Johansson wrote: >> In rtcweb we have remote participants that prefer anonymity for a number >> of reasons. > > I'm going to make a broad assumption that the "number of reasons" all > relate to privacy. If that is incorrect, please weigh in. > >> The question is how this is handled in regards to note well, when they >> want jabber scribes to relay opinions or proposals to the meeting. >> >> Just a note for the future. I think we should allow anonymous listeners, >> but should they really be allowed to participate? >> > > We had a previous conversation around pseudonyms, which I think > concluded that pseudonyms are pretty much okay (and impossible to > reliably detect anyway). > > Given this fact, someone can protect their identity through use of a > consistent pseudonym. This has the property of developing a persona > behind that pseudonym that the working group members can reasonably > interact with. > > By contrast, attempting to participate in a truly anonymous fashion > rather than participating with a pseudonym seems to have very little > justification, with significant potential drawback for the working > group. The privacy implications are pretty much identical, but it > provides the illusion that one can act in a way that has no impact on a > persona's reputation. IMHO, this is ripe for bad behavior, bad faith > participation, and other abuses. > > Given the availability of pseudonymous participation, I don't think we > need to tolerate anonymous participation. > > /a > >
RE: 6tsch BoF
Okay, http://tools.ietf.org/id/draft-resnick-on-consensus-00.txt can there be anything to discuss on not having consensus, developing two competing solutions in the same WG, and then having to downselect to one? Lloyd Wood http://sat-net.com/L.Wood/ From: ietf-boun...@ietf.org [ietf-boun...@ietf.org] On Behalf Of Barry Leiba [barryle...@computer.org] Sent: 04 August 2013 05:55 To: Scott Brim Cc: SM; Andy Bierman; IETF discussion list Subject: Re: 6tsch BoF > What did you think of Pete Resnick's draft about hums. I thought well of it; I still do. When Pete planned to write it, I offered to co-author it. But he said that once he got started, it all just flowed out, and he wanted to present it as just his craziness, at least at first. It's not about hums, in particular, but about rough consensus, in general, however it's reached. The main point where Pete and I disagree is whether raised hands are an appropriate replacement for humming when you're "getting a sense of the room" -- I like hands, he doesn't. But we're completely in agreement about what to do with the data. Barry
RE: Rude responses (Was: Last Call: (Sender Policy Framework (SPF) for Authorizing Use of Domains in Email, Version 1) to Proposed Standard)
> I can't myself think of a good justification for sarcasm, (well, maybe [1]:-) good sarcasm is like good protocol design - many can recognise it, some can appreciate it, few can truly understand its nuances, and even fewer can create it. You're just not one of them. Lloyd Wood http://sat-net.com/L.Wood/
RE: The Last Call social contract (was - Re: Rude responses)
> LC should not be treated as a right of passage, to test the patience of > folks who have developed a document. rite? Lloyd Wood http://sat-net.com/L.Wood/
RE: Rude responses
> I experienced rude respondings in IETF list That would be when you tried to get April 1 RFCs discontinued. > in one WG list That would be MANET, when you lobbied for an acknowledgement on a draft you didn't write or contribute significantly to. Have you considered that being polite and reasonable on organisation business means both not making unreasonable requests, and first making an effort to understand the organisation whose business you are attempting to conduct? Your requests come from a clear lack of understanding of the IETF or how it works. Lloyd Wood http://sat-net.com/L.Wood/ From: ietf-boun...@ietf.org [ietf-boun...@ietf.org] On Behalf Of Abdussalam Baryun [abdussalambar...@gmail.com] Sent: 25 August 2013 12:27 To: Pete Resnick Cc: dcroc...@bbiw.net; ietf@ietf.org Subject: Re: Rude responses (Was: Last Call: (Sender Policy Framework (SPF) for Authorizing Use of Domains in Email, Version 1) to Proposed Standard) I experienced rude respondings in IETF list and in one WG list, I don't beleive that it is culture of IETF participants, but it seems that some people should understand to be polite and reasonable in such organisation business. Finally, the rude responding is not controled by the chair of thoes lists, therefore, thoes lists can be rude lists from time to time. AB
RE: pgp signing in van
Surely, pgp signing in vain? Don't know about you, but I value plausible deniability. Lloyd Wood http://sat-net.com/L.Wood/ From: ietf-boun...@ietf.org [ietf-boun...@ietf.org] On Behalf Of Randy Bush [ra...@psg.com] Sent: 06 September 2013 01:45 To: IETF Disgust Subject: pgp signing in van so, it might be a good idea to hold a pgp signing party in van. but there are interesting issues in doing so. we have done lots of parties so have the social protocols and n00b cheat sheets. but that is the trivial tip of the iceberg. o is pgp compromised? just because it is not listed in [0] is not very strong assurance in these dark days. o what are the hashes of audited software, and who did the audits? o what are the recommended algs/digest/keylen parameters? o do we really need eliptical, or is that a poison pill? o your questions go here ... randy --- [0] http://www.nytimes.com/interactive/2013/09/05/us/unlocking-private-communications.html
RE: Bruce Schneier's Proposal to dedicate November meeting to saving the Internet from the NSA
http://www.mail-archive.com/cryptography@metzdowd.com/msg12325.html That's a pretty damning indictment of the development of IPSec from John Gilmore. Lloyd Wood http://sat-net.com/L.Wood
RE: pgp signing in van
There is no upside. By signing your mail you lose plausible deniability, remove legal doubt as to what you said... Lloyd Wood http://sat-net.com/L.Wood/ From: ietf-boun...@ietf.org [ietf-boun...@ietf.org] On Behalf Of Ted Lemon [ted.le...@nominum.com] Sent: 08 September 2013 22:50 To: Michael Richardson Cc: IETF discussion list Subject: Re: pgp signing in van On Sep 8, 2013, at 5:33 PM, Michael Richardson wrote: > To all the people who posted to this thread about how they don't know what > a PGP key signature means, and who did not PGP or S/MIME their email: What's the upside to signing my email? I know why I want everybody I know to sign my email, but what's the upside for me if I do it? Until there's a clear win, it's not going to happen.
RE: Bruce Schneier's Proposal to dedicate November meeting to saving the Internet from the NSA
...and a rebuttal from Jeff Schiller. http://www.mail-archive.com/cryptography@metzdowd.com/msg12497.html Pass the popcorn. Lloyd Wood http://sat-net.com/L.Wood/ From: ietf-boun...@ietf.org [ietf-boun...@ietf.org] On Behalf Of l.w...@surrey.ac.uk [l.w...@surrey.ac.uk] Sent: 08 September 2013 22:32 Cc: ietf@ietf.org Subject: RE: Bruce Schneier's Proposal to dedicate November meeting to saving the Internet from the NSA http://www.mail-archive.com/cryptography@metzdowd.com/msg12325.html That's a pretty damning indictment of the development of IPSec from John Gilmore. Lloyd Wood http://sat-net.com/L.Wood
RE: [Tools-discuss] independant submissions that update standards track, and datatracker
"because all IETF document are examined by IESG" No they're not. See RFC4844. Lloyd Wood http://sat-net.com/L.Wood/ From: ietf-boun...@ietf.org [ietf-boun...@ietf.org] On Behalf Of Abdussalam Baryun [abdussalambar...@gmail.com] Sent: 02 October 2013 13:18 To: Michael Richardson Cc: ietf; tools-disc...@ietf.org Subject: Re: [Tools-discuss] independant submissions that update standards track, and datatracker Hi Michael, I agree that it should appear in related WG's field or area. I see in IETF we have WGs documents list but not areas' documents list, so the individual document may not be found or discovered. I think any document of IETF should be listed in its field area or related charter, but it seems like the culture of IETF focusing on groups work not on the IETF documents. For example, when I first joined MANET WG I thought that RFC3753 is related because it is IETF, but in one discussion one participant did not accept to use that document even though it was related. Fuethermore, some WGs don't comment on related documents to their WG, which I think this should change in future IETF culture (e.g. there was one individual doc that was requested by AD to comment on by the WG but no respond). Therefore, IMHO, the IETF is divided by groups with different point of views/documents and they force their WG Adopted-Work to list documents (not all related to Group-Charters), but it seems that managemnet does not see that there is a division in knowledge or in outputs of the IETF, which a new comer may see it clearly. I recommend to focus/list documents related to Charter, not related to WG adoptions, because all IETF document are examined by IESG. AB On Tue, Oct 1, 2013 at 7:29 PM, Michael Richardson mailto:mcr+i...@sandelman.ca>> wrote: This morning I had reason to re-read parts of RFC3777, and anything that updated it. I find the datatracker WG interface to really be useful, and so I visited http://datatracker.ietf.org/wg/nomcom/ first. I guess I could have instead gone to: http://www.rfc-editor.org/info/rfc3777 but frankly, I'm often bad with numbers, especially when they repeat... (3777? 3737? 3733?) While http://datatracker.ietf.org/wg/nomcom/ lists RFC3777, and in that line, it lists the things that update it, it doesn't actually list the other documents. Thinking this was an error, I asked, and Cindy kindly explained: >http://datatracker.ietf.org/wg/nomcom/ lists the documents that were >published by the NOMCOM Working Group. The NOMCOM Working Group was >open from 2002-2004, and only produced one RFC, which is RFC 3777. > >The RFCs that update 3777 were all produced by individuals (that is, >outside of the NOMCOM Working Group), and so aren't listed individually >on the NOMCOM Working Group documents page. I wonder about this as a policy. Seeing the titles of those documents would have helped me find what I wanted quickly (RFC5680 it was)... While I think that individual submissions that are not the result of consensus do not belong on a WG page. But, if the document was the result of consensus, but did not occur in a WG because the WG had closed, I think that perhaps it should appear there anyway. -- Michael Richardson mailto:mcr%2bi...@sandelman.ca>>, Sandelman Software Works ___ Tools-discuss mailing list tools-disc...@ietf.org<mailto:tools-disc...@ietf.org> https://www.ietf.org/mailman/listinfo/tools-discuss
RE: Improving the ISOC Fellowship programme to attract people from under-represented regions into the IETF
> I am part of the community design team as well ... as being the coauthor of a MANET RFC! Lloyd Wood http://sat-net.com/L.Wood/
