Re: Of governments and representation (was: Montevideo Statement)
For what it's worth, I think Russ and Jari did the right thing in signing the statement the way they did, at the time they did it, with the prior consultation they did. I was not consulted. And I'm glad they are capable of acting at this level without consulting me. On 10/11/2013 06:02 PM, John Curran wrote: Folks - As a result of the Internet's growing social and economic importance, the underlying Internet structures are receiving an increasing level of attention by both governments and civil society. The recent revelations regarding US government surveillance of the Internet are now greatly accelerating government attention on all of the Internet institutions, the IETF included. All of this attention is likely bring about significant changes in the Internet ecosystem, potentially including how the IETF interacts with governments, civil society, and other Internet organizations globally. In my personal view, it is a very important for the IETF to select leadership who can participate in any discussions that occur, and it would further be prudent for the IETF leaders to be granted a sufficient level of support by the community to take positions in those discussions and make related statements, to the extent the positions and the statements are aligned with established IETF positions and/or philosophy. The most interesting part of the myriad of Internet Governance discussions is that multiple organizations are all pushing ahead independently from one another, which results in a very dynamic situation where we often don't even know that there will be a conference or meeting until after its announced, do not know auspices under which it will be held, nor what the scope of the discussions held will ultimately be. However, the failure of any of the Internet organizations to participate will not actually prevent consideration of a variety of unique and colorful proposals for improving the Internet and/or the IETF, nor will it preclude adoption even in the absence of IETF input... The IETF is a very important Internet institution, and it deserves to be represented in any discussions which might propose changes to the fundamental mechanisms of Internet cooperation. It would be a wonderful world indeed if all of these discussions started with submission of an Internet Draft and discussion on open mailing lis, but that hasn't been the modus operandi of governments and is probably too much to realistically expect. /John
Re: Transparency in Specifications and PRISM-class attacks
I'd like to snippet Phil's suggestion to an abbreviated version of one sentence, becaue I think this is right on. On 09/19/2013 05:37 PM, Phillip Hallam-Baker wrote: The issue we need to focus on is how to convince our audience that our specifications have not been compromised To my mind, the first thing to focus on is making our specs readable, so that it's possible to understand that they have not been compromised. That means that complexity is our enemy. (Or perhaps the zeroeth thing is actually finishing our specs, so that we can worry about whether RFC is compromised rather than worrying about whether deployed equipment has fixed the glitch that was introduced in -24 and fixed in -27, but everyone had forgotten about by -33...)
Re: Transparency in Specifications and PRISM-class attacks
On 09/20/2013 01:38 PM, Hannes Tschofenig wrote: On 20.09.2013 13:20, Harald Alvestrand wrote: To my mind, the first thing to focus on is making our specs readable, so that it's possible to understand that they have not been compromised. Three questions for you Harald: 1) When you say that our documents have to be readable then you have to say readable by whom? Of course, most of our documents are tailored to those who implement rather than to, let's say, someone who has little understanding of Internet technology in general. By those who implement them, and those who try to understand how it works to the degree that they feel assured that there are no non-understood security risks (intentional or otherwise). 2) Are there documents you find non-readable? From the stack I'm currently working on, I find the ICE spec to be convoluted, but the SDP spec is worse, becaue it's spread across so many documents, and there are pieces where people seem to have agreed to ship documents rather than agree on what they meant. I have not found security implications of these issues. 3) Do you have any reasons to believe that there are documents that have been compromised? I have no evidence that they have intentionally been compromised. I think we manage to make specs unreadable without deliberate obfuscation - but the reader can't know that.
Re: Last Call: draft-nandakumar-rtcweb-stun-uri-05.txt (URI Scheme for Session Traversal Utilities for NAT (STUN) Protocol) to Proposed Standard
On 08/15/2013 11:04 AM, Graham Klyne wrote: Hi Harald, On 14/08/2013 19:49, Harald Alvestrand wrote: On 08/13/2013 12:14 AM, Graham Klyne wrote: [...] But, in a personal capacity, not as designated reviewer, I have to ask *why* this needs to be a URI. As far as I can tell, it is intended for use only in very constrained environments, where there seems to be little value in having an identifier that can appear in all the contexts where a URI may be recognized. The criteria for new URI schemes in http://tools.ietf.org/html/rfc4395 include: New URI schemes SHOULD have clear utility to the broad Internet community, beyond that available with already registered URI schemes. -- http://tools.ietf.org/html/rfc4395#section-2.1 This utility to the broader community is not clear to me, but I don't fully understand the intended scope of this protocol, so I could be missing something. So, in declaring consensus for this specification, I would request that this aspect at least be considered. I can only give my personal opinion 1) This is a format for a piece of data. This data cannot be expressed using any existing URI scheme - indeed, I don't think there exists another well-defined textual representation of this piece of data. 1) This is defining an identifier that will be used in W3C-defined APIs. W3C tends to use URIs every time they want a self-defining piece of data with a clearly defined structure. In the particular API where this is wanted, one wants to have STUN URIs, TURNS URIs and TURN URIs passed over the same interface. Thus, keeping with the W3C tradition of URIs seems reasonable. I think this answers the question about utility to the broader community to my satisfaction - your mileage may differ, of course. Some thoughts occur to me: 1. My reading was that this is a generic NAT traversal protocol, so the requirement here is not Web/W3C specific. But you do say used in W3C-defined APIs... Truth in advertising: One W3C-defined API. The specific reference: http://dev.w3.org/2011/webrtc/editor/webrtc.html#dictionary-rtciceserver-members 2. If this is being driven by W3C activities, this should probably be flagged with W3C TAG. I'll raise it there. 3. URIs are not generally used as *data* formats, but rather as identifiers for resources. Web architecture and REST principles tend to discourage information encoded in URIs in favour of data representation formats. Cf. http://www.w3.org/TR/webarch/#uri-opacity, http://www.w3.org/2001/tag/doc/metaDataInURI-31.html Well, it is. The data encoded is the identification of a STUN server, which is a resource. 4. If the purpose here is simply to encode data, then there does already exist a suitable URI scheme, viz data:. A new content type can be defined to actually encode the required data, and the whole be wrapped in a data: URI. This approach has the advantage that alternative mechanisms (other than URIs) can be used to transfer the traversal data if required (though that may be moot in the very restricted intended scope of deployment for stun:, etc.) Yes, but why? ... Further, according to http://tools.ietf.org/html/rfc5389 it appears that there are security considerations with regard to the STUN protocol that it should not be used in isolation: [[ Classic STUN also had a security vulnerability -- attackers could provide the client with incorrect mapped addresses under certain topologies and constraints, and this was fundamentally not solvable through any cryptographic means. Though this problem remains with this specification, those attacks are now mitigated through the use of more complete solutions that make use of STUN. For these reasons, this specification obsoletes RFC 3489, and instead describes STUN as a tool that is utilized as part of a complete NAT traversal solution. ]] -- http://tools.ietf.org/html/rfc5389#section-2 It seems to me that creating a URI for STUN could encourage its use in environments outside the more complete solutions that make use of STUN. This seems to be further reason that STUN[S] should not be a URI scheme. I have also suggested that, if registered, the URI scheme registration should carries a health warning to this effect, and that it is not suitable for general use that is not part of a complete NAT traversal solution. But I also recognize that I do not fully grasp the security implications, and that if those that do know better can agree that there is no potential for creating security risks here, this suggestion may be unnecessary. This URI scheme does not represent STUN. It represents configuration data that is used to initialize a protocol machine that utilizes STUN. This configuration data has to be passed no matter what the format of the data is - whether it be URI or not. Thus, I do not think the argument raised is really relevant to the context. The data will be passed
Re: Last Call: draft-nandakumar-rtcweb-stun-uri-05.txt (URI Scheme for Session Traversal Utilities for NAT (STUN) Protocol) to Proposed Standard
On 08/15/2013 04:05 PM, Graham Klyne wrote: Harald, Briefly: 1. Thanks for the reference, and 2. I misunderstood what you meant by This is a format for a piece of data. In light of your clarification, I withdraw my comments 3 4. Identification of the STUN service would appear to be a perfectly reasonable use. ... So the remaining issues from my questions are whether the intended highly constrained use of these services justifies allocating a URI scheme. If the community consensus is that it is of sufficient value, I might suggest an annotation to the scheme registration along the lines of: This URI scheme is intended for use in very specific NAT traversal environments, and should not be used otherwise on the open Web or Internet. Would such a comment run contrary to your expectations for its use? I would prefer to run the comment as This scheme is intended for use in specific environments that involve NAT traversal. Users of the scheme need to carefully consider the security properties of the context in which they are using it. Echoing the warning in the STUN scheme - use this when you know what you're doing only. Frankly, like Hadriel indicated, I have no idea whether it will be useful in other contexts or not, and I'm hesitant to put language that seems to claim that we've evaluated all possible contexts and say that there aren't other contexts in which it can be useful. #g -- On 15/08/2013 11:04, Harald Alvestrand wrote: On 08/15/2013 11:04 AM, Graham Klyne wrote: Hi Harald, On 14/08/2013 19:49, Harald Alvestrand wrote: On 08/13/2013 12:14 AM, Graham Klyne wrote: [...] But, in a personal capacity, not as designated reviewer, I have to ask *why* this needs to be a URI. As far as I can tell, it is intended for use only in very constrained environments, where there seems to be little value in having an identifier that can appear in all the contexts where a URI may be recognized. The criteria for new URI schemes in http://tools.ietf.org/html/rfc4395 include: New URI schemes SHOULD have clear utility to the broad Internet community, beyond that available with already registered URI schemes. -- http://tools.ietf.org/html/rfc4395#section-2.1 This utility to the broader community is not clear to me, but I don't fully understand the intended scope of this protocol, so I could be missing something. So, in declaring consensus for this specification, I would request that this aspect at least be considered. I can only give my personal opinion 1) This is a format for a piece of data. This data cannot be expressed using any existing URI scheme - indeed, I don't think there exists another well-defined textual representation of this piece of data. 1) This is defining an identifier that will be used in W3C-defined APIs. W3C tends to use URIs every time they want a self-defining piece of data with a clearly defined structure. In the particular API where this is wanted, one wants to have STUN URIs, TURNS URIs and TURN URIs passed over the same interface. Thus, keeping with the W3C tradition of URIs seems reasonable. I think this answers the question about utility to the broader community to my satisfaction - your mileage may differ, of course. Some thoughts occur to me: 1. My reading was that this is a generic NAT traversal protocol, so the requirement here is not Web/W3C specific. But you do say used in W3C-defined APIs... Truth in advertising: One W3C-defined API. The specific reference: http://dev.w3.org/2011/webrtc/editor/webrtc.html#dictionary-rtciceserver-members 2. If this is being driven by W3C activities, this should probably be flagged with W3C TAG. I'll raise it there. 3. URIs are not generally used as *data* formats, but rather as identifiers for resources. Web architecture and REST principles tend to discourage information encoded in URIs in favour of data representation formats. Cf. http://www.w3.org/TR/webarch/#uri-opacity, http://www.w3.org/2001/tag/doc/metaDataInURI-31.html Well, it is. The data encoded is the identification of a STUN server, which is a resource. 4. If the purpose here is simply to encode data, then there does already exist a suitable URI scheme, viz data:. A new content type can be defined to actually encode the required data, and the whole be wrapped in a data: URI. This approach has the advantage that alternative mechanisms (other than URIs) can be used to transfer the traversal data if required (though that may be moot in the very restricted intended scope of deployment for stun:, etc.) Yes, but why? ... Further, according to http://tools.ietf.org/html/rfc5389 it appears that there are security considerations with regard to the STUN protocol that it should not be used in isolation: [[ Classic STUN also had a security vulnerability -- attackers could provide the client with incorrect mapped addresses under certain
Re: Last Call: draft-nandakumar-rtcweb-stun-uri-05.txt (URI Scheme for Session Traversal Utilities for NAT (STUN) Protocol) to Proposed Standard
On 08/15/2013 04:20 PM, Peter Saint-Andre wrote: On 8/15/13 8:10 AM, Harald Alvestrand wrote: On 08/15/2013 04:05 PM, Graham Klyne wrote: Harald, Briefly: 1. Thanks for the reference, and 2. I misunderstood what you meant by This is a format for a piece of data. In light of your clarification, I withdraw my comments 3 4. Identification of the STUN service would appear to be a perfectly reasonable use. ... So the remaining issues from my questions are whether the intended highly constrained use of these services justifies allocating a URI scheme. If the community consensus is that it is of sufficient value, I might suggest an annotation to the scheme registration along the lines of: This URI scheme is intended for use in very specific NAT traversal environments, and should not be used otherwise on the open Web or Internet. Would such a comment run contrary to your expectations for its use? I would prefer to run the comment as This scheme is intended for use in specific environments that involve NAT traversal. Users of the scheme need to carefully consider the security properties of the context in which they are using it. Echoing the warning in the STUN scheme - use this when you know what you're doing only. Frankly, like Hadriel indicated, I have no idea whether it will be useful in other contexts or not, I tend to think not. and I'm hesitant to put language that seems to claim that we've evaluated all possible contexts Agreed. and say that there aren't other contexts in which it can be useful. Too many negatives. :-) You are hesitant to say that it won't be useful in other contexts, or you would prefer to say that it was designed for a specific contexts and probably wouldn't be useful outside that context? I'm hesitant to say that it won't be useful in other contexts - that is, I'd prefer to say nothing about whether it will be useful elsewhere or not. Others understand other contexts better than I do; if they come forward (as Hadriel just did) and say This is useful to me, I don't want the draft to say Sorry, but we decided you can't use it. Peter
Re: Last Call: draft-nandakumar-rtcweb-stun-uri-05.txt (URI Scheme for Session Traversal Utilities for NAT (STUN) Protocol) to Proposed Standard
On 08/13/2013 12:14 AM, Graham Klyne wrote: From: The IESG iesg-secret...@ietf.org To: IETF-Announce ietf-annou...@ietf.org Reply-To: ietf@ietf.org Sender: iesg-secret...@ietf.org Subject: Last Call: draft-nandakumar-rtcweb-stun-uri-05.txt (URI Scheme for Session Traversal Utilities for NAT (STUN) Protocol) to Proposed Standard The IESG has received a request from an individual submitter to consider the following document: - 'URI Scheme for Session Traversal Utilities for NAT (STUN) Protocol' draft-nandakumar-rtcweb-stun-uri-05.txt as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2013-08-16. 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 is the specification of the syntax and semantics of the Uniform Resource Identifier (URI) scheme for the Session Traversal Utilities for NAT (STUN) protocol. The file can be obtained via http://datatracker.ietf.org/doc/draft-nandakumar-rtcweb-stun-uri/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-nandakumar-rtcweb-stun-uri/ballot/ No IPR declarations have been submitted directly on this I-D. As IANA designated expert for reviewing URI scheme registrations, I've been asked to approve this scheme for registration. If there is IETF consensus to publish this document, it is clear to me that the scheme should be registered. But, in a personal capacity, not as designated reviewer, I have to ask *why* this needs to be a URI. As far as I can tell, it is intended for use only in very constrained environments, where there seems to be little value in having an identifier that can appear in all the contexts where a URI may be recognized. The criteria for new URI schemes in http://tools.ietf.org/html/rfc4395 include: New URI schemes SHOULD have clear utility to the broad Internet community, beyond that available with already registered URI schemes. -- http://tools.ietf.org/html/rfc4395#section-2.1 This utility to the broader community is not clear to me, but I don't fully understand the intended scope of this protocol, so I could be missing something. So, in declaring consensus for this specification, I would request that this aspect at least be considered. I can only give my personal opinion 1) This is a format for a piece of data. This data cannot be expressed using any existing URI scheme - indeed, I don't think there exists another well-defined textual representation of this piece of data. 1) This is defining an identifier that will be used in W3C-defined APIs. W3C tends to use URIs every time they want a self-defining piece of data with a clearly defined structure. In the particular API where this is wanted, one wants to have STUN URIs, TURNS URIs and TURN URIs passed over the same interface. Thus, keeping with the W3C tradition of URIs seems reasonable. I think this answers the question about utility to the broader community to my satisfaction - your mileage may differ, of course. ... Further, according to http://tools.ietf.org/html/rfc5389 it appears that there are security considerations with regard to the STUN protocol that it should not be used in isolation: [[ Classic STUN also had a security vulnerability -- attackers could provide the client with incorrect mapped addresses under certain topologies and constraints, and this was fundamentally not solvable through any cryptographic means. Though this problem remains with this specification, those attacks are now mitigated through the use of more complete solutions that make use of STUN. For these reasons, this specification obsoletes RFC 3489, and instead describes STUN as a tool that is utilized as part of a complete NAT traversal solution. ]] -- http://tools.ietf.org/html/rfc5389#section-2 It seems to me that creating a URI for STUN could encourage its use in environments outside the more complete solutions that make use of STUN. This seems to be further reason that STUN[S] should not be a URI scheme. I have also suggested that, if registered, the URI scheme registration should carries a health warning to this effect, and that it is not suitable for general use that is not part of a complete NAT traversal solution. But I also recognize that I do not fully grasp the security implications, and that if those that do know better can agree that there is no potential for creating security risks here, this suggestion may be unnecessary. This URI scheme does not represent STUN. It represents configuration data that is used to initialize a protocol machine that utilizes STUN. This configuration data has to be passed no matter what the format of the data is - whether it be URI or not. Thus, I do not think
Re: Last Call: draft-nandakumar-rtcweb-stun-uri-05.txt (URI Scheme for Session Traversal Utilities for NAT (STUN) Protocol) to Proposed Standard
On 08/13/2013 09:03 PM, S Moonesamy wrote: At 15:14 12-08-2013, Graham Klyne wrote: But, in a personal capacity, not as designated reviewer, I have to ask *why* this needs to be a URI. As far as I can tell, it is intended for use only in very constrained environments, where there seems to be little value in having an identifier that can appear in all the contexts where a URI may be recognized. This is an individual comment. I reviewed draft-petithuguenin-behave-turn-uris-05. I wondered why a URI was needed given the limited use. The same argument is applicable for draft-nandakumar-rtcweb-stun-uri-05. There is running code for both drafts. Both draft qualify for DNP. I would describe the proposals as trying to fit the solution within a URI instead of designing a URI scheme. Both proposals sound like UNSAF. FWIW, UNSAF = Unilateral Self Address Fixing, or figuring out what my address is on the Internet, and is exactly what STUN is useful for. In a world of NATs, UNSAF is, unfortunately, a necessary thing to do. These URI schemes allow us to pass configuration data for performing these operations in a standardized form.
Re: [MMUSIC] Update on Orlando time for human language draft discussion
On 03/10/2013 09:08 PM, Randall Gellens wrote: At 6:16 PM + 3/10/13, Keith (Keith) DRAGE wrote: My understanding was that the idea was to label a particular media stream, rather than (for example) a SIP body. Different media streams could have different labels. Keith is right. As an example, SIP might be used to setup a call with an audio stream using English and a video stream using American Sign Language. SDP also allows other protocols besides SIP to be used to establish the session. OK, but that's not what I really was thinking about RFC 3282 (and its predecessors as part of the HTTP protocol) distinguished between two distinct fields: - Here's what I'm willing to accept - where prioritization is important - Here's what I'm going to use - where prioritization is not only unimportant, it's meaningless It might be good if whatever comes out of this discussion supports making that distinction. You may also want to think about how language tags interact with direction - if you're talking to an interpreter, where audio going one way is English and what comes back is in Spanish, are you able to mark the RTP session (if that's what you're marking, and not the media stream) as sending English, receiving Spanish? But this level of detail doesn't really belong on the IETF list - which list should we use? -Original Message- From: mmusic-boun...@ietf.org [mailto:mmusic-boun...@ietf.org] On Behalf Of Harald Alvestrand Sent: 10 March 2013 15:07 To: Randall Gellens Cc: Ari Keranen; ietf@ietf.org; Alexey Melnikov; Gunnar Hellstrom; DRAGE, Keith (Keith); Peter Saint-Andre; ietf-languages-boun...@alvestrand.no; Flemming Andreasen; Hannes (NSN - FI/Espoo) Tschofenig; Peter Saint-Andre; Brian Rosen; mmu...@ietf.org Subject: Re: [MMUSIC] Update on Orlando time for human language draft discussion Sorry for barging in late on this thread, but quick questions: - what's the right mailing list to post to on this one? - have everyone read RFC 3282 (the standalone accept-language spec)? Seems to me the desired semantic is more accept-language than content-language. On 03/10/2013 03:38 PM, Randall Gellens wrote: Hi Everyone, Thursday lunch (11:30-1:00) it is. I'll make a reservation at The Tropicale (the cafe in the Caribe Royal hotel attached to the convention center). Please let me know if you can make it so I can make sure we have a large enough table. Thank you. Hi everyone, It looks like Thursday lunch (11:30-1:00) works well for everyone who has responded so far. Let's plan on that for now. At 9:35 AM -0700 3/9/13, Peter Saint-Andre wrote: It looks like Thursday lunch would work well. On 3/5/13 4:47 AM, Randall Gellens wrote: Hi all, I created a Doodle poll to see if we can find a time in Orlando to meet face to face. Doodle poll for time at Orlando to discuss open issues and moving forward with Human Language Negotiation: http://doodle.com/uwedikez6etwsf39 Link to current version (-02) of draft: http://www.ietf.org/internet-drafts/draft-gellens-negotiating-human- language-02.txt -- Randall Gellens Opinions are personal;facts are suspect;I speak for myself only -- Randomly selected tag: --- A child of five would understand this. Send somebody to fetch a child of five.--Groucho Marx, Duck Soup ___ mmusic mailing list mmu...@ietf.org https://www.ietf.org/mailman/listinfo/mmusic
Re: [MMUSIC] Update on Orlando time for human language draft discussion
Sorry for barging in late on this thread, but quick questions: - what's the right mailing list to post to on this one? - have everyone read RFC 3282 (the standalone accept-language spec)? Seems to me the desired semantic is more accept-language than content-language. On 03/10/2013 03:38 PM, Randall Gellens wrote: Hi Everyone, Thursday lunch (11:30-1:00) it is. I'll make a reservation at The Tropicale (the cafe in the Caribe Royal hotel attached to the convention center). Please let me know if you can make it so I can make sure we have a large enough table. Thank you. Hi everyone, It looks like Thursday lunch (11:30-1:00) works well for everyone who has responded so far. Let's plan on that for now. At 9:35 AM -0700 3/9/13, Peter Saint-Andre wrote: It looks like Thursday lunch would work well. On 3/5/13 4:47 AM, Randall Gellens wrote: Hi all, I created a Doodle poll to see if we can find a time in Orlando to meet face to face. Doodle poll for time at Orlando to discuss open issues and moving forward with Human Language Negotiation: http://doodle.com/uwedikez6etwsf39 Link to current version (-02) of draft: http://www.ietf.org/internet-drafts/draft-gellens-negotiating-human-language-02.txt -- Randall Gellens Opinions are personal;facts are suspect;I speak for myself only -- Randomly selected tag: --- A child of five would understand this. Send somebody to fetch a child of five.--Groucho Marx, Duck Soup
Re: Revised Draft IESG Statement on Removal of an Internet-Draft from the IETF Web Site
I like this. Nit: There's a missing to in the last line.
Re: Last Call: draft-hoffman-tao-as-web-page-02.txt (Publishing the Tao of the IETF as a Web Page) to Informational RFC
On 06/15/2012 11:27 PM, Paul Hoffman wrote: On Jun 15, 2012, at 2:03 PM, Peter Saint-Andre wrote: One possible oversight is that this I-D does not describe how the editor will work on the tao-possible-revision.html file (e.g., will only the editor have permissions to work on that, might there be multiple committers, will it be under source control?). Are such details intentionally out of scope? I would imagine that that would be determined by the IESG when they pick a Tao editor. Adhering to the principles of oversight rather than control, I would imagine that the IESG would tell the editor to use his best judgment, and if they don't like his judgment, they'll replace him. But then I'm an optimist :-) ObDraftComment: I support the draft. ObMinorTweak: I think the URL structure for the dated versions is not the best one, because it requires all Tao versions to be in the root namespace of the IETF web service. I would prefer that they be named www.ietf.org/tao/archive/-MM-DD.html, which would also give rise to a presumption that one could list all versions by going to www.ietf.org/tao/archive. I'd even support the reference to the archive being in the Tao itself, making another layer of indirection possible. But the ability to say the Tao said THIS on Feb 16, 2013 is important. Yours for more nits in the Last Call process :-) Harald
Re: New Non-WG Mailing List: IETF-822
On 06/15/2012 08:46 AM, Yoav Nir wrote: On Jun 15, 2012, at 12:44 AM, Peter Saint-Andre wrote: On 6/14/12 3:37 PM, IETF Secretariat wrote: List address: ietf-...@ietf.org Is no one thinking ahead to the 822nd meeting of the IETF in the year 2258?!? Well, I've started working on draft-nir-ipv6-were-finally-deploying-it but I'm not sure what format would be an appropriate submission format in the 23rd century. ASCII, of course. But the boilerplate will have changed. Doesn't it coincide with the 1st season of Babylon 5? Yoav
Re: Is the IETF aging?
On 04/27/2012 04:41 PM, Yoav Nir wrote: Hi Phil After each meeting, Ray sends out a survey to all participants. The results from the latest one: When were you born? Before 19502.9% 1950 - 1960 16.6% 1961 - 1970 33.7% 1971 - 1980 32.8% After 198014.0% The greybeards talk more. Especially in plenaries.
Re: Second Last Call: draft-ietf-sieve-notify-sip-message-08.txt (Sieve Notifica tion Mechanism: SIP MESSAGE) to Proposed Standard
John, a worry I have with going out with such a massive demand set for this IPR code violation is that we'd be encouraging the other IPR behaviour we've seen: That of saying nothing. The current Huawei people who caused this disclosure to be filed deserve our praise for doing the Right Thing now, even while the people in the past who did not deserve our condemnation. On one point, however, I'm aligned: On 01/26/2012 10:31 AM, John C Klensin wrote: (3) A request to the company involved to remove the reciprocity clause from the license stated in the disclosure statement. As a show of good faith, they should agree to derive no benefit from the patent other than what praise accrues from having it awarded. Indeed, this reciprocity clause is of the form that I used to complain to Cisco's IPR lawyer about Cisco making when I was at Cisco: It asserts the right of withdrawal of this license for *any* use of *any* patent against Huawei - that means that anyone who dares to depend on this license is effectively granting a license to *all* their patents to the holder of this patent. The proper scope of reciprocity clauses is a fertile ground for debate (and nearly impossible to hold a debate on, unfortunately), but this type is one that I am not happy to see. Harald ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Consensus Call: draft-weil-shared-transition-space-request
On 11/29/2011 05:47 PM, Paul Hoffman wrote: On Nov 29, 2011, at 7:57 AM, Russ Housley wrote: +1 On Nov 29, 2011, at 10:51 AM, Bradner, Scott wrote: to be pedantic - a BCP stands for the best way we know how to do something it is not required that the process actually be in use before the BCP is adopted as Mike O'Dell once said, if BCPs had to reflect what was actually being done we could never have a BCP defining good manners on the IETF mailing list see RFC 2026 - it says The BCP subseries of the RFC series is designed to be a way to standardize practices and the results of community deliberations. A BCP document is subject to the same basic set of procedures as standards track documents and thus is a vehicle by which the IETF community can define and ratify the community's best current thinking on a statement of principle or on what is believed to be the best way to perform some operations or IETF process function. i.e, the IETF's best current thinking on the best way to do something - not 'describing the way something is done' You stopped the excerpt from 2026 too soon on both ends; the community's best current thinking on a statement of principle. Ron already said that the community didn't agree on a clear best current thinking, and the document very clearly says that this is meant to be a new allocation of addresses, not a statement of principle. If the IESG wants to weasel around the actual words in RFC 2026, that's fine: this wouldn't be the first time. However, there is also an opportunity to be more honest and call it a Proposed Standard. I believe Russ was reading the words on what is believed to be the best way to perform some operations FWIW, given that the IAB has chosen to not uphold the principle of subsidiarity and let this thing be done at the lowest possible level in the decision hierarchy, I hold with the people who argue that allocating this /10 is less harmful than not allocating it. best in this case being synonymous with least bad, not synonymous with good. Harald ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: RFC 3951 source code usage situation just got murkier
We're working on an updated IPR statement. We had it on our list of things that need doing, but until now, it didn't seem the most urgent thing in the world. Harald (for once speaking for Google). On 09/07/11 17:18, Kevin P. Fleming wrote: RFC 3951 is the specification of iLBC, and includes the reference implementation in C source code. This is distributed by the IETF under its normal license terms (BSD-style). However, the creators of the codec claimed to have patents that would be infringed by distribution/usage of that code (and made appropriate IPR disclosures to the IETF), and they offered a free patent non-assert license via the 'ilbcfreeware.org' web site. Many people have been taking advantage of this license for years now, in order to ensure they could safely use the code from RFC 3951. After Google's acquisition of GIPS, the situation has changed. There is a new implementation of iLBC on the WebRTC site, under a different license, with an explicit patent grant. However, that patent grant applies *only* to the WebRTC implementation, not the implementation in RFC 3951. The previous license mechanism on 'ilbcfreeware.org' has been removed and is no longer available. This leaves the community in the unfortunate situation of having an RFC that contains a reference implementation, which has had IPR disclosures made against it, but for which no free licensing terms are available (even though they were in the past). ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Expiring a publication - especially standards track documents which are abandoned
On 09/04/11 20:39, Eric Burger wrote: Why? No one has cared about the annual review from 2026. No one has time to do the bookkeeping and spend the effort to evaluate stuck documents. If there is an RFC that is harmful, then one can always ask to have it moved to Historic. On Sep 4, 2011, at 10:23 AM, todd glassey wrote: There are any number of IETF RFC's which were published and then accepted in the community under the proviso 'that they would become IETF standards' which in many instances they do not. Further many of them are abandoned in an uncompleted mode as standards efforts. To that end I would like to propose the idea that any IETF RFC which is submitted to the Standards Track which has sat unchanged in a NON-STANDARD status for more than 3 years is struck down and removed formally from the Standards Track because of failure to perform on the continued commitment to evolve those standards. In all cases I'm aware of where promises have been made based on the eventual status of the document (such as in certain IPR disclosures), the community has accepted that a Proposed Standard is a standard status. I refer the community to the thread on -twolevel for all the other stock arguments on the issue. Why this is necessary is that the IETF has become a tool of companies which are trying to get specific IETF approval for their wares and protocols - whether they are open in form or not. The IETF entered into a contract with these people to establish their standard and published those documents on the standards track so that they would be completed. Since they have not been completed as IETF Standards the Project Managers for those submissions have formally breached their contract to complete that process with both their WG members who vetted those works as well as the rest of the IETF's relying parties. As such it is reasonable to put a BURN DATE on any Standards Track effort which has stalled or stopped dead in its tracks for years. Todd Glassey -- Todd S. Glassey This is from my personal email account and any materials from this account come with personal disclaimers. Further I OPT OUT of any and all commercial emailings. ___ 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: Another look at 6to4 (and other IPv6 transition issues)
On 07/20/11 01:24, Sabahattin Gucukoglu wrote: On 20 Jul 2011, at 00:34, Doug Barton wrote: On 07/19/2011 14:01, Sabahattin Gucukoglu wrote: Clearly, the view that making something historic when it's in active use is offensive. No standards body could seek to stand behind their specifications, or to give the impression of doing so, with such a position. Define active use. Actively being used. In production. So that taking it away would hurt the entity using it, threaten the entity's comfort and convenience, or just generally go against the stated goals of making the Internet a better place for everybody through the instrumentation and maintenance of standards. The idea that moving a standard to Historic would take away the ability of people to use it reminds me of the story from the Norwegian army, approx 1939: - If the enemy invades, how will you prevent them from using the train network? - Burn all the tickets, sir! ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Review of draft-doria-gen-art-08
I support the publication of this document. In general, the document is clearly written, explains the processes followed for gen-Art review, and forms a valuable snapshot of the procedures followed at this time. It makes it very clear that the document does not, in any way, shape or form, attempt to modify the rules for IETF work. One point that I can't see clearly stated (I may have missed it) is that both the reviews and the names of the reviewers are public. This may seem obvious now, but wasn't obvious when the process got started; I think it is important to call this out. Nits: - Section 4.3 links to I-D.rfc-editor-rfc2223bis - this draft expired in 2008. New target needed. - In the same bulleted list, the last bullet should either be a non-bullet or have As well as removed from its beginning. - In section 4.4, a note should be made about groups of I-Ds. I think the process is that when a document set is Last Called as a set, one reviewer handles it if possible - but I am not sure about this. - Section 6 claims that the quality of I-Ds has increased, but gives only a single data point (2007). Is there a second datapoint that is missing somehow? Thanks for doing this! Harald ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Confidentiality notices on email messages
On 07/20/11 09:22, Nathaniel Borenstein wrote:
Except that the other Content-disposition values express the sender's intent,
whereas this one expresses the receiver's [likely] perception.
In this case, we have to invent a cute backronym for it that expresses
the sender's intent what about Not Optional {Ignorable,Irritating}
Suit-avoiding Exposition?
It might as well be Content-disposition: discard -- no sender would ever
generate it. In contrast one could make at least a semi-serious case that by defining a
media type for legal disclaimers, you could have UA's that by default hid it but didn't
throw it away, so that you could see it later if for some inconceivable reason you wanted
to. (And the issue of including different media types could be addressed by making it
multipart/noise.)
On the other hand, if Ned and I disagree that's itself an indication that this
is not a very serious discussion. :-) -- Nathaniel
We can always find a point of agreement - in this case on the
seriousness of the discussion!
On Jul 19, 2011, at 4:16 PM, ned+i...@mauve.mrochek.com wrote:
Content-disposition: noise.
Harald, I was about to say the same thing but you beat me to it. Unless we're
prepared to talk about defining a general format for such notices (and I'm
pretty sure we're not interested in doing that), this doesn't fit as a media
type - I can easily envision using various different types depending on the
sort of notice I want to send.
But a content-disposition value has the right semantics and makes all sorts
of sense.
Ned
___
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: Review of draft-yevstifeyev-ion-report-06
On 07/16/11 06:12, Mykyta Yevstifeyev wrote: Hello Harald, As you could see in one of my previous messages, I did intend to include some analysis in the draft (http://www.ietf.org/mail-archive/web/ietf/current/msg67491.html). However, numerous responses which discouraged me from doing this were received, and including that section will create problems with consensus. I saw the messages. It is very hard to write an analysis on behalf of someone else - to my mind, the analysis of why the IESG decided what they did has to be based on information from the IESG; it's impossible for any outsider, including you and me, to divine what their thought processes on this matter were. There's no IETF consensus to be documented here; the analysis and decision was done by the IESG, and the IESG (as it was composed at that time) is the body from which the information has to come. All any outsider (like you and me) can do is to help with the editing. However, I share your opinion that the document won't be full, so I think the following analysis section, which is different from the previous proposed one, can satisfy you and everybody else: Now, if someone were to speak for the then-present IESG and say the same thing, I would make the following comments: 3.4. Analysis There were a number of reasons which forced IESG to close the IONs experiment. Nit: forced IESG - caused the IESG to decide. There's no forcing function. One of them is a complexity of their approval and publication, compared with ones for IESG Statements and simple Web Pages. As IONs were intended to represent operational experience, they might have needed to be updated quickly. Even though these documents were meant to have a very lightweight approval procedure, it could sometimes be inappropriate for that material which was contained therein. In a protocol, I'd ask for a definition of quickly. Days, weeks or months? Examples of documents where days is the correct timescale? Secondly, due to the nature of the scope of IONs, there was no need to allow the access to the revision history (which is unavailable in simple Web Pages as well). I disagree with this statement, obviously. If the IESG thought so, it is correct to include it. Thirdly, IONs on procedural question could step into the conflict with Best Current Practice (BCP) RFCs; moreover, as IONs approval procedure did not imply any formal community review, unlike BCPs, they could easily fall in the community non-acceptance. I believe this is a red herring. However, I can fully believe that the argument was raised, even though I don't believe it, so if the IESG indeed thought that, I'm fine with having that documented. Correspondingly, it was concluded that the mandate of IONs can fully be fulfilled by RFCs, when documenting IETF procedures, IESG Statements, when clearing up other issues for which RFC publication process is not appropriate, and Web Pages, when dealing with other IETF-related issues. Nit: it was concluded - the IESG concluded. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Confidentiality notices on email messages
Content-disposition: noise. On 07/16/11 09:15, Nathaniel Borenstein wrote: Notice Of Intentions in Sending Email? On Jul 16, 2011, at 1:09 AM, Murray S. Kucherawy wrote: -Original Message- From: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On Behalf Of John C Klensin Sent: Thursday, July 14, 2011 11:39 AM To: Randall Gellens; Marc Petit-Huguenin Cc: IETF discussion list Subject: Re: Confidentiality notices on email messages If one starts down that path, there is a real possibility for a semantically-rich environment. For example, consider a noise type for flaming, repetitive, responses to a topic on the IETF list. One could also very efficiently reflect what I assume was the intent of a recent observation on the list with noise-type=hitler :-( The trick though, alas, is to get people using such disclaimers to begin using such a media type. Maybe we need an attractive acronym for NOISE as a decoy. ___ 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
Review of draft-yevstifeyev-ion-report-06
My apologies for the lateness of this review. I am not happy with this document. I was unhappy with the IESG's decision to close the ION experiment, since I believe the mechanisms that were chosen to replace it failed to fulfil several of the requirements that were driving forces in the design of the ION mechanism (as an example, try to find out who, if anyone, approved http://iaoc.ietf.org/network_requirements.html, what the previous version was, and when this version was approved). The document does not refer back to the aims of the experiment, which I tried to make explicit in section 5 of RFC 4693, which include: - Easy updating - Explicit approval - Accessible history The sum total of analysis in this document is two sentences: The cited IESG statement It is clear that the IESG, IAB, and IAOC need the ability to publish documents that do not expire and are easily updated. Information published as web pages, including IESG Statements, are sufficient for this purpose. The draft's statement Taking everything into account, it was considered that IONs added complications to the maintenance of documents but did not give a corresponding benefit to the IETF. I would at least expect those three points to be explicitly addressed by analysis, such as: - The IESG concluded that publication of IONs was more complex than publishing Web pages and IESG statements - The IESG concluded that the IESG statement mechanism, which has no formal definition, was enough documentation of the IESG's decisions where decision documentation was reasonable, and that Web pages needed no explicit approval - The IESG concluded that there was no need to provide an accessible history of versions of the documents for which the ION mechanism was intended The document also needs a language check, but I feel that the lack of *any* explicit analysis with respect to the aims of the experiment, even an explicit statement that the issues involved were considered not important, is the most important shortcoming of the document. Harald ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: How to pay $47 for a copy of RFC 793
On 05/09/11 19:53, Marshall Eubanks wrote: On May 9, 2011, at 6:51 AM, Eric Burger wrote: Agreeing with John here re: it's just a bug. IEEE Xplore regularly does deals (read: free) to add publishers to the digital library. It is part of the network effect from their perspective: if you are more likely to get a hit using their service, you are more likely to use the service. We (RFC Editor? IAOC? Me as an individual?) can approach IEEE to add the RFC series to Xplore. Or the IETF Trust could do this, as it falls squarely within the purpose of the Trust. soapbox The Trust should not do. The Trust should set policy, and observe that the Right Thing Happens. /soapbox In the case of Google Scholar, I found the guidelines to be a bit intimidating: http://scholar.google.com/intl/en/scholar/inclusion.html but not something that would be hard for the RFC publisher to set up in a few hours based on the PDF form of the RFCs and the rfc-index.xml file. FWIW: The RFC series does have an ISSN. Harald ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Google Scholar, was How to pay $47 for a copy of RFC 793
On 05/10/11 17:28, John Levine wrote: In the case of Google Scholar, I found the guidelines to be a bit intimidating: http://scholar.google.com/intl/en/scholar/inclusion.html but not something that would be hard for the RFC publisher to set up in a few hours based on the PDF form of the RFCs and the rfc-index.xml file. Actually, now that I look at their guidelines, I'm sort of surprised that they're not in Scholar. They say they'll index HTML versions of documents so long as they have meta tags that have the title, author, and other bibliographic info and it has references it can crawl to do cross links to other documents. The HTML versions in tools.ietf.org/html look to me like they have the right tags. The problem may be that the meta tags are missing some minor item, that it can't recognize the references sections, which should be a matter of tweaking the HTML a little bit, or maybe that there isn't a TOC page that lets it recognize all the RFCs as a collection. Whatever it is, it doesn't look like it'd be hard for someone with sufficient spare time to fix. For some reason, scholar has indexed 151 docs from tools.ietf.org and then stopped. http://scholar.google.com/scholar?hl=enq=site%3Atools.ietf.orgbtnG=Searchas_sdt=0%2C5as_ylo=as_vis=0 http://scholar.google.com/scholar?hl=enq=site%3Atools.ietf.orgbtnG=Searchas_sdt=0%2C5as_ylo=as_vis=0 R's, John ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Google Scholar, was How to pay $47 for a copy of RFC 793
On 05/10/2011 10:08 PM, John C Klensin wrote: --On Tuesday, May 10, 2011 20:22 +0200 Harald Alvestrand har...@alvestrand.no wrote: If only there was someone who worked at Google on this list who could send an internal message to get this rectified :-) From what I could tell from the instructions, Scholar is using some heuristics to figure out that this is a paper and this is not a paper. The highest one on the list was a 3-slide presentation that really didn't say very much - I think this is one where heuristics had failed. I think someone at the site could help them a lot more. Harald, I'm not sure what you mean by someone at the site. Certainly, various of us could explain to them why the series should be more comprehensibly indexed. But with Maps as a notable exception, I've found that suggesting that a particular heuristic is failing, or that something should have been indexed that isn't, is most likely to get a response whose essence is the Google folks and their algorithms are ever so much smarter then us lusers, so what could we possibly know? The instructions at Scholar were pretty comprehensive and specific: - Make either your abstracts or your documents into HTML - Put a very specific selection of tags into your documents - Report your collection to the Scholar robot We can either ignore this particular set of instructions, and get the result that the heuristics generate, or follow this set of instructions, and hope for a better result. My point (if I have any) is that those instructions should be easy to follow for the people who control these sites, but are not so easy for anyone else (unless they want to act as if they are an official mirror). That puts the ball in the RFC publisher's court. Of course, my personal heuristic, and that of many folks I know who use Scholar much more intensely than I do, is that if a Scholar search fails or produces nonsense, I go to the general-purpose search engine. For RFCs, it tends to do very well, both at finding the right stuff and at ranking the RFC text itself near the top. So, other than being lazy about not doing the second search, pedantic about what Scholar should be indexing and how, or demanding and expecting a more perfect universe, I'm not sure I see a real problem in this. john ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Call for a Jasmine Revolution in the IETF: Privacy, Integrity, Obscurity
Actually, this discussion has been going on for longer than so-far referenced docs show. One of my favourite RFCs on the subject: RFC 2804 IETF Policy on Wiretapping. IAB, IESG. May 2000. The Internet Engineering Task Force (IETF) has been asked to take a position on the inclusion into IETF standards-track documents of functionality designed to facilitate wiretapping. This memo explains what the IETF thinks the question means, why its answer is no, and what that answer means. On 03/06/11 21:52, Dean Willis wrote: Marc suggested: I any case, may I suggest a Bar BOF in Prague? Plotting revolutions in coffeehouses is a very old tradition. Excellent idea. Perhaps this should be plotted over jasmine tea instead of coffee... The point I really want to stress is that we must stop deliberately designing privacy, integrity, and obscurity weakness into our protocols, and where we can't avoid weakness we should at least consider its implications. We have a real lack of understanding of these issues in the community. For example, if Alice and Bob have a communications session, IETF has never clued onto the fact that Alice and Bob might want intermediary Charlie not jut to be unable to read the data of their session, but to not even be able to know that they have one. We might not be able to hide the fact that Alice has a session with SOMEBODY from her next-door neighbor Allen, or the fact that Bob has a session from his next-door neighbor Burt, but even if Allen and Burt are working together, we should be able to hide the Alice-Bob relationship. What do I mean by not designing weakness into our protocols? I give you SIP, for example. After twelve years of work, I have yet to make a real call using the optional sips signaling model. Why? It's optional. Nobody uses it. Actually, I'm having a hard time using even basic SIP any more -- it looks like Google just pulled-the-plug on my telephony ISP service, which had been provided by the Gizmo Project. But that's another problem. -- Dean ___ 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: IETF Plenary Discussions
Olaf Kolkman wrote: During previous technical sessions I mailed an announcement about the technical plenary and in those announcements I've asked something along the lines of: If you consider asking a question during the open-microphone session it would be helpful to send that question to the IABi...@iab.org in advance. In that way we may be able to think about the problem and answer your question effectively. Note that sending in a question is _not_ a requirement for asking one. I believe that submitting questions in advance will help to get concise questions asked (because some thought went into phrasing them) and get pointed answers (because some thought went into answering them). In fact the questions may be shared by the larger group and not just the individual opinions of the folk that are happen to be on stage. Perhaps we should look into http://moderator.appspot.com/ ? FWIW, in the sessions I had asked this questions nobody walked up during the microphone. I just forgot to add the paragraph in this weeks announcement. --Olaf Olaf M. KolkmanNLnet Labs Science Park 140, http://www.nlnetlabs.nl/ 1098 XG Amsterdam ___ 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: [rfc-i] path forward with RFC 3932bis
Aaron Falk wrote: Jari- The draft says: The RFC Editor reviews Independent Submission Stream submissions for suitability for publication as RFCs. As described in RFC 4846 [I3], the RFC Editor asks the IESG to review the documents for conflicts with the IETF standards process or work done in the IETF community. Similarly, documents intended for publication as part of the IRTF Stream are sent to the IESG for review for conflicts with the IETF standards process or work done in the IETF community [I2]. I'm concerned about the phrase or work done in the IETF community. Unbound it can cover much, much more than IETF standards work. In fact, one could make the case that it covers the IRTF (since much IRTF work is done in the standards community. I don't believe IESG review should cover conflicts in the IRTF (or IAB or IETF Trust or ISOC or with other Independent Submissions authors...) The IESG's authority in this paragraphs derives from RFC2026 which is pretty clear: To ensure that the non-standards track Experimental and Informational designations are not misused to circumvent the Internet Standards Process, the IESG and the RFC Editor have agreed that the RFC Editor will refer to the IESG any document submitted for Experimental or Informational publication which, in the opinion of the RFC Editor, may be related to work being done, or expected to be done, within the IETF community. I'd like to see the phrase in question removed or perhaps clarified (say to include planned standards work or some such). That phrase was also present in RFC 3932, and, as you note, in RFC 2026. I'm concerned that in our eagerness to make the perfect document, we might be making too many changes, especially at what's hopefully a late stage in the process of getting that revised. If I remember rightly (but vaguely) from the writing of 3932, the phrase was kept that way because we didn't want to be unable to speak about a document just because the WG wasn't chartered yet, or the work was processed through independent submissions to the IESG, or any of the other multitude of ways work gets done in the IETF without invoking excessive procedural overhead. That said, the IESG notes in 3932 were tailored for conflict with WGs specifically - it was also the desire of the IESG-at-the-time that the note to the RFC Editor needed to *identify* the work it conflicted with, not just a vague there's work in this area. Harald Harald ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [Trustees] Objection to reworked para 6.d (Re: Rationale for Proposed TLP Revisions)
Robert Elz wrote: Date:Tue, 21 Jul 2009 18:40:52 +0200 From:Harald Alvestrand har...@alvestrand.no Message-ID: 4a65ef94.2050...@alvestrand.no | I'm afraid that your perception disagrees with the structure that RFC | 5378 set up. I was misunderstanding what's going on, Joel has been educating me off list... But while my reasoning changes slightly, my conclusion does not. | The Trust has enough rights to license code under a license | of its choice, and has currently chosen to use the BSD license. I think we can agree that the trust (the IETF) cannot give away more rights than it has obtained from the contributor (however much they are, and if that's everything related to copyright that's fine). I can think of no reason why the trust (IETF) should ever offer less than what the contributor has allowed - that would be entirely contrary to the purposes for which we need licences from the contributor in the first place - the aim is to make sure that the code is available with as few restrictions as possible, having the trust add restrictive licence terms would be counter productive (regardless of what those terms are). The working group's non-consensus on this point is documented in section 4.4 of RFC 5377: 4.4. Rights Granted for Use of Text from IETF Contributions There is no consensus at this time to permit the use of text from RFCs in contexts where the right to modify the text is required. The authors of IETF Contributions may be able and willing to grant such rights independently of the rights they have granted to the IETF by making the Contribution. If all that's reasonable, then it follows that licence in == licence out, and while it is possible that might be change from time to time, the change must be to the licence in first, and that then means that the licence out change affects only those RFCs published after the change, one earlier must still be on the old terms (if the change was broadening the licence to the IETF, then no earlier submission by anyone would be broader in the new way, and so the outgoing licence could not be the new broader form, if the change is to narrow the rights given to the IETF, that will necessarily narrow what the IETF can grant users of the code, but there's no reason it should restrict the rights granted under older submissions, that were published with a broader grant to the IETF. The RFC 5378 license to the trust allows, for instance, the Trust to grant the right of copying small snippets of code without attaching the full BSD license to them. The current TLP does not give that right. Incoming and outgoing rights for code are currently different. So, I remain fairly convinced that there's no need at all to ever make (or pretend to make) any change which would ever require updating all past RFCs, a change should only ever affect future publications. I'm fairly convinced that there will come a time when we need to relicense text that was previously licensed by the Trust in a way that is more liberal than the current text of the TLP allows for (while remaining within the scope of rights granted to the trust). That's why I yell so much on this matter. Harald ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [Trustees] Objection to reworked para 6.d (Re: Rationale for Proposed TLP Revisions)
Andrew Sullivan wrote: On Mon, Jul 20, 2009 at 02:56:01PM -0400, Joel M. Halpern wrote: Rather, what it does is the RfC says the code must include whatever license the trust document says. When the code is produced, that link is dereferenced, the license is determined, and the license is inserted in the code. Ok. So is the point then just not to have to issue a new RFC if the Trust decides they want a different license? I.e. is that the future-proofing that the proposed change is supposed to provide? If so, in light of the other comments people are making about how the Trust appears to be rather more activist than some people find congenial (I am reserving my opinion on that topic), I'm not sure the proposed change is a good one. If the Trust needed to change the license, there would be two reasons to do it, I think: 1. The community wants the change. 2. External forces (say, legal precedents) cause the currently-selected license to be the wrong one. But both of those cases seem to me to be the sort of thing that requires some community input and some rough consensus, no? If so, then what would be hard about writing a new RFC that captured this update, and publishing it the way of the usual RFC process? I agree completely that any licensing change needs solid community input and rough consensus (as well as being legal). That's entirely orthogonal to the binding time issue (I think). My worry is the logistics of executing the change. We have two possibilities: 1 - the update consists of revisions of *every single RFC* that references the BSD license 2 - some RFCs continue to carry the BSD license, even while the real current license is different. 1 seems like a logistical nightmare. 2 seems confusing to me. Harald ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [Trustees] Objection to reworked para 6.d (Re: Rationale for Proposed TLP Revisions)
Andrew Sullivan wrote: On Tue, Jul 21, 2009 at 08:57:01AM +0200, Harald Alvestrand wrote: We have two possibilities: 1 - the update consists of revisions of *every single RFC* that references the BSD license 2 - some RFCs continue to carry the BSD license, even while the real current license is different. 1 seems like a logistical nightmare. 2 seems confusing to me. Ok, this is what I was trying to understand. What you are proposing is that the licence on the code in the RFC can change restrospectively, by virtue of the Trust changing the licence they select. This scenario is exactly what inspired my first question, then. Imagine I have a product, and it is shipping. It has code taken from an RFC. The original RFC was published when the Trust used the BSD licence. Therefore, as far as I know, the code I used is under BSD licence. Suppose now that the Trust now changes the licence they use to the GPL. (I know, I know, this won't happen, c. But there's nothing to prevent it, as far as I can tell, except community consensus. I don't know what that might be in the future.) If I understand what you want, I think there are four possibilities: a. The product I have already shipped is now suddenly covered by the GPL. It may be in violation of the licence therefore. b. The prodict I have already shipped does not change, but products I ship after the Trust changes policy are covered under the new rules. So my shipped product is BSD, and my unshipped stuff is suddenly GPL (possibly forcing me to change my product, or its licence). c. The code I used remains under the BSD because of the date I used it, but new uses of that code are under GPL (so my competitors would have to have a different licence, or version 2 of my product might have to have a different licence). I think this is the version that applies, with one difference that matters. Under the BSD license, you can ALSO give copies of the copy you took from the RFC to anyone at any time, and they will have the right of modification, but not the right to publish the code without the BSD license text - that is, the BSD license is a sublicenseable license. Effectively, the code will be available under all licenses that the Trust has ever licensed stuff under between the time of publication and the present time; if a more restrictive license is used (perish the thought!), you have the right to fork the code, and distribute the forked code under the BSD license in perpetuity. d. The date the RFC was published binds the licence, so that the terms on the code embedded in the RFC change. This is equivalent to your option (2), I think, and you say its undesirable. I argue that compared to (a-c), (d) is a big win. If (d) is right, however, your option (1) isn't a problem: the RFCs that are already published don't need a new licence in them, because they stick to the old one. Therefore, the new text only gives the Trust a way around getting a new RFC published with the new licence explicitly selected by community consensus. I don't see the reason to provide that short cut. If, however, you think (a-c) are preferable, then your proposed change makes sense. If I were building a product, however, I would be very wary of using any code whose licence might change after I've shipped my code. See above. But as usual, IANAL, I just have opinions. Harald ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [Trustees] Objection to reworked para 6.d (Re: Rationale for Proposed TLP Revisions)
Robert Elz wrote: Date:Tue, 21 Jul 2009 08:57:01 +0200 From:Harald Alvestrand har...@alvestrand.no Message-ID: 4a6566bd.1080...@alvestrand.no | We have two possibilities: | | 1 - the update consists of revisions of *every single RFC* that | references the BSD license | 2 - some RFCs continue to carry the BSD license, even while the real | current license is different. Harald, what you're anticipating there is absurd, if an RFC gets issued containing code with the BSD licence, then that is the licence that code, in that RFC will have forevermore, nothing can change that - and nothing should change that, nothng the trustees or community can do can ever change that - only the rights holder (author) of the code can cause it to be offered with some different licence.Any system where it even looked as if it were possible for anyone to simply alter the licence under which code that had previously been published became available would be a disaster. Robert, I'm afraid that your perception disagrees with the structure that RFC 5378 set up. The Trust has enough rights to license code under a license of its choice, and has currently chosen to use the BSD license. The authors may *in addition* license the code under the BSD license, the GPL license, or any other license they feel like using, and there's no way the Trust can stop them from doing that. But neither can the authors restrict the Trust's ability to license the code. It may be a disaster, but it's been in that state since November 2008. Harald ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Objection to reworked para 6.d (Re: Rationale for Proposed TLP Revisions)
Apologies for this being a month late. From the rationale: 4.e -- this new section clarifies the legend requirements for Code Components that are used in software under the BSD License. In short, the user must include the full BSD License text or a shorter pointer to it (which is set forth in Section 6.d) Explanation: The issue of the appropriate BSD License language to include in Code Components extracted from IETF documents has been discussed extensively within the IESG. The proposed TLP language is intended to be consistent with the IESG's latest guidance language, and allows the user of IETF Code to include either the full BSD license language (about 15 lines of text), or a short pointer to the BSD language (about 4 lines). 6.b -- a new sentence has been added to the legend that must be placed on all IETF Documents, pointing out the BSD License requirements described in 4.e above and emphasizing that code in IETF Documents comes without any warranty, as described in the BSD License. Explanation: See 4.e above The text added, which is intended to be placed on all IETF documents (internet-drafts and RFCs), is: Code Components extracted from this document must include BSD License text as described in Section 4.e of the TLP and are provided without warranty as described in the BSD License. I object to this change. The reason is this: - The RFCs are intended to be permanent (as in forever). - The purpose of the incoming/outgoing split was to make sure the Trust had the tools it needed to fix any errors made, or to respond to changed circumstances, by changing the rights granted under outgoing. - The BSD license is a specific license text, and there is no guarantee that there won't be new circumstances that warrant generic licensing under a different license in the future. Thus, this change limits the ability of the Trust to respond to future changes; if it ever decides (as an example) to use the Apache License instead of the BSD license because some court has found the BSD text to be objectionable in some manner, this will lead to all documents published with this text to be misleading. (As an example of changed circumstances - the Wikimedia Foundation just changed its licensing terms from GPL to a Creative Commons license - this required some fancy footwork to make it seem legal, even though a large majority of contributors agreed that it was the right thing to do. I don't want to see that kind of trouble in the IETF.) If the text added instead read: Code Components extracted from this document must include license text as described in the TLP and are provided without warranty as described in the TLP license provisions I would have no objection. This preserves the Trust's ability to change provisions. Harald Alvestrand ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [rfc-i] Objection to reworked para 6.d (Re: Rationale for Proposed TLP Revisions)
Julian Reschke wrote: Harald Alvestrand wrote: ... Hi, I'm trying to understand whether this change affects me. So... 1) Many specs I'm editor of contain ABNF. Does it need to be labeled as code component (I believe not). In my understanding, all ABNF is code by definition (included in the Trust's list of things considered code), so no. 2) These specs also collect all ABNF fragments into an appendix, containing the collected ABNF. Does that appendix need to contain the BSD license text (I believe not, but heard from colleagues that their docs are blocked because they do not). I believe it would be silly to make it contain the BSD license. Some people on the IESG seem to think that the IESG has made such a statement; one of my WGs has a couple of documents that are blocked until this is resolved. 3) If I *extract* ABNF from these documents (such as for the purpose of generating an input file for an ABNF parser), do I need to include the BSD license text? If so, can somebody explain how to do that given the constraints of the ABNF syntax? ; is a fine character. A block of comment should be fine. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [rfc-i] Objection to reworked para 6.d (Re: Rationale for Proposed TLP Revisions)
John C Klensin wrote: --On Monday, July 20, 2009 14:20 +0200 Julian Reschke julian.resc...@gmx.de wrote: Julian Reschke wrote: ... 3) If I *extract* ABNF from these documents (such as for the purpose of generating an input file for an ABNF parser), do I need to include the BSD license text? If so, can somebody explain how to do that given the constraints of the ABNF syntax? ... Explanation: for some reason I thought that the ABNF syntax only allows comments that are attached to an ABNF rule; but it appears that I was confused. Independent of that, considering any sequence of ABNF statements as necessarily code goes far beyond the intent of the IPR WG as I, at least, understood it. If you, as author, want to identify it as code, that is your perogative, but this is about copyright and not patents and, at least IMO, metalanguage, metasyntax, pseudo-code, etc., are not intrinsically code in the sense that the WG discussed and intended it. ABNF was specifically used as an example of code in the WG discussions. RFC 5377 section 4.3: IETF Contributions often include components intended to be directly processed by a computer. Examples of these include ABNF definitions, XML Schemas, XML DTDs, XML RelaxNG definitions, tables of values, MIBs, ASN.1, and classical programming code. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: More liberal draft formatting standards required
Phillip Hallam-Baker wrote: I remain heartily fed up that the HTML versions of documents that I know were submitted with XML source are not available, nor is the XML source. The TXT versions do not print on my printer and have not printed reliably on any printer I have ever owned. just an aside: the way I've found that works reliably these days for printing I-Ds and RFCs is to load them into OpenOffice's editor (oowriter) and use print from there. Somehow, OpenOffice managed to understand the formfeed character. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Voting (Re: Publicizing IETF nominee lists)
Voting has all kinds of issues. I like the current Nomcom process because it depends on 2 things: - A pool of qualified volunteers - Luck in picking a nomcom that behaves sensibly (for whatever that means to you) Given that luck is involved, many of the possible attacks that people could mount in order to gain more IETF influence won't happen - simply because they have a significant chance of failure. Trying, failing, and being detected as having tried, would be harmful to the group that tried it. Besides, knowing that the IETF fundamentally depends on luck gives me a good feeling when the pomposity gets too overwhelming :-) Phillip Hallam-Baker wrote: This is a useful and necessary change. A more useful change would be to abolish NOMCON and for those currently qualified to sit on NOMCON to elect the IAB and ADs directly. Direct elections provide accountability and authority. Today we have an Internet Architecture Board that stopped trying to do architecture after the Kobe revolt. That is a problem because the architecture is not a static property, without direction it degrades over time. Instead of the outcome of proposals to change the standards process being 'the IESG didn't like them', we the broader membership[*] of the IETF can demand reasons and persons. And we can kick out the people who are being obstacles to change or proposing changes we disagree with. Direct elections allow for contrarian views to enter into the discussions. The priority of successive NOMCONs has been to ensure that the members of the IAB get along and to keep out anyone who might rock the boat. As a result the only members of the awkward squad who get appointed are the ones who are committed to defending the status quo at all costs, not the people who point out what is not working. Yes, there is a risk of factions, but not a very large one. I am a member of the Oxford Union society and I know quite a bit about that type of politics. A Cisco or a Microsoft faction would be entirely counter-productive for the companies involved who come to the IETF to build industry support for adoption of their proposals and to be part of the consensus that emerges. The only type of faction that could be sustained long-term would be one committed to a particular technical principle such as preventing wiretap-friendly protocols or copyright enforcement schemes and only then if there was a sizable counter-faction or some group idiot enough to try to do that type of thing in IETF. We should try democracy. It is an old idea, seems to work. [*] Yes, we should demand consideration as citizens, not serfs. The pretense that the IETF has no members is very convenient for those appointed, not so great for the rest of us. On Wed, Jun 10, 2009 at 10:11 AM, Sam Hartmanhartmans-i...@mit.edu wrote: Thanks for bringing this to our attention. Having reviewed the draft, I support publication of this document as a BCP. I think it is a long-needed change. I understand that there are important tradeoffs involved, and while I acknowledge that there are disadvantages to this change, I think that it is a significant net good. ___ 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: Fw: Last Call: draft-dawkins-nomcom-openlist (Nominating Committee Process: Open Disclosure of Willing Nominees) to BCP
I support the use of should. Spencer Dawkins wrote: Brian Carpenter had a Last Call comment that I needed to follow up on... Hi, (IETF list not copied as I'm on leave and minimising email, but there is nothing confidential about this comment.) Feedback on nominees should always be provided privately to NomCom. Nominees should not solicit support, and other IETF community members should not post statements of support/ non-support for nominees in any public forum. I believe these three occurrences of 'should' need to be 'must'. I don't think there should be any wiggle room on this point. Brian Russ thinks I should check on this with the rest of the community, so I'm asking for feedback now. Thanks, Spencer ___ 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: Voting (Re: Publicizing IETF nominee lists)
Phillip Hallam-Baker wrote: On Thu, Jun 11, 2009 at 6:58 AM, Harald Alvestrandhar...@alvestrand.no wrote: Voting has all kinds of issues. Precisely the type of vague, non reason that I was complaining about. Consider the last ten years of yelling to be included by reference. I like the current Nomcom process because it depends on 2 things: - A pool of qualified volunteers - Luck in picking a nomcom that behaves sensibly (for whatever that means to you) Given that luck is involved, many of the possible attacks that people could mount in order to gain more IETF influence won't happen - simply because they have a significant chance of failure. Trying, failing, and being detected as having tried, would be harmful to the group that tried it. The last time I was aware of anything like that happening in any standards group was when XrML was killed in OASIS, but the issue there was people opposed to DRM, not a company driven thing. Where companies want to tilt the playing field they usually have to start the organization to succeed. Or get in early like the XRI folk did with OpenID. And fat lot of good it did them. As a former corporate rep, I can assure you that there is precisely zero value in gaining the imprimatur of the IETF (or OASIS or W3C for that matter) if you short circuit the process. The point of standards participation is to get buy in from other parties you need to build common infrastructure. Sure. That's why Microsoft spent so much resource (and credibility) making sure the OOXML vote went through; they did not gain anything of value. Or perhaps the value proposition is different for ISO than for the IETF. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Steve Coya
I am sad to hear this. I miss him. Fred Baker wrote: Steve Coya, the IETF's Executive Director at CNRI during much of the 1990's and early 2000's, has passed away. His wife, Mary Beth, wanted folks to know, as the IETF was a big part of his life. http://www.legacy.com/washingtonpost/DeathNotices.asp?Page=LifestoryPersonId=128055919 ___ 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: IETF 78 Annoucement
Iljitsch van Beijnum wrote: And as I said before, I would be very interested to learn whether doing this in june rather than july would have made a different location in the Netherlands a more viable option. ICANN's holding its Latin America meeting June 20-25. Guess why they chose those dates? ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [Fwd: Re: Changes needed to Last Call boilerplate]
Jari Arkko wrote: Despite currently excessive number of comments, I think we should invite more comments and make it easier, not harder to send them. Even if traffic on the list is now too high and information content per message is low, in general our average number of comments in the IETF Last Call stage is too low. I don't have a problem with the number of messages. Deleting is easy. But I wouldn't mind stricter enforcement of the Subject lines... Note that this opinion is entirely separate from the value of the comments. Repetition and mail bombing is not valuable. Well justified opinions are very valuable. The latter may come from both inside and outside the IETF; sometimes experts on some topic can be persuaded to send in a comment, but not to subscribe to lists or engage in lengthy debate. I think anyone who posts to the IETF list should have his unsubscribe function disabled for a week. That seems like a punishment that fits the crime. (despite the obvious workarounds) Harald ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Previous consensus on not changing patent policy (Re: References to Redphone's patent)
Lawrence Rosen wrote: Chuck Powers wrote: +1 That is a legal quagmire that the IETF (like all good standards development groups) must avoid. Chuck is not alone in saying that, as you have just seen. These are the very people who refused to add patent policy to the charter of the previous IPR WG, and who controlled consensus on that point last time. To be precise: Last time was at the San Francisco IETF meeting, March 16-22 2003, and I was the one controlling consensus. The minutes (at http://www.ietf.org/proceedings/03mar/132.htm ) show this conclusion, after much discussion: 1. do you wish this group to recharter to cdhange the IETF's IPR policy hum for (some) hom anti (more) fairly clear consensus against rechartering. anyone disagree? harald: will verified on mailing list, will lead to some debate. if consensus is reached against rechartering... the IETF will not consider proposals to create or reactivate IPR wg before people with compelling arg to do so. those should be different than what prevented so far. Despite the abysmal spelling quality, it was pretty clear at the time that the arguments presented were not compelling. I haven't seen significant new arguments in the meantime; that doesn't mean they don't exist, just that I haven't seen them. Harald ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Including the GPL in GPL code (Re: IETF and open source license compatibility)
Simon Josefsson wrote: I consider the inability to include immutable text in software released under the GPL a bug in the GPL. Nobody forces you to use the GPL, so if you perceive a problem I suggest to use another license for your program. However, the IETF should not prevent implementers from using the GPL, for the same reasons IETF should not prevent Microsoft from using its EULA as the license. BTW, this means that at least one program I have released under the GPL is illegal; it includes the GPL as a part of the source code, and since the GPL text is immutable according to the GPL, it is illegal (by this logic) to include it in source code, since the source has to be free of restrictions upon its modification. I don't see how that makes the program illegal. It just makes it harder for others to redistribute it safely because the licensing information is unclear. Simon, the example is at http://counter.li.org/scripts/machine-update. Take a look. There is a single file that contains both the program source and the GPL. I want to release this under the GPL. Now, I have three possible interpretations: 1 - The words of the GPL that say Everyone is permitted to copy and distribute verbatim copies of this license document, but changing it is not allowed. don't really apply in this case. 2 - The words of the GPL that say You may modify your copy or copies of the Program or any portion of it, thus forming a work based on the Program, and copy and distribute such modifications or work under the terms of Section 1 above don't apply to modifications of the portion of the Program that is the GPL 3 - I'm breaking the GPL Now, with your extensive knowledge of what the GPL means for included text which is it? Harald ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Including the GPL in GPL code (Re: IETF and open source license compatibility)
Simon Josefsson wrote: This is getting off-topic, and seems like typical FAQ material, but I'll reply briefly. I suggest using, e.g., discuss...@fsfeurope.org to get other people's interpretations. If you want a more authoritative answer, talk to licens...@gnu.org. 2 - The words of the GPL that say You may modify your copy or copies of the Program or any portion of it, thus forming a work based on the Program, and copy and distribute such modifications or work under the terms of Section 1 above don't apply to modifications of the portion of the Program that is the GPL This seems more or less correct, even though it may sound surprising at first. More generally, and more clearly expressed, it can be stated as this: The license for a piece of work applies to the piece of work, it does not apply to the license itself. The license of a work is not normally not considered part of the work; it is metadata about the work. But (and the reason why this is important, and IETF-relevant) how is this case different from the case where you introduce pieces of an RFC (which also don't need to be considered part of the work) as comments into a work? With the GPL text, you don't have the copyright, and you don't have a license that permits modified versions. But you do have the right to copy it. With the excerpt from an RFC, you don't have the copyright, and you don't have a license that permits modified versions. But you do have the right to copy it - you even have the right to copy pieces of it. Why are you insisting that the first is perfectly reasonable, and the second is a show-stopper? Harald ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: The Dean list
Andrew Sullivan wrote: I also was resubscribed. I received the usual totally clarifying message one has come to expect from Mr Anderson. None of this suggests to me, however, that we ought to do something. My understanding (and I'd appreciate being disabused if I'm wrong) is that Mr Anderson is already not allowed to post to IETF lists, even though he sometimes manages to do so anyway. If I'm right, I can't see how banning him for longer, we mean it this time, neener neener, is any help. We just need better sieve rules, not better ietf ones. So far I haven't seen anyone but Dean Anderson post to the ietf-honest list, so for me there's no extra workload involved - my sieve filters are already doing the Right Thing. We have a name for people who subscribe you to receive mail you don't want, and that word is spammer. In this case, we even know exactly who the spammer is. Dealing with the spammer is not an IETF matter, no matter what he calls his list. Harald ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: IETF and open source license compatibility (Was: Re: yet another comment on draft-housley-tls-authz-extns-07.txt)
Tony Finch wrote: On Thu, 12 Feb 2009, Jari Arkko wrote: I agree that there are problematic case, but I believe I hope everyone realizes this is only the case if the RFC in question has code. Otherwise it really does not matter. Only some RFCs have code. Except that it prevents using the text of an RFC as comments in an implementation. actually that's intended to be permitted by RFC 5377 section 4.2: 4.2. Rights Granted for Quoting from IETF Contributions There is rough consensus that it is useful to permit quoting without modification of excerpts from IETF Contributions. Such excerpts may be of any length and in any context. Translation of quotations is also to be permitted. All such quotations should be attributed properly to the IETF and the IETF Contribution from which they are taken. You're not permitted to modify the text. You are permitted to use it. Harald ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: IETF and open source license compatibility
Simon Josefsson wrote: actually that's intended to be permitted by RFC 5377 section 4.2: 4.2. Rights Granted for Quoting from IETF Contributions There is rough consensus that it is useful to permit quoting without modification of excerpts from IETF Contributions. Such excerpts may be of any length and in any context. Translation of quotations is also to be permitted. All such quotations should be attributed properly to the IETF and the IETF Contribution from which they are taken. You're not permitted to modify the text. You are permitted to use it. Exactly, and disallowing modifications prevents using the text of an RFC as a comment in implementations licensed under free software licenses. For short excerpts, one can use the text anyway and claim fair use, but larger excerpts can be useful to quote in comments or documentation and then there is a problem. I consider the inability to include immutable text in software released under the GPL a bug in the GPL. BTW, this means that at least one program I have released under the GPL is illegal; it includes the GPL as a part of the source code, and since the GPL text is immutable according to the GPL, it is illegal (by this logic) to include it in source code, since the source has to be free of restrictions upon its modification. Not My Problem to solve. Harald ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Please Review Draft IESG Statement on Activities that are OBE
Two concerns. 1) As the chair of a WG that many will consider to be a prime example of OBE, I am a bit worried about the MUST NOT publish statements. A traditional antidote to long-running WGs has been to kill them and tell the editors if you really want to finish up, you can always do individual submission - and individual submission has no barrier to publishing PS or Experimental for OBE technologies - the traditional mantras being this is an experiment to see if interest revives or this PS is replacing another, even more OBE PS. I wouldn't want to put a WG into a situation where its work items get better treatment if the WG is shut down and items progressed without WG review than it does if the WG remains active. 2) For completeness, I'm also quite puzzled as to why the IESG statement does not contain the words If the IESG determines that a WG is OBE, the IESG will shut down the working group at the end of section 2. Even if that happens after the WG submits documents to the IESG, so that the IESG has to follow the advice in section 3, there seems little reason to let it hang around. A logical reason might be that the IESG doesn't want to take on the excess heat generated by declaring a WG to be OBE and closing it - but in that case, it can never invoke the procedure in section 3, since the WG hasn't been declared OBE (unless the OBE declaration is done in secret, which would be very un-IETFish). If OBE = closed, the handling should become simpler. Harald The IESG wrote: The IESG is considering publication of the attached IESG Statement on IETF activities that are overtaken by events (OBE). Please review and comment. The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2009-02-11. Exceptionally, comments may be sent to i...@ietf.org instead. The IESG == 1. Introduction IETF activities can be overtaken by events (OBE). For example, assume that a Working Group is chartered to address a particular problem. While the working group is developing its solution to the problem, one of the following events occur: - unrelated technologies evolve, causing the problem to cease to exist - unrelated technologies evolve, significantly decreasing the magnitude of the problem In these cases, the WG is OBE. Its output no longer merits the investment that it requires. Therefore, the WG should be rechartered or terminated. A WG can also be OBE if the community agrees that it should never have been chartered for any of the following reasons: - it addresses an ill-defined problem - it addresses a non-problem - it address a problem to which all solutions are worse than the problem This memo describes several measures that ADs can take to prevent WGs from becoming OBE. It also describes several measures that can be taken in the unhappy event that the IESG is presented with the output of a WG that has been OBE. 2. Preventative Measures 2.1 Prudent Chartering Avoid charters that run longer than one or two years. When faced with multi-year efforts, break the task into smaller pieces that can be achieved in one-or-two year increments. 2.2 Frequent Charter Review Use re-chartering exercises to re-evaluate the problem that a WG is addressing. Do not recharter a WG to work on a problem that is OBE. 3. IESG Actions The worst outcome for a WG that is OBE is for that WG to continue its work and send its output to the IESG for publication. When that happens, the IESG must choose among the following options: - publish with the status proposed by the WG - negotiate the document status with the WG and then publish - reject the document. If the IESG publishes the document unchanged, it may adversely impact the overall quality of the RFC series. If it rejects the document, it violates its charter with the WG. The IESG MUST NOT publish the output of WG that has been OBE as PS, BCP or EXPERIMENTAL. Publishing under those headers would imply that the IETF proposes deployment of those solutions/experiments, which it clearly does not. The IESG MAY publish the output of a WG that has been OBE as INFORMATIONAL or HISTORIC. It should add an IESG note stating that the problem addressed by the document has been OBE. The IESG MUST NOT reject a document simply because it has been OBE. It must consider publication as INFORMATIONAL or HISTORIC. ___ IETF-Announce mailing list ietf-annou...@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: RFC 5378 contributions
Paul Hoffman wrote: At 1:38 PM +1300 1/15/09, Brian E Carpenter wrote: IANAL, but it seems to me that we should proceed on the assumption that this would fall under fair use provisions. Anything else would seem unreasonable to me. IANAL, and I'm only following about 10% of this thread, but the phrase fair use does not appear in RFC 5378. Maybe it should. Fair use is a concept of US law. 5378 tried to use language with reasonably global definitions. At one point it was suggested that RFC 5377 (desires for outgoing rights) should refer to fair use, but section 4.1 ended up saying that we want to grant unlimited permission to quote instead. Harald ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: where to send RFC 5378 license forms
Contreras, Jorge wrote: Who owns the oft-repeated The key words MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL in this document are to be interpreted as described in [RFC2119]. I'm referring to the bits effectively required by the MIB doctors, e.g.: This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it defines a basic set of managed objects for Simple Network Management Protocol (SNMP)-based management of ... and For a detailed overview of the documents that describe the current Internet-Standard Management Framework, please refer to section 7 of RFC 3410 [RFC3410]. Managed objects are accessed via a virtual information store, termed the Management Information Base or MIB. MIB objects are generally accessed through the Simple Network Management Protocol (SNMP). Objects in the MIB are defined using the mechanisms defined in the Structure of Management Information (SMI). This memo specifies a MIB module that is compliant to the SMIv2, which is described in STD 58, RFC 2578 [RFC2578], STD 58, RFC 2579 [RFC2579] and STD 58, RFC 2580 [RFC2580]. and various incarnations of this stuff that appear in the text of RFCs that happen to contain MIB modules, not the stuff that's in the MIB modules. (Earlier versions of this were rather lengthy.) I will check into this. Ideally, all boilerplate would be owned by the IETF Trust, but I am not aware that anyone has ever focused on this material. Technically, the copyright owner would be the author(s) who wrote the first document that says those words. However, the copyright in such generic phrases is vestigial at best. Jorge, would the fact that people have acted as if these phrases can be copied freely for the last 20 years create a presumption that the copyright holders (if any) have given permission for their free copying? (I tracked the first sentence of the Managed objects are accessed phrase back to RFC 1065, August 1988; authors-of-record were Marshall Rose and Keith McCloghrie. There were drafts before that, of course.) Harald ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: where to send RFC 5378 license forms
Simon Josefsson wrote: Harald Tveit Alvestrand har...@alvestrand.no writes: Simon Josefsson skrev: Ray Pelletier rpellet...@isoc.org writes: On Dec 18, 2008, at 2:14 PM, Sam Hartman wrote: Why do we need to send these license forms in at all? I thought the requirement was that the authors get the necessary rights. Are you just conveniently keeping track for us? I would envision folks providing 5378 licenses to the Trust or their pre-5378 work. If licenses are submitted their names could be posted online for other Contributors to ascertain whether a pre-existing work has been so licensed. How does this help contributors use the older material? As far as I understood the rules, it is the author that needs to get the necessary rights from the original contributor before submitting it to the IETF. The form appears to give the necessary rights from the original contributor to the IETF Trust, not to the authors. If the Trust has those rights, it's licensing them to all participants under the same terms as post-5378 works. Not as far as I can see. You're right. I should have said It should be licensing them, since the current text of the Trust's license says that it applies only to post-5378 works. The Outgoing license from the Trust does not include many of the rights required from contributors in Incoming. That's by design. As John said so many times during the discussions: we probably have to expand the rights granted to the Trust once, but we should make very, very sure that we don't have to do it again. For example, RFC 5378 section 5.3 d) says: d. to reproduce any trademarks, service marks, or trade names which are included in the Contribution solely in connection with the reproduction, distribution, or publication of the Contribution and derivative works thereof as permitted by this Section 5.3, provided that when reproducing Contributions, trademark and service mark identifiers used in the Contribution, including TM and (R), will be preserved. The 'Legal Provisions' document does not mention trademarks. Thus, by default, there is no grants of rights related to trademarks from the IETF Trust to IETF participants. If you are updating a pre-RFC 5378 document that contains trademarked words, it isn't sufficient for the old contributor to have signed the IETF Trust form if the document contains trademarks. You need to contact him anyway, to get permission to reproduce the trademark. I sure hope that's a bug (and one that, because of the separation of concerns, we can get fixed without spinning up a working group). Harald (thankful to not be IPR chair any more, and being back to just having opinions) ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: RFC5378 alternate procedure (was: Re: IPR Questions Raised by Sam Hartman at the IETF 73 Plenary)
Material comments: - Section 3: RFC 5378 expected the date on which 5378 was effective to be set by the Trust (section 2.1), and explicitly did not want to cast into RFC stone the procedure by which the changeover date was determined. - I disagree with the decision to allow *all* of a submission, including new text, to be 3978-boilerplated. As I've said before, my preferred resolution mechanism is to have a mechanism available (probably front-page disclaimer + details in the Contributors section) for listing pre-5378 sources from which material was copied without 5378 permission being granted by the authors. I believe the continued production of material that is licensed under 3978 only will be long-term harmful to the state of the IETF's IPR confusion. Harald John C Klensin wrote: Hi. I've just reposted this draft as draft-klensin-rfc5378var-01.txt. I didn't removing the material I indicated I was going to remove because this version follows too quickly on the previous one. There are only two sets of changes, but the first seemed sufficiently important to be worth a quick update: (1) Alfred Hoenes caught several places in which I had transposed digits or otherwise fouled up RFC numbers to which I was making reference. This type of work is sufficiently confusing without that sort of stupid problem, for which I apologize -- I thought I had proofread it carefully enough but obviously did not. They have been fixed. (2) I realized that it was necessary for completeness to un-obsolete 3948 and 4748 if they were going to be referenced, or material from them picked up and copied into, documents, so I have inserted a paragraph to take care of that. Anyone who has successful read the -00 version and understood it can safely ignore this one. Anyone who has not yet read -00, or who tried to read it and was confused by the numbering errors, may find this version more helpful. Comments are, of course, welcome on either one. john ___ 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: IPv6 traffic stats
Pekka Savola wrote: On Tue, 11 Nov 2008, Harald Alvestrand wrote: The correct number from the presentation is 0.238% - only Russia, Ukraine and France have more than 0.5% IPv6. Presentation available from http://rosie.ripe.net/presentations-detail/Thursday/Plenary%2014:00/index.html. Depends on what you're looking for, but if you are interested in the amount of users that have any kind of IPv6 connectivity, this undercounts severely because address selection rules on recent OSs typically select IPv4 if their connectivity is 6to4 or Teredo. Pekka, can you identify the OSes that prefer IPv4 when on 6to4, and pointers to docs? Steinar (the guy who did the Google experiment) has tried to dig through the documentation on both Vista and Linux, and has drawn a blank (Vista with Teredo doesn't even look up the record if it has IPv4 connectivity, according to the documentation, so it seems that it will not use IPv6 to IPv6-only hosts; it will never find the address.) Harald ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: IPv6 traffic stats
David Kessens wrote: Joe, On Tue, Nov 11, 2008 at 08:20:11AM -0800, Joe St Sauver wrote: I'm not aware of DNS block lists which cover IPv6 address spaces at this time, probably in part because IPv6 traffic remains de minimis (see http://asert.arbornetworks.com/2008/8/the-end-is-near-but-is-ipv6/ showing IPv6 traffic as constituting only 0.002% of all Internet traffic). For the record: It seems that arbornetworks estimates are extremely low to the point where one has to ask whether there were other issues that caused such a low estimate. There is no question that IPv6 traffic is quite low in the Internet. However, many other reports that I have seen recently measure multiple orders of magnitude more IPv6 traffic (for an easily accesible example see: http://www.ams-ix.net/technical/stats/sflow/) Google's measurements indicate that when faced with a dual-stack host (one with both an and an A record in the DNS), 0.5% of all hosts will access that host using IPv6. (As presented at the RIPE meeting in Dubai last month.) Harald ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: IPv6 traffic stats
Sorry, I misremembered. The correct number from the presentation is 0.238% - only Russia, Ukraine and France have more than 0.5% IPv6. Presentation available from http://rosie.ripe.net/presentations-detail/Thursday/Plenary%2014:00/index.html. Harald Turchanyi Geza wrote: Harald, Your Half percent is great! When Tim Berners-Lee presented the www at the JENC conference in Insbruck in 1992, he said that according to the traffic mesurement statistics, the www-related trafic is around half percent. What was the ratio two years later? 40% Half percent is a good start for a real revolution. The question is: where is any similar movement to those pushed the web development in the early nineties? Best, Géza On Tue, Nov 11, 2008 at 9:38 PM, Harald Alvestrand [EMAIL PROTECTED] wrote: David Kessens wrote: Joe, On Tue, Nov 11, 2008 at 08:20:11AM -0800, Joe St Sauver wrote: I'm not aware of DNS block lists which cover IPv6 address spaces at this time, probably in part because IPv6 traffic remains de minimis (see http://asert.arbornetworks.com/2008/8/the-end-is-near-but-is-ipv6/ showing IPv6 traffic as constituting only 0.002% of all Internet traffic). For the record: It seems that arbornetworks estimates are extremely low to the point where one has to ask whether there were other issues that caused such a low estimate. There is no question that IPv6 traffic is quite low in the Internet. However, many other reports that I have seen recently measure multiple orders of magnitude more IPv6 traffic (for an easily accesible example see: http://www.ams-ix.net/technical/stats/sflow/) Google's measurements indicate that when faced with a dual-stack host (one with both an and an A record in the DNS), 0.5% of all hosts will access that host using IPv6. (As presented at the RIPE meeting in Dubai last month.) Harald ___ 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: Publication track for IBE documents (Was Second Last Call...)
Stephane Bortzmeyer wrote: On Wed, Oct 22, 2008 at 04:51:23PM +0200, Harald Alvestrand [EMAIL PROTECTED] wrote a message of 23 lines which said: (That said, the RFC Editor's work on these will cost the IETF a known amount of dollars. Known by who? How an ordinary IETF participant could find out The Real True Cost of a RFC? IETF homepage - IASA - Budget and Finance - Budget - 2008 Expenses: RFC Editor/Edit Svcs: 737.800 dollars. I don't have the RFCs per year number in my head just now. Harald ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Publication track for IBE documents (Was Second Last Call...)
Stephen Farrell wrote: So while I don't strongly object to these as informational RFCs, I do wonder why, if only one implementation is ever likely, we need any RFC at all. Its not like these docs describe something one couldn't easily figure out were there a need, given that the (elegant but not especially useful) crypto has been around for a while without finding any serious applications. My personal opinion is that Informational documents should have a low bar for publication. Thus, in the absence of compelling other information (such as a claim that the technology is incompetently described, or can't be implemented from the specs), I'd favour publication. (That said, the RFC Editor's work on these will cost the IETF a known amount of dollars. The bar shouldn't be TOO low.) Harald ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Second Last Call: draft-ietf-smime-bfibecms (Using the Boneh-Franklin and Boneh-Boyen identity-based Encryption Algorithms with the Cryptographic Message Syntax (CMS)) to Proposed Standard
SM wrote: At 05:37 20-10-2008, The IESG wrote: This is a second last call for consideration of the following document from the S/MIME Mail Security WG (smime): - 'Using the Boneh-Franklin and Boneh-Boyen identity-based Encryption Algorithms with the Cryptographic Message Syntax (CMS) ' draft-ietf-smime-bfibecms-10.txt as a Proposed Standard Technical issues raised in IETF Last Call and IESG evaluation have been resolved. However, there have been substantive changes in the relevant IPR disclosures statements since the review process was initiated. Specifically, IPR disclosure statement #888, (see https://datatracker.ietf.org/ipr/888/) was replaced by PR disclosure statement #950, (see https://datatracker.ietf.org/ipr/950/) This Last Call is intended to confirm continued community support in light of the new IPR disclosure statement. Given the limited scope of this Last Call, an abbreviated time period has been selected. Disclosure statement #888 mentions draft-martin-ibcs-08. That I-D was published as RFC 5091 in December 2007. Disclosure #950 submitted in May 2008 mentions new licensing terms for RFC 5091. That disclosure mentions that draft-ietf-smime-bfibecms-10 is on the Informational Track whereas it is on the Standards Track. As there seems to be only one implementation and very little public discussion about the draft, I don't see why it should be on the Standards Track. With licensing terms like these, I would want to see a compelling argument for why the community needs it standardized to put it on the standards track. Let it be informational. Harald ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Failing of IPR Filing Page when makling updates in re LTANS and other filings.
You can't change your earlier public statement; that would be tampering with the historical record. You can, however, file a new statement that updates the old one, as you have already done by filing #954, listed as an update of #201, and #955, #956, #957, #958, #959, #960, #961, #962 and #963, all listed as updates of #954. TS Glassey wrote: Folks - I found several working flaws with the IPR disclosure page when I went back to the IPR201 filing this AM to add several additional Internet Draft's for notice of Patent Controls; As to the IPR Page - it does not allow for updates of already filed IPR Statement's to include new IETF documents which violate the patent rights after the posting of the IPR Notice. So then how does one add more IETF infringing document's to an existing IPR declaration. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Call for review of proposed update to ID-Checklist
IETF Chair wrote: From the discussion just prior to the recent appeal by John Klensin, it was clear that the guidance regarding example domain names in IETF documents provided in the ID-Checklist needed to be updated. This point was emphasized further during the discussion of the Klensin appeal. Proposed text is now available. Many thanks to Bert Wijnen for continuing to edit the document. The IESG solicits comments on this proposed update. The IESG plans to make a decision on this proposed text on 2008-07-17. Please send substantive comments to the ietf@ietf.org mailing lists by 2008-07-16. Exceptionally, comments may be sent to [EMAIL PROTECTED] instead. In either case, please retain the beginning of the Subject line to allow automated sorting. The proposed text can be obtained via http://www.ietf.org/Draft-ID-Checklist.html 6 days later, the URL gives me an object not found. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Removal of IETF patent disclosures?
Simon Josefsson wrote: Harald Alvestrand [EMAIL PROTECTED] writes: At least one of the removed patent licenses promises to make available patent licenses on fair, reasonable, reciprocal and non-discriminatory terms. It seems unfortunate that IETF allows organizations to file such claims and permits them be removed later, presumably when the organization change their minds. Agreed in principle. On the other hand (trying to play devil's advocate), if the promise was made by someone in the organization that did not have authority to commit the organization to that statement, I could see why the responsible persons for that organization would want the original statement made invisible, so as to not have to eternally go around and explain the situation. Harald ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
New schemes vs recycling http: (Re: Past LC comments on draft-ietf-geopriv-http-location-delivery-08)
Julian Reschke wrote: Well. There's definitively a total disconnect between that IESG recommendation, and the W3C TAG's point of view (see ongoing discussion on the TAG mailing list about the xri scheme). It would be good when both organizations could come up with consistent answers. If a new URI scheme is defined, it needs to state what it identifies, and how it is resolved. If it identifies an HTTP resource, and resolution is done via HTTP, then it seems to me you don't need it. Note: I totally disagree. I detest, abhor and condemn the idea that there is such a thing as a HTTP resource. An URI identifies a resource. One possibility of accessing that resource is by using HTTP; if the URI scheme is http:, there is an implication that the definer of the URI regarded this as the normal way of accessing the resource, and that whether the resource is static, dynamic or changeable is a matter strictly under the control of the manager of the server identified by the hostname in the URI. Certain usages of HTTP (in particular, the use of HTTP URLs for XML schemas) have tended to denigrate this implication, and say you should regard this as an identifier. Still, the usage is prevalent enough that people have complained that servers identified in popular XML schemas are getting hit with enough extra traffic to cause operational problems. Now, many resources can be accessed over HTTP. And many more will be. But in many cases, the guarantees given should be DIFFERENT; a mid: URI means that if you find a copy of the message with this message-ID, it's probably the same message - a tag: URI means someone intended this URI to be an unique reference, and you can figure out who it was given enough time and effort. And I haven't even mentioned URNs yet. The WG needs to be clear about what kinds of resources it's identifying, and what the properties it wants to embed as part of the URI scheme is. Usually, all the features and warts of HTTP won't be the answer. I don't speak for anyone but myself. But just based on Julian's comments, I stand with the IESG advice on this one, and think that the W3C TAG (if its recommendation is reported correctly) is off in the weeds. Harald ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: New schemes vs recycling http: (Re: Past LC comments on draft-ietf-geopriv-http-location-delivery-08)
it's surprising how much we agree on :-) Julian Reschke wrote: Certain usages of HTTP (in particular, the use of HTTP URLs for XML schemas) have tended to denigrate this implication, and say you should regard this as an identifier. Still, the usage is prevalent enough that people have complained that servers identified in popular XML schemas are getting hit with enough extra traffic to cause operational problems. I've heard that as well, and tried to find out exactly *what* URLs were causing the problem. As far as I can tell, it was always because of URLs that were intended to be dereferenced, such as URLs of DTDs. (If this is incorrect, I'd love to see a pointer...). Is it clearly stated somewhere that URLs of DTDs are intended to be dereferenced? (in the Murky Old Days we had DTDs identified by SGML identifiers, which I don't think I'll be able to dereference any time soon) Harald ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: IESG Processing of RFC Errata for the IETF Stream
The IESG (by way of Russ Housley [EMAIL PROTECTED]) wrote: The attached describes the manner in which the IESG will be processing RFC Errata for the IETF Stream. The current tools on the RFC Editor site support approved and rejected, but they need to be updated to also permit hold for document update as errata states. Thanks, IESG Secretariat -- These are strong guidelines and not immutable rules. Common sense and good judgment should be used by the IESG to decide what is the right thing to do. Errata are meant to fix bugs in the specification and should not be used to change what the community meant when it approved the RFC. These guidelines only apply to errata on RFCs in the IETF stream. They apply to new errata and not errata that have already been approved. After an erratum is reported, a report will be sent to the authors, chairs, and Area Directors (ADs) of the WG in which it originated. If the WG has closed or the document was not associated with a WG, then the report will be sent to the ADs for the Area most closely associated to the subject matter. The ADs are responsible for ensuring review; they may delegate the review or perform it personally. The reviewer will classify the erratum as falling under one of the following states: o Approved - The erratum is appropriate under the criteria below and should be available to implementors or people deploying the RFC. I assume that these will be made prominently visible in the RFC Editor's errata list. o Rejected - The erratum is in error, or proposes a change to the RFC that should be done my publishing a new RFC that replaces the current RFC. In the latter case, if the change is to be considered for future updates of the document, it should be proposed using channels other than the errata process, such as a WG mailing list. I assume that these errata will not be visible in the RFC Editor's errata list. o Hold for Document Update - The erratum is not a necessary update to the RFC. However, any future update of the document might consider this erratum, and determine whether it is correct and merits including in the update. Are these intended to be visible in the errata list, or not? (I would prefer them to be visible.) Guidelines for review are: 1. Only errors that could cause implementation or deployment problems or significant confusion should be Approved. 2. Things that are clearly wrong but could not cause an implementation or deployment problem should be Hold for Document Update. 3. Errata on obsolete RFCs should be treated the same as errata on RFCs that are not obsolete where there is strong evidence that some people are still making use of the related technology. What's the Else here - if there is no such strong evidence, is the errata Accepted under a different set of conditions, Rejected or Hold for Document Update? (I would prefer the latter, unlikely as such an event may be, if my interpretation of intended visibility is right). Harald ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: IESG Processing of RFC Errata for the IETF Stream
Russ Housley wrote: Harald: I'd like to see this discussed on the rfc-interest mail list. Previously, you suggested that all errata and their disposition be available for historical review, regardless of the state that the errata is put into. I think that this is the plan, but these details are for the RFC Editor to implement. OK - message forwarded to rfc-interest. The answers affect whether or not I think the suggested IESG process is reasonable, which is why I was asking the questions. Harald ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Missing Materials
Eric Rescorla wrote: As I have done for previous IETFs I just ran getdrafts (http://tools.ietf.org/tools/getdrafts/) on the entire agenda and what follows is the output. As you can see, a pretty substantial number of WGs are without agendas, about 10% of the drafts listed are wrong, and about half of those appear to be simple version errors. -Ekr draft-ietf-eai-smtpext-11.txt (wg=eai) draft-ietf-eai-utf8headers-09.txt (wg=eai) draft-ietf-eai-downgrade-07.txt - draft-ietf-eai-downgrade-08.txt (wg=eai) draft-ietf-eai-imap-utf8-02.txt - draft-ietf-eai-imap-utf8-03.txt (wg=eai) draft-ietf-eai-pop-03.txt - draft-ietf-eai-pop-04.txt (wg=eai) draft-ietf-ipr-3978-incoming-08.txt - draft-ietf-ipr-3978-incoming-09.txt (wg=ipr) draft-ietf-ipr-outbound-rights-06.txt - draft-ietf-ipr-outbound-rights-07.txt (wg=ipr) all fixed now. Thanks for running the check! Harald, back from holidays ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Appeal against IESG blocking DISCUSS on draft-klensin-rfc2821bis
Simon Josefsson wrote: Brian Dickson [EMAIL PROTECTED] writes: Here's my suggestion: List 2606 in the informative references, and footnote the examples used to indicate that they are grandfathered non-2606 examples. So, in text that previously read not-example.com, it might read not-example.com [*], with the references section having [*] Note - non-RFC2606 examples used. Please read RFC2606. Something along those lines, should hopefully be enough to keep both sides happy, and resolve the DISCUSS, and hopefully both set a suitable precedent *and* make moot the appeal. I think this sounds like a good compromise, and it does improve the document quality IMHO. John, would this be an acceptable addition to the document? I do not want a compromise on whether or not the IESG documents the rules it's enforcing. BEFORE trying to enforce them consistently, and using the consistency as an argument that what looks like a recommendation in a BCP is really a MUST. Harald ___ IETF mailing list IETF@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: WG Review: NETCONF Data Modeling Language (netmod)
Eric Rescorla wrote: At Tue, 22 Apr 2008 19:17:47 -0600, Randy Presuhn wrote: Our ADs worked very hard to prevent us from talking about technology choices at the CANMOD BOF. Our original proposal for consensus hums included getting a of sense of preferences among the various proposals. We were told we could *not* ask these questions, for fear of upsetting Eric Rescorla. Well, it's certainly true that the terms--agreed to by the IESG and the IAB--on which the BOF were held were that there not be a beauty contest at the BOF but that there first be a showing that there was consensus to do work in this area at all. I'm certainly willing to cop to being one of the people who argued for that, but I was far from the only one. If you want to blame me for that, go ahead. In any case, now that consensus to do *something* has been established it is the appropriate time to have discussion on the technology. I certainly never imagined that just because there weren't hums taken in PHL that that meant no hums would ever be taken. It's been a month since PHL. The IETF's supposed to be able to work on mailing lists between meetings, including being able to work when no WG exists - which of course means working on mailing lists that are not WG lists. I congratulate the participants who worked on the charter on managing to have the discussion and come to consensus on an approach. I think it's up to Eric to demonstrate to the IESG that there's support in the community for disagreeing with the consensus of the discussing participants. Harald ___ IETF mailing list IETF@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Weekly posting summary for ietf@ietf.org
Andrew G. Malis wrote: Thomas, I would personally find this more useful if it were measured by subject line rather than by sender. At the time when these summaries started, it was obvious from some summaries that some participants seemed to be spending more time typing answers than reading the responses (when one person had two to three times as many postings as #2 on the list). That behaviour has largely disappeared, so it may be less obvious why it's a good thing to see this metric. Personally, I'm for keeping the weekly posting as-is. Harald Thanks, Andy On Fri, Apr 18, 2008 at 12:53 AM, Thomas Narten [EMAIL PROTECTED] wrote: Total of 103 messages in the last 7 days. script run at: Fri Apr 18 00:53:01 EDT 2008 Messages | Bytes| Who +--++--+ 6.80% |7 | 5.33% |37130 | [EMAIL PROTECTED] 5.83% |6 | 6.08% |42351 | [EMAIL PROTECTED] 5.83% |6 | 5.17% |35998 | [EMAIL PROTECTED] ___ IETF mailing list IETF@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Proposed Revisions to IETF Trust Administrative Procedures
I too like Ted's comments. If the job is really to preside over the Trust meetings, the title convener might be useful; if the job is to make sure Trust work gets followed up, call it an executive director. But I can live with the current proposal (although dropping #12 entirely would make absolutely no difference, and make the document shorter). Harald ___ IETF mailing list IETF@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Blue Sheet Change Proposal
Ray Pelletier wrote: All, We are considering changing the meeting Blue Sheet by eliminating the need to enter an email address to avoid spam concerns. Is there any good reason to retain that info bit? I think you should ask Jorge whether the disambiguation factor matters - he's the lawyer, unlike all the armchair occupants around here. I don't see any other reason to retain them. Diving straight into armchairing myself, I'll just note that under EU data privacy laws, it's illegal to collect personal info for which you have no legitimate purpose - so if we never use those emails for anything, we shouldn't collect them. I'm all in favour of making things simpler if we can. (The hypothetical subpoena could, in theory, lead to me standing in a courtroom looking at a blue sheet copy and being asked is this your handwriting, and having to stammer maybe. :-) Harald ___ IETF mailing list IETF@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Proposed Revisions to IETF Trust Administrative Procedures
After considering the comments so far, I think I disagree with having a separate Trust chair. The idea behind making the IAOC be the Trustees was, among other things, to make sure that we didn't create yet another nexus of control in the labyrinth of committees; I understood the legal existence of the Trustees as something different (in name) from the IAOC to be strictly something we did for legal purposes If the IAOC chair is overburdened by having to manage the IAOC in two different contexts, get him (or her) a secretary. I agree with John's comment that leaving the current trustees in charge on dissolution of the IAOC is inappropriate; for one thing, that also removes all the recall mechanisms. Figure out something else to do in this case. Harald ___ IETF mailing list IETF@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Proposed Revisions to IETF Trust Administrative Procedures
Ray Pelletier wrote: 12. The Trustees are the current members of the IAOC. When a member leaves the IAOC for whatever reason, he or she ceases to be a Trustee. When a new member joins the IAOC, he or she becomes a Trustee [ADD - upon their acceptance in writing]. This is already covered in the Trust agreement section 6.1, which states that the IAOC are Eligible Persons, and they become Trustees when they agree to that in writing. The addition makes the administrative procedures consistent with the trust agreement - but why say it twice? If at any time the IAOC ceases to exist, the Trustees then in office shall remain in office and determine the future of the Trust in accordance with the Trust Agreement. This is already covered in the Trust Agreement section 6.1 (c) - the expiration of the IAOC would reduce the number of Eligible Persons to zero, making the IESG, or the IESG's successor as the leadership of the IETF, repsonsible for picking at least 3 people to serve as temporary Trustees. So this proposed change would be in breach of the trust agreement - not good. The administrative procedures need to refer to section 6.1 of the trust agreement; creativity is bad. Harald ___ IETF mailing list IETF@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Sharing information from questionnaires (Re: Nomcom 2007-8 Chair's Report)
Lakshminath Dondeti wrote: On 3/6/2008 10:44 PM, Harald Tveit Alvestrand wrote: Lakshminath Dondeti skrev: Folks, A report on the nomcom's activities is available at https://www.tools.ietf.org/group/nomcom/07/nomcom-report. Please direct any comments to [EMAIL PROTECTED] I will make a brief presentation at the IESG plenary. Abstract This document reports on the work of Nomcom 2007-8. The topics of discussion include the experiences in starting the nomcom process early enough to facilitate the nomcom to do their work at 2 face-to- face meetings, the various logistical challenges involved in the nomcom process and the differing interpretations of RFC 3777 by different people and organizations involved in the process. This document also discusses the challenges in the interaction between the nomcom and the confirmation bodies. regards, Lakshminath ___ IETF mailing list IETF@ietf.org https://www.ietf.org/mailman/listinfo/ietf Laksminath, thank you very much for providing the report - and thank you for trying to defend people's expectations of confidentiality! Hi Harald, as nomcom chair You are welcome. I do agree with Scott that the process needs clarification - unlike him, I think it can be done without reopening 3777 on this point. speaking as an individual Sure, there are ways. A solution without changing 3777 is for future chairs to be made aware that this is coming and advise them that they need to prepare accordingly. First, it will be great if the IAB could clarify their requirements. It is simply not acceptable to say candidate statement == questionnaire response. Nomcoms may collect all kinds of information from nominees through a questionnaire or for that matter, other means. The questionnaire itself is prepared by a nomcom process. They cannot share that information just because a confirmation body asks for it pointing to their own internal documents. Agreed - and one of the process failures here is that a nomcom that includes the previous chair and a liaison from the IAB designed a questionnaire in ignorance of the stated requirements; if the IAB expects the nomcom to consider the IAB's desires on the process when starting work, it's the IAB's responsibility to call attention to them. (that said, I too was unaware of the IAB document - and I was relatively closely connected to the process in June 2003.) Future nomcoms could, in the absence of any response from the current IAB or the one a week from today, include an item in the questionnaire that asks for information for IAB's consumption: specifically, CV and candidate's statement (nominee's statement, when the nomcom asks for it) pointing to http://www.iab.org/documents/docs/2003-07-23-nomcom.html. Note: A variation of the above idea has been suggested by others. I am not coming up with anything original there. My suggestion is even more simple-minded: Put markers in the questionnaire around the sections - Resume - About the Area (possibly more sections) saying these sections will be provided to the confirming bodies if you are forwarded to the confirming body as a candidate. All other information is confidential to the nomcom. The questionnaire is under nomcom's control, and the decision to forward information is the nomcom's - the way I read it, the problem this year was that candidates couldn't reasonably be consulted about changing their privacy expectations after the fact. But that requires that someone at questionnaire design time is aware of the requiremement to provide such information. Of course the question then is, what purpose does 3777 serve when a confirming body chooses to prepare their own list of what needs to be provided as supporting material? To repeat my own take on this, of all things, 3777 is quite clear on what needs to be provided. There is no ambiguity whatsoever. The text that the IAB point to -- all information and any means acceptable to them does not say anything about the nomcom facilitating it. Now one could say, any means acceptable includes not confirming until the information they ask for is provided. If we go down that road however, the same text reference could be used (note: hypothetical case) to ask for community feedback. The other question is why should the IAB get any special consideration here? Surely, the IESG and the ISOC BoT could ask for more information too and should be privy to the same level of information that IAB is privy to. I think the ISOC Board is far more reticent about questioning the choices of the Nomcom than the IAB is, for multiple reasons agree that it's reasonable to get their expectations on the table, too. So, we also need to be consistent, however we choose to do this going forward. What is not good is to leave it be and let each nomcom fight
Re: Hasty attempt to create an IDN WG (Was: WG Review: Internationalized Domain Name (idn)
Stephane Bortzmeyer wrote: On Mon, Mar 03, 2008 at 04:32:08PM +0200, Jari Arkko [EMAIL PROTECTED] wrote a message of 21 lines which said: But it is quite common when we revise a specification that we have only an incomplete defect list. Or we may not have determined if a particular issue is really a defect. Understanding which specific issues have to be fixed is typically WG work in a bis spec effort. But it is not in the charter, quite the contrary. The proposed charter is written as if there was a consensus on the IDN problems (there is not, besides the limitation to Unicode 3.2 and may be the bidi). No work is planned to discuss the problems, only solutions are present in the charter, already decided even before the WG exists. The charter is an agenda item at the BOF. If there's consensus that you're right and the proponents are wrong, we can change it. Harald ___ IETF mailing list IETF@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: PTR for IPv6 clients (Re: IPv6 NAT?)
Jeroen Massar wrote: Harald Alvestrand wrote: Mark Andrews skrev: You also don't want to do it as you would also need massive churn in the DNS. Microsoft gets this wrong as they don't register the privacy addresses in the DNS which in turn causes services to be blocked because there is no address in the DNS. perhaps the advent of IPv6 will result in people finally (*finally*) giving up on this sorry excuse for a security blanket? (calling it a mechanism is too kind) Or perhaps it'll just make people register wildcard records at the /64 level in ip6.arpa :-( [EMAIL PROTECTED] (MY, what an useful reverse map!) Like a lot of things, it depends. For SMTP/SSH and for management-alike protocols requiring proper reverse - forward - reverse mapping is IMHO a good thing. Clients servers using these protocols should be on stable trackable addresses. (of course you an set a low TTL etc, that is why one should always log the name + IP, the more information the better). With management I mean for instance reverses on router IP addresses, as it makes traceroute so much more informative, also reverses on servers etc. For SSH you will most likely have firewall rules in place anyway. SMTP should similarly only be allowed to clients that are in your client list. One doesn't have to require r-f-r if the client is in your client-list of course. Your server, which talks to other SMTP servers outside of your control, should be on a stable IP and have functioning r-f-r. For SMTP the current track of mind is: no reverse, no communication. Which stops most of the spam already, as that client is clearly not configured correctly to do inter-domain SMTP. For that matter anything that is 'stable' should (note should) IMHO have a proper r-f-r. For any other protocol _requiring_ reverse is silly IMHO. You don't need it for HTTP, you don't need it for BitTorrent etc. Having reverse in those cases is nice, as it might give extra information (eg the remote is most likely dsl as it contains 'dsl' in the reverse), but it is always a guess and might quite well be faked. The biggest issue with the use of reverses tends to be with applications which only lookup a reverse, but don't check if the r-f-r link is complete. The biggest issue with reverse mapping for clients (any protocol) is that people try to make their applications treat it as anything but here is some information you might find interesting. I think draft-ietf-dnsop-reverse-mapping-considerations-05.txt has it right: 4.3 Application considerations Applications should not rely on reverse mapping for proper operation, although functions that depend on reverse mapping will obviously not work in its absence. Operators and users are reminded that the use of the reverse tree, sometimes in conjunction with a lookup of the name resulting from the PTR record, provides no real security, can lead to erroneous results and generally just increases load on DNS servers. FYI, I ssh out from the address I used as an example above every day. Thinking that SSH clients should be required to be on round-trippable mapped addresses is just silly. Harald ___ IETF mailing list IETF@ietf.org http://www.ietf.org/mailman/listinfo/ietf
Re: PTR for IPv6 clients (Re: IPv6 NAT?)
Rémi Després wrote: Harald Alvestrand a écrit : Mark Andrews skrev: You also don't want to do it as you would also need massive churn in the DNS. Microsoft gets this wrong as they don't register the privacy addresses in the DNS which in turn causes services to be blocked because there is no address in the DNS. perhaps the advent of IPv6 will result in people finally (*finally*) giving up on this sorry excuse for a security blanket? (calling it a mechanism is too kind) Or perhaps it'll just make people register wildcard records at the /64 level in ip6.arpa :-( One approach to achieve it could be ias follows: - An IPv6 link where some privacy source addresses may be used would have in the DNS a record for a generic privacy address. - This address would be the /64 of the link followed by an agreed joker IID (0:0:0:0 or some other to be agreed on, e.g. :0:0:0). - Resolvers, if they recognize a privacy remote address, would query the reverse DNS with this generic privacy address of the remote link. - They could also do this type of queries after failures of full address queries. Problem: Privacy addresses, as specified today, cannot be distinguished with 100% certainety from addresses obtained with stateful DHCPv6. A proposal would be an addition to the privacy extension spec (rfc 4941). - A variant of privacy addresses would be defined for dsitinguishable privacy addresses. - These addresses would, for example, have FF00::/8 at the beginning of their IID (no currently specified IPv6 IID begins that way; randomness on 58 bits is good enough). - Then resolvers could recognize such privacy addresses for sure, and could query the reverse DNS with the generic privacy address only when this is appropriate. IMHO, this is a feasible step to reconcile: (1) privacy requirements of individuals; (2) desire to know which site is at the other end where and when such a desire exists. My desire to have privacy is, in itself, something I may want to keep private. If what you want to know is indeed which site is at the other end, wildcards at the /64 level will achieve that with no changes to existing code. Harald ___ IETF mailing list IETF@ietf.org http://www.ietf.org/mailman/listinfo/ietf
Re: PTR for IPv6 clients (Re: IPv6 NAT?)
Rémi Després wrote: My desire to have privacy is, in itself, something I may want to keep private. I am not sure I see the practical consequences. If my source address says I am someone but you will not know who I am, isn't this sufficient? You're not thinking this through. Think of the case where there are 1000 users on a LAN, and one of them desires to use the address privacy option for all the normal reasons. Then think about the policeman / bad guy / secret agent / mafioso with a trace of all traffic from that LAN - he can immediately say that the 999 were using non-privacy-enhanced addresses, and the resulting trace will show him immediately what the 1000th was up to, no matter how many times he changed his address. If what you want to know is indeed which site is at the other end, wildcards at the /64 level will achieve that with no changes to existing code. I am not familiar enough with wildcard operation in the DNS. If it provides for queries that concern only site prefixes, then you are right: no need for an agreed wildcard IID. The result is the same with existing mechanisms, which is clearly better. Read RFC 1034 - or perhaps better, RFC 4592. They've been around for a while (although their behaviour still surprises many). Harald ___ IETF mailing list IETF@ietf.org http://www.ietf.org/mailman/listinfo/ietf
Re: PTR for IPv6 clients (Re: IPv6 NAT?)
Iljitsch van Beijnum wrote: On 21 feb 2008, at 16:34, Harald Alvestrand wrote: Think of the case where there are 1000 users on a LAN, and one of them desires to use the address privacy option for all the normal reasons. Then think about the policeman / bad guy / secret agent / mafioso with a trace of all traffic from that LAN - he can immediately say that the 999 were using non-privacy-enhanced addresses, and the resulting trace will show him immediately what the 1000th was up to, no matter how many times he changed his address. I'm assuming you mean a trace of the activities of addresses from that LAN as seen from elsewhere, because if they can sniff the LAN they can also see the link addresses. But what the good/bad guy sees is 1099 addresses, 999 of which are used for somewhat long periods, and 100 of which are used for somewhat short periods. They don't know how many users there were on the LAN, although they can probably guess to within 10% or so based on the amount of traffic. They also don't have any way to know which user was using which privacy address at any given time unless they had a much more intimite view of the LAN in question. Unless you implement an identifiable format for privacy enhanced addresses; in that case they can 100% accurately say that 100 addresses were used by someone with something to hide. That was the idea I was trying to point out the bad sides of. ___ IETF mailing list IETF@ietf.org http://www.ietf.org/mailman/listinfo/ietf
PTR for IPv6 clients (Re: IPv6 NAT?)
Mark Andrews skrev: You also don't want to do it as you would also need massive churn in the DNS. Microsoft gets this wrong as they don't register the privacy addresses in the DNS which in turn causes services to be blocked because there is no address in the DNS. perhaps the advent of IPv6 will result in people finally (*finally*) giving up on this sorry excuse for a security blanket? (calling it a mechanism is too kind) Or perhaps it'll just make people register wildcard records at the /64 level in ip6.arpa :-( [EMAIL PROTECTED] (MY, what an useful reverse map!) ___ IETF mailing list IETF@ietf.org http://www.ietf.org/mailman/listinfo/ietf
Re: Call for Comment: RFC 4693 experiment
Cullen Jennings skrev: I'd like to comment as an individual on one part of our process for doing IONs. The process for publishing them has many bottlenecks and delays and we need a better way of doing it. If we decide to continue with IONs, I will provide detailed comments on issues with how we are doing them. Overall I think we would need tools so that an ION author can put a new version, reviewers could easily see the diffs from the previous version, and when the document is approved by the approving body, it gets posted and does not require manual editing of the document after it was approved. one comment... the procedure as described in the ION RFC has exactly two requirements: - that one should be able to tell who approved it, and when - that one should be able to tell the difference between a final document and a draft. I think we need to continue to have both of these properties. There's no requirement that a process exist for handling them, or even that it be consistent between IONs. The existing process is, deliberately, unconstrained by the RFC. I could argue that we might need fewer tools, not more; any tool you create increases the number of tools one has to learn in order to get one's job done. But that's part of what the experiment has been about. Harald ___ Ietf mailing list Ietf@ietf.org http://www.ietf.org/mailman/listinfo/ietf
Re: Call for Comment: RFC 4693 experiment
Cullen Jennings skrev: I'd like to comment as an individual on one part of our process for doing IONs. The process for publishing them has many bottlenecks and delays and we need a better way of doing it. If we decide to continue with IONs, I will provide detailed comments on issues with how we are doing them. Overall I think we would need tools so that an ION author can put a new version, reviewers could easily see the diffs from the previous version, and when the document is approved by the approving body, it gets posted and does not require manual editing of the document after it was approved. one comment... the procedure as described in the ION RFC has exactly two requirements: - that one should be able to tell who approved it, and when - that one should be able to tell the difference between a final document and a draft. I think we need to continue to have both of these properties. There's no requirement that a process exist for handling them, or even that it be consistent between IONs. The existing process is, deliberately, unconstrained by the RFC. I could argue that we might need fewer tools, not more; any tool you create increases the number of tools one has to learn in order to get one's job done. But that's part of what the experiment has been about. Harald ___ IETF-Announce mailing list IETF-Announce@ietf.org http://www.ietf.org/mailman/listinfo/ietf-announce
Re: Last Call: draft-carpenter-rfc2026-changes (Changes to the ..
Russ Housley skrev: Scott: There have been several attempts to generate discussion on prior versions of this document by its author. Very little resulted. I am using the Last Call to make sure that discussion happens, and it has worked. It has generated review, and not just superficial review. And the resulting comments are generating interesting discussion. Call a BOF on it. If not a WG. The discussion of a focused charter that could encompass this should be interesting. Using a Last Call as a wakeup call is a Bad Move. Harald ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Finding information
Henrik Levkowetz skrev: On 2008-01-21 11:24 Stephane Bortzmeyer said the following: On Sun, Jan 20, 2008 at 03:01:24AM -0800, Tony Li [EMAIL PROTECTED] wrote a message of 23 lines which said: Or, you can google IMAP and come up with 3501 straight away... Bad idea. Not only it makes the RFC process depend on an external organization, but it often fails for the reasons explained by the OP. For instance, googling Sieve does not bring back RFC 5228... Submitting 'sieve' in the document search form on http://tools.ietf.org/html returns 3028 as the first result, and a link to the htmlized 3028 which notes that it has been obsoleted by 5228. (I'm surprised that the search results doesn't already include 5228, too, but I expect they will fairly soon). The sieve WG web page also doesn't list 5228 as a product, so I guess some routine updates are on hold while the transition is taking place. Harald ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Call for Comment: RFC 4693 experiment
Being the RFC author, I'm naturally very much interested. still, I'll observe that the procedure that seemed most important to me, which was getting new versions out whenever they were needed, has been exercised exactly once: in http://www.ietf.org/IESG/content/ions/dated/, the only document in 2 versions is Brian's procdocs document. So the 3rd option in the evaluation process: 3. We cannot decide yet; the experiment should continue might be an option to seriously consider. (This of course has some disadvantages - for instance, we have discovered that we can't write text into a BCP that says the information about X is to be published as an ION before IONs are permanent. But perfection seems to escape us every time) Harald ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: I-D Action:draft-hoffman-tao4677bis-00.txt
Paul Hoffman skrev: At 12:50 PM +1300 1/18/08, Brian E Carpenter wrote: Added sentences to section 8.1 explaining that BCPs and FYIs are sub- series of Informational RFCs. Namely: The sub-series of FYIs and BCPs are comprised of Informational documents in the sense of the enumeration above, with special tagging applied. That's certainly true of the FYI series (which I believe the RFC Editor regards as dormant today). It absolutely is not true of the BCP series - they are single-stage normative documents, and not a subset of Informational documents. If there's text in RFC 2026 that implies otherwise, I need to update draft-carpenter-rfc2026-changes again. Note that Section 8.1 (which currently doesn't mention BCPs at all, and thus the needed change) talks about Informational documents, not Informational RFCs. That might be too clever of a differentiation. Would you be happier if the list above the text you quoted had seven entries instead of six, with Best current practices (BCP) documents as a new entry in the list? I would. Personally, I don't feel that RFC 2026 is clear enough on the status of BCPs, and we thus have BCPs whose meaning differs from what 2026 says BCPs are for. I don't think we can change 2026 in a way that won't invalidate some BCPs. Sure we can. A BCP is a document that is approved by the IESG as a BCP. :-) They are definitely not informational documents. (I long ago proposed splitting the series into the two effective subseries it has - process documents and forcefully recommended advice to operators/implementors - but that obvious move is Just Too Much Of A Hassle) Harald ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Should the RFC Editor publish an RFC in less than 2 months?
Tom.Petch wrote: I recall a recent occasion when the IESG withdrew its approval, for draft-housley-tls-authz-extns a document that both before and after its approval generated a lot of heat, within and without a WG. Presumably the expedited process would, or at least could, have seen that published as an RFC. With that example in mind, a 60 day hold seems rather a good idea. In that case, it went into the RFC Editor queue on June 30,, 2006, and was yanked from the queue on February 26, 2007 - 8 months later. According to the third last call announcement: On June 27, 2006, the IESG approved Transport Layer Security (TLS) Authorization Extensions, (draft-housley-tls-authz-extns) as a proposed standard. On November 29, 2006, Redphone Security (with whom Mark Brown, a co-author of the draft is affiliated) filed IETF IPR disclosure 767. it was five months between approval and the IPR disclosure. A two-month hold wouldn't have caught it. (No idea why it was still hanging there long enough for the IPR disclosure to catch up with it...) Harald ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Should the RFC Editor publish an RFC in less than 2 months?
IETF Chair skrev: Dear IETF Community: Due to a lot of hard work, the RFC Editor is publishing approved Internet-Drafts more quickly. Overall this is just what we want to happen. However, I am concerned that the RFC Editor is might be getting too quick. Anyone can appeal the approval of a document in the two months following the approval. In the past, there was not any danger of the RFC Editor publishing a document before this timer expired, and the only documents that became RFCs in less than 60 days were the ones where the IESG explicitly asked for expedited processing. The recent improvements by the RFC Editor make it likely that all documents will be moving through the publication process in less than two months. My short reply: Bad idea. In my opinion, placing such a hold on documents is a triumph of process over sanity. We have already lost the opportunity to restrict the circulation of the text when we published the I-D, which anyone in the world can copy. So the further aggravation of having copies out there of a document with an RFC number that isn't in the index any more is, if it is a difference at all, an extremely marginal one. So the remedy of making the text not published is already unavailable. In that case, the only difference between holding an approved document and then not publishing it and publishing an RFC and then withdrawing it is that in the latter case, we're left with a permanent mark in our RFC Index saying This RFC was withdrawn. (I know this option does not exist now, as Leslie pointed out. I have big problems seeing a situation where it would be appropriate, but if people really argue that we need it once we admit that we can't unpublish an I-D, we can change the rules.) If we err so egregriously as to end up in a situation where a retraction is the appropriate remedy (as opposed to the situation where we can publish another RFC saying on further consideration, the idea we approved in RFC was stupid, and we regret doing it; it's now Historic), having to live with the blame for such a mark forever is appropriate and just punishment. We're ALREADY in a no-hold situation in many cases; when someone appeals the decision on an appealed approval, we do NOT, in general, hold the publication of the RFC, even though we are not just afraid there'll be an appeal, we positively *know* that there is an appeal. The same thing applies for appeals against the RFC Editor/WG chair/author's decision to approve an AUTH48 change. Such a hold is a dumb idea, and we shouldn't do it. Just publish, and if we turn out to have made the wrong decision, make a public statement saying that; one form of public statement is leaving a hole in the RFC Index. (As to the ideas for further complexity in the process with provisional markers considered by Brian and John: My opinion is that they add cost, and in practice provide zero value. Just publish, and if needed, unlist.) Harald ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
NAT-PT (Re: FW: I-D Action:draft-narten-ipv6-statement-00.txt)
[EMAIL PROTECTED] skrev: ULA, No apparent consensus to do this. But is it needed to deploy IPv6? A lot of people say absolutely not. And if, during the next year or so of larger scale deployment of IPv6, we discover that ULA-C is needed, then it can be made available relatively quickly because it doesn't require upgrades to any existing IPv6 devices or software. Don't forget NAT-PT. Deprecated by the IETF because its not a good long-term idea, but it has already been deployed and if people can get some short term use out of it, the IETF only deprecates, it doesn't ban. ... I'd be even happier if the people who have deployed it come to the IETF and tell us where they have had to depart from the specs/add to the specs to get things to work properly (and whether or not some of those were in the areas worried about in the deprecation), so that we can have a spec for NAT-PT that is both useful and corresponding to someone's reality Harald, admitting to spinning out subthreads... ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Megatron
Brian E Carpenter skrev: Afaik, non-member postings to the list are automatically held in moderation to trap spam, and moderators are only human. And I do think that one reason why letter-writing campaigns against the IETF have been rare is that it's hard to argue that people who care *shouldn't* subscribe to the relevant mailing lists at least for the duration of the discussion - which means that they get copies of all the campaign letters too :-) Harald ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Offer of time on the IPR WG agenda for rechartering
Ted Hardie skrev: I'd like the people who want time on the agenda to supply a text (preferably published as an I-D), which summarizes, as clearly as possible: - What they think has changed since the last IPR WG evaluation of patent policy - What changes in overall direction they think the WG should address - What the charter for this activity should look like If more than one such proposal should appear, I'd suggest giving each submitter a 5-10 minute slot for making their argument, and leaving at least half an hour for general discussion. Please submit I-Ds with the name pattern of draft-submitter-ipr-patent-something - that would make it easy for us to find them all. The timeslot for the WG is Tuesday morning from 0900 to 1130; the rechartering discussion would be within the time from 1030 to 1130. Just to be clear, if someone has the view that documents like Simon's how-to should be within the charter of the working group, but that there are no changes needed to the base policy, do you still want an I-D? Or is a rationale submitted as a short statement enough? In the case of Simon's I-D, there is already an existing I-D, which (if I remember rightly - it's been a long time since I've read it) explains its rationale fairly well. So a simple request to have that placed on the agenda, with a brief statement of what the desired outcome is, should be enough. Harald ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Offer of time on the IPR WG agenda for rechartering
Lawrence Rosen skrev: Harald, I am unable to be in Vancouver for the meeting, but I hope that someone else there will support the re-charter of the IPR WG as I suggested in my earlier email: *** I request that we charter the IETF IPR-WG to propose policies and procedures, consistent with the worldwide mission of IETF, which will result in IETF specifications unencumbered by restrictive, non-free patents. *** Thanks for the comment. I look forward to seeing your I-D, and hope you will find someone to present it in Vancouver. I also hope that a decision on this will not be based simply on who attends in Vancouver, but on a wider representative vote of IETF participants. Since we don't vote, it won't be decided by a vote. I don't rule out opinion polls... ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: why can't IETF emulate IEEE on this point?
Chris Elliott wrote: You mean like: Cisco is the owner of US published patent applications 20050154872 and 20050154873 and one or more pending unpublished patent applications relating to the subject matter of Transport Layer Security (TLS) Session Resumption without Server Side State draft-salowey-tls-rfc4507bis-01.txt. If technology in this document is included in a standard adopted by IETF and any claims of any Cisco patents are necessary for practicing the standard, any party will have the right to use any such patent claims under reasonable, non-discriminatory terms, with reciprocity, to implement and fully comply with the standard. The reasonable non-discriminatory terms are: If this standard is adopted, Cisco will not assert any patents owned or controlled by Cisco against any party for making, using, selling, importing or offering for sale a product that implements the standard, provided, however that Cisco retains the right to assert its patents (including the right to claim past royalties) against any party that asserts a patent it owns or controls (either directly or indirectly) against Cisco or any of Cisco's affiliates or successors in title or against any products of Cisco or any products of any of Cisco's affiliates either alone or in combination with other products; and Cisco retains the right to assert its patents against any product or portion thereof that is not necessary for compliance with the standard. Royalty-bearing licenses will be available to anyone who prefers that option. Note that if: - Company A has a patent on nanosecond gate opening - Company A has issued the claim above, in conjunction with an IETF standard - Company B has a patent on the application of slow-drying oil paint - Company A paints their house with such an oil paint - Company B asserts their patent on slow-drying oil paint against company A then company B will automatically be the target for an assertion of the nanosecond patent against all its uses of that patent, past, present and future, within or outside the scope of the relevant IETF standard. It's a blanket license for use of the technology by any company that doesn't hold a patent, but it's definitely not a no strings attached policy. (that said, it is a LOT better than a we know something, but we're not telling policy) Harald ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: RFC 1345 mnemonics table not consistent with Unicode 3.2.0
John C Klensin wrote: --On Friday, 31 August, 2007 01:00 +0200 Harald Alvestrand [EMAIL PROTECTED] wrote: Harald, Ben has pointed out one important use for something like 1345, which involves references to characters in programming languages and command interfaces. The Unicode names are bad news for that, I certainly don't want characterNamed(SLOBBOVIAN LOWER CASE COMBINATION LEFT-HANDED SPANNER) in those contexts, and that is what Unicode would give me. Our current solution to that problem seems to be U+[N[N]], which is pretty unattractive (except when compared to all of the other alternatives). On the other hand, one could argue that 1345 inadvertently proves that no shorter set of mnemonics is going to work across all of Unicode without becoming pretty arbitrary and discriminatory against scripts not familiar to the creator as well as difficult to extend. Two different threads here: one about the idea of mnemonics, the other about this specific document's implementation of it... Actually I used 1345 mnemonics in a fairly hefty piece of work back in 1995 (draft-alvestrand-lang-char, I think the latest published version was -03). Ten years later, I'm unable to figure out what characters I was trying to point to in some cases; somehow, characters snuck in where it's obvious that the mnenmonic for X has to be *X, but 1345 doesn't provide a definition for *X. For cases where the correct mnemonic was +X and the draft specifies *X, it's impossible to tell by anything short of character-by-character lookup that I goofed. Based on that experience in working with 1345, I claim that the idea of a larger set of mnemonics than what one can memorize in an hour or two for handling data in a wider character set than the one you're writing in is a Bad Idea. Tried it, didn't work. In programming language constructs intended to be read and maintained by people who aren't familiar with the script they're maintaining and aren't willing to bother looking up the code every time they use it, characterNamed(SLOBBOVIAN LOWER CASE COMBINATION LEFT-HANDED SPANNER) is exactly the right construct, in my opinion; if people can read the script, an UTF-8 environment is a far cleaner solution than any possible mnemonic set. The second part of my criticism involves the tables in 1345 that claim to show existing character sets and what characters they contain. These tables are defined inconsistently with their base specifications (ISO 646 IRV-NO is a 94-character ISO 2022-based charcter set, but presented in 1345 as if it was an 128-character one, without explaining what control character set it is matched with to create that set, for instance), and, as Ned says, contain errors. Both are good reasons to ignore 1345 as it currently stands, in my opinion. If anyone wants to resolve the second by creating a revision, feel free. But I don't see how it can help with the first one. Harald ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RFC 1345 as an input method
One part I didn't catch when first replying to this thread was Ben's focus on input methods. I'm curious about that - could someone give more details? In particular: - Is there any consistency among the input methods in how mnemonics are framed? That is, how do you tell the IME that you're starting a mnemonic? Do you switch into mnemonic mode and type several of them, or do you enter them as leadin mnemonic leadin mnemonic? - How do the input methods deal with finding the end of a mnemonic? While a lot of character mnemonics of 1345 are 2-characer, there are a lot that are not , and there doesn't seem to be a consistent character set for intermediate and ending characters (16 is VULGAR FRACTION ONE SIXTH, while 16. is NUMBER SIXTEEN FULL STOP). I'm curious to learn about whether the IMEs (EMACS and SCIM was mentioned) actually use 1345 or some adapted subset of it - if the latter, documenting the adapted subset that has proved useful in practice might be a worthwhile exercise. Harald ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: RFC 1345 mnemonics table not consistent with Unicode 3.2.0
Lisa Dusseault wrote: If the IETF were to consider something like RFC1345 today, there would be a lot of questions like - whether a registry would be more appropriate than a static document, after all it's a set of fields that might be extended, - how one would determine whether any two implementations were interoperable, or if that's a sensible concept in this context - whether another standards organization wouldn't be a better place for detailed char set mappings For all I know those conversations occurred with RFC1345, but we'd still have them again :) I just feel like being blunt today: RFC 1345 was a bad idea at the time. It was published without IETF review, and contains errors, both in design and in details, that would have been caught if people who could have done the review had been asked to do so. RFC 1345 is best ignored. If you want to name characters, use Unicode. Harald ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: I-D ACTION:draft-wilson-class-e-00.txt
What happened to draft-hain-1918bis-01, which tried to get more address space for private Internets, but expired back in 2005? I see the point about regarding 240.0.0.0/4 as tainted space and therefore being less than useful on the public Internet. Harald Brian E Carpenter wrote: On 2007-08-07 16:15, [EMAIL PROTECTED] wrote: A New Internet-Draft is available from the on-line Internet-Drafts directories. Title: Redesignation of 240/4 from 'Future Use to Limited Use for Large Private Internets' Author(s): P. Wilson, et al. Filename: draft-wilson-class-e-00.txt Pages: 4 Date: 2007-8-7 This document directs the IANA to designate the block of IPv4 addresses from 240.0.0.0 to 255.255.255.255 (240.0.0.0/4) as unicast address space for limited use in large private Internets. It seems to me that we first need a discussion about why this space can't be released as public address space. Is it known to be already deployed as de facto private space? I'd be a bit nervous about unintended side effects if DHCP assigned me 255.255.255.255/32. Brian ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
