Poster sessions
I've never attended an IETF meeting. Why? Because it seems to me quite unlikely to have a chance to say something useful by going there. I mean useful with respect to a problem that I consider important. That is, not just a minimal contribution to an already scheduled session that I may happen to attend. Perhaps, I should request a session... Problems are often expressed in the form of tentative solutions. Such solutions may occasionally happen to be discussed, refined, and agreed upon by a group of individuals. Implementation, standardization, and adoption may eventually follow --not necessarily in this order. Isn't this how the IRTF and the IETF should work? A poster session would be a sort of plenary, lasting a couple of hours or so, with posters hanged on numbered hardboard panels arranged along a walkway. A poster may be sized A0, or ~50 in, or consist of an equivalent number of smaller sheets. Posters may stay exposed for a few hours before/after the scheduled time period. During the session time, however, authors should stand beside their posters and thus have their chance to talk to any interested ietfers, one by one or in small knots, informally. A few dozens of posters per session may provide for adequate gathering. IME, this way of participating is easier and less binding for both authors and attendees. A poster would suit subjects for which it's difficult to carve a niche within a hosting WG's session, but it may also work as a means to achieve consensus on a given topic before raising it in a more official discussion. Opinions/suggestions? ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Poster sessions
On Jan 6, 2011, at 11:26 AM, Alessandro Vesely wrote: I've never attended an IETF meeting. Why? Because it seems to me quite unlikely to have a chance to say something useful by going there. I mean useful with respect to a problem that I consider important. That is, not just a minimal contribution to an already scheduled session that I may happen to attend. Perhaps, I should request a session... Problems are often expressed in the form of tentative solutions. Such solutions may occasionally happen to be discussed, refined, and agreed upon by a group of individuals. Implementation, standardization, and adoption may eventually follow --not necessarily in this order. Isn't this how the IRTF and the IETF should work? A poster session would be a sort of plenary, lasting a couple of hours or so, with posters hanged on numbered hardboard panels arranged along a walkway. A poster may be sized A0, or ~50 in, or consist of an equivalent number of smaller sheets. Posters may stay exposed for a few hours before/after the scheduled time period. During the session time, however, authors should stand beside their posters and thus have their chance to talk to any interested ietfers, one by one or in small knots, informally. A few dozens of posters per session may provide for adequate gathering. IME, this way of participating is easier and less binding for both authors and attendees. A poster would suit subjects for which it's difficult to carve a niche within a hosting WG's session, but it may also work as a means to achieve consensus on a given topic before raising it in a more official discussion. Opinions/suggestions? Hi Alessandro. Following the Maastricht meeting, there was a lively discussion of a similar issue. The way things are, you need a lot of support to present an idea at a BoF, so the usual way to present new things has become to publish a bar BoF and present there. Despite the name, the modern bar BoF is not held in a bar, but rather in the empty conference rooms during lunch time and late in the evening. Understandably, people don't like this much. There have been a few suggestions for alternate ways of presenting and gathering supporters. One such suggestion is in this draft: http://tools.ietf.org/html/draft-nir-non-wg-presentations-01 A poster session sounds cool, but it works well when the presenters are companies, rather than individuals. To get a good A0 poster, you need access to printing services (which are not cheap, but doable) and graphic design talent, which is neither cheap nor common in IETF attendees. To get such a poster up, I would need either my company's sponsorship, or else use my own talents in graphic design: Hmm, #12FF12. Now there's a nice shade of green for a background. As for fonts, let's go with Mistral, because http://www.cracked.com/funny-5647-fonts . Seriously, though, most of the presentation slides you see in an IETF meeting are either black-on-white with way too much text, sometimes adding some default design from the software, or else they're extremely well designed, where you know there's been some company sponsorship. Some of the Internet-of-Things presentations in recent IETF meetings are examples of the latter. I think that's too high a bar to set for new ideas that still don't have much traction. It could be done with some booths instead of the posters - maybe some desks arranged around a room. Yoav ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Poster sessions
On Jan 6, 2011, at 5:16 AM, Yoav Nir wrote: On Jan 6, 2011, at 11:26 AM, Alessandro Vesely wrote: I've never attended an IETF meeting. Why? Because it seems to me quite unlikely to have a chance to say something useful by going there. I mean useful with respect to a problem that I consider important. That is, not just a minimal contribution to an already scheduled session that I may happen to attend. Perhaps, I should request a session... Problems are often expressed in the form of tentative solutions. Such solutions may occasionally happen to be discussed, refined, and agreed upon by a group of individuals. Implementation, standardization, and adoption may eventually follow --not necessarily in this order. Isn't this how the IRTF and the IETF should work? A poster session would be a sort of plenary, lasting a couple of hours or so, with posters hanged on numbered hardboard panels arranged along a walkway. A poster may be sized A0, or ~50 in, or consist of an equivalent number of smaller sheets. Posters may stay exposed for a few hours before/after the scheduled time period. During the session time, however, authors should stand beside their posters and thus have their chance to talk to any interested ietfers, one by one or in small knots, informally. A few dozens of posters per session may provide for adequate gathering. IME, this way of participating is easier and less binding for both authors and attendees. A poster would suit subjects for which it's difficult to carve a niche within a hosting WG's session, but it may also work as a means to achieve consensus on a given topic before raising it in a more official discussion. Opinions/suggestions? Hi Alessandro. Following the Maastricht meeting, there was a lively discussion of a similar issue. The way things are, you need a lot of support to present an idea at a BoF, so the usual way to present new things has become to publish a bar BoF and present there. Despite the name, the modern bar BoF is not held in a bar, but rather in the empty conference rooms during lunch time and late in the evening. Understandably, people don't like this much. There have been a few suggestions for alternate ways of presenting and gathering supporters. One such suggestion is in this draft: http://tools.ietf.org/html/draft-nir-non-wg-presentations-01 A poster session sounds cool, but it works well when the presenters are companies, rather than individuals. To get a good A0 poster, you need access to printing services (which are not cheap, but doable) and graphic design talent, which is neither cheap nor common in IETF attendees. To get such a poster up, I would need either my company's sponsorship, or else use my own talents in graphic design: Hmm, #12FF12. Now there's a nice shade of green for a background. As for fonts, let's go with Mistral, because http://www.cracked.com/funny-5647-fonts . I am neutral on the overall idea, but in many (most?) academic conferences in a poster session you get a pin board (hopefully with a bunch of pins), which lends itself well to pinning up a set of printed out slides. I have seen many fine poster session presentations from people with very little money, so I don't agree it unduly favors the well sponsored. And it has one great advantage... Seriously, though, most of the presentation slides you see in an IETF meeting are either black-on-white with way too much text, ... in that you can read the slides with too much text at your leisure if you want to, rather than having them flash by unread. I am not sure it would fit well with the IETF ecosystem, as it takes time to scan through a bunch of posters, and it takes time to stand by your poster and answer any questions, and time is always short at an IETF. Maybe we could just have them in the halls and call them a hall-BOF. Regards Marshall sometimes adding some default design from the software, or else they're extremely well designed, where you know there's been some company sponsorship. Some of the Internet-of-Things presentations in recent IETF meetings are examples of the latter. I think that's too high a bar to set for new ideas that still don't have much traction. It could be done with some booths instead of the posters - maybe some desks arranged around a room. Yoav ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Poster sessions
A poster session sounds cool, but it works well when the presenters are companies, rather than individuals. To get a good A0 poster, you need access to printing services (which are not cheap, but doable) and graphic design talent, which is neither cheap nor common in IETF attendees. To get such a poster up, I would need either my company's sponsorship, or else use my own talents in graphic design: Hmm, #12FF12. Now there's a nice shade of green for a background. As for fonts, let's go with Mistral, because http://www.cracked.com/funny-5647-fonts . Conferences (IEEE, ACM, ...) routinely have poster sessions, with mostly academic participation. Well-funded universities spend $50 at the local print shop or have an in-house large-size printer; not-so-well-funded universities simply print a dozen letter-size sheets and attach them to the board. Henning ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Poster sessions
+1 Regards, Ed J On 1/6/11, Marshall Eubanks t...@americafree.tv wrote: On Jan 6, 2011, at 5:16 AM, Yoav Nir wrote: On Jan 6, 2011, at 11:26 AM, Alessandro Vesely wrote: I've never attended an IETF meeting. Why? Because it seems to me quite unlikely to have a chance to say something useful by going there. I mean useful with respect to a problem that I consider important. That is, not just a minimal contribution to an already scheduled session that I may happen to attend. Perhaps, I should request a session... Problems are often expressed in the form of tentative solutions. Such solutions may occasionally happen to be discussed, refined, and agreed upon by a group of individuals. Implementation, standardization, and adoption may eventually follow --not necessarily in this order. Isn't this how the IRTF and the IETF should work? A poster session would be a sort of plenary, lasting a couple of hours or so, with posters hanged on numbered hardboard panels arranged along a walkway. A poster may be sized A0, or ~50 in, or consist of an equivalent number of smaller sheets. Posters may stay exposed for a few hours before/after the scheduled time period. During the session time, however, authors should stand beside their posters and thus have their chance to talk to any interested ietfers, one by one or in small knots, informally. A few dozens of posters per session may provide for adequate gathering. IME, this way of participating is easier and less binding for both authors and attendees. A poster would suit subjects for which it's difficult to carve a niche within a hosting WG's session, but it may also work as a means to achieve consensus on a given topic before raising it in a more official discussion. Opinions/suggestions? Hi Alessandro. Following the Maastricht meeting, there was a lively discussion of a similar issue. The way things are, you need a lot of support to present an idea at a BoF, so the usual way to present new things has become to publish a bar BoF and present there. Despite the name, the modern bar BoF is not held in a bar, but rather in the empty conference rooms during lunch time and late in the evening. Understandably, people don't like this much. There have been a few suggestions for alternate ways of presenting and gathering supporters. One such suggestion is in this draft: http://tools.ietf.org/html/draft-nir-non-wg-presentations-01 A poster session sounds cool, but it works well when the presenters are companies, rather than individuals. To get a good A0 poster, you need access to printing services (which are not cheap, but doable) and graphic design talent, which is neither cheap nor common in IETF attendees. To get such a poster up, I would need either my company's sponsorship, or else use my own talents in graphic design: Hmm, #12FF12. Now there's a nice shade of green for a background. As for fonts, let's go with Mistral, because http://www.cracked.com/funny-5647-fonts . I am neutral on the overall idea, but in many (most?) academic conferences in a poster session you get a pin board (hopefully with a bunch of pins), which lends itself well to pinning up a set of printed out slides. I have seen many fine poster session presentations from people with very little money, so I don't agree it unduly favors the well sponsored. And it has one great advantage... Seriously, though, most of the presentation slides you see in an IETF meeting are either black-on-white with way too much text, ... in that you can read the slides with too much text at your leisure if you want to, rather than having them flash by unread. I am not sure it would fit well with the IETF ecosystem, as it takes time to scan through a bunch of posters, and it takes time to stand by your poster and answer any questions, and time is always short at an IETF. Maybe we could just have them in the halls and call them a hall-BOF. Regards Marshall sometimes adding some default design from the software, or else they're extremely well designed, where you know there's been some company sponsorship. Some of the Internet-of-Things presentations in recent IETF meetings are examples of the latter. I think that's too high a bar to set for new ideas that still don't have much traction. It could be done with some booths instead of the posters - maybe some desks arranged around a room. Yoav ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Poster sessions
On Thu, 6 Jan 2011, Yoav Nir wrote: A poster session sounds cool, but it works well when the presenters are companies, rather than individuals. To get a good A0 poster, you need access to printing services (which are not cheap, but doable) and graphic design talent, which is neither cheap nor common in IETF attendees. To get such a poster up, I would need either my company's sponsorship, or else use my own talents in graphic design: Hmm, #12FF12. Now there's a nice shade of green for a background. As for fonts, let's go with Mistral, because http://www.cracked.com/funny-5647-fonts. My just completed her MS in Nutrition and Food Science. As part of her program she had to produce two posters. It turns out to be quite easy to use PowerPoint to create poster sized slides ... in one case a single very large slide and in the other, 3 slides, one per tri-fold panel. I forget what FedEx Office (aka Kinko's) would have charged, and our local large format print ship would have been less as the company I was working for allowed me to use their large format HP printer, but it was in the order of $200. Quite reasonable for someone to spend to put forth an idea they are passionate about with or without sponsorship. And as others have noted, printed pages fastened to a board is much cheaper. Seems like a few tables at one end of the break area could be setup if there are just a few such presentations at a meeting, or if this becomes popular, reserve a meeting room near the break area. Schedule a couple specific breaks/lunch times as Poster BOFs when the presenters would be there and include a list of topics, etc. in the meeting materials. Probably require an ID to backup the material. Dave Morris ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: Poster sessions
From: ietf-boun...@ietf.org [ietf-boun...@ietf.org] On Behalf Of Alessandro Vesely [ves...@tana.it] I've never attended an IETF meeting. Why? Because it seems to me quite unlikely to have a chance to say something useful by going there. I mean useful with respect to a problem that I consider important. That is, not just a minimal contribution to an already scheduled session that I may happen to attend. Perhaps, I should request a session... Problems are often expressed in the form of tentative solutions. Such solutions may occasionally happen to be discussed, refined, and agreed upon by a group of individuals. Implementation, standardization, and adoption may eventually follow --not necessarily in this order. Isn't this how the IRTF and the IETF should work? ___ If one has a tentative solution that one wants discussed, the usual technique is to submit an Internet-Draft discussing it and post an explanatory e-mail in a proper working group list. Consider it a 24x7 poster session! Dale ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: Fwd: FCC IPv6 Working Paper Released
From: ietf-boun...@ietf.org [ietf-boun...@ietf.org] On Behalf Of John Levine [jo...@iecc.com] This seems like a document that might interest some on this list... It's not bad, but it's basically a well written summary of the conventional wisdom about IPv6. As we all know, some of the conventional wisdom is more grounded in reality, some less. ___ Nonetheless, it's better than nothing -- the conventional wisdom is known by only a small subset of the people who ought to know it (and considerably more wisdom as well). Dale ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Poster sessions
Dale, I agree! I think the bar of producing an internet draft is low enough. Regardless of what mechanisms we adopt to give people a chance to try and sell their drafts, I think it is critical that we require the drafts to be written. I'm not really interested in lowering the bar too much for someone to put together an idea for consideration. I think we gain a fair bit by asking people to refine their idea a fair bit before the initial presentation. Writing a draft is one way of making sure that happens. Above, I'm commenting on the general problem of presenting an idea, not the more complicated question of what the bar should be for BOFs. I'm not surewhether that bar is in the right place. I'd need to think somewhat more about that. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Poster sessions
On 1/6/11 6:30 PM, Sam Hartman wrote: Dale, I agree! I think the bar of producing an internet draft is low enough. Regardless of what mechanisms we adopt to give people a chance to try and sell their drafts, I think it is critical that we require the drafts to be written. I'm not really interested in lowering the bar too much for someone to put together an idea for consideration. I think we gain a fair bit by asking people to refine their idea a fair bit before the initial presentation. Writing a draft is one way of making sure that happens. Above, I'm commenting on the general problem of presenting an idea, not the more complicated question of what the bar should be for BOFs. I'm not surewhether that bar is in the right place. I'd need to think somewhat more about that. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf Couldn't agree more. /Sal ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Poster sessions
On Jan 6, 2011, at 4:32 AM, Marshall Eubanks wrote: I am not sure it would fit well with the IETF ecosystem, as it takes time to scan through a bunch of posters, and it takes time to stand by your poster and answer any questions, and time is always short at an IETF. Maybe we could just have them in the halls and call them a hall-BOF. I like this idea. A few ideas for requirements: Slides MUST include the name of the draft so we can go read it in detail, and mention which WG or pre-WG mailing list the discussion is taking place on. If anyone puts an obvious product pitch on a poster, attendees SHOULD deface it with snarky post-it notes and smeared food. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: NAT behavior for IP ID field
Although this is a fairly old thread, I didn't see mention of the IPv4 ID draft we've been working on in INTAREA that addresses this: https://datatracker.ietf.org/doc/draft-ietf-intarea-ipv4-id-update/ It was updated last Oct. See esp. Sec 9. Joe On 8/31/2010 1:04 PM, John Kristoff wrote: I'm trying to locate an RFC that spells out the behavioral requirements, expectations or guidelines for NAT handling of the IP ID field, particularly for UDP messages. Section 3.2.5 in RFC 3235 briefly mentions issues surrounding IP fragmentation and reassembly, but it doesn't specifically say if NATs should re-write IDs as a general rule. RFC 4787 doesn't seem to address this either. If this is not written down anywhere, do NATs generally rewrite the ID field with or without the MF bit set? For background and reference, I refer you to Steve Bellovin's 'A Technique for Counting NATted Hosts', particularly section IV. Thanks for any pointers, John ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Win a free trip to Washington DC and the FCC.
The FCC challenges researchers and software developers to engage in research and create apps that help consumers foster, measure, and protect Internet openness. http://challenge.gov/FCC/114-fcc-open-internet-apps-challenge Richard Shockey Shockey Consulting Chairman of the Board of Directors SIP Forum PSTN Mobile: +1 703.593.2683 mailto:richard(at)shockey.us mailto:richard(at)shockey.us skype-linkedin-facebook: rshockey101 http//www.sipforum.org ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: Poster sessions
From: Sam Hartman [hartmans-i...@mit.edu] I think the bar of producing an internet draft is low enough. Regardless of what mechanisms we adopt to give people a chance to try and sell their drafts, I think it is critical that we require the drafts to be written. Actually, the bar for writing an I-D is near zero, so it should not be a barrier to presenting any idea, no matter how half-baked. A more significant effect is that an I-D is in text form rather than poster form so it tends to direct the writer to a more thought-through presentation. But most importantly, an I-D is globally available and globally announced, whereas a poster session at an IETF meeting would be inherently limited to those physically present, which is biased toward frequent attendees, those with sponsorship from large organizations, and those from the developed world. Historically, the IETF has tried to limit biases in favor of those groups. Dale ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Old transport-layer protocols to Historic?
Historic might imply that they were once in service, but have later been replaced/deprecated. In fact, these protocols were always, and are still, *experimental*. It would seem logical to assign them the Experimental category and be done with it. Bob Braden On 1/5/2011 9:44 PM, Mykyta Yevstifeyev wrote: Hello all, There have been a discussion on tsvwg mailing list about old transport layer protocols - exactly IRTP (RFC938), RDP (RFC908,1151) and NETBLT (RFC998). Initially there have been proposed to define IANA considerations for them. But after a discussion it was found out that it would be better to move them to Historic. I am writing to request more wider discussion on this topic. There is quite strong consensus that IRTP should be Historic. There is a registered draft on this topic: https://datatracker.ietf.org/doc/draft-yevstifeyev-tsvwg-irtp-to-historic/ But as for others it should be discussed. Moreover, maybe anyone knows some other old transport-layer protocols that are no longer in use? Please copy tour answer to ts...@ietf.org All the best, Mykyta Yevstifeyev ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Old transport-layer protocols to Historic?
On 01/06/2011 15:40 EST, Bob Braden wrote: Historic might imply that they were once in service, but have later been replaced/deprecated. In fact, these protocols were always, and are still, *experimental*. It would seem logical to assign them the Experimental category and be done with it. Bob Braden Yup. On 1/5/2011 9:44 PM, Mykyta Yevstifeyev wrote: Hello all, There have been a discussion on tsvwg mailing list about old transport layer protocols - exactly IRTP (RFC938), RDP (RFC908,1151) and NETBLT (RFC998). Initially there have been proposed to define IANA considerations for them. But after a discussion it was found out that it would be better to move them to Historic. I am writing to request more wider discussion on this topic. There is quite strong consensus that IRTP should be Historic. There is a registered draft on this topic: https://datatracker.ietf.org/doc/draft-yevstifeyev-tsvwg-irtp-to-historic/ But as for others it should be discussed. Moreover, maybe anyone knows some other old transport-layer protocols that are no longer in use? Please copy tour answer to ts...@ietf.org All the best, Mykyta Yevstifeyev ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Old transport-layer protocols to Historic?
On Jan 6, 2011, at 12:40 PM, Bob Braden wrote: Historic might imply that they were once in service, but have later been replaced/deprecated. In fact, these protocols were always, and are still, *experimental*. It would seem logical to assign them the Experimental category and be done with it. Bob Braden I would like to second Bob's position here. as a co-author for NETBLT (RFC998): NETBLT was out of a research effort to answer the question: can we *fully* utilize long delay, high bandwidth (and potentially error prone) networks? NETBLT says and here is one way to do it. Over the years (it's published in 1987) I have received comments from many people saying that they learned something interesting or even useful from NETBLT. The NETBLT paper (SIGCOMM 1987) got cited over 200 times. As RFC998 stated clearly: This document is published for discussion and comment, and does not constitute a standard. The proposal may change and certain parts of the protocol have not yet been specified; implementation of this document is therefore not advised. I don't see any harm to keep it as is. Lixia PS: on the other hand, what would a historical status imply? the ideas obsolete? On 1/5/2011 9:44 PM, Mykyta Yevstifeyev wrote: Hello all, There have been a discussion on tsvwg mailing list about old transport layer protocols - exactly IRTP (RFC938), RDP (RFC908,1151) and NETBLT (RFC998). Initially there have been proposed to define IANA considerations for them. But after a discussion it was found out that it would be better to move them to Historic. I am writing to request more wider discussion on this topic. There is quite strong consensus that IRTP should be Historic. There is a registered draft on this topic: https://datatracker.ietf.org/doc/draft-yevstifeyev-tsvwg-irtp-to-historic/ But as for others it should be discussed. Moreover, maybe anyone knows some other old transport-layer protocols that are no longer in use? Please copy tour answer to ts...@ietf.org All the best, Mykyta Yevstifeyev ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: Old transport-layer protocols to Historic?
Lixia Zhang lixia at cs dot ucla dot edu wrote: PS: on the other hand, what would a historical status imply? the ideas obsolete? Every now and then, someone proposes to move a given RFC to Historic, not merely to reflect an observation that a process or protocol is obsolete, but as an active attempt to deprecate it, regardless of its currency or relevance. I remember a few months ago, it was proposed (evidently not for the first time) to move FTP to Historic, on the basis of its lack of airtight 21st-century security features, with no consideration for the innumerable existing systems and processes that have no need for top-notch security, and rely daily on FTP. I often see comments on this list about whether the outside world views the IETF as irrelevant. Declaring a commonly used, core process or protocol as Historic because something better exists might be a perfect example of this. -- Doug Ewell | Thornton, Colorado, USA | http://www.ewellic.org RFC 5645, 4645, UTN #14 | ietf-languages @ is dot gd slash 2kf0s ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Gen-ART LC Review of draft-zeilenga-ldap-dontusecopy-08
Ben, Thank you for your comments. They have lead to a number of improvements in the I-D (new revision to be published shortly). A few notes below. -- Kurt On Oct 11, 2010, at 2:39 PM, Ben Campbell wrote: I am the assigned Gen-ART reviewer for this draft. For background on Gen-ART, please see the FAQ at http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq. Please resolve these comments along with any other Last Call comments you may receive. Document: draft-zeilenga-ldap-dontusecopy-08 Reviewer: Ben Campbell Review Date: 2010-10-11 IETF LC End Date: 2010-10-11 IESG Telechat date: (if known) Summary: This draft is almost ready to be published as a proposed standard, but I have some comments that should be considered first. Major issues: None Minor issues: -- General: (Let me preface my general comments with the admission that I am not an LDAP expert. Since this is a Gen-ART review, I'm approaching this as a generalist. If the answer is something like Ben, if you new anything about LDAP this would all be obvious to you, that will not offend me in any way.) I'd like to see more explanation of the problem this needs to be solved. The short explanation is that acting upon slate data can introduce security vulnerabilities in directory applications. Exactly how a directory application might be vulnerable depends a great deal on the particulars of the directory application. The intent of this specification is merely to provide a tool, long present in X.500 directory applications, to LDAP directory applications. I assume that there is concern that copied or cached data may not be up to date, or otherwise not be authoritative. Some comments to that effect, along with reasoning for why this may happen in the first place would be helpful. A quick scan of 4511 and 4512 didn't turn up much about this, other than some passing references that some servers may shadow or cache dats from other servers., and not to accept modification requests against cached or shadowed data. Is there any other specification about LDAP cacheing, maintaining cache freshness, etc? The reference, I guess, would be X.500 series of documents. LDAP is specified as alternative access protocol to an X.500 directory service. While this document only has an informative reference to its X.500 counterpart, I note that this document does contain a normative reference to the LDAP technical specification [RFC4510] which does include normative references to relevant X.500 specifications. I do not reference X.500 normatively here as I believe a developer can well implement this control, by itself, without ever having read a X.500 specification. I get a gut feeling that this extension effectively patches a hole in an implied delegation model for LDAP, but I don't find much in the way of explicit specification for that in the referenced docs (Maybe I should be looking at X.500 specs?). I'm not saying that this document should be burdened with a formal specification of the LDAP delegation model. But I think a little more context would be helpful. I really don't think it necessary to understand the particulars the X.500/LDAP delegation model to understand when and how this control ought to be used. Basically, some knowledge a server might rely on in answering a question can be stale. Use of stale data can be problematic. This control says don't use stale data. I'd also like to see some more guidance on when it's reasonable to use this extension. For example, wouldn't a client always want an authoritative answer to an interrogation? Generally, clients should only use this control when there is a directory application need for it to be used. Why wouldn't it use this extension all the time? Because that would eliminate all the benefits of caching and shadowing of data. Does it hurt anything if it does? It can break the application. In general, applications ought to be designed to well use copied information. Anyways, I'll make some minor tweaks here to address these points. -- section 3, 2nd paragraph: I think this paragraph might be better restated normatively. I'm not sure what you mean by normatively as I feel it obvious that whole section a normative part of the specification. I guess what you might mean is use RFC 2119 keywords here. I rather not. Aside from RFC 2119 saying keywords ought to be sparingly, to me, MUST and SHOULDs are best used to impart implementation requirements and recommendations, especially those which if not followed will result in some significant peculiar behavior. -- section 4: The security consideration comments seem to be about caching in general. Does this extension make things any better or worse? The extension is a tool which, if used well, can be used to mitigate certain threats. I'll be replacing the security considerations text with the text provided by Phillip Hallam-Baker
Re: Poster sessions
Firstly, I agree: as a general rule, to get official floor space of any kind at the IETF venue, you SHOULD have posted a draft. If there is no draft, that is exactly when you need a bar BOF. (Complicated joke about the height of the bar for a bar BOF, and the drafts to be drunk, goes here.) Second, a number of operators' meetings have a session for lightning talks with minimal formality. But in practice, we have that at most Area Meetings - post a relevant draft, ask the ADs for a 5 minute slot, and you usually get it. So I'm not sure that we have a gap in our options. I'm more likely to read a draft with an interesting title than to walk around reading hard-copy posters. Regards Brian Carpenter On 2011-01-07 09:16, Worley, Dale R (Dale) wrote: From: Sam Hartman [hartmans-i...@mit.edu] I think the bar of producing an internet draft is low enough. Regardless of what mechanisms we adopt to give people a chance to try and sell their drafts, I think it is critical that we require the drafts to be written. Actually, the bar for writing an I-D is near zero, so it should not be a barrier to presenting any idea, no matter how half-baked. A more significant effect is that an I-D is in text form rather than poster form so it tends to direct the writer to a more thought-through presentation. But most importantly, an I-D is globally available and globally announced, whereas a poster session at an IETF meeting would be inherently limited to those physically present, which is biased toward frequent attendees, those with sponsorship from large organizations, and those from the developed world. Historically, the IETF has tried to limit biases in favor of those groups. Dale ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Weekly posting summary for ietf@ietf.org
Total of 66 messages in the last 7 days. script run at: Fri Jan 7 00:53:02 EST 2011 Messages | Bytes| Who +--++--+ 7.58% |5 | 8.21% |45451 | rbar...@bbn.com 1.52% |1 | 13.58% |75158 | mohamed.boucad...@orange-ftgroup.com 3.03% |2 | 9.82% |54374 | stpe...@stpeter.im 4.55% |3 | 6.14% |33997 | y...@checkpoint.com 6.06% |4 | 3.76% |20841 | dwor...@avaya.com 4.55% |3 | 4.91% |27197 | hal...@gmail.com 4.55% |3 | 3.22% |17841 | t...@americafree.tv 4.55% |3 | 2.32% |12830 | jo...@iecc.com 3.03% |2 | 3.61% |20010 | ron.even@gmail.com 3.03% |2 | 2.08% |11512 | scott.b...@gmail.com 3.03% |2 | 1.52% | 8403 | mo...@necom830.hpcl.titech.ac.jp 1.52% |1 | 2.64% |14630 | karlheinz.w...@nic.at 1.52% |1 | 2.08% |11521 | jsalo...@cisco.com 1.52% |1 | 1.74% | 9620 | kurt.zeile...@isode.com 1.52% |1 | 1.71% | 9479 | edj@gmail.com 1.52% |1 | 1.69% | 9361 | rolf.win...@neclab.eu 1.52% |1 | 1.44% | 7961 | rich...@shockey.us 1.52% |1 | 1.30% | 7184 | d...@dcrocker.net 1.52% |1 | 1.27% | 7009 | s...@cs.columbia.edu 1.52% |1 | 1.26% | 6948 | daedu...@btconnect.com 1.52% |1 | 1.24% | 6876 | brian.e.carpen...@gmail.com 1.52% |1 | 1.21% | 6717 | jmp...@cisco.com 1.52% |1 | 1.16% | 6398 | nar...@us.ibm.com 1.52% |1 | 1.15% | 6367 | christer.holmb...@ericsson.com 1.52% |1 | 1.13% | 6237 | li...@cs.ucla.edu 1.52% |1 | 1.09% | 6026 | hartm...@painless-security.com 1.52% |1 | 1.06% | 5887 | mansa...@besserwisser.org 1.52% |1 | 1.04% | 5753 | d...@xpasc.com 1.52% |1 | 1.04% | 5739 | john-i...@jck.com 1.52% |1 | 0.99% | 5482 | j...@jlc.net 1.52% |1 | 0.99% | 5468 | salvatore.lor...@ericsson.com 1.52% |1 | 0.98% | 5443 | hartmans-i...@mit.edu 1.52% |1 | 0.97% | 5397 | elw...@dial.pipex.com 1.52% |1 | 0.97% | 5390 | ves...@tana.it 1.52% |1 | 0.94% | 5227 | p...@cisco.com 1.52% |1 | 0.94% | 5207 | tobias.gond...@gondrom.org 1.52% |1 | 0.88% | 4884 | jdfalk-li...@cybernothing.org 1.52% |1 | 0.86% | 4783 | bra...@isi.edu 1.52% |1 | 0.85% | 4723 | d...@ewellic.org 1.52% |1 | 0.85% | 4715 | to...@isi.edu 1.52% |1 | 0.84% | 4642 | o...@cisco.com 1.52% |1 | 0.83% | 4605 | h...@cs.columbia.edu 1.52% |1 | 0.79% | 4389 | a...@nostrum.com 1.52% |1 | 0.77% | 4272 | f...@cisco.com 1.52% |1 | 0.77% | 4241 | a.k...@sh.cvut.cz 1.52% |1 | 0.72% | 3961 | jari.ar...@piuha.net 1.52% |1 | 0.63% | 3467 | j...@mercury.lcs.mit.edu +--++--+ 100.00% | 66 |100.00% | 553623 | Total ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Old transport-layer protocols to Historic?
06.01.2011 23:45, Doug Ewell wrote: Lixia Zhanglixia at cs dot ucla dot edu wrote: PS: on the other hand, what would a historical status imply? the ideas obsolete? Every now and then, someone proposes to move a given RFC to Historic, not merely to reflect an observation that a process or protocol is obsolete, but as an active attempt to deprecate it, regardless of its currency or relevance. I remember a few months ago, it was proposed (evidently not for the first time) to move FTP to Historic, on the basis of its lack of airtight 21st-century security features, with no consideration for the innumerable existing systems and processes that have no need for top-notch security, and rely daily on FTP. I often see comments on this list about whether the outside world views the IETF as irrelevant. Declaring a commonly used, core process or protocol as Historic because something better exists might be a perfect example of this. I think that the author of RFC2026 was wrong while writing the definition of Historic status. This document says that Historic should be assigned only to that documents that were standards and now are obsolete. But why do we need such narrow definition? Non-standards RFCs are not made Historic while obsoleting, according to 2026. Moreover, such status will just duplicate the obsoleted-by one. When there will be the attempt to revise RFC 2026, we should put there that Historic status is to be assigned to that documents that are considered to be /deprecated/. I fully share the opinion of Doug here. As for NETBLT, I am strongly against moving it to Historic, rather than specifying by Standards Track Document. There has been one attempt to do that by John White in 1995 (see draft-white-protocol-stack), but IMO (that likes strange, but...) we can align this document with the most current needs of Internet and publish. Mykyta -- Doug Ewell | Thornton, Colorado, USA | http://www.ewellic.org RFC 5645, 4645, UTN #14 | ietf-languages @ is dot gd slash 2kf0s ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Old transport-layer protocols to Historic?
I have also seen attempts to make a standard Historic with the supposed reason being to clear things out for the introduction of some better replacement. That seems like just nonsense to me. If it is so obvious that a replacement is superior, the replacement document can do the move of earlier document to Historic... Thanks, Donald = Donald E. Eastlake 3rd +1-508-333-2270 (cell) 155 Beaver Street Milford, MA 01757 USA +1-508-634-2066 (home) d3e...@gmail.com On Thu, Jan 6, 2011 at 4:45 PM, Doug Ewell d...@ewellic.org wrote: Lixia Zhang lixia at cs dot ucla dot edu wrote: PS: on the other hand, what would a historical status imply? the ideas obsolete? Every now and then, someone proposes to move a given RFC to Historic, not merely to reflect an observation that a process or protocol is obsolete, but as an active attempt to deprecate it, regardless of its currency or relevance. I remember a few months ago, it was proposed (evidently not for the first time) to move FTP to Historic, on the basis of its lack of airtight 21st-century security features, with no consideration for the innumerable existing systems and processes that have no need for top-notch security, and rely daily on FTP. I often see comments on this list about whether the outside world views the IETF as irrelevant. Declaring a commonly used, core process or protocol as Historic because something better exists might be a perfect example of this. -- Doug Ewell | Thornton, Colorado, USA | http://www.ewellic.org RFC 5645, 4645, UTN #14 | ietf-languages @ is dot gd slash 2kf0s ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Old transport-layer protocols to Historic?
07.01.2011 8:30, Donald Eastlake wrote: I have also seen attempts to make a standard Historic with the supposed reason being to clear things out for the introduction of some better replacement. That seems like just nonsense to me. If it is so obvious that a replacement is superior, the replacement document can do the move of earlier document to Historic... As I've mentioned before, I think that the problem is the definition of Historic status. It is not correct. It duplicates the obsoleted-by status (if that can be called like this). It is really inappropriate for its real reason - indicating the deprecated (but not obsoleted) docs. Moreover, 'obsoleted' means the same as 'deprecated' or 'non-current' (see http://www.synonym.com/synonyms/obsolete/ or http://dictionary.sensagent.com/obsolete/en-en/#synonyms). So it is a problem in RFC2026. All the best, Mykyta Yevstifeyev Thanks, Donald = Donald E. Eastlake 3rd +1-508-333-2270 (cell) 155 Beaver Street Milford, MA 01757 USA +1-508-634-2066 (home) d3e...@gmail.com On Thu, Jan 6, 2011 at 4:45 PM, Doug Ewelld...@ewellic.org wrote: Lixia Zhanglixia at cs dot ucla dot edu wrote: PS: on the other hand, what would a historical status imply? the ideas obsolete? Every now and then, someone proposes to move a given RFC to Historic, not merely to reflect an observation that a process or protocol is obsolete, but as an active attempt to deprecate it, regardless of its currency or relevance. I remember a few months ago, it was proposed (evidently not for the first time) to move FTP to Historic, on the basis of its lack of airtight 21st-century security features, with no consideration for the innumerable existing systems and processes that have no need for top-notch security, and rely daily on FTP. I often see comments on this list about whether the outside world views the IETF as irrelevant. Declaring a commonly used, core process or protocol as Historic because something better exists might be a perfect example of this. -- Doug Ewell | Thornton, Colorado, USA | http://www.ewellic.org RFC 5645, 4645, UTN #14 | ietf-languages @ is dot gd slash 2kf0s ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RFC 6061 on Uniform Resource Name (URN) Namespace for the National Emergency Number Association (NENA)
A new Request for Comments is now available in online RFC libraries. RFC 6061 Title: Uniform Resource Name (URN) Namespace for the National Emergency Number Association (NENA) Author: B. Rosen Status: Informational Stream: IETF Date: January 2011 Mailbox:b...@brianrosen.net Pages: 7 Characters: 14145 Updates/Obsoletes/SeeAlso: None I-D Tag:draft-rosen-urn-nena-03.txt URL:http://www.rfc-editor.org/rfc/rfc6061.txt This document describes the Namespace Identifier (NID) nena for Uniform Resource Name (URN) resources published by the National Emergency Number Association (NENA). NENA defines and manages resources that utilize this URN model. Management activities for these and other resource types are provided by the NENA Registry System (NRS). This document is not an Internet Standards Track specification; it is published for informational purposes. INFORMATIONAL: This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see http://www.ietf.org/mailman/listinfo/ietf-announce http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html. For downloading RFCs, see http://www.rfc-editor.org/rfc.html. Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-edi...@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
RFC 6070 on PKCS #5: Password-Based Key Derivation Function 2 (PBKDF2) Test Vectors
A new Request for Comments is now available in online RFC libraries. RFC 6070 Title: PKCS #5: Password-Based Key Derivation Function 2 (PBKDF2) Test Vectors Author: S. Josefsson Status: Informational Stream: IETF Date: January 2011 Mailbox:si...@josefsson.org Pages: 5 Characters: 7334 Updates/Obsoletes/SeeAlso: None I-D Tag:draft-josefsson-pbkdf2-test-vectors-06.txt URL:http://www.rfc-editor.org/rfc/rfc6070.txt This document contains test vectors for the Public-Key Cryptography Standards (PKCS) #5 Password-Based Key Derivation Function 2 (PBKDF2) with the Hash-based Message Authentication Code (HMAC) Secure Hash Algorithm (SHA-1) pseudorandom function. This document is not an Internet Standards Track specification; it is published for informational purposes. INFORMATIONAL: This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see http://www.ietf.org/mailman/listinfo/ietf-announce http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html. For downloading RFCs, see http://www.rfc-editor.org/rfc.html. Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-edi...@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
