IPv6 Zone Identifiers Considered Hateful
I've obviously not been doing all my homework, and RFC 4007 slipped my attention. Worse, for all the communication my IPv6 nodes are doing amongst themselves using link-local addresses, it's never really been much more than a hastily-justified curiosity why, when I ping one from the other using link-local-scoped addresses, I have to put in this zone identifier (%ifname on BSD and Linux). Yesterday, I configured a DNS server to listen just using a link-local address, the one autoconfigured for an ethernet card accessible to all the nodes. It's a host, not a router, so I'm relying on that address not being routable and being filtered at the router. It didn't work. The server would not start until I specified the zone suffix. Now I am wondering why, given that there is no ambiguous link-local address anywhere around here, I need to do that. Can't it figure it out itself? What about the other problems with this suffix? It's host-specific, so it's unsafe to share it over the network (I need to share the DNS server using stateless DHCPv6). The format differs between OSes (Windows uses %n). It interferes with URLs, if Wikipedia is to be believed. It breaks expectations, essentially because it's the exception to the rule that the address bits (and hence the address format) conveys all the required information. So zone suffixes are considered hateful. Yes, it's true, I enjoy a good whinge and it's a shame I had to learn this on-demand, but really, their use should be limited to just those circs where it's actually necessary, and let's be honest, that ought to be very rare. Cheers, Sabahattin
RE: Last Call: draft-betts-itu-oam-ach-code-point-03.txt (Allocation of an Associated Channel Code Point for Use by ITU-T Ethernet based OAM) to Informational RFC
+1 Original Message From: Rui Costa rco...@ptinovacao.pt Sent: zaterdag 17 maart 2012 12:00:56 + To: ietf@ietf.org ietf@ietf.org Subject: RE: Last Call: draft-betts-itu-oam-ach-code-point-03.txt (Allocation of an Associated Channel Code Point for Use by ITU-T Ethernet based OAM) to Informational RFC Hello, I support the allocation of an ACH codepoint to G.8113.1, not precluding the ITU-T to progress refinements. Ergo, i support this draft and proposal http://www.ietf.org/mail-archive/web/ietf/current/msg72191.html IMHO, the status quo analysis expressed in both http://www.ietf.org/mail-archive/web/ietf/current/msg72188.html and http://www.ietf.org/mail-archive/web/ietf/current/msg72273.html is accurate. Regards, Rui = Original Message From: The IESG iesg-secret...@ietf.org Sent: Wed, 22 Feb 2012 07:12:52 -0800 To: IETF-Announce ietf-annou...@ietf.org Subject: Last Call: draft-betts-itu-oam-ach-code-point-03.txt (Allocation of an Associated Channel Code Point for Use by ITU-T Ethernetbased OAM) to Informational RFC The IESG has received a request from an individual submitter to consider the following document: - 'Allocation of an Associated Channel Code Point for Use by ITU-T Ethernet based OAM' draft-betts-itu-oam-ach-code-point-03.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 ietf@ietf.org mailing lists by 2012-03-21. 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. Abstract This document assigns an Associated Channel Type code point for carrying Ethernet based Operations, Administration, and Management messages in the MPLS Generic Associated Channel (G-ACh). The file can be obtained via http://datatracker.ietf.org/doc/draft-betts-itu-oam-ach-code-point/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-betts-itu-oam-ach-code-point/ No IPR declarations have been submitted directly on this I-D. ___ IETF mailing list IETF@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: Query to the community -- An additional IETF Meeting event?
From: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On Behalf Of Henk Uijterwaal We have had cases where the opening reception was sponsored by somebody other than the host for the meeting (if there was a host). The sponsor didn't get much more than the possibility to put a sign near the front door and get some recognition during one of the plenary sessions. This proposal essentially says that the sponsors can demonstrate equipment during the reception. [WEG] +1 I was one of the people who suggested this to IAOC after recently attending my first NANOG in a good while. While I realize the audiences (and therefore the attractiveness to marketing budgets) are different, the sharp contrast between the two made it clear that there may be some opportunities to tweak IETF's sponsorship methods and potentially reduce the costs attendees are asked to bear without turning it into yet another tradeshow or forcing I* members to wear auto-racing-style suits emblazoned with vendor logos. :-) In addition to Beer-n-gear, NANOG had 2 other sponsored (i.e. free to all attendees) socials, and enough free T-shirts to last a person a week, plus 3-4 slides full of sponsor logos. Not that we need any more free t-shirts, but compare that to this IETF, where if you want a shirt, you must purchase it because we didn't have a primary sponsor until Cisco took pity on us (and apparently the shirt cannot be sponsored separately). That said, I don't think that this potential experiment requires a *separate* night. I'd much prefer to replace the current overpriced hotel cash bar arrangement at the welcome reception with something more like beer-n-gear. I'm also willing to try it in lieu of a social event, since those are typically hit or miss in terms of whether the environment is conducive to socializing, whether they're worth the additional money one must pay to attend them, and the fact that these are generally limited participation (tickets required), thereby reducing the opportunities for group socialization. And, having been to such sessions at NANOG and others, I know that you don't have to look at the gear brought by the vendors, it is perfectly possible to have the beer (for free) and have the hallway discussion you wanted to have anyway, while ignoring the demos. [WEG] This is definitely true. The two are not mutually exclusive. Wes George This E-mail and any of its attachments may contain Time Warner Cable proprietary information, which is privileged, confidential, or subject to copyright belonging to Time Warner Cable. This E-mail is intended solely for the use of the individual or entity to which it is addressed. If you are not the intended recipient of this E-mail, you are hereby notified that any dissemination, distribution, copying, or action taken in relation to the contents of and attachments to this E-mail is strictly prohibited and may be unlawful. If you have received this E-mail in error, please notify the sender immediately and permanently delete the original and any copy of this E-mail and any printout.
Re: IPv6 Zone Identifiers Considered Hateful
In your previous mail you wrote: So zone suffixes are considered hateful. = in fact it is not the problem: link-local address are considered hateful. Regards francis.dup...@fdupont.fr PS: at least for use in standard applications.
Re: Trade show at IETF
Separate budgets, but it really all depends on the type of Trade Shows the IETF is contemplating. I will note it does spike my interest to consider going to a IETF event from a technical sales standpoint, illustrating products built on IETF standardized protocol efforts, developing technology transfer agreements, joint ventures, etc. But if targeting a consumer market, thats a different set of departmental cost issues (Sales, engineers, technicians, etc). My only warning with this is that it make become too successful! It may actually attracts more vendors, especially among those whose main interest is as implementators and don't care much for the getting involved with the protocol development politics. As it gets bigger, the IETF will need to be ready with larger locations and offering pre-ordering space selections for the next events. This is very important part of the strategic booth location planning. Finally, a certain level of commitment will need to be shown because if the IETF does eventually decide it no longer wants (or can't) to get into this area, then refunds will be needed and whole slew of legal messy contract lawyers are needed. Also, once its reaches of level where its big part of the IETF, it might begin to see the unions knocking on the door which adds even more cost. -- HLS John C Klensin wrote: --On Friday, March 16, 2012 21:28 -0700 Joel jaeggli joe...@bogus.com wrote: On 3/16/12 20:04 , John C Klensin wrote: Note too that, if the company sends only five technical people and concludes that it doesn't suffer harm from that small a number, the odds of getting back up to 10 if the experiment is terminated and those five sales/market types disappear is just about zero, at least until the economy improves considerable. Scale and juggle the figures as you like, this is not a zero-risk experiment. You know nothing about marketing budgets. Sorry, Joel. I have both had to administer those budgets and policies, been the victim of them, as well as seen it go on in companies with whom I've done consulting work on organizational and strategic matters. Companies differ -- I tried to say that -- but in many companies that are really oriented toward the bottom line, marketing controls virtually all travel budgets. In a few, sales and/or controls and perceptions of their needs control almost all budget categories: Engineering is rarely a profit center, the money has to come from somewhere, and the organizational question is how much control the money source and its needs affect how it is spent. I didn't mean to suggest that the effects would be felt immediately -- there are usually budget cycles. But, over the medium term, even more relaxed organizations in tight budget situations do tend to eventually notice total number of people attending from company, and push back. If the attendees include both people from cost centers and people from profit centers, the latter tend to win the battle for slots, or at least to win less. But I suppose I should defer to your superior experience in senior management and corporate finance roles. john
Re: Issues relating to managing a mailing list...
I am responding to Russ' original message, because it is too hard to pick one of the 52 responses received so far. A quick count is something like 10 thinking this is a good idea with the remainder thinking this idea ranks somewhere between really bad and evil. Apps Area people who have thought deeply about the topic over the last 25 years are in near unanimous agreement this idea is on the evil end of the spectrum. While Apps Area folks do not have a monopoly on email ideas, I would offer we listen carefully. This idea brings out a whole host of very old (and solved!) issues: o What constitutes a message? (if you strip stuff, you will break signatures) o What is an attachment? (is it useless cruft like TNEF or is it S/MIME? What about the next part type?) o What about using 15-year-old solutions like HTTP on the composing side? o What about using 10-year-old solutions like IMAP 4? o ... If another vote in the Nay column is needed, here it is. Nay. -- - Eric On Mar 14, 2012, at 7:46 PM, Russ Housley wrote: Some suggestions have been made about the IETF mail lists. There is a way for mailman to strip attachments and put them in a place for downloading with a web browser. This would be a significant change to current practice, so the community needs to consider this potential policy change. What do you think? Russ The only bug in the soup is that it seemed to me that we might want to look into an alternative approach. We have asked people to post large documents somewhere and only send a pointer. Not everyone can do that, lots of people forget, and some people are just not willing to take the extra step. Plus, we cannot expect people to keep things posted on their own personal, or their company's, web-site indefinitely. If they don't keep it there, then the pointer in the archive will become stale, and information that should probably be there is lost. So we need a solution to the issue with really big email messages sometime. One solution might be to simpy strip attachments off, put them in the archive and replace them with a pointer. That shouldn't be that hard, since a lot of anti-virus software does something similar with suspect attachment types. Or we could - once again - ask people to post attachments and use a pointer in their mail, only provide them with a place to post them in the same general area as the mail archive. If there is already something like this in place, please let me know what it is and I will add a pointer to it in my too big rejection messages. The thing about threaded messages getting too big is a slightly different issue, brought about by the increasing use of HTML format email. I talked years ago about this with Scott Bradner because I really think that HTML format messages are useful and relatively easy to read when compared to plain old text. But using HTML leads to messages that are deceptively big. Possibly the right answer in that case is to bump the size limit up to maybe 100K. Even with HTML format, people will many likely realize that nobody is going to read past the 10th back message in any case (or if they do want to, they can look at the thread in the archive). But even that approach is not fool proof, and there are a lot of resourceful fools out there. Just trying to be creative, and help out... smime.p7s Description: S/MIME cryptographic signature
Beer and Gear
I think this would be a good idea. I have attended a number of the NANOG events and always found I can talk to vendors on a technical level. Additionally, it provides a convivial forum for attendees to get together and talk to each other. I don’t think it would detract from other IETF events and to be honest, most large events manage to co-exist with a multiplicity of sponsors. I am thinking of events like NANOG, MAAWG etc. Mike
FW: Query to the community -- An additional IETF Meeting event?
I think this is a good thing to try. -Original Message- From: ietf-announce-boun...@ietf.org [mailto:ietf-announce-boun...@ietf.org] On Behalf Of IAOC Chair Sent: Friday, March 16, 2012 4:14 PM To: IETF Announcement List Subject: Query to the community -- An additional IETF Meeting event? The IESG and IAOC are considering an addition to the IETF meeting week, and we would like your views before we develop the idea further. At NANOG, there is a Beer and Gear reception one evening. There are exhibitor tables with product vendors (hardware and software) and service providers (registries, registrars, ISPs, ESPs, etc.) and anyone else interested in face time with NANOG participants. They show their equipment and services. There is bar in the center of the room serving beer, wine, and soft drinks. There are hors d'oeuvres scattered around the room. QUESTION: What do you think about doing a Beer and Gear style of event on an evening that does not conflict with other IETF activities? This would be an opportunity for free food and drink for attendees, for vendors and service providers to talk with IETF participants, and for additional revenue to the IETF. Obviously, attendance would be optional. Technical people are at the tables, not sales or marketing staff. Vendors know that the audience is very technical, so they send the people that can communicate with that audience. We would charge for exhibit tables, to raise additional funds for the IETF. A stronger base of opportunities for IETF sponsorship distributes our funding, making it less fragile; this could make it less likely that we would have last-minute scrambles for additional sponsors, including hosts. A successful Beer-and-Gear like event would not solve this but it would help. In the past, the IETF has avoided vendor exhibits and demonstrations. However it is clear that NANOG has found a balance that works and that NANOG participants and the vendors consider the event valuable. We believe this could translate well to the IETF. We are considering some test events, hopefully to be held at IETF 84 (Vancouver, July 2012) and IETF 85 (Atlanta, November 2012). The kinds of evaluation criteria we are considering could include: - Did participants enjoy the event? - Did vendors consider the event successful? - Did the IETF raise additional funds? - Did the event steal potential sponsors away from other aspects of the meeting? So, what do you think? Is this something that we should try? Please respond on the ietf@ietf.org mail list. On behalf of the IESG and the IAOC, Russ Housley Bob Hinden
VS: Query to the community -- An additional IETF Meeting event?
Hi, I would find this educative. So + Would this be also the centralized place to show prototype implementations of IETF technologies still in WGs process, or would/could those be separate events (similar to the past, e.g. dedicated room)? Teemu alkuperäinen viesti Lähett.: ext IAOC Chair Lähet.: 16.03.2012, 22:14 V.ottaja: IETF Announcement List Aihe: Query to the community -- An additional IETF Meeting event? The IESG and IAOC are considering an addition to the IETF meeting week, and we would like your views before we develop the idea further. At NANOG, there is a Beer and Gear reception one evening. There are exhibitor tables with product vendors (hardware and software) and service providers (registries, registrars, ISPs, ESPs, etc.) and anyone else interested in face time with NANOG participants. They show their equipment and services. There is bar in the center of the room serving beer, wine, and soft drinks. There are hors d'oeuvres scattered around the room. QUESTION: What do you think about doing a Beer and Gear style of event on an evening that does not conflict with other IETF activities? This would be an opportunity for free food and drink for attendees, for vendors and service providers to talk with IETF participants, and for additional revenue to the IETF. Obviously, attendance would be optional. Technical people are at the tables, not sales or marketing staff. Vendors know that the audience is very technical, so they send the people that can communicate with that audience. We would charge for exhibit tables, to raise additional funds for the IETF. A stronger base of opportunities for IETF sponsorship distributes our funding, making it less fragile; this could make it less likely that we would have last-minute scrambles for additional sponsors, including hosts. A successful Beer-and-Gear like event would not solve this but it would help. In the past, the IETF has avoided vendor exhibits and demonstrations. However it is clear that NANOG has found a balance that works and that NANOG participants and the vendors consider the event valuable. We believe this could translate well to the IETF. We are considering some test events, hopefully to be held at IETF 84 (Vancouver, July 2012) and IETF 85 (Atlanta, November 2012). The kinds of evaluation criteria we are considering could include: - Did participants enjoy the event? - Did vendors consider the event successful? - Did the IETF raise additional funds? - Did the event steal potential sponsors away from other aspects of the meeting? So, what do you think? Is this something that we should try? Please respond on the ietf@ietf.org mail list. On behalf of the IESG and the IAOC, Russ Housley Bob Hinden
RE: [OAUTH-WG] Last Call: draft-ietf-oauth-v2-bearer-15.txt (The OAuth 2.0 Authorization Protocol: Bearer Tokens) to Proposed Standard
I am treating this issue as closed, unless someone wants to proposed language changes based on John's analysis below. EH -Original Message- From: John Bradley [mailto:ve7...@ve7jtb.com] Sent: Thursday, March 08, 2012 8:13 AM To: Eran Hammer Cc: Julian Reschke; ietf@ietf.org; The IESG; oa...@ietf.org Subject: Re: [OAUTH-WG] Last Call: draft-ietf-oauth-v2-bearer-15.txt (The OAuth 2.0 Authorization Protocol: Bearer Tokens) to Proposed Standard Thanks that is better. Without knowing the lifetime of the token these are per guess probabilities. Effectively 128bits for a random value and 256bits for a HMAC or other signature. For tokens intended for handling by end-users it may be useful to give some advice. In general you don't want an attacker having more than a one in 2^14 chance of guessing a valid code for a AS during the lifetime of the code(NIST LoA 2). For a code randomly generated from a 94 character code set 4 characters gets you 26.3 bits of entropy. 5 characters requires limiting an attacker to 2^12.3 (5,042) guesses per token lifetime. For a code randomly generated from a 94 character code set 5 characters gets you 32.9 bits of entropy. 5 characters requires limiting an attacker to 2^18.9 (489,178) guesses per token lifetime. If the token is single use and the client uses it right away that is easy, however in a worst case scenario the token might live 10min? That would be 8.4 attempts per second as a max for a 4 character code or 815 per second for 5 characters. That is all way too much to explain however I would recommend as a general rule: Credentials intended for handling by end users SHOULD be a minimum of 5 randomly generated charters from a set of 94 or otherwise contain a minimum entropy of 2^32.9. That is probably high enough that the AS will notice an attack, lower entropy may pass under the radar. Also the chances of an attacker being successful go up proportionally to the number simultaneous codes in flight at any point (it becomes a non targeted attack). It isn't something that I will loose sleep over, It gives me something else to profile:) Thanks John B. On 2012-03-07, at 8:18 PM, Eran Hammer wrote: New text: The probability of an attacker guessing generated tokens (and other credentials not intended for handling by end-users) MUST be less than or equal to 2^(-128) and SHOULD be less than or equal to 2^(-160). Removed reference to RFC 1750. EH -Original Message- From: John Bradley [mailto:ve7...@ve7jtb.com] Sent: Monday, February 06, 2012 5:07 PM To: Eran Hammer Cc: Julian Reschke; ietf@ietf.org; The IESG; oa...@ietf.org Subject: Re: [OAUTH-WG] Last Call: draft-ietf-oauth-v2-bearer-15.txt (The OAuth 2.0 Authorization Protocol: Bearer Tokens) to Proposed Standard RE new text in Draft 23 http://tools.ietf.org/html/draft-ietf-oauth-v2-23#section-10.10 Generated tokens and other credentials not intended for handling by end-users MUST be constructed from a cryptographically strong random or pseudo-random number sequence ([RFC1750]) generated by the authorization server. Given that many implementations may elect to use signed tokens, such as SAML or JWT (JOSE) this should not be a MUST. Giving people sensible defaults such as the probability of an attacker guessing a valid access token for the protected resource should be less than 2^(-128). The probability of generating hash colisions randomly is a odd metric, 2^(- 128) for a SHA256 as I recall. Many factors play into what is secure, token lifetime etc. I don't mind some reasonable defaults but adding a requirement for unstructured tokens is a bit much. Regards John B.
Re: Query to the community -- An additional IETF Meeting event?
Wes == Wes George George writes: Wes That said, I don't think that this potential experiment Wes requires a *separate* night. I'd much prefer to replace the Wes current overpriced hotel cash bar arrangement at the welcome Wes reception with something more like beer-n-gear. I'm also Wes willing to try it in lieu of a social event, since those are Wes typically hit or miss in terms of whether the environment is Wes conducive to socializing, whether they're worth the additional +1. If it's really the social, or better, the Sunday night event, then great. I've been at two NANOGs for beer-n-gear, and while I found it a bit weak in gear, and not that well attended, I actually enjoyed it. pgpwC4EmV4N9j.pgp Description: PGP signature
Re: IPv6 Zone Identifiers Considered Hateful
On 03/19/2012 05:55 AM, Sabahattin Gucukoglu wrote: Yesterday, I configured a DNS server to listen just using a link-local address, the one autoconfigured for an ethernet card accessible to all the nodes. It's a host, not a router, so I'm relying on that address not being routable and being filtered at the router. It didn't work. The server would not start until I specified the zone suffix. Now I am wondering why, given that there is no ambiguous link-local address anywhere around here, I need to do that. Can't it figure it out itself? Sure, it can, until a new network interface appears on that box (VPN, tunnel, hardware, etc.). -- Kevin P. Fleming Digium, Inc. | Director of Software Technologies Jabber: kflem...@digium.com | SIP: kpflem...@digium.com | Skype: kpfleming 445 Jan Davis Drive NW - Huntsville, AL 35806 - USA Check us out at www.digium.com www.asterisk.org
Re: Query to the community -- An additional IETF Meeting event?
On Mon, 19 Mar 2012, Michael Richardson wrote: +1. If it's really the social, or better, the Sunday night event, then great. I've been at two NANOGs for beer-n-gear, and while I found it a bit weak in gear, and not that well attended, I actually enjoyed it. Must have been a while ago, the 3 last ones I've been to have been packed in terms of attendees, and oversold so that not all potential exhibitors could get a table. Ole
Re: Query to the community -- An additional IETF Meeting event?
I have two comments on this. 1) I am in favor of allowing the IAOC to experiment with an event (or two) like this for the purposes of developing running code with the associated pros, cons and economics. 2) I would attend such an additional event if the gear on display was related to technology I am personally interested in (e.g. commerically available IPv6 Ready gear). Regards, Ed J. On Fri, Mar 16, 2012 at 3:49 PM, IAOC Chair bob.hin...@gmail.com wrote: The IESG and IAOC are considering an addition to the IETF meeting week, and we would like your views before we develop the idea further. At NANOG, there is a Beer and Gear reception one evening. There are exhibitor tables with product vendors (hardware and software) and service providers (registries, registrars, ISPs, ESPs, etc.) and anyone else interested in face time with NANOG participants. They show their equipment and services. There is bar in the center of the room serving beer, wine, and soft drinks. There are hors d'oeuvres scattered around the room. QUESTION: What do you think about doing a Beer and Gear style of event on an evening that does not conflict with other IETF activities? This would be an opportunity for free food and drink for attendees, for vendors and service providers to talk with IETF participants, and for additional revenue to the IETF. Obviously, attendance would be optional. Technical people are at the tables, not sales or marketing staff. Vendors know that the audience is very technical, so they send the people that can communicate with that audience. We would charge for exhibit tables, to raise additional funds for the IETF. A stronger base of opportunities for IETF sponsorship distributes our funding, making it less fragile; this could make it less likely that we would have last-minute scrambles for additional sponsors, including hosts. A successful Beer-and-Gear like event would not solve this but it would help. In the past, the IETF has avoided vendor exhibits and demonstrations. However it is clear that NANOG has found a balance that works and that NANOG participants and the vendors consider the event valuable. We believe this could translate well to the IETF. We are considering some test events, hopefully to be held at IETF 84 (Vancouver, July 2012) and IETF 85 (Atlanta, November 2012). The kinds of evaluation criteria we are considering could include: - Did participants enjoy the event? - Did vendors consider the event successful? - Did the IETF raise additional funds? - Did the event steal potential sponsors away from other aspects of the meeting? So, what do you think? Is this something that we should try? Please respond on the ietf@ietf.org mail list. On behalf of the IESG and the IAOC, Russ Housley Bob Hinden
Re: Last Call: draft-betts-itu-oam-ach-code-point-03.txt (Allocation of an Associated Channel Code Point for Use by ITU-T Ethernet based OAM) to Informational RFC
Maarten, please be aware of what u asking for - you won't have a an ACH codepoint to G.8113.1. First, what is requested is an Associated Channel Type and it will be assigned to the RFC resulting from draft-betts-. I will not do my tutorial on Associated Channel acronyms, but it could do it if needed, but some other venue. Assigning the Associated Channel Type is what I see that a solid majority want to happen! This is not an attempt to end-run the consensus call by the AD, just my personal read of the situation. The first remaining caveat is the draft-betts is too poorly written and need to be improve, suggestions has been sent to this mailing list, I take it that people who send mails to this list saying that they support Russ' proposal also implicitly support these improvements. The second caveat is that an ITU-T Recommendation is not stable according to the criteria we normally apply to RFCs. We are solving this by generating a RFC from draft-betts-. I believe that the way out here is to update RFC draft-betts- every time ITU-T rev G.8113.1. That way we will have our stable reference pointing to the right version of G.8113.1. I'd like to hear from the process people on this, but not as part of this last call. /Loa On 2012-03-19 11:55, Maarten vissers wrote: +1 Original Message From: Rui Costarco...@ptinovacao.pt Sent: zaterdag 17 maart 2012 12:00:56 + To: ietf@ietf.orgietf@ietf.org Subject: RE: Last Call:draft-betts-itu-oam-ach-code-point-03.txt (Allocation of an Associated Channel Code Point for Use by ITU-T Ethernet based OAM) to Informational RFC Hello, I support the allocation of an ACH codepoint to G.8113.1, not precluding the ITU-T to progress refinements. Ergo, i support this draft and proposal http://www.ietf.org/mail-archive/web/ietf/current/msg72191.html IMHO, the status quo analysis expressed in both http://www.ietf.org/mail-archive/web/ietf/current/msg72188.html and http://www.ietf.org/mail-archive/web/ietf/current/msg72273.html is accurate. Regards, Rui = Original Message From: The IESGiesg-secret...@ietf.org Sent: Wed, 22 Feb 2012 07:12:52 -0800 To: IETF-Announceietf-annou...@ietf.org Subject: Last Call:draft-betts-itu-oam-ach-code-point-03.txt (Allocation of an Associated Channel Code Point for Use by ITU-T Ethernetbased OAM) to Informational RFC The IESG has received a request from an individual submitter to consider the following document: - 'Allocation of an Associated Channel Code Point for Use by ITU-T Ethernet based OAM' draft-betts-itu-oam-ach-code-point-03.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 ietf@ietf.org mailing lists by 2012-03-21. 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. Abstract This document assigns an Associated Channel Type code point for carrying Ethernet based Operations, Administration, and Management messages in the MPLS Generic Associated Channel (G-ACh). The file can be obtained via http://datatracker.ietf.org/doc/draft-betts-itu-oam-ach-code-point/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-betts-itu-oam-ach-code-point/ No IPR declarations have been submitted directly on this I-D. ___ IETF mailing list IETF@ietf.org https://www.ietf.org/mailman/listinfo/ietf -- Loa Andersson email: loa.anders...@ericsson.com Sr Strategy and Standards Managerl...@pi.nu Ericsson Inc phone: +46 10 717 52 13 +46 767 72 92 13
Re: Gen-ART LC review of draft-melnikov-smtp-priority-09
Hi Roni, Thank you for your review. On 13/03/2012 19:25, Roni Even wrote: I am the assigned Gen-ART reviewer for this draft. For background on Gen-ART, please see the FAQ at http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq. Please resolve these comments along with any other Last Call comments you may receive. Document: draft-melnikov-smtp-priority-09 Reviewer: Roni Even Review Date:2012--3--13 IETF LC End Date: 2012--3--28 IESG Telechat date: Summary: This draft is almost ready for publication as a standard track RFC. Major issues: Minor issues: 1.In section 4.2 In absence of both the MT-PRIORITY MAIL FROM parameter and the MT-Priority header field, other message header fields, such as Priority [RFC2156] and X-Priority, MAY be used for determining the priority under this Priority Message Handling SMTP extension. . My understanding from the third bullet in this section is that for this case the message priority is 0 so I am not clear what this sentence means Ah, good catch. The text should be another bullet point in the list. and why is there a difference if the MT-PRIORITY or MT-Priority values do exist with regards to Priority and X-Priority for this case. Basically there are existing header fields with similar semantics already in use, so people want to use them as the last resort. There was a bit of a debate about specific header fields during the IETF LC, so this text will hopefully be improved after the debate. 2.In section 8 MT-PRIORITY=3. I did not see where the MT-PRIORITY SMTP extension is specified and has the syntax of using = before the value. This is described by the following text in Section 3: One optional parameter (MT-PRIORITY) is added to the MAIL FROM command. The value associated with this parameter is a decimal integer number from -9 to 9 (inclusive) indicating the priority of the email message. The syntax of In SMTP parameter values are separated with = from the corresponding parameter names. Nits/editorial comments: 1.MUA is used in section 1 but expanded only in section 5. 2.Some typos in section 5. syntatically -- syntactically prioritiy -- priority comminicate -- communicate contraints --constraints 3.In section 10 for X.3.TBD3 Description: The message mas accepted I assume you meant was 4.In section D.2 first paragraph some typos focusses --focuses comparision -- comparison All of these fixed in my copy, thanks! Best Regards, Alexey
Global INET 2012
Join the Internet Society at Global INET 2012 in Geneva on 22-24 April 2012 to celebrate 20 years advancing the open development, evolution and use of the Internet for the benefit of all people throughout the world. Meet and network with policy makers, technologists, government representatives and business executives from around the globe to learn how they are addressing issues that will shape the Internet's future. Visionary keynotes, industry leaders, Internet pioneers and futurists will share their insights and inspirations as we consider how to preserve an Internet responsive to all stakeholders while extending its access and power as an engine for education and economic growth. Pre-conference workshops for Chapter members and delegates will also be offered along with the latest developments and resources, so take advantage of this special opportunity to learn and share with peers around the globe. Be part of our 20th anniversary, as the inaugural class of honorees is inducted into the “Internet Hall of Fame” will highlight the history and personal stories of the Internet’s pioneers – past, present, and future. It is all happening at the Awards Gala on 23 April 2012 at the InterContinental Hotel in Geneva. The IETF is very fortunate to receive ongoing support from the Internet Society. Register today! http://www.internetsociety.org/events/inet-conferences/global-inet-2012/register
Last Call: draft-dbider-sha2-mac-for-ssh-05.txt (SHA-2 Data Integrity Verification for the Secure Shell (SSH) Transport Layer Protocol) to Proposed Standard
The IESG has received a request from an individual submitter to consider the following document: - 'SHA-2 Data Integrity Verification for the Secure Shell (SSH) Transport Layer Protocol' draft-dbider-sha2-mac-for-ssh-05.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 2012-04-16. 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. Abstract This memo defines algorithm names and parameters for use of some of the SHA-2 family of secure hash algorithms for data integrity verification in the Secure Shell (SSH) protocol. It also updates RFC4253 by specifying a new RECOMMENDED data integrity algorithm. The file can be obtained via http://datatracker.ietf.org/doc/draft-dbider-sha2-mac-for-ssh/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-dbider-sha2-mac-for-ssh/ballot/ No IPR declarations have been submitted directly on this I-D.
Document Action: 'Simplified Multicast Forwarding' to Experimental RFC (draft-ietf-manet-smf-14.txt)
The IESG has approved the following document: - 'Simplified Multicast Forwarding' (draft-ietf-manet-smf-14.txt) as an Experimental RFC This document is the product of the Mobile Ad-hoc Networks Working Group. The IESG contact persons are Adrian Farrel and Stewart Bryant. A URL of this Internet Draft is: http://datatracker.ietf.org/doc/draft-ietf-manet-smf/ Technical Summary This document specifies some simple mechanisms to distribute multicast data packets within a Mobile Ad-hoc Network (MANET). This document provides basic and simple multicast forwarding that can complement the on-going unicast routing protocol efforts of the MANET working group. Additionally, this document describes several different reduced relay set algorithms that can be used to make multicast dissemination more efficient. Working Group Summary There were no issues in the WG process. The I-D has progressed very slowly since WG lsat call as updates to address WG last call comments and to satisfy AD review have been slow. Protocol Quality This is intended for publication as an Experimental RFC. Several interoperable implementations of SMF exist; although only one is available. Note: that several of the methods laid out in SMF have been included in many MANET protocols and their implementations. Personnel Stan Ratliff (sratl...@cisco.com) is the Document Shepherd Adrian Farrel (adr...@olddog.co.uk) is the Responsible AD
WG Action: INtermediary-safe SIP session ID (insipid)
A new IETF working group has been formed in the Real-Time Applications and Infrastructure Area. For additional information, please contact the Area Directors or the WG Chairs. INtermediary-safe SIP session ID (insipid) -- Status: Active Working Group Chairs: Keith Drage dr...@alcatel-lucent.com Hadriel Kaplan hkap...@acmepacket.com Real-Time Applications and Infrastructure Area Directors: Gonzalo Camarillo gonzalo.camari...@ericsson.com Robert Sparks rjspa...@nostrum.com Real-Time Applications and Infrastructure Area Advisor: Gonzalo Camarillo gonzalo.camari...@ericsson.com Mailing Lists: General Discussion: insi...@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/insipid Archive: http://www.ietf.org/mail-archive/web/insipid/ An end-to-end session identifier in SIP-based multimedia communication networks refers to the ability for endpoints, intermediate devices, and management and monitoring system to identify and correlate SIP messages and dialogs of the same higher-level end-to-end communication session across multiple SIP devices, hops, and administrative domains. Unfortunately, there are a number of factors that contribute to the fact that the current dialog identifiers defined in SIP are not suitable for end-to-end session identification. Perhaps the most important factor worth describing is that in real-world deployments of Back-to-Back User Agents (B2BUAs) devices like Session Border Controllers (SBC) often change the call identifiers (e.g., the From-tag and To-tag that are used in conjunction with the Call-ID header to make the dialog-id) as the session signaling passes through. An end-to-end session identifier should allow the possibility to identify the communication session from the point of origin, passing through any number of intermediaries, to the ultimate point of termination. It should have the same aim as the From-tag, To-tag and Call-ID conjunction, but should not be mangled by intermediaries. A SIP end-to-end session identifier has been considered as possible solution of different use cases like troubleshooting, billing, session tracking, session recording, media and signaling correlation, and so forth. Some of these requirements come from other working groups within the RAI area (e.g., SIPRec). Moreover, other standards organizations have identified the need for SIP and H.323 to carry the same session ID value so that it is possible to identify a call end-to end even when performing inter working between protocols. This group will focus on a document that will specify a SIP identifier that have the same aim as the From-tag, To-tag and Call-ID conjunction, but is less likely to be mangled by intermediaries. In doing this work, the group will pay attention to the privacy implications of a session ID, for example considering the possibility to make it intractable for nodes to correlate session IDs generated by the same user for different sessions. Goal and Milestone: Dec 2012 - Specification of the new identifier sent to the IESG (PS)
WG Action: RECHARTER: Hypertext Transfer Protocol Bis (httpbis)
The Hypertext Transfer Protocol Bis (httpbis) working group in the Applications Area of the IETF has been rechartered. For additional information, please contact the Area Directors or the working group Chairs. Hypertext Transfer Protocol Bis (httpbis) - Status: Active Working Group Current Status: Active Working Group Chair(s): Mark Nottingham m...@mnot.net Applications Area Director(s): Pete Resnick presn...@qualcomm.com Peter Saint-Andre stpe...@stpeter.im Applications Area Advisor: Peter Saint-Andre stpe...@stpeter.im Mailing Lists: General Discussion:ietf-http...@w3.org To Subscribe: ietf-http-wg-requ...@w3.org In Body: subscribe Archive: http://lists.w3.org/Archives/Public/ietf-http-wg/ Description of Working Group: This Working Group is charged with maintaining and developing the core specifications for HTTP. The Working Group's specification deliverables are: * A document (or set of documents) that is suitable to supersede RFC 2616 (HTTP/1.1) and move RFC 2817 to Historic status * A document cataloguing the security properties of HTTP/1.1 * A document that specifies HTTP/2.0 an improved binding of HTTP's semantics to the underlying transport. HTTP/1.1 HTTP is one of the most successful and widely-used protocols on the Internet today. However, its specification has several editorial issues. Additionally, after years of implementation and extension, several ambiguities have become evident, impairing interoperability and the ability to easily implement and use HTTP. The working group will refine RFC2616 to: * Incorporate errata and updates (e.g., references, IANA registries, ABNF) * Fix editorial problems which have led to misunderstandings of the specification * Clarify conformance requirements * Remove known ambiguities where they affect interoperability * Clarify existing methods of extensibility * Remove or deprecate those features that are not widely implemented and also unduly affect interoperability * Where necessary, add implementation advice * Document the security properties of HTTP and its associated mechanisms (e.g., Basic and Digest authentication, cookies, TLS) for common applications It will also incorporate the generic authentication framework from RFC 2617, without obsoleting or updating that specification's definition of the Basic and Digest schemes. Finally, it will incorporate relevant portions of RFC 2817 (in particular, the CONNECT method and advice on the use of Upgrade), so that that specification can be moved to Historic status. In doing so, it should consider: * Implementer experience * Demonstrated use of HTTP * Impact on existing implementations and deployments HTTP/2.0 There is emerging implementation experience and interest in a protocol that retains the semantics of HTTP, without the legacy of HTTP/1.x message framing and syntax. The Working Group will leverage this to create new major version of HTTP. Particular goals of this effort include: * Significantly improved perceived performance for common use cases (e.g., browsers, mobile) * More efficient use of network resources; in particular, reducing the need to use multiple TCP connections * Ability to be deployed on today's Internet, using IPv4 and IPv6, in the presence of NATs * Maintaining HTTP's ease of deployment * Reflecting modern security requirements and practices With regard to security requirements, in the initial phase of work on HTTP/2.0, new proposals for authentication schemes can be made. The WG will have a a goal of choosing at least one scheme that is better than those available for HTTP/1.x. However, the WG might select zero schemes. In addition, non-selected schemes might be discussed with the IETF Security Area for further work there. In documenting this protocol, the Working Group must: * Meet the goals specified above * Make it possible to pass through a HTTP/1.1 message with reasonable fidelity; i.e., to implement a gateway to or from HTTP/1.1 * consider the needs of a variety of HTTP implementers and users (such as back-end or web api uses of HTTP, servers and intermediaries) * Address HTTP proxy and CDN infrastructure requirements Changes to the existing semantics of HTTP are out of scope in order to preserve the meaning of messages that might cross a 1.1 -- 2.0 -- 1.1 request chain. However, the effort may define new semantics to further the goals above, along with suitable extensibility mechanisms for defining additional semantics. This work will be known as HTTP/2.0, unless the Working Group determines that this isn't suitable (e.g., for interoperability). Goals and Milestones: DoneFirst HTTP/1.1 Revision Internet Draft DoneFirst HTTP Security Properties Internet Draft Jan 2012Request Last Call for HTTP/1.1 Revision Jan 2012Request Last Call for HTTP Security Properties Apr 2012
WG Action: RECHARTER: Locator/ID Separation Protocol (lisp)
The Locator/ID Separation Protocol (lisp) working group in the Internet Area of the IETF has been rechartered. For additional information, please contact the Area Directors or the working group Chairs. Locator/ID Separation Protocol (lisp) - Current Status: Active Last updated: 2012-03-15 Chairs: Joel Halpern j...@joelhalpern.com Terry Manderson terry.mander...@icann.org Internet Area Directors: Ralph Droms rdroms.i...@gmail.com Jari Arkko jari.ar...@piuha.net Internet Area Advisor: Jari Arkko jari.ar...@piuha.net Secretaries: Wassim Haddad wassim.had...@ericsson.com Luigi Iannone lu...@net.t-labs.tu-berlin.de Mailing Lists: General Discussion: l...@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/lisp Archive: http://www.ietf.org/mail-archive/web/lisp/current/maillist.html Description of Working Group: The IAB's October 2006 Routing and Addressing Workshop (RFC 4984) rekindled interest in scalable routing and addressing architectures for the Internet. Among the many issues driving this renewed interest are concerns about the scalability of the routing system. Since the IAB workshop, several proposals have emerged which attempt to address the concerns expressed there and elsewhere. In general, these proposals are based on the locator/identifier separation. The basic idea behind the separation is that the Internet architecture combines two functions, routing locators, (where you are attached to the network) and identifiers (who you are) in one number space: The IP address. Proponents of the separation architecture postulate that splitting these functions apart will yield several advantages, including improved scalability for the routing system. The separation aims to decouple locators and identifiers, thus allowing for efficient aggregation of the routing locator space and providing persistent identifiers in the identifier space. A number of approaches are being looked at in parallel in other contexts. The IRTF RRG examined several proposals, some of which were published as IRTF-track Experimental RFCs. The LISP WG has completed the first set of Experimental RFCs describing the Locator/ID Separation Protocol. LISP requires no changes to end-systems or to routers that do not directly participate in the LISP deployment. LISP aims for an incrementally deployable protocol. The LISP WG is chartered to continue work on the LISP base protocol, completing the ongoing work, and any items which directly impact LISP protocol structures and which are related to using LISP for improving Internet routing scalability. Specifically, the group will work on: - Architecture description: This document will describe the architecture of the entire LISP system, making it easier to read the rest of the LISP specifications and providing a basis for discussion about the details of the LISP protocols. The document will include a description of the cache management and ETR synchronization essential characteristics needed to ensure the correct operation of the protocol. - Deployment models: This document will describe what kind of deployments can be expected for LISP, and give operational advice on how they can be set up. - A description of the impacts of LISP: This document will describe the problems that LISP is intended to address and the impacts that employing LISP has. While the work on LISP was initiated by Internet routing scaling concerns, there has also been an interest on improved solutions to a number of different problems, such as traffic engineering. This document should describe problem areas (such as scaling or traffic engineer) where LISP is expected to have a positive effect, as well as any tradeoffs that are caused by LISP's design. - LISP security threats and solutions: This document will describe the security analysis of the LISP system, what issues it needs to protect against, and a solution that helps defend against those issues. The replay attack problem discussed on the mailing list should be included in this work. - Allocation of Endpoint IDentifier (EID) space: This document requests address space to be used for the LISP experiment as identifier space - Alternate mapping system designs: Develop alternative mapping designs to be tested. - Data models for management of LISP. The first three items (architecture, deployment models, impacts) need to be completed first before other items can be submitted as RFCs. The three first documents also need to complement each other, by describing how the architecture supports a solution for a particular problem area and how the solution can be deployed to help with that problem. In addition, if work chartered in some other IETF WG requires changes in the LISP base protocol or any items which directly impact LISP protocol structures, then the LISP WG is chartered to work on such
Protocol Action: 'ATM-Based xDSL Bonded Interfaces MIB' to Proposed Standard (draft-ietf-adslmib-gbond-atm-mib-06.txt)
The IESG has approved the following document: - 'ATM-Based xDSL Bonded Interfaces MIB' (draft-ietf-adslmib-gbond-atm-mib-06.txt) as a Proposed Standard This document is the product of the ADSL MIB Working Group. The IESG contact persons are Dan Romascanu and Ronald Bonica. A URL of this Internet Draft is: http://datatracker.ietf.org/doc/draft-ietf-adslmib-gbond-atm-mib/ Technical Summary This document defines Management Information Base (MIB) module for use with network management protocols in TCP/IP based networks. This document proposes an extension to the GBOND-MIB module with a set of objects for managing ATM-based multi-pair bonded xDSL interfaces, defined in ITU-T recommendation G.998.1. Working Group Summary The WG process was smooth with no real controversies. All work took place on the mailing list. Document Quality No information is available about implementations. Personnel Menachem Dodge is the Document Shepherd for this document Dan Romascanu is the Responsible Area Director.
Protocol Action: 'xDSL multi-pair bonding using Time-Division Inverse Multiplexing (G.Bond/TDIM) MIB' to Proposed Standard (draft-ietf-adslmib-gbond-tdim-mib-08.txt)
The IESG has approved the following document: - 'xDSL multi-pair bonding using Time-Division Inverse Multiplexing (G.Bond/TDIM) MIB' (draft-ietf-adslmib-gbond-tdim-mib-08.txt) as a Proposed Standard This document is the product of the ADSL MIB Working Group. The IESG contact persons are Dan Romascanu and Ronald Bonica. A URL of this Internet Draft is: http://datatracker.ietf.org/doc/draft-ietf-adslmib-gbond-tdim-mib/ Technical Summary This document defines Management Information Base (MIB) module for use with network management protocols in TCP/IP based internets. This document proposes an extension to the GBOND-MIB module with a set of objects for managing multi-pair bonded xDSL interfaces using Time-Division Inverse Multiplexing (TDIM), defined in ITU-T recommendation G.998.3. Working Group Summary The WG process was smooth with no real controversies. All work took place on the mailing list. Document Quality No information is available about implementations. Personnel Menachem Dodge is the Document Shepherd for this document Dan Romascanu is the Responsible Area Director.
Protocol Action: 'IANA Registry for MEDIACTRL Interactive Voice Response Control Package' to Proposed Standard (draft-ietf-mediactrl-6231-iana-00.txt)
The IESG has approved the following document: - 'IANA Registry for MEDIACTRL Interactive Voice Response Control Package' (draft-ietf-mediactrl-6231-iana-00.txt) as a Proposed Standard This document is the product of the Media Server Control Working Group. The IESG contact persons are Robert Sparks and Gonzalo Camarillo. A URL of this Internet Draft is: http://datatracker.ietf.org/doc/draft-ietf-mediactrl-6231-iana/ Technical Summary This document creates an IANA registry for the response codes for the MEDIACTRL Interactive Voice Response Control Package, RFC6231. Working Group Summary This document corrects an oversight in RFC6231, asking IANA to create a registry that RFC6231 clearly intended to create - the format, initial contents and maintenance rules were specified in RFC6231. This document was reviewed by the working group concurrently with IETF LC. Document Quality This document is essentially an IANA considerations section with content from RFC6231. Personnel Eric Burger is the Document Shepherd. Robert Sparks is the responsible Area Director. RFC Editor Note (applies to -00) The following correction adds a missing word not to the description of the 433 code: (please view in fixed width font) OLD: - | 433 | Unsupported | request contains || | | collect and | collect and || | | record| record elements and || | | capability| the MS does support || | | | these operations || | | | simultaneously. || NEW: -- | 433 | Unsupported | request contains || | | collect and | collect and || | | record| record elements and || | | capability| the MS does not || | | | support these || | | | operations|| | | | simultaneously. || Please make this change to the IANA considerations section: OLD: Please create the following registry. NEW: Please create the following registry, with a name of MEDIACTRL Interactive Voice Response Control Package Registry
SIDR Interim 24/March is CANCELLED
The announcement of the SIDR virtual interim failed to reach iesg-secret...@ietf.org within the required two weeks notice. Additionally the agenda was published on Sunday 17th March and thus failed to meet the requirement that The agenda must be published at least one week before the call or session . The requirement to provide appropriate notice of the meeting and its agenda is fundamental to the IETF open standards process. Since the failure to meet these requirement may disadvantage some contributors, I regret that I find it necessary to cancel the proposed SIDR interim meeting scheduled for 24/March. I thank those that provided feedback on the matter and apologize for any inconvenience caused. Stewart
Document Action: 'Overview of Pre-Congestion Notification Encoding' to Informational RFC (draft-ietf-pcn-encoding-comparison-09.txt)
The IESG has approved the following document: - 'Overview of Pre-Congestion Notification Encoding' (draft-ietf-pcn-encoding-comparison-09.txt) as an Informational RFC This document is the product of the Congestion and Pre-Congestion Notification Working Group. The IESG contact persons are David Harrington and Wesley Eddy. A URL of this Internet Draft is: http://datatracker.ietf.org/doc/draft-ietf-pcn-encoding-comparison/ Technical Summary The PCN mechanism in routers in the interior of a PCN domain marks packets when certain configured rates are exceeded. The PCN working group explored a number of approaches for encoding this pre-congestion information into the IP header. This document describes the various approaches that were examined and discusses the constraints that had to be satisfied by a viable encoding mechanism. Working Group Summary The document was subject to thorough review by the PCN working group, and strong consensus for publication was reached. Document Quality The document was subject to thorough review by the PCN working group, and strong consensus for publication was reached. There are a number of companion documents that detail the specific approaches. Personnel Document Shepherd: Steven Blake Responsible Area Director: David Harrington RFC Editor Note 4.5 says RFC5696 was published as a draft Internet Standard. This is confusing, given the existence of the Draft Internet Standard status. RFC5696 is a Proposed Standard. Please reword to: The baseline encoding described in section 4.1 is defined in [RFC5696].
RFC 6544 on TCP Candidates with Interactive Connectivity Establishment (ICE)
A new Request for Comments is now available in online RFC libraries. RFC 6544 Title: TCP Candidates with Interactive Connectivity Establishment (ICE) Author: J. Rosenberg, A. Keranen, B. B. Lowekamp, A. B. Roach Status: Standards Track Stream: IETF Date: March 2012 Mailbox:jdro...@jdrosen.net, ari.kera...@ericsson.com, b...@lowekamp.net, a...@nostrum.com Pages: 29 Characters: 72318 Updates/Obsoletes/SeeAlso: None I-D Tag:draft-ietf-mmusic-ice-tcp-16.txt URL:http://www.rfc-editor.org/rfc/rfc6544.txt Interactive Connectivity Establishment (ICE) defines a mechanism for NAT traversal for multimedia communication protocols based on the offer/answer model of session negotiation. ICE works by providing a set of candidate transport addresses for each media stream, which are then validated with peer-to-peer connectivity checks based on Session Traversal Utilities for NAT (STUN). ICE provides a general framework for describing candidates but only defines UDP-based media streams. This specification extends ICE to TCP-based media, including the ability to offer a mix of TCP and UDP-based candidates for a single stream. [STANDARDS-TRACK] This document is a product of the Multiparty Multimedia Session Control 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 Association Management Solutions, LLC
RFC 6549 on OSPFv2 Multi-Instance Extensions
A new Request for Comments is now available in online RFC libraries. RFC 6549 Title: OSPFv2 Multi-Instance Extensions Author: A. Lindem, A. Roy, S. Mirtorabi Status: Standards Track Stream: IETF Date: March 2012 Mailbox:acee.lin...@ericsson.com, a...@cisco.com, s...@cisco.com Pages: 9 Characters: 16639 Updates:RFC2328 I-D Tag:draft-ietf-ospf-multi-instance-09.txt URL:http://www.rfc-editor.org/rfc/rfc6549.txt OSPFv3 includes a mechanism to support multiple instances of the protocol running on the same interface. OSPFv2 can utilize such a mechanism in order to support multiple routing domains on the same subnet. This document defines the OSPFv2 Instance ID to enable separate OSPFv2 protocol instances on the same interface. Unlike OSPFv3 where the Instance ID can be used for multiple purposes, such as putting the same interface in multiple areas, the OSPFv2 Instance ID is reserved for identifying protocol instances. This document updates RFC 2328. [STANDARDS-TRACK] This document is a product of the Open Shortest Path First IGP 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 Association Management Solutions, LLC
RFC 6561 on Recommendations for the Remediation of Bots in ISP Networks
A new Request for Comments is now available in online RFC libraries. RFC 6561 Title: Recommendations for the Remediation of Bots in ISP Networks Author: J. Livingood, N. Mody, M. O'Reirdan Status: Informational Stream: IETF Date: March 2012 Mailbox:jason_living...@cable.comcast.com, nirmal_m...@cable.comcast.com, michael_oreir...@cable.comcast.com Pages: 29 Characters: 74562 Updates/Obsoletes/SeeAlso: None I-D Tag:draft-oreirdan-mody-bot-remediation-20.txt URL:http://www.rfc-editor.org/rfc/rfc6561.txt This document contains recommendations on how Internet Service Providers can use various remediation techniques to manage the effects of malicious bot infestations on computers used by their subscribers. Internet users with infected computers are exposed to risks such as loss of personal data and increased susceptibility to online fraud. Such computers can also become inadvertent participants in or components of an online crime network, spam network, and/or phishing network as well as be used as a part of a distributed denial-of-service attack. Mitigating the effects of and remediating the installations of malicious bots will make it more difficult for botnets to operate and could reduce the level of online crime on the Internet in general and/or on a particular Internet Service Provider's network. This document is not an Internet Standards Track specification; it is published for informational purposes. INFORMATIONAL: This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see http://www.ietf.org/mailman/listinfo/ietf-announce http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html. For downloading RFCs, see http://www.rfc-editor.org/rfc.html. Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-edi...@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC
