Re: draft-housley-two-maturity-levels
John C Klensin <john-ietf@jck.com> Tue, 02 August 2011 22:51 UTC
Return-Path: <john-ietf@jck.com>
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 88F9511E80E3 for <ietf@ietfa.amsl.com>; Tue, 2 Aug 2011 15:51:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.63
X-Spam-Level:
X-Spam-Status: No, score=-102.63 tagged_above=-999 required=5 tests=[AWL=-0.031, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LzXT2ndUL2Y0 for <ietf@ietfa.amsl.com>; Tue, 2 Aug 2011 15:51:13 -0700 (PDT)
Received: from bs.jck.com (ns.jck.com [209.187.148.211]) by ietfa.amsl.com (Postfix) with ESMTP id 62C0111E8095 for <ietf@ietf.org>; Tue, 2 Aug 2011 15:51:12 -0700 (PDT)
Received: from [127.0.0.1] (helo=localhost) by bs.jck.com with esmtp (Exim 4.34) id 1QoNnr-000CEd-Cg; Tue, 02 Aug 2011 18:51:12 -0400
Date: Tue, 02 Aug 2011 18:51:10 -0400
From: John C Klensin <john-ietf@jck.com>
To: "Joel M. Halpern" <jmh@joelhalpern.com>
Subject: Re: draft-housley-two-maturity-levels
Message-ID: <E1090BD02A7BD74AA756B06E@PST.JCK.COM>
In-Reply-To: <4E36C3E3.6050500@stpeter.im>
References: <20110728121904.2D22AD7A76F@newdev.eecs.harvard.edu> <12B69DB8-AFDD-4C40-BC9A-0A8158D9F7C0@nostrum.com> <0D43A851-C57B-484F-ADDD-BBD7A412689C@standardstrack.com> <4E343791.7040401@qualcomm.com> <4E3439CE.4030509@joelhalpern.com> <4E36C3E3.6050500@stpeter.im>
X-Mailer: Mulberry/4.0.8 (Win32)
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Cc: Pete Resnick <presnick@qualcomm.com>, Bradner Scott <sob@harvard.edu>, IETF <ietf@ietf.org>
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ietf>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 02 Aug 2011 22:51:17 -0000
On 7/30/11 11:05 AM, Joel M. Halpern wrote: > It seems to me that this does two things, both small but > useful. 1) It makes a minor change in the advancement > procedures so that they are more reasonable. They may still > not be sufficiently reasonable to be used, but it improves > them, and thereby improves the odds. Actually, there is no evidence that this is an improvement. I'd agree that it is a minor change, but there has been no serious analysis of whether it is an improvement or not. To the extent to which approving this lowers the odds of considering and making changes that might actually have significant effects (e.g., really sorting out what maturity levels mean in a world of increasingly complex standards), it is harmful. See long discussion below. > 2) It is coupled to an > intent to actually behave according to what the document > says. Such an intent is obviously not feasible without some > change. Well, yes and no. My sense of the discussion over the last year is that a significant fraction of the community believes that the critical path change in this area is an adjustment to the threshold for Proposed Standard. That issue is addressed in draft-bradner-restore-proposed, which requires no change to RFC 2026 or other formal procedures at all. It is not addressed in this document. > It is useful to have our behavior and our documented > description of how we work match because the mismatch causes > confusion, at least for new participants, and sometimes even > for experienced participants. I agree with this. But this document doesn't make nearly enough of a contribution in that area to justify approving it. It addresses exactly one provision of our processes in which documentation and practice don't align, a provision about which there is no subtlety or confusion within the community at all (even though new participants may be confused). If the issue is important, then let's make a serious effort to update the places where 2026, 2028, 2031, 2360, 3710, 4071, and probably several other documents have fallen at least somewhat out of line with reality. If the particular issue of the annual review is really more important than any of those other issues, I assume that a stand-along document that changed it would rapidly achieve community consensus (albeit with some complaints about wasted time). Certainly it should not be sufficient to justify approving this document... the change is almost irrelevant to it. > It might be the case that it will improve the advancement > percentage. It might not. I can not imagine that it will > make that even worse. I can because the effects of changes like this are actually very hard to predict. It increases the requirements for the second level, however slightly. Since we have trouble getting things to the second level now, that increased requirement might reduce incentives to bring things off Proposed at a least as much as a theoretical "just one more level and then you are finished" change would increase those incentives. By changing Proposed from "1/3 of the way" to "1/2 way or a bit more", it might remove a small incentive to take the additional step. In addition, the "publication without a new RFC" provision may actually further increase the de facto requirements for Proposed Standards by requiring that those documents be edited to a high standard of clear English and specification precision. While, IMO, we have taken too little advantage of it, the current provisions of RFC 2026 permit publishing a Proposed Standard as soon as the WG understands it, leaving language cleanup (and refined translation from the writing styles of many people in the community whether native speakers of English or not) for Draft Standard versions. More important, for those of us who believe that a maturity system based on rigid named categories that apply to entire documents has outlived its usefulness as our specifications have become more complex, approval of this document is almost certain to cause consideration of such approaches to be postponed by some years as people complain that the changes made in this draft must have time to take effect and be evaluated. --- A more extended analysis of other aspects of the situation with this document follows. Those who don't like extended analyses might want to stop reading at some point. A very long time ago, a then-professor of mine observed that one of the most common sources of failures in engineering, especially computer engineering, was to look at a problem that seemed too large or too intractable, find some easily-changed and tractable part of the problem, do something with it (almost anything), and then claim that significant progress had been made on the original/ real problem because one had started on it. In many cases, the approach actually makes the real problem harder: systems become more complex, applying remedies later turns out to be more complicated, and so on. The narrow "solution" may also use up energy and creates expectations that make it harder than it would have been otherwise to take on the real work when the narrow job fails to solve any significant problems. An even more insidious version of the same approach is to identify a problem and claim it is serious enough that one needs to do _something_. One then proceeds to do something that has nothing at all to do with the problem, just to demonstrate motion (or in the hope that setting a butterfly in motion in one part of the world will cause major change elsewhere). These approaches are very different from taking a large design issue and modularizing it into pieces that can be worked out separately but with clear and well-understood interfaces. Doing that right requires that the overall design issue be understood well enough to define all of the modules and interfaces, not doing one piece, ignoring the poorly-understood rest, and hoping that things will sort themselves out. The IETF periodically falls into this trap. We often see protocols that are designed to handle the easy issues adopted without consideration of the harder ones and edge cases, only to discover that those protocols represent a framework into which solutions for the other issues won't fit. The largest symptoms of this used to show up only with Security issues -- protocols being designed without security provisions with the expectation that security would somehow be patched in later... and despite repeated experiences that such patches are rarely completely satisfactory. Now we see it spreading: I've seen "we knew about those issues but ignored them and now have to clean up the mess somehow" comments in two separate WGs in recent weeks and suspect that there are many more. Many of the comments on this list try to justify approving this draft on the same basis. These "there is a problem so let's do something and hope it will help", "even though we can demonstrate no logic that would predict that the change being proposed will result in the desired effect", and "let's fix something to show that we can" approaches are _always_ justified on the basis of "baby steps" or "incremental efforts". Those justifications would be quite reasonable if we actually had good evidence of the linkages. In the absence of such demonstrated linkages, we are just thrashing around and wasting energy --energy that, under other circumstances, could actually be used to address the problems. So, while I applaud the efforts of the authors of this draft to remove controversial and largely extraneous material, it seems to me that the core issue remains the one that many people have commented on in much earlier versions: At present, we don't get many documents from Proposed Standard to Draft Standard, despite the requirements for Draft Standard being slightly lower than those set forth for Internet Standard in this document. We have a possibly-serious problem with the norms for Proposed Standard being too high in practice --far beyond what RFC 2026 requires. It is noteworthy that draft-housley-two-maturity-levels no longer makes any claim to solve that problem. On the other hand, there has been considerable discussion in the community, previously supported by the strongest advocates for the predecessors of the current draft, that the norms for getting to Proposed Standard _are_ the keystone problem. I don't personally believe that -- I think things are more complicated-- but I do see it as a critical element (see draft-bradner-restore-proposed (expired today but can be reposted if that would be useful)). So this draft now ignores the threshold problem for Proposed Standard and argues that "Changing the Internet Standards Process from three maturity levels to two is intended to create an environment where lessons from implementation and deployment experience are used to improve specifications". But there is no logic to support the belief that intention will be satisfied. The purpose of the three-level system is to create an environment where the same lessons can be learned, applied, and documented. This document does nothing to change or improve that environment unless one believes that, magically, removing the third level will increase motivations for getting things to draft. The problem, which the document still describes, is that documents don't move off the first level, not that somehow the existence of the third one is pressing things down. In progressing by baby steps, actual babies fall down a lot. Usually they learn while falling and keep trying until they get it right. Equally important, for their purposes, the important target is learning how to walk more reliably, not reaching a specific goal or solving a particular problem. The IETF lacks those advantages: First, we are focused on the goal of making a change and have posited that change in terms of a choice between this particular document and doing nothing --all other possibilities have been dismissed without significant consideration. To quote one of the co-authors of this draft from a different thread: > Herein lies the real problem: As with many process and > structure discussions in the IETF, folk often see only a > simplistic, binary choice between whatever they prefer, versus > something akin to chaos. > > The world is more nuanced than that, and the choices more rich. I agree, but this document is being treated as that sort of binary choice. Second, the community is easily exhausted by process debates and the debate about this particular document has now been going on for 13+ months. Even if the suggestion made at the plenary about opening 2026 were serious, does anyone actually believe the community will be able to take up and evaluate more significant process changes in the near future? Or that this document, if approved, will not be used to justify deferring discussion of other changes because we have to see how it works out? So this is not "baby steps". It is one step, a step that makes a change that isn't demonstrably connected to the problem it purports to solve and that leads into a dead end. john >
- draft-housley-two-maturity-levels John C Klensin
- Re: draft-housley-two-maturity-levels SM
- Re: draft-housley-two-maturity-levels Brian E Carpenter
- Re: draft-housley-two-maturity-levels Dave CROCKER
- Re: draft-housley-two-maturity-levels John C Klensin
- Re: draft-housley-two-maturity-levels Eric Rosen
- Re: draft-housley-two-maturity-levels Dave CROCKER
- Re: draft-housley-two-maturity-levels Julian Reschke
- Re: draft-housley-two-maturity-levels Dave CROCKER
- Re: draft-housley-two-maturity-levels Russ Housley
- Re: draft-housley-two-maturity-levels Brian E Carpenter
- Re: draft-housley-two-maturity-levels James M. Polk
- Re: draft-housley-two-maturity-levels Brian E Carpenter
- Re: draft-housley-two-maturity-levels James M. Polk
- Re: draft-housley-two-maturity-levels Phillip Hallam-Baker
- Re: draft-housley-two-maturity-levels Russ Housley
- Re: draft-housley-two-maturity-levels Barry Leiba
- Re: draft-housley-two-maturity-levels Brian E Carpenter
- Re: draft-housley-two-maturity-levels Eric Burger
- Re: draft-housley-two-maturity-levels Keith Moore
- Re: draft-housley-two-maturity-levels John Levine
- Re: draft-housley-two-maturity-levels Scott O. Bradner
- RE: draft-housley-two-maturity-levels Ross Callon
- Re: draft-housley-two-maturity-levels Bert (IETF) Wijnen
- Re: draft-housley-two-maturity-levels Eric Burger
- Re: draft-housley-two-maturity-levels Scott O. Bradner
- Re: draft-housley-two-maturity-levels Russ Housley
- Re: draft-housley-two-maturity-levels Scott O. Bradner
- Re: draft-housley-two-maturity-levels Dave CROCKER
- Re: draft-housley-two-maturity-levels Julian Reschke
- Re: draft-housley-two-maturity-levels John Leslie
- Re: draft-housley-two-maturity-levels Michael Richardson
- Re: draft-housley-two-maturity-levels Michael Richardson
- Re: draft-housley-two-maturity-levels Andrew Sullivan
- Re: draft-housley-two-maturity-levels RJ Atkinson
- Re: draft-housley-two-maturity-levels Barry Leiba
- Re: draft-housley-two-maturity-levels Martin Rex
- Re: draft-housley-two-maturity-levels Keith Moore
- Re: draft-housley-two-maturity-levels Scott O. Bradner
- Re: draft-housley-two-maturity-levels Ted Hardie
- RE: draft-housley-two-maturity-levels Tony Hain
- Re: draft-housley-two-maturity-levels Michael Richardson
- Re: draft-housley-two-maturity-levels Phillip Hallam-Baker
- Re: draft-housley-two-maturity-levels John Leslie
- Re: draft-housley-two-maturity-levels Phillip Hallam-Baker
- Re: draft-housley-two-maturity-levels Scott O. Bradner
- Re: draft-housley-two-maturity-levels Phillip Hallam-Baker
- Re: draft-housley-two-maturity-levels Scott O. Bradner
- RE: draft-housley-two-maturity-levels Tony Hain
- RE: draft-housley-two-maturity-levels Tony Hain
- Re: draft-housley-two-maturity-levels Phillip Hallam-Baker
- Re: draft-housley-two-maturity-levels Michael Richardson
- two independent implementations (Re: draft-housle… Lars Eggert
- Re: draft-housley-two-maturity-levels Lars Eggert
- Re: draft-housley-two-maturity-levels Lars Eggert
- Re: draft-housley-two-maturity-levels ned+ietf
- Re: two independent implementations (Re: draft-ho… James M. Polk
- RE: draft-housley-two-maturity-levels Tony Hain
- Re: draft-housley-two-maturity-levels Dave CROCKER
- Re: two independent implementations (Re: draft-ho… James M. Polk
- Re: draft-housley-two-maturity-levels David Kessens
- Re: two independent implementations John Leslie
- Re: draft-housley-two-maturity-levels SM
- RE: two independent implementations Tony Hain
- Re: draft-housley-two-maturity-levels Bob Braden
- Re: draft-housley-two-maturity-levels Yoav Nir
- RE: draft-housley-two-maturity-levels Tony Hain
- Re: draft-housley-two-maturity-levels Bob Braden
- Re: draft-housley-two-maturity-levels Peter Saint-Andre
- Re: draft-housley-two-maturity-levels Phillip Hallam-Baker
- Re: draft-housley-two-maturity-levels Eric Burger
- Re: draft-housley-two-maturity-levels Ralph Droms
- Re: draft-housley-two-maturity-levels Ralph Droms
- Re: draft-housley-two-maturity-levels ned+ietf
- Re: draft-housley-two-maturity-levels Phillip Hallam-Baker
- Re: draft-housley-two-maturity-levels Joel Jaeggli
- Re: draft-housley-two-maturity-levels Phillip Hallam-Baker
- Re: draft-housley-two-maturity-levels Russ Housley
- Re: draft-housley-two-maturity-levels Peter Saint-Andre
- Re: draft-housley-two-maturity-levels Joel M. Halpern
- Re: draft-housley-two-maturity-levels Peter Saint-Andre
- Re: draft-housley-two-maturity-levels Phillip Hallam-Baker
- Re: draft-housley-two-maturity-levels RJ Atkinson
- Re: draft-housley-two-maturity-levels Tony Hansen
- Re: draft-housley-two-maturity-levels Mykyta Yevstifeyev
- Re: draft-housley-two-maturity-levels John Leslie
- Re: draft-housley-two-maturity-levels ned+ietf
- Re: draft-housley-two-maturity-levels Scott O. Bradner
- Re: draft-housley-two-maturity-levels John C Klensin
- Re: draft-housley-two-maturity-levels Gonzalo Camarillo
- Re: draft-housley-two-maturity-levels John C Klensin
- Re: draft-housley-two-maturity-levels Dave CROCKER
- Re: draft-housley-two-maturity-levels Doug Barton
- Re: draft-housley-two-maturity-levels SM
- Re: draft-housley-two-maturity-levels Martin Rex
- Re: draft-housley-two-maturity-levels Mark Atwood
- Re: draft-housley-two-maturity-levels Brian E Carpenter
- Re: draft-housley-two-maturity-levels Dave CROCKER
- Re: draft-housley-two-maturity-levels Brian E Carpenter
- Re: draft-housley-two-maturity-levels Russ Housley
- New version of NroffEdit released for IETF80 Stefan Santesson
- Re: draft-housley-two-maturity-levels Joel M. Halpern
- Re: New version of NroffEdit released for IETF80 Stefan Santesson
- Re: draft-housley-two-maturity-levels Mykyta Yevstifeyev
- Re: draft-housley-two-maturity-levels Joel M. Halpern
- Re: draft-housley-two-maturity-levels Mykyta Yevstifeyev
- Re: draft-housley-two-maturity-levels Dave CROCKER
- Re: draft-housley-two-maturity-levels Bob Hinden
- Re: draft-housley-two-maturity-levels Eric Burger
- draft-housley-two-maturity-levels Jari Arkko
- Re: draft-housley-two-maturity-levels Brian E Carpenter
- Re: draft-housley-two-maturity-levels Scott O. Bradner
- Re: draft-housley-two-maturity-levels Robert Sparks
- Re: draft-housley-two-maturity-levels Eric Burger
- Re: draft-housley-two-maturity-levels Peter Saint-Andre
- Re: draft-housley-two-maturity-levels Keith Moore
- Re: draft-housley-two-maturity-levels Peter Saint-Andre
- Re: draft-housley-two-maturity-levels Brian E Carpenter
- Re: draft-housley-two-maturity-levels Chris Newman
- Re: draft-housley-two-maturity-levels Pete Resnick
- Re: draft-housley-two-maturity-levels Joel M. Halpern
- Re: draft-housley-two-maturity-levels John Leslie
- Re: draft-housley-two-maturity-levels Brian E Carpenter
- Re: draft-housley-two-maturity-levels RJ Atkinson
- Re: draft-housley-two-maturity-levels Eric Burger
- Re: draft-housley-two-maturity-levels Scott O Bradner
- Re: draft-housley-two-maturity-levels Peter Saint-Andre
- Re: draft-housley-two-maturity-levels John C Klensin
- Re: draft-housley-two-maturity-levels Joel M. Halpern
- Re: draft-housley-two-maturity-levels John C Klensin
- Conclusion of the last call on draft-housley-two-… Jari Arkko
- Re: Conclusion of the last call on draft-housley-… SM
- Re: Conclusion of the last call on draft-housley-… John C Klensin
- Re: Conclusion of the last call on draft-housley-… Keith Moore
- Re: Conclusion of the last call on draft-housley-… Frank Ellermann
- RE: Conclusion of the last call on draft-housley-… Ross Callon
- Re: Conclusion of the last call on draft-housley-… Keith Moore
- RE: Conclusion of the last call on draft-housley-… ned+ietf
- RE: Conclusion of the last call on draft-housley-… James M. Polk
- Other proposals (Was: :Re: Conclusion of the last… Jari Arkko
- Re: Conclusion of the last call on draft-housley-… Keith Moore
- Re: Conclusion of the last call on draft-housley-… Jari Arkko
- Re: Conclusion of the last call on draft-housley-… Keith Moore
- Re: Conclusion of the last call on draft-housley-… Barry Leiba
- RE: Conclusion of the last call on draft-housley-… John C Klensin
- Re: Conclusion of the last call on draft-housley-… ned+ietf
- Re: Conclusion of the last call on draft-housley-… ned+ietf
- Re: Conclusion of the last call on draft-housley-… Brian E Carpenter
- Re: Conclusion of the last call on draft-housley-… Keith Moore
- Re: Conclusion of the last call on draft-housley-… ned+ietf
- Re: Other proposals (Was: :Re: Conclusion of the … SM
- Re: Conclusion of the last call on draft-housley-… Russ Housley
- Re: Conclusion of the last call on draft-housley-… Hector Santos
- RE: Conclusion of the last call on draft-housley-… Ross Callon
- Re: Conclusion of the last call on draft-housley-… Andrew Sullivan
- Re: Conclusion of the last call on draft-housley-… Keith Moore
- Re: Conclusion of the last call on draft-housley-… ned+ietf
- Re: Conclusion of the last call on draft-housley-… Ted Hardie
- Re: Conclusion of the last call on draft-housley-… John C Klensin
- Who raised the bar? [Conclusion of the last call … Brian E Carpenter
- Re: Conclusion of the last call on draft-housley-… Keith Moore
- Re: Who raised the bar? [Conclusion of the last c… Julian Reschke
- Re: Who raised the bar? [Conclusion of the last c… Keith Moore
- Re: Who raised the bar? [Conclusion of the last c… Dave Cridland
- Re: Conclusion of the last call on draft-housley-… Keith Moore
- Re: Who raised the bar? Brian E Carpenter
- Re: Who raised the bar? [Conclusion of the last c… Cullen Jennings
- Re: Conclusion of the last call on draft-housley-… Ted Hardie
- Re: Who raised the bar? [Conclusion of the last c… Ted Hardie
- Re: Conclusion of the last call on draft-housley-… Fred Baker
- Re: Conclusion of the last call on draft-housley-… Keith Moore
- Re: Conclusion of the last call on draft-housley-… Keith Moore
- Re: Conclusion of the last call on draft-housley-… John Leslie
- Re: Conclusion of the last call on draft-housley-… t.petch
- Re: Conclusion of the last call on draft-housley-… ned+ietf
- Re: Conclusion of the last call on draft-housley-… Keith Moore
- Re: Who raised the bar? [Conclusion of the last c… Hector Santos
- Re: Who raised the bar? [Conclusion of the last c… JP Vasseur
- Re: Who raised the bar? [Conclusion of the last c… JP Vasseur
- Re: Who raised the bar? [Conclusion of the last c… SM
- Re: Conclusion of the last call on draft-housley-… Thomas Narten
- Re: Conclusion of the last call on draft-housley-… Mykyta Yevstifeyev
- Re: Conclusion of the last call on draft-housley-… Barry Leiba
- Re: Conclusion of the last call on draft-housley-… Russ Housley
- Re: Conclusion of the last call on draft-housley-… Keith Moore
- Re: Conclusion of the last call on draft-housley-… Mykyta Yevstifeyev
- Re: Conclusion of the last call on draft-housley-… Mykyta Yevstifeyev
- Re: Conclusion of the last call on draft-housley-… Sam Hartman
- Re: Conclusion of the last call on draft-housley-… Hector
- Re: Conclusion of the last call on draft-housley-… hector
- Re: Conclusion of the last call on draft-housley-… Brian E Carpenter
- Re: Conclusion of the last call on draft-housley-… Scott O. Bradner
- Re: Conclusion of the last call on draft-housley-… Keith Moore
- Re: Conclusion of the last call on draft-housley-… Hector
- Re: Conclusion of the last call on draft-housley-… John C Klensin
- Re: Conclusion of the last call on draft-housley-… Eric Burger
- RFC3844 and IETF Core Values Hector
- Re: Conclusion of the last call on draft-housley-… John C Klensin
- Re: Conclusion of the last call on draft-housley-… Brian E Carpenter
- Re: Conclusion of the last call on draft-housley-… John C Klensin
- Re: Conclusion of the last call on draft-housley-… hector
- Re: Conclusion of the last call on draft-housley-… Mykyta Yevstifeyev
- Re: Conclusion of the last call on draft-housley-… Jari Arkko
- Re: Conclusion of the last call on draft-housley-… Russ Housley
- Re: Conclusion of the last call on draft-housley-… John C Klensin
- Re: Conclusion of the last call on draft-housley-… Hector
- Re: Conclusion of the last call on draft-housley-… John C Klensin
- Re: Conclusion of the last call on draft-housley-… Hector
- Re: Conclusion of the last call on draft-housley-… Sam Hartman
- Re: Conclusion of the last call on draft-housley-… Keith Moore
- Re: Conclusion of the last call on draft-housley-… Martin Rex
- Re: Conclusion of the last call on draft-housley-… Douglas Otis
- Re: Conclusion of the last call on draft-housley-… Hadriel Kaplan
- Re: Conclusion of the last call on draft-housley-… Brian E Carpenter