Re: IETF Last Call for two IPR WG Dcouments
Olaf Kolkman skrev: While reviewing the documents I tried to determine how the 4 streams currently defined in RFC4844 fit into the framework. Although the stream is not specifically mentioned it is clear that the incoming rights document applies to the IETF Stream. That was my interpretation too. I (wearing my WG chair hat) take under advisement that this needs to be made clear, possibly with a 4844 reference. In the terms of pre-4844 terminology, I (wearing my contributor hat) always thought of IRTF and IAB streams as subsets of the non-IETF stream. To me it is clear that a contribution to the IAB is explicitly bound by the rules (including the No Duty to Publish rule, that allows for confidential information to be supplied to the IAB), so are contributions from the IAB, i.e. IAB stream document. I conclude this from the fact that IAB is part of the IETF under the definition in 1.e. However, I may be over-interpreting, and the status of the incoming rights for the IAB stream is also not captured. I think the IAB will have to make the rules for the IAB stream; a rule that says -incoming and -outgoing applies as appropriate would be nice and short - but it's not within the scope of an IETF WG to make that determination. Harald ___ IETF mailing list IETF@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: IETF Last Call for two IPR WG Dcouments
Simon Josefsson skrev: Regarding -outbound section 4.3: IETF contributions often include components intended to be directly processed by a computer. Examples of these include ABNF definitions, XML Schemas, XML DTDs, XML RelaxNG definitions, tables of values, MIBs, ASN.1, or classical programming code. These are included in IETF contributions for clarity and precision in specification. It is clearly beneficial, when such items are included in IETF contributions, to permit the inclusion of such code components in products which implement the contribution. It has been pointed out that in several important contexts use of such code requires the ability to modify the code. One common example of this is simply the need to adapt code for use in specific contexts (languages, compilers, tool systems, etc.) Such use frequently requires some changes to the text of the code from the IETF contribution. Another example is that code included in open source products is frequently licensed to permit any and all of the code to be modified. Since we want this code included in such products, it follows that we need to permit such modification. While there has been discussion of restricting the rights to make such modifications in some way, the rough consensus of the IETF is that such restrictions are likely a bad idea, and are certainly very complex to define. As such, the rough consensus is that the IETF Trust is to grant rights such that code components of IETF contributions can be extracted, modified, and used by anyone in any way desired. To enable the broadest possible extraction, modification and usage, the IETF Trust should avoid adding software license obligations beyond those already present in a contribution. The granted rights to extract, modify and use code should allow creation of derived works outside the IETF that may carry additional license obligations. ... I believe the intention here is good, but it leaves the IETF Trust with no guidelines on how to write the license declaration that is likely to work well in practice with actual products. There are no reference to what open source means in this context, and references to free software is missing. I believe it would be a complete failure if code-like portions of RFCs cannot be included into open source and free software products such as the Debian project. To give the Trust something concrete to work with I propose to add the following: To make sure the granted rights are usable in practice, they need to at least meet the requirements of the Open Source Definition [OSD], the Free Software Definition [FSD], and the Debian Free Software Guidelines [DFSG]. For those who fear that this will lead to complexity: releasing something that is compatible with those requirements is simple. The modified BSD license meets those requirements, as does a number of other methods, including releasing the work into the public domain. The references being: [OSD] The Open Source Definition, http://opensource.org/docs/osd [FSD] The Free Software Definition, http://www.fsf.org/licensing/essays/free-sw.html [DFSG] The Debian Free Software Guidelines, http://www.debian.org/social_contract#guidelines Thanks, Simon This has been considered in the WG and rejected, I believe - it was felt inappropriate to tie the IETF definitions to other organizations' definitions. In particular, it was felt inappropriate to do anything that might be interpreted as permitting copyleft requirements to be placed on source code from IETF documents. If the Trust is able to achieve compatibility, I'm all for it. Harlad ___ IETF mailing list IETF@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-klensin-rfc2821bis
agree with most of what you said, however: Since bad guys can deduce addresses by scanning --and will certainly do so if we make it sufficiently hard for them to use the DNS-- this type of DNS change, it seems to me, would have little effect on the antisocial. note that scanning is a lot harder in IPv6 than it was in IPv4, because such a large address space is delegated to a customer and the normal assumption of stateless address autoconfiguration implies that addresses are allocated sparsely within the last 64 bits. Keith ___ IETF mailing list IETF@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: IETF Last Call for two IPR WG Dcouments
Joel M. Halpern [EMAIL PROTECTED] writes: I am still left with the impression that adding references to specific licenses to the draft is going to be confusing, not helpful. If we started saying needs to be compatible with license X, Y, and Z then we have at least two problems. We would have to confirm that X, Y, and Z all met our goals. No, that is a misunderstanding. The IPR documents says that anyone should be able to use the code. If the license on code doesn't meet the requirements in OSD, FSD or DFSG, it fails to comply with that goal. Please read my original proposed wording again: To make sure the granted rights are usable in practice, they need to at least meet the requirements of the Open Source Definition [OSD], ^^ If the software license used fails to meet those requirements, it will fail to meet others too, and fail to meet the intended goal. And we would have to figure out why we should point to X, Y, and Z but not Q, W, or any other licenses that may be suitable as models. I don't see that. Note that the references I mentioned aren't licenses in the first place. Secondly, I don't see anything exclusive about listing these. We can list others as well, if you want. I have no problem with any individual suggesting to the Trustees that specific existing models may be a good way to achieve the stated goal. But adding references to example licenses, even if we were sure they matched our goals, will not help anyone understand the agreed goals. The existing statement is quite clear English. Please read what I proposed, those references aren't licenses. /Simon Yours, Joel M. Halpern Simon Josefsson wrote: Paul Hoffman [EMAIL PROTECTED] writes: At 7:30 PM +0200 3/30/08, Simon Josefsson wrote: Paul Hoffman [EMAIL PROTECTED] writes: These are interesting points, but maybe not interesting in the way you intended. If some large group (in this example, the Debian folks) want to have some restriction on what they can use in their software, that's fine. But that doesn't mean that the IETF needs to do anything beyond what it wants to do in order to cater to that group's current desires. Every such group could act just like the IETF does: look around at what the problems it is facing and change the way it acts based on an analysis of the problems. We disagree here. I believe the IETF has a responsibility to chose a license that works well for a large majority of Internet users. To some extents, the IETF needs to cater for organizations that make up parts of the Internet. So, then we clearly agree. Where we seem to disagree is whether it is possible to demand that the IETF cater to all the organizations that you want, or that I want, or * wants, or whatever. Right. Further, I believe the intention with the documents is to cater to everyone: grant rights such that code components of IETF contributions can be extracted, modified, and used by anyone in any way desired The complicated part is HOW that goal is achieved. It is easy to go wrong even with the best intentions. /Simon ___ 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: IETF Last Call for two IPR WG Dcouments
Peter Saint-Andre [EMAIL PROTECTED] writes: Given the fact that the Trust is supposed to meet on the 3rd Wednesday of each month but that as of today the most recent minutes posted at http://trustee.ietf.org/minutes.html are from 2007-06-21, I cannot say that I have much confidence regarding the Trust's commitment to open communication regarding its activities. I share that concern. I have requested that minutes should be posted a couple of times. There were no minutes posted since December 2005 just a few weeks ago. See: http://thread.gmane.org/gmane.ietf.general/29158 /Simon ___ IETF mailing list IETF@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: IETF Last Call for two IPR WG Dcouments
Ted Hardie [EMAIL PROTECTED] writes: At 12:11 PM -0700 3/30/08, Joel M. Halpern wrote: I am still left with the impression that adding references to specific licenses to the draft is going to be confusing, not helpful. If we started saying needs to be compatible with license X, Y, and Z then we have at least two problems. We would have to confirm that X, Y, and Z all met our goals. And we would have to figure out why we should point to X, Y, and Z but not Q, W, or any other licenses that may be suitable as models. I have no problem with any individual suggesting to the Trustees that specific existing models may be a good way to achieve the stated goal. But adding references to example licenses, even if we were sure they matched our goals, will not help anyone understand the agreed goals. The existing statement is quite clear English. Yours, Joel M. Halpern I agree with Joel. We're trying to give instructions to the Trust that cover the broadest possible user base; calling out specific licenses or user bases either appears to privilege them or adds no value at all. Suggesting to the Trustees that they consider specific licenses or, even better, pointing their lawyers at the potholes others have hit would be very useful. But this draft is not the place to do it. I believe the document is the place to do it. This is the only document were the IETF explains how the Trust should write its outgoing software license for code in RFCs. Useful considerations for that process should go into the document. My proposed text does not suggest specific licenses. That is a misunderstanding. /Simon ___ IETF mailing list IETF@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-klensin-rfc2821bis
On Sat, 29 Mar 2008, John Levine wrote: Getting rid of the fallback flips the default to be in line with reality -- most hosts don't want to receive mail directly, so if you're one of the minority that actually does, you affirmatively publish an MX to say so. I agree that this is the right thing to do in an ideal world. However there's a lot of old running code out there that implements the fallback. Is IPv6 still enough of a toy that the stability of its specifications doesn't matter? Tony (in two minds). -- f.anthony.n.finch [EMAIL PROTECTED] http://dotat.at/ ROCKALL MALIN: SOUTHERLY VEERING WESTERLY, 4 IN MALIN AT FIRST, OTHERWISE 7 TO SEVERE GALE 9. ROUGH BECOMING VERY ROUGH OR HIGH. RAIN OR SHOWERS. MODERATE OR GOOD, OCCASIONALLY POOR. ___ IETF mailing list IETF@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-klensin-rfc2821bis
I don't think this is a major issue, for two reasons: By the time that IPv6 mail becomes common, mail clients (and MTAs) will have been updated numerous times to deal with the security issue de jour. Secondly, even if a mail client or MTA were to erroneously implement this behavior, this causes no particular harm to the world at large, except bad error behavior for that particular MTA or MUA. Henning On Mar 31, 2008, at 7:58 AM, Tony Finch wrote: On Sat, 29 Mar 2008, John Levine wrote: Getting rid of the fallback flips the default to be in line with reality -- most hosts don't want to receive mail directly, so if you're one of the minority that actually does, you affirmatively publish an MX to say so. I agree that this is the right thing to do in an ideal world. However there's a lot of old running code out there that implements the fallback. Is IPv6 still enough of a toy that the stability of its specifications doesn't matter? Tony (in two minds). -- f.anthony.n.finch [EMAIL PROTECTED] http://dotat.at/ ROCKALL MALIN: SOUTHERLY VEERING WESTERLY, 4 IN MALIN AT FIRST, OTHERWISE 7 TO SEVERE GALE 9. ROUGH BECOMING VERY ROUGH OR HIGH. RAIN OR SHOWERS. MODERATE OR GOOD, OCCASIONALLY POOR. ___ 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
ISOC Fellowship to the IETF - seeking applicants for IETF 72 and IETF 73
[I am sorry if you receive this more than once.] Dear Colleagues, The Internet Society announces that it is seeking applications for the next round of the ISOC Fellowship to the IETF program. The program offers engineers from developing countries fellowships that fund the cost of attending an Internet Engineering Task Force (IETF) meeting. As you know, the IETF is the Internet's premier standards-making body, responsible for the development of protocols used in IP-based networks. IETF participants represent an international community of network designers, operators, vendors, and researchers involved in the technical operation of the Internet and the continuing evolution of Internet architecture. Fellowships will be awarded through a competitive application process. The Internet Society is currently accepting fellowship applications for the next two IETF meetings: * IETF 72 being held in Dublin, Ireland, 27 July - 1 August 2008 * IETF 73 being held in Minneapolis, 16 - 21 November 2008 Up to five fellowships will be awarded for each IETF meeting. Full details on the ISOC Fellowship to the IETF, including how to apply, are located on the ISOC website at : http://www.isoc.org/educpillar/fellowship Fellowship applications for both IETF meetings are due by 2 May 2008. The Internet Society formally launched the ISOC Fellowship to the IETF program in January 2007 after successfully piloting the program during 2006 at IETF 66 in Montreal and IETF 67 in San Diego. Fifteen individuals from 12 countries have participated in the program since its inception. I encourage you to pass information about this program to individuals involved in your regional operators' groups that have a keen interest in the Internet standardisation activities of the IETF. You also may consider being a reference for the applicant. If you have questions, please do not hesiate to contact Karen Rose [EMAIL PROTECTED] or Mirjam Kuehne [EMAIL PROTECTED]. Kind Regards, Mirjam Kuehne ISOC ___ IETF mailing list IETF@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-klensin-rfc2821bis
On Sun, Mar 30, 2008 at 11:53:37PM -0400, John C Klensin wrote: It was obvious 20+ years ago that MX processing was broken as there was no way to say I don't want email. First, it may have been obvious to you, but it wasn't obvious to many of us. In the general case, it still isn't. But you stated the situation exactly correctly. MX 0 . means I don't want email. SRV 0 0 . doesn't really indicate no service, it indicates please do look for that service here. actually, it means the DNS admin doesn't want SMTP connections set to the indicated node. While it is better than interpreting the lack of a bit in a WKS record as no service, it is still nothing more than an attempt to use the DNS to say please don't try a mail connection to this domain. right. --bill 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). ___ IETF mailing list IETF@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-klensin-rfc2821bis
were you folks pursuing this on ietf-smtp, as requested, you might have noticed that the problems with changing the model have been explored thoroughly. d/ Henning Schulzrinne wrote: I don't think this is a major issue, for two reasons: By the time that IPv6 mail becomes common, mail clients (and MTAs) will have been updated numerous times to deal with the security issue de jour. Secondly, even if a mail client or MTA were to erroneously implement this behavior, this causes no particular harm to the world at large, except bad error behavior for that particular MTA or MUA. Henning On Mar 31, 2008, at 7:58 AM, Tony Finch wrote: On Sat, 29 Mar 2008, John Levine wrote: Getting rid of the fallback flips the default to be in line with reality -- most hosts don't want to receive mail directly, so if you're one of the minority that actually does, you affirmatively publish an MX to say so. I agree that this is the right thing to do in an ideal world. However there's a lot of old running code out there that implements the fallback. Is IPv6 still enough of a toy that the stability of its specifications doesn't matter? Tony (in two minds). -- f.anthony.n.finch [EMAIL PROTECTED] http://dotat.at/ ROCKALL MALIN: SOUTHERLY VEERING WESTERLY, 4 IN MALIN AT FIRST, OTHERWISE 7 TO SEVERE GALE 9. ROUGH BECOMING VERY ROUGH OR HIGH. RAIN OR SHOWERS. MODERATE OR GOOD, OCCASIONALLY POOR. ___ 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 -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ IETF mailing list IETF@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: IETF Last Call for two IPR WG Dcouments
I agree with Joel. We're trying to give instructions to the Trust that cover the broadest possible user base; calling out specific licenses or user bases either appears to privilege them or adds no value at all. Suggesting to the Trustees that they consider specific licenses or, even better, pointing their lawyers at the potholes others have hit would be very useful. But this draft is not the place to do it. I believe the document is the place to do it. This is the only document were the IETF explains how the Trust should write its outgoing software license for code in RFCs. Useful considerations for that process should go into the document. My proposed text does not suggest specific licenses. That is a misunderstanding. Simon, The list of potentially useful considerations in this arena is both long and ever-changing. Imagine, for a moment, that I suggested that the Trust survey the legal departments of every organization which had sponsored a nomcom-eligible participant in the IETF over the past 3 years asking, if the proposed license was usable by their organization. In some lights, this is a pretty reasonable suggestion. These are organizations with a demonstrated interest in our output, and surveys can be a useful tool even when response rates are low. Why not confirm that we are meeting the needs of core participants? The answer, basically, is that we want the output to be usable by anyone, and privileging the people who pay kind of misses the point. We are giving instructions to the Trust to do the best job they can in making sure that the output is usable by anyone for any purpose, no matter whether they belong to group A, group B, or won't know for many years that they'll have an interest at all. As for how to get in touch with them, trustees of the trust are the IAOC. The IAOC's membership is listed here: http://iaoc.ietf.org/members_detail.html I am sure they will listen carefully to your concerns and will consider the issues you raise. regards, Ted ___ IETF mailing list IETF@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-klensin-rfc2821bis
Tony Finch wrote: On Sat, 29 Mar 2008, John Levine wrote: Getting rid of the fallback flips the default to be in line with reality -- most hosts don't want to receive mail directly, so if you're one of the minority that actually does, you affirmatively publish an MX to say so. I agree that this is the right thing to do in an ideal world. However there's a lot of old running code out there that implements the fallback. Is IPv6 still enough of a toy that the stability of its specifications doesn't matter? You could make the same kind of argument in the other direction: Is IPv6 still enough of a toy that we shouldn't maintain the specifications for applications that use it, updating them when there's a good reason to do so? I'm not worried about running code that implements the fallback, because I don't think that this change breaks anything. If domains were already relying on just an record to tell other domains how to send mail to them, I'd be concerned about backward compatibility. But that's not the case. ___ IETF mailing list IETF@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Gen-ART Review of draft-ietf-pim-bsr-mib-04.txt
I have been selected as the General Area Review Team (Gen-ART) reviewer for
this draft (for background on Gen-ART, please see
http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html).
Please resolve these comments along with any other Last Call comments you
may receive.
Thanks,
Spencer
Document: draft-ietf-pim-bsr-mib-04.txt
Reviewer: Spencer Dawkins
Review Date: 2008-03-31 (LATE)
IETF LC End Date: 2008-03-26
IESG Telechat date: (if known)
Summary: Ready for publication as a Proposed Standard
Comments: there are a small number of questions I tagged as Clarity: in
the notes below. If this draft is revised, it would be worth looking at
these questions.
4. Overview
This MIB module contains four tables. The tables are:
1. The Candidate-RP Table, which contains one row for each multicast
group address prefix for which the local router is to advertise
itself as a Candidate-RP. This table exists on routers that are
configured as Candidate-RP.
Clarity: I'm reading this as configured to advertise itself as
Candidate-RP - right? That seems to be the terminology used in the MIB
descriptions, and is more clear to me (if I understood correctly here).
Clarity: There are a decent number of multicast abbreviations that aren't
expanded on first use. If the document gets respun after Last Call, it would
be worth making sure these terms are expanded on first use (otherwise the
RFC Editor has to either ask you or guess).
5. Definitions
pimBsrCandidateRPStatus OBJECT-TYPE
SYNTAX RowStatus
MAX-ACCESS read-create
STATUS current
DESCRIPTION
The status of this row, by which new entries may be
created, or old entries deleted from this table.
Clarity: I'm sorry, but I don't get status by which new entries may be
created/old entries deleted - is that actually how it works? I would have
thought the status was the side effect of creation/deletion, not how
creation/deletion actually happens. s/by which new/used to identify when
new/? but I'm guessing here.
This status object can be set to active(1) without
setting any other columnar objects in this entry
All writable objects in this entry can be modified
when the status of this entry is active(1).
::= { pimBsrCandidateRPEntry 10 }
___
IETF mailing list
IETF@ietf.org
https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-klensin-rfc2821bis
There was a call for me to explain this statement. Mark Andrews wrote: Also getting rid of implict MX records would deal with all those ISP's that insist that they need to re-write NXDOMAIN responses. Todays there are ISP's that replace NXDOMAIN with a A record pointing to a web server which has a search page. This is often turned on for everyone with a opt-out which doesn't help the masses as they don't know that this is bad. The ISP usually claims it is being helpful. Any MTA using that caching resolver, directly or indirectly, get A records rather than NXDOMAIN on typos, hosts that have gone away etc. The implict MX rule then causes all those typos to be valid email destinations. Which either queue up for a week or are intercepted and hopefully bounced without being read. An explict MX rule would miminize the damage caused by doing this re-writing, as would publishing a MX 0 . record, if we can get that standardised. Either change would allow a MUA to validate the RHS by performing just a MX lookup rather the MX and A. NODATA is as useful as NXDOMAIN with a explict MX rule. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: [EMAIL PROTECTED] -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: [EMAIL PROTECTED] ___ IETF mailing list IETF@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Last Call: draft-ietf-rserpool-asap (Aggregate Server Access Protocol (ASAP)) to Experimental RFC
The IESG has received a request from the Reliable Server Pooling WG (rserpool) to consider the following documents: - 'Reliable Server Pooling Policies ' draft-ietf-rserpool-policies-08.txt as an Experimental RFC - 'Aggregate Server Access Protocol (ASAP) ' draft-ietf-rserpool-asap-19.txt as an Experimental RFC - 'Aggregate Server Access Protocol (ASAP) and Endpoint Handlespace Redundancy Protocol (ENRP) Parameters ' draft-ietf-rserpool-common-param-16.txt as an Experimental RFC - 'Endpoint Handlespace Redundancy Protocol (ENRP) ' draft-ietf-rserpool-enrp-19.txt as an Experimental RFC The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the [EMAIL PROTECTED] mailing lists by 2008-04-14. Exceptionally, comments may be sent to [EMAIL PROTECTED] 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-rserpool-policies-08.txt http://www.ietf.org/internet-drafts/draft-ietf-rserpool-asap-19.txt http://www.ietf.org/internet-drafts/draft-ietf-rserpool-common-param-16.txt http://www.ietf.org/internet-drafts/draft-ietf-rserpool-enrp-19.txt IESG discussion can be tracked via https://datatracker.ietf.org/public/pidtracker.cgi?command=view_iddTag=7094rfc_flag=0 ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
Last Call: draft-ietf-rserpool-overview (An Overview of Reliable Server Pooling Protocols) to Informational RFC
The IESG has received a request from the Reliable Server Pooling WG (rserpool) to consider the following document: - 'An Overview of Reliable Server Pooling Protocols ' draft-ietf-rserpool-overview-05.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 [EMAIL PROTECTED] mailing lists by 2008-04-14. Exceptionally, comments may be sent to [EMAIL PROTECTED] 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-rserpool-overview-05.txt IESG discussion can be tracked via https://datatracker.ietf.org/public/pidtracker.cgi?command=view_iddTag=15354rfc_flag=0 ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
Last Call: draft-ietf-rserpool-threats (Threats Introduced by RSerPool and Requirements for Security in Response to Threats) to Informational RFC
The IESG has received a request from the Reliable Server Pooling WG (rserpool) to consider the following document: - 'Threats Introduced by RSerPool and Requirements for Security in Response to Threats ' draft-ietf-rserpool-threats-09.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 [EMAIL PROTECTED] mailing lists by 2008-04-14. Exceptionally, comments may be sent to [EMAIL PROTECTED] 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-rserpool-threats-09.txt IESG discussion can be tracked via https://datatracker.ietf.org/public/pidtracker.cgi?command=view_iddTag=9759rfc_flag=0 ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
ISOC Fellowship to the IETF - seeking applicants for IETF 72 and IETF 73
[I am sorry if you receive this more than once.] Dear Colleagues, The Internet Society announces that it is seeking applications for the next round of the ISOC Fellowship to the IETF program. The program offers engineers from developing countries fellowships that fund the cost of attending an Internet Engineering Task Force (IETF) meeting. As you know, the IETF is the Internet's premier standards-making body, responsible for the development of protocols used in IP-based networks. IETF participants represent an international community of network designers, operators, vendors, and researchers involved in the technical operation of the Internet and the continuing evolution of Internet architecture. Fellowships will be awarded through a competitive application process. The Internet Society is currently accepting fellowship applications for the next two IETF meetings: * IETF 72 being held in Dublin, Ireland, 27 July - 1 August 2008 * IETF 73 being held in Minneapolis, 16 - 21 November 2008 Up to five fellowships will be awarded for each IETF meeting. Full details on the ISOC Fellowship to the IETF, including how to apply, are located on the ISOC website at : http://www.isoc.org/educpillar/fellowship Fellowship applications for both IETF meetings are due by 2 May 2008. The Internet Society formally launched the ISOC Fellowship to the IETF program in January 2007 after successfully piloting the program during 2006 at IETF 66 in Montreal and IETF 67 in San Diego. Fifteen individuals from 12 countries have participated in the program since its inception. I encourage you to pass information about this program to individuals involved in your regional operators' groups that have a keen interest in the Internet standardisation activities of the IETF. You also may consider being a reference for the applicant. If you have questions, please do not hesiate to contact Karen Rose [EMAIL PROTECTED] or Mirjam Kuehne [EMAIL PROTECTED]. Kind Regards, Mirjam Kuehne ISOC ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
RFC 5157 on IPv6 Implications for Network Scanning
A new Request for Comments is now available in online RFC libraries. RFC 5157 Title: IPv6 Implications for Network Scanning Author: T. Chown Status: Informational Date: March 2008 Mailbox:[EMAIL PROTECTED] Pages: 13 Characters: 29054 Updates/Obsoletes/SeeAlso: None I-D Tag:draft-ietf-v6ops-scanning-implications-04.txt URL:http://www.rfc-editor.org/rfc/rfc5157.txt The much larger default 64-bit subnet address space of IPv6 should in principle make traditional network (port) scanning techniques used by certain network worms or scanning tools less effective. While traditional network scanning probes (whether by individuals or automated via network worms) may become less common, administrators should be aware that attackers may use other techniques to discover IPv6 addresses on a target network, and thus they should also be aware of measures that are available to mitigate them. This informational document discusses approaches that administrators could take when planning their site address allocation and management strategies as part of a defence-in-depth approach to network security. This memo provides information for the Internet community. This document is a product of the IPv6 Operations Working Group of the IETF. 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 list and the RFC-DIST list. Requests to be added to or deleted from the IETF distribution list should be sent to [EMAIL PROTECTED] Requests to be added to or deleted from the RFC-DIST distribution list should be sent to [EMAIL PROTECTED] Details on obtaining RFCs via FTP or EMAIL may be obtained by sending an EMAIL message to [EMAIL PROTECTED] with the message body help: ways_to_get_rfcs. For example: To: [EMAIL PROTECTED] Subject: getting rfcs help: ways_to_get_rfcs Requests for special distribution should be addressed to either the author of the RFC in question, or to [EMAIL PROTECTED] Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. Submissions for Requests for Comments should be sent to [EMAIL PROTECTED] Please consult RFC 2223, Instructions to RFC Authors, for further information. 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 5167 on Media Server Control Protocol Requirements
A new Request for Comments is now available in online RFC libraries. RFC 5167 Title: Media Server Control Protocol Requirements Author: M. Dolly, R. Even Status: Informational Date: March 2008 Mailbox:[EMAIL PROTECTED], [EMAIL PROTECTED] Pages: 9 Characters: 17147 Updates/Obsoletes/SeeAlso: None I-D Tag:draft-ietf-mediactrl-requirements-04.txt URL:http://www.rfc-editor.org/rfc/rfc5167.txt This document addresses the communication between an application server and media server. The current work in IETF working groups shows these logical entities, but it does not address the physical decomposition and the protocol between the entities. This document presents the requirements for a Media Server Control Protocol (MCP) that enables an application server to use a media server. It will address the aspects of announcements, Interactive Voice Response, and conferencing media services. This memo provides information for the Internet community. This document is a product of the Media Server Control Working Group of the IETF. 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 list and the RFC-DIST list. Requests to be added to or deleted from the IETF distribution list should be sent to [EMAIL PROTECTED] Requests to be added to or deleted from the RFC-DIST distribution list should be sent to [EMAIL PROTECTED] Details on obtaining RFCs via FTP or EMAIL may be obtained by sending an EMAIL message to [EMAIL PROTECTED] with the message body help: ways_to_get_rfcs. For example: To: [EMAIL PROTECTED] Subject: getting rfcs help: ways_to_get_rfcs Requests for special distribution should be addressed to either the author of the RFC in question, or to [EMAIL PROTECTED] Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. Submissions for Requests for Comments should be sent to [EMAIL PROTECTED] Please consult RFC 2223, Instructions to RFC Authors, for further information. 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 5169 on Handover Key Management and Re-Authentication Problem Statement
A new Request for Comments is now available in online RFC libraries. RFC 5169 Title: Handover Key Management and Re-Authentication Problem Statement Author: T. Clancy, M. Nakhjiri, V. Narayanan, L. Dondeti Status: Informational Date: March 2008 Mailbox:[EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED] Pages: 15 Characters: 34082 Updates/Obsoletes/SeeAlso: None I-D Tag:draft-ietf-hokey-reauth-ps-09.txt URL:http://www.rfc-editor.org/rfc/rfc5169.txt This document describes the Handover Keying (HOKEY) re-authentication problem statement. The current Extensible Authentication Protocol (EAP) keying framework is not designed to support re-authentication and handovers without re-executing an EAP method. This often causes unacceptable latency in various mobile wireless environments. This document details the problem and defines design goals for a generic mechanism to reuse derived EAP keying material for handover. This memo provides information for the Internet community. This document is a product of the Handover Keying Working Group of the IETF. 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 list and the RFC-DIST list. Requests to be added to or deleted from the IETF distribution list should be sent to [EMAIL PROTECTED] Requests to be added to or deleted from the RFC-DIST distribution list should be sent to [EMAIL PROTECTED] Details on obtaining RFCs via FTP or EMAIL may be obtained by sending an EMAIL message to [EMAIL PROTECTED] with the message body help: ways_to_get_rfcs. For example: To: [EMAIL PROTECTED] Subject: getting rfcs help: ways_to_get_rfcs Requests for special distribution should be addressed to either the author of the RFC in question, or to [EMAIL PROTECTED] Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. Submissions for Requests for Comments should be sent to [EMAIL PROTECTED] Please consult RFC 2223, Instructions to RFC Authors, for further information. 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 5168 on XML Schema for Media Control
A new Request for Comments is now available in online RFC libraries. RFC 5168 Title: XML Schema for Media Control Author: O. Levin, R. Even, P. Hagendorf Status: Informational Date: March 2008 Mailbox:[EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED] Pages: 10 Characters: 17845 Updates/Obsoletes/SeeAlso: None I-D Tag:draft-levin-mmusic-xml-media-control-13.txt URL:http://www.rfc-editor.org/rfc/rfc5168.txt This document defines an Extensible Markup Language (XML) Schema for video fast update in a tightly controlled environment, developed by Microsoft, Polycom, Radvision and used by multiple vendors. This document describes a method that has been deployed in Session Initiation Protocol (SIP) based systems over the last three years and is being used across real-time interactive applications from different vendors in an interoperable manner. New implementations are discouraged from using the method described except for backward compatibility purposes. New implementations are required to use the new Full Intra Request command in the RTP Control Protocol (RTCP) channel. 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 list and the RFC-DIST list. Requests to be added to or deleted from the IETF distribution list should be sent to [EMAIL PROTECTED] Requests to be added to or deleted from the RFC-DIST distribution list should be sent to [EMAIL PROTECTED] Details on obtaining RFCs via FTP or EMAIL may be obtained by sending an EMAIL message to [EMAIL PROTECTED] with the message body help: ways_to_get_rfcs. For example: To: [EMAIL PROTECTED] Subject: getting rfcs help: ways_to_get_rfcs Requests for special distribution should be addressed to either the author of the RFC in question, or to [EMAIL PROTECTED] Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. Submissions for Requests for Comments should be sent to [EMAIL PROTECTED] Please consult RFC 2223, Instructions to RFC Authors, for further information. The RFC Editor Team USC/Information Sciences Institute ... ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
