http://permalink.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/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 </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 resu</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 http://permalink.gmane.org/gmane.ietf.general/51970 <pre> On May 20, 2012, at 11:36 PM, Marc Petit-Huguenin wrote: la lojban satci .ije la lojban na'e nolmle </pre> Yoav Nir 2012-05-20T22:44:25 http://permalink.gmane.org/gmane.ietf.general/51969 <pre>-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 05/20/2012 12:41 PM, Stephane Bortzmeyer wrote: Su'i pa - -- Marc Petit-Huguenin Personal email: marc&lt; at &gt;petit-huguenin.org Professional email: petithug&lt; at &gt;acm.org Blog: http://blog.marc.petit-huguenin.org -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQIcBAEBCAAGBQJPuVXnAAoJECnERZXWan7E4tEP/RmoX1ga8rxp9PdWgBKImiwu HYrypdCvVndRLwrdnNiEBU0hx83gdOdFn6MhOImmVmY7LMwuL0sofkCI9Y4ZnN4G X6yBHqji1aTbGHbliQK5p44pebqX7NKxtQa4msFCl+8BNQ6bezHmwK9CKyN7QMSc zXaA8Y7wo0mlmgbPfCF93/cR3yXUEdKLOi3wZDwEP/jFX632cUS6n2am9mL/HZA9 qm8td0F0xRb/+oV0MMfzEb+MDDi2TptKDNDSXIqyCMsZ1qMyVUwVOCTUnJ7waxoX dmHTZ5HhPFlOTY+aPYwSDzmqDfZa4jd1z6vUR5hZ2uLxLX6LD4/Bjc4W2E1yPWG+ BAZxGbwNchWwXlb1xzuCch4CVIXtuN7nGe3EPvNDLiWM50vSuFyOROsIaV1MgW0W EVA0Vk68CvDu9O+OjCg83eDkFHi/OHloTqz0tx71xD5vtnPxrZWvR4hdIe/ffs4e i/PKY2c0PItN9vA4hskDkoJoXQ1Drg91t9eoh4qJBulm4+YZ+Xv6SrmmnYJtzTzk ezHeCzatkGB9FvXoyBkNnbZPLFDqgHuPDIdcV067x+r2Yqdywb04ECy/30Dy6HfH BI//qYZEO3fbgbLYz7s8NpvuucP43OpsDIkUpp4p7CKss1LTVodi</pre> Marc Petit-Huguenin 2012-05-20T20:36:58 http://permalink.gmane.org/gmane.ietf.general/51968 <pre>On Wed, May 16, 2012 at 11:06:25AM -0400, Simon Perreault &lt;simon.perreault&lt; at &gt;viagenie.ca&gt; wrote a message of 12 lines which said: Nice troll. Let me amend it: we now have languages which were conceived for writing precisely what you mean (not too much ambiguity, not too little). Lojban &lt;http://en.wikipedia.org/wiki/Lojban&gt; is the best known. I do not expect IETF to adopt it for RFCs (despite the imperfections of English) but I regret it. This would give me the push I need to really learn Lojban. </pre> Stephane Bortzmeyer 2012-05-20T19:41:40 http://permalink.gmane.org/gmane.ietf.general/51967 <pre> My personal preference is to use RFC 2119, but if the IESG made that into a rule without community consensus, I think it would be wrong. Yes, it would be sad if the IETF were no longer to allow itself to apply common sense rather than rules. Brian </pre> Brian E Carpenter 2012-05-20T18:00:13 http://permalink.gmane.org/gmane.ietf.general/51966 <pre> --On Sunday, May 20, 2012 07:53 +0100 Brian E Carpenter &lt;brian.e.carpenter&lt; at &gt;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 requi</pre> John C Klensin 2012-05-20T16:29:27 http://permalink.gmane.org/gmane.ietf.general/51965 <pre> Curious, does any "fixes" of 2119, will fix a document or set of documents? automatically, unchanged? It just seems that the docs themselves need the fixing and desires to change meanings in 2119 is to correct past mistakes or perhaps intentional relaxations wanting to be stronger today. Here is one example where a conflict is often raised that "Local Policy" Rules. The Checking Software can choose between A or B. It is RECOMMENDED that C is used. A is not defined, B has 2119 language. However, although it is not written, C is only possible if A is used. B preempts, short-circuits C. A possible correction would based on Implementation vs Deployment, two different readers getting the same understanding: The Implementation MUST offer A and B and C. The Deployment CAN choose between A or B. The Deployment SHOULD use C when the Deployment uses A. I would use a MUST in the last one, but that will change the original RECOMMENDED spec item. </pre> Hector Santos 2012-05-20T14:40:15 http://permalink.gmane.org/gmane.ietf.general/51964 <pre> On 05/20/2012 07:25 AM, Yaakov Stein wrote: If you want a discussion as to whether we should live in Times Roman, that'd be best on the rfc editor list. (Sorry, couldn't resist;-) S. </pre> Stephen Farrell 2012-05-20T10:29:09 http://permalink.gmane.org/gmane.ietf.general/51963 <pre> On Sat, 2012-05-19, Brian E Carpenter wrote: I do not agree that 2119 is "clear" on this topic. I read the beginning of the first paragraph of the Abstract as: Some background motivation: In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. A new proposal: This document defines these words as they should be interpreted in IETF documents. Thus, it is defining a new, unified convention for documenting requirements language. And then the boilerplate shows all of the requirement words in uppercase, obviously convincing a lot of people that the new standard is to use them in uppercase when their meaning is normative. As one example, in section 6 the text reads: Imperatives of the type defined in this memo must be used with care and sparingly. 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</pre> Bill McQuillan 2012-05-20T07:39:46 http://permalink.gmane.org/gmane.ietf.general/51961 <pre>... Just to be clear about the current rules, 2119 makes it clear that upper case keywords are optional ("These words are often capitalized"). Indeed, numerous standards track documents don't use them. Brian </pre> Brian E Carpenter 2012-05-20T06:53:54 http://permalink.gmane.org/gmane.ietf.general/51960 <pre> I was waiting to see if someone was going to bring this up. In Roman law, the way you capitalized something in a document could have significant consequences, for example, incorrect use of Capitis Diminutio could change you from a free person into a slave! OTOH, the Uniform Commercial Code requires certain terms be rendered "conspicuous", which may be accomplished though capitalization, or using bold face, or a larger font, or contrasting color, etc. The intervening 2000 years enabled the UCC to exploit more modern typesetting technologies. But the IETF is still living in Roman times. Y(J)S </pre> Yaakov Stein 2012-05-20T06:25:52 http://permalink.gmane.org/gmane.ietf.general/51959 <pre> yikes! i did not intend that. and i think folk need to look up 'erratum', think trivial bug fix. this would be a change. and i do not have the hubris to change sob's immortal words :) i think the practical problem my text may hit is id-nits and id nit pickers. two friends have warned me that i may have fun getting a draft through the iesg with it, and that i can look forward to silliness. my read of the iesg is that they have been taking a higher road these years. but we'll see. randy </pre> Randy Bush 2012-05-19T21:45:28 http://permalink.gmane.org/gmane.ietf.general/51958 <pre> On 5/16/12 3:59 PM, Barry Leiba wrote: Did you envision THIS much discussion? </pre> Eliot Lear 2012-05-19T20:19:36 http://permalink.gmane.org/gmane.ietf.general/51957 <pre>As a reader of RFCs, I've come to expect that 2119 words are always capitalized, and that when the same words appear in lowercase or mixed case they're not being used in the 2119 sense. This seems to be a de facto standard, even though 2119 doesn't require it. I'm in favor of continuing with this standard since I think most readers of RFCs have grown to expect it, but there doesn't seem to be a need to make any change. Two things I like: - Randy's new suggested boilerplate - Avoiding using 2119-like words in lowercase when other wording would work equally well, at the author's discretion. That seems like a reasonable practice, but trying to define and enforce it would be far too much trouble and have silly unintended consequences. So perhaps if Randy's new suggested boilerplate could be added as an erratum to 2119, clearly labeled an optional suggestion, I think that might be useful. But don't change the rules. 2119 works well as is IMO. -- Cos </pre> Ofer Inbar 2012-05-19T19:39:04 http://permalink.gmane.org/gmane.ietf.general/51956 <pre> +1 This is one of those issues that is best addressed by *awareness*, not by new rules. Grüße, Carsten </pre> Carsten Bormann 2012-05-19T07:28:12 http://permalink.gmane.org/gmane.ietf.general/51955 <pre> the discussion has incited me to change the boiler plate which i will use henceforth The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as described in RFC 2119 [RFC2119] only when they appear in all upper case. They may also appear in lower or mixed case as English words, without any normative meaning. randy </pre> Randy Bush 2012-05-19T06:54:26 http://permalink.gmane.org/gmane.ietf.general/51954 <pre> May I say "+1"? Very seriously - after all that has been said on this thread, I see no reason to change anything. Authors and the RFC Editor can create unambiguous language with a bit of thought. There is an erratum in 2119 ("NOT RECOMMENDED" is not mentioned in the recommended boilerplate) but we know how to deal with that. A strong argument against updating RFC 2119 is the fact that it's one of the most cited RFCs *outside* the RFC series. Several other SDOs commonly cite RFC 2119 and use its terminology. If it was a protocol, we'd be proud of its success, but that makes changing it a source of unintended consequences. Brian </pre> Brian E Carpenter 2012-05-19T06:48:44 http://permalink.gmane.org/gmane.ietf.general/51952 <pre>my wife says the purpose of tourists (we in japan) is to amuse the natives randy </pre> Randy Bush 2012-05-18T22:54:55 Search the mailing list at Gmane query http://search.gmane.org/?group=$group=gmane.ietf.general