Re: APPSDIR review of draft-ietf-netmod-rfc6021-bis-01
S Moonesamy wrote: At 01:32 30-04-2013, Juergen Schoenwaelder wrote: I am not sure what you think is unclear. Note that the definition of the typedef domain-name is unchanged from the one in RFC 6021. Perhaps you can make a concrete text change proposal so I better understand what your concern is. I read draft-ietf-netmod-rfc6021-bis-02. In Section 4: The domain-name type represents a DNS domain name. The name SHOULD be fully qualified whenever possible. That sounds like a MAY. That is a MAY. That probably needs to be a may. How do you recognize a fully qualified name anyway? Today a huge number of machines simply does not have a fully qualified domain name (and uses private address space). My DSL router (a brand that is pretty common in Germany) does _not_ provide a domain name via DHCP and will resolve plain hostnames for all addresses that it hands out via DHCP. And a lot of stuff that you attach to home networks comes with a Web-UI (my DVB-S Set-Top Box, my HomeNAS, my DSL-router (although the latter recognizes fritz.box as a name for itself). -Martin
Re: APPSDIR review of draft-ietf-netmod-rfc6021-bis-01
MAY != SHOULD The text is as follows: The name SHOULD be fully qualified whenever possible. If the working group would like a RFC 2119 SHOULD it would help if there is an explanation in the sentence for the reader weigh the implications of not following that. My knee-jerk reaction is to use MUST. Partially-qualified domain names are ambiguous at best. that is a separate issue Similarly, wherever possible is unhelpful; if it's not possible to fully-qualify a domain name then ambiguity is guaranteed. no, that is what SHOLD means. e.g. when i write docco that has an ops clause where there is likely a knob or other op choice, i do not think i have the prerogative to tell the op how they MUST run their network. but i can say that they SHOULD do x. randy
Re: call for ideas: tail-heavy IETF process
On 5/8/2013 10:50 AM, Jari Arkko wrote: Heather, all, You are correct, Peter. MISSREF and AUTH48 are not part of the RFC Editor timed states, and the RFC Editor timed states have been largely under 7 weeks for the last year. Indeed. The actual time for what RFC Editor does for documents is quite short (and thank you and others at the RFC Editor side for that!). My stats counted both MISSREF and AUTH48, I think. I remember that when this was previously discussed (mid-2000s), we noted that the states didn't map 1:1 with who had to actually do something. Sounds like this is still true. So in this case, we're looking at RFC Editor state = Heather, please do something + some working group, please do something + author(s), please do something, and we can't tell how much time to attribute to each of these ... Spencer
Re: APPSDIR review of draft-ietf-netmod-rfc6021-bis-01
--On Thursday, May 09, 2013 09:28 +0200 Randy Bush ra...@psg.com wrote: Similarly, wherever possible is unhelpful; if it's not possible to fully-qualify a domain name then ambiguity is guaranteed. no, that is what SHOLD means. e.g. when i write docco that has an ops clause where there is likely a knob or other op choice, i do not think i have the prerogative to tell the op how they MUST run their network. but i can say that they SHOULD do x. If you are writing a protocol spec and you believe various bad things can happen to you if partially-qualified names are used, sure you do. Whether your belief about possible damage and its likelihood is reasonable is another question and that, IMO, is the discussion we should be having. Now that op has prerogatives too. Because conformance to IETF Standards is voluntary, it can ignore the MUST, leaving you the option of calling the protocol police and/or deciding not to deal with that op. Or it could decide to not deal with you because you make such unreasonable demands. But neither of those options deprive you, or the IETF, from saying MUST if you are convinced it is necessary. IMO, necessary should include interoperability, security, or stable and predictable operational reasons, despite 2119's apparent restriction to the first of those. best, john
Re: call for ideas: tail-heavy IETF process
--On Thursday, May 09, 2013 03:32 -0500 Spencer Dawkins spen...@wonderhamster.org wrote: So in this case, we're looking at RFC Editor state = Heather, please do something + some working group, please do something + author(s), please do something, and we can't tell how much time to attribute to each of these ... You could further add to that list RFC Production Center, please do something (different from an RSE wait, which is, or at least ought to be, more significant) and IESG or appropriate AD, please do something, which does happen. But the RFC Editor's numbers try (almost always successfully) to separate the two waiting on the RFC Editor Function to do something (Heather plus Production Center plus, in principle, Publisher) from the other states. Those other states could, from their point of view, be aggregated into stuck, someone else's problem. If we are looking for issues with IETF end-game process, we need to parse those, but that is a different sort of question in terms of data-gathering and reporting. best, john
Re: call for ideas: tail-heavy IETF process
On 10/05/2013 01:13, John C Klensin wrote: --On Thursday, May 09, 2013 03:32 -0500 Spencer Dawkins spen...@wonderhamster.org wrote: So in this case, we're looking at RFC Editor state = Heather, please do something + some working group, please do something + author(s), please do something, and we can't tell how much time to attribute to each of these ... You could further add to that list RFC Production Center, please do something (different from an RSE wait, which is, or at least ought to be, more significant) and IESG or appropriate AD, please do something, which does happen. But the RFC Editor's numbers try (almost always successfully) to separate the two waiting on the RFC Editor Function to do something (Heather plus Production Center plus, in principle, Publisher) from the other states. Those other states could, from their point of view, be aggregated into stuck, someone else's problem. If we are looking for issues with IETF end-game process, we need to parse those, but that is a different sort of question in terms of data-gathering and reporting. All of which suggests that, ideally, the tracker would include a variable onTheHook for each draft, containing at all times the person or role responsible for the next step. That isn't necessarily implied by the state machine. For example, AUTH48 doesn't always imply that the author is on the hook - it may be that the author has asked the WG Chair to ask the WG for a quick review of a proposed last-minute change. At that point, the WG as a whole is on the hook. Brian
Update of draft-otis-ipv6-email-authent
Dear ietf, spfbis, and repute, Until an identifier is linked with the source of an exchange by way of authentication, it must not be trusted as offering valid reputation input. For example, a valid DKIM signature lacks important context. A valid DKIM signature does not depend upon actual sources or intended recipients, both of which are essential elements in determining unsolicited messages or even whether the message is valid. SPF only offers authorization of Non-Delivery Notifications, and can not be considered to represent actual sources. Three different authors attempted to repair DKIM's header field issue within the WG process but repairs were rejected. As with the DKIM WG, being right about likely outcomes will not always prevail in offering safe and dependable protocols offering a well understood services. The initial intent for DKIM was to help prevent spoofing, but that effort ran astray with desires to extend DKIM beyond its capabilities. Flexibility allowing DKIM to be relayed removes typical rate limitations protecting a domain's reputation from occasional lapses or from messages easily taken out of context. Since a valid DKIM signature may not preclude prepended header fields, this raises important questions. When such spoofing does occur, which domain's reputation should be affected? A domain too big to block that does not add the non-existent header field hack? A domain being spoofed to improve statistical filtering? It is clear those actually responsible for abusive exchange may be ignored by these strategies. Better solutions at enforcing security and offering fair reputations are readily available. http://tools.ietf.org/html/draft-otis-ipv6-email-authent-01 DKIM can not be used to establish reputation without a link with those responsible for its transmission. Neither DKIM nor SPF established those actually responsible for the exchange. Today, unfortunately, the only thing that can be trusted in email is the ip address of the host connecting to the mail server - and even that can be subverted with BGP injection. Regards, Douglas Otis
Weekly posting summary for ietf@ietf.org
Total of 138 messages in the last 7 days. script run at: Fri May 10 00:53:02 EDT 2013 Messages | Bytes| Who +--++--+ 7.25% | 10 | 8.90% |93387 | ma...@isc.org 6.52% |9 | 7.85% |82311 | nar...@us.ibm.com 7.25% | 10 | 6.58% |69033 | john-i...@jck.com 4.35% |6 | 4.92% |51589 | sc...@kitterman.com 4.35% |6 | 3.90% |40851 | hannes.tschofe...@gmx.net 4.35% |6 | 3.70% |38841 | sm+i...@elandsys.com 3.62% |5 | 3.33% |34916 | brian.e.carpen...@gmail.com 2.90% |4 | 3.30% |34585 | doug.mtv...@gmail.com 2.90% |4 | 3.27% |34333 | alh-i...@tndh.net 2.90% |4 | 3.06% |32061 | bcla...@cisco.com 2.90% |4 | 3.05% |31953 | daedu...@btconnect.com 2.90% |4 | 2.61% |27392 | ned+i...@mauve.mrochek.com 2.17% |3 | 2.15% |22521 | do...@dougbarton.us 2.17% |3 | 1.80% |18858 | joe...@bogus.com 2.17% |3 | 1.63% |17072 | wor...@ariadne.com 2.17% |3 | 1.43% |14970 | ra...@psg.com 1.45% |2 | 1.97% |20627 | rdroms.i...@gmail.com 1.45% |2 | 1.48% |15501 | presn...@qti.qualcomm.com 1.45% |2 | 1.46% |15269 | hsan...@isdg.net 1.45% |2 | 1.43% |15015 | s...@resistor.net 1.45% |2 | 1.30% |13638 | s...@internet2.edu 1.45% |2 | 1.28% |13407 | ted.le...@nominum.com 1.45% |2 | 1.25% |13073 | elw...@dial.pipex.com 1.45% |2 | 1.19% |12444 | jari.ar...@piuha.net 1.45% |2 | 1.16% |12116 | derhoe...@gmx.net 1.45% |2 | 1.15% |12093 | j...@jlc.net 1.45% |2 | 1.06% |11096 | adr...@olddog.co.uk 1.45% |2 | 1.05% |11035 | m...@sap.com 1.45% |2 | 1.04% |10900 | pe...@akayla.com 0.72% |1 | 1.61% |16854 | o...@nlnetlabs.nl 0.72% |1 | 1.58% |16521 | rjspa...@nostrum.com 0.72% |1 | 1.41% |14746 | mohamed.boucad...@orange.com 0.72% |1 | 1.02% |10730 | l.w...@surrey.ac.uk 0.72% |1 | 0.94% | 9817 | war...@kumari.net 0.72% |1 | 0.92% | 9697 | c...@daydream.com 0.72% |1 | 0.87% | 9082 | y...@checkpoint.com 0.72% |1 | 0.82% | 8628 | t...@ecs.soton.ac.uk 0.72% |1 | 0.79% | 8334 | gonzalo.camari...@ericsson.com 0.72% |1 | 0.78% | 8214 | a...@yumaworks.com 0.72% |1 | 0.73% | 7621 | jouni.nos...@gmail.com 0.72% |1 | 0.69% | 7232 | randy_pres...@mindspring.com 0.72% |1 | 0.68% | 7184 | r...@rfc-editor.org 0.72% |1 | 0.68% | 7109 | superu...@gmail.com 0.72% |1 | 0.67% | 6977 | mcqui...@pobox.com 0.72% |1 | 0.63% | 6643 | yaronf.i...@gmail.com 0.72% |1 | 0.62% | 6543 | mcr+i...@sandelman.ca 0.72% |1 | 0.62% | 6505 | barryle...@computer.org 0.72% |1 | 0.62% | 6475 | jab...@hopcount.ca 0.72% |1 | 0.60% | 6336 | stpe...@stpeter.im 0.72% |1 | 0.58% | 6130 | d...@dcrocker.net 0.72% |1 | 0.58% | 6070 | spen...@wonderhamster.org 0.72% |1 | 0.57% | 5934 | rpellet...@isoc.org 0.72% |1 | 0.55% | 5817 | c...@tzi.org 0.72% |1 | 0.55% | 5765 | jo...@taugh.com 0.72% |1 | 0.55% | 5731 | mansa...@besserwisser.org 0.72% |1 | 0.53% | 5607 | stephen.farr...@cs.tcd.ie 0.72% |1 | 0.53% | 5583 | env...@rolamasao.org +--++--+ 100.00% | 138 |100.00% | 1048772 | Total
MMUSIC Working Group Virtual Interim Meeting, May 23, 2013
Greetings This is to announce a virtual interim meeting for the MMUSIC Working Group to take place on Thursday, May 23rd, from 7:00 am - 10:00 am Pacific Time. The goal of this meeting is to come to a resolution on the so-called Plan A or Plan B approach related to SDP signaling needed by RTCWeb, CLUE, etc. (i.e. do we have potentially lots of m= lines or very few m= lines and to what extent is there sub-negotation and signaling at the SSRC level). A more detailed agenda and logistics will be sent out separately. For now, people should take a close look at the following two drafts: http://www.ietf.org/id/draft-roach-rtcweb-plan-a-00.txt http://www.ietf.org/internet-drafts/draft-uberti-rtcweb-plan-00.txt You may also want to look at http://www.ietf.org/id/draft-roach-rtcweb-glareless-add-00.txt Thanks -- Ari Flemming (MMUSIC co-chairs) PS: We are currently also considering having a physical interim meeting the week of June 24th, likely on the US West Coast. We will await the outcome of the virtual interim meeting before making a decision on this but wanted to give people a heads-up for now.
RFC 6923 on MPLS Transport Profile (MPLS-TP) Identifiers Following ITU-T Conventions
A new Request for Comments is now available in online RFC libraries. RFC 6923 Title: MPLS Transport Profile (MPLS-TP) Identifiers Following ITU-T Conventions Author: R. Winter, E. Gray, H. van Helvoort, M. Betts Status: Standards Track Stream: IETF Date: May 2013 Mailbox:rolf.win...@neclab.eu, eric.g...@ericsson.com, huub.van.helvo...@huawei.com, malcolm.be...@zte.com.cn Pages: 12 Characters: 23811 Updates/Obsoletes/SeeAlso: None I-D Tag:draft-ietf-mpls-tp-itu-t-identifiers-08.txt URL:http://www.rfc-editor.org/rfc/rfc6923.txt This document specifies an extension to the identifiers to be used in the Transport Profile of Multiprotocol Label Switching (MPLS-TP). Identifiers that follow IP/MPLS conventions have already been defined. This memo augments that set of identifiers for MPLS-TP management and Operations, Administration, and Maintenance (OAM) functions to include identifier information in a format typically used by the International Telecommunication Union Telecommunication Standardization Sector (ITU-T). This document is a product of the Multiprotocol Label Switching Working Group of the IETF. This is now a Proposed Standard. 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 6937 on Proportional Rate Reduction for TCP
A new Request for Comments is now available in online RFC libraries. RFC 6937 Title: Proportional Rate Reduction for TCP Author: M. Mathis, N. Dukkipati, Y. Cheng Status: Experimental Stream: IETF Date: May 2013 Mailbox:mattmat...@google.com, nandi...@google.com, ych...@google.com Pages: 16 Characters: 39437 Updates/Obsoletes/SeeAlso: None I-D Tag:draft-ietf-tcpm-proportional-rate-reduction-04.txt URL:http://www.rfc-editor.org/rfc/rfc6937.txt This document describes an experimental Proportional Rate Reduction (PRR) algorithm as an alternative to the widely deployed Fast Recovery and Rate-Halving algorithms. These algorithms determine the amount of data sent by TCP during loss recovery. PRR minimizes excess window adjustments, and the actual window size at the end of recovery will be as close as possible to the ssthresh, as determined by the congestion control algorithm. This document is a product of the TCP Maintenance and Minor Extensions Working Group of the IETF. EXPERIMENTAL: This memo defines an Experimental Protocol for the Internet community. It does not specify an Internet standard of any kind. Discussion and suggestions for improvement are requested. 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 6943 on Issues in Identifier Comparison for Security Purposes
A new Request for Comments is now available in online RFC libraries. RFC 6943 Title: Issues in Identifier Comparison for Security Purposes Author: D. Thaler, Ed. Status: Informational Stream: IAB Date: May 2013 Mailbox:dtha...@microsoft.com Pages: 26 Characters: 62676 Updates/Obsoletes/SeeAlso: None I-D Tag:draft-iab-identifier-comparison-09.txt URL:http://www.rfc-editor.org/rfc/rfc6943.txt Identifiers such as hostnames, URIs, IP addresses, and email addresses are often used in security contexts to identify security principals and resources. In such contexts, an identifier presented via some protocol is often compared using some policy to make security decisions such as whether the security principal may access the resource, what level of authentication or encryption is required, etc. If the parties involved in a security decision use different algorithms to compare identifiers, then failure scenarios ranging from denial of service to elevation of privilege can result. This document provides a discussion of these issues that designers should consider when defining identifiers and protocols, and when constructing architectures that use multiple protocols. This document is a product of the Internet Architecture Board. 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
