Re: Repetitions and consensus
Brian, I repeat, you are right. Your statement might receive even full consensus ;-) Regards, Géza On Tue, Jul 12, 2011 at 4:58 AM, Brian E Carpenter brian.e.carpen...@gmail.com wrote: Hi, We quite often discuss here how to judge rough consensus. In a completely non-IETF context, I came upon a reference to an article published in 2007 with the catchy title Inferring the Popularity of an Opinion From Its Familiarity: A Repetitive Voice Can Sound Like a Chorus. Here's an extract from the abstract: ...people do not always correctly estimate the distribution of opinions within their group. One important mechanism underlying such misjudgments is people’s tendency to infer that a familiar opinion is a prevalent one, even when its familiarity derives solely from the repeated expression of 1 group member. Six experiments demonstrate this effect and show that it holds even when perceivers are consciously aware that the opinions come from 1 speaker. The article by Weaver et al was in the Journal of Personality and Social Psychology, 2007, Vol. 92, No. 5, 821–833. I found it at http://www.apa.org/pubs/journals/releases/psp-925821.pdf -- Regards Brian Carpenter ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [hybi] Last Call: draft-ietf-hybi-thewebsocketprotocol-10.txt (The WebSocket protocol) to Proposed Standard
On 2011-07-11 16:02, The IESG wrote: .. I believe Section 11 (IANA Considerations) should be grouped to into URI scheme registrations, HTTP header field registrations, and new registries. Best regards, Julian ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [hybi] Last Call: draft-ietf-hybi-thewebsocketprotocol-10.txt (The WebSocket protocol) to Proposed Standard
On 2011-07-12 06:40, Mykyta Yevstifeyev wrote: ... Throughout the document: _This section is non-normative._ are quite unusual. Such statements occur at the beginning of Introduction, which is meant to be nob-normative a priori, its subsections, and Section 4.7, Examples. These sections, IMO, doesn't need to be additionally marked as non-normative. ... +1 Section 3. I propose to rewrite the first paragraph as follows: This specification defines two URI schemes for WebSocket protocol - 'ws' and 'wss'. Their syntax is defined below using ABNF [RFC5234] in thews-uri andwss-uri, respectively: ws-uri = ws: // host [ : port ] path-abempty [ ? query ] wss-uri = wss: // host [ : port ] path-abempty [ ? query ] where thehost,port,path-abempty andquery rules are defined in RFC 3986 [RFC3986]. Rationale: (1) The first paragraph gets clearer. (2) ABNF is changed not ot use pros-vals (RFC 5234) (3) s/path/path-abempty/ to directly import it from RFC 3986 (4) Several editorial issues fixed. -10 Granted, it doesn't use prose values anymore, but then it get's incomplete. I believe putting references to ABNF productions from other specs into prose values is absolutely the right thing to do (as opposed to just mention them in prose). Section 5.2.2, bullet 3, sub-bullet 4. When defining the ABNF for a header, the header name should be included in it as well. So the first line should be: ... Why? Section 9.1: extension-token = registered-token / private-use-token If you want RFC 2616 ABNF, this should be changed to: ... yes. extension-token = registered-token | private-use-token Ibid: Sec-WebSocket-Extensions: bar; baz=2 is exactly equivalent to Sec-WebSocket-Extensions: foo, bar; baz=2 These two examples don't match the aforementioned ABNF; the space before baz=2 should be removed. ... They do, as the RFC 2616 ABNF allows implied Linear Whitespace. That being said, it might be a good idea to revisit the choice of syntax, or at least to clarify the LWS situation. In ABNF terms using the terminals from the URI specifications: [RFC5234] [RFC3986] ws : hier-part [ ? query ] This isn't what you described in Section 3. hier-part includes the userinfo part, which shouldn't be present in WebSocket URIs. This ABNF should be fixed to match one in Section 3. ...or removed. Why are there two? Thepath [RFC3986] andquery components form the resource name sent to the server to identify the kind of service desired. Other components have the meanings described in RFC3986. If you adopt my proposal to Section 3, this should be fixed in the same way. References. RFC References here mean (from RFC 4395): References. Include full citations for all referenced documents. Registration templates for provisional registration may be included in an Internet Draft; when the documents expire or are approved for publication as an RFC, the registration will be updated. So this field should refer to Section 14 of the draft. Section 14 of this document. Section 11.2: the same applies. Section 11.12: Version Number | Reference -++-+- | 0 + draft-ietf-hybi-thewebsocketprotocol-00 | -++-+- [ . . . ] -++-+- | 9 + draft-ietf-hybi-thewebsocketprotocol-09 | -++-+- ... This is indeed fishy and I would be really surprised if IESG and RFC Editor let this pass. If 0..9 can't be reassigned then let's just state they are reserved. ... Best regards, Julian ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [hybi] Last Call: draft-ietf-hybi-thewebsocketprotocol-10.txt (The WebSocket protocol) to Proposed Standard
On 2011-07-12 09:48, Iñaki Baz Castillo wrote: 2011/7/12 Mykyta Yevstifeyevevniki...@gmail.com: Sec-WebSocket-Extensions: bar; baz=2 is exactly equivalent to Sec-WebSocket-Extensions: foo, bar; baz=2 These two examples don't match the aforementioned ABNF; the space before baz=2 should be removed. Hi, are you sure of that? In SIP protocol (which inherits from HTTP grammar) a header parameter (;foo=lalala) can contain spaces anywhere (before/after the ;, before/after the =). So something like: Sec-WebSocket-Extensions: foo , bar ; baz = 2 is valid. However it's not clear for me wheter in this example baz=2 is a header param or a param just for the value bar. In the last case it would mean a specific header syntax, so spaces could be not allowed. Could you please point to the ABNF grammar you meant? According to http://tools.ietf.org/html/draft-ietf-hybi-thewebsocketprotocol-10#section-9.1 it's a parameter of bar. That being said, I'm not happy with extension-param = token [ = token ] In HTTP header fields, parameters usually support both token and quoted-string form. Making this special means that existing header field parser code can't be easily re-used. Best regards, Julian ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [hybi] Last Call: draft-ietf-hybi-thewebsocketprotocol-10.txt (The WebSocket protocol) to Proposed Standard
On 2011-07-12 10:23, Iñaki Baz Castillo wrote: 2011/7/12 Julian Reschkejulian.resc...@gmx.de: That being said, I'm not happy with extension-param = token [ = token ] In HTTP header fields, parameters usually support both token and quoted-string form. Right. Making this special means that existing header field parser code can't be easily re-used. Well, not exaclty as any parser supporting tokens and quoted-strings would also parse just tokens :) But if they *are* re-used, those recipients will accept quoted-strings as well (thus accepting invalid header fields). This could be harmless, or it could cause them to be used in practice, forcing other recipients to accept them as well. ... Best regards, Julian ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [hybi] Last Call: draft-ietf-hybi-thewebsocketprotocol-10.txt (The WebSocket protocol) to Proposed Standard
12.07.2011 9:56, Julian Reschke wrote: On 2011-07-11 16:02, The IESG wrote: .. I believe Section 11 (IANA Considerations) should be grouped to into URI scheme registrations, HTTP header field registrations, and new registries. This is quite reasonable. +1. Mykyta Best regards, Julian ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [hybi] Last Call: draft-ietf-hybi-thewebsocketprotocol-10.txt (The WebSocket protocol) to Proposed Standard
12.07.2011 9:59, Julian Reschke wrote: On 2011-07-12 06:40, Mykyta Yevstifeyev wrote: [ . . . ] Section 3. I propose to rewrite the first paragraph as follows: This specification defines two URI schemes for WebSocket protocol - 'ws' and 'wss'. Their syntax is defined below using ABNF [RFC5234] in thews-uri andwss-uri, respectively: ws-uri = ws: // host [ : port ] path-abempty [ ? query ] wss-uri = wss: // host [ : port ] path-abempty [ ? query ] where thehost,port,path-abempty andquery rules are defined in RFC 3986 [RFC3986]. Rationale: (1) The first paragraph gets clearer. (2) ABNF is changed not ot use pros-vals (RFC 5234) (3) s/path/path-abempty/ to directly import it from RFC 3986 (4) Several editorial issues fixed. -10 Granted, it doesn't use prose values anymore, but then it get's incomplete. I believe putting references to ABNF productions from other specs into prose values is absolutely the right thing to do (as opposed to just mention them in prose). I don't have any string position in the way of importing the productions from other documents. However, what is above is what I like more. However, what we can see, eg. in http://tools.ietf.org/html/rfc5538#appendix-A can be fine as well. Section 5.2.2, bullet 3, sub-bullet 4. When defining the ABNF for a header, the header name should be included in it as well. So the first line should be: ... Why? There is the following formulation: The 'Foo' headers takes the form of foo-header ABNF rules below: foo-header = *(APHA/DIGIT) will result in the message headers like: Upgrade: TLS/1.2 Connection: Upgrade gfr134 and gfr134 will be the 'Foo' header. foo-header = Foo: *(APHA/DIGIT) will result in valid: Upgrade: TLS/1.2 Connection: Upgrade Foo: gfr134 See also eg. RFC 3282, RFC 2616. [ . . . ] That being said, it might be a good idea to revisit the choice of syntax, or at least to clarify the LWS situation. The document may reference the httpbis-p1 where the n#mrule extension will be described for valid ABNF. See http://tools.ietf.org/html/draft-ietf-httpbis-p1-messaging-15#section-1.2.1 [ . . . ] Section 11.2: the same applies. Section 11.12: Version Number | Reference -++-+- | 0 + draft-ietf-hybi-thewebsocketprotocol-00 | -++-+- [ . . . ] -++-+- | 9 + draft-ietf-hybi-thewebsocketprotocol-09 | -++-+- ... This is indeed fishy and I would be really surprised if IESG and RFC Editor let this pass. If 0..9 can't be reassigned then let's just state they are reserved. I believe there is no problems to make the 0..9 spare, except 1, for this version of WS. Mykyta Yevstifeyev ... Best regards, Julian ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [hybi] Last Call: draft-ietf-hybi-thewebsocketprotocol-10.txt (The WebSocket protocol) to Proposed Standard
On 2011-07-12 11:09, Mykyta Yevstifeyev wrote: ... Section 5.2.2, bullet 3, sub-bullet 4. When defining the ABNF for a header, the header name should be included in it as well. So the first line should be: ... Why? There is the following formulation: The 'Foo' headers takes the form of foo-header ABNF rules below: foo-header = *(APHA/DIGIT) It should say: The 'Foo' header field's value takes the form... will result in the message headers like: Upgrade: TLS/1.2 Connection: Upgrade gfr134 and gfr134 will be the 'Foo' header. foo-header = Foo: *(APHA/DIGIT) will result in valid: Upgrade: TLS/1.2 Connection: Upgrade Foo: gfr134 See also eg. RFC 3282, RFC 2616. Have a look at the HTTPbis drafts. [ . . . ] That being said, it might be a good idea to revisit the choice of syntax, or at least to clarify the LWS situation. The document may reference the httpbis-p1 where the n#mrule extension will be described for valid ABNF. See http://tools.ietf.org/html/draft-ietf-httpbis-p1-messaging-15#section-1.2.1 It could, but my guess is that HyBi doesn't want to wait for HTTPbis. ... Best regards, Julian ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [hybi] Last Call: draft-ietf-hybi-thewebsocketprotocol-10.txt (The WebSocket protocol) to Proposed Standard
12.07.2011 10:48, Iñaki Baz Castillo wrote: 2011/7/12 Mykyta Yevstifeyevevniki...@gmail.com: Sec-WebSocket-Extensions: bar; baz=2 is exactly equivalent to Sec-WebSocket-Extensions: foo, bar; baz=2 These two examples don't match the aforementioned ABNF; the space before baz=2 should be removed. Hi, are you sure of that? In SIP protocol (which inherits from HTTP grammar) a header parameter (;foo=lalala) can contain spaces anywhere (before/after the ;, before/after the =). So something like: Sec-WebSocket-Extensions: foo , bar ; baz = 2 is valid. No, its' everything OK with this issue. LWS is allowed between extension productions in the header, but not between the parts of this productions: extension-tokens and extension-params. See http://tools.ietf.org/html/rfc2616#section-2.1 and http://tools.ietf.org/html/rfc2616#section-2.1. However it's not clear for me wheter in this example baz=2 is a header param or a param just for the value bar. In the last case it would mean a specific header syntax, so spaces could be not allowed. Could you please point to the ABNF grammar you meant? This was meant to be the parameter for the bar, as far as I understand. Mykyta Thanks. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [hybi] Last Call: draft-ietf-hybi-thewebsocketprotocol-10.txt (The WebSocket protocol) to Proposed Standard
12.07.2011 12:14, Julian Reschke wrote: On 2011-07-12 11:09, Mykyta Yevstifeyev wrote: ... Section 5.2.2, bullet 3, sub-bullet 4. When defining the ABNF for a header, the header name should be included in it as well. So the first line should be: ... Why? There is the following formulation: The 'Foo' headers takes the form of foo-header ABNF rules below: foo-header = *(APHA/DIGIT) It should say: The 'Foo' header field's value takes the form... This will eliminate the problem. Currently we have: The ABNF of this header is defined as follows: not its entity. will result in the message headers like: Upgrade: TLS/1.2 Connection: Upgrade gfr134 and gfr134 will be the 'Foo' header. foo-header = Foo: *(APHA/DIGIT) will result in valid: Upgrade: TLS/1.2 Connection: Upgrade Foo: gfr134 See also eg. RFC 3282, RFC 2616. Have a look at the HTTPbis drafts. They should also be clear about whether they mean the header field or the header field's entity. [ . . . ] That being said, it might be a good idea to revisit the choice of syntax, or at least to clarify the LWS situation. The document may reference the httpbis-p1 where the n#mrule extension will be described for valid ABNF. See http://tools.ietf.org/html/draft-ietf-httpbis-p1-messaging-15#section-1.2.1 It could, but my guess is that HyBi doesn't want to wait for HTTPbis. That's up to them. Mykyta ... Best regards, Julian ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [Gen-art] Gen-ART LC Review of draft-ietf-dnsext-rfc2672bis-dname-22
Sorry for the late response--I just got back from vacation. Yes, I was referring to the title and also the last paragraph of section 1. Your proposed change, along with something similar in section 1, would IMHO resolve the issue. Thanks! Ben. On Jun 27, 2011, at 9:15 AM, Scott Rose wrote: Ben, Are you referring to the title (Update to the DNAME...)? Then yes, that could be confusing - that was missed in the revision. Would trimming the title to the shorter DNAME Redirection in the DNS fix that? It's the simplest fix. Scott On Jun 24, 2011, at 6:18 PM, Ben Campbell wrote: Thanks! This version resolves all of my comments, with the exception that while the text now says the draft updates DNAME, the header still says it obsoletes RFC 2672. Is that the intent? Thanks! Ben. On Jun 24, 2011, at 10:16 AM, Scott Rose wrote: FYI: A new version (-23) of the dname-bis draft has been posted with the two sections re-added (resolver algorithm and examples of DNAME use). I haven't heard any comments from the DNSEXT WG on it, but it was only just posted. Scott On Jun 8, 2011, at 5:50 PM, Ben Campbell wrote: Thanks for the response! Comments below, eliding the bits I think need no further comment. On Jun 8, 2011, at 12:11 PM, Scott Rose wrote: Perhaps the document should only update RFC 2672 instead of obsoleting it? That would resolve my concern, if it fits with the intent of the work group. As for the nits: On Tue, Jun 7, 2011 at 6:35 PM, Ben Campbell b...@nostrum.com wrote: [...] Yes, will correct. -- ..., 7th paragraph: ...replaced with the word DELETED. Won't that just leave the word deleted hanging on page without explanation? Wouldn't it be better to just simply delete it? Maybe, but I think the logic was that if there is some text there (just something), it can be cleanly referenced (i.e. DELETED [RFC])if someone is making a revised version of the RFC for some purpose. Purely deleting it accomplishes the task, but this provides a good hook for a paper trail. Okay. On reflection, it's not like we really render the updates the old RFC documents. Scott ___ Gen-art mailing list gen-...@ietf.org https://www.ietf.org/mailman/listinfo/gen-art === Scott Rose NIST scott.r...@nist.gov +1 301-975-8439 Google Voice: +1 571-249-3671 http://www.dnsops.gov/ === === Scott Rose NIST scott.r...@nist.gov +1 301-975-8439 Google Voice: +1 571-249-3671 http://www.dnsops.gov/ === ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-ietf-hybi-thewebsocketprotocol-10.txt (The WebSocket protocol) to Proposed Standard
For the benefit of the wider ietf@ietf.org audience, I'd like to summaries an unresolved issue from the Hybi WG with the websocket draft protocol. Draft 10 if this document contains the deflate-stream extension in section 9.2.1 This extension does not comply with any of the anticipated uses of extensions listed in section 4.8, at best this makes it a poor exemplar of an extension, as worst it makes it an unexpected total change to the framing seen on the wire. Because the extension changes the framing of bytes on the wire, this will force all tools and intermediaries that wish to observe the frame boundaries, to implement this extension, making it non optional. For example, intermediaries that do not implement this extension will be unable to buffer/forward on frame boundaries. Because default-stream is applied after the masking of client sent frames, it is highly inefficient, with little or no compression being achieved due to the random masking keys and the masking of any regular patterns in the payload. The intent of masking was to prevent bytes sent on the wire being being controlled by an attacker. However, a security concern has been raised that the predictability of the deflate algorithm to convert byte patterns into shorter bit sequences may allow a payload to be crafted that would predictably produce bytes on the wire regardless of the masking applied. A reasonable alternative has been proposed that does not apply deflation to the stream. Rather it applies it only to the application data before masking, while keeping the compression dictionary between frames. This alternative proposal is a good exemplar extension (in line with 4.8), provides efficient compression and does not suffer from the security concern raised. Since draft -7, there have been many voices in the WG calling for the withdrawal of deflate-stream and nobody has spoken in favour of the retention of deflate-stream on any grounds other than it is already implemented/deployed. I fail to understand why a non essential feature that was put into draft-3 without discussion or consensus, that has demonstrable deficiencies, security concerns and vocal opponents has been left in the draft all the way to final call? regards Greg Wilkins ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Nomcom 2011-2012: Final List of Volunteers
I would like to thank everyone who volunteered to serve on this year's Nominating Committee. As specified in my earlier timeline announcement, the solicitation for volunteers is now closed. All volunteers have been checked by the secretariat to verify their eligibility to serve, and I have notified them of the same. Below is the list of 120 people who have volunteered and are eligible to serve. If your name is not on the list and you think it should be or if it is and it shouldn't be, please contact me as soon as possible. Any challenges as to the eligibility of these people to serve on the Nomcom should be received by 23:59 EDT on Thursday, July 14th 2011. If there are no challenges, the process will proceed with this list. Assuming any raised challenges have been resolved, the resulting list will then be published before any of the random seeds (as previously published) have selected their numbers. If there are unresolved issues, then a notice will be sent, and new seeds announced, before the seeds have selected values. 1 Jaap Akkerhuis, NLnet labs 2 Alia Atlas, Juniper Networks 3 Ignas Bagdonas, Cisco Systems 4 Gabor Bajko, Nokia 5 Fred Baker, Cisco Systems 6 Richard Barnes, BBN Technologies 7 Ray Bellis, Nominet UK 8 Lou Berger, LabN Consulting 9 Deborah Brungard, ATT 10 Randy Bush, Internet Initiative Japan 11 Zhen Cao, China Mobile 12 Samita Chakrabarti, Ericsson 13 Gang Chen, China Mobile 14 Mach Chen, Huawei Technologies Co. 15 Subir Das, Telcordia Technologies Inc 16 Wojciech Dec, Cisco 17 Hui Deng, China Mobile 18 Thomas D. Nadeau, CA Technologies 19 Jie Dong, Huawei Technologies 20 Lilla Dovner, Ericsson 21 Keith Drage, Alcatel-Lucent 22 Donald Eastlake, Huawei 23 Toerless Eckert, Cisco Systems 24 John E Drake, Juniper Networks 25 Byron Ellacott, APNIC 26 Mehmet Ersue, Nokia Siemens Networks 27 Hannu Flinck, NSN 28 Wesley George, Time Warner Cable 29 Fernando Gont, UTN/FRH 30 Eric Gray, Ericsson 31 Chris Griffiths, Comcast 32 Yingjie Gu, Huawei Technologies 33 Wassim Haddad, Ericsson 34 Michael Hamilton, BreakingPoint Systems 35 Stephen Hanna, Juniper Networks 36 Tony Hansen, ATT 37 Sam Hartman, Painless Security 38 Jia He, Huawei Technologies Co. 39 Thomas Herbst, Silver Spring Networks 40 Christer Holmberg, LM Ericsson 41 Fangwei Hu, ZTE Corporation 42 John Jason Brzozowski, Comcast 43 Cullen Jennings, Cisco 44 Sheng Jiang, Huawei Technologies Co. Ltd. 45 Benno J. Overeinder, NLnet Labs 46 Hadriel Kaplan, Acme Packet 47 Stephen Kent, BBN Technologies 48 Ari Keranen, Ericsson 49 Sohel Khan, Comcast 50 Bhumip Khasnabish, ZTE USA 51 Krisztian Kiss, Nokia 52 Peter Koch, DENIC eG 53 Jouni Korhonen, Nokia Siemens Networks 54 Mirja K�hlewind, University of Stuttgart 55 Matt Lepinski, BBN Technologies 56 Marco Liebsch, NEC 57 Hongyu Li, Huawei Technologies 58 Dapeng Liu, China Mobile 59 Guoman liu, ZTE 60 Yiu L. Lee, Comcast 61 Andrew Malis, Verizon 62 Terry Manderson, ICANN 63 Scott Mansfield, Ericsson 64 Luca Martini, Cisco 65 Andrew McLachlan, Cisco 66 David Meyer, Cisco Systems/University of Oregon 67 George Michaelson, APNIC 68 Karen O'Donoghue, Internet Society 69 B�rje Ohlman, Ericsson 70 Dimitri Papadimitriou, Alcatel-Lucent 71 Keyur Patel, Cisco Systems 72 Simon Pietro Romano, Meetecho/University of Napoli 73 Leon Portman, NICE Systems 74 Robert Raszuk, Cisco 75 Adam Roach, Tekelec 76 Allyn Romanow, Cisco Systems 77 Joseph Salowey, Cisco Systems 78 Behcet Sarikaya, Huawei USA 79 Teemu Savolainen, Nokia 80 Christian Schmidt, Nokia Siemens Networks 81 Shida Schubert, NTT 82 John Scudder, Juniper Networks 83 Karen Seo, BBN Technologies 84 Rifaat Shekh-Yusef, Avaya 85 Sean Shen, CNNIC 86 Jonne Soininen, Renesas Mobile 87 Haibin Song, Huawei Technologies 88 Ning So, Verizon Inc./University of Texas at Dallas 89 Nurit Sprecher, Nokia Siemens Networks 90 Ond#345;ej Sur�, CZ.NIC 91 George Swallow, Cisco Systems 92 Pascal Thubert, Cisco 93 Mark Townsley, Cisco Systems 94 Brian Trammell, ETH Z�rich 95 Ole Troan, Cisco 96 Tina Tsou, FutureWei Technologies 97 Javier Ubillos, Swedish Institute of Computer Science 98 Gunter Van de Velde, Cisco 99 Olivier Vautrin, Juniper Networks 100 Simo Veikkolainen, Nokia 101 Stig Venaas, Cisco 102 Bill VerSteeg, Cisco 103 Samuel Weiler, Cobham 104 Jason Weil, Time Warner Cable 105 Yaacov Weingarten, Nokia Siemens Networks 106 Stephan Wenger, Bidyo 107 Magnus Westerlund, Ericsson 108 IJsbrand Wijnands, Cisco 109 Qin Wu, Huawei
Re: [hybi] Last Call: draft-ietf-hybi-thewebsocketprotocol-10.txt (The WebSocket protocol) to Proposed Standard
2011/7/12 Mykyta Yevstifeyev evniki...@gmail.com: Sec-WebSocket-Extensions: bar; baz=2 is exactly equivalent to Sec-WebSocket-Extensions: foo, bar; baz=2 These two examples don't match the aforementioned ABNF; the space before baz=2 should be removed. Hi, are you sure of that? In SIP protocol (which inherits from HTTP grammar) a header parameter (;foo=lalala) can contain spaces anywhere (before/after the ;, before/after the =). So something like: Sec-WebSocket-Extensions: foo , bar ; baz = 2 is valid. However it's not clear for me wheter in this example baz=2 is a header param or a param just for the value bar. In the last case it would mean a specific header syntax, so spaces could be not allowed. Could you please point to the ABNF grammar you meant? Thanks. -- Iñaki Baz Castillo i...@aliax.net ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [hybi] Last Call: draft-ietf-hybi-thewebsocketprotocol-10.txt (The WebSocket protocol) to Proposed Standard
2011/7/12 Julian Reschke julian.resc...@gmx.de: That being said, I'm not happy with extension-param = token [ = token ] In HTTP header fields, parameters usually support both token and quoted-string form. Right. Making this special means that existing header field parser code can't be easily re-used. Well, not exaclty as any parser supporting tokens and quoted-strings would also parse just tokens :) However I agree that making new/custom grammar for a simple header makes no sense. -- Iñaki Baz Castillo i...@aliax.net ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [hybi] Last Call: draft-ietf-hybi-thewebsocketprotocol-10.txt (The WebSocket protocol) to Proposed Standard: request for max frame size
Hi, Recently, I posted [1] that websocket protocol should include an indication about max frame size that is willing to accept the connecting peer. Many pointed this is not an issue because you could use a stream oriented API (like TCP send/recv and others), but that only bypasses the problem (in some cases) not solves it. Websocket protocol is frame based and every frame based protocol designed until now has/need such feature or similar. Even TCP, for those that proposes to use a stream oriented API as a solution, includes a more complex mechanism than a simple max frame size (window based ack), so each party can control/inform the sender. This is critical. A good example for this would be the next. Let suppose you have a constrained memory device (either because it is small or because it accepts a large amount of connections). On that device you deploy a websocket app that only accepts small messages ( 512 bytes, let's say). In this context, you can hard code at your web app (javascript) that must not send messages larger than this size (so you control websocket payload size) and in the case you need to, you must split them properly. However, even with this mechanism, you have no warranty that the browser or an intermediary will join those messages into a single frame, causing your device to receive a bigger message/frame than expected. Assuming this I think we would require either to include a Max-Frame-Size indication (or a really poor solution: to explicitly state on the draft that frames must not be coalesced by intermediaries or browsers). Regards, [1] http://www.ietf.org/mail-archive/web/hybi/current/msg07641.html -- Francis Brosnan Blázquez francis.bros...@aspl.es ASPL 91 134 14 22 - 91 134 14 45 - 91 116 07 57 AVISO LEGAL Este mensaje se dirige exclusivamente a su destinatario. Los datos incluidos en el presente correo son confidenciales y sometidos a secreto profesional, se prohíbe divulgarlos, en virtud de las leyes vigentes. Si usted no lo es y lo ha recibido por error o tiene conocimiento del mismo por cualquier motivo, le rogamos que nos lo comunique por este medio y proceda a destruirlo o borrarlo. En virtud de lo dispuesto en la Ley Orgánica 15/1999, de 13 de diciembre, de Protección de Datos de Carácter Personal, le informamos de que sus datos de carácter personal, recogidos de fuentes accesibles al público o datos que usted nos ha facilitado previamente, proceden de bases de datos propiedad de Advanced Software Production Line, S.L. (ASPL). No obstante, usted puede ejercitar sus derechos de acceso, rectificación, cancelación y oposición dispuestos en la mencionada Ley Orgánica, notificándolo por escrito a: ASPL - Protección Datos, C/Antonio Suárez 10 A-102, 28802, Alcalá de Henares (Madrid). ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-yevstifeyev-ion-report-06.txt (Report on the Experiment with IETF Operational Notes (IONs)) to Informational RFC
Hello, As Russ agreed to sponsor this document on I-D submission cut-off date, I did make only some minor changed proposed by him during AD evaluation. However I thought the document would be incomplete without analysis, so after LC I propose to add the following sub-section in the draft: 3.4. Analysis and Results IONs were intended to serve as a means to document issues related to procedures used by IETF or other parties, but to be more stable as a simple web page and to have a more lightweight procedures for approval than Best Current Practice (BCP) or other sort of RFC. Even though such middle-ground approach might be quite useful, it also brings a number of complexities and negative effects, which are described below. First of all, IONs were mainly scoped to IETF procedural questions. A number of IONs were published defining procedures used by IETF community, such as ion-ad-sponsoring. However, it should be noted that the formal procedure of IONs approval, laid out in RFC 4693 [RFC4693] did not imply community involvement, unlike one for BCP or other IETF Stream RFC. Even though RFC 4693 intended IONs to cover issues not sufficient for documenting in BCP, this regulation was often overlooked. This might have resulted in community non- acceptance of such procedures, partial or full, if IONs were adopted on the persistent basis. Moreover, as IONs were lower in the hierarchy of IETF documents that RFCs, published RFCs may override what mentioned in a particular ION (whereas a published RFC may change already established procedures), which might result in them not being sufficiently followed, creating documentation conflicts. Several IONS were published that describe the procedures used by IESG or its members internally, such as ion-discuss-criteria or ion-tsv- alt-cc. Such material is obviously more appropriate for publication as IESG Statements, which are also meant to be quite stable when published and are approved at IESG's discretion. A number of IONs were published covering different IAOC issues. Such IONs included ion-execd-tasks and ion-subpoena. However, even though IAOC works tightly with IETF, they have an ability to publish such material on their site - http://iaoc.ietf.org/. A one ION - ion-procdocs - was a reference guide to the IWTF Process documents. An other ION - ion-2026-practice - provided the criticism and operational experience on RFC 2026 [RFC2026]. Both this documents are fine as web pages, since the material contained in it might change quickly and often. ion-ion-format and ion-ion-store were published for the purpose of the IONs series itself and were discarded upon experiment closure. They are not analyzed here. The aforementioned facts claim that IONs were less useful than the equivalent information published in other way, and should be abandoned, as proposed by Section 4 of RFC 4693 [RFC4693]. In order not to request the 2nd LC after this text is included, I'd like to seek community feedback on it during this Last Call. Thanks, Mykyta Yevstifeyev 12.07.2011 17:39, The IESG wrote: The IESG has received a request from an individual submitter to consider the following document: - 'Report on the Experiment with IETF Operational Notes (IONs)' draft-yevstifeyev-ion-report-06.txt as an Informational RFC [ . . . ] ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Second Last Call: draft-hammer-hostmeta-16.txt (Web Host Metadata) to Proposed Standard -- feedback
On 6/21/11 11:08 PM, Mark Nottingham wrote: Generally, it's hard for me to be enthusiastic about this proposal, for a few reasons. That doesn't mean it shouldn't be published, but I do question the need for it to be Standards Track as a general mechanism. How about publishing it on the standards track but not as a general mechanism (i.e., why not clarify when it is and is not appropriate)? Clearly, both service providers (Google, Yahoo, etc.) and spec authors (draft-hardjono-oauth-dynreg-00, draft-hardjono-oauth-umacore-00) have found hostmeta somewhat useful in certain contexts. RFC 2026 says: A Proposed Standard specification is generally stable, has resolved known design choices, is believed to be well-understood, has received significant community review, and appears to enjoy enough community interest to be considered valuable. and: Usually, neither implementation nor operational experience is required for the designation of a specification as a Proposed Standard. However, such experience is highly desirable, and will usually represent a strong argument in favor of a Proposed Standard designation. The spec seems to be stable at this point, it's received significant review, people seem to understand what it does and how it works, it's had both implementation and operational experience, and it appears to enjoy enough community interest to be considered valuable in certain contexts. I also think it has resolved the design choices and solved the requirements that it set out to solve, although you might be right that it doesn't solve all of the problems that a more generic metadata framework would need to solve. As a result, it seems like a fine candidate for Proposed Standard, i.e., an entry-level document on the standards track that might be modified or even retracted based on further experience. Mostly, it's because I hasn't really seen much discussion of it as a general component of the Web / Internet architecture; AFAICT all of the interest in it and discussion of it has happened in more specialised / vertical places. Again, perhaps we need to clarify that it is not necessarily a general component of the web architecture, although it can be used to solve more specific problems. The issues below are my concerns; they're not insurmountable, but I would have expected to see some discussion of them to date on lists like this one and/or the TAG list for something that's to be an Internet Standard. * XRD -- XRD is an OASIS spec that's used by OpenID and OAuth. Maybe I'm just scarred by WS-*, but it seems very over-engineered for what it does. I understand that the communities had reasons for using it to leverage an existing user base for their specific user cases, but I don't see any reason to generalise such a beast into a generic mechanism. As discussed in responses to your message, XRD seems to have been an appropriate tool for the job in this case. Whether XRD, too, is really a general component of the web architecture is another question. * Precedence -- In my experience one of the most difficult parts of a metadata framework like this is specifying the combination of metadata from multiple sources in a way that's usable, complete and clear. Hostmeta only briefly mentions precedence rules in the introduction. That could be something to work on if and when folks try to advance this technology to the next maturity level (currently Draft Standard). * Scope of hosts -- The document doesn't crisply define what a host is. This seems at least somewhat well-defined: a host is not a single resource but the entity controlling the collection of resources identified by Uniform Resource Identifiers (URI) with a common URI host [RFC3986]. That is, it references Section 3.2.2 of RFC 3986, which defines host with some precision (albeit perhaps not crisply). * Context of metadata -- I've become convinced that the most successful uses of .well-known URIs are those that have commonality of use; i.e., it makes sense to define a .well-known URI when most of the data returned is applicable to a particular use case or set of use cases. This is why robots.txt works well, as do most other currently-deployed examples of well-known URIs. Defining a bucket for potentially random, unassociated metadata in a single URI is, IMO, asking for trouble; if it is successful, it could cause administrative issues on the server (as potentially many parties will need control of a single file, for different uses -- tricky when ordering is important for precedence), and if the file gets big, it will cause performance issues for some use cases. It would be helpful to hear from folks who have deployed hostmeta to hear if they have run into any operational issues of the kind you describe here. * Chattiness -- the basic model for resource-specfic metadata in hostmeta requires at least two requests; one to get the hostmeta document, and one to
Re: Second Last Call: draft-hammer-hostmeta-16.txt (Web Host
Peter Saint-Andre wrote: On 6/21/11 11:08 PM, Mark Nottingham wrote: Generally, it's hard for me to be enthusiastic about this proposal, for a few reasons. That doesn't mean it shouldn't be published, but I do question the need for it to be Standards Track as a general mechanism. How about publishing it on the standards track but not as a general mechanism (i.e., why not clarify when it is and is not appropriate)? How about publishing as Informational? RFC 2026 says: 4. THE INTERNET STANDARDS TRACK Specifications that are intended to become Internet Standards evolve through a set of maturity levels known as the standards track. These maturity levels -- Proposed Standard, Draft Standard, and Standard -- are defined and discussed in section 4.1. If there is no strong consensus and commitment to work the document along the standards track up to full standard, then it shouldn't be on the standards track at all. For documents where the only purpose of publishing it is only to obtain an rfc number for it, but otherwise just describe this is how others have solved a particular problem before and let vendors and implementors wiggle out interop, then Informational is quite appropriate. -Martin ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Confidentiality notices on email messages
I am increasingly seeing IETF participants posting messages to IETF mailing lists, sending messages to chairs and ADs, and so on, where their messages include confidentiality/security/legal notices at the bottom. You know the ones; here are excerpts from two recent examples: Information Security Notice: The information contained in this mail is solely the property of the sender's organization. This mail communication is confidential. Recipients named above are obligated to maintain secrecy and are not permitted to disclose the contents of this communication with others. CONFIDENTIALITY NOTICE The information contained in this e-mail and any attachments is CONFIDENTIAL and is intended only for the use of the addressee. Any unauthorized use, disclosure, distribution, dissemination, or copying is strictly prohibited and may be unlawful. If you are not the intended recipient, you are prohibited from any further viewing of the e-mail or any attachments or from making any use of the e-mail or attachments. Those are just the beginnings of them -- they go on, and continue for another paragraph each. I've seen them in Spanish, French, and German, as well as English. Now, apart from being long and annoying, they're in conflict with the IETF's Note Well, which applies to anything posted to IETF mailing lists or sent to anyone in IETF leadership about IETF business: http://www.ietf.org/about/note-well.html I'd also argue that those posting such messages are running afoul of their own organizations' rules by posting confidential messages publicly. Of course, that's nonsense, but, hey, folks, it wouldn't be the first time a company might behave irrationally and discipline someone base on the letter, rather than the intent, of a rule. Of course, I know that these messages are put there automatically, according to your companies' policies. No one is actually including them on purpose, and most probably aren't even aware, any more, that they're there. But they are. I don't think this merits any official statement by the IESG, though the IESG might want to consider for itself whether it does. But how about if we try to deal with this as a community? It rather makes you look silly to have those notices there. And you don't want to look silly, right? So have a look at your posts, everyone, and if yours have any such junk at the bottoms of them, please do one of two things, tout de suite: 1. Arrange not to have them put there. If there's some way you can get an exception to your company's rule for things sent to the IETF, do it. 2. Get a non-company address, and use that for your IETF participation. You can get free addresses easily. This option also has the advantage that if you should change employers, your IETF-related email address doesn't need to change. Barry ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Confidentiality notices on email messages
Barry, You may want to refer to Section 5.2 of RFC 5378, which addresses this issue: Each Contributor agrees that any statement in a Contribution, whether generated automatically or otherwise, that states or implies that the Contribution is confidential or subject to any privilege, can be disregarded for all purposes, and will be of no force or effect. Best regards, Jorge On Tue, Jul 12, 2011 at 4:28 PM, Barry Leiba barryle...@computer.orgwrote: I am increasingly seeing IETF participants posting messages to IETF mailing lists, sending messages to chairs and ADs, and so on, where their messages include confidentiality/security/legal notices at the bottom. You know the ones; here are excerpts from two recent examples: Information Security Notice: The information contained in this mail is solely the property of the sender's organization. This mail communication is confidential. Recipients named above are obligated to maintain secrecy and are not permitted to disclose the contents of this communication with others. CONFIDENTIALITY NOTICE The information contained in this e-mail and any attachments is CONFIDENTIAL and is intended only for the use of the addressee. Any unauthorized use, disclosure, distribution, dissemination, or copying is strictly prohibited and may be unlawful. If you are not the intended recipient, you are prohibited from any further viewing of the e-mail or any attachments or from making any use of the e-mail or attachments. Those are just the beginnings of them -- they go on, and continue for another paragraph each. I've seen them in Spanish, French, and German, as well as English. Now, apart from being long and annoying, they're in conflict with the IETF's Note Well, which applies to anything posted to IETF mailing lists or sent to anyone in IETF leadership about IETF business: http://www.ietf.org/about/note-well.html I'd also argue that those posting such messages are running afoul of their own organizations' rules by posting confidential messages publicly. Of course, that's nonsense, but, hey, folks, it wouldn't be the first time a company might behave irrationally and discipline someone base on the letter, rather than the intent, of a rule. Of course, I know that these messages are put there automatically, according to your companies' policies. No one is actually including them on purpose, and most probably aren't even aware, any more, that they're there. But they are. I don't think this merits any official statement by the IESG, though the IESG might want to consider for itself whether it does. But how about if we try to deal with this as a community? It rather makes you look silly to have those notices there. And you don't want to look silly, right? So have a look at your posts, everyone, and if yours have any such junk at the bottoms of them, please do one of two things, tout de suite: 1. Arrange not to have them put there. If there's some way you can get an exception to your company's rule for things sent to the IETF, do it. 2. Get a non-company address, and use that for your IETF participation. You can get free addresses easily. This option also has the advantage that if you should change employers, your IETF-related email address doesn't need to change. Barry ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Confidentiality notices on email messages
Hi, Jorge. You may want to refer to Section 5.2 of RFC 5378, which addresses this issue: Each Contributor agrees that any statement in a Contribution, whether generated automatically or otherwise, that states or implies that the Contribution is confidential or subject to any privilege, can be disregarded for all purposes, and will be of no force or effect. Yes, I'm aware of that. My point was exactly that: that the confidentiality statement is pointless. I'm asking people to try to get rid of them entirely. Barry ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-yevstifeyev-ion-report-06.txt (Report on the Experiment with IETF Operational Notes (IONs)) to Informational RFC
Mykyta, I think the draft is fine without this addition, which contains some statements that I disagree with. I don't think analysis is needed; this all ancient history anyway. Regards Brian On 2011-07-13 04:50, Mykyta Yevstifeyev wrote: Hello, As Russ agreed to sponsor this document on I-D submission cut-off date, I did make only some minor changed proposed by him during AD evaluation. However I thought the document would be incomplete without analysis, so after LC I propose to add the following sub-section in the draft: 3.4. Analysis and Results IONs were intended to serve as a means to document issues related to procedures used by IETF or other parties, but to be more stable as a simple web page and to have a more lightweight procedures for approval than Best Current Practice (BCP) or other sort of RFC. Even though such middle-ground approach might be quite useful, it also brings a number of complexities and negative effects, which are described below. First of all, IONs were mainly scoped to IETF procedural questions. A number of IONs were published defining procedures used by IETF community, such as ion-ad-sponsoring. However, it should be noted that the formal procedure of IONs approval, laid out in RFC 4693 [RFC4693] did not imply community involvement, unlike one for BCP or other IETF Stream RFC. Even though RFC 4693 intended IONs to cover issues not sufficient for documenting in BCP, this regulation was often overlooked. This might have resulted in community non- acceptance of such procedures, partial or full, if IONs were adopted on the persistent basis. Moreover, as IONs were lower in the hierarchy of IETF documents that RFCs, published RFCs may override what mentioned in a particular ION (whereas a published RFC may change already established procedures), which might result in them not being sufficiently followed, creating documentation conflicts. Several IONS were published that describe the procedures used by IESG or its members internally, such as ion-discuss-criteria or ion-tsv- alt-cc. Such material is obviously more appropriate for publication as IESG Statements, which are also meant to be quite stable when published and are approved at IESG's discretion. A number of IONs were published covering different IAOC issues. Such IONs included ion-execd-tasks and ion-subpoena. However, even though IAOC works tightly with IETF, they have an ability to publish such material on their site - http://iaoc.ietf.org/. A one ION - ion-procdocs - was a reference guide to the IWTF Process documents. An other ION - ion-2026-practice - provided the criticism and operational experience on RFC 2026 [RFC2026]. Both this documents are fine as web pages, since the material contained in it might change quickly and often. ion-ion-format and ion-ion-store were published for the purpose of the IONs series itself and were discarded upon experiment closure. They are not analyzed here. The aforementioned facts claim that IONs were less useful than the equivalent information published in other way, and should be abandoned, as proposed by Section 4 of RFC 4693 [RFC4693]. In order not to request the 2nd LC after this text is included, I'd like to seek community feedback on it during this Last Call. Thanks, Mykyta Yevstifeyev 12.07.2011 17:39, The IESG wrote: The IESG has received a request from an individual submitter to consider the following document: - 'Report on the Experiment with IETF Operational Notes (IONs)' draft-yevstifeyev-ion-report-06.txt as an Informational RFC [ . . . ] ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: notes from discussion of KARP design guidelines
Hi, Joel (et al.), On 7/10/2011 7:10 AM, Joel Halpern wrote: Joe, THE KARP WG Chairs have reviewed your comments, in order to figure out what the best way to address them. We would appreciate it if you could engage in discussion of this proposal on the KARP working group email list. If you feel we are still not understanding your point, we would be happy to make some time avaialble for discussion at the WG session in Quebec City. (Comments from anyone else, particularly WG members, on the proposals being made by the WG chairs are appreciated as well.) Rather than a line by line response, we have tried to find the common themes and respond to them. If we have missed major issues, please let us know. You raised concern about the use of the term on-the-wire. Rather than replace the term, we would prefer to add descriptive text early in the document. This text would note that it is a widely used term in IETF documents, including many RFCs. It would also state for clarity that in this document it is used to refer to the message sent from one routing process to another. That's a great example of why this term should be removed. The message sent from one BGP to another is sent *inside* a TCP connection, and nobody would ever call the TCP bytestream payload the message on the wire. This term is simply sloppy, and just as the security community rightly raises issues with similarly poor use of its terms (e.g., random where pseudorandom or arbitrary are intended, or authenticated where integrity protection is intended), I consider this a *significant* transport issue. With regard to your comment about identifiers, we can add in the description of protocol reviews indications that such reviews should be clear about what IDs the review considers need protecting, as that is important context for the protocol review. OK. As noted in other exchanges, the document abstract needs a complete rewrite. It should be just an abstract, with the rest of the context either removed or moved to the introduction. In doing so, we will add text describing briefly the general concept of the routing protocol transport. OK. In general however, protocol specific behaviors are to be left to the protocol analysis documents. Equally, descriptions of detailed threats will be left either to the threat document or to the individual protocol analysis document as appropriate. My goal is to make some transport properties as notable and discussed in as much (or as little) detail as, e.g., multicast and unicast already are in the current document. There are several items in your comments indicating that you would like to see more discussion in the design guidelines of the protocol layering. That does not seem to be a useful addition to this document. Again, individual protocol analysis documents will deal with that where it is appropriate, and avoid it where it is a distraction. We do not see useful general statements of guidance that can be put into this document. As noted above, this is already in the document w.r.t. multicast/unicast; I'm suggesting that it's equally appropriate to include similar discussion of the issues of other layers on routing protocol security. Adding some general text in the discussion of communication modes elaborating on the difference between the communication as seen by the routing and security components, and the actual communication (e.g. that what is seen as multicast may be delivered as broadcast or multiple uni-cast) does seem a helpful addition to the document, and we will do that. I'm not sure if this is basically all I'm asking for; see above. The intent was to add discussion of some known transport issues that are as relevant as the multicast/unicast difference already discussed, in similar detail. Joe ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
LAST CALL: Room at the Hilton for CAD$229/night
Last call before I cancel this. If you would like a room at the Hilton for CAD$229/night please let me know. I seem to have a spare. -- Randall Gellens Opinions are personal;facts are suspect;I speak for myself only -- Randomly selected tag: --- Every word is like an unnecessary stain on silence and nothingness. --Beckett ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: notes from discussion of KARP design guidelines
On 12/07/2011 23:23, Joe Touch wrote: Hi, Joel (et al.), On 7/10/2011 7:10 AM, Joel Halpern wrote: Joe, THE KARP WG Chairs have reviewed your comments, in order to figure out what the best way to address them. We would appreciate it if you could engage in discussion of this proposal on the KARP working group email list. If you feel we are still not understanding your point, we would be happy to make some time avaialble for discussion at the WG session in Quebec City. (Comments from anyone else, particularly WG members, on the proposals being made by the WG chairs are appreciated as well.) Rather than a line by line response, we have tried to find the common themes and respond to them. If we have missed major issues, please let us know. You raised concern about the use of the term on-the-wire. Rather than replace the term, we would prefer to add descriptive text early in the document. This text would note that it is a widely used term in IETF documents, including many RFCs. It would also state for clarity that in this document it is used to refer to the message sent from one routing process to another. That's a great example of why this term should be removed. The message sent from one BGP to another is sent *inside* a TCP connection, and nobody would ever call the TCP bytestream payload the message on the wire. This term is simply sloppy, and just as the security community rightly raises issues with similarly poor use of its terms (e.g., random where pseudorandom or arbitrary are intended, or authenticated where integrity protection is intended), I consider this a *significant* transport issue. Joe Please can you suggest a suitable generic term that covers the set of cases that we need to deal with in routing - i.e. over the MAC, over IP, over UDP and over TCP, so that we can discuss inter routing entity message passing as an abstract operation. As Joel says when we get to the detailed design of each routing protocol we will discuss the details, but we want a high level discussion in this document. Note BTW that 186 RFCs use the term on the wire in this sort of situation. - Stewart With regard to your comment about identifiers, we can add in the description of protocol reviews indications that such reviews should be clear about what IDs the review considers need protecting, as that is important context for the protocol review. OK. As noted in other exchanges, the document abstract needs a complete rewrite. It should be just an abstract, with the rest of the context either removed or moved to the introduction. In doing so, we will add text describing briefly the general concept of the routing protocol transport. OK. In general however, protocol specific behaviors are to be left to the protocol analysis documents. Equally, descriptions of detailed threats will be left either to the threat document or to the individual protocol analysis document as appropriate. My goal is to make some transport properties as notable and discussed in as much (or as little) detail as, e.g., multicast and unicast already are in the current document. There are several items in your comments indicating that you would like to see more discussion in the design guidelines of the protocol layering. That does not seem to be a useful addition to this document. Again, individual protocol analysis documents will deal with that where it is appropriate, and avoid it where it is a distraction. We do not see useful general statements of guidance that can be put into this document. As noted above, this is already in the document w.r.t. multicast/unicast; I'm suggesting that it's equally appropriate to include similar discussion of the issues of other layers on routing protocol security. Adding some general text in the discussion of communication modes elaborating on the difference between the communication as seen by the routing and security components, and the actual communication (e.g. that what is seen as multicast may be delivered as broadcast or multiple uni-cast) does seem a helpful addition to the document, and we will do that. I'm not sure if this is basically all I'm asking for; see above. The intent was to add discussion of some known transport issues that are as relevant as the multicast/unicast difference already discussed, in similar detail. Joe -- For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/index.html ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Repetitions and consensus
Brian E Carpenter wrote: We quite often discuss here how to judge rough consensus. That issue turns up most of the time in inappropriate situations. I regularly see folks _counting_ opinions when issues have been raised instead of actually resolving the issues. As previously said, the most important thing is to drill down and sort out matters of personal taste from issues are technical or procedural. Matters of personal taste can be settled by signficant majority, and rough applies almost exclusively to issues of personal taste. Technical and procedural issues need to be addressed with an issue resolution process, where alternatives are seriously evaluated. Here is a snipped from an IESG response to an appeal: However, several ADs felt that the issue was technical, not stylistic, thus the IESG as a whole did not have consensus that the issue was non-technical in this case. Trying to gauge (rough) consensus by counting voiced opinions when an issue has not been reliably determined to be non-technical and non-procedural _is_ inappropriate. At least that is what I believe that the IESG thought a couple of years ago. -Martin ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Confidentiality notices on email messages
Barry, I'm not a lawyer and I don't play one on TV or the net, so I likely don't understand the situation. As a point of possibly interesting information, once upon a time, at a training session held by a lawyer regarding how to protect confidential information, we were admonished not to slap a confidential label on anything automatically or without consideration, because, we were warned, doing so can cause the label to lose meaning for everything. In other words, if we labelled everything confidential, then we were really saying nothing was confidential. Ever since, I've wondered if these notices were set up by someone who is a lawyer and does understand the situation, or if they were set up by someone who saw others do it, or heard that this sort of thing was needed. -- Randall Gellens Opinions are personal;facts are suspect;I speak for myself only -- Randomly selected tag: --- I always avoid prophesying beforehand, because it is a much better policy to prophesy after the event has already taken place. --Winston Churchill ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-yevstifeyev-ion-report-06.txt (Report on the Experiment with IETF Operational Notes (IONs)) to Informational RFC
+1 I also disagree with some of the statements in the proposed text. I do not think it is worth the effort to come up with consensus text. Russ On Jul 12, 2011, at 6:20 PM, Brian E Carpenter wrote: Mykyta, I think the draft is fine without this addition, which contains some statements that I disagree with. I don't think analysis is needed; this all ancient history anyway. Regards Brian On 2011-07-13 04:50, Mykyta Yevstifeyev wrote: Hello, As Russ agreed to sponsor this document on I-D submission cut-off date, I did make only some minor changed proposed by him during AD evaluation. However I thought the document would be incomplete without analysis, so after LC I propose to add the following sub-section in the draft: 3.4. Analysis and Results IONs were intended to serve as a means to document issues related to procedures used by IETF or other parties, but to be more stable as a simple web page and to have a more lightweight procedures for approval than Best Current Practice (BCP) or other sort of RFC. Even though such middle-ground approach might be quite useful, it also brings a number of complexities and negative effects, which are described below. First of all, IONs were mainly scoped to IETF procedural questions. A number of IONs were published defining procedures used by IETF community, such as ion-ad-sponsoring. However, it should be noted that the formal procedure of IONs approval, laid out in RFC 4693 [RFC4693] did not imply community involvement, unlike one for BCP or other IETF Stream RFC. Even though RFC 4693 intended IONs to cover issues not sufficient for documenting in BCP, this regulation was often overlooked. This might have resulted in community non- acceptance of such procedures, partial or full, if IONs were adopted on the persistent basis. Moreover, as IONs were lower in the hierarchy of IETF documents that RFCs, published RFCs may override what mentioned in a particular ION (whereas a published RFC may change already established procedures), which might result in them not being sufficiently followed, creating documentation conflicts. Several IONS were published that describe the procedures used by IESG or its members internally, such as ion-discuss-criteria or ion-tsv- alt-cc. Such material is obviously more appropriate for publication as IESG Statements, which are also meant to be quite stable when published and are approved at IESG's discretion. A number of IONs were published covering different IAOC issues. Such IONs included ion-execd-tasks and ion-subpoena. However, even though IAOC works tightly with IETF, they have an ability to publish such material on their site - http://iaoc.ietf.org/. A one ION - ion-procdocs - was a reference guide to the IWTF Process documents. An other ION - ion-2026-practice - provided the criticism and operational experience on RFC 2026 [RFC2026]. Both this documents are fine as web pages, since the material contained in it might change quickly and often. ion-ion-format and ion-ion-store were published for the purpose of the IONs series itself and were discarded upon experiment closure. They are not analyzed here. The aforementioned facts claim that IONs were less useful than the equivalent information published in other way, and should be abandoned, as proposed by Section 4 of RFC 4693 [RFC4693]. In order not to request the 2nd LC after this text is included, I'd like to seek community feedback on it during this Last Call. Thanks, Mykyta Yevstifeyev 12.07.2011 17:39, The IESG wrote: The IESG has received a request from an individual submitter to consider the following document: - 'Report on the Experiment with IETF Operational Notes (IONs)' draft-yevstifeyev-ion-report-06.txt as an Informational RFC [ . . . ] ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: notes from discussion of KARP design guidelines
On 7/12/2011 3:36 PM, Stewart Bryant wrote: On 12/07/2011 23:23, Joe Touch wrote: Hi, Joel (et al.), On 7/10/2011 7:10 AM, Joel Halpern wrote: Joe, THE KARP WG Chairs have reviewed your comments, in order to figure out what the best way to address them. We would appreciate it if you could engage in discussion of this proposal on the KARP working group email list. If you feel we are still not understanding your point, we would be happy to make some time avaialble for discussion at the WG session in Quebec City. (Comments from anyone else, particularly WG members, on the proposals being made by the WG chairs are appreciated as well.) Rather than a line by line response, we have tried to find the common themes and respond to them. If we have missed major issues, please let us know. You raised concern about the use of the term on-the-wire. Rather than replace the term, we would prefer to add descriptive text early in the document. This text would note that it is a widely used term in IETF documents, including many RFCs. It would also state for clarity that in this document it is used to refer to the message sent from one routing process to another. That's a great example of why this term should be removed. The message sent from one BGP to another is sent *inside* a TCP connection, and nobody would ever call the TCP bytestream payload the message on the wire. This term is simply sloppy, and just as the security community rightly raises issues with similarly poor use of its terms (e.g., random where pseudorandom or arbitrary are intended, or authenticated where integrity protection is intended), I consider this a *significant* transport issue. Joe Please can you suggest a suitable generic term that covers the set of cases that we need to deal with in routing - i.e. over the MAC, over IP, over UDP and over TCP, so that we can discuss inter routing entity message passing as an abstract operation. As Joel says when we get to the detailed design of each routing protocol we will discuss the details, but we want a high level discussion in this document. Note BTW that 186 RFCs use the term on the wire in this sort of situation. I counted nearly 210, when including over the wire too. There are similar misuses of, e.g., security terms, though, so let's not let past errors suggest continued use. That said, let's proceed: First, when you say on the wire do you mean: (A)- the routing protocol data units (RPDUs) (B)- way in which RPDUs are exchanged this includes message payloads, meta-info (header information), and any other info at other layers beyond RPDUs that the routing protocol uses or relies upon I'm presuming the term on the wire is intended to differentiate between (A) and (B). There's no good way to describe (B) as a single entity because it's not one. You basically are differentiating between the message and the means of its communication. The latter is often called a 'channel' in other contexts, so maybe that's the term you want - a way to protect the 'channel'. Joe ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Confidentiality notices on email messages
On Jul 12, 2011, at 4:12 PM, Randall Gellens wrote: Ever since, I've wondered if these notices were set up by someone who is a lawyer and does understand the situation, or if they were set up by someone who saw others do it, or heard that this sort of thing was needed. The latter seems likely to me as well, but the IETF community is unlikely to convince such people to change their minds. It's certain to be far easier, in this case, to gently encourage participants to use a different email address for their IETF participation. (I do that already -- not because of inappropriate footers, but because Exchange and Outlook are mind-bogglingly poor tools for discussion lists.) -- J.D. Falk the leading purveyor of industry counter-rhetoric solutions ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Confidentiality notices on email messages
Randall Gellens wrote: Barry, I'm not a lawyer and I don't play one on TV or the net, so I likely don't understand the situation. As a point of possibly interesting information, once upon a time, at a training session held by a lawyer regarding how to protect confidential information, we were admonished not to slap a confidential label on anything automatically or without consideration, because, we were warned, doing so can cause the label to lose meaning for everything. In other words, if we labelled everything confidential, then we were really saying nothing was confidential. Ever since, I've wondered if these notices were set up by someone who is a lawyer and does understand the situation, or if they were set up by someone who saw others do it, or heard that this sort of thing was needed. Depending on the organization, it may be a legally required especially if it is public stock company. It is also legally required to make an explicit statement in order to have stronger enforcement when push comes to shove, i.e. ignorance can not be claimed. There is also a difference in PUBLIC vs PRIVATE communications and while it is more important to have disclaimers when public, unless an explicit statement is also made in private, it can not be assumed. A good example is a private message send to someone and he/she makes it public. In tort cases, the receiver has to right to make it public if and only if the author did not make an explicit statement that it remains private and the guideline is to make it the very first statement: THIS IS A PRIVATE MESSAGE AND THE INTENTION IS THAT IT REMAINS PRIVATE. MAKING THIS MESSAGE PUBLIC WILL VIOLATE US EPCA User Privacy Expectation PROVISIONS. IMV, the IETF will be opening up a can of worms if they begin to cite legal conflicts with the NOTE WELL statement and if its suggested that participants use external addresses in order to participate without conflict, well, even if people took the advice, it may put the person in some legal conflict with his corporate employer. e.g. just because a person moonlights in some other activity, does not necessary mean they are free from company employment contracts and if there is any kind of relationship of his external activities with his normal work, they might want him to use a corporate identity or not. I guess it all depends how much of a hard ass is his boss, employer or their chief counsel. You might find if the IETF is making a fuss, they may ask the employee to just not participate - lurk, but don't post. -- Hector Santos, CTO http://www.santronics.com http://santronics.blogspot.com ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-yevstifeyev-ion-report-06.txt (Report on the Experiment with IETF Operational Notes (IONs)) to Informational RFC
13.07.2011 1:20, Brian E Carpenter wrote: Mykyta, I think the draft is fine without this addition, which contains some statements that I disagree with. I don't think analysis is needed; this all ancient history anyway. Brian, Let me explain why I'm planning to include this sub-section. The current draft, after giving background, lists all IONs which were published. Then it notifies the reader about de-facto closure of the experiment by IESG and provides information on what was done with IONs. Finally, there is a conclusion, which states that IONs were a bad idea. Such conclusion needs some basis, and will be unjustified without any analysis of why were IONs a bad idea. If you have some objections/proposals, please feel free to express them. I think we'll be able to find some consensus. Mykyta Yevstifeyev Regards Brian On 2011-07-13 04:50, Mykyta Yevstifeyev wrote: Hello, As Russ agreed to sponsor this document on I-D submission cut-off date, I did make only some minor changed proposed by him during AD evaluation. However I thought the document would be incomplete without analysis, so after LC I propose to add the following sub-section in the draft: 3.4. Analysis and Results [ . . . ] abandoned, as proposed by Section 4 of RFC 4693 [RFC4693]. In order not to request the 2nd LC after this text is included, I'd like to seek community feedback on it during this Last Call. Thanks, Mykyta Yevstifeyev 12.07.2011 17:39, The IESG wrote: The IESG has received a request from an individual submitter to consider the following document: - 'Report on the Experiment with IETF Operational Notes (IONs)' draft-yevstifeyev-ion-report-06.txt as an Informational RFC [ . . . ] ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Call for opinion on impact of cashless economy on 'Security Consideration'
Hi, Readers use information given in this message at thier own risk. Author cannot be held responsible for damages/consequences caused. Refer http://samirsrivastava.typepad.com. Search wipo.int for patents by me. Work has potential to impact security consideration of IETF docs. Awarding a prize is in the sole discretion of awarding organization.Yet nobel peace prize to US President not clear. He was awarded it for diplomacy within a year after becoming President. I sent slide set on cashless economy to khosla ventures in 2007. When I posted on alt.security.terrorism on nov-28-10, president went on surprise trip to Afganistan. I suspect it is used for someting else also. Due to various reasons referred work is not able to draw attention from media and governments. I request parties mentioned on email to clarify doubts on public forum. I request IETEers to review it. BTW outstanding work of nobel winners is well known in advance. Due to unavoidable situations I cannot submit draft. Regards Samir Srivastava ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Call for opinion on impact of cashless economy on 'Security Consideration'
Added more on the distribution list regards Samir Srivastava On 7/12/11, Samir Srivastava samirs.li...@gmail.com wrote: Hi, Readers use information given in this message at thier own risk. Author cannot be held responsible for damages/consequences caused. Refer http://samirsrivastava.typepad.com. Search wipo.int for patents by me. Work has potential to impact security consideration of IETF docs. Awarding a prize is in the sole discretion of awarding organization.Yet nobel peace prize to US President not clear. He was awarded it for diplomacy within a year after becoming President. I sent slide set on cashless economy to khosla ventures in 2007. When I posted on alt.security.terrorism on nov-28-10, president went on surprise trip to Afganistan. I suspect it is used for someting else also. Due to various reasons referred work is not able to draw attention from media and governments. I request parties mentioned on email to clarify doubts on public forum. I request IETEers to review it. BTW outstanding work of nobel winners is well known in advance. Due to unavoidable situations I cannot submit draft. Regards Samir Srivastava ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Last Call: draft-yevstifeyev-ion-report-06.txt (Report on the Experiment with IETF Operational Notes (IONs)) to Informational RFC
The IESG has received a request from an individual submitter to consider the following document: - 'Report on the Experiment with IETF Operational Notes (IONs)' draft-yevstifeyev-ion-report-06.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 i...@ietf.org mailing lists by 2011-08-09. 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 reports on the IETF Operational Notes (IONs) process experiment, conducted by RFC 4693 in accordance with RFC 3933. It also updates RFC 4693 and changes its status to Historic. The file can be obtained via http://datatracker.ietf.org/doc/draft-yevstifeyev-ion-report/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-yevstifeyev-ion-report/ No IPR declarations have been submitted directly on this I-D. ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
Protocol Action: 'DomainKeys Identified Mail (DKIM) Signatures' to Draft Standard (draft-ietf-dkim-rfc4871bis-15.txt)
The IESG has approved the following document: - 'DomainKeys Identified Mail (DKIM) Signatures' (draft-ietf-dkim-rfc4871bis-15.txt) as a Draft Standard This document is the product of the Domain Keys Identified Mail Working Group. The IESG contact persons are Sean Turner and Stephen Farrell. A URL of this Internet Draft is: http://datatracker.ietf.org/doc/draft-ietf-dkim-rfc4871bis/ Technical Summary DomainKeys Identified Mail (DKIM) permits a person, role, or organization that owns the signing domain to claim some responsibility for a message by associating the domain with the message. This can be an author's organization, an operational relay or one of their agents. DKIM separates the question of the identity of the signer of the message from the purported author of the message. Assertion of responsibility is validated through a cryptographic signature and querying the signer's domain directly to retrieve the appropriate public key. Message transit from author to recipient is through relays that typically make no substantive change to the message content and thus preserve the DKIM signature. Working Group Summary Getting this document finished has been a controversial process, with strong disagreement about a number of points. There is certainly broad agreement that DKIM is a widely deployed, useful protocol, and that it's ready for advancement. There are major differences of opinion on several things, including 1. The importance of giving specific advice on which email header fields to sign. 2. What information should be considered output from the signature verifier. 3. How the DKIM signature ties into, or should tie into, domain names that appear in other parts of the email message, particularly the RFC 5322 from header field. 4. How to handle potential attacks mounted by adding extra header fields to the message after it has been signed. This is a particular issue with the RFC 5322 from header field, but affects other header fields as well. There have been other controversies; this list is not exhaustive. See the mailing list archives for more details. In the end, though, the document as submitted has rough and significant consensus of the working group as a whole, even when it doesn't represent unanimity. Document Quality The DKIM base protocol is widely deployed, with many implementations (see http://www.ietf.org/iesg/implementation/report-rfc4871.txt ). This version of the spec comes after a thorough working group review and publication of RFC 5672, which added significant clarifications to the language. Diffs between RFC 4871 and this draft can be found at: http://www.trusteddomain.org/dkim-diff.html Personnel Barry Leiba (barryle...@computer.org) is the Document Shepherd. Sean Turner (turn...@ieca.com) is the Responsible Area Director. RFC Editor Note Note that draft-ietf-dkim-mailinglists depends heavily on draft-ietf-dkim-rfc4871bis, and will be waiting in the editor queue for a reference to it. That document has references to specific sections in draft-ietf-dkim-rfc4871bis, so the RFC Editor should process rfc4871bis first, and make sure the section references in dkim-mailinglists are correct afterward. ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
