http://blog.gmane.org/gmane.ietf.general hourly 1 1901-01-01T00:00+00:00 http://gmane.org/img/gmane-25t.png http://gmane.org http://permalink.gmane.org/gmane.ietf.general/51997 <pre>Total of 59 messages in the last 7 days. script run at: Fri May 25 00:53:03 EDT 2012 Messages | Bytes | Who --------+------+--------+----------+------------------------ 8.47% | 5 | 5.54% | 25712 | randy&lt; at &gt;psg.com 6.78% | 4 | 7.16% | 33268 | stpeter&lt; at &gt;stpeter.im 3.39% | 2 | 9.13% | 42391 | ron.even.tlv&lt; at &gt;gmail.com 5.08% | 3 | 6.59% | 30626 | shanna&lt; at &gt;juniper.net 5.08% | 3 | 4.94% | 22928 | marshall.eubanks&lt; at &gt;gmail.com 5.08% | 3 | 4.57% | 21219 | brian.e.carpenter&lt; at &gt;gmail.com 5.08% | 3 | 4.30% | 19950 | rdroms.ietf&lt; at &gt;gmail.com 1.69% | 1 | 6.05% | 28097 | bclaise&lt; at &gt;cisco.com 3.39% | 2 | 3.54% | 16456 | trammell&lt; at &gt;tik.ee.ethz.ch 3.39% | 2 | 3.27% | 15189 | sm&lt; at &gt;resistor.net 3.39% | 2 | 3.15% | 14620 | hsantos&lt; at &gt;isdg.net 3.39% | 2 | 2.53% | 11729 | cabo&lt; at &gt;tzi.org 3.39% | 2 | 2.52% | 11728 | ned+ietf&lt; at &gt;mauve.mrochek.com 1.69% | 1 | 2.94% | 13672 | alexey.melnikov&lt; at &gt;isode.com 1.69% | 1 | 1.80% | 8383 | hartmans-ietf&lt; at &gt;mit.edu 1.69% | 1 | 1.77% | 8218 | narten&lt; at &gt;us.ibm.com 1.69% | 1 | 1.72% | 7972 | mcquilwp&lt; at &gt;pobox.com 1.69% | 1 | 1.69% | 7844 | marka&lt; at &gt;isc.org 1.69% | 1 | 1.65% | 7684 | abdussalambaryun&lt; at &gt;gmail.com 1.69% | 1 | 1.57% | 7270 | weiler+secdir&lt; at &gt;watson.org 1.69% | 1 | 1.56% | 7263 | jhutz&lt; at &gt;cmu.edu 1.69% | 1 | 1.50% | 6980 | john-ietf&lt; at &gt;jck.com 1.69% | 1 | 1.44% | 6703 | petithug&lt; at &gt;acm.org 1.69% | 1 | 1.44% | 6687 | housley&lt; at &gt;vigilsec.com 1.69% | 1 | 1.42% | 6591 | bob.hinden&lt; at &gt;gmail.com 1.69% | 1 | 1.39% | 6464 | erosen&lt; at &gt;cisco.com 1.69% | 1 | 1.34% | 6215 | stephen.farrell&lt; at &gt;cs.tcd.ie 1.69% | 1 | 1.33% | 6161 | ynir&lt; at &gt;checkpoint.com 1.69% | 1 | 1.32% | 6136 | yaakov_s&lt; at &gt;rad.com 1.69% | 1 | 1.27% | 5907 | chair&lt; at &gt;ietf.org 1.69% | 1 | 1.27% | 5894 | pradeepar&lt; at &gt;gmail.com 1.69% | 1 | 1.26% | 5850 | vinayakh&lt; at &gt;gmail.com 1.69% | 1 | 1.22% | 5646 | elwynd&lt; at &gt;folly.org.uk 1.69% | 1 | 1.21% | 5627 | cos&lt; at &gt;aaaaa.org 1.69% | 1 | 1.21% | 5618 | lear&lt; at &gt;cisco.com 1.69% | 1 | 1.18% | 5462 | bortzmeyer&lt; at &gt;nic.fr 1.69% | 1 | 1.11% | 5178 | julian.reschke&lt; at &gt;gmx.de 1.69% | 1 | 1.11% | 5138 | dhc&lt; at &gt;dcrocker.net --------+------+--------+----------+------------------------ 100.00% | 59 |100.00% | 464476 | Total </pre> Thomas Narten 2012-05-25T04:53:03 http://permalink.gmane.org/gmane.ietf.general/51996 <pre> Got it. Thanks! Peter </pre> Peter Saint-Andre 2012-05-25T00:25:16 http://permalink.gmane.org/gmane.ietf.general/51995 <pre>Hi Peter, At 15:01 24-05-2012, Peter Saint-Andre wrote: Ok. The audio seemed like a grey area to me. I'll keep that discussion for another day. Ok. The possible steps are: 1. Reminder checks whether there are claims of IPR that needs to be disclosed 2. Someone mentions a claim 3. Ask the WG whether they are ok given the new information 4. consensus call on the technical work Step 3 is the follow-up question. I consider it as separate as what is being asked of the WG participant is not clear. Some guidance is needed so participants know what they are being asked to do or what they can say (see past OAUTH thread as an example). Regards, -sm </pre> SM 2012-05-24T23:10:18 http://permalink.gmane.org/gmane.ietf.general/51994 <pre> OK, Tim and I will look into perhaps adding a sentence or two about this. Even if a document is mentioned in a charter as a likely starting point, the chairs still need to make an explicit call for adoption of that document as a WG item. The slides and audio are part of the record. Naturally it would be best if the disclosure were explicitly called out in the minutes, as well. However, I agree with you that a formal disclosure is always best. Let me chat about this with Tim. WFM. Yes, I saw that message, and I thought it was helpful. Now your wording is not clear to me. What do you mean by "the follow-up question"? Good point. Thanks for the feedback! Peter </pre> Peter Saint-Andre 2012-05-24T22:01:44 http://permalink.gmane.org/gmane.ietf.general/51992 <pre> During the IESG off-site meeting, this topic received quite a bit of discussion. The IESG recognized that blue sheet information is valuable for peer pressure to abide by the IPR rules. In contrast, I understand the concerns that have been raised on this thread. As a result, I am looking into a mechanism where a datatracker password is needed to get the blue sheet images. This would be the same password that an IETF community participant will to use with the soon-to-be-released Internet-Draft Tracking features (see RFC 6293). These accounts are available to anyone; however, the need for an account to access blue sheet images raises the bar for access. Additionally, the need for an account will keep the blue sheet images hidden from web crawlers. Thanks to Ted hardie for the question that lead to this potential solution. Russ </pre> Russ Housley 2012-05-24T18:42:45 http://permalink.gmane.org/gmane.ietf.general/51991 <pre>Please sent it to &lt;ietf-action&lt; at &gt;ietf.org&gt;. Bob On May 24, 2012, at 10:58 AM, Vinayak Hegde wrote: </pre> Bob Hinden 2012-05-24T18:32:20 http://permalink.gmane.org/gmane.ietf.general/51990 <pre>Hi, I was trying to register for IETF 84 and tried the link http://www.ietf.org/meeting/register.html from the main site. Sometimes it takes me to the IETF 80 page (registration over) and sometimes it takes me to the right note well page. Trying to replicate the issue, I am seeing that it works well on IE and Safari on Windows but not on Firefox on Linux/Windows. Further attempts to replicate this problem on Firefox on Windows did not work. Posting this here as I am not sure what is the right place to post such issues. Please point me there. Also hoping that I would get more datapoints of this problem from other people on this list (which probably will help pinpoint the problem). Looks like a cache-expiry or an improper redirection issue. Either ways the workaround is to change the number of the IETF meeting in the link as this (https://www.ietf.org/registration/ietf84/ietfreg.py) works. </pre> Vinayak Hegde 2012-05-24T17:58:13 http://permalink.gmane.org/gmane.ietf.general/51989 <pre> It does need copy-editing. As far as I know, the IETF does not have a team of volunteer copy-editors, and multiple attempts to get help from within the working group have met with only limited success (most notably in the form of help from Stephen, who did quite a bit of work on this before starting on his AD review). If anyone wants to volunteer to spend some time on helping to clean up this document, let me know. Otherwise, I think our only options are either to ask the paid editors at the RFC production center to take a stab, or block an otherwise completed document on cycles that may never appear. It does; I somehow missed that in my review. The algorithm is fine, but the description requires careful reading. Step 2 kicks in only if you get a DHCP response containing Kerberos configuration but no nameservers. There are only two branches here. Either you get a response containing one or more relevant SRV RRs, or you don't. The latter is phrased as "no answer from the DNS server", but is meant to also include errors and empty responses. A suggestion for how to word this better would be welcome. Yes, the description is wrong; the correct length is _23_ plus the length of the realm. The 16-bit option code and length are part of the DHCPv6 protocol; unless I'm misremembering, the length is the length of the option payload (that is, excluding the two header fields). Thanks for taking the time to review this. </pre> Jeffrey Hutzelman 2012-05-24T17:50:37 http://permalink.gmane.org/gmane.ietf.general/51988 <pre> To me this seems to be the compelling, non-surprising result of this discussion. We don't need another 100 messages to finally arrive at the same result. So it would help if the responsible I* would make a decision, please. Grüße, Carsten </pre> Carsten Bormann 2012-05-24T15:37:20 http://permalink.gmane.org/gmane.ietf.general/51987 <pre>Hello All Had a question on RFC 3315, Section 18.1.2 Creation and Transmission of Confirm messages When a client changes its configuration from dhcpv6 enabled to static ipv6, is this considered as moving to a new link and is the client required to send out a Confirm message ? Thanks pradeep </pre> pradeep ramachandran 2012-05-23T23:31:02 http://permalink.gmane.org/gmane.ietf.general/51986 <pre>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 doc specifies several DHCPv6 options for carrying Kerberos config info. There are obvious risks to doing this, but they're discussed reasonably well in this and similar cited docs (e.g. RFC3634, which specifies a much more limited option for DHCPv4). The doc explains by DNS service discovery isn't ideal for some environments. With that said, there are some things that need clarification, and the doc sorely needs an editorial pass. As-is, the doc is not ready for publication. I will be happy to review the doc again once it's been thoroughly edited. Things that need clarification or consideration: For the transport type field, would it be better to use a bitmask? Then one could use a single DHCPv6 option to specify a KDC that's reachable over both TCP and UDP, rather than needing two DHCPv6 options. Section 7 uses the term "TGT" without expansion. In the Kerberos world I can't imagine someone not knowing what this is, but it's not clear to the layman. It probably needs to be expanded. The algorithm in section 4.1 needs work. The obvious thing is to read it linearly. Doing that, one would prefer DHCP over DNS SVR info (per step 2), which is not what step 6 and the graphic say. Saying "no answer from the DNS server" is probably not the desired semantic. In 3.4, the option-len field is ambiguous. It says "24-octet + the length of the realm-name field in octets." But it looks to me like this option is 27 octets + length of realm name. Perhaps it would be better to just count the length of the realm name? And here are some examples of wording that needs work. There are many more -- I quit copying them into this review after the first few: 3.2 "This option informs a DHCPv6 server of which realm the client want to access, ..." 7 "... a rogue KDC that does not know the client access." What is "the client access"? "The incorrect KDC is not be able to proceed any further state of the client." "The considerable situation is that the support of an unconfigured workstation used by multiple users, which obtains its KDC information and default realm via DHCP." </pre> Samuel Weiler 2012-05-23T23:12:17 http://permalink.gmane.org/gmane.ietf.general/51985 <pre>For what it is worth, here is my opinion on this subject (which I was asked to post here). I see possible privacy law problems with posting the blue sheets, so I would not. I see a good reason to scan and have images of new blue sheets, make it easier to respond to subpoenas. I do see a historical benefit to keeping the blue sheets (as blue sheets, not just scans), and the expense of doing so is minimal, so I would urge that their archiving be continued. Regards Marshall On Thu, May 10, 2012 at 6:11 PM, SM &lt;sm&lt; at &gt;resistor.net&gt; wrote: </pre> Marshall Eubanks 2012-05-24T14:12:09 http://permalink.gmane.org/gmane.ietf.general/51984 <pre>Sam, Thanks for addressing my comments in draft-ietf-emu-chbind-16.txt. I'm happy with this version. All my substantive concerns are addressed. I do see two non-substantive issues. These can be addressed in some future version or not at all. 1) The word "subvert" is misspelled as "subvirt" in the new text. 2) Editing Charles Clancy's address in the Authors' Addresses section has apparently caused the list of authors in the top right corner of the first page to revert to this suboptimal form: EMU Working Group S. Hartman, Ed. Internet-Draft Painless Security Intended status: Standards Track T. Clancy Expires: November 25, 2012 Department of Electrical Engineering and Computer Science K. Hoeper Motorola Solutions, Inc. As you can see, Dr. Clancy's affiliation has now changed back to "Department of Electrical Engineering and Computer Science". I guess that whatever tool you're using to create the draft must insist on placing the second line of each author's address on the first page. If that's the case, you might want to change Dr. Clancy's address to T. Charles Clancy Virginia Tech Department of Electrical Engineering and Computer Science Arlington, VA 22203 USA Or perhaps you'll just have to surrender to the flawed tool and leave the credit for Dr. Clancy on the first page as nonsensical. Thanks for your patience in addressing the issues that I raised. I think the document is much better for this attention. Take care, Steve </pre> Stephen Hanna 2012-05-24T13:07:33 http://permalink.gmane.org/gmane.ietf.general/51982 <pre> Sounds good to me. Best regards, Julian </pre> Julian Reschke 2012-05-24T06:34:09 http://permalink.gmane.org/gmane.ietf.general/51981 <pre>Folks, g'day. There are periodic questions about ABNF that go beyond the specifics of a specification attempting to use it. While these are not hot topics, they do occur periodically. Also, there is support material (software, documentation) for ABNF that has no single, natural home. I'd like to suggest an abnf-discuss&lt; at &gt;ietf.org mailing list and an abnf.ietf.org web page. Thoughts? d/ </pre> Dave Crocker 2012-05-23T16:56:49 http://permalink.gmane.org/gmane.ietf.general/51980 <pre>Hi It is preferable to update RFC2119 to be more suitable for IETF RFCs in the future, IMO importance of using CAPS is understood, but when to use lower case (e.g. must, should, etc.) is not clear. Some use their sensibility to determine when to use lower case. In the end we can leave it for the editors to feedback on that when submitting, or use different sentences. In summary, from some discussions, RFC2119 seems not to be the best practice so far. Abdussalam +++++++++++++++++++++++++++++++++++++++++++++ --On Sunday, May 20, 2012 07:53 +0100 Brian E Carpenter &lt;brian.e.carpenter at gmail.com&gt; wrote: Brian, I've been trying really hard to avoid this discussion, but I think the above is misleading. In recent years, various IESG members have insisted that any IETF Track document that contains anything approximating conformance language include the 2119 reference and whatever the strict interpretation of the week is about caps, etc. As Randy suggests, there have been signs of more nuance in the last IESG or two, but... The same problem applies to the other issue with 2119, which is that we have history for at least two different interpretations of those words, the ones in 2119 that are interpreted as "necessary for interoperability" and the ones in, e.g., 1122/1123 (Section 1.3.2 in the latter) which are "requirements of the specification" without binding those requirements to a particular reason. From my point of view, the other difficulty with treating 2119 like Received Wisdom and a set of absolute requirements is that the interoperability criterion often makes no sense for what are perfectly reasonable requirements. As an example drawn from 1123, a specification might reasonably say "this option MUST be configurable" because it is necessary to make things work in a plausible way even if that statement cannot be explicitly linked to "won't interoperate unless it does". But again, in recent years, some IESG members (and others) have insisted that only the 2119 definitions are permitted. The combination of the two is known in some quarters as writing technically poor or deficient specs in the interest of clear conformance to procedures. At least historically, that was a trap the IETF tried to avoid. john </pre> Abdussalam Baryun 2012-05-23T10:49:28 http://permalink.gmane.org/gmane.ietf.general/51979 <pre>Hi, Peter, One minor point, inline... On May 21, 2012, at 5:16 PM, Peter Saint-Andre wrote: This is IMO the right way to go. During the creation of this document, we envisioned in most cases that work to extend IODEF would not have any other "natural" home, and as such would be done within the IETF in the MILE WG; this assumption is probably apparent in the document. In cases where the work _does_ have a natural home (the application of IODEF to XMPP-specific events is a perfect example), it definitely makes sense to do work there in possible consultation with the MILE WG. Indeed, for such cases, the IODEF expert review on IODEF extension schemas specified by draft-ietf-mile-iodef-xmlreg would be a final backstop to ensure that specified extensions are consistent with IODEF. Best regards, Brian (as author, draft-ietf-mile-template) </pre> Brian Trammell 2012-05-23T12:08:28 http://permalink.gmane.org/gmane.ietf.general/51978 <pre>Hi Peter, I understand why the intended status is not BCP. I suggest taking into account the wider audience feedback to determine whether the it should not be made clearer. A question which is not covered by the draft is when a draft is "adopted" through a charter. I assume that the AD will contact the authors in such cases. In Section 2: There is a typo, "secretatires". in Section 3.1: "If necessary disclosures have not been submitted, the chairs have a choice: insist on an informal disclosure in the presentation, or deny the agenda slot unless the IPR disclosure is submitted. One factor in this decision could be the number of revisions that have occurred: the chairs might wish to permit presentation of a -00 draft with a verbal disclosure, but not after a draft has gone through multiple cycles." The boilerplate explicitly states that this draft as any other draft is submitted in full conformance with the provisions of the usual BCPs. If disclosures are necessary they should be submitted especially if the goal of this draft is to promote compliance. Informal disclosures causes uncomfortable situations as there are usually valid reasons. There is also the presumption of good faith which makes it a difficult decision. I don't know how often verbal disclosures go on record. The information may not be available to the working group (decisions are taken through the mailing list) unless the participants go through the audio. In A.1: "In order to comply with IETF processes while avoiding unnecessary delays, document authors and contributors to our discussions in the FOO WG are asked to take these messages seriously, and to reply in a timely fashion." Is there any message from WG chairs which should not be taken seriously? :-) I'll suggest: In order to comply with IETF processes and avoid unnecessary delays, document authors and contributors to our discussions in the FOO WG are asked to take pay careful attention to these messages and to reply in a timely fashion. In A.2: "We will weigh this information when we judge the consensus on the call for adoption." The wording is not that clear. It is up to the participants to see whether they are ok to work the specification given the IPR claims. Sam Hartman posted some possible responses in such cases ( http://www.ietf.org/mail-archive/web/oauth/current/msg08992.html ). What we were are looking for here is whether there are any claims. The easy path is to remove the sentence and keep the IPR question for the follow-up question. In A.3: "The authors of draft-ietf-foo-wiffle have asked for a Working Group Last Call. Before issuing the Last Call, we would like to check" I suggest "before issuing the Working Group Last Call" as Last Call is generally considered as what's in the subject line of this message. I'll +1 the draft. Please feel free to ignore the comments to keep matters simple. Regards, -sm </pre> SM 2012-05-23T08:16:45 http://permalink.gmane.org/gmane.ietf.general/51975 <pre>Hi Stephan, thanks for the feedback and sorry about the slow reply. On 4/30/12 11:19 AM, Stephan Wenger wrote: I see your point: one can't realistically be expected to file a disclosure before making a Contribution. Tim and I will discuss together how we'd like to make this clearer. One possibility is to use a less formal method, e.g., providing information about known IPR in the materials to be presented or posting to the relevant discussion list ahead of time (rather than filing a formal disclosure). I think you're right that absence of evidence can't be interpreted as evidence of absence. If Tim agrees, we'll stike that sentence. Your suggestion of "authors and other Contributors" seems right. Agreed. Thanks for those suggestions. We'll look at those sample messages again, but on a first look I think all your points are spot-on. Peter </pre> Peter Saint-Andre 2012-05-22T22:20:44 http://permalink.gmane.org/gmane.ietf.general/51973 <pre> Stephen&gt; The changes in draft-ietf-emu-chbind-15.txt satisfactorily Stephen&gt; address almost all of the comments in my April 13, 2012 Stephen&gt; secdir review. I do have one remaining substantive comment Stephen&gt; on this latest draft and two non-substantive ones. Stephen&gt; Substantive Comment ------------------- Stephen&gt; The last paragraph of section 9.1 points out a security Stephen&gt; problem with implementing channel bindings using EAP tunnel Stephen&gt; methods. If the EAP tunnel method terminates on the Stephen&gt; authenticator, the channel bindings can easily be defeated Stephen&gt; by the authenticator. While that's true, nobody terminates Stephen&gt; the EAP tunnel method on the authenticator today. In the Stephen&gt; EAP model, the authenticator is not trusted so terminating Stephen&gt; the EAP tunnel method on the authenticator is a bad idea Stephen&gt; for many reasons. For example, the authenticator would then Stephen&gt; have the ability to bypass protected result indications and Stephen&gt; to bypass all the cryptographic protections provided by the Stephen&gt; tunnel. Sometimes there is value in having the inner and Stephen&gt; outer methods terminate on different servers but both Stephen&gt; servers must be trusted. The authenticator is not. So Stephen&gt; there is no big security hole here, unless you have already Stephen&gt; opened an enormous security hole. It's ironic that this Stephen&gt; document which attempts to close vulnerabilities caused by Stephen&gt; malicious authenticators ends up subtly suggesting that Stephen&gt; people open a much larger vulnerability! Stephen&gt; I would recommend deleting the end of this paragraph, Stephen&gt; starting with the sentence that starts "Even when Stephen&gt; cryptographic binding".&gt; I disagree very strongly with this proposed change. It's possible that the text is not clear and I'd be happy to work for a round or two to see if we can clarify the text, but ending the paragraph as you propose would defeate the point of text we added after a WG consensus call. I agree with you that authenticators are not trusted. The issue is that you cannot trust attackers to act within a specification. If an attacker can gain benefit from doing something, they may do so. So, if an attacker can create a tunnel terminating at an authenticator and gain advantage from doing so, then they will do so. Remember that we're talking about crypto binding. If crypto binding is relevant for confirming there are no extra servers, then we're in a threat model space where we're trusting the inner method to authenticate the server, not the outer method. You can't say "you should only establish trusted tunnels," because we're hoping that crypto binding will give us that trust. So, the issue here is that once you add channel bindings and the associated changes to the threat model to EAP, an authenticator can gain advantage through convincing a client to trust a tunnel that terminates at an authenticator. That is, an authenticator can mount an attack. Yes, the authenticator needs to convince the peer to trust the extra tunnel. However, as I discuss in draft-hartman-emu-mutual-crypto-binding and in my presentation at last IETF, that's often fairly easy. So, how can we make the text more clear? </pre> Sam Hartman 2012-05-21T21:50:57 http://permalink.gmane.org/gmane.ietf.general/51972 <pre> And to you for following up. Likewise. Thanks for the clarifications. I chatted about this I-D offlist with Sean Turner and he explained that a bunch of folks who are not familiar with the IETF might be coming here to define IODEF extensions, so I now think that an Informational RFC could be useful. As mentioned, I happen to be working on some IODEF extensions that are specific to the XMPP community. Is it expected that I work on the relevant spec in the MILE WG, in the XMPP WG, or (as I'm doing right now) at the XMPP Standards Foundation? IMHO, doing this work at the XSF makes the most sense because that's where most of the XMPP developers and operators are active. Seeking a sanity check on this work from the MILE WG does seem reasonable, though (once it's ready for review). IMHO, it seems fine to repeat some of that information, as long as you say that the styleguide rules on general matters of RFC authorship. But your AD might know better. ;-) Peter </pre> Peter Saint-Andre 2012-05-21T15:16:41 Search the mailing list at Gmane query http://search.gmane.org/?group=$group=gmane.ietf.general