Re: [ietf-privacy] [Int-area] NAT Reveal / Host Identifiers
On 10/06/2014 04:43, Ted Lemon wrote: On Jun 9, 2014, at 12:32 PM, Eliot Lear l...@cisco.com wrote: But does adding a header solve the problem? Not unless it is signed AND I believe the signature. And then I had better be willing to spend the processing time to sort out your good customers from your bad customers. I might do that if you're at a very big mail service provider, in which case I probably get very little spam, anyway. I probably won't do that if you're Joe's small time ISP, unless there is some scaling feature not yet deployed today. Bingo. So, there are some more components of the threat analysis and the solution requirements. That's good, but I thought we were discussing whether to document the use cases. Brian ___ ietf-privacy mailing list ietf-privacy@ietf.org https://www.ietf.org/mailman/listinfo/ietf-privacy
Re: [ietf-privacy] [Int-area] NAT Reveal / Host Identifiers
Stephen, On 06/06/2014 00:48, Stephen Farrell wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hiya, On 05/06/14 08:05, Hannes Tschofenig wrote: If you want to review a document with privacy implications then have a look at the NAT reveal / host identifier work (with draft-boucadair-intarea-host-identifier-scenarios-04 currently in a call for adoption). I had raised my concerns several times now on the mailing list and during the meetings. I share those concerns. And adopting this without any consideration of BCP188 would fly in the face of a very recent, very thoroughly discussed, IETF consensus. I have to call you on that. WG adoption is not approval. It's agreement to work on a topic. It is not OK to attempt a pocket veto on adoption because you don't like the existing content. For something like this, the onus ought IMO be on the proposers to have done that work before asking for adoption. Why? Where do the rules say that? As a matter of fact I tend to agree with many of your criticisms of the draft, and I like the idea (below) of adding what we might call the misuse cases. That's a discussion the intarea WG could have. Brian Based on the draft, they clearly have not done that. We could also ask to add more use-cases: use-case#12: spy on everyone more easily, TEMPORA++ use-case#13: sell data that's even more fine-grained than clickstreams use-case#14: expose your n/w internals to help on path attackers use-case#15: track hosts from which people emit dangerous utterances use-case#16: block hosts from which people emit dangerous utterances use-case#17: charge me more for using two of my computers in my house The set of use-cases presented very much contradicts the explicit claim in the draft that no position is being taken as to the merits of this. IMO that argues strongly to not adopt this. One could also comment on the requirements that seem to require new laws of physics or are otherwise pretty odd: REQ#1: seems to require knowing from packets passing by that a device is a trusted device (and REQ#15 says that can be done with 16 bits;-) Hmm... are those qubits maybe? REQ#5: *all* IP packets MUST have a HOST_ID... but presumably without a flag day. Hmm... REQ#6: says this is a transport thing. Eh, why ask INT-AREA? REQ#10+REQ#11: MUST be intradomain only but MUST also be inter domain. Hmm... REQ#18: receiver MUST enforce policies like QoS. Huh? Such a frankly bogus list of requirements also means that this is not something that ought be adopted in the IETF. I also think that this proposal has previously been proposed in other ways and not adopted. Such forum-shopping is yet another reason to not adopt it, and certainly not as an area wg thing without any broader IETF-wide consideration. (As an aside: having to play whack-a-mole with such repeat proposals is one of the downsides of area wgs. Not sure if anything can be done about that though.) In summary: ignoring BCP188, the selection-bias in use cases, the badly thought out requirements and forum shopping are all independently sufficient reasons to not adopt this. And of course that doesn't include all the other issues with potential solutions listed in RFC6967 (the reference to which is oddly to the I-D and not the RFC). My conclusion: this one ought go to /dev/null same as the previous attempts to shop the same thing into other parts of the IETF. S Ciao Hannes Original Message Subject: [Int-area] Call for adoption of draft-boucadair-intarea-host-identifier-scenarios-04 Date:Thu, 5 Jun 2014 04:20:56 + From:Suresh Krishnan suresh.krish...@ericsson.com To: Internet Area int-a...@ietf.org Hi all, This draft was originally intended to be published as an AD sponsored submission from the OPS area, but the authors have expressed their interest to continue this work in the intarea wg given that RFC6269 and RFC6967 originated here. The draft has been updated to address the issues brought up during earlier discussions on the wg mailing list and the latest version of the draft is available at http://tools.ietf.org/html/draft-boucadair-intarea-host-identifier-scenarios-04 This call is being initiated to determine whether there is WG consensus towards adoption of draft-boucadair-intarea-host-identifier-scenarios-04 as an intarea WG draft. Please state whether or not you're in favor of the adoption by replying to this email. If you are not in favor, please also state your objections in your response. This adoption call will complete on 2014-06-19. Regards Suresh Juan Carlos ___ ietf-privacy mailing list ietf-privacy@ietf.org https://www.ietf.org/mailman/listinfo/ietf-privacy -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQEcBAEBAgAGBQJTkGcRAAoJEC88hzaAX42iFYYIAIlJHJE1BNetIdjhDTqlTfsX
Re: [ietf-privacy] [Int-area] NAT Reveal / Host Identifiers
On 06/06/2014 09:26, Ted Lemon wrote: On Jun 5, 2014, at 4:28 PM, Brian E Carpenter brian.e.carpen...@gmail.com wrote: I have to call you on that. WG adoption is not approval. It's agreement to work on a topic. It is not OK to attempt a pocket veto on adoption because you don't like the existing content. WG adoption is a pretty heavy action. It states that the WG has consensus to work on the document, and weighs heavily in the consensus evaluation during WGLC. If there are problems with the document, part of the adoption process should be the identification of those flaws and an agreement to address them. So bringing up those flaws during the adoption process is crucial to the process. I have no problem with that. It's also worth noting that the INTAREA working group is a special working group, with an extremely broad charter, Indeed. So (speaking only for myself) I tend to ignore drafts aimed at the WG until they are close to adoption, because my input bit rate is limited. Brian which is moderated by the fact that in order for work to be done by the working group, the Internet Area ADs have to approve the work. So needless to say I at least am watching keenly to see if Stephen's objections are being addressed, and likely won't approve the adoption of the work if they aren't. ___ ietf-privacy mailing list ietf-privacy@ietf.org https://www.ietf.org/mailman/listinfo/ietf-privacy
Re: [ietf-privacy] [Int-area] WG Adoption
On 06/06/2014 08:42, Joel M. Halpern wrote: Brian, in my experience working group adoption is more than the working group agreeing to work on the topic. It is generally the working group agreeing that the given document is a good basis for starting the work. Yes, there will almost always be need for improvement. Sometimes major improvement. But it is an agreement that this is a good starting point. Without commenting on the specific document, leaving out that consideration in your response to Stephen makes the discussion MUCH harder. Well, not harder than suggesting immediate /dev/null I think. Also, there is history here (RFC6269 and RFC6967) so I think it's clear that the topic is appropriate for the WG. There is a real problem caused by NAT, compared with the theoretically normal case where the host's globally unique address is visible to all. Brian Yours, Joel On 6/5/14, 4:28 PM, Brian E Carpenter wrote: ... I have to call you on that. WG adoption is not approval. It's agreement to work on a topic. It is not OK to attempt a pocket veto on adoption because you don't like the existing content. ... ___ ietf-privacy mailing list ietf-privacy@ietf.org https://www.ietf.org/mailman/listinfo/ietf-privacy
Re: Last Call: draft-ietf-6man-oversized-header-chain-08.txt (Implications of Oversized IPv6 Header Chains) to Proposed Standard
Fred, On 15/10/2013 06:38, Templin, Fred L wrote: ... We could have that discussion in 6man, sure, but I don't believe that it's relevant to the question of whether draft-ietf-6man-oversized-header- chain is ready. If it messes up tunnels, then it's not ready. That doesn't follow. See below. This draft mitigates a known problem in terms of the current IPv6 standards. If that problem is also mitigated by a measure that does not mess up tunnels, then wouldn't that be worth considering before finalizing this publication. The draft mitigates a known problem with communication paths that do not include nested tunnels requiring nested fragmentation, where the nested tunnel has to deal with an MTU 1280 *and* where the nested tunnel goes through a firewall that wants to analyse the complete header chain of the innermost packet. No, I don't think it's worth considering that case before specifying this mitigation. Brian
Terms and Conditions May Apply
I know we don't normally do movie plugs on this list, but anyone who's planning to attend the technical plenary in Vancouver could do worse than watch Terms and Conditions May Apply. It covers both commercial and governmental invasions of privacy, and how they are interlinked. http://www.imdb.com/title/tt2084953/ or http://tacma.net/ (but you might not want to click on the 'I agree' button until you've seen the movie...) Brian
Re: Of governments and representation (was: Montevideo Statement)
Hi John, On 12/10/2013 05:02, John Curran wrote: ... In my personal view, it is a very important for the IETF to select leadership who can participate in any discussions that occur, Without obsessing about the word leadership, but following up on a comment made by Noel Chiappa on the leader statements thread, I think we have to recognise that nothing in the NomCom process, the IAB Charter, or the IESG Charter, would cause us to select IAB or IETF Chairs who are particularly suited to this role. In fact I think that the plan of record is to leave such matters to ISOC. Reality is different - the outside world expects to hear from us. Brian
Re: Last Call: draft-ietf-6man-oversized-header-chain-08.txt (Implications of Oversized IPv6 Header Chains) to Proposed Standard
On 12/10/2013 06:04, Fernando Gont wrote: ... P.S.: Reegarding enforcing a limit on the length of the header chain, I must say I symphatize with that (for instance, check the last individual version of this I-D, and you'll find exactly that). But the wg didn't want that in -- and I did raise the issue a few times. So what we have is what the 6man wg had consensus on. I agree that this was the WG consensus after considerable discussion, which included Fred, so I'm not sure why we're discussing it again during IETF LC. Brian
Re: Last Call: draft-ietf-6man-oversized-header-chain-08.txt (Implications of Oversized IPv6 Header Chains) to Proposed Standard
Fred, On 12/10/2013 08:56, Templin, Fred L wrote: Hi Brian, -Original Message- From: Brian E Carpenter [mailto:brian.e.carpen...@gmail.com] Sent: Friday, October 11, 2013 12:50 PM To: Fernando Gont Cc: Templin, Fred L; Ray Hunter; 6man Mailing List; ietf@ietf.org Subject: Re: Last Call: draft-ietf-6man-oversized-header-chain-08.txt (Implications of Oversized IPv6 Header Chains) to Proposed Standard On 12/10/2013 06:04, Fernando Gont wrote: ... P.S.: Reegarding enforcing a limit on the length of the header chain, I must say I symphatize with that (for instance, check the last individual version of this I-D, and you'll find exactly that). But the wg didn't want that in -- and I did raise the issue a few times. So what we have is what the 6man wg had consensus on. I agree that this was the WG consensus after considerable discussion, which included Fred, so I'm not sure why we're discussing it again during IETF LC. Technical matters should be discussed as they come to light; not dismissed because of some real or perceived deadline. That was what got us the 1280 MTU in the first place. Quoting from Steve Deering: We would like to get this issue settled as soon as possible, since this is the only thing holding up the publication of the updated Proposed Standard IPv6 spec (the version we expect to advance to Draft Standard), so let's see if we can come to a decision before the ID deadline at the end of next week (hoping there isn't any conflict between thoughtful analysis and let's decide quickly :-). So, it wasn't necessarily the case that 1280 was a product of thoughtful analysis so much as the fact that **they were rushing to get a spec out the door**. So now, 16 years later, we get to put it back on the 6man charter milestone list. We could have that discussion in 6man, sure, but I don't believe that it's relevant to the question of whether draft-ietf-6man-oversized-header-chain is ready. This draft mitigates a known problem in terms of the current IPv6 standards. Brian
Re: leader statements
On 11/10/2013 07:52, Noel Chiappa wrote: From: Arturo Servin arturo.ser...@gmail.com Then we have a big problem as organization, we are then leaderless. I'm not sure this is true. The IETF worked quite well (and produced a lot of good stuff) back in, e.g. the Phill Gross era, when I am pretty sure Phill's model of his job was indeed as a 'facilitator', not a 'leader' in the sense you seem to be thinking of. So why do we now need a 'leader'? We have a collective leadership, which is quite a good system as long as it avoids groupthink, and I think the IETF community is talkative enough to reduce (not eliminate) that risk. But when we're invited to wider inter-organisation meetings, we can't all go, and the ones who do go are certain to be viewed as our leaders by the other organisations. Inevitably, it's the Chairs who get invited; up to them to delegate if they want. Brian
Re: leader statements
On 10/10/2013 08:27, Andrew Sullivan wrote: ... What I am not sure about is whether people are willing to accept the chairs acting in that sort of leader of organization role. If we do accept it, then I think as a consequence some communications will happen without consultation. For a CEO is not going to agree to issue a joint communiqué with someone who has to go negotiate the contents of that communiqué (and negotiate those contents in public). If we do not accept it, then we must face the fact that there will be meetings where the IETF or IAB just isn't in the room, because we'll have instructed the chairs not to act in that capacity. I've been there in the past, as IAB Chair, ISOC Board Chairman, and IETF Chair. Either we trust our current and future chairs, on certain occasions, to speak in our name without there being a discursive debate in advance, or we will have no voice on those occasions. If there was a pattern of I* chairs subscribing to statements that the relevant community clearly found quite outrageous, there might be an argument for having no voice. I suggest that there is no such pattern. There may be quibbles over wording sometimes, but that is inevitable when several different stakeholder organisations have to agree on wording. The wording is inevitably a compromise; it can't be otherwise. It's perfectly reasonable to ask our chairs to invite debate in advance when that is possible; but in many of these cases, it simply isn't. It's also perfectly reasonable that people should comment on the wording even after it's set in stone; that helps us to do better next time. If we nominate good candidates for our leadership positions, and send thoughtful comments to the NomCom (and the IESG and IAB for their nominating duties), we won't get leaders who put their names to anything outrageous. We should trust our chairs to act as figureheads and leaders towards the outside world. Brian Carpenter
Re: Last Call: draft-ietf-6man-oversized-header-chain-08.txt (Implications of Oversized IPv6 Header Chains) to Proposed Standard
Fred, See below... On 10/10/2013 06:42, Templin, Fred L wrote: Hi Ole, -Original Message- From: Ole Troan [mailto:otr...@employees.org] Sent: Wednesday, October 09, 2013 10:31 AM To: Templin, Fred L Cc: Ronald Bonica; i...@ietf.org; ietf@ietf.org Subject: Re: Last Call: draft-ietf-6man-oversized-header-chain-08.txt (Implications of Oversized IPv6 Header Chains) to Proposed Standard Fred, -Original Message- From: Ronald Bonica [mailto:rbon...@juniper.net] Sent: Tuesday, October 08, 2013 5:46 PM To: Ole Troan; Templin, Fred L Cc: i...@ietf.org; ietf@ietf.org Subject: RE: Last Call: draft-ietf-6man-oversized-header-chain- 08.txt (Implications of Oversized IPv6 Header Chains) to Proposed Standard I agree with Ole. How so? A tunnel that crosses a 1280 MTU link MUST fragment in order to satisfy the IPv6 minMTU. If it must fragment, then an MTU-length IPv6 header chain would not fit within the first fragment, and we have opened an attack vector against tunnels. This is not a matter to be agreed or disagreed with - it is a simple fact. right, and RFC2460 has this to say about it: IPv6 requires that every link in the internet have an MTU of 1280 octets or greater. On any link that cannot convey a 1280-octet packet in one piece, link-specific fragmentation and reassembly must be provided at a layer below IPv6. Very true. In this case, the link is the tunnel and the link- specific fragmentation is IPv6 fragmentation. Which places the first part of an MTU-length IPv6 header chain in the first fragment and the remainder of the header chain in the second fragment. indeed. which would violate the MUST in oversized-header-chain. what do we do? a) ignore this particular corner case b) suggest the tunnel head end to drop the packet c) develop a new tunnel segmentations scheme that doesn't depend on IPv6 fragmentation. :-) You know I have an interest in alternative c), but that does not address the issue of splitting the header chain across multiple fragments. So, my choice is: d) limit the size of the IPv6 header chain so that the chain will fit within the first fragment by having the host limit the chain to the MTU size minus 256 bytes. Actually, I would be even happier if we just asked the host to limit the size of the header chain to 1024 bytes regardless of the path MTU. Since the problem recurses as we tunnel tunnels, I don't see how any finite limit can solve the problem. 1280 itself is a pragmatic choice of a bit shorter than 1500. The problem is that you are asserting that middleboxes that a tunnel passes through are expected to examine the complete header chain of the encapsulated packet even if the encapsulated packet is a fragment. I think that's an unreasonable expectation. A reasonable expectation is that middleboxes should identify the encapsulated packet as a payload that they cannot analyse, and let it go (unless they have a policy setting to drop tunnelled packets, which is a different discussion). I understood that to be the basis on which the WG reached consensus. Brian
Re: leader statements
Björn, On 10/10/2013 10:21, Bjoern Hoehrmann wrote: * Brian E Carpenter wrote: Either we trust our current and future chairs, on certain occasions, to speak in our name without there being a discursive debate in advance, or we will have no voice on those occasions. We should think before we speak, and discursive debate is our collective thought process. Accordingly I would expect Chairs to anticipate and fa- cilitate debates that might be necessary or useful, especially on issues where they find giving the collective a voice may be important. It seems implausible to me that there would be notably many such occasions. Maybe because as German I am inclined towards disregarding phatic expressions. I assure you that after looking up phatic I feel the same way. And I agree with your point: when there's time to consult the community, of course it should be done. But sometimes there isn't time, which is when IMHO we should show some trust in our various Chairs. Brian
Re: Last Call: draft-resnick-on-consensus-05.txt (On Consensus and Humming in the IETF) to Informational RFC
On 08/10/2013 08:03, Ted Hardie wrote: ... were. On the second point, the truth is that informational RFCs are [not] treated as actual requests for comments much any more, but are taken as fixed; I've inserted the not that Ted certainly intended. But I think he raises an important point. If the phrase Request For Comments no longer means what it says, we need another RFC, with a provisional title of Request For Comments Means What It Says. We still see comments on RFC 791 reasonably often, and I see comments on RFC 2460 practically every day. That's as it should be. So I'd like to dispute Ted's point that by publishing a version of resnick-on-consensus as an RFC, we will engrave its contents in stone. If that's the case, we have an even deeper problem than misunderstandings of rough consensus. otoh Ted's specific points on the draft are all valuable. Brian
Re: independant submissions that update standards track, and datatracker
The place to go is definitely not the page for a closed WG. How can that be expected to track things that happened after the WG closed? Since it's a BCP, you get the lot at http://www.rfc-editor.org/info/bcp10 or http://www.rfc-editor.org/bcp/bcp10.txt. In this particular case, you can also find it at http://www.ietf.org/about/process-docs.html#anchor5 Regards Brian On 02/10/2013 07:35, Adrian Farrel wrote: Not to detract from your point, Michael, but http://datatracker.ietf.org/doc/search/?name=nomcomrfcs=onsort= is pretty good. Adrian -Original Message- From: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On Behalf Of Michael Richardson Sent: 01 October 2013 19:29 To: ietf@ietf.org; tools-disc...@ietf.org Subject: independant submissions that update standards track, and datatracker This morning I had reason to re-read parts of RFC3777, and anything that updated it. I find the datatracker WG interface to really be useful, and so I visited http://datatracker.ietf.org/wg/nomcom/ first. I guess I could have instead gone to: http://www.rfc-editor.org/info/rfc3777 but frankly, I'm often bad with numbers, especially when they repeat... (3777? 3737? 3733?) While http://datatracker.ietf.org/wg/nomcom/ lists RFC3777, and in that line, it lists the things that update it, it doesn't actually list the other documents. Thinking this was an error, I asked, and Cindy kindly explained: http://datatracker.ietf.org/wg/nomcom/ lists the documents that were published by the NOMCOM Working Group. The NOMCOM Working Group was open from 2002-2004, and only produced one RFC, which is RFC 3777. The RFCs that update 3777 were all produced by individuals (that is, outside of the NOMCOM Working Group), and so aren't listed individually on the NOMCOM Working Group documents page. I wonder about this as a policy. Seeing the titles of those documents would have helped me find what I wanted quickly (RFC5680 it was)... While I think that individual submissions that are not the result of consensus do not belong on a WG page. But, if the document was the result of consensus, but did not occur in a WG because the WG had closed, I think that perhaps it should appear there anyway. -- Michael Richardson mcr+i...@sandelman.ca, Sandelman Software Works
Re: IPR Disclosures for draft-ietf-xrblock-rtcp-xr-qoe
On 17/09/2013 05:34, Alan Clark wrote: ... It should be noted that the duty to disclose IPR is NOT ONLY for the authors of a draft, and the IETF reminder system seems to be focused solely on authors. The duty to disclose IPR lies with any individual or company that participates in the IETF not just authors. Companies don't participate in the IETF; the duty of disclosure is specifically placed on individual contributors and applies to patents reasonably and personally known to them. IANAL but I did read the BCP. Brian
[Fwd: I-D Action: draft-carpenter-prismatic-reflections-00.txt]
I got my arm slightly twisted to produce the attached: a simple concatenation of some of the actionable suggestions made in the discussion of PRISM and Bruce Schneier's call for action. Brian Original Message Subject: I-D Action: draft-carpenter-prismatic-reflections-00.txt Date: Thu, 19 Sep 2013 21:47:18 -0700 From: internet-dra...@ietf.org Reply-To: internet-dra...@ietf.org To: i-d-annou...@ietf.org A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Prismatic Reflections Author(s) : Brian Carpenter Filename: draft-carpenter-prismatic-reflections-00.txt Pages : 9 Date: 2013-09-19 Abstract: Recent public disclosure of allegedly pervasive surveillance of Internet traffic has led to calls for action by the IETF. This draft exists solely to collect together a number of possible actions that were mentioned in a vigorous discussion on the IETF mailing list. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-carpenter-prismatic-reflections There's also a htmlized version available at: http://tools.ietf.org/html/draft-carpenter-prismatic-reflections-00 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ ___ I-D-Announce mailing list i-d-annou...@ietf.org https://www.ietf.org/mailman/listinfo/i-d-announce Internet-Draft directories: http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
Re: I-D Action: draft-kolkman-proposed-standards-clarified-02.txt
Is it just me, or does this sentence now seem like hubris? In fact, the IETF review is more extensive than that done in other SDOs owing to the cross- area technical review performed by the IESG, a position that is further strengthened by the common presence of interoperable running code and implementation before publication as a Proposed Standard. At the least, I would prefer to see it start thus: The IETF review is possibly more extensive than ... Regards Brian
Re: Why we don't want to actually replace 2026
On 17/09/2013 17:49, S Moonesamy wrote: Hi John, At 08:31 16-09-2013, John C Klensin wrote: By the way, while I understand all of the reasons why we don't want to actually replace 2026 (and agree with most of them), things are getting to the point that it takes far too much energy to actually figure out what the rules are. Perhaps it is time for someone to create an unofficial redlined version of 2026 that incorporates all of the changes and put it up on the web somewhere. I think we would want a clear introduction and I posted draft-moonesamy-stds-process-00 (expired) [1] in 2010. I have to update the draft as it does not take into account the two-track change. I would not post a revision on the web as the IETF Trust might not like it. In my opinion it might be related to the original negotiating position of CNRI. For some years I've maintained http://www.ietf.org/about/process-docs.html to assist IETF participants in navigating the labyrinth. It does carefully avoid red-lining or commentary, and I think it also shows the complexity that we have created. Brian Regards, S. Moonesamy 1. http://tools.ietf.org/html/draft-moonesamy-stds-process-00
Re: [IETF] Re: ORCID - unique identifiers for contributors
On 18/09/2013 09:11, Melinda Shore wrote: On 9/17/13 1:08 PM, Warren Kumari wrote: On Sep 17, 2013, at 4:52 PM, Yoav Nir y...@checkpoint.com wrote: Having an IETF identity is OK if all you ever publish is in the IETF. Some of our participants also publish at other SDOs such as IEEE, W3C, ITU, and quite a few publish Academic papers. Using the same identifier for all these places would be useful, Would it? Why? It's useful to librarians/archivists/people who organize things. It's very useful to people who maintain citation databases, where uniquely identifying authors is necessary. It's practically essential for academics whose career depends on attribution of publications and on citation counts (and for the people who hire or promote them). At first sight, it doesn't seem to matter too much for the IETF itself, until the day we have two authors with the same name, or one author with two names. I think we have several instances of the latter, and I can't really tell you easily if the following set of RFC authors contains 10 people or more: A. Li, C. Li, D. Li, H. Li, J. Li, K. Li, T. Li, X. Li, Y. Li, Z. Li. A. Li, who authored RFC 2363, is an especially interesting case. Probably the same person as A. Lin, who authored RFC 2764, but worked for a different company. I see that R.T. Braden, R. Braden and B. Braden have all authored RFCs. One person or three? In other words, objective identification would actually help sometimes. Brian
Re: ORCID - unique identifiers for contributors
On 17/09/2013 02:39, Andy Mabbett wrote: [First post here] Hello, I'm a contributor to RFC 6350 - but I'm listed there by name only, and there is nothing to differentiate me from some other Andy Mabbett (the problem is no doubt worse for people with less unusual family names). Like many such contributors, I don't want to publish my email address as an identifier, in case I get spammed, and if I give an affiliation or even the URL of my website, that may change over time. This problem is addressed by Open Research Contributor Identifiers (ORCID; http://orcid.org), UIDs (and URIs) for scientific and other academic authors. Mine is below. The idea is interesting, but I don't understand the security model. How do I know that the sender of this message actually has the right to claim the ORCID in question (-0001-5882-6823)? The web page doesn't present anything (such as a public key) that could be used for authentication. Brian
Re: IPR Disclosures for draft-ietf-xrblock-rtcp-xr-qoe
On 17/09/2013 08:10, Ted Lemon wrote: On Sep 16, 2013, at 3:51 PM, Ted Lemon ted.le...@nominum.com wrote: This is a claim in the boilerplate which the IETF, not the authors, are making. I am sure flames are already directed my way for being imprecise here, but what I mean is that although the authors put this boilerplate in the document, the IETF, through the document publication process, effectively affirms that the authors have made this claim, so it's entirely reasonable for us to double-check that all of the authors of a document know they are making this claim, and that it isn't something that one author put in without asking the others about it, and that all the authors actually understand what the boilerplate says. Yes. And as an author, I have never been offended by being asked, for recent RFCs, if I had in fact done what the BCPs specify, which is to disclose (or arrange to be disclosed) IPR of which I was reasonably and personally aware. I believe this question was added to the procedure after one or two cases where authors had not done so. Brian
Re: ORCID - unique identifiers for contributors
On 17/09/2013 11:19, Melinda Shore wrote: On 9/16/13 1:02 PM, Yoav Nir wrote: If we use ORCID instead of email, we get less strong authentication. That's not its job - it's there to distinguish between authors with similar names. Fair enough, but adding a public key to the record would enable authentication too. As I understand the proposal the intent is to have it provide additional information, not supplant anything. There is currently no identifier that provides that kind of discrimination. I wonder about that, but this is certainly a decent option. I can see it being especially valuable for people who change their name but want to keep a unified publication history. Also for people who've published under legitimate variants (B Carpenter, B E Carpenter, Brian Carpenter and Brian E Carpenter have all published, and brian.e.carpen...@gmail.com asserts that they are all the same person, except for the ones that aren't). I don't see any real downside to allowing people who have ORCIDs to put them in IETF documents. Agreed. Brian I'm not sure there's a lot of demand for them (this is the first time it's come up, as far as I know) but I don't see a problem with plopping one more piece of information - one that has a unique function - into our docs. Melinda
Re: Practical issues deploying DNSSEC into the home.
On 11/09/2013 09:59, Olafur Gudmundsson wrote: ... My colleagues and I worked on OpenWrt routers to get Unbound to work there, what you need to do is to start DNS up in non-validating mode wait for NTP to fix time, then check if the link allows DNSSEC answers through, at which point you can enable DNSSEC validation. Hopefully you also flush the DNS cache as soon as NTP runs. Even so, paranoia suggests that a dodgy IP address might still be cached in some app. Brian
What real users think [was: Re: pgp signing in van]
On 10/09/2013 01:58, Ted Lemon wrote: ... Seriously, this perfectly illustrates the reason why PGP hasn't seen widespread deployment: it doesn't address a use case that anybody understands or cares about, True story: Last Saturday evening I was sitting waiting for a piano recital to start, when I overheard the person sitting behind me (who I happen to know is a retired chemistry professor) say to his companion Email is funny, you know - I've just discovered that when you forward or reply to a message, you can just change the other person's text by typing over it! You'd have thought they would make that impossible. Yes, they should have made that impossible. Brian
Re: What real users think [was: Re: pgp signing in van]
On 10/09/2013 08:39, Steve Crocker wrote: Yes, I am speaking of what would be possible today with a fresh start. The fresh start would also include signatures and encryption as a required part of the design. (If everyone has to have a key, the key management problems would be greatly reduced.) Indeed. How one achieves such a fresh start is unclear. (Excuse my ignorance, but do existing MUAs allow one to edit a body part that arrived with a PGP signature?) Brian Steve On Sep 9, 2013, at 4:36 PM, Dave Crocker d...@dcrocker.net wrote: On 9/9/2013 1:27 PM, Steve Crocker wrote: Actually, I interpret the chemistry professor's comment in a different light. It would be possible to design a system where: o the standard end user software doesn't facilitate editing the other person's text, and o each piece of text is signed. The result would be a system where a recipient would know whether the person who is alleged to have written a piece of the message actually did so, and the normal mode of use would be to leave things untouched. Or, if you edit someone else's text, it immediately becomes your text. The professor's comment was on function, not method. My comment was on the limitations to methods available at the time. In a controlled environment, with good resources, quite a bit is possible. Indeed, server-based department-level email products in the 1980s did enforce such restrictions. The single-administration servers had complete control over the message. Distribution with independent administrative authorities makes this a very different game. Enforcement by fiat is impossible. That's where signing comes in, of course. Modify the content and the signature fails. Besides the computational overhead -- which was relatively onerous back when the infrastructure was being established -- this requires that the receiver know and demand that the signature be present; this requirement has its own adoption barriers. Starting with a blank sheet and today's technologies, the requirement is possibly feasible to satisfy -- if we ignore the continuing human factors barriers to large scale email authentication. However given the resources at the time the operational service was developed, I think it wasn't. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net
Re: Equably when it comes to privacy
On 09/09/2013 03:03, Phillip Hallam-Baker wrote: On Sun, Sep 8, 2013 at 10:27 AM, Noel Chiappa j...@mercury.lcs.mit.eduwrote: Probably best if we keep the politics off the IETF list. Noel I grew up in politics. There is a method to my approach here. Nevertheless, it is the wrong method here. Brian
Re: decentralization of Internet (was Re: Bruce Schneier's Proposal to dedicate November meeting to saving the Internet from the NSA
On 07/09/2013 08:55, Tim Chown wrote: On 6 Sep 2013, at 21:32, Roger Jørgensen rog...@gmail.com wrote: On Fri, Sep 6, 2013 at 9:47 AM, Adam Novak interf...@gmail.com wrote: The IETF focused on developing protocols (and reserving the necessary network numbers) to facilitate direct network peering between private individuals, it could make it much more expensive to mount large-scale traffic interception attacks. Think there are work being done on the topic? However, how are you going to interconnect all of this private peerings? It sort of imply that everyone need to have their own netblock they can exchange with others. Mobile IPv6 gives one way to run multiple devices in one subnet. Someone needs to be the HA though. And/or if future homes have multiple /64's, it's not infeasible to dedicate one or more to virtual/overlay LANs. It serves no purpose as long as there's an underlying customer/provider relationship, because it's the provider that is suborned by the government agency. Brian
Teachable moment
Ted, On 07/09/2013 03:32, Ted Lemon wrote: On Sep 6, 2013, at 2:46 AM, SM s...@resistor.net wrote: At 20:08 05-09-2013, Ted Lemon wrote: I think we all knew NSA was collecting the data. Why didn't we do something about it sooner? Wasn't it an emergency when the PATRIOT act was passed? We certainly thought it was an emergency back in the days of Skipjack, but then they convinced us we'd won. Turns out they just went around us. I would describe it as a scuffle instead of a battle. My guess is that the IETF did not do anything sooner as nobody knows what to do, or it may be that the IETF has become conservative and it does not pay attention to the minority report. It was definitely a battle. There were threats of imprisonment, massive propaganda dumps (think of the children!), etc. People broke the law, moved countries, etc. We just forget it because we won it, and it seems smaller in memory than it was when it was happening. The IETF didn't do anything because the tin foil hat contingent didn't have consensus, and we had no data to force the point. As you alluded to earlier, it's historically been very difficult to get people to treat security and privacy seriously, and frankly it still is. So this isn't an emergency. It's a teachable moment. We should pay attention. Absolutely. I have noted at least 20 messages in the recent flood that mention useful things the IETF can do, which is exactly what my provocative message asked for. But (as Bruce's own recent posts show) the main weak spots are not protocols and algorithms. Brian
Re: Last Call: draft-resnick-retire-std1-00.txt (Retirement of the Internet Official Protocol Standards Summary Document) to Best Current Practice
I tend to agree with Pete - the minutes are more like an official record, as well. BTW, the IESG Charter (RFC 3710) says: The IESG publishes a record of decisions from its meetings on the Internet,... In any case, apart from this detail, I think the draft is good to go. Brian On 06/09/2013 10:20, Pete Resnick wrote: On 9/5/13 2:45 PM, Scott O Bradner wrote: looks good to me except that maybe using the IETF Announce list rather than IESG minutes as the publication of record The only reason I went with the IESG minutes is because they do state the pending actions too, as well as the completed ones, which the IETF Announce list does not. For instance, the IESG minutes say things like: The document remains under discussion by the IESG in order to resolve points raised by... The document was approved by the IESG pending an RFC Editor Note to be prepared by... The document was deferred to the next teleconference by... The minutes also of course reflect all of the approvals. So they do seem to more completely replace what that paragraph as talking about. And we have archives of IESG minutes back to 1991; we've only got IETF Announce back to 2004. I'm not personally committed to going one way or the other. The minutes just seemed to me the more complete record. pr
Re: Bruce Schneier's Proposal to dedicate November meeting to saving the Internet from the NSA
I'm sorry, I don't detect the emergency. I'm not saying there's no issue or no work to do, but what's new about any of this? Was PRISM a surprise to anyone who knew that the Five Eyes sigint organisations have been cooperating since about 1942 and using intercontinental data links since 1944)? Was Xkeyscore a surprise to anyone who's been observing the whole Big Data scene? Is any ISP or router vendor actually unaware of the security issues in routers? Aren't most of them o/s implementation issues in any case? Hasn't the IETF been working on BGP4 security for quite a while now? I'm very glad we did RFC 1984 and RFC 2804 when we did, but it's probably more important that we did RFC 3552. We certainly need to apply it. I am against any panic response to the hype. If someone can identify any specific, new, protocol-based threats in the recent media stories, that would be worth an I-D and appropriate IETF action. Regards Brian Carpenter On 06/09/2013 12:46, Lucy Lynch wrote: On Thu, 5 Sep 2013, Dean Willis wrote: This is bigger than the perpass list. I suggested that the surveillance/broken crypto challenge represents damage to the Internet. I'm not the only one thinking that way. an additional call to action can be found here: http://www.newamerica.net/pressroom/2013/statement_oti_statement_on_new_leaks_of_nsa_defeating_encryption_technology_3 In the interim, technologists need to take a hard look at how to reengineer the Internet to avoid this type of massive undermining of our privacy rights. Our current trajectory is toward a more fractured, less safe Internet, and only major, meaningful reforms will restore trust and prevent even more detrimental outcomes. I'd like to share the challenge raised by Bruce Schneier in: http://www.theguardian.com/commentisfree/2013/sep/05/government-betrayed-internet-nsa-spying To quote: --- We need to know how exactly how the NSA and other agencies are subverting routers, switches, the internet backbone, encryption technologies and cloud systems. I already have five stories from people like you, and I've just started collecting. I want 50. There's safety in numbers, and this form of civil disobedience is the moral thing to do. Two, we can design. We need to figure out how to re-engineer the internet to prevent this kind of wholesale spying. We need new techniques to prevent communications intermediaries from leaking private information. We can make surveillance expensive again. In particular, we need open protocols, open implementations, open systems – these will be harder for the NSA to subvert. The Internet Engineering Task Force, the group that defines the standards that make the internet run, has a meeting planned for early November in Vancouver. This group needs dedicate its next meeting to this task. This is an emergency, and demands an emergency response. The gauntlet is in our face. What are we going to do about it? -- Dean Willis
Re: Bruce Schneier's Proposal to dedicate November meeting to saving the Internet from the NSA
On 06/09/2013 15:08, Ted Lemon wrote: On Sep 5, 2013, at 9:36 PM, Brian E Carpenter brian.e.carpen...@gmail.com wrote: I'm sorry, I don't detect the emergency. I think we all knew NSA was collecting the data. Why didn't we do something about it sooner? Wasn't it an emergency when the PATRIOT act was passed? We certainly thought it was an emergency back in the days of Skipjack, but then they convinced us we'd won. Turns out they just went around us. Tell me what the IETF could be doing that it isn't already doing. I'm not talking about what implementors and operators and users should be doing; still less about what legislators should or shouldn't be doing. I care about all those things, but the question here is what standards or informational outputs from the IETF are needed, in addition to what's already done or in the works. I don't intend that to be a rhetorical question. Brian
Re: Last Call: draft-resnick-retire-std1-00.txt (Retirement of the Internet Official Protocol Standards Summary Document) to Best Current Practice
On 04/09/2013 04:16, Pete Resnick wrote: On 9/3/13 9:32 AM, Bradner, Scott wrote: the quoted text came from RFC 1602 and is descriptive not proscriptive removing a description of a process that is no longer followed makes sense to me but might not warrant a RFC to do but the 3rd paragraph in section 6.1.3 says: The RFC Editor shall publish periodically an Internet Official Protocol Standards RFC [1], summarizing the status of all Internet protocol and service specifications. is a process requirement - this requirement is the specific text that should be removed and is worth spinning a RFC to do Good catch. I'll switch the citation and the quote to the bit from 6.1.3, but I'll also note the removal of the piece in 2.1. I also found a mention in the last paragraph of 3.3. I'll make sure to note in the document that we're removing that too. and while you are at it - maybe you should remove the 2nd paragraph in the same section An official summary of standards actions completed and pending shall appear in each issue of the Internet Society's newsletter. This shall constitute the publication of record for Internet standards actions. should also be removed since that is not being done either and it is not good to say we have a publication of record that does not actually exist I agree it should probably be removed. Should we replace it anything? Maybe an informational statement that the current standards status is always at http://www.rfc-editor.org/rfcxx00.html ? (Or whatever stable URL the RFC Editor prefers to cite.) Brian
Re: Last Call: draft-resnick-retire-std1-00.txt (Retirement of the Internet Official Protocol Standards Summary Document) to Best Current Practice
Comment at the end... On 04/09/2013 08:58, Spencer Dawkins wrote: On 9/3/2013 3:49 PM, Bradner, Scott wrote: in line On Sep 3, 2013, at 4:45 PM, Pete Resnick presn...@qti.qualcomm.com wrote: at it - maybe you should remove the 2nd paragraph in the same section An official summary of standards actions completed and pending shall appear in each issue of the Internet Society's newsletter. This shall constitute the publication of record for Internet standards actions. should also be removed since that is not being done either and it is not good to say we have a publication of record that does not actually exist I agree it should probably be removed. Should we replace it anything? Maybe an informational statement that the current standards status is always at http://www.rfc-editor.org/rfcxx00.html ? (Or whatever stable URL the RFC Editor prefers to cite.) I've fixed the reference to [STDS-TRK] so that it shows the URL. I'm not sure we need to make further reference to it. Thinking about this more, we're starting to drift afield of the purpose of this document if we start removing that paragraph. Removing that paragraph requires a different explanation than the rest. Speaking for myself only, I'm leaning against dealing with it. Anyone want to speak strongly for or against? I agree that the explanation is different, but I go back to Scott's it is not good to say we have a publication of record that does not actually exist. Not that Pete and I get paid by the document on telechat agendas, but is this another candidate for a short draft? rant class=shortSo that the reader of RFC 2026 will need to read yet another document to get the full picture? There are currently 8 RFCs that update RFC 2026, some of which have been updated themselves./rant Quite seriously - I appreciate Pete's reluctance to overload the draft, but it is a related topic. I'd be inclined to include it. Brian
Re: Last Call: draft-resnick-retire-std1-00.txt (Retirement of the Internet Official Protocol Standards Summary Document) to Best Current Practice
On 04/09/2013 11:20, Spencer Dawkins wrote: On 9/3/2013 6:02 PM, Pete Resnick wrote: On 9/3/13 3:17 PM, Brian E Carpenter wrote: rant class=shortSo that the reader of RFC 2026 will need to read yet another document to get the full picture? There are currently 8 RFCs that update RFC 2026, some of which have been updated themselves./rant Quite seriously - I appreciate Pete's reluctance to overload the draft, but it is a related topic. I'd be inclined to include it. OK, does this do anything for anyone? Finally, RFC 2026 [RFC2026] section 6.1.3 also calls for the publication of an official summary of standards actions completed and pending in the Internet Society's newsletter. This has also not been done in recent years, and the publication of record for standards actions has for some time been the minutes of the IESG. [IESG-MINUTES] Therefore, that paragraph is also effectively removed from section 6.1.3. That would work for me. Spencer Me too. Brian
Re: PS Characterization Clarified
Hi Jari, On 03/09/2013 02:23, Jari Arkko wrote: ... At the time of this writing, the IETF operates as if the Proposed Standard was the last chance for the to ensure the quality of the technology and the clarity of the standards document. There's a point that I think should be made here, something like: In practice, interoperable implementations are commonly based on Proposed Standard documents, so whatever design defects those documents have tend to become part of the interoperable network, perhaps in the form of work-arounds. Similarly, in today's Internet, any security defects tend to be exploited at an early stage. Fixing design and security issues in widely deployed code may be difficult or impossible in practice. Therefore, there is now very strong pressure to make the Proposed Standard as mature as possible, rather than being just good enough to meet the RFC 2026 requirements. The result is that IETF Proposed Standards approved over the last decade or more have had extensive review. Exactly. Brian
Re: draft-moonesamy-ietf-conduct-3184bis
On 02/09/2013 04:22, Dave Crocker wrote: On 9/1/2013 9:08 AM, Barry Leiba wrote: I think Scott has put this perfectly, and it's exactly right. The main point is clear communication. Everything else is advice about how to achieve that. Both are needed. Especially for a topic like this. That is, for each point, the principle or concept needs to be stated, but then there need to be concrete, behavioral examples. If the document only cites concepts or principles or other terms of abstraction, each of us is likely to interpret them /very/ differently. Especially for a topic like this. Worse, even if we interpret them in the same way, we might not understand what behaviors to attempt or to avoid, since that often requires some understanding of the differences between cultures and people. That also applies to the listener. We should advise people to allow for cultural differences and language differences when listening or reading. Is this exchange from 2004 rude or not? I believe we are off-topic here. You are off-topic from the beginning. Brian
Re: Mail lost yesterday
On 31/08/2013 02:26, SM wrote: ... The nit is why is the IETF still using PDT. I assure you that things were operationally much worse when the Secretariat was using EDT. Really - the service level has improved continuously over the last eight years. Of course things can always be better, and we learn collectively from every incident, but compared to various corporate and campus services I have used, IETF participants have nothing to complain about. Brian
Re: I-D Action: draft-sweet-uri-zoneid-00.txt
I am *not* an author of this draft, which Michael Sweet produced on his own. I have not read the draft and have no idea whether I agree with it. (I believe this was an honest mistake on his part but I don't want there to be any misunderstanding.) Regards Brian Carpenter On 28/08/2013 03:55, internet-dra...@ietf.org wrote: A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Representing IPv6 Zone Identifiers in Address Literals and Uniform Resource Identifiers Author(s) : Michael Sweet Brian Carpenter Stuart Cheshire Robert M. Hinden Filename: draft-sweet-uri-zoneid-00.txt Pages : 11 Date: 2013-08-27 Abstract: This document describes how the zone identifier of an IPv6 scoped address, defined as zone_id in the IPv6 Scoped Address Architecture (RFC 4007), can be represented in a literal IPv6 address and in a Uniform Resource Identifier that includes such a literal address. It updates the URI Generic Syntax specification (RFC 3986) accordingly. [ Editor's note: This draft adds the IPvFuture format used by CUPS since 2005, addresses some misconceptions of how zoneid's are not useful to HTTP servers, and is intended to replace RFC 6874. ] The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-sweet-uri-zoneid There's also a htmlized version available at: http://tools.ietf.org/html/draft-sweet-uri-zoneid-00 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ ___ I-D-Announce mailing list i-d-annou...@ietf.org https://www.ietf.org/mailman/listinfo/i-d-announce Internet-Draft directories: http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
Re: Call for Review of draft-rfced-rfcxx00-retired, List of Internet Official Protocol Standards: Replaced by an Online Database
I think that if we worried about every minor deviation from RFC 2026, we would be here for a long time and wasting most of it. I have no particular objection to publishing the draft. Regards Brian Carpenter (who tried and failed - see draft-carpenter-rfc2026-critique, draft-carpenter-rfc2026-practice, draft-carpenter-rfc2026-changes) On 17/08/2013 06:44, John C Klensin wrote: --On Thursday, August 15, 2013 12:06 -0700 SM s...@resistor.net wrote: At 11:48 14-08-2013, IAB Chair wrote: This is a call for review of List of Internet Official Protocol Standards: Replaced by an Online Database prior to potential approval as an IAB stream RFC. The document is available for inspection here: https://datatracker.ietf.org/doc/draft-rfced-rfcxx00-retired/ From Section 2.1 of RFC 2026: 'The status of Internet protocol and service specifications is summarized periodically in an RFC entitled Internet Official Protocol Standards.' My guess is that draft-rfced-rfcxx00-retired cannot update RFC 2026. Does the IAB have any objection if I do something about that? SM, You have just identified another aspect of why I find this document troubling. I note that requirement of RFC 2026 has not been satisfied for years unless one interprets periodically as consistent with whenever we get around to it, which, in today's age, is likely to be never. I note that the last version of STD 1 was RFC 5000, published in May 2008 and that its predecessor was RFC 3700 in July 2004, i.e., there was a four year interval followed by at least a seven year one. That is well outside most normal interpretations of periodic. I don't personally think it is worth it (or, more specifically, think the resources could be better spent in other ways) but, if one believed the keep anything that might turn out to be historically important theme of the IETF 86 History BOF, then there is value in maintaining the sort of comprehensive status snapshot that STD 1 was supposed to provide (once its [other] original purpose of being part of a report to the sponsor became irrelevant) even if that snapshot is taken only once every few years. That aside, I think this document is almost completely unnecessary. RFC 5000 already points to the HTML version of the RFC index as the authority for contemporary information. There has, as far as I know, never been a requirement that STD 1 be issued as RFCs numbered NN00, nor that all such numbers be reserved for that purpose, outside the internal conventions of the RFC Editor function. At the same time, if the IAB and RSE believe that assembling and publishing this statement formally and in the RFC Series is a good use of their time and that of the community, I think it is basically harmless, _unless_ it becomes an opportunity to nit-pick such questions as its relationship to requirements or statements in 2026 or elsewhere. From Section 3: This document formally retires STD 1. Identifier STD 1 will not be re-used unless there is a future need to publish periodic snapshots of the Standards Track documents (i.e., unless the documentation is resumed). The document argues that STD 1 is historic as there is an online list now. The above reserves an option to restart periodic snapshots if there is a future need. I suggest removing that option as I presume that the IAB has thought carefully about the long term evolution of the Series before taking the decision to retire STD 1. This is another form of the nit-picking (if there were protocols involved, the historical term would involve the phrase protocol lawyer) that concerns me. I don't remember where it is written down (if at all), but the RFC Editor has had a firm rule ever since I can remember that STD numbers are never reused for a different topic. Violating that prohibition against reuse would be a really stupid move on the part of the RFC Editor and/or the IAB. If they were to be that stupid, we have much more serious other problems. If they are going to continue to avoid that sort of stupidity, then that part of the statement above is completely unnecessary - but still harmless. As far as removing the option is concerned, I think doing so would be pointless if the rest of the statement remains. For better or worse, anything that is written into one RFC by the IAB (or, under different circumstances, the IETF) can be amended out of it by another RFC. While I think it unlikely, I can imagine at least one scenario, tied to the historical concern above, under which we would resume publishing a snapshot. Whether the IAB has considered it or not and whatever promises this document does or does not make are irrelevant to whether or not that would happen. Summary: I think the RFC Series Editor should just make whatever announcement she feels it is appropriate to make, recognizing that we stopped regularly updating
Re: Community Feedback: IETF Trust Agreement Issues
I've been doing some more thinking about this, and I have received quite a bit of private feedback about my previous comments, ranging from don't be so picky, let these guys do their thankless job to please be more picky, this is the thin end of the wedge. So - this isn't really about being picky, except that a legal agreement more or less forces us to be picky. Also, I appreciate as much as anybody that the Trustees are doing a thankless job for the benefit of the community. But if we look at the three issues together, we have to also consider *why* the Trust was created in the first place. My summary: it was created to ensure that the intellectual property important for the openness of Internet standards could never be alienated or altered except for the benefit of the community. I can understand why, in certain circumstances, the community might agree that some physical property, such as a worn-out pencil sharpener, should be disposed of, or that a specific piece of intellectual property might be agreed by the community to no longer important and therefore could be released by the Trust. The first case is pretty easy and I think we *could* give the Trustees the authority to dispose of useless physical property. Intellectual property is much harder, because who is to judge what's important? We might reach consensus that it's OK to release change control over the Tao (although I'm not sure I agree with that - what's so hard about keeping it under an RFC-like license?). We probably wouldn't reach consensus to release change control over RFC 791. But who would care to write down legally sound text drawing the line between those two extremes? A couple more comments in line... On 09/08/2013 07:47, Chris Griffiths wrote: On Aug 8, 2013, at 5:42 AM, t.p. daedu...@btconnect.com wrote: Chris I would not like to see the Trust Agreement change to accommodate issues one or two - I think that the agreement got that one right. As I said, if the Trust has a worn-out piece of equipment, they should be able to dispose of it. But this dilemma can be avoided by not acquiring equipment at all. Thank you for this feedback. Three is different. The Trust ought to be able to dispose of rights that are not needed, never will be and are costing money. But how can that be expressed without giving carte blanche to dispose of everything, for whatever purposes? We need a proposal as to how that line would be drawn - I do not have any sound ideas on this. I think providing thoughtful language around seeking community feedback and requiring time frames to dispose of items would be needed in this case. I note that the Trust Agreement does not explicitly recognise that the Trustees should follow BCP 101, including aspects such as: To ensure that the IASA is run in a transparent and accountable manner. the IAOC and IAD will ensure that guidelines are developed for regular operational decision making. Where appropriate, these guidelines should be developed with public input. In all cases, they must be made public If we're going to add something about community feedback to the Trust Agreement it should probably be more general rather than just for the specific matter of asset disposal. It's always been understood that the transparency requirement for the IAOC also applies to the Trust, but to my surprise we never wrote it down. Can you indicate what annual or one-off costs we are talking about? The domain names I have dealt with have been cheap enough not to be concerned about, once I found the best way to deal with them, although I understand that the IETF is operating in a different realm and so may have costs of a different magnitude. I agree some domains are not very expensive, however trademarks require legal work for registering and filing for them. While not huge numbers, we want to raise the issue that keeping these items requires overhead and expense that seems to not be warranted in some cases, and we want to discussed and get feedback on if keeping these and paying for them makes sense. There's also the issue that (as I understand it) specific marks like IETF Secretariat may be easier to defend than a more generic mark like plain IETF. IANAL. Brian Thanks Tom Petch - Original Message - From: Chris Griffiths cgriffi...@gmail.com To: ietf@ietf.org Sent: Saturday, August 03, 2013 7:48 AM IETF Community, The IETF Trust Trustees would like feedback from the community on several issues: - We have received requests that we cannot accommodate and have consulted legal counsel to review our options - The trust agreement does not allow the trustees to effectively manage some trust assets The Trust was created in December 2005 by the Internet Society and the Corporation for National Research Initiatives (CNRI) for the purpose of the advancement of education and public interest by acquiring, holding, maintaining and licensing certain
Re: [Trustees] The Trust Agreement
On 06/08/2013 03:11, Noel Chiappa wrote: From: Brian E Carpenter brian.e.carpen...@gmail.com Thanks for the careful explanations. I'll second that; it does seem that some tweaking may be in order. Clearly the Trust shouldn't have blanket permission to abandon or dispose of assets When the time comes to draft actual wording, I would suggest that there be a requirement for a notification to the IETF-Announce list at least one month (or so?) prior to any actual disposal or abandonment, or completion of any agreement to dispose. (Maybe only for IP, and not real property too, such as old servers, etc?) I can't imagine the Trust would be disposing of stuff very often, so I think this would be a reasonable requirement. Agreed; that's very much in the spirit of how we set up the Trust to be responsive to the community. It doesn't seem like the sort of detail to be embedded in the Trust Agreement though - more like part of a tiny addendum to BCP 101. (Since I have raised that question, I hereby volunter to draft it if necessary.) Brian
Re: procedural question with remote participation
On 05/08/2013 06:54, Ted Lemon wrote: While I think getting slides in on time is great for a lot of reasons, reading the slides early isn't that important. What is important is that remote people see the slides at the same time as local people. For that, it seems to me that Meetecho support does exactly what is needed. You just follow the slideshow online, along with the audio. Of course, in order to have Meetecho support, you need the slides in advance of the meeting, preferably far enough in advance that it doesn't create a massive hassle for the Meetecho team. But by making Meetecho the place where the slides are presented, you ensure that everybody is on an equal footing, without engaging in punitive behavior. The main reason to want to see the slides in advance is so that the working group chairs can evaluate them to see if they will actually be a good use of time. But that's completely orthogonal to the remote participation issue. For remote attendees, there is a distinct advantage in having time to download store slides in advance. There are still plenty of places where real-time bandwidth is an issue and audio and jabber may be all you can get. There is another equally important reason for having them well in advance, for both on-site and remote attendees: so that participants can review them in advance, decide which of several clashing sessions to attend, and even prepare questions. This applies even if the slides summarise a draft that was available two or three weeks in advance. Things are often expressed differently in the slides. Finally: a deadline one week before the meeting is no harder to meet than one minute before the meeting. If it's a zero-tolerance deadline, people will meet it. Brian
Re: [Trustees] The Trust Agreement
Jorge, Thanks for the careful explanations. My only quibble is whether the phrase other than rights in IETF standards-related documents (such as RFCs, Internet Drafts and the like) actually excludes the Tao, which is not a standards document, but is very relevant to the standards process and was an RFC in earlier forms. The web page version is clearly a derivative work of the preceding RFC. However, I can see this being a problem some time in the future, even if the Tao squeezed past. For issues #1 and #3, I can see the case for a cautious procedure for exceptions to the current restrictions. Clearly the Trust shouldn't have blanket permission to abandon or dispose of assets (except if the IETF itself winds up, which I believe is already covered). As for the physical property issue #2 I can see that there's an inconsistency but (IMHO) we need to be sure that any change is fully consistent with BCP 101. To be specific, RFC 4371 says: A Trust (the IETF Trust) has been formed for the purpose of acquiring, holding, maintaining, and licensing certain existing and future intellectual property and other property used in connection with the administration of the IETF. If we are picky, we'd need to slightly modfiy that sentence if the Trust has the right to abandon or dispose of assets. Regards Brian On 03/08/2013 23:50, Jorge Contreras wrote: Please see below for some specific responses to Brian's concerns. On Sat, Aug 3, 2013 at 1:49 AM, Chris Griffiths cgriffi...@gmail.comwrote: On Aug 1, 2013, at 10:59 PM, Brian E Carpenter brian.e.carpen...@gmail.com wrote: Hi Brian, Re the Trust's plenary slides (I was not in Berlin): I have an allergy to modifying the Trust Agreement unless there's an overwhelming reason to do so. It was a very hard-won piece of text. I recognize that this was a very hard-won piece of text and agree we should put a much higher threshold in order to update it. Based on review of some recent items with legal counsel, we were advised that there were some sections that would need to be updated in order to deal with some recent requests and we felt we would ask the community for feedback if we had enough justification to make changes. Indeed, I was also part of that original negotiating team in 2005 and have recently spent a great deal of time reviewing the records of that negotiation. Issue #1 We have recently been asked permission to republish the TAO with a creative commons license, but unfortunately the current trust agreement does not give the trustees the rights to do this It doesn't? You have the right to license existing and future intellectual property according to clause 2.1 of the Trust Agreement. Is there some particular property of the CC license that causes a problem? Brian - the restriction is contained in Section 9.5 which, as you may recall, was added quite late in the negotiation. It reads as follows: 9.5 Licenses. The Trust (acting through the Trustees) shall have the right to grant licenses for the use of the Trust Assets on such terms, subject to Section 7.1, as the Trustees deem appropriate; provided, however, that the Trust shall not grant any license that would be deemed a transfer of ownership or abandonment of any Trust Assets under applicable law. Specifically, any license granted by the Trust for the use of the Trust Assets consisting ofiPR other than rights in IETF standards-related documents (such as RFCs, Internet Drafts and the like) that have been acquired by the Trust through non-exclusive licenses granted by their contributors pursuant to the IETF community-approved procedures currently set forth in RFC 3978, and any community-approved updates and revisions thereto, shall include provisions stating that (a) the licensee agrees to grant and assign to the Trust all right, title, and interest it may have or claim in any derivative works of licensee that are based on or incorporate the IPR, and (b) the licensee's use of the IPR and any goodwill associated therewith shall inure to the benefit of the Trust. The last sentence of this clause makes the Trust is quite limited in its ability to grant licenses to IPR other than standards-related documents. That is, it cannot grant licenses to non-standards IPR unless the requirements of sub-clauses (a) and (b) are met. If you recall, the original negotiating position of CNRI was that the Trust have NO right whatsoever to grant licenses to non-standards IPR. We requested the exceptions in clauses (a) and (b) to address planned tools development by paid and volunteer contractors. Those exceptions were negotiated and allowed, and now the only way that the Trust can grant licenses to non-standards IPR is if the licensee agrees to grant the Trust ownership of any derivative works of the IPR. Such a requirement is normal and appropriate when dealing with contractor-developed tools
Re: Anonymity versus Pseudonymity (was Re: [87attendees] procedural question with remote participation)
On 03/08/2013 00:13, Scott Brim wrote: I'm completely against participating anonymously because of IPR issues. I'm mostly against pseudonymous participation for the same reason. I need to be able to know who I'm dealing with, in order to know if there are IPR issues that should be brought up. More generally, there are other kinds of conflict of interest, not just intentional or accidental concealment of IPR, that can be hidden by anonymity or pseudonymity. It seems to me to be directly against the principles of open standards openly developed. Brian
Re: 6tsch BoF
On 02/08/2013 01:30, Andy Bierman wrote: On Thu, Aug 1, 2013 at 4:24 AM, Yoav Nir y...@checkpoint.com wrote: On Aug 1, 2013, at 11:14 AM, Andy Bierman a...@yumaworks.com wrote: Hi, Isn't it obvious why humming is flawed and raising hands works? (Analog vs. digital). A hand is either raised or it isn't. The sum of all hands raised is comparable across tests. The sum of the amplitude of all hums is not. Hums are better as they give greater weight to people who are more vocally in support (or in opposition) to the assertion. Please provide some evidence that a loud hum means the person is more committed to work on an item. I spotted a number of virtual :-)s in Yoav's message. The fact is that both methods are broken. A loud hum may indeed represent strength of feeling, which in judging consensus is valuable input. Or it may represent chance (some people naturally hum louder) or a cultural split in opinion. So it's fairly meaningless. A lot of hands up may indicate that a couple of employers have loaded the room. One can make a case that we shouldn't use either method: just go by the arguments made in the room and on the list. In the case of a WG-forming BOF, it seems to me that a nucleus of people willing and competent to do the work, and a good set of arguments why the work needs to be done and how it will make the Internet better, are more important than any kind of numbers game. Brian
The Trust Agreement
Hi, Re the Trust's plenary slides (I was not in Berlin): I have an allergy to modifying the Trust Agreement unless there's an overwhelming reason to do so. It was a very hard-won piece of text. Issue #1 We have recently been asked permission to republish the TAO with a creative commons license, but unfortunately the current trust agreement does not give the trustees the rights to do this It doesn't? You have the right to license existing and future intellectual property according to clause 2.1 of the Trust Agreement. Is there some particular property of the CC license that causes a problem? Issue #2 We cannot currently accept physical assets like hardware donations into the trust Once accepted into the trust, we would be unable to dispose of these items in the future if they are identified as no longer being needed It was definitely intended that the Trust would only handle intellectual property, and that ISOC on behalf of IASA would handle money and material property. Why change this? (I'm not quite sure why the Trust Agreement included the words and other property in the first place. It was there from a very early draft and was never discussed, as far as I can tell from my 2005 email archive.) Issue #3 Once a domain name or trademark is registered by the trust, it cannot be abandoned even if it is no longer needed We must maintain these in perpetuity IANAL, but it isn't clear to me that clause 9.4 forces you to do this. It requires you to take reasonable steps and to file applications as the Trustees deem necessary in order to maintain and protect the Trust Assets. If you decide (and minute) that it isn't reasonable or necessary to maintain veryolddomainname.org, where's the crime? Brian
Re: making our meetings more worth the time/expense
Hi Keith, On 31/07/2013 18:35, Keith Moore wrote: On Jul 30, 2013, at 10:38 PM, Brian E Carpenter wrote: It's been pointed out before that in a group with very diverse languages, written words are usually better understood than speech. It's a fact of life that you can't have a full-speed cut-and-thrust discussion in a group of 100 people, half of whom are speaking a foreign language. Sitting in a circle does not fix this. Yes, but most of the people in a typical WG meeting today aren't really participating in the meeting anyway. They're not contributing input, they're not paying attention. Their noses are in laptops. The last sentence there doesn't imply the previous one. I can only speak for myself (and I'm not in Berlin), but I am often looking at the slides, the draft and the jabber session while listening to the speaker; no need to look up in order to pay attention. Alternatively I am working on something else while waiting for the topic I'm interested in to start; or I'm checking whether it's time to move across to a clashing session. Of course I have no idea what fraction of attendees are doing this. It's hard to tell how many of them would be participating if the meeting were more useful, but the very fact that the room contains so many nonparticipants is itself a deterrent to getting work done in the meeting. If nothing else, whenever someone tries to get a sense of the room, it's very misleading - people may be humming when they haven't even been listening, or it may appear that there's no significant support for something when there really is significant support among those who are interested in the topic. That's true; I am much more suspicious of sense of the room consensus calls than I am of sense of the mailing list calls. But pretty much all WG Chairs do what they're supposed to by confirming the consensus on the list. Also, remote participants need full text slides; the soundtrack simply isn't enough. You seem to be assuming that the purpose of WG meetings is to have presentations. I emphatically disagree. The purpose is to communicate, including communication with remote participants. Sometimes that means explaining things that are, perhaps, badly explained in the draft - and getting back comments that show what needs to be changed in the draft. If we decide to make WG meetings fora for interaction and discussion, we can adopt or invent disciplines and tools to better accommodate interaction and discussion between people of diverse languages and including those at other locations. But the disciplines and tools that we've adopted at the moment are designed to accommodate an audience, not active participants. I don't think it's fair to blame the tools. We should be asking questions about how we use the tools. The old days are gone. It sounds like you are saying that IETF is doomed to become irrelevant because it's stuck in habits that do not work. I hope you're wrong about that. No, I mean that we have to deal with a very diverse community and the style of discussion that was successful when you or I first started coming to the IETF isn't going to come back. I don't, unfortunately, have the magic formula. On 31/07/2013 14:23, Andrew Sullivan wrote: First, I observe that we already _have_ a great deal of written words: the drafts. I continue to believe that altogether too much time in WG meetings is spent introducing, presenting, or otherwise showing off ideas in an existing draft to participants in the WG. I acknowledge that (particularly in early stages of WG life, in topics with a lot of different work, and in cross-WG presentations) these intro presentations are a fact of life. But I think we are extremely bad at holding the reigns on them. In a WG meeting, I think such intro presentations about drafts really can be kept to three pieces of information: the name of the draft, a slogan describing the problem it is supposed to solve, and a pointer to the beginning(s) of discussion thread(s) on the draft. If the person promoting the draft can't give the elevator pitch, they don't know their own draft well enough to summarize it and shouldn't be presenting it. That's a bit hard on people early in their IETF career who may be among the most creative. So I disagree, when we are talking about a piece of new work that has attracted interest on the mailing list - we should be reasonably liberal at that stage. Once. After that, I agree; repeat intros and non-substantive discussions shouldn't be given meeting time. But I've been in vey useful sessions where people have showed slides to illustrate open issues, and got very productive feedback that clarifies the options. I've been in other sessions where after a few seconds I switch off after 2 slides and wait for the chairs to call time. deleted several paragraphs that I strongly agree with ... Unfortunately, actually running meetings this way is a lot of work
Re: PS to IS question from plenary
On 31/07/2013 06:27, John C Klensin wrote: --On Tuesday, July 30, 2013 16:41 +0200 IETF Chair ch...@ietf.org wrote: Last night there was a question in the plenary about how many PS-IS transitions have occurred since RFC 6410 was published in October 2011. That RFC changed the three-step standards process to two steps. There was also a question of how this compared to previous times before that RFC got approved. Looking at the timeframe from October 2011 to today (22 months), there have been four such protocol actions. These results are given by searching the IETF Announce mail archive: ... Prior to the publication of RFC 6410, in the preceding 22 months there were these 20 actions raising standards to either Draft Standard or Full Standard: ... I should insert here the Standard disclaimer about possibly faulty search methodology or records, misunderstanding the question, or the hasty interpretation of results. In particular, the above search was not easy on ARO, involved manual steps, and I might have easily missed something. And I wish I had been able to do a database query instead. Feel free to repeat verify my results... Jari, Thanks for this. Disclaimers and possible small classification errors aside and being careful to avoid making causal assumptions, I believe that the implication of the above is that there is no evidence that the 3 - 2 transition has increased the number of documents being moved or promoted out of Proposed Standard. If one were to assume a causal relationship and an absence of external confounding variates or processes, one might even conclude the the 3 - 2 transition has made things quite a lot worse. Conversely, it seems to me that one could argue that the change has made things better only by demonstrating the existence of a process that would have led to considerably fewer than four documents being moved out of Proposed Standard in the last 22 months in the absence of the change. While the apparently-significant reduction in documents moved out of Proposed Standard is far worse than we expected, is it time for Scott Bradner and myself to review draft-bradner-restore-proposed-00, issue a new version, and start a serious discussion about that model of a solution? Would be willing to sponsor such a draft or, if you prefer, organize a WG or equivalent to consider it? I would rephrase it as performing the inverse operation to RFC 4450. I don't think it needs to be a fully-fledged experiment under RFC 3933; just a large batch of PS-IS promotions in one go under RFC 6410. It is a good idea. Brian
Re: Bringing back Internet transparency
On 31/07/2013 05:21, Melinda Shore wrote: On 7/30/13 7:59 AM, Keith Moore wrote: I don't think that's the problem; I think the problem is that most users don't realize how much lack of transparency is harming them. So transparent Internet access isn't a commodity.Transparency would be cheaper if there were more demand for it, and there would be more demand for it if people realized how much more utility they'd get out of the Internet if they had it. n decades in, I suspect that if there were going to be demand for transparency we'd be seeing it by now. If VoIP wasn't the kick in the pants that's been needed to change things, it's difficult to imagine what else might be. Users want applications to just work, but they (and many business managers in our industry) don't understand that when applications fail unpredictably, it's often because of glitches in what we call transparency. However, we are in an arms race here. Every step to improve transparency will be met by a further step in middleboxes that nibbles away at transparency. We've been debating this for 15 years; have you seen any real change in the balance of power? Brian
Re: making our meetings more worth the time/expense
On 31/07/2013 05:47, Bob Braden wrote: On 7/30/2013 9:35 AM, Noel Chiappa wrote: Easy fix: 'slide' (well, nobody uses real slides anymore :-) rationing. E.g. if a presenter has a 10 minute slot, maximum of 3 'slides' (approximately; maybe less). That will force the slides to be 'discussion frameworks', rather than 'detailed overview of the design'. Noel Noel, I tried the 3 slide limit in the End2end Research Group some years ago, and it did not work very well. Presenters just can't discipline themselves that much, no matter how hard you beat on them. It's been pointed out before that in a group with very diverse languages, written words are usually better understood than speech. It's a fact of life that you can't have a full-speed cut-and-thrust discussion in a group of 100 people, half of whom are speaking a foreign language. Sitting in a circle does not fix this. Also, remote participants need full text slides; the soundtrack simply isn't enough. The old days are gone. Brian
Re: Remote participants, newcomers, and tutorials
On 30/07/2013 06:18, John C Klensin wrote: --On Monday, July 29, 2013 01:37 -0400 Brian Haberman br...@innovationslab.net wrote: ... One of the things that I ask the Internet Area chairs to do is send in a summary of their WG after each IETF meeting. Those summaries generally give folks a good idea of the current state of each WG. I post those summaries on the Internet Area wiki. An alternative that would work as well is to have each WG post summaries to their own wikis. Each WG has a wiki available via their Tools page (e.g., http://trac.tools.ietf.org/wg/6man/trac/wiki). I like seeing the summaries from my chairs and I have gotten feedback from participants that they find them quite useful for keeping up with WGs that are tangential to their primary focus. I would encourage every WG chair to periodically summarize the state of their WG/drafts. Dave and a few other ancients will recall that there was a time when there was a requirement for ADs to put together per-meeting Area Reports, which went into the minutes. These were put together from WG Chair's session reports, which were (and are) mandatory under RFC 2418 (BCP 25): Immediately after a session, the WG Chair MUST provide the Area Director with a very short report (approximately one paragraph, via email) on the session. That's not quite the same as a WG status report, but makes a good start. Brian Unless ADs were masochists who wanted to do all the work themselves, that pretty much required that sort of status reports that he and Brian are talking about. It also ensured that ADs were aware of what was going on in all of the WGs for which they were responsible and that, if there were two ADs in an area, they were talking with each other. If those expectations were not met, someone observing that would presumably have something very concrete to tell the Nomcom. In the context of the current discussion, a set of well-written and frequently-updated area reports could also be a big help to a newcomer trying to navigate WG names and acronyms. I agree that it would probably help to be more descriptive about WG names rather than looking for things that will make cute acronyms. Whether we move in that direction or not, most newcomers and isolated/remote participants are going to find it easier to identify an Area of interest than a specific WG. A well-written Area Report that includes brief descriptions of the main focus of each WG along with current status information would be, IMO, a huge help in matching people and specific interests. I think a Wiki or equivalent would be a fine way to maintain such pages but, given how well we do about keeping benchmarks and similar information up to date and the advantages deadlines seem to bring, I'd like to see at least snapshots or the equivalent in meeting minutes. john
Re: Remote participants, newcomers, and tutorials
On 28/07/2013 00:23, Dave Crocker wrote: On 7/27/2013 7:17 AM, Jari Arkko wrote: newcomers who attend Working Group meetings are encouraged to observe and absorb whatever material they can, but should not interfere with the ongoing process of the group ... The first quote might discourage newcomers from participating. I suggest discussing about the two quotes during the orientation as they could be misunderstood. ... But the first one is just plain wrong. Is this from RFC 3184? Many of the first time IETFers are here for a reason, are well-versed in the technology in question, and very much able to provide suggestions to the WG. It's not wrong. It's badly worded, possibly bordering on rudeness. It certainly lacks context. And it probably doesn't apply to BOFs. But it's not wrong. It reads rudely when taken out of context. But try reading the whole paragraph in RFC 3184: IETF participants who attend Working Group meetings read the relevant Internet-Drafts, RFCs, and e-mail archives beforehand, in order to familiarize themselves with the technology under discussion. This may represent a challenge for newcomers, as e- mail archives can be difficult to locate and search, and it may not be easy to trace the history of longstanding Working Group debates. With that in mind, newcomers who attend Working Group meetings are encouraged to observe and absorb whatever material they can, but should not interfere with the ongoing process of the group. Working Group meetings run on a very limited time schedule, and are not intended for the education of individuals. The work of the group will continue on the mailing list, and many questions would be better expressed on the list in the months that follow. Exactly. My experience back when I was a newcomer was that it was easy enough to ask beginner's questions after the meeting, and obviously wrong to do so during the session. This remains true years later, if I drop into a WG that I'm not familiar with. Brian
Re: Remote participants, newcomers, and tutorials
On 27/07/2013 03:32, John C Klensin wrote: Hi. For a newcomer or someone expecting to write I-Ds, some of the most important sessions at the IETF are the various Sunday afternoon tutorials and introductions. Many of them are (or should be) of as much interest to remote participants as to f2f attendees. Until and unless a newcomer's tutorial can be prepared that is focused on remote participants, even that session should be of interest. For this particular meeting all of the following seem relevant to at least some remote participants: Newcomers' Orientation Tools for Creating I-Ds and RFCs IAOC Overview Session Multipath TCP Applying IP Flow Information Export (IPFIX) to Network Measurement and Management So... (1) The note below strongly implies that none of those sessions are being audiocast.Why not and can that be fixed? I think that would mean that the crew (partly volunteers) would need to mobilise 24 hours earlier. Not impossible, I suppose, but not free of costs either. (2) There is no hint on the agenda or tools agenda about availability of presentation and related materials (slides, etc.) for those sessions. Do those materials not exist? At the moment the various EDU tutorials usually get posted after the event, and I agree that isn't ideal. It would be useful for all these ancillary sessions to be included in the meeting materials page and all agenda tools (official and volunteer). Again, not impossible, in fact very desirable IMHO, but not free. Brian I know, but a newcomer or remote participant might not, that I can find some tutorials by going to the IETF main page and going to Tutorial under Resources, but I have no idea which of those links actually reflects what will be presented on Sunday. Assuming the presentation materials do exist for at least several of the sessions, finding them is much like the situation with subscribing to the 87all list. It should no involve a treasure hunt at which only very experienced IETF participants can be expected to succeed. Specific suggestions: (i) Let's get these open Sunday sessions audiocast and/or available over Meetecho or WebEx. If that is impossible for IETF 87, it should be a priority for IETF 88 and later. (ii) If there are presentation materials available, links from the tools agenda and an announcement to IETF-Announce as to where to find them would be desirable. (iii) If presentation materials are not available, why not? And, more important, can this be made a requirement for IETF 88 and beyond? thanks, john --On Friday, July 26, 2013 12:00 +0200 Nick Kukich nkuk...@verilan.com wrote: Greetings, For those interested in monitoring sessions or participating remotely the following information may prove useful. ... All 8 parallel tracks at the IETF 87 meeting will be broadcast starting with the commencement of working group sessions on Monday, July 29, 2013 at 0900 CEST (UTC+2) and continue until the close of sessions on Friday, August 2nd. ...
Oh look! [Re: Remote participants, newcomers, and tutorials]
And there is a Training section in the meeting materials page. It's empty... but thanks to somebody for putting it there. All we need to do is figure out how to pre-load it. Regards Brian On 27/07/2013 08:33, Brian E Carpenter wrote: On 27/07/2013 03:32, John C Klensin wrote: Hi. For a newcomer or someone expecting to write I-Ds, some of the most important sessions at the IETF are the various Sunday afternoon tutorials and introductions. Many of them are (or should be) of as much interest to remote participants as to f2f attendees. Until and unless a newcomer's tutorial can be prepared that is focused on remote participants, even that session should be of interest. For this particular meeting all of the following seem relevant to at least some remote participants: Newcomers' Orientation Tools for Creating I-Ds and RFCs IAOC Overview Session Multipath TCP Applying IP Flow Information Export (IPFIX) to Network Measurement and Management So... (1) The note below strongly implies that none of those sessions are being audiocast.Why not and can that be fixed? I think that would mean that the crew (partly volunteers) would need to mobilise 24 hours earlier. Not impossible, I suppose, but not free of costs either. (2) There is no hint on the agenda or tools agenda about availability of presentation and related materials (slides, etc.) for those sessions. Do those materials not exist? At the moment the various EDU tutorials usually get posted after the event, and I agree that isn't ideal. It would be useful for all these ancillary sessions to be included in the meeting materials page and all agenda tools (official and volunteer). Again, not impossible, in fact very desirable IMHO, but not free. Brian I know, but a newcomer or remote participant might not, that I can find some tutorials by going to the IETF main page and going to Tutorial under Resources, but I have no idea which of those links actually reflects what will be presented on Sunday. Assuming the presentation materials do exist for at least several of the sessions, finding them is much like the situation with subscribing to the 87all list. It should no involve a treasure hunt at which only very experienced IETF participants can be expected to succeed. Specific suggestions: (i) Let's get these open Sunday sessions audiocast and/or available over Meetecho or WebEx. If that is impossible for IETF 87, it should be a priority for IETF 88 and later. (ii) If there are presentation materials available, links from the tools agenda and an announcement to IETF-Announce as to where to find them would be desirable. (iii) If presentation materials are not available, why not? And, more important, can this be made a requirement for IETF 88 and beyond? thanks, john --On Friday, July 26, 2013 12:00 +0200 Nick Kukich nkuk...@verilan.com wrote: Greetings, For those interested in monitoring sessions or participating remotely the following information may prove useful. ... All 8 parallel tracks at the IETF 87 meeting will be broadcast starting with the commencement of working group sessions on Monday, July 29, 2013 at 0900 CEST (UTC+2) and continue until the close of sessions on Friday, August 2nd. ...
IEEE Internet Award winner: Jon Crowcroft
Some people here will remember that Jon was an IETF participant and an IAB member a number of years ago. Brian 2014 IEEE Technical Field Award Recipients and Citations IEEE INTERNET AWARD-recognizes exceptional contributions to the advancement of Internet technology for network architecture, mobility, and/or end-use applications-sponsored by Nokia Corporation-to JON CROWCROFT (FIEEE)-Professor, University of Cambridge, Cambridge, United Kingdom For contributions to research in and teaching of Internet protocols, including multicast, transport, quality of service, security, mobility, and opportunistic networking. (from http://www.ieee.org/about/awards/news/2014_ieee_tfa_recipients_and_citations_list.pdf)
Re: Remote participants access to Meeting Mailing Lists was Re: BOF posters in the welcome reception
On 25/07/2013 05:01, Scott Brim wrote: The point of having a separate list for participants was to avoid spamming the ietf list. It can be open to everyone to subscribe to, since anyone can see the archives, HOWEVER I recommend that only registered participants be allowed to post. Ahem. Either remote participants are allowed to post, or they need a list of their own. I would envisage a fair amount of chatter about specific remote-participation issues, like this new codec isn't working for me, is it OK for anyone else using browser version on operating system version? Brian
Re: Remote participants access to Meeting Mailing Lists was Re: BOF posters in the welcome reception
On 25/07/2013 11:27, Scott Brim wrote: Brian: yes but non-registered thus non-ifentifiable subscribers, spammers etc don't. We're talking about a list with a useful lifetime of perhaps 3 weeks. I really don't think spam is a big issue. Trolls might be, but they would be *our* trolls ;-) Anyway - as John Klensin said, we should come up with a reasonably complete and welcoming set of info and facilities for the remotes. That may well include pro forma registration. Brian On Jul 24, 2013 3:56 PM, Brian E Carpenter brian.e.carpen...@gmail.com wrote: On 25/07/2013 05:01, Scott Brim wrote: The point of having a separate list for participants was to avoid spamming the ietf list. It can be open to everyone to subscribe to, since anyone can see the archives, HOWEVER I recommend that only registered participants be allowed to post. Ahem. Either remote participants are allowed to post, or they need a list of their own. I would envisage a fair amount of chatter about specific remote-participation issues, like this new codec isn't working for me, is it OK for anyone else using browser version on operating system version? Brian
Re: IETF 87 Technical Plenary Experiment
The wiki page uses the phrase WebRTC-compatible browser. For those who know zilch about WebRTC, a list of such browsers would be handy. Also a test page for OPUS, since otherwise people will have exactly 5 minutes before the session to get set up. Finally, is the list 87all of any help to non-attendees? Don't we need a list for 87remote attendees? Regards Brian On 23/07/2013 07:03, IAB Chair wrote: The OPUS codec, defined in RFC 6716, can scale from low bit-rate narrowband speech to very high quality stereo music, making it suitable for a wide range of audio applications. The IETF 87 Technical Plenary session will cover the past and future of Opus as well as the lessons learned from the standardization process that could apply to future IETF work. To provide additional materials relating to the plenary topic, the IAB has created a wiki. If you have material relevant to the plenary topic (such as papers or test data relating to OPUS), please contribute it to the wiki, either by editing it yourself, or sending it to the IAB iab at iab.org. Also, during the IETF 87 Technical Plenary, the MeetEcho team will be running an experiment to enable remote participation in the Technical Plenary using the OPUS codec. Information on how to access on the Remote Participation experiment is also available on the IAB wiki page: http://trac.tools.ietf.org/group/iab/trac/wiki/IETF-87#IETF87TechnicalPlenary:OPUSCodec On behalf of the IAB, Russ Housley IAB Chair
IAOC overview clash
Sanjay, A comment from an old-timer: if you want to understand the IETF as a whole, put your priority on the Newcomer's orientation. There's plenty of time in the future to understand details of the IETF's administration. Unfortunately, clashes between interesting sessions are unavoidable at the IETF, because there is just too much going on. If they move the IAOC overview again, it will clash with something else, even on Sunday. Regards Brian Carpenter On 19/07/2013 08:14, Mishra, Sanjay wrote: Moving IAOC Overview session now conflicts with Newcomer's orientation. The original schedule for IAOC conflicted only for the 2nd hour with newcomer meet and greet and I had figured to attend at least the first hour but now the IAOC session overlaps fully with Newcomer's orientation so those first time attendees like me will have to likely pick newcomer orientation over IAOC overview which if not conflicting would have been helpful. Is it possible to start sooner on Sunday? Thanks Sanjay -Original Message- From: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On Behalf Of ietf-requ...@ietf.org Sent: Tuesday, July 16, 2013 8:33 PM To: ietf@ietf.org Subject: Ietf Digest, Vol 62, Issue 57 If you have received this digest without all the individual message attachments you will need to update your digest options in your list subscription. To do so, go to https://www.ietf.org/mailman/listinfo/ietf Click the 'Unsubscribe or edit options' button, log in, and set Get MIME or Plain Text Digests? to MIME. You can set this option globally for all the list digests you receive at this point. Send Ietf mailing list submissions to ietf@ietf.org To subscribe or unsubscribe via the World Wide Web, visit https://www.ietf.org/mailman/listinfo/ietf or, via email, send a message with subject or body 'help' to ietf-requ...@ietf.org You can reach the person managing the list at ietf-ow...@ietf.org When replying, please edit your Subject line so it is more specific than Re: Contents of Ietf digest...
Re: IAB Statement on Dotless Domains
Do you think they are lying when they say they won't be dotless? Since http://dotless won't work in any host that has a default domain configured, which as far as I can tell is most hosts on earth, I don't think they're lying. It may be stupid and a license to print money, but that's another story. Brian
Re: IETF registration fee?
Douglas, ... Those traveling thousands of miles already confront many uncertainties. Those that elect to participate remotely should be afforded greater certainty of being able to participate when problems occur at local venues or with transportation. Increasing participation without the expense of the brick and mortar and travel should offer long term benefits and increased fairness. How much would you be willing to pay for remote participation (assuming it was of high quality)? $600 for the week (cookies and taxes not included)? Brian
Re: IETF registration fee?
On 11/07/2013 07:44, Peter Saint-Andre wrote: On 7/10/13 1:41 PM, Keith Moore wrote: On 07/10/2013 02:50 PM, Donald Eastlake wrote: The IETF values cross area interaction at IETF meeting and attendees have always been encouraged to attend for the week. Allowing one day passes is a recent phenomenon to which some people, including myself, are on balance opposed. I'm also of the opinion that the one-day passes were a bad idea. We have too little cross-group and cross-area participation, too many groups working at cross-purposes, and too little attention paid to the implications of any one new protocol on the Internet architecture. We have become very overspecialized and we need to see what we can do to discourage this trend. I can spend a week at an IETF meeting and never participate in a session outside a given area. That's true of course, but you will also have the chance to pick up corridor gossip from other areas, and to be found by people in other areas who are concerned about something your area is doing. Day passes have nothing to do with it. I disagree. Day passes encourage the notion that it's normal to parachute into the IETF to attend a single session. I think that the IETF's strength is that we don't totally compartmentalise work items. In that light, it's reasonable that two day passes should cost more than the whole week. In any case, hotel costs quickly exceed the meeting fee if you stay for a few days. Not to mention that people who've paid for a day pass get mighty upset when a session is moved to a different day at the last moment. Brian
Re: Final Announcement of Qualified Volunteers
(2) Four companies account for 44.3% of the volunteers. OK, but what would X be in Four companies account for X% of people eligible to volunteer? That said, the not more than two from the same employer rule was written in anticipation of a theoretical problem; it seems that it was a good idea, but it does allow the following to become true: Four companies account for 67% of the NomCom members. Should we consider changing it to not more than one in view of today's data? Regards Brian
Re: Evi Nemeth
One more update on the search. Family members are still hoping for a good outcome: http://www.stuff.co.nz/national/8876799/Lost-text-from-missing-yacht-Nina-crew (For those who don't remember Evi, she and her students provided IP multicast services at numerous IETF meetings in the 1990s.) Regards Brian Carpenter On 28/06/2013 11:24, Brian E Carpenter wrote: Evi used to be an IETF regular. There is rather ominous news - she is lost at sea between New Zealand and Australia: http://www.nzherald.co.nz/nz/news/article.cfm?c_id=1objectid=10893482 http://www.nzherald.co.nz/nz/news/article.cfm?c_id=1objectid=10893503 Regards Brian Carpenter
Re: Appeal Response to Abdussalam Baryun regarding draft-ietf-manet-nhdp-sec-threats
On 03/07/2013 14:23, Russ Housley wrote: http://www.ietf.org/iesg/appeal.html Every appeal ever submitted to the IESG and its response can be found here. ...since late 2002, that is. There were appeals earlier in history. The first one I recall reached the IAB in 1995, and had presumably already been rejected by the IESG. However, statistics since 2002 are probably enough. I'd say that rejected appeals quite often lead to clarification of procedures for the future; therefore they have value, even if it isn't immediately obvious. Brian
Re: Evi Nemeth
Further bad news: no sighting and no debris after considerable searching. http://www.bbc.co.uk/news/world-asia-23110736 Regards Brian Carpenter On 28/06/2013 11:24, Brian E Carpenter wrote: Evi used to be an IETF regular. There is rather ominous news - she is lost at sea between New Zealand and Australia: http://www.nzherald.co.nz/nz/news/article.cfm?c_id=1objectid=10893482 http://www.nzherald.co.nz/nz/news/article.cfm?c_id=1objectid=10893503 Regards Brian Carpenter
Evi Nemeth
Evi used to be an IETF regular. There is rather ominous news - she is lost at sea between New Zealand and Australia: http://www.nzherald.co.nz/nz/news/article.cfm?c_id=1objectid=10893482 http://www.nzherald.co.nz/nz/news/article.cfm?c_id=1objectid=10893503 Regards Brian Carpenter
Re: IAOC Website Updated
Tom, On 25/06/2013 22:48, t.p. wrote: ... The main impression that this page has on me is that this is a part of the IETF, Yes. It is a committee set up by the IETF (with help from ISOC). ... The very brief description - the fiscal and administrative support - makes me think of taxes (and tax avoidance) The word fiscal means either pertaining to taxes or pertaining to financial matters. It's quite appropriate - the IAOC oversees the budget, and would undoubtedly oversee the handling of any tax matters that came up despite ISOC's not-for-profit status. while the link to an RFC, which starts with loads of irrelevant - to the likely reader of this page (I assume someone relatively new to the work of this SDO) - I don't see that at all. The Introduction of the RFC gives a pretty good summary of IASA's job and the IAOC's role. Anyway, this is not particularly intended for newcomers. We don't even mention IASA on the newcomers page. Do you think we should? boilerplate is enough to make anyone reach for the off-switch, and guaranteed to do so if they get as far as IAD, IASA, ISOC, etc. Alphabet soup indeed! I have tried - and failed - to produce a paragraph which summarises what IAOC is. To my mind the phrase The IETF Administrative Oversight Committee is completely self defining, as in The IETF Administrative Oversight Committee oversees the administration of the IETF. OOPS Ray - fix that Oversite typo And the sentence should also state that IAOC is part of IASA. I would start with the need of the IETF for e-mail and web servers, and a few other bits and pieces such as legal advice and ownership of rights, then the need for money to fund that, where the money comes from and how the expenditure is supervised and where ISOC fits into that - but not an RFC in sight - or site. This would not need to mention the IAD but cannot, IMO, avoid IASA. That belongs on the About page rather than the Home page. I agree it would make sense to mention technical support there as well as pure admin support. Brian
Re: SHOULD and RECOMMENDED
On 26/06/2013 05:58, Phillip Hallam-Baker wrote: On Tue, Jun 25, 2013 at 11:51 AM, Doug Ewell d...@ewellic.org wrote: Scott Brim scott dot brim at gmail dot com wrote: 2119 overrides anything you might think you know about what words mean. No, 2119 PURPORTs to do that. It can try but it probably isn't going to succeed. The purpose of RFCs is to communicate ideas. In ordinary language there is a clear distinction between RECOMMENDED and SHOULD. There is a useful distinction between them in the context of writing a standard. There are in fact standards bodies apart from the IETF. Yes, and when they explicitly cite RFC 2119, they accept the definitions therein, one of which equates SHOULD and RECOMMENDED. You can dislike that equation but it becomes an axiom. They both mean there may exist valid reasons in particular circumstances to ignore a particular item, but the full implications must be understood and carefully weighed before choosing a different course. If you don't like this, it's easy to avoid: don't cite RFC 2119. Brian
Re: SHOULD and RECOMMENDED
On 25/06/2013 08:38, John C Klensin wrote: --On Monday, June 24, 2013 16:28 -0400 Alia Atlas akat...@gmail.com wrote: I read SHOULD and RECOMMENDED as different. SHOULD is how a implementation ought to behave unless there are special circumstances (deployment, additional functionality, better idea). MUST says that there are no circumstances special enough to change the behavior. RECOMMENDED is closer to a Best Current Practice (BCP); so I might write It is RECOMMENDED that the network-converged timer have a minimum value of 2 seconds. but in 10 years, maybe it'll only take 2 microseconds - so that'll become a bad recommendation! And that, again, is close to the distinction that a reasonable person might read into 2026. But not into 2119 which appears (at least to me) to make them fully-substitutable alternatives. The distinction doesn't make the comments made by Peter, Dave, or others any less valid. If we told ourselves that readers should (lower case) infer conformance statements from SHOULD and applicability ones from RECOMMENDED... well, we would be pretty delusional. Also, issuing 2119bis with a subtle difference between the two would create a horrible problem of interpretation for all existing documents (including numerous documents from other SDOs) that explicitly cite 2119. This has ramifications that make my head hurt. Brian
Re: IAOC Website Updated
Hi Ray, I think it's very good. One micro-comment: the menu at the left is headed up by the IETF logo (which is in fact a link to the main site). I did find that momentarily confusing - maybe the first two items could be labelled IASA Home and About IASA to make it clear which menu this is? Best wishes Brian On 21/06/2013 06:59, IETF Administrative Director wrote: One of the IAOC goals for 2013 was to update the IAOC website to improve consistency, organization, linkage, and ease of use. I am pleased to announce that the IAOC site has been updated and is available now for your use at http://iaoc.ietf.org/. On the home page see a video of an Overview of the IAOC given by Chair Bob Hinden in Orlando that includes a discussion of venue selection and IETF finances. Also on the home page are recent announcements, as well as reports from IANA, the RFC Editor, the IETF Chair, the NomCom Chair, and more. The navigation bar makes it easy to find financial statements, minutes, meeting sponsorship opportunities, and much more. We hope you find this helpful, the IAOC as more transparent, and of course we welcome your feedback. Ray IETF Administrative Director PS: Going to IETF 87 in Berlin? The IAOC will be doing another overview session there, Sunday July 28 at 3:00 PM. Hope to see you there!
Re: IETF, ICANN and Whois (Was Re: Last Call: draft-housley-rfc2050bis-01.txt (The Internet Numbers Registry System) to Informational RFC)
On 19/06/2013 18:25, Patrik Fältström wrote: On 18 jun 2013, at 18:54, Jari Arkko jari.ar...@piuha.net wrote: As for the rest of the discussion - I'm sure there are things to be improved in ICANN. I'd suggest though that some of the feedback might be better placed in an ICANN discussion than on IETF list. And is not like there'd be nothing to improve on our side :-) Lets focus on IETF aspects here. I think this is the correct strategy, BUT, I see as a very active participant in ICANN (chair of SSAC) that work in ICANN could be easier if some more technical standards where developed in IETF, A pre-condition for that is that technical and operational problem statements are formulated, which could be sent to appropriate WGs or used to justify a BOF. If ICANN could focus on that instead of solutionism or committeeism, progress should be possible. Brian and moved forward along standards track, that ICANN can reference. Same with some epp-related issues, and also DNS-related, which I must admit I think has stalled in the IETF. When that happens, ICANN start to invent or at least discuss IETF related issues -- which I think is non optimal. But on the other hand, if IETF do not move forward, then what should ICANN do? I will btw be the first few days (until including Tuesday or so) at IETF in Berlin and am happy to discuss this issue with anyone interested. Patrik Fältström Chair SSAC, ICANN .
Re: Content-free Last Call comments
'scuse front posting, but I'm going to outrageously summarise Pete's point as I want substance in all Last Call comments, or alternatively I will ignore +1 just as I will ignore -1. That isn't unreasonable, but personally I would interpret I've read it and I think it's good work as substantive, especially if it comes from a known expert. YMMV Regards Brian On 12/06/2013 08:31, Pete Resnick wrote: On 6/11/13 3:05 PM, Brian E Carpenter wrote: Pete, On 12/06/2013 07:45, Pete Resnick wrote: It's interesting to see that people are interpreting me to mean I want more text. I don't. I want less. Save your breath. There is no reason to send one line of support, and it only encourages the view that we're voting. Details below. Just to test what you are saying, let me ask the following. Oooo...I love a test. How would you react to one that says something like: I've read the draft, and I've considered Joe Blow's objection, but I still support publication of the draft (*not followed by a reasoned rebuttal of Joe Blow's argument)? I would be rather grumpy with such a message. If there's an outstanding (reasonable) objection to a document, I need to know why to consider that argument in the rough. I'd have to ask for more detail from the sender. If the response I get back is, I figured it was obvious why Joe Blow was full of crap, I'd ask, Then why did you bother posting? If the sender happens to be an expert (and Joe Blow is not), I'm still not going to take it at face value that Joe Blow is wrong. If I did, Joe would be well within rights to appeal because his argument got blown off. So, if you're saying something that is perfectly obvious, no need to say it. But if it's not perfectly obvious, I do want more text. pr
Re: Content-free Last Call comments
Pete, On 12/06/2013 07:45, Pete Resnick wrote: It's interesting to see that people are interpreting me to mean I want more text. I don't. I want less. Save your breath. There is no reason to send one line of support, and it only encourages the view that we're voting. Details below. Just to test what you are saying, let me ask the following. I will stipulate that a message that can be summarised accurately as +1 doesn't serve much purpose. How would you react to one that says something like: I've read the draft, and I've considered Joe Blow's objection, but I still support publication of the draft (*not followed by a reasoned rebuttal of Joe Blow's argument)? Brian
Re: ietf@ietf.org is a failure
On 09/06/2013 07:55, Melinda Shore wrote: On 6/8/13 10:09 AM, SM wrote: As an off-topic comment, there are are alternative ways in making a decision; the best judgement of the most experienced or IETF Consensus. I don't think it's off-topic. Consensus (rough or otherwise) requires that at some point people can live with decisions with which they disagree. To the extent that we've seen recent misbehavior on this list, it's from only one person who's rejecting the consensus and rejecting the process. It's really annoying but I don't think it's particularly disruptive. If it becomes disruptive, there's a rarely-used hammer: the PR action. I agree. Whatever misbehaviour Melinda means hasn't troubled me; it must be a user or a thread that I filter to junk. Disagreement is fine as long as people in the end understand when they're in the rough and not in the consensus. There are times when this list annoys me too, but it is far from a failure IMHO. Brian
Re: ietf@ietf.org is a failure
On 09/06/2013 13:20, Andy Bierman wrote: Hi, I'm not sure how the desire for IETF Last Call discussions to be on a dedicated and constrained mailing list in any way implies that this generalized and unconstrained list is somehow a failure. Filtering by subject line is unreliable. For example, please provide a filter that will not have any false positives or negatives over the past 20,000 emails on this list. Do we have tools that make sure no human has altered any subject line inappropriately? Filtering by mailing list address is much easier and more reliable. True, but it's a much coarser implement. Indeed, I mainly filter to 'junk' rather than 'trash' so that once in a while I can check for false positives. False negatives aren't that big a problem in practice; the delete key works quickly. Brian
Best list for IETF last calls [was: Weekly posting summary for ietf@ietf.org]
Rule 1 for complex and divergent mail threads is to change the Subject header when the subject changes. If you don't do that, your mail is rather likely to get junked. I think that IETF last call threads should stay on the main IETF discussion list. That is exactly the right place for them. It's rather trivial to filter them into a dedicated folder; I have one called 'lastcallsin', that also picks up most WG Last Call threads, although those have less standardised subject headers. Brian On 08/06/2013 06:17, Juliao Braga wrote: +1 Em 07/06/2013 15:09, Ulrich Herberg escreveu: I like the idea of a separate list for last calls. It would not solve the issue of noise for all of us (and not reduce the overall amount of emails), but it would separate general discussions from IETF LCs. I have IETF emails filtered by mailing list into different IMAP folders, and thus a separation could be useful for me. Ulrich
Re: I-D Action: draft-crocker-id-adoption-02.txt
Hi, My main positive comment is that it's a good idea to document guidelines in this area, and that (viewed as guidelines) I largely agree with the draft. My main negative comment is that although the draft says it's not a formal process document, its language in many places belies that. For example: 2. Adoption Process 2.1. Formal Steps To adopt a new working group document, the chairs need to: would be better phrased as: 2. Adoption Guidelines 2.1. Typical Steps To adopt a new working group document, the chairs often: I'd suggest a careful pass through the text, removing instances of words like process, formal and need, and emphasising words like guideline and typical and might. Now some minor comments: The convention for identifying an I-D formally under the ownership of a working group is by the inclusion of ietf in the second field of the I-D filename and the working group name in the third field, It's a useful convention but *not* a requirement afaik. Note that from time to time a working group will form a design team to produce the first version of a working group draft. I think that's slightly wrong. A design team draft is *not* automatically a WG draft. I think this is more accurate: Note that from time to time a working group will form a design team to produce the first version of a document that may be adopted as a working group draft. That's an important difference - we've seen cases where design teams falsely believed that they had been delegated authority by the WG. * Is there strong working group support for the draft? I think that's going a bit far. Actually a WG might adopt a draft because there is support for the *topic* but not for the details of the draft as it stands. Indeed, one objective of adopting a draft is so that the WG as a whole obtains control of the contents - so that they can change it. * What is the position of the working group chairs, concerning the draft? [[editor note: I am not sure this is relevant. Indeed is might be specifically not relevant. /a]] Actually I'd go the other way: the WG chairs' job at that point is to judge the WG's opinion of the draft, not their own opinion. (At least once, as a WG chair, I had to declare adoption of a draft to which both I and my co-chair were strongly opposed.) 5.1. Individual I-Ds Under WG Care ... OK, but there are in fact four possible outcomes for such a draft 1. As you describe; 2. The document proceeds as an individual submission to the IESG without continued WG discussion; 3. The document proceeds as an Independent Submission to the RFC Editor; 4. The document is abandoned. Regards Brian
Re: Not Listening to the Ops Customer
On 01/06/2013 15:00, John C Klensin wrote: --On Friday, May 31, 2013 17:23 -0700 Randy Bush ra...@psg.com wrote: rant the sad fact is that the ietf culture is often not very good at listening to the (ops) customer. look at the cf we have made out of ipv6. the end user, and the op, want the absolute minimal change and cost, let me get an ipv6 allocation from the integer rental monopoly, flip a switch or two, and get 96 more bits no magic. 15 years later, dhcp is still a cf, i have to run a second server (why the hell does isc not merge them?), i can not use it for finding my gateway or vrrp exit, ... at least we got rid of the tla/nla classful insanity. but u/g? puhleeze. Randy, I suggest that characterizing that set of issues as IETF versus Ops is probably not completely right either. It was more complicated. I was actually running a team that ran site network ops at the time, and (since DHCP was not yet deployable), IPv4 was then a serious nuisance to manage, compared say to Novell Netware and, even, Appletalk. There were good reasons we wanted stateless auto-configuration and unlimited subnet size, to mention two IPv6 bells and whistles. If DHCP had already been deployed, our opinion might have been different. For example, with IPv6, the IETF has proposed multiple transition solutions with no roadmap as to which one to apply under what circumstances and growing evidence that some of those solutions are unworkable in practice and others are incompatible with what are claimed to be fundamental and important features of the Internet. It turns out that as soon as you envisage a network in which some nodes only support 32 bit addresses and other nodes can't get a globally unique 32 bit address, you are forced into a world of hurt that requires some combination of NAT, tunnels and dual-stack. That is completely independent of the design of IPng, and we knew it 1994. So while your criticism is valid that we collectively came up with too many such combinations, that collective mistake was (IMHO) not a result of the design of IPv6 as such. It was more caused by the design of human beings. It doesn't take a skilled operations person to understand that is a problem; someone with a pointy head and barely enough clue to figure out what a bit is much less how many of them are in various addresses can derive a don't be the first person on the block or don't migrate if you can figure out an alternative lesson from that. Similarly, various applications folks within the IETF have pointed out repeatedly that any approach that assigns multiple addresses, associated with different networks and different policies and properties, either requires the applications to understand those policies, properties, and associated routing (and blows up all of the historical application-layer APIs in the process) or requires request/response negotiation that TCP doesn't allow for (and blows up most of the historical application-layer APIs). It's true, but to avoid that, I think we'd have to abolish cellular telecommunications, Wi-Fi, and competition between providers. One of the original promises about IPv6 was no need for changes to TCP and consequent transparency to most applications. Ha! Right, but again - only part of that is due to the change of address size and socket API details. Most of it is due to multiple connectivity. That was going to happen anyway. I have never been convinced that longer addresses and nothing else was the only viable solution for IPng, Don't forget, BTW, that even just changing address size from 32 to 64 would have blown up almost every app written to BSD sockets (since Real Programmers Don't Use Structures and almost everybody used to stick addresses into uint_32). There never was a free lunch on the table. Brian but I don't think it requires an advanced degree in economics to understand that, if the incentives to do something don't exceed the costs and risks of doing it, one shouldn't expect a lot of rational folks to charge off and do it. A complex system with high deployment costs and risks and a dubious set of advantages is not a story that is going to sell itself. And, again, it doesn't require a sophisticated operator to figure that out. None of this takes away from your rant (or Warren's). But I suggest that, on several of the dimensions you identify, the operators are not being singled out for abusive treatment because we don't listen to each other or elementary decision-making or economic realities either... at least where broad issues, rather than fine-tuning of a spec are concerned. john
Re: What do we mean when we standardize something?
On 30/05/2013 08:04, Dave Cridland wrote: On 29 May 2013 18:42, Peter Saint-Andre stpe...@stpeter.im wrote: /me wonders if we need a separate series for informational documentation Or maybe multiple paths, with multiple entry points. We already do have exactly that, and there are many instances of proprietary or local protocols being documented, but not standardised, as Informational RFCs in the Independent stream. Sometimes they squeeze through as Informational RFCs in the IETF stream. We also have BCPs, when there is robust consensus on good operational practice. Again, we have Informational RFCs when somebody wants to document current practice without seeking consensus. I'm not sure what we need to change. Where we get into trouble seems to be when people want a rubber stamp for something that doesn't make the cut for IETF consensus. We have a little trouble saying No. But I think we have a duty to say No when something works but is believed to be bad for the Internet as a whole. Brian Perhaps instead of Proposed Standard, we have a Engineering Proposal for an engineering consensus, and a Submitted Proposal for an industry submission. Both would move to Internet Standard from there, if appropriate. I admit to picking names without the word standard in on purpose, but that's because I think we should reclaim PS... I know I'm in the rough. Dave.
Re: When to adopt a WG I-D
On 28/05/2013 21:32, Adrian Farrel wrote: Hi, Dave Crocker and I have this little draft [1] discussing the process and considerations for creating formal working group drafts that are targeted for publication. We believe that this may help clarify some of the issues and concerns associated with this part of the process. We are targeting this as Informational (i.e. commentary on existing process, not new normative definition of process) and would like your input. What is not clear? What have we got wrong? I haven't read the draft yet, and *before* I do so, I'd like to express some doubt whether we should even informally describe this using the word process. It seems to me that it's each WG's prerogative how it does this; it has no impact on the standards process as a whole. The word adopt doesn't even occur in RFC 2418, and it is not used in the context of WG adoption in RFC 2026. In other words, I don't think this action is part of the standards process. It's WG folklore. Brian How should we resolve the remaining editor notes? Thanks, Adrian (per pro Dave) [1] http://www.ietf.org/internet-drafts/draft-crocker-id-adoption-02.txt .
Re: Last Call: draft-jabley-dnsext-eui48-eui64-rrtypes-03.txt (Resource Records for EUI-48 and EUI-64 Addresses in the DNS) to Proposed Standard
Publication of EUI-48 or EUI-64 addresses in the global DNS may result in privacy issues in the form of unique trackable identities. This might also result in such MAC addresses being spoofed, thereby allowing some sort of direct attack. So it isn't just a privacy concern. ... These potential concerns can be mitigated through restricting access to zones containing EUI48 or EUI64 RRs or storing such information under a domain name whose construction requires that the querier already know some other permanent identifier. This can be seems too weak. Shouldn't we have a MUST here? Also, I doubt that the second option (a shared secret) is sufficient. Regards Brian Carpenter
Re: Last Call: draft-jabley-dnsext-eui48-eui64-rrtypes-03.txt (Resource Records for EUI-48 and EUI-64 Addresses in the DNS) to Proposed Standard
On 21/05/2013 13:06, John C Klensin wrote: --On Monday, May 20, 2013 19:49 -0400 Rob Austein s...@hactrn.net wrote: At Mon, 20 May 2013 10:18:21 -0400, John C. Klensin wrote: This is not my primary (or even secondary) area of expertise but, given that the RR space is not unlimited even though it is large, wouldn't it be better to have a single RRtype for IEEE-based EUIs with a flag or other indicator in the DATA field as to whether a 48 bit or 64 bit identifier was present? Short answer: Probably not, but it depends on the application. Longer answer: See RFC 5507. Rob, I've reread 5507 and did so again before writing my second note today. I don't see that it helps. I haven't heard anyone proposing use of TXT (or any existing RRTYPE) instead, so that is presumably a non-issue. The discussion in 3.1 clearly applies to relatively complex schemes like NAPTR, but it is not clear that it has anything to do with this case. In particular, if I correctly understand the IEEE's allocation scheme for longer identifiers (and I may not) than a given device gets only one -- this is not analogous to a dual-stack IPv4/IPv6 arrangement -- and an application gets back whatever it gets back (whether the query is addressed to the DNS, read off a label on the device and entered manually, or something else). If so, then one RRTYPE with the appropriate identifier in the data is the right answer. If not... if, for example, different types of applications will look for only one type-length of identifier and will either find it or give up (not try falling back to the other because that would make no sense), then the use of two RRTYPEs is entirely reasonable. But, if that is the case and this is going to be standards track, I expect to see an explanation in the document. That explanation could be as simple as a statement to that effect and an example or two of the types of applications that would use each identifier and/or a reference to IEEE materials that describe the circumstances under which one example or the other is used. I'm not opposed to having two separate RRTYPEs -- I just want to see the rationale. And what passes for use cases in the draft appears to me to be completely silent on that issue. Especially since there is an IEEE-defined method for representing a 48-bit address in the 64-bit format. Now you mention it, why can't that be used in all cases? Brian
Re: Last Call: draft-housley-rfc2050bis-01.txt (The Internet Numbers Registry System) to Informational RFC
John, On 18/05/2013 05:23, John C Klensin wrote: ... I, however, do have one significant objection to the current draft of the document and do not believe it should be published (at least as an RFC in the IETF Stream) until the problem is remedied. The Introduction (Section 1) contains the sentence Since the publication of RFC 2050, the Internet Numbers Registry System has changed significantly. If we want to avoid ratholes built into the document, it might be prudent to rephrase that sentence as Since the publication of RFC 2050, the environment of the Internet Numbers Registry System has changed. That sentence is expanded upon in Section 6, which bears the interesting title of Summary of Changes Since RFC 2050. But Section 6 contains no such summary, merely a statement that things have changed and that some material -- unidentified except by the broadest of categories -- has been omitted. I took that section title to refer to changes *in the text* of 2050, not changes in the system. Maybe the authors could clarify their intent, and if it is limited to text changes, clarify the wording accordingly. Brian
Re: Last Call: draft-housley-rfc2050bis-01.txt (The Internet Numbers Registry System) to Informational RFC
On 18/05/2013 11:59, John C Klensin wrote: --On Saturday, May 18, 2013 08:14 +1200 Brian E Carpenter brian.e.carpen...@gmail.com wrote: John, On 18/05/2013 05:23, John C Klensin wrote: ... I, however, do have one significant objection to the current draft of the document and do not believe it should be published (at least as an RFC in the IETF Stream) until the problem is remedied. The Introduction (Section 1) contains the sentence Since the publication of RFC 2050, the Internet Numbers Registry System has changed significantly. If we want to avoid ratholes built into the document, it might be prudent to rephrase that sentence as Since the publication of RFC 2050, the environment of the Internet Numbers Registry System has changed. Both statements are true-- the environment has changed and the system has changed. At least in principle, the environment has changed less with three three really notable events being the advent of ICANN, the end-game of the IPv4 address space, and the growing importance of the IPv6 one. I think that can be said and the other changes summarized. From my point of view, if we have to avoid describing the changes to avoid ratholes, it would be legitimate for someone to ask what we are hiding. That sentence is expanded upon in Section 6, which bears the interesting title of Summary of Changes Since RFC 2050. But Section 6 contains no such summary, merely a statement that things have changed and that some material -- unidentified except by the broadest of categories -- has been omitted. I took that section title to refer to changes *in the text* of 2050, not changes in the system. Maybe the authors could clarify their intent, and if it is limited to text changes, clarify the wording accordingly. I just checked your hypothesis by looking at a diff between 2050 and the present draft. As far as I can tell from a quick review, there is not a single unchanged paragraph. So, if the issue is text changes, this is not an update but an almost complete replacement. Yes, because apart from anything else, the draft leaves out a number of topics that are explicitly out of IETF scope since RFC 2860. I don't really see what we are hiding in this: This document describes the Internet Numbers Registry System as it presently exists and omits policy and operational procedures that have been superseded by ICANN and RIR policy since RFC 2050 publication. (given that there is a reference to RFC 2860 a few lines earlier). If I had the edit pen I would probably want to rephrase that paragraph a bit, but it does say what has been deleted and why. Brian
Re: Is this an elephant? [Was: call for ideas: tail-heavy IETF process]
Dave, On 17/05/2013 04:23, Dave Crocker wrote: ... The problem here is that basic reviewing is being done by the ADs too late in the process. You are making a lot of assumptions in that sentence. At least these: 1. Basic reviewing means 2. At some stage before approval, ADs should perform basic reviewing. 3. Doing basic reviewing after the document has completed IETF LC is too late. Now, if basic reviewing means (A) looking for fundamental flaws that is one thing. If it means (B) getting a general understanding of the topic it's another. I'm really not sure which you mean. We are making the mistake of having ADs be exempt from IETF Last Call, and allowing them to be unprepared for the IESG vote. So we are combining education with voting. That's a paradigm error. By the time the IESG schedules the vote, ADs need to already have educated themselves about the document. Ah, maybe you mean basic (B). Well, I think this is a totally unrealistic expectation. There are too many drafts on too diverse a range of subjects for ADs to educate themselves at the time of IETF LC, which may be weeks or months before a draft hits the agenda. (I'm not talking about the sponsoring AD or her co-AD, of course: they are presumed to be aware of what's going on in their area.) Busy people are deadline driven, and the IESG agenda is an imminent deadline for ADs in a way that an IETF LC in another Area isn't. Of course, the IESG discussion during the voting process well might uncover an actual, serious issue with the document; And that's basic (B). I think we all agree that it's unfortunate if a basic flaw shows up during the IESG ballot phase, but please don't blame the IESG for that. Blame the WG and the IETF as a whole for failing to pick it up during WG LC and IETF LC. Thank the IESG for finding it. this should be exceptional and it should be an issue that the /IESG/ agrees needs to be resolved and it means that voting should not take place until it is. But that is quite different from the usual let's talk about it kind of Discuss imposed by individual ADs. I'm not quite sure what you're saying here, but I think you're saying that the majority of clarity and cross-area issues should be picked up earlier. I couldn't agree more, but don't expect the over-worked IESG to fix that. The rest of us need to fix that. So here's a simple proposal that pays attention to AD workload and includes a simple efficiency hack: When the IETF Last Call is issued, wait a few days, to see whether any serious issues are raised by the community. The really serious ones usually are raised quickly. If there are none, it's pretty certain the document will advance to an IESG vote. That leaves 7-10 days of IETF Last Call for ADs to get educated and ask questions, just like everyone else. Which, as I said above, is a totally unrealistic expectation. Jari has expressed the goal of having AD concerns be raised more publicly. Moving AD review and comment to the IETF Last Call venue nicely accomplishes this, too. Thanks but no thanks. My mail is full enough with discussion of drafts I will never read as it is. AD reviews should certainly go to the WG list unless they are only nits, but isn't that what everybody does anyway? On 5/15/2013 8:55 AM, Thomas Narten wrote: 1) Discuss criteria should be principles, not rigid rules. The details of the issue at hand always matter, and it will sometimes come down to judgement calls where reasonable individuals just might disagree. We've been doing protocol specification for 40 years. If we can't codify the major concerns that warrant blocking advancement of a protocol, we're just being lazy. Really. That a given situation might cause the IESG to decide to enhance the list does not mean that the list shouldn't seek to be complete and precise and that ADs be held to it. I agree with Thomas. We need to be able to apply common sense. Rules and targets are the enemy of common sense. At every turn, the approach we've taken to the IESG review and approval process is to limit actual accountability to the community. Everyone is well-intentioned, but really this makes the process a matter of personalities and not the rigor of serious professionalism. The IESG's process is far, far better than it was 10-15 years ago, but it still lacks meaningful predictability and serious accountability; it I find that the tracker in its present state has substantially improved both visibility and predictability. is not reasonable for the process to require that authors and chairs take the initiative of complaining when an AD is being problematic. Huh? Who else will complain? In terms of quality assurance, the idea that we have a process that relies on the sudden insight of a single AD, at the end of a many-month process, is broken. It's fine if that person sees something that everyone else has missed until then, but that is quite
Re: call for ideas: tail-heavy IETF process
I think this exchange between Cullen and Ted says it all, except for one tweak: the IESG is allowed, even encouraged, to apply common sense when considering the DISCUSS criteria. They are guidance, not rules. Also, everybody needs to take the word discuss literally. An entirely possible outcome is that after discussion, the AD says Oh. You're correct. Pretend I never spoke!. Or the author says Oh. You're correct. We'll change it. Either outcome is good. Regards Brian On 15/05/2013 04:55, Cullen Jennings (fluffy) wrote: inline On May 14, 2013, at 10:34 AM, Ted Lemon ted.le...@nominum.com wrote: On May 14, 2013, at 9:58 AM, Cullen Jennings (fluffy) flu...@cisco.com wrote: 2) On the point of what the IESG should be doing, I would like to see the whole IESG say they agree with the Discuss Criteria document and will stay within that (or change it if they disagree). The cross area review teams might want to also provide comments within this context. I am not entirely convinced that the DISCUSS criteria are complete. agree but I like and think they help even thought they are not complete There are some rules in the criteria that are intended to curb abuse, and that I think do have that effect, but that also would make some very appropriate DISCUSSes fail to meet the criteria. If you could give some examples of DISCUSSes that you think are reasonable but fail to meet the criteria, it would be really great if you could provide some examples of that as I think it would help refine DISCUSS criteria. I think everyone agrees there could be things in that category but - that was part of the reason DISCUSS criteria did not end up as a BCP. I don't really know how to address that problem. The IESG needs to keep using common sense and keep doing the right thing. I'm happy that the IESG deal with the unexpected. E.g. the rule about not coming up with new DISCUSSes: if a DISCUSS winds opening up a can of worms, it ought to be possible to enlarge the DISCUSS, but I think that the rule about not adding new DISCUSSes after the first DISCUSS tends to forbid that, and the reason given is a good one. Having said that, I don't think the right answer is to ignore that requirement. I don't actually have a good answer. I think the IESG has generally followed a good path of not adding new things, and at the same time if some huge problem was found later, still dealing with it. A long time ago it was hard to know when the IESG might actually finish review, that is not longer a problem but I don't want to go back to it being a problem. It's worth noting that ADs are not omniscient, and hence the DISCUSS criteria apply to what the AD entering the DISCUSS _knows_, not to the full state of all knowledge in the world. Of course and that is part of why the name DISCUSS. The AD wants to DISCUSS it with people and improve their knowledge of state of work and what happened in WG and why it is the way it is and resolve it. I'm perfectly happy with DISCUSSes being resolved with once it got explained to me, I see it is not a problem and cleared. If someone other than the AD has knowledge that they think means that the DISCUSS doesn't meet the criteria, that doesn't mean the DISCUSS doesn't mean the criteria. In this case, the critic needs to communicate it to the AD, who may or may not agree with the critic's point of view. This is not to say that it's never correct to say this doesn't meet the DISCUSS criteria. But the reason given should be that it would be obvious to anyone reading the DISCUSS that it didn't meet the criteria. Sure but as everyone knowledge increases, I'd expect that AD would update the DISCUSS or remove it if it becomes clear it is not longer relevant. My experience has been IESG does do this. The critic's expert knowledge can't be given as a reason. I have also noticed that some authors have the impression that a DISCUSS means the AD doesn't like the document, or doesn't want the document to advance, or is a non-negotiable pronouncement from on high that the authors should not question. This is certainly not my motivation when I enter a DISCUSS. I'm just some guy who got nominated by the nomcom. Hopefully I'm qualified, but I don't claim to be right. I have seen DISCUSSes I've raised improve documents, and I've seen DISCUSSes I've raised turn out not to require any change, but just some discussion to clear up a misunderstanding on my part. I very much hope that in the latter case, the author will argue back, and not just make a change to shut me up! +1 to that. The reason I raise a DISCUSS rather than a comment is that at the time I'm writing the DISCUSS, it appears _to me_ to be the case that there is a problem that ought to be addressed before the document is published. I may think it's generally a great document, but I want the
Re: Last Call: draft-housley-rfc2050bis-01.txt (The Internet Numbers Registry System) to Informational RFC
On 12/05/2013 03:17, SM wrote: ... The fact that the IPv6 address pool is very large does not remove the fact that it is a not an infinite resource and thus, constraints must be applied to allocation policy. The constraints are not set by the IETF. It's up to other communities to see what constraints, if any, should be applied. It's up to the IETF to set boundary conditions for the address space that it created (in the case of IPv6) or inherited (in the case of IPv4), in order to protect the long-term viability of the Internet. ... I'll suggest alternative text: 1) Allocation Pool: IP addresses and AS numbers are fixed length numbers. The allocation pools for these number resources are considered as resources which are finite. That doesn't set any boundary conditions beyond those imposed by mathematics, and is therefore a no-op. The mention of operational needs is a real boundary condition that makes it clear that address space is not to be wasted. As has been pointed out from time to time, it would be quite easy to design an allocation model, fully respecting the hierarchical constraint in the following guideline, that blows away galactic quantities of address space, even for IPv6. It is entirely appropriate for the IETF and IAB to write a goal that avoids this. The principle for the above is to avoid set any constraint unless it is necessary for IETF protocols to work. No IETF protocol will work if the address space is exhausted of if BGP4 runs out of steam or otherwise fails. The goals listed in Section 2 address that. ... Section 2 is about the goals for distributing number resources (re. first sentence). I suggest removing the third goal as it might be a matter of global (or other) policy. No, it's a necessity in order for the two preceding goals to be verifiably achieved, and to avoid accidental duplication of addresses. ... In Section 5: The discussions regarding Internet Numbers Registry evolution must also continue to consider the overall Internet address architecture and technical goals referenced in this document. I'll wordsmith this: It is expected that discussions regarding Internet Numbers Registry evolution will continue to consider the overall Internet address architecture and goals mentioned in this document. I removed the must. The must is necessary. I noticed the following in Section 5: In addition, in the cases where the IETF sets technical recommendations for protocols, practices, or services which are directly related to IP address space or AS numbers, such recommendations must be taken into consideration in Internet Numbers Registry System policy discussions regardless of venue. The text does not add any value as must be taken into consideration does mean anything. Er, it means what it says. It is exactly as powerful as any other must or even MUST written by the IETF. If you ignore it, your network might break. I think that the current wording of the draft is correct. Brian
Re: Gen-art telechat review: draft-ietf-6renum-gap-analysis-06.txt (updated for -07)
On 11/05/2013 04:58, Stig Venaas wrote: On 5/10/2013 8:12 AM, Robert Sparks wrote: Thanks Bing - The updates make the document better, and I appreciate the resolution of referencing Tim's expired draft. So the solution is to not reference it? I see the name of the draft is mentioned in the acknowledgments as: [draft-chown-v6ops-renumber-thinkabout]. Shouldn't it then be an informational reference? It doesn't make sense to me to mention a draft in the text and not have a reference. YMMV, but I expect the RFC Editor will resolve this. Brian
Re: call for ideas: tail-heavy IETF process
On 10/05/2013 01:13, John C Klensin wrote: --On Thursday, May 09, 2013 03:32 -0500 Spencer Dawkins spen...@wonderhamster.org wrote: So in this case, we're looking at RFC Editor state = Heather, please do something + some working group, please do something + author(s), please do something, and we can't tell how much time to attribute to each of these ... You could further add to that list RFC Production Center, please do something (different from an RSE wait, which is, or at least ought to be, more significant) and IESG or appropriate AD, please do something, which does happen. But the RFC Editor's numbers try (almost always successfully) to separate the two waiting on the RFC Editor Function to do something (Heather plus Production Center plus, in principle, Publisher) from the other states. Those other states could, from their point of view, be aggregated into stuck, someone else's problem. If we are looking for issues with IETF end-game process, we need to parse those, but that is a different sort of question in terms of data-gathering and reporting. All of which suggests that, ideally, the tracker would include a variable onTheHook for each draft, containing at all times the person or role responsible for the next step. That isn't necessarily implied by the state machine. For example, AUTH48 doesn't always imply that the author is on the hook - it may be that the author has asked the WG Chair to ask the WG for a quick review of a proposed last-minute change. At that point, the WG as a whole is on the hook. Brian
Re: Language editing
On 08/05/2013 03:28, John C Klensin wrote: ... I'll also point out that this has diddley-squat to do with formal verification processes. Again as Mark Anrdrews points out, we deployed something with a restriction that subsequently turned out to be unnecessary, and now we're stuck with it. Indeed, had formal verification processes been properly used, they would have flagged any attempt to change this as breaking interoperability. Also agreed. To be clear, I'm no fan of formal verification either, but this *is* a case where the IETF's lapse in formality has come back to bite, and the Postel principle would have helped. Also, given the original subject of the thread, I don't see how language editing could have made any difference. Brian
Re: Language editing
On 08/05/2013 08:33, Ned Freed wrote: On 08/05/2013 03:28, John C Klensin wrote: ... I'll also point out that this has diddley-squat to do with formal verification processes. Again as Mark Anrdrews points out, we deployed something with a restriction that subsequently turned out to be unnecessary, and now we're stuck with it. Indeed, had formal verification processes been properly used, they would have flagged any attempt to change this as breaking interoperability. Also agreed. To be clear, I'm no fan of formal verification either, but this *is* a case where the IETF's lapse in formality has come back to bite, and the Postel principle would have helped. Also, given the original subject of the thread, I don't see how language editing could have made any difference. Reread the notes about the history behind this in this thread. You haven't even come close to making a case that formal verification of the standards would have prevented this from happening. You are correct if only considering the mail standards. I suspect that a serious attempt at formal verification would have thrown up an inconsistency between the set of mail-related standards and the URI standard. However, I think the underlying problem here is that we ended up defining the text representation of IPv6 addresses in three different places, rather than having a single normative source. (ABNF in the mail standards, ABNF in the URI standard, and English in ipv6/6man standards.) (Formal verification of implementation compliance to the standards would of course have prevented Apple's client bug, but that's a very different thing.) You are, however, correct that this has nothing to do with specification editing. Ned
Re: Language editing
On 07/05/2013 02:10, l.w...@surrey.ac.uk wrote: http://labs.apnic.net/blabs/?p=309 an excellent detective story on badly-written, poorly edited, standards track RFCs leading to interop problems. Enjoy. I don't that is quite right. The problem in this case is not to do with linguistic quality. It's due to a lack of formal verification among a set of interacting and cross-area RFCs. (And the problem is wider, because there are two distinct places in IETF standards where ABNF for the text representation of IPv6 addresses can be found.) This is a case where no amount of language editing would have helped. Actually I used it a couple of months ago in a discussion with some experts on formal verification, and they rather liked it as a poster child for the need for formal methods in SDOs. Brian
Re: Language editing
On 04/05/2013 09:22, Yaron Sheffer wrote: GEN-ART is a good example, but actual document editing is much more work and arguably, less rewarding than a review. So I think this can only succeed with professional (=paid) editors. I think I disagree, if we can find the knack of effective crowd-sourcing. We do after all have several hundred native English speakers active in the IETF, which would mean each one would have to volunteer for less than one draft per year and we'd be done. I don't know how much experience you have with professional editors. Apart from the RFC Editor crew, my experience has been mixed. Somebody a year or three ago (the last time we had this exact same discussion) pointed out the differences between copy-editors and technical editors. One difference is that the latter are much more expensive. Copy-editors tend to be rule-driven; technical editors are supposed to understand the material. Brian
Re: call for ideas: tail-heavy IETF process
Would people like to see a new version of the SIRS draft? In addition to the questions John raised below, Francis and others mentioned: lack of reviewers. Also there is the question of overlap with Area review teams such as secdir, and there is accumulated experience from Gen-ART (RFC 6385). Regards Brian On 03/05/2013 08:29, John Leslie wrote: Pete Resnick presn...@qti.qualcomm.com wrote: Note that although we did ask the bigger question, the more central question relates to what we on the IESG can do all by ourselves (without making changes to the formal processes) that we can discuss during our IESG meeting next week. So don't limit your thinking to things that require process changes; suggested behavior changes on the part of ADs are also useful. The ADs could do worse than starting from the SIRS draft: tools.ietf.org/html/draft-carpenter-icar-sirs-01 but as I read through it, I find a number of issues which I'd advise _not_ trying to resolve. For example: - All reviews public: not always a good idea; - Normally posted to WG list: often a bad idea -- to easy for them to start a flame-war; - Standardized summary message: these may be a very poor choice for early reviews; - Selection process: it's far more important that the IESG be comfortable with each member. OTOH it contains items which SHOULD be taken seriously: - No change to formal process; - Formal process to add SIRS members; - Inactive members fall off the SIRS list; - WG may request a particular member; - WG should request more than one reviewer; - Earlier reviews should consider architectural questions; - Three review cycle per document should be the minimum. I also note the overlapping discussion of DNS type SPF... From: Doug Barton do...@dougbarton.us Given that you can be 100% confident that the issue will be raised during IETF LC, wouldn't it be better to hash it out in the WG (as we have attempted to do)? Or is the WG's position, we have no intention of dealing with this unless we're forced to? In this case, hashing it out on the WG list at this stage seems a _bad_ idea. If we had gotten a SIRS review right at the beginning, it could perhaps be discussed on the WG list; but by now it's doubtful any discussion would change anyone's mind. (And, of course, if the WG had chosen only SIRS reviewers that agreed with their preferred way of resolving the issue, the issue _wouldn't_ have been resolved early in the process...) This is on it's way to being a poster-child late surprise. :^( I'm fully sympathetic with your collective desire to move the process forward, and finish your document. The problem is that as it stands the document contains a course of action that is not only bad on its face, but contrary to a basic architectural principle adopted 4 years ago in 5507. BTW, I agree with Doug Barton that deprecating type SPF has some serious negatives. The IESG will have to balance WG rough-consensus against architectural principles; and I see no resolution that won't invite appeals. :^( In a properly designed early-review situation, the issue would have surfaced early; and it's possible it could have been resolved before too many folks' positions had hardened... -- John Leslie j...@jlc.net
Re: call for ideas: tail-heavy IETF process
On 02/05/2013 05:59, Dave Crocker wrote: The blog nicely classes the problem as being too heavy-weight during final stages. The quick discussion thread seems focused on adding a moment at which the draft specification is considered 'baked'. I think that's still too late. What, you agree with your younger self? http://tools.ietf.org/html/draft-carpenter-icar-sirs-01 Apart from the non-diverse acronym, I still think that proposal was a good one. Brian
Re: IETF Diversity Question on Berlin Registration?
On 30/04/2013 08:49, Sam Hartman wrote: ... Statistical analysis is only useful if it's going to tell you something that matters for your decision criteria. Yes. And I would like to know, in statistical terms, whether there are significant differences between (for example) the M/F ratios among (a) IETF registrants, (b) active participants, (c) WG chairs secretaries and (d) I* members. [Discussion on the objective definition of active participation is deferred for now.] The null hypothesis would be that no significant differences exist. If that turns out to be true, we know that our problem is only lack of diversity among registrants. If it turns out to be false, we know that we have an internal problem of some kind as well. Brian
Re: W3C standards and the Hollyweb
On 27/04/2013 20:02, Alessandro Vesely wrote: A DRM add-on that individuals or small groups use to protect their stuff seems to be a chimera. Has anybody tried to design one? Brian
Re: W3C standards and the Hollyweb
On 26/04/2013 23:38, Alessandro Vesely wrote: On Fri 26/Apr/2013 02:53:58 +0200 Mark Nottingham wrote: Personally, I don't have a firm position on these issues, but I couldn't let this pass by. I've thought about this a bit and looked at some on-line discussions. In as far as this might be an IETF-W3C liaison issue (and it probably should be), I would suggest that three points could be made: 1. DRM is a fact of life, and it is therefore better that there should be a well-formulated standard than a free-for-all. A free-for-all is a guaranteed route to non-interoperability. 2. DRM should be off by default. That's probably a given (if a content provider doesn't use EME there will be no DRM) but it needs to be specified. 3. EME should have a very low or zero cost of entry for a content provider. Quoting from a commenter on The Register: The DRM mechanism must allow *individuals* (or small groups) a low-cost low-hassle way to use it. That's because the way to destroy the various evil DRM empires is not to steal content - it's to allow creators to manage the sale of their own creations without needing a big bad bloodsucker to help them. That means a DRM system that anybody can use to protect their own stuff. Brian
