Re: Retention of blue sheets
At 07:03 30-07-2009, Samuel Weiler wrote: During the plenary yesterday, it came out that the IETF has retained the working group attendance sheets (blue sheets) from previous meetings, and those are occasionally the subject of subpoenas. In the interest of minimizing IETF overhead and reducing legal risks to individual participants, I'd like to see those old records destroyed. And, though there appeared to be a variety of opinions, it sounded like I wasn't alone in this. It was pointed out during the reply that the cost of retaining the blue sheets is minimal. Marshall has provided some background information about the physical material held by the IETF Trust and their documentation retention policy (see http://www.ietf.org/mail-archive/web/ietf/current/msg57844.html ). The blue sheets are one of the few artifacts of Working Group sessions for the last eighteen years. As they are not a burden to the IETF, it is better to preserve them for history. There hasn't been any argument about how the legal risk to some individual participants would be reduced by not having a record of the presence of the individual at a specific location at a given point in time. The reason typically given for the attendance lists is planning meeting room capacity. That may have been the reason at some point. Minute takers have used the blue sheets to find out how a participant's name is spelled. What harms would come from destroying those old records and/or not collecting such details in the future? And how widespread is the support for destroying them? For the sake of openness and transparency, it is better to have an record of participation. That can be at odds with the corporate mindset where harm is assessed in terms of legal risk. There will likely be a bluesheet experiment at IETF 76. Regards, -sm ___ 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
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
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: IETF74 T-Shirt Art Donated to IETF Trust
Gregory M. Lebovitz gregory.i...@gmail.com 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
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: 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 Savolapek...@netcore.fi 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
Re: Retention of blue sheets
--On Thursday, July 30, 2009 16:09 -0700 Stephan Wenger st...@stewe.org 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
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 rel, Link:) and at the phrasing level (a rel, area rel). 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: [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
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 d...@dcrocker.net 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
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 d...@dcrocker.net 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/74attendeesfaint_grain.jpgimstp_animation_butterflies_fr_020908.gif___ 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
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
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: 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: 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
Last Call: draft-ietf-krb-wg-cross-problem-statement (Problem statement on the cross-realm operation of Kerberos) to Informational RFC
The IESG has received a request from the Kerberos WG (krb-wg) to consider the following document: - 'Problem statement on the cross-realm operation of Kerberos ' draft-ietf-krb-wg-cross-problem-statement-04.txt 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 i...@ietf.org mailing lists by 2009-08-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://www.ietf.org/internet-drafts/draft-ietf-krb-wg-cross-problem-statement-04.txt IESG discussion can be tracked via https://datatracker.ietf.org/public/pidtracker.cgi?command=view_iddTag=16482rfc_flag=0 ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
Last Call: draft-ietf-pkix-authorityclearanceconstraints (Clearance Attribute and Authority Clearance Constraints Certificate Extension) to Proposed Standard
The IESG has received a request from the Public-Key Infrastructure (X.509) WG (pkix) to consider the following document: - 'Clearance Attribute and Authority Clearance Constraints Certificate Extension ' draft-ietf-pkix-authorityclearanceconstraints-02.txt as a Proposed Standard 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 i...@ietf.org mailing lists by 2009-08-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://www.ietf.org/internet-drafts/draft-ietf-pkix-authorityclearanceconstraints-02.txt IESG discussion can be tracked via https://datatracker.ietf.org/public/pidtracker.cgi?command=view_iddTag=17987rfc_flag=0 ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
Last Call: draft-turner-clearancesponsor-attribute (Clearance Sponsor Attribute) to Informational RFC
The IESG has received a request from an individual submitter to consider the following document: - 'Clearance Sponsor Attribute ' draft-turner-clearancesponsor-attribute-01.txt 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 i...@ietf.org mailing lists by 2009-08-28. 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://www.ietf.org/internet-drafts/draft-turner-clearancesponsor-attribute-01.txt IESG discussion can be tracked via https://datatracker.ietf.org/public/pidtracker.cgi?command=view_iddTag=17755rfc_flag=0 ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
Last Call: draft-turner-deviceowner-attribute (Device Owner Attribute) to Informational RFC
The IESG has received a request from an individual submitter to consider the following document: - 'Device Owner Attribute ' draft-turner-deviceowner-attribute-01.txt 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 i...@ietf.org mailing lists by 2009-08-28. 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://www.ietf.org/internet-drafts/draft-turner-deviceowner-attribute-01.txt IESG discussion can be tracked via https://datatracker.ietf.org/public/pidtracker.cgi?command=view_iddTag=17756rfc_flag=0 ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
RFC 5587 on Extended Generic Security Service Mechanism Inquiry APIs
A new Request for Comments is now available in online RFC libraries. RFC 5587 Title: Extended Generic Security Service Mechanism Inquiry APIs Author: N. Williams Status: Standards Track Date: July 2009 Mailbox:nicolas.willi...@sun.com Pages: 16 Characters: 32002 Updates/Obsoletes/SeeAlso: None I-D Tag:draft-ietf-kitten-extended-mech-inquiry-06.txt URL:http://www.rfc-editor.org/rfc/rfc5587.txt This document introduces new application programming interfaces (APIs) to the Generic Security Services API (GSS-API) for extended mechanism attribute inquiry. These interfaces are primarily intended to reduce instances of hardcoding of mechanism identifiers in GSS applications. These interfaces include mechanism attributes and attribute sets, a function for inquiring the attributes of a mechanism, a function for indicating mechanisms that possess given attributes, and a function for displaying mechanism attributes. [STANDARDS TRACK] This document is a product of the Kitten (GSS-API Next Generation) Working Group of the IETF. This is now a Proposed Standard Protocol. STANDARDS TRACK: This document specifies an Internet standards track protocol for the Internet community,and requests discussion and suggestions for improvements. Please refer to the current edition of the Internet Official Protocol Standards (STD 1) for the standardization state and status of this protocol. 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 USC/Information Sciences Institute ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
RFC 5594 on Report from the IETF Workshop on Peer-to-Peer (P2P) Infrastructure, May 28, 2008
A new Request for Comments is now available in online RFC libraries. RFC 5594 Title: Report from the IETF Workshop on Peer-to-Peer (P2P) Infrastructure, May 28, 2008 Author: J. Peterson, A. Cooper Status: Informational Date: July 2009 Mailbox:jon.peter...@neustar.biz, acoo...@cdt.org Pages: 28 Characters: 61652 Updates/Obsoletes/SeeAlso: None I-D Tag:draft-p2pi-cooper-workshop-report-01.txt URL:http://www.rfc-editor.org/rfc/rfc5594.txt This document reports the outcome of a workshop organized by the Real-time Applications and Infrastructure Area Directors of the IETF to discuss network delay and congestion issues resulting from increased Peer-to-Peer (P2P) traffic volumes. The workshop was held on May 28, 2008 at MIT in Cambridge, MA, USA. The goals of the workshop were twofold: to understand the technical problems that ISPs and end users are experiencing as a result of high volumes of P2P traffic, and to begin to understand how the IETF may be helpful in addressing these problems. Gaining an understanding of where in the IETF this work might be pursued and how to extract feasible work items were highlighted as important tasks in pursuit of the latter goal. The workshop was very well attended and produced several work items that have since been taken up by members of the IETF community. This memo provides information for the Internet community. 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 USC/Information Sciences Institute ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
