Re: IETF74 T-Shirt Art Donated to IETF Trust
On Jul 31, 2009, at 9:40 PM, James M. Polk wrote: this is a choice between "how can the IETF get money?" That is something the Trust would have to think about. What we had been considering was literally licensing a t-shirt company to print the designs and enabling IETFers to order them. The monetary value to the IETF - the revenue stream - is very much TBD, and I wouldn't automatically assume it was large. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: IETF74 T-Shirt Art Donated to IETF Trust
On Jul 31, 2009, at 1:23 AM, Simon Josefsson wrote: I suggest the Trust considers T-shirt designs as code components so that the BSD license applies to it. :-) Do we have to write the license on the shirt, or can we use a URL? :-) ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [75attendees] IETF74 T-Shirt Art Donated to IETF Trust
On Jul 31, 2009, at 12:49 AM, Gregory M. Lebovitz wrote: Juniper has donated the art for the highly popular IETF74 San Francisco T-shirt (brown, IPv6 World Tour, "concert" concept) to the IETF Trust. Speaking as a Trustee, the Trust thanks Juniper for the donation. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: IETF74 T-Shirt Art Donated to IETF Trust
This is a cool design, I agree.
With that said, I think a discussion needs to occur on the
devaluation of the importance of what the shirt means - were it to be
distributed to any/many folks that did not attend an IETF.
There have been several other cool designs from IETFs past, most
notably is the one that the IETF refused to have a shirt for (i.e.,
IETF47 in Adelaide). I think that's still (for those who attended)
the most popular IETF shirt. I'll give Juniper credit (dare
I? ;-) that this is a very popular design.
So, this is a choice between "how can the IETF get money?" vs. the
purity that those that have an IETF shirt actually went to that
particular IETF meeting.
I realize this "purity" isn't really purity, given that I'm a rather
large man, and sometimes they don't have my size, so I get a size
that fits my wife or daughter. But the idea that there is one per
paid attendee remains.
I fear that advertising ("Joe's Bar/Grill & ISP") will become the
next step to gain revenue goals if we go down this path, but I might
be being too pessimistic...
James
BTW - I hate for this whole idea to devolve into this scenario -- the
event sponsor will sell the design of the shirt to the IETF, who
might believe they can earn more that it cost (sponsor fee plus COGS) in sales.
At 02:49 AM 7/31/2009, Gregory M. Lebovitz wrote:
I have been asked about this several times this week, so I'd like to
clarify here for all.
Juniper has donated the art for the highly popular IETF74 San
Francisco T-shirt (brown, IPv6 World Tour, "concert" concept) to the
IETF Trust. This was done because a) many people wanted to buy more
of these shirts, b) the IETF expressed an interest in fulfilling
those requests.
We hope this art can be leveraged to spread the message about IPv6
transition broadly across the Internet community, in a fun and cool
way . The ball is now in Ray (and team's) court.
Hope it helps, and enjoy,
the Juniper host team from IETF74
+++
IETF-related email from
Gregory M. Lebovitz
Juniper Networks
g r e go r y d o t i e tf a t g m a i l do t c o m
___
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: Last Call: draft-dawkins-nomcom-openlist (NominatingCommittee Process: Open Disclosure of Willing Nominees) to BCP
On Tue, Jul 28, 2009 at 01:15:20PM -0400, Thomas Narten wrote: > Can we please drop everything after the comma? (I'm not sure how to > reword it, since I think the only point that needs to be made is that > the nomcom as discretion not to publish names, for whatever reason.) The usual way to say that in English is "at its discretion". Which also carries the right connotation, I think. A -- Andrew Sullivan a...@shinkuro.com Shinkuro, Inc. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Usage of DNS UPDATE protocols by server applications to manage the DNS records they need on their own
On 31-Jul-2009, at 07:30, Tobias Markmann wrote: The protocol that seems to handle such DNS updates seems to be RFC 2136 which is around since 1997. I wonder how far this RFC is implemented among authoritative DNS servers and whether that RFC is the right approach to solve the problem of double DNS configuration. DNS UPDATE is wildly deployed and used. It forms an integral part of Microsoft's Active Directory, for example. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Retention of blue sheets
Way back in the early days of the IETF, the email address was used for adding people to the mailing list for the WG. But that was a long time ago, when many mailing lists weren't so automated. :-) -David Borman On Jul 31, 2009, at 9:06 AM, Pekka Savola wrote: On Fri, 31 Jul 2009, Brian E Carpenter wrote: I agree with Alissa that having an explicit privacy policy would be a good idea, but the fact of participation in an open standards process certainly cannot be considered a private matter. Exactly the opposite, in fact. Indeed, but why do the blue sheets ask for an email address? I'm not interested in receiving any mail (e.g. product advertisements loosely related to the IETF protocols) based on my writing my email on the blue sheets. I accept it's good for disambiguation though asking for affiliation might achieve the same. If anyone would be able to get the blue sheets, they probably shouldn't get the email addresses. Having to write a privacy policy would require ironing out these small details which might be a goog thing. -- Pekka Savola "You each name yourselves king, yet the Netcore Oykingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings ___ 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
OT : Skype may shut down as eBay battles founders
hey folks, sorry for my offtopic spam check this: http://money.ninemsn.com.au/article.aspx?id=844226 i cant believe at the end closed source eats itself *pmpl* regards MarcM -- Les enfants teribbles - research / deployment Marc Manthey Vogelsangerstrasse 97 D - 50823 Köln - Germany Vogelsangerstrasse 97 Geo: 50.945554, 6.920293 PGP/GnuPG: 0x1ac02f3296b12b4d Tel.:0049-221-29891489 Mobil:0049-1577-3329231 web : http://www.let.de Opinions expressed may not even be mine by the time you read them, and certainly don't reflect those of any other entity (legal or otherwise). Please note that according to the German law on data retention, information on every electronic information exchange with me is retained for a period of six months. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Réf. : Re: [74attendees] [75attendees] IETF74 T-Shirt Art Donated to IETFTrust
I think it's right. nice art, nice colour and wonderful design. Coko Tracy ---Message original--- De : Richard Barnes Date : 7/31/2009 12:00:00 PM A : dcroc...@bbiw.net Cc : ietf@ietf.org; 74attend...@ietf.org; 75attend...@ietf.org Sujet : Re: [74attendees] [75attendees] IETF74 T-Shirt Art Donated to IETFTrust It would seem in the open spirit if the IETF to make this a standing order for t-shirt art, wouldn't it? On Friday, July 31, 2009, Dave CROCKER wrote: > > > Gregory M. Lebovitz wrote: > > I have been asked about this several times this week, so I'd like to clarify here for all. > > Juniper has donated the art for the highly popular IETF74 San Francisco > > > > Greg, > > Many thanks! > > Especially in light of Bob Hinden's cautionary reference to the Wasa, at the Plenary, I suspect it would be worth exploring also obtaining the layered" art on the back of the t-shirt (and on the invitations) of the Wasa > > d/ > > -- > > Dave Crocker > Brandenburg InternetWorking > http://bbiw.net > ___ > 75attendees mailing list > 75attend...@ietf.org > https://www.ietf.org/mailman/listinfo/75attendees > ___ 74attendees mailing list 74attend...@ietf.org https://www.ietf.org/mailman/listinfo/74attendees<><>___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [75attendees] IETF74 T-Shirt Art Donated to IETF Trust
It would seem in the open spirit if the IETF to make this a standing order for t-shirt art, wouldn't it? On Friday, July 31, 2009, Dave CROCKER wrote: > > > Gregory M. Lebovitz wrote: > > I have been asked about this several times this week, so I'd like to clarify > here for all. > > Juniper has donated the art for the highly popular IETF74 San Francisco > > > > Greg, > > Many thanks! > > Especially in light of Bob Hinden's cautionary reference to the Wasa, at the > Plenary, I suspect it would be worth exploring also obtaining the "layered" > art on the back of the t-shirt (and on the invitations) of the Wasa. > > d/ > > -- > > Dave Crocker > Brandenburg InternetWorking > http://bbiw.net > ___ > 75attendees mailing list > 75attend...@ietf.org > https://www.ietf.org/mailman/listinfo/75attendees > ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [75attendees] IETF74 T-Shirt Art Donated to IETF Trust
Gregory M. Lebovitz wrote: I have been asked about this several times this week, so I'd like to clarify here for all. Juniper has donated the art for the highly popular IETF74 San Francisco Greg, Many thanks! Especially in light of Bob Hinden's cautionary reference to the Wasa, at the Plenary, I suspect it would be worth exploring also obtaining the "layered" art on the back of the t-shirt (and on the invitations) of the Wasa. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Last Call: draft-nottingham-http-link-header (Web Linking) to Proposed Standard
In general, I don't really understand what problem this draft is trying to solve. A clearer statement in the abstract or introduction explaining _why_ a common registry is a good thing would be very useful. It might also be worth considering separating the Link: header and the registry into two different specifications. This would also help clarify how a specification should refer to the registry. Comparing relation types case-sensitively (e.g. as in 4.2 Extension Relation Types) is incompatible with HTML's processing of rel=""; I would like to request that all relations always be case-insensitive. The Link: header has a "rev" attribute. I would recommend dropping it for consistency with HTML5; we discovered in examining typical usage that people generally didn't understand how to use rev="", and it is redundant with rel="" anyway. If it is kept, then please define how it works. Allowing something but leaving it undefined is the worst of both worlds. (The ideal would be to define how it works but not allow it, IMHO.) The link relations should better define how to handle interactions between multiple link types, so that alternate stylesheet can be well-defined, and so that we can define rel="up up up" as in HTML5. I recommend dropping the entire bit about profile="" -- while it sounds like the right thing to do, in practice almost nobody uses profile="", and the attribute has been dropped in HTML5. This is a lot of complexity without a particularly compelling use case as far as I can tell. The spec should clearly say which takes preference if both title= and title*= are given. Also, the spec should clearly say which takes preference if multiple title=, type=, etc, attributes are given. I think for the best compatibility with legacy implementations, the spec should say that there must only be one occurance of each attribute, and that multiple link types in one Link: header should be listed in one rel="" attribute. (That is, only allow rel="a b", not rel=a;rel=b.) Unless there are really strong use cases, I think that the anchor= attribute should be dropped. In practice, implementations today ignore that attribute, which would mean that, e.g., a rel=stylesheet;anchor=a link would fail to have the "right" effect. If it is kept, then the right behaviour for how this should integrate with style sheet linking should be defined in great detail. I would like to request that each link type be defined as either being a hyperlink or an external resource link, as defined in HTML5, and that this be added as one of the things that must be defined in the registry. Similarly, the registry should define whether or not link relations are allowed at the document level (, Link:) and at the phrasing level (, ). Some types in HTML5 only apply to one or the other. Ideally, I would like the Link: header section to more clearly define how some of the keywords defined in the spec should actually be used. For example, how should the rel=stylesheet keyword affect the CSSOM? Where do resources imported in this way fall in the CSS cascade? How should it affect documents with MIME types like text/plain? Do rel=icon links interact with those specified in the document? If so, where should they be considered as falling in terms of tree order? I would like to request that the registration mechanism be made significantly simpler than the one described in the spec. For example, a simple mechanism could be just to edit a wiki listing all the extensions. I would like to request some guidance on what HTML5 would have to do to be compatible with this draft, and what benefits would come from it. There are clear benefits to the Link: header section, assuming that how it fits into the general Web platform is defined (as requested above). But how does the registry fit into the RelExtensions registry for HTML5? How should they interact? The "up", "first", "last", and "payment" types are woefully underdefined. What is the expected UA behaviour when discovering a link with rel=payment? What are the authoring requirements? What are the implementation requirements? Cheers, -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.' ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Retention of blue sheets
--On Thursday, July 30, 2009 16:09 -0700 Stephan Wenger wrote: > Hi Brian, > > One can sit in a WG meeting for years, and never incur a > disclosure obligation under BCP78, correct? Just sitting > there and not saying/writing/contributing a thing does not > trigger a disclosure obligation. Same goes for merely being > subscribed to a mailing list. This is a major difference from > the organization where that infamous case law of Pete's has > had its playground. Stephan, This is going to be about as far from legal advice as you can get. If you need legal advice, consult you own attorney or try to get the Trust's to say something authoritative. However, as I read the Note Well, the intent of 5378, etc., I would think that, if you wanted to avoid any risk of someone claiming that you needed to disclose and having a judge agree with them, you should maintain a clean room attitude toward any WG for which you held IPR that you wanted to keep secret. "Clean room attitude" would presumably keep you out of its f2f meetings, off its mailing list, and maybe even off the IETF list when Last Calls were issued. In other words, while the strongest and most obvious obligations fall on Contributors, I believe that those documents can be read to require disclosure by anyone with a reasonable expectation of knowledge of the patent claim and a reasonable expectation of knowledge of what the IETF was doing in the area. Again, not only am I not a lawyer, but I am certainly not a likely candidate for judge in a hypothetical future patent case. But the costs of being wrong about a decision to not disclose a patent that you later assert can be high enough that I think someone who wants to play that game ought to be hyper-cautious. john ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Retention of blue sheets
Pekka, E-mail address are useful data. Anyhow, I would not able to replay to you without using your address ;-) and how to know which "John Smith" is the real participant? +1 for Brian Carpenter Thanks, Géza On Fri, Jul 31, 2009 at 9:06 AM, Pekka Savola wrote: > On Fri, 31 Jul 2009, Brian E Carpenter wrote: >> >> I agree with Alissa that having an explicit privacy policy would be a >> good idea, but the fact of participation in an open standards process >> certainly cannot be considered a private matter. Exactly the opposite, >> in fact. > > Indeed, but why do the blue sheets ask for an email address? I'm not > interested in receiving any mail (e.g. product advertisements loosely > related to the IETF protocols) based on my writing my email on the blue > sheets. I accept it's good for disambiguation though asking for affiliation > might achieve the same. If anyone would be able to get the blue sheets, > they probably shouldn't get the email addresses. Having to write a privacy > policy would require ironing out these small details which might be a goog > thing. > > -- > Pekka Savola "You each name yourselves king, yet the > Netcore Oy kingdom bleeds." > Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings > ___ > 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
Usage of DNS UPDATE protocols by server applications to manage the DNS records they need on their own
Hi, I'm currently looking for a convenient solution for the problem of manual configuration of DNS RRs. The usual setup is that you configure domain and IP relation in your DNS configuration, in zonefiles or some other kind of DB, and nearly the same configuration is done in your server application, may it be a HTTP, SMTP or XMPP server. In my opinion an ideal solution would be that the applications send the records they need to the master DNS server. This kind of DNS record management would be ideal for shared hosting providers or clustered server situations. I'm sure several shared hosting providers already deploy something of that kind but I haven't found a open documented way of doing this. After all one should aim for minimal configuration by humans to reduce the amount of errors being introduced by them. Sure, some manual configuration would still be needed in the DNS server for example, DNS records like SOA and NS and authentication information to authenticate applications (entities that want to send DNS updates) against the server. The protocol that seems to handle such DNS updates seems to be RFC 2136 which is around since 1997. I wonder how far this RFC is implemented among authoritative DNS servers and whether that RFC is the right approach to solve the problem of double DNS configuration. Cheers, Tobias Markmann ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: IETF74 T-Shirt Art Donated to IETF Trust
"Gregory M. Lebovitz" writes: > I have been asked about this several times this week, so I'd like to > clarify here for all. > > Juniper has donated the art for the highly popular IETF74 San > Francisco T-shirt (brown, IPv6 World Tour, "concert" concept) to the > IETF Trust. This was done because a) many people wanted to buy more of > these shirts, b) the IETF expressed an interest in fulfilling those > requests. > > We hope this art can be leveraged to spread the message about IPv6 > transition broadly across the Internet community, in a fun and cool > way . The ball is now in Ray (and team's) court. Great, thanks! I suggest the Trust considers T-shirt designs as code components so that the BSD license applies to it. :-) /Simon ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
IETF74 T-Shirt Art Donated to IETF Trust
I have been asked about this several times this week, so I'd like to clarify here for all. Juniper has donated the art for the highly popular IETF74 San Francisco T-shirt (brown, IPv6 World Tour, "concert" concept) to the IETF Trust. This was done because a) many people wanted to buy more of these shirts, b) the IETF expressed an interest in fulfilling those requests. We hope this art can be leveraged to spread the message about IPv6 transition broadly across the Internet community, in a fun and cool way . The ball is now in Ray (and team's) court. Hope it helps, and enjoy, the Juniper host team from IETF74 +++ IETF-related email from Gregory M. Lebovitz Juniper Networks g r e go r y d o t i e tf a t g m a i l do t c o m ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: On Thursday's Multipath TCP BOF
I see value in working on a "linked" congestion control scheme (work consisting in architecting and determining how efficient such scheme would be compared to current practice/congestion control schemes). I have a couple of comments/concerns though: - The BoF presentation considers that the TCP end-points controls routing of the traffic along a certain path in the network but routing information does not reach the end-points. So for what it concerns routing of the traffic, per TCP connection, there is no difference compared to the current situation (the network is not aware that two connections entering the network belong to the same "set"). This assumption is to be revisited because the "possible" paths towards (set of destinations) will be as provided by the routing system and means for triggering and enforcing diversity inside network is not achievable without additional mechanism (at the "networking layer" level). Note: The term "path" is from this perspective a bit confusing i.e. inverse multiplexed TCP or multi component TCP would probably better suite. - The BoF presentation considers that controlling onto which (sub-)connection the source puts traffic leads to offload the network from performing traffic engineering. Thus, I do not see how this would lead to a situation where the network would be free from any traffic engineering ? (I would even say the contrary, this would lead us back to the hyper-aggregation problem). - On the proposed scheme itself, if the end-points assumes that sub-connections (say between IP Address 1 and 2) can not be re-established after detecting their failures, the degraded state would remain permanent since the connection between Address 1 and 2 would not be re-established. So, it may be that some of the decisions taken by the end-points become detrimental. At this stage, it is not clear how to prevent such situation would happen. Note: also that some of the RTT numbers provided in the presentations are within recovery times achievable using fast re-routing schemes. Thanks, -dimitri. > -Original Message- > From: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On > Behalf Of Christian Vogt > Sent: Wednesday, July 29, 2009 10:59 PM > To: IETF Discussion Mailing List > Cc: Multipath TCP Mailing List > Subject: On Thursday's Multipath TCP BOF > > Dear all - > > Since I won't make it to tomorrow's Multipath TCP BOF unfortunately, I > would like to express my support for this effort by email. > > Multipath TCP promises to enable an attractive set of new features -- > ranging from automatic fail-over, to load-balancing, to mobility > support. Even though there are, of course, important challenges to be > surmounted, early analyses indicate the feasibility of the concept as > such. And the strong academic background and support from key IETF > folks ensures that people with clue and sufficient time will > work on it. > > Therefore, personally, I believe this BOF should be given a thumbs-up > for working group establishment. > > - Christian > > > ___ > 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: Retention of blue sheets
On Fri, 31 Jul 2009, Brian E Carpenter wrote: I agree with Alissa that having an explicit privacy policy would be a good idea, but the fact of participation in an open standards process certainly cannot be considered a private matter. Exactly the opposite, in fact. Indeed, but why do the blue sheets ask for an email address? I'm not interested in receiving any mail (e.g. product advertisements loosely related to the IETF protocols) based on my writing my email on the blue sheets. I accept it's good for disambiguation though asking for affiliation might achieve the same. If anyone would be able to get the blue sheets, they probably shouldn't get the email addresses. Having to write a privacy policy would require ironing out these small details which might be a goog thing. -- Pekka Savola "You each name yourselves king, yet the Netcore Oykingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
