Re: NIST documents
Dearlove, Christopher (UK) wrote: One draft I'm working on [...] (Of course I haven't been able to check the copyright on [NIST documents ...) As a author of IT-related documents, you should be aware that, by its constitution plus long lasting tradition, the US government works of authorship have no copyright claims on them. The principle being that we, the people paid for a civil servant to make a write-up, nobody can claim intellectual property. Maybe the openness of the Internet owes a lot to this tradition. So, NIST documents can be used as if in the public domain. Bizarrely, the RSA and early public key crypto patents were filed precisely because US government funding was involved, but that's part of a longer story. Regards, -- - Thierry Moreau CONNOTECH Experts-conseils inc. 9130 Place de Montgolfier Montreal, QC, Canada H2M 2A1 Tel. +1-514-385-5691
Re: article on innovation and open standards
Mikael Abrahamsson wrote: On Tue, 14 May 2013, Dale R. Worley wrote: The critical difference is that the IETF is an organization of *buyers* rather than an organization of *sellers*. Not that I have been active in the IETF that long (only a few years), but IETF is pretty vendor-heavy. Some sections of the IETF would be more vendor-heavy, e.g. the routing area. In those sections, only a serious economic study might tell to which extent the patent pool (wikipedia is your friend) excludes the permissionless inventor in those IETF sections. The DNS aspects pertaining to very high throughput nameservers appears vendor-heavy. I noticed some patents that are under the IETF IPR policy in this niche IT sector, and I am not aware of patent pools in this specific case. Otoh hand the whole point with IETF is that *nobody* is *excluded*, it consists of all interested parties and the barrier of entry is really low. Still in the DNS field, the lack of support of authoritative nameservers for generic resource record type would be a barrier to entry for permisionless innovation, maybe with a root cause linked to vendor-weight in a portion of the DNS field. Thus, permissionless invention occurs with the DNS TXT resource record type. Let me insist that these two observations are hypotheses. -- - Thierry Moreau CONNOTECH Experts-conseils inc. 9130 Place de Montgolfier Montreal, QC, Canada H2M 2A1 Tel. +1-514-385-5691
Re: STEAM: BOF proposal for Berlin
Dear Daniel, IETFers: With regard to security, I'm afraid the proposed scope of work is covered to a large extent by a breakthrough patent application titled Defending the namespace for which the abstract reads: This invention is about an global entity oriented declarative authentication and security system that can be used in the present and future internet based distributed applications and services. An entity here refers to an unique object (most likely to be physical or human) or aspect that can hardly be duplicated. The system provides both authentication and security (A S). It can be used in areas comprising one to one or one to many (OR or AND) content publication or distribution so that maximum granularity of access control is made possible. Examples comprise 1) A S in messaging or communication (one to one). 2) A S in publication or distribution or information sharing (one to many(OR)). 3) Secured document escrowing (one to many(AND)). 4) Declarative just in time A S for web-services. 5) Copyright protection for digital products. 6) Digital cash. 7) Internet based electronic voting system. 8) Witnessed digital legal papers. 9) Support large scale virtualized virtual private network and its applications. 10) etc. The reference is the US patent application publication 20040255137. If the BOF proceeds, at least this will deserve an IPR disclosure. - Thierry Daniel Raft wrote: STEAM: BOF proposal for Berlin You may have noticed a recent trend in the IETF towards very lightweight protocols for the Internet of Everything. http://tools.ietf.org/html/draft-draft-draft is the most fully developed proposal on the table today. It is extremely lightweight by simply using UDP and nothing else. Recently, however, that draft has been criticized for lack of congestion control. And rightly so, because the only way to have congestion control is to use TCP. And, TCP is all you need. But then, clearly, there aren't enough RFCs about TCP yet [RFC4627]. A new WG will therefore develop Secure TCP Extensions for Application and Management (STEAM). Again, TCP is all you need, but it hasn't been used for Provisioning very much yet. The main objective of the new WG is therefore an informational document for Secure Provisioning for Applications and Management using TCP Reimagined as an Attractive Protocol, SPAM-TRAP. We aren't quite sure yet whether STEAM will be in the Security, Transport, Application, or Management Areas, or whether it should have its own area (EVG for Internet of Everything). We will use the BOF in Berlin to figure out, and to set up the new EVG area in the IETF, and to restyle the IETF to Internet of Everything Task Force. One other field that STEAM will be working in is IETF process innovation. (We also figure you can't post to the IETF mailing list without including at least one process improvement suggestion. So we make two.) 1) You might notice there is no R in STEAM. This is because we have to increase collaboration within a diverse IETF. The RTG area already has the ROLL working group, which has been very innovative in getting routing protocols to standards track RFC before there is even a glimpse of security, applicability or management. Doing standardization in smoke-filled backrooms is unhealthy, and STEAM has many of the properties needed for a replacement process. We don't want to spill the beans just yet, but can already say the process innovation will be named in honor of the two WGs, STEAM/ROLL. 2) Finally, preparing for the global deployment of the Internet-Enabled Smart Grid (IESG), and to further increase diversity, we probably want to enable the use of steam-powered typewriters for IETF work. The STEAM WG will enhance the RFC format and process to allow direct publishing from typewritten sheets and scanned printouts of Word documents. See you at the STEAM BOF in Berlin, Daniel Raft
Re: IANA [Re: Last Call: draft-hoffman-tao4677bis-15.txt (The Tao of IETF: A Novice's Guide to the Internet Engineering Task Force) to Informational RFC]
Brian E Carpenter wrote: On 2012-05-31 09:24, SM wrote: ... In Section 3.2.3: Approves the appointment of the IANA Isn't IANA more of a U.S. Government decision? The IAB decides who acts as the IETF's IANA. RFC 2860 again. Brian See e.g. http://ntia.doc.gov/page/iana-functions-purchase-order -- - Thierry Moreau
Re: IPv6 Zone Identifiers Considered Hateful
Francis Dupont wrote: In your previous mail you wrote: Looking at the link-local address, it appears to be constructed from the interface's MAC address, and basically nothing else. ^^^ = note the IEEE spec says device MAC address and if the common interpretation is device == NIC there is at least one vendor where device == machine, i.e., you get the same MAC address so same link-local address on all the 10 interfaces of a 10 interface box! Regards francis.dup...@fdupont.fr PS: I maintain my opinion: zone identifiers don't suck, link-local addresses used where they should not definitely suck. Maybe link local addresses are erroneously used where one should use RFC4193 (Unique Local IPv6 Unicast Addresses) with L=1? (I mean where link local addresses are inconvenient but not necessary.) I.e. something like FDxx::::id where xx:: is 40 random bits that you pick-up as you wish, is a subnet id for your (local) routing scheme id is the 64 bits interface ID ... It's a suggestion. I guess the trouble of assigning addresses in this way is much smaller than tracking link local addresses derived from hardware serial numbers. The interface ID assignment strategy/tools with RFC4193 is deemed to be close to the strategy/tools useful for globally routable addresses. Is this well explained in the IPv6 tutorials? Regards, -- - Thierry Moreau
Re: RIM patents using a mime body in a message (and ignores IETF IPR rules)
Simon Josefsson wrote: Brian E Carpenter brian.e.carpen...@gmail.com writes: On 2009-11-24 06:44, Steven M. Bellovin wrote: On Mon, 23 Nov 2009 08:16:49 -0500 Scott Brim scott.b...@gmail.com wrote: Simon Josefsson allegedly wrote on 11/23/2009 5:03 AM: John-Luc said he is bound by confidentiality obligations from his company, and I think the same applies to most employees of larger organizations. There is nothing explicit in BCP 79 to protect against this apparent conflict of interest, or is there? Since disclosure is required for anyone submitting documents or participating in IETF discussions, a person who does not disclose IPR for this reason, or any other reason, must not contribute to or participate in IETF activities with respect to technologies that he or she reasonably and personally knows to be Covered by IPR which he or she will not disclose. Precisely. The conflict Simon mentions was of course known to most of the WG; that's one reason we have that clause. IMHO, BCP79 creates no particular problem for corporate lawyers who are instructed by their corporate management to ensure that the company behaves as a good citizen in its standards activities. This is strongly in the company's interests, anyway, since failure to disclose when required by a standards process threatens the validity of the patent. There is no requirement in the IETF process for organizations to disclose patents as far as I can see. The current approach of only having people participate, and disclose patents, in the IETF is easy to work around by having two persons in an organization doing different things: one works on specifying and standardizing technology, and the other is working on patenting the technology. Hi Simon, This is certainly correct in principles. But to which extent the IETF disclosure approach is easy to work around by having two persons ... is a matter of appreciation. My understanding is that it is not easy to arrange protocol engineer rolls in such a way. I'm quite sure you don't have a clear case which you can refer to support the opposite view. The reason I am confident is that both inventor status and an IETF contributor require creativity in general. The IETF collective engineering faces technological challenges like any other design group. I guess it is not realistic to expect managers to send protocol engineers with little creativity traits to the IETF in order to preserve the ability to file patent applications without disclosure. It really is not the IETF's problem. It is a problem for a company that chooses not to behave as a good citizen. The situation remains that the IETF does not have any mechanism to apply pressure on organizations to disclose patent information. This is certainly correct, but I am afraid the cause is more profound than the above IPR disclosure work around. Specifically, the Qualcom vs Broadcom case on JVT over H.264 IPR would have taught corporate lawyers that a standardization body membership contract binding to the corporation is a must for IPR disclosure enforcement against the corporation. (I am not a lawyer ...) The IETF does not use this approach. Regards, - Thierry Moreau /Simon ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: RIM patents using a mime body in a message (and ignores IETF IPR rules)
Russ Housley wrote: John-Luc: I am sending this note to help you understand the IETF IPR policies; they are fully described in BCP 79 (http://www.ietf.org/rfc/bcp/bcp79.txt). I hope this note clarifies the responsibilities of RIM employees (and anyone else) who participate in IETF. IETF participants engage as individuals, not as representatives of their employers (See Section B.1 of RFC 4677; http://www.ietf.org/rfc/rfc4677.txt). The obligation to follow the IPR policies in BCP 79 is an individual one, not a corporate one. Section 6.1of BCP 79 is quite clear; IETF Participants are required to disclose IPR which they reasonably and personally know applies to a Contribution. The BCP specifically excludes cases in which a participant is unaware of IPR held by their employer. Please do not hesitate to contact me if you need further clarification. In the present instance, the invitation to use the lack of personal knowledge as an excuse is ill-advised: a quick search for inventor name john-luc bakker in the US patent office database of published patent applications returns 34 patent applications with titles indicating a connection to data networks and mobility. It could have been that RIM internal IPR management would have isolated IETF contributors from personal knowledge of specific applications, but that seems not to be the case. Perhaps the Note Well has some intrinsic enforcement limitations (enforcement in the meaning that it would be useful for a third party - neither IESG not its trust - against a patent holder who had failed to comply). But I am not a lawyer and I don't know. Regards, - Thierry Moreau Russ Housley IETF Chair At 06:46 PM 11/19/2009, John-Luc Bakker wrote: Dear all, With regard to the recent discussion regarding RIM's recent IPR disclosures, I understand the community's concerns regarding the timeliness of the disclosure. As employees of companies we are bound by confidentiality obligations and, in addition, cannot always control our company's internal processes. The community's concerns have been brought to the attention of my employer and they are in the process of evaluating the concerns. My company has asked for your patience while they take the time to evaluate the concerns and determine if there is an appropriate course of action in this matter to alleviate the concerns of the community. Your understanding is appreciated. Kind regards, John-Luc ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: DNSSEC is NOT secure end to end
Masataka Ohta wrote: Christian Huitema wrote: That is, security of DNSSEC involves third parties and is not end to end. That is indeed correct. An attacker can build a fake hierarchy of secure DNS assertions and try to get it accepted. The attack can succeed with the complicity of one of the authorities in the hierarchy. It is a classic attack by a trusted party. Yes, the hierarchy has hops. For my domain: necom830.hpcl.titech.ac.jp, hierarechy of zones have hops of ., jp, ac.jp, titech.ac.jp and hpcl.titech.ac.jp. The authority hops are IANA, JPNIC, my university, and my lab. Though you may have direct relationship with IANA, JPNIC is the third party for both you and me. This is exactly like a chain of PKI CA's (replacing the path from bottom to top of zone hierarchy): For my [end-user administrative units], [chain of CA's] have hops of [CA run by IANA], [CA run by JPNIC], [CA run by my university], and [CA run by my lab]. I don't know what is meant by a direct relationship with IANA. If an intermediate authority has been compromised, it can just as well insert a fake NS record -- that's not harder than a fake record signature. So, with a compromised hop of an intermediate authority, record signature on the faked next hop key can be generated. Exactly the same with a compromised intermediate CA. Then, with a private key corresponding to the faked next hop key, record signature on the faked second next hop key can be generated. Exactly the same with a private key corresponding to the next intermediate CA along the chain (i.e. the one certified by the compromised CA). Then, with a private key corresponding to the faked second next hop key, record signature on the faked third next hop key can be generated. Same thing. Yes, security of DNSSEC is totally hop by hop. Thus, you imply a definition of hop by hop along digital signature relationships. Indeed, DNSSEC security is limited to the weakest link along the chain from the bottom to the top of the DNS hierarchy. Nothing new there. I don't think any DNSSEC expert ever claimed differently. Regards, - Thierry Moreau Masataka Ohta ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: DNSSEC is NOT secure end to end (more tutorial than debating)
Richard Barnes wrote: This debate has nothing to do with the security properties of DNSSEC. A basic assumption of the DNS is that what the authoritative server for zone says is, well, authoritative. The structure of DNS itself entitles JPNIC to point ac.jp wherever they want; by using a name within the .jp domain, you are agreeing to act within JPNIC's domain of control. JPNIC could set up an authoritative server for hpcl.titech.ac.jp completely independently of you, regardless of DNSSEC, and from the perspective of the DNS, that would be the right answer. I guess what Masataka was referring to is a different source of variance, i.e. an impersonation of JPNIC's authority over its domain of control (using a compromised JPNIC's private key). All DNSSEC does is make the assertions made in the DNS reliable -- it does nothing to change the locus of control. Reliable through a chain fo digital signatures. Reliable to the extent an impersonation attack (on the locus of control) does not occur based on a compromised private signature key. On the other hand, you can certainly use the DNSSEC protocol elements to do peer-to-peer security, just like you can use private DNS servers, and just like you can use TLS without trust anchors (i.e., with self-signed certs). Just hand out the public half of your ZSK to people you want to be able to verify names within your zone. Then you reduce the chain of digital signatures to a single one, raising confidence level at the cost of more key management hindrance. Indeed, this thread seems to be another attempt to understand the basic DNSSEC properties. - Thierry --Richard ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: DNSSEC is NOT secure end to end (more tutorial than debating)
Richard Barnes wrote: (That is: You already trust the zones above you to maintain the integrity of the zone on the *server*; This assumption does not stand universally. For some DNS users/usage, DNSSEC signature verification will be a must. The discussion implicitly referred to such uses. Then, it is legitimate to appraise the overall confidence in the DNSSEC chain of signatures, and to pinpoint the weakest link (e.g. the zone manager having the greatest likelihood of lousy private key protection in place). Indeed, DNS+DNSSEC is no different from plain DNS for those who are satisfied with the plain DNS. For those awaiting DNS+DNSSEC for some uses, it is useful to understand DNSSEC chains of digital signatures. Accesssorily, the zones above you means nothing to a relying party that is not validating its own domain. Regards, -- - Thierry Moreau ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Appropriate forum? (was: DNSSEC is NOT secure end to end)
To the IETF mailing list subscribers: The US government involvement in DNSSEC operations is almost certainly not in-scope for the ietf mailing list. Thus, it would be counterproductive to start a discussion based on Mr. Baptista comments on this topic (hence no in-line comments in the original message below). However, the question remains: which forum, if any, is appropriate for a discussion? I don't have the answer, so I merely share the following observations. A) ICANN was specifically requested to abstain from public consultations about its proposal to deploy DNSSEC at the root. This is in a letter from US Department of Commerce to ICANN, ref http://www.icann.org/correspondence/baker-to-twomey-09sep08.pdf (filed among other documents in http://www.icann.org/correspondence/ ). B) The US Department of Commerce issued a public comment notice (the deadline is now past), see http://www.ntia.doc.gov/DNS/DNSSEC.html . This forum has been used by Mr. Baptista. I was favourably impressed by the material written by NTIA staff (and published in the Federal Register), so I would recommend this reading (at http://www.ntia.doc.gov/frnotices/2008/FR_DNSSEC_081009.pdf ). However, this forum is not really interactive. C) Some other forums on which DNSSEC protocol and operational aspects are discussed frequently avoid and/or terminate discussions about US government involvement in DNSSEC operations for the DNS root. I do not blame their moderator or anybody else, I'm just reporting an observation. D) If any stakeholder group or representatives see some effectiveness in the WSIS, the discussions on DNSSEC deployment would fall under the heading critical Internet resources. I don't see much potential for active discussion on this front, but it's only my opinion. So, that's it. Anybody has other suggestions for an appropriate forum for DNSSEC deployment at the root *including* US government involvement? Regards, - Thierry Moreau Joe Baptista wrote: DNSSEC indeed violates the end to end principle. It's simply that simple. And it asks us to put our trust in the root a.k.a. ICANN. I don't think governments world wide are going to put their trust and faith in ICANN. The U.S. Government is the only government that has been bamboozled into adopting DNSSEC into .gov infrastructure. I wonder how President Obama would feel about handing over the keys to U.S. Government infrastructure to a U.S. contractor. I'd have trouble sleeping at night if that was the case. I've addressed this at length in my comments to the NTIA. http://www.ntia.doc.gov/DNS/comments/comment034.pdf If the U.S. government wants DNSSEC today then it must nationalize the roots. I don't even trust Vixie with the root. I remember when he hijacked the root with Postel. Or as they put it we were only running an experiment. In any case the new infrastructure campaign demands U.S. government roots be set up to exclusively serve U.S. network infrastructure. regards joe baptista p.s. If you want to secure the DNS end to end - think DNSCurve - not DNSSEC. http://dnscurve.org/ On Sat, May 30, 2009 at 7:27 PM, Masataka Ohta mo...@necom830.hpcl.titech.ac.jp mailto:mo...@necom830.hpcl.titech.ac.jp wrote: Francis Dupont wrote: = not only this is very arguable (for instance about the resource exhaustion) but no hop-by-hop/channel security, even something as strong as TSIG, can provide what we need, i.e., end-to-end/object security (*). Unless your meaning of end-to-end differs from that of David Clark, the following argument of his paper is applicable to DNSSEC. http://portal.acm.org/citation.cfm?doid=383034.383037 Rethinking the design of the Internet: The end to end arguments vs. the brave new world The certificate is an assertion by that (presumably trustworthy) third party that the indicated public key actually goes with the particular user. These certificates are principal components of essentially all public key schemes, That is, security of DNSSEC involves third parties and is not end to end. PS (*): I use the common meaning of end-to-end, not Masataka Ohta's one. I'm afraid you don't know who David Clark is and how he is related to the end to end argument. However, all the people who are qualified to discuss end to end do know him and his argument. Masataka Ohta ___ Ietf mailing list Ietf@ietf.org mailto:Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf -- Joe Baptista www.publicroot.org http://www.publicroot.org PublicRoot Consortium The future of the Internet is Open, Transparent, Inclusive, Representative Accountable
Re: Beyond reproach, accountability and regulation
David W. Hankins wrote: On Wed, Apr 29, 2009 at 02:03:00PM -0400, Phillip Hallam-Baker wrote: In theory we have a consensus based organization. In practice we have a system where it is rather easy for some people to take strategic offense as a tactic to shut down debate. 'Establishing (rough) consensus' is, at its root, Sophistic debate. What about Who controls the process controls the outcome. ? From time to time, this is my mental representation of IETF processes. - Thierry Moreau ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Proposal to create IETF IPR Advisory Board
Michael Dillon wrote: Some of the time, [...] the IETF should ask the FSF to collect their thoughts and write an Internet draft that explains why the proposed plan of action is bad, and why the IETF should take some other plan of action. That draft can then go to the WG and get resolved before a new protocol ever reaches RFC status. Under the rule that the IETF will make no determination about the validity of any particular IPR claim (BCP79), the WG chair(s) would simply object to discussions about such a draft (apparently no matter who authored the draft, but sometimes some IETF participants are more equal than others, so I'm not 100% sure). If you want to change this rule, e.g. the IETF may collect evidence useful to the determination of a particular IPR claim validity and/or scope then you were challenged to come up with a detailed proposal. My point in this discussion was that the IETF processes are increasingly inefficient because *at the participant level*, under the current rules, insufficient investigation and analyses are being made. But that's an incomplete diagnostic of the current situation, and I have no solution to propose. -- - Thierry Moreau CONNOTECH Experts-conseils inc. 9130 Place de Montgolfier Montreal, Qc Canada H2M 2A1 Tel.: (514)385-5691 Fax: (514)385-5900 web site: http://www.connotech.com e-mail: thierry.mor...@connotech.com ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Including the GPL in GPL code (Re: IETF and open source license compatibility)
Harald Alvestrand wrote: Simon, the example is at http://counter.li.org/scripts/machine-update. Take a look. There is a single file that contains both the program source and the GPL. I want to release this under the GPL. Now, I have three possible interpretations: 1 - The words of the GPL that say Everyone is permitted to copy and distribute verbatim copies of this license document, but changing it is not allowed. don't really apply in this case. 2 - The words of the GPL that say You may modify your copy or copies of the Program or any portion of it, thus forming a work based on the Program, and copy and distribute such modifications or work under the terms of Section 1 above don't apply to modifications of the portion of the Program that is the GPL 3 - I'm breaking the GPL Now, with your extensive knowledge of what the GPL means for included text which is it? 4 - The contradiction in licensing terms turns the work licensed by its own terms, that are not exactly those of the GPL. Furthermore, the original copyright holder breached the GPL *text* copyright. He did not breached the GPL itself since he is the original author of the work. The intent of the original copyright holder is clear however, despite a minor glith in document distribution. Simon and I and anyone else who whish to create derivative works under the GPL can fix it, and not carry forward the contradiction in licensing terms (the Harald intent above is not clear, the referenced work is not his work, and it is already released). Anyway, Harald highlighted a corner case in GPL licensing that creates some inconvenience (can't put GPL text in GPL'ed work, it must remain meta-data). IETF as a *document* editor is expected to use licensing terms that reasonably fits its purpose. The audience lobbyed by Simon should just live by inconvenience created by IETF licensing terms (no RFC text in GPL'ed software beyond fair use - it must remain as separate documentation). Routine open software distribution abide by these rules. Please preserve the integrity of IETF rules addressing the needs of a broader and a more diversified audience than the one lobbied by Simon. Regards, -- - Thierry Moreau ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: References to Redphone's patent
Lawrence Rosen wrote: Lots of the recent emails on this list refer to Redphone's patent but there is no such thing. In my emails, I used the reference to US patent application 11/234,404 as amended on 2008/01/25. As anyone who has ever worked with real patents knows, there is a great difference between a patent application and a patent. Whatever claims are written in patent applications are merely wishes and hopes, placeholders for negotiated language after a detailed examination of the application. Until the PTO actually issues a patent, nothing is fixed. And even then, newly-found prior art and other issues can defeat an issued patent. Indeed, plus the geographical applicability restrictions that are determined 30 or 31 months after the priority date according to PCT rules - the above patent application has national or regional applications in Australia, Canadian, and the EU (I didn't check the EPO database, perhaps it's not the whole EPC member states). Why are we all so afraid of Redphone? Who gives a damn what patent claims they hope to get? I guess (i.e. speculate) that it is more convenient for the FSF to get publicity / support with a case involving a small organization without significant market presence and lobbying resources that could retaliate an FSF campaign more visibly. I thought the GnuTLS connection triggered the FSF action, but Simon corrected me on this hypothesis. There's something wrong with the IETF process if spurious and self-serving assertions that a patent application has been filed can serve to hold up progress on important technology. I wish you'd ask real patent attorneys to advise the community on this rather than react with speculation and a generalized fear of patents. I agree. You may notice that the FSF did not share (AFAIK) any result of investigation into the patent application status which would include some professional advice. Actually, two PCT/WIPO search/examination reports are on-line, and one *denies* novelty to every claims but 3 of them, and denies inventive step to all of them! The patent applicant may (further) amend the claims at the national or regional phase, but the initial assessment is not so good for the patent applicant. Check by yourself, I do not provide professional advice in here. So it's really the FSF campaign that is detracting the IETF process here in the way you are alluding above. The Redphone's IPR disclosure 1026 verbatim does not detract the IETF process. Again, finer investigations and analyses of IPR issues (finer than ideological opposition to patents) would be benefitial to the IETF. Regards, - Thierry Moreau ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: References to Redphone's patent
Lawrence: I think we are close to intellectual agreement([0]), but see below. (Nothing to do about my personal position as an [---] advice provider.) Lawrence Rosen wrote: Thierry Moreau wrote: Check by yourself, I do not provide professional advice in here. And that's why I made my suggestion that we do these analyses in a professional manner! Too many patent-savvy attorneys (and their companies?) expect the community to decide these things in a random fashion. The IETF--collectively--needs professional advice, including from you. I will allow that you speak for yourself and offer no guarantees or warranties. But expert attorneys need to give us their expert opinions about the effects of specific patents on our specific work. That's why I'm so irritated that the previous IPR WG, since disbanded (fortunately), refused even to discuss a patent policy for IETF. Of course such studied ignorance can lead to community displays of confusion and anger. Hence the FSF campaign and others like it; entirely justified. Maybe s/justified/to be expected/? I don't quite follow how the FSF campaign may be justified if the underlying patent application details has been ignored. If among the high volume e-mails triggerd by the FSF there was one based on finer investigation and analysis, I would expect the IESG to count this one as an IETF community participation. Simon, as a GnuTLS project leader, stated he did not read the patent. You seem to suggest that studied ignorance should be fixed at the IETF/IESG institution level, and until done, the institution gets what it deserves (i.e. is hurt by FSF and othe campaigns as expected). I'm comfortable with either way, fighting studied ignorance at the participant or institution level. - Thierry Moreau [0] intellectual agreement is distinct from agreement as understood by a lawyer and agreement in the terminology used in UP patent application 11/234,404 - by the way it's Friday afternoon! ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Review of draft-ietf-tls-authz-extns-07
Simon, Thanks for these clarifications. They explain how you, and how apparently the FSF came to the conclusion about the current Redphone IPR situation. (No need to repeat my opposite views already on the record.) - Thierry Simon Josefsson wrote: Thierry Moreau thierry.mor...@connotech.com writes: Simon Josefsson wrote: When evaluating whether to implement a particular technology, you need to evaluate all the risks. The text of patent (applications) helps in the evaluation. My point is that the actions of patent holders is significantly more relevant. Dear Simon: Interesting, and completely new to me. Do you have any guidelines / methodology / evaluation criteria / sources of precedents or any other sources of law? According to those, one could turn emprircal-observations-of-patent-holder-actions into a) an evaluation whether to implement and/or b) an evaluation whether to adopt as an IETF document (standards track / informational / experimental). Perhaps there is some form of non written IPR etiquette. See RFC 3669, it contains good discussion and interesting examples. The evaluation done in the examples of RFC 3669 does not generally seem to be of what's in the actual patent text. Instead people have evaluated the actions taken (or not taken) by patent holders. This re-inforces my point. Perhaps you have an intuitive talent at this type of analysis and you are the Oracle in the present instance, i.e. you made the evaluation and then the FSF started its campaign. Heh. I have been careful to avoid reading any patent text or make any judgement of the patent disclaimer and licensing conditions. That is not my field of expertise. I do not have any influence over what the FSF does or decides here. One person can't reliable make a decision like this, it needs to be discussed by the community and people can provide their thoughts on the topic. Eventually, after hearing what people have said, everyone can form their own opinion of the situation. This is what I've done, and I have also made my opinion publicly known in this discussion. That doesn't mean I cannot be convinced otherwise. There are two things I believe are critical in this discussion: 1) how widely the patent filer believes their patent applies, and 2) the licensing conditions offered by the patent filer. Item 2) has apparently been evaluated by the FSF and they found that the conditions doesn't allow wide use of implementations. Reading the patent disclaimer myself, I don't see anything that invalidates this evaluation, and I see things that re-inforce the evaluation. The FSF has access to legal aid and has a track record in working in this area. Some engineers, like Pasi and Sam seems to believe the opposite. However, the FSF takes the legal risk if I re-add the tls-authz implementation to GnuTLS. So to me the FSFs evaluation carry more weight. Item 1) is, alas, difficult to judge without the vulcan mind melt, but it is warranted to be conservative. The licensing conditions demanded for certain uses also gives some indication of the scope of the perceived applicability. As far as I can tell, the simplest approach to resolve the problem would be to offer the technology for free use to anyone without limitation. This solves item 2) and makes the more difficult to judge item 1) irrelevant. /Simon ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Review of draft-ietf-tls-authz-extns-07
. To sharpen this point, consider the case where RedPhone sold the patent to some other entity which then decided to file suit. This is not a purely theoretical worry. While I have not studied the patent, a number of the claims seem rather broader than what is described above and quite possibly cover all uses of the protocol described in this document. This would apply to any IETF IPR disclosure, and it essentially says that no matter what the inventor-entrepreneur discloses, hypothetical developments from loosely related precedents, or even mere imagination, will ever put the IPR submitter in the devil's role. OK, you seem to have better faith in big corporations - I don't know why. Basically, you state that an IETF IPR disclosure can hardly be deterministic enough for those ideologically opposed to patents. This statement detracts the whole IETF process. Aren't you committed to the advance of the IETF? If so, the IPR disclosure mechanism is a bait-and-trap mechanism: an inventor-entrepreneur is told Please disclose in good faith, and then he is forever presumed to act in bad faith. TECHNICAL ISSUES S 3.3. As Simon Josefsson notes, the length of the SAMLAssertion should allow up to 2^24 or 2^32 bytes. As far as I know, the only objection to this is backward compatibility. S 3.3.1 I'm quite concerned about the use of entityName field to bind an AC to a certificate. In the absence of Internet-wide name subordination, there may be many certificates with the same DN issued by different CAs. As the issuer of an AC, I generally want to authorize specific entities, not anyone who has a DN that chains to one of the 150 roots in your browser. I would remove this option entirely. S 3.3. This URLandHash production has a nasty futureproofing bug, because the length isn't self-contained. If the server uses a hash the consumer doesn't recognize, the consumer can't even parse the rest of the extension, even if it contains other AuthorizationDataEntry objects which the client could otherwise parse and which would in and of themselves be sufficient. The URLandHash production should either have a length or have the hash be a variable length value, e.g., opaque hash0..255. This would allow parsing even if you don't know the hash. S 3.3.3 This circular reference issue seems bogus to me. There are lots of places where it's not going to be relevant, and SHOULD is overstrong. S 4. This document should use the RFC 5246 hash registry (and its contents), not define its own. Note that the values in that registry differ from those in this draft. EDITORIAL ISSUES S 2. The beginning of this section needs to be clearly marked as non-normative, since it's just a recap of 4366. S 3. can be exchanges - can be exchanged -Ekr ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf -- - Thierry Moreau CONNOTECH Experts-conseils inc. 9130 Place de Montgolfier Montreal, Qc Canada H2M 2A1 Tel.: (514)385-5691 Fax: (514)385-5900 web site: http://www.connotech.com e-mail: thierry.mor...@connotech.com ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Review of draft-ietf-tls-authz-extns-07
Scott Brim wrote: Excerpts from Thierry Moreau on Wed, Feb 11, 2009 09:53:42AM -0500: You seem to assume that patent rights are created by the IPR disclosure, while they are created by the *patent* (in this case still at the application stage) that you didn't study. Actually intellectual property rights are never firm until tested in the courts, and even after that they may change. Obviously. However a big step towards determinism is achieved when someone actually reads the patent application versus *not reading*. My point is that IETF participants doing their assessment of the pros and cons should at least be aware that the reference citation in the IETF IPR disclosue entry (e.g. US patent application 11/234,404 in the present instance) is highly relevant. Protocol engineering is improved when relevant facts are taken into consideration. - Thierry Moreau ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Review of draft-ietf-tls-authz-extns-07
Simon Josefsson wrote: When evaluating whether to implement a particular technology, you need to evaluate all the risks. The text of patent (applications) helps in the evaluation. My point is that the actions of patent holders is significantly more relevant. Dear Simon: Interesting, and completely new to me. Do you have any guidelines / methodology / evaluation criteria / sources of precedents or any other sources of law? According to those, one could turn emprircal-observations-of-patent-holder-actions into a) an evaluation whether to implement and/or b) an evaluation whether to adopt as an IETF document (standards track / informational / experimental). Perhaps there is some form of non written IPR etiquette. Perhaps you have an intuitive talent at this type of analysis and you are the Oracle in the present instance, i.e. you made the evaluation and then the FSF started its campaign. May I invite you politely to bring some form of rationality to this. I am confident that you have such potential. In the meantime, I stubbornly stick to my reading of the IPR disclosure 1026 section 3 along with the US patent application 11/234,404 independent claims as amended on 2008/01/25. I hereby acknowledge that this action may be detrimental to future evaluations of my actions with respect to the IPR etiquette as you may have intuitive knowledge. Regards, -- - Thierry Moreau CONNOTECH Experts-conseils inc. 9130 Place de Montgolfier Montreal, Qc Canada H2M 2A1 Tel.: (514)385-5691 Fax: (514)385-5900 web site: http://www.connotech.com e-mail: thierry.mor...@connotech.com ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: FWIW: draft-housley-tls-authz-extns-07.txt to Proposed Standard
I agree with Brian and Marshall, but let me introduce a different perspective on the issue. Marshall Eubanks wrote: [...] I don't see any sensible way you get from the [Brian interprtetation] to the [FSF interpretation]. Maybe it's a matter of ideological objection to patents. Engineering is not always rational, ideology sneaks in in various ways, sometimes under the name ethic. So you see a bunch of instantaneous IETF volunteers who whish to bring a consensus based on some form of ethic (as they see it, I presume). What can the IETF do? Is there some obscure provision in IETF processes that can turn down participation based on manifest ideological grounds that do not resist analysis from another perspective? Incidentally, it is intriguing to see the FSF deeply rooted in the Copyright foundation (Berne convention) for ensuring legal protection of intellectual property, and at the same time so ideologically opposed to the patent foundation (Paris convention). But at this point, it becomes useless to argue with them about patents. Some form of procedural integrity should be sought by the IETF if there is anything to be salvaged after being victimized by instantaneous volunteering based on ideological grounds. Good luck! -- - Thierry Moreau CONNOTECH Experts-conseils inc. 9130 Place de Montgolfier Montreal, Qc Canada H2M 2A1 Tel.: (514)385-5691 Fax: (514)385-5900 web site: http://www.connotech.com e-mail: thierry.mor...@connotech.com ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [Sip] Last Call: draft-ietf-sip-dtls-srtp-framework (Frameworkfor Establishing an SRTP Security Context using DTLS) to ProposedStandard
Dear Pasi, Thanks for pointing many RFCs and an approved draft as useful precedents applicable to the draft-ietf-sip-dtls-srtp-framework. This indeed addresses the issue I raised. See in-line below for feedback not specific to the draft at stake. [EMAIL PROTECTED] wrote: Hi Thierry, There's ample precedent for using self-signed certificates to carry public keys in situations where a bare public key mode (if TLS/DTLS had it -- IKEv2 does have this, BTW) would have worked, too. Exactly the same approach as in this draft (exchange fingerprints via SDP, and use those to check self-signed certificates used in TLS/DTLS) is already used in RFCs 4572, 4582, and 4975. In this lineage, I find it difficult to follow the many security schemes which ultimately allows a relying party to affix a trust rating to the bind between a public key and a remote party identification. (The many security schemes are created by the many alternatives in the specifications.) As an example, in the section 14.4 (end of 2nd paragraph) in RFC4975, I read: If the endpoint is also able to make anonymous sessions, a distinct, unique certificate MUST be used for this purpose. For a client that works with multiple users, each user SHOULD have its own certificate. Because the generation of public/private key pairs is relatively expensive, endpoints are not required to generate certificates for each session. It is unclear whether distinct, unique certificate also imply dictinct, unique public/private key pair. I don't recall a generic mandatory provision where certificate rollover implies public key rollover. (Obviously public key commonality among users or sessions somehow impairs anonymity.) This is just an example of questions I ask myself in reading these elaborate specifications where the rationales for establishing trust are found only after figuring out a specific selection of protocol deployment options. Several other RFCs (e.g. 3261, 3920, 5380) and drafts (e.g. draft-ietf-syslog-transport-tls, currently in RFC Editor Queue) also use self-signed certificates in some way. I broadly classify these in two categories: SSH-public-key-introduction derivatives, where an operator is expected to accept the remote party public key upon first use, which is an un-debatably effective deployment strategy. RFC3920 (section 14.2) is an interesting case which formalizes the browser pop-up windows for accepting security certificate (otherwise thou shall not browse) in the case of instant messaging. I wasn't able to come up with a characterization fo RFC5380. It seems to make a statement about the possible existence of self-signed certificates, but the purpose of this statement was unclear to me. (Of course, using self-signed certificates for some particular purpose can't set a precedent that they'd be the best solution to all possible problems. They're a useful tool, but some problems require using other tools.) (Indeed.) Best regards, Pasi Same, -- - Thierry Moreau ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [Sip] Last Call: draft-ietf-sip-dtls-srtp-framework (Framework for Establishing an SRTP Security Context using DTLS) to Proposed Standard
The IESG wrote: The IESG has received a request from the Session Initiation Protocol WG (sip) to consider the following document: - 'Framework for Establishing an SRTP Security Context using DTLS ' draft-ietf-sip-dtls-srtp-framework-04.txt as a Proposed Standard This document approval at the IESG level might signal a shift in the IETF consistent use of PKI security certificates for remote party authentication in (D)TLS protocols. The present comment is submitted to make sure that the IESG decision is an educated one, and not made inedvertantly. If another document previously approved by the IESG is an accepted precedent for the subject matter discussed below, the present comment may be ignored. The present comment is neither for or against advancement of the draft. From the introduction section of the draft: The goal of this work is to provide a key negotiation technique that allows encrypted communication between devices with no prior relationships. The media is transported over a mutually authenticated DTLS session where both sides have certificates. It is very important to note that certificates are being used purely as a carrier for the public keys of the peers. This is required because DTLS does not have a mode for carrying bare keys, but it is purely an issue of formatting. The certificates can be self-signed and completely self-generated. From these indications it is easy to see that the framework would (ideally) require a (D)TLS protocol derivative in which bare peer public keys can be carried without the burden of security certificate. Despite the above wording, the current lack of such a (D)TLS mode might be more than a mere issue of formatting - it might be a consequence of a long-standing policy at the IETF. If this draft is approved by the IESG, it might signal that similar uses of self-signed-at-will (or otherwise meaningless) security certificates is an approved approach for circumventing the lack of a bare public key (D)TLS mode. Note that this is different from the PSK-TLS mode (pre-shared key) which explicitly relies on pre-established symmetric keys as a *replacement* for security certificate assurance. It is my understanding that the self-signed-at-will (or otherwise meaningless) certificate approach is technically feasible but should remain standardized outside of the IETF activities, if at all. Based on this understanding, my draft draft-moreau-pkix-aixcm (that also falls in this broad approach) has been submitted as a non-IETF informational RFC. (A comparative analysis between the SIP draft and mine is a matter of implementation strategy for the overall approach, and is thus out of scope for the present comment.) See http://www.rfc-editor.org/queue2.html#draft-moreau-pkix-aixcm . In any event, this comment is made for the sole purpose of making IESG/IETF directions more explicit. Thanks to Eric Rescorla who brought my attention to the similarities between the SIP draft and an early version of the ideas behind my draft. Regards, -- - Thierry Moreau CONNOTECH Experts-conseils inc. 9130 Place de Montgolfier Montreal, Qc Canada H2M 2A1 Tel.: (514)385-5691 Fax: (514)385-5900 web site: http://www.connotech.com e-mail: [EMAIL PROTECTED] ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: NTIA request for feedback on DNSSEC deployment at the root zone
Brian E Carpenter wrote: Like it or not, civil servants somewhere in an office called NTIA are faced with the task of deciding about these (boring but required) DNSSEC KSK scenarios. Actually they have another option, which is to leave ICANN alone to take the technical decisions for technical reasons, including getting advice from the IETF if they want. Someone may naively believe the NTIA staff *has the option* to let ICANN alone on DNSSEC deployment decisions. But that's not true, because the US administration established, and now abides, by the US Principles on the Internat's Domain Name and Addressing System. That's reference 19 in the Notice of Inquiry. Any submission *aiming* at changing those principles will be quietly ignored by NTIA, a waste of energy from the part of the submitter, and out of scope. But I see your point if you suggest that technical comments should be accompanied by a disclaimer against any implied admission (acknowledgement) of legitimacy for the US governement to maintain oversight of ICANN and/or IANA. Regards, -- - Thierry Moreau ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: NTIA request for feedback on DNSSEC deployment at the root zone
Brian E Carpenter wrote, to multiple mailing lists of which ietf@ietf.org is the only relevant as far as I am individually concerned: On 2008-10-10 03:50, Olaf Kolkman wrote: There are links to a number of process flow diagrams that may interest you. For easy accessibility of those links see: http://www.ntia.doc.gov/DNS/DNSSEC.html I don't think we should endorse in any way the implication that the NTIA or any other part of the US (or any other) government gets to decide about this. So I suggest that any formal reponse from the IAB or IESG should be very clear that this is a decision for the community to take and implement. Wow, that's a late wake up call! The legaleese that binds ICANN to the US government has been around since ICANN inception. It's this very legaleese that makes the US government the ultimate permission gate needed for DNSSEC root deployment. That being said, it's obviously a very desirable thing to do, and government encouragement seems welcome. I can't comment on which of the detailed proposals is technically best. This inability makes sense to me, because the IETF (if I'm correct, your contributions are mainly supportive of the IETF-IESG progress - i.e. effectiveness, influence, assertions of legitimacy and representativeness, and why not, power) didn't challenge the ICANN-US governemnt-Verising position in DNS operational issues. In other words, the IETF has not been concerned (beyond relatively minor activity in dnsop wg) with the ICANN mission, which is multi-faceted. Like it or not, civil servants somewhere in an office called NTIA are faced with the task of deciding about these (boring but required) DNSSEC KSK scenarios. Indeed, this activity looks like the last permission before actual implementation progress towards deployment - hopefully it is. At its face value, the NTIA call for comments plainly delineates the scope of the issues, their relevance, available options, and the like. If you challenge *now* their legitimacy to so fulfill their historic role, I don't see whoose progress it is. I would add, as a careful observer of NTIA involvement in ICANN / Internet governance, that processes followed by civil servants paid by the US federal government seem quite transparent, open, and accountable, thanks to things like 1) every output documents in the public domain, 2) subject to FOIA inquiries (Freedom of Information Act), 3) parliamentary oversight through reports to the the House and hearings, 4) the NOI process (Notice of Inquiry) that is being used in the current instance. (Each of these have specific instances where Internet governance aspects were the central subject matter.) In my view, this overall procedural landscape compares fairly well to e.g. the un-timeliness of release of IAB meeting minutes (pun intended to Olaf). Thus, in the above like it or not, the arrangement is not as distateful as it looks like at first glance. In other tribunes, I may be very critical of what NTIA does or does not. But this is somehow unrelated to the processes that are followed. Regards, -- - Thierry Moreau ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Possible RFC 3683 PR-action
Russ Housley wrote: Raising a technical problem anonymously does not seem to be a concern. However, there could be significant IPR problems with anonymous solutions to technical problems. It is my understanding that IETF is already in this type of problems. Solutions contributed by employees of large organizations could be problematic, as soon as unpublished patent applications are considered confidential corporate trade secrets circulated on a need-to-know basis, which is recommended practice by patent practitioners anyway. Sometimes one wonders even about published patent applications, especially when a US patent agent expects broad claims to be tailored to the prior art in the course of examination - hardly anyone from the corporation would be allowed to make well-informed statements about the connection of the patent application to an SDO activity. In practice, I suspect that many corporations abstain from contributing to IETF in specific standardization areas where they have an IPR strategy, and so the scope of IETF activities - and achievements - is shrinking. Russ ___ IETF mailing list IETF@ietf.org https://www.ietf.org/mailman/listinfo/ietf -- - Thierry Moreau CONNOTECH Experts-conseils inc. 9130 Place de Montgolfier Montreal, Qc Canada H2M 2A1 Tel.: (514)385-5691 Fax: (514)385-5900 web site: http://www.connotech.com e-mail: [EMAIL PROTECTED] ___ IETF mailing list IETF@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Nominet position paper about Signing the Root.
Dear Roy and IETF-ers: A quick reaction to this document: Good contribution: at last there is a documented proposition for the view that DNSSEC root signature is strictly a technical management issue. This document uses a two-tiered organization for root key management, respectively handling the KSK private keys and ZSK private keys for signature operations. Such a two-tiered organization is deemed to be present in the final solution. Maybe a difficulty lies in the selection of RZM as one of the two tiers. The document author(s) should check if a current project at IANA is indeed to integrate the RZM function in IANA operations. In view of the possible merger of IANA and the RZM function, the document author(s) should state what minimal conditions, in terms of institutional independence, they expect between the two tiers of control over the DNSSEC root keys. Regards, -- - Thierry Moreau CONNOTECH Experts-conseils inc. 9130 Place de Montgolfier Montreal, Qc Canada H2M 2A1 Tel.: (514)385-5691 Fax: (514)385-5900 web site: http://www.connotech.com e-mail: [EMAIL PROTECTED] ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Withdrawal of Approval and Second Last Call: draft-housley-tls-authz-extns
Dear Mark: You volunteered extensive explanations about the specifics of your patent claims and licensing conditions per IPR disclosure 833. Thanks for doing so. There is no agreement or consensus to reach on these substantive questions, but your explanations may be useful to other participants in making their opinion on how the ietf standard drafting activities may proceed. Stated differently, I don't think you are negotiating licensing terms with the discussion forum: you state your best description of licensing terms in the IPR disclosure, and the ietf does its own thing, i.e. standards drafting activities. I doubt, however, that general principles (for standard drafting activities) can be easily inferred from the lessons of IPR disclosure 833, which is simply too complex! Regards, -- - Thierry Moreau CONNOTECH Experts-conseils inc. 9130 Place de Montgolfier Montreal, Qc Canada H2M 2A1 Tel.: (514)385-5691 Fax: (514)385-5900 web site: http://www.connotech.com e-mail: [EMAIL PROTECTED] ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Last Call: draft-ietf-dnsext-rollover-requirements -- Comment submission
Dear IESG participants: Now that the draft-ietf-dnsext-rollover-requirements comes to the IESG, I suspect the document should be reviewed with a broader perspective than the interoperability focus of the DNSEXT wg. This draft is a requirements document that supports a protocol document, i.e. draft-ietf-dnsext-trustupdate-timers. In the DNSEXT wg, I objected to the requirements document, but acknowledged that the protocol document seems coherent with the requirements as documented. In this context, I bring to the IESG three questions about the draft-ietf-dnsext-rollover-requirements: (A) Is the redefinition of IPR procedures in a working group requirements document an acceptable precedent in IETF governance? See the text of document section 5.2 which was instrumental in the adoption of the protocol document by the DNSEXT wg. (B) ICANN (with the assistance of its IANA operating entity and DNS root operators) is the foremost operator for the protocol to be adopted by the IETF for automated DNSSEC trust anchor key rollover. Was the ICANN perspective taken into account in the document development process to the satisfaction fo the IESG? (C) In the later phase of DNSEXT wg activities in this area, an IESG member expressed concerns about the absence of a security model in the protocol document (see comment by Eric Rescorla at http://ops.ietf.org/lists/namedroppers/namedroppers.2006/msg01027.html and replies by Mike St-Johns at http://ops.ietf.org/lists/namedroppers/namedroppers.2006/msg01036.html and myself at http://ops.ietf.org/lists/namedroppers/namedroppers.2006/msg01038.html). Does the IESG perspective call for a greater attention to a formal security foundation in the requirements specifications phase as well? Despite my personal reservations about the DNSEXT wg process that brought the two drafts to their current state, e.g. question (A) above, I do not challenge the fact that rough consensus was reached at the wg level. Thus, the above three questions would be relevant to the extent that the IESG perspective may be more encompassing than the wg one. Thanks for your attention to the DNSSEC protocol extension project; in any event, it remains a fascinating application scheme for public key digital signatures. Best regards, -- - Thierry Moreau CONNOTECH Experts-conseils inc. 9130 Place de Montgolfier Montreal, Qc Canada H2M 2A1 Tel.: (514)385-5691 Fax: (514)385-5900 web site: http://www.connotech.com e-mail: [EMAIL PROTECTED] ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
