Re: Detective story (was: Language editing)
On May 7, 2013, at 1:08 AM, SM s...@resistor.net wrote: At 13:23 06-05-2013, Brian E Carpenter wrote: I don't that is quite right. The problem in this case is not to do with linguistic quality. It's due to a lack of formal verification Quoting from the detective story: At [censored] we have changed our mail server configuration in the past few months, and are now using a mail server from [censored] namely the [censored] Server. There isn't any mention of whether the mail server was tested. I don't know why you censored this, but that particular implementation is used by a vast majority of corporations. The one good thing about running with the crowd is that stuff pretty much just works. And it does, unless you do heresy something weird like enabling IPv6 /heresy. Seemingly at random my efforts to send mail just fail. There would likely be an error code with text providing an explanation. I would probably follow a different debugging path. Anyway, the session showed: EHLO [IPv6:2001:df9::4015:1430:8367:2073:5d0] 501 5.5.4 Invalid domain name Yeah, I would also start with the tcpdump. But that part of the story sounded bogus. 2nd paragraph has this: To collect my mail I use IMAP, and to send my mail I use STMP, both standard protocols. These days security can’t be ignored so we use TLS for channel encryption. All pretty standard stuff. So how did he get to see the server response, or test with telnet? This is where I go and read RFC 6409 and I find that: The MSA SHOULD log message errors, especially apparent misconfigurations of client software. And then follow up with RFC 5321 where I find a mention of address literals. I go and read RFC 4291 which is a Draft Standard. I see an update in RFC 5952 which is a Proposed Standard. As I was told that the Internet runs on Proposed Standards that update must be right. I see the following: The recommendation in this section SHOULD be followed by systems when generating an address to be represented as text, but all implementations MUST accept and be able to handle any legitimate [RFC4291] format. Gee, you read a lot of RFCs when debugging network problems :-). I only do so if I'm going to file a bug report / support ticket Back to the detective story: The writing if RFC5952 is incredibly sloppy for a Proposed Standard I look at the write-up: The 6MAN working group reviewed and discussed this document several times. There is a strong consensus to move this forward. This document has been reviewed by key members of the 6MAN working group and the chairs. I look at the IESG evaluation and I see: Language grammar are rough. Between you and me, these Area Directors are trouble-makers. :-) So they are. But the hard-to-read parts of this spec are mainly the motivational sections (everything but 4). It might have been clearer to state again that the whole point of this spec is conservative in what you send. Liberal in what you accept is mentioned in the first paragraph of section 4. I verify compliance (2010), RFC 2821, RFC 4409; there isn't any mention of the IPv6 specifications mentioned in the detective story. There are people out there who have to fix problems like this. There are people out there who have to read those specifications and figure out where is the head and where is the tail. Yup. That's why those people get the big bucks. Regards, -sm
Re: secdir review of draft-ietf-mmusic-sdp-cs-17
Hi Samuel, the authors of this draft have reviewed it in order to address your comments: http://tools.ietf.org/html/draft-ietf-mmusic-sdp-cs-18 Could you please have a look at this revision and let them know whether you are happy with it? Thanks, Gonzalo On 04/02/2013 9:08 PM, Samuel Weiler wrote: I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. This document allows SIP endpoints to negotiate the use of a circuit-switched (e.g. PSTN) channel. It presents a mechanism for correlating an incoming circuit-switched connection with a given SDP/SIP session by sending a nonce or a static string. Summary: I would like to see a stronger authentication mechanism defined to replace the static string or plaintext password nonce. I am content with the analysis of security weaknesses: an attacker could trick someone into initiating a potentially expensive PSTN call, and the correlation mechanism is weak. I am not content with the use of a mere nonce or static string for correlation. That is the equivalent of sending plaintext passwords, and I suspect we have better mechanisms available that could allow for mutual endpoint authentication, making it statistically unlikely for a man-in-the-middle to participate successfully in the correlation exchange. The document makes a case for using short strings/nonces (e.g. a caller-ID string or 10 DTFM digits). I suspect both that those lengths could be extended without great pain and that some stronger authentication mechanisms could work with such short strings, especially given the ability to send longer keying material in the packet-switched SDP session. Non-security observation: I'm worried that the architecture of the current correlation mechanism will have some unintended consequences. From section 5.2.3: The endpoints should be able to correlate the circuit-switched bearer with the session negotiated with SDP in order to avoid ringing for an incoming circuit-switched bearer that is related to the session controlled with SDP (and SIP). As I understand it, some of the defined variants of the correlation scheme require answering the call (e.g. the DTMF scheme) before knowing whether or not the channel corresponds to a SIP session. If it does not, then what? The call is already answered, which gives a surprising user experience. Feel free to tell me I'm off base with this one. -- Sam
Re: Last Call: draft-eastlake-rfc5342bis-02.txt (IANA Considerations and IETF Protocol and Documentation Usage for IEEE 802 Parameters) to Best Current Practice
On 5/7/13 12:07 PM, The IESG wrote: The IESG has received a request from an individual submitter to consider the following document: - 'IANA Considerations and IETF Protocol and Documentation Usage for IEEE 802 Parameters' draft-eastlake-rfc5342bis-02.txt as Best Current Practice Sponsoring AD here, Getting feedback on the 5342bis document is important since this is the primary consensus call. Thanks Joel 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 2013-06-04. 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 Some IETF protocols make use of Ethernet frame formats and IEEE 802 parameters. This document discusses some use of such parameters in IETF protocols, specifies IANA considerations for assignment of points under the IANA OUI (Organizationally Unique Identifier), provides some values for use in documentation, and obsoletes RFC 5342. The file can be obtained via http://datatracker.ietf.org/doc/draft-eastlake-rfc5342bis/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-eastlake-rfc5342bis/ballot/ No IPR declarations have been submitted directly on this I-D.
Re: Language editing
Maybe things have changed, but, if one actually believes the robustness principle, then, in the case Geoff cites, Exchange is simply non-conforming -- not because the spec prohibits rejecting on the basis of a fine distinction about IPv6 formats, but because doing so is unnecessary, inconsistent with the robustness principle, and, arguably, plain silly. I'm afraid I'm going to have to disagree here. If you look at RFC 5321 and are unaware of the history of how the text came about, it gives the definite appearance of going out of its way to ban the use of :: to replace a single 0. A reasonable interpretation is therefore that such forms are disallowed for a reason. It's fine to be tolerant of stuff the relevant standard doesn't allow but doesn't call out explicitly. But that's not the case here. In any case, if you want to fix this, we could change RFC 5321 to accept this form. But as Mark Andrews points out, you can't make it legal to send such forms without breaking interoperability. I suppose we could make the change and recycle at proposed, but that seems rather extreme to fix what is in fact a nonissue. I'll also point out that this has diddley-squat to do with formal verification processes. Again as Mark Anrdrews points out, we deployed something with a restriction that subsequently turned out to be unnecessary, and now we're stuck with it. Indeed, had formal verification processes been properly used, they would have flagged any attempt to change this as breaking interoperability. Ned
Re: Language editing
--On Tuesday, May 07, 2013 08:08 -0700 Ned Freed ned.fr...@mrochek.com wrote: Maybe things have changed, but, if one actually believes the robustness principle, then, in the case Geoff cites, Exchange is simply non-conforming -- not because the spec prohibits rejecting on the basis of a fine distinction about IPv6 formats, but because doing so is unnecessary, inconsistent with the robustness principle, and, arguably, plain silly. I'm afraid I'm going to have to disagree here. If you look at RFC 5321 and are unaware of the history of how the text came about, it gives the definite appearance of going out of its way to ban the use of :: to replace a single 0. A reasonable interpretation is therefore that such forms are disallowed for a reason. I hadn't looked at the syntax (as you know, the other part of that history of how the text came about is that I didn't write it or even make an effort to check it carefully). But, having now done so, you are completely correct. It's fine to be tolerant of stuff the relevant standard doesn't allow but doesn't call out explicitly. But that's not the case here. Of course, we have lots of implementations that allow things on input that the standard explicitly prohibits and we rarely spend much time complaining about them. I suppose that tolerance for bare LF is among the most common examples. In any case, if you want to fix this, we could change RFC 5321 to accept this form. But as Mark Andrews points out, you can't make it legal to send such forms without breaking interoperability. I suppose we could make the change and recycle at proposed, but that seems rather extreme to fix what is in fact a nonissue. Agreed I'll also point out that this has diddley-squat to do with formal verification processes. Again as Mark Anrdrews points out, we deployed something with a restriction that subsequently turned out to be unnecessary, and now we're stuck with it. Indeed, had formal verification processes been properly used, they would have flagged any attempt to change this as breaking interoperability. Also agreed. best, john
Re: Language editing
On 08/05/2013 03:28, John C Klensin wrote: ... I'll also point out that this has diddley-squat to do with formal verification processes. Again as Mark Anrdrews points out, we deployed something with a restriction that subsequently turned out to be unnecessary, and now we're stuck with it. Indeed, had formal verification processes been properly used, they would have flagged any attempt to change this as breaking interoperability. Also agreed. To be clear, I'm no fan of formal verification either, but this *is* a case where the IETF's lapse in formality has come back to bite, and the Postel principle would have helped. Also, given the original subject of the thread, I don't see how language editing could have made any difference. Brian
Re: Language editing
On 08/05/2013 03:28, John C Klensin wrote: ... I'll also point out that this has diddley-squat to do with formal verification processes. Again as Mark Anrdrews points out, we deployed something with a restriction that subsequently turned out to be unnecessary, and now we're stuck with it. Indeed, had formal verification processes been properly used, they would have flagged any attempt to change this as breaking interoperability. Also agreed. To be clear, I'm no fan of formal verification either, but this *is* a case where the IETF's lapse in formality has come back to bite, and the Postel principle would have helped. Also, given the original subject of the thread, I don't see how language editing could have made any difference. Reread the notes about the history behind this in this thread. You haven't even come close to making a case that formal verification of the standards would have prevented this from happening. (Formal verification of implementation compliance to the standards would of course have prevented Apple's client bug, but that's a very different thing.) You are, however, correct that this has nothing to do with specification editing. Ned
Re: call for ideas: tail-heavy IETF process
On 5/2/13 4:58 PM, Dave Crocker wrote: On 5/2/2013 3:25 PM, Jari Arkko wrote: But the delay was really not my main concern. Primarily because I think other issues such as transparency to the working group or late surprises are more fundamental issues than mere timing. But also because I actually*do* have some statistics that seem to indicate that, overall, the last phase still goes through pretty quickly. Look athttp://www.arkko.com/tools/lifecycle/wgdocs.html and compare the WG, IESG, and RFC editor times in the first graph. The WG time dominates. (I said seem to indicate because the results are pretty dated and I'm not really sure how valid they are, but they match at least my intuitive experience.) Not saying delay reduction wouldn't be useful, the overall times are still very long, and the IETF last call - IESG time is still a significant component. Just that delay would not be my primary Jari, Very interesting set of graphs. Thanks! Doing very rough eyeballing of the left side averages against the right side averages -- that is, considering how things have changed over the last 10 years -- it looks like: Working groups were taking around 500 days and now take around 600. The IESG was taking around 200 days and now takes around 110. The RFC then and now takes around 100 days (with lots of variation between the then and the now, of course.) I'm curious what exactly falls under the RFC Editor phase. My impression from recent plenaries is that the purely RFC Editor responsibilities (not including states like MISSREF and AUTH48) has been running around 6-7 weeks. That's a far cry from 100 days. Peter
Re: Language editing
On 08/05/2013 08:33, Ned Freed wrote: On 08/05/2013 03:28, John C Klensin wrote: ... I'll also point out that this has diddley-squat to do with formal verification processes. Again as Mark Anrdrews points out, we deployed something with a restriction that subsequently turned out to be unnecessary, and now we're stuck with it. Indeed, had formal verification processes been properly used, they would have flagged any attempt to change this as breaking interoperability. Also agreed. To be clear, I'm no fan of formal verification either, but this *is* a case where the IETF's lapse in formality has come back to bite, and the Postel principle would have helped. Also, given the original subject of the thread, I don't see how language editing could have made any difference. Reread the notes about the history behind this in this thread. You haven't even come close to making a case that formal verification of the standards would have prevented this from happening. You are correct if only considering the mail standards. I suspect that a serious attempt at formal verification would have thrown up an inconsistency between the set of mail-related standards and the URI standard. However, I think the underlying problem here is that we ended up defining the text representation of IPv6 addresses in three different places, rather than having a single normative source. (ABNF in the mail standards, ABNF in the URI standard, and English in ipv6/6man standards.) (Formal verification of implementation compliance to the standards would of course have prevented Apple's client bug, but that's a very different thing.) You are, however, correct that this has nothing to do with specification editing. Ned
Re: Language editing
Hi - From: Brian E Carpenter brian.e.carpen...@gmail.com To: Ned Freed ned.fr...@mrochek.com Cc: John C Klensin john-i...@jck.com; yaronf.i...@gmail.com; ietf@ietf.org Sent: Tuesday, May 07, 2013 2:19 PM Subject: Re: Language editing ... You are correct if only considering the mail standards. I suspect that a serious attempt at formal verification would have thrown up an inconsistency between the set of mail-related standards and the URI standard. However, I think the underlying problem here is that we ended up defining the text representation of IPv6 addresses in three different places, rather than having a single normative source. (ABNF in the mail standards, ABNF in the URI standard, and English in ipv6/6man standards.) (Formal verification of implementation compliance to the standards would of course have prevented Apple's client bug, but that's a very different thing.) You are, however, correct that this has nothing to do with specification editing. Ned I'm not so sure about that. To me this seems to be a case of inappropriate use of MUST. First a reminder from RFC 2119: In particular, they MUST only be used where it is actually required for interoperation or to limit behavior which has potential for causing harm (e.g., limiting retransmisssions) The prohibition against using :: more than once is amply motivated. Multiple occurrances would introduce ambiguities, so that prohibition clearly warrants a MUST. The prohibition against using :: for a single 0 seems to lack such an obvious syntactic / semantic motivation. Does anyone remember why this syntactic limitation was added? Randy
Re: Language editing
On 08/05/2013 08:33, Ned Freed wrote: On 08/05/2013 03:28, John C Klensin wrote: ... I'll also point out that this has diddley-squat to do with formal verification processes. Again as Mark Anrdrews points out, we deployed something with a restriction that subsequently turned out to be unnecessary, and now we're stuck with it. Indeed, had formal verification processes been properly used, they would have flagged any attempt to change this as breaking interoperability. Also agreed. To be clear, I'm no fan of formal verification either, but this *is* a case where the IETF's lapse in formality has come back to bite, and the Postel principle would have helped. Also, given the original subject of the thread, I don't see how language editing could have made any difference. Reread the notes about the history behind this in this thread. You haven't even come close to making a case that formal verification of the standards would have prevented this from happening. You are correct if only considering the mail standards. I suspect that a serious attempt at formal verification would have thrown up an inconsistency between the set of mail-related standards and the URI standard. Which is relevant to the present situation... how exactly? And in any case, the relevant URI standard incorporates the ABNF from RFC 2373, but doesn't state whether or not it also inherits restrictions specified in prose in that specification, which is where the restriction in RFC 2821 originated. However, I think the underlying problem here is that we ended up defining the text representation of IPv6 addresses in three different places, rather than having a single normative source. (ABNF in the mail standards, ABNF in the URI standard, and English in ipv6/6man standards.) Except that wasn't the problem. The ABNF in the email standards is consistent with what the other standards said when RFC 2821 was published. And once that happened the die was cast as far as email usage was concerned. The fact that the other standards later decided to loosen the rules in this regard is what caused the inconsistency. If you want to blame something, it has to be either the initial decision to limit use of :: or the subsequent decision to remove that limit. And for increased formalism to have helped it would have to have prevented one of those from happening. I supose that's possible, but I certainly don't see it as inevitable. Ned
Last Call: draft-eastlake-rfc5342bis-02.txt (IANA Considerations and IETF Protocol and Documentation Usage for IEEE 802 Parameters) to Best Current Practice
The IESG has received a request from an individual submitter to consider the following document: - 'IANA Considerations and IETF Protocol and Documentation Usage for IEEE 802 Parameters' draft-eastlake-rfc5342bis-02.txt as Best Current Practice 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 2013-06-04. 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 Some IETF protocols make use of Ethernet frame formats and IEEE 802 parameters. This document discusses some use of such parameters in IETF protocols, specifies IANA considerations for assignment of points under the IANA OUI (Organizationally Unique Identifier), provides some values for use in documentation, and obsoletes RFC 5342. The file can be obtained via http://datatracker.ietf.org/doc/draft-eastlake-rfc5342bis/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-eastlake-rfc5342bis/ballot/ No IPR declarations have been submitted directly on this I-D.
Protocol Action: 'RTP Control Protocol(RTCP) Extended Report (XR) Block for Burst/Gap Discard metric Reporting' to Proposed Standard (draft-ietf-xrblock-rtcp-xr-burst-gap-discard-14.txt)
The IESG has approved the following document: - 'RTP Control Protocol(RTCP) Extended Report (XR) Block for Burst/Gap Discard metric Reporting' (draft-ietf-xrblock-rtcp-xr-burst-gap-discard-14.txt) as Proposed Standard This document is the product of the Metric Blocks for use with RTCP's Extended Report Framework Working Group. The IESG contact persons are Gonzalo Camarillo and Richard Barnes. A URL of this Internet Draft is: http://datatracker.ietf.org/doc/draft-ietf-xrblock-rtcp-xr-burst-gap-discard/ Technical Summary This document defines an RTP Control Protocol(RTCP) Extended Report (XR) Block that allows the reporting of Burst and Gap Discard metrics for use in a range of RTP applications. Working Group Summary The WG path of this document was reasonably short and efficient. Several technical comments were made during the reviews and all were resolved with consensus. Document Quality At least one vendor has implemented this draft. It is expected that with the approval of this document the number of implementations will increase. Personnel Dan Romascanu is the Document Shepherd. Gonzalo Camarillo is the Responsible Area Director.
