RIPE NCC DNSSEC trust anchors
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Dear colleagues, Most of the zones that the RIPE NCC signs with DNSSEC have trust anchors in their parent zones, with the exception of these three zones: 151.76.62.in-addr.arpa ripe.int ripen.cc We have been publishing trust anchors for these three zones on our website, as well as in the ISC DLV trust anchor repository (TAR): https://dlv.isc.org On Tuesday, 11 November 2014, we rolled our DNSSEC Key Signing Keys and added the new trust anchors for these three zones to the ISC DLV TAR. Because we believe manual configuration of trust anchors is very rare these days, we are taking this opportunity to stop publishing trust anchors for these three zones on our website. The trust anchors remain available via the ISC DLV TAR. Of course, as soon as we are able to publish DS records for these zones in their parents, we will do so and withdraw them from the ISC DLV TAR, as we have done for all our other zones. If you have any questions or concerns, please send email to dns@ripe.net. Regards, Anand Buddhdev Senior Engineer RIPE NCC -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.22 (Darwin) Comment: GPGTools - http://gpgtools.org iEYEARECAAYFAlRkxj4ACgkQi+U8Q0SwlCvWtQCgiCxJt53Ala7tTYXzzXW6787w GPcAn0a/u+aRB8BlpTT5cp5QomFo/LSB =ZAsP -----END PGP SIGNATURE-----
Well, this may be seen as a stupid question from a DNS DAU, but can you explain what ripe.int (an international treaty organisation?) and ripen.cc are used for? Thanks, Wilfried Anand Buddhdev wrote:
Dear colleagues,
Most of the zones that the RIPE NCC signs with DNSSEC have trust anchors in their parent zones, with the exception of these three zones:
151.76.62.in-addr.arpa ripe.int ripen.cc
We have been publishing trust anchors for these three zones on our website, as well as in the ISC DLV trust anchor repository (TAR): https://dlv.isc.org
On Tuesday, 11 November 2014, we rolled our DNSSEC Key Signing Keys and added the new trust anchors for these three zones to the ISC DLV TAR. Because we believe manual configuration of trust anchors is very rare these days, we are taking this opportunity to stop publishing trust anchors for these three zones on our website. The trust anchors remain available via the ISC DLV TAR. Of course, as soon as we are able to publish DS records for these zones in their parents, we will do so and withdraw them from the ISC DLV TAR, as we have done for all our other zones.
If you have any questions or concerns, please send email to dns@ripe.net.
Regards,
Anand Buddhdev Senior Engineer RIPE NCC
Hi Anand, On 13.11.2014 16:18, Wilfried Woeber wrote:
Well, this may be seen as a stupid question from a DNS DAU,
but can you explain what ripe.int (an international treaty organisation?) and ripen.cc are used for?
I'd like to second Wilfried's question at least for the .int part. Thanks, -C.
once, long ago, there was a serious and aggressive move to remove .arpa we moved everything into .int and included the rirs as organizations responsible for the numbers. then it was pointed out that replacing all the resolver libraries might be problematic and DNAME had not been invented… then the IAB decided to repurpose .arpa (changed the name) and ICANN took over .int … but they didn’t do a real good job of cleaning up. so we still have .arpa and .int is strictly treaty orgs (or should be). i guess one could argue RIPE is an offshoot of a treaty org (the EU) /bill PO Box 12317 Marina del Rey, CA 90295 310.322.8102 On 13November2014Thursday, at 7:18, Wilfried Woeber <Woeber@CC.UniVie.ac.at> wrote:
.int
the EU is not a treaty based org? I thought that the Maastricht Treaty in 1993 created the EU. certainly RIPE existed before then (didm;t it emerge from RARE?)… which if memory serves, was an agreement between several organizations to work together. While that might not have engendered a formal, state-recognized treaty, it was an agreement… There. I have argued. Lets move on /bill PO Box 12317 Marina del Rey, CA 90295 310.322.8102 On 13November2014Thursday, at 12:12, Rob Blokzijl <k13@nikhef.nl> wrote:
i guess one could argue RIPE is an offshoot of a treaty org (the EU)
/bill
No, it is not.
Rob
On 13 Nov 2014, at 14:54, Anand Buddhdev <anandb@ripe.net> wrote:
Signed PGP part Dear colleagues,
Most of the zones that the RIPE NCC signs with DNSSEC have trust anchors in their parent zones, with the exception of these three zones:
151.76.62.in-addr.arpa ripe.int ripen.cc
We have been publishing trust anchors for these three zones on our website, as well as in the ISC DLV trust anchor repository (TAR): https://dlv.isc.org
On Tuesday, 11 November 2014, we rolled our DNSSEC Key Signing Keys and added the new trust anchors for these three zones to the ISC DLV TAR. Because we believe manual configuration of trust anchors is very rare these days, we are taking this opportunity to stop publishing trust anchors for these three zones on our website. The trust anchors remain available via the ISC DLV TAR. Of course, as soon as we are able to publish DS records for these zones in their parents, we will do so and withdraw them from the ISC DLV TAR, as we have done for all our other zones.
Anand, I am confused. 62/8 is under RIPE NCC control. There are DS records for 62.in-addr.arpa which presumably got put there by the NCC. So why does anything underneath that domain have to be in DLV? I would very much like to see a timetable and plan for the removal of RIPE NCC managed zones from DLV. Is there a worthwhile reason for any NCC-managed reverse zones and keying material to remain there? I can't think of one. As for the other two domain names, do you have any statistics on how often they are used/looked up and why? And of those lookups, how many result in DLV-flavour validation? How often do URLs containing these two domain names appear in web content or whatever? ie Does validation of these two domains actually matter to anything? Neither of these TLDs seem appropriate for the NCC. IIRC ripen.cc was a botched experiment some years ago that was quietly buried. [Apparently URLs with a ripen.cc hostname were shorter than those which used ripe.net. Go figure.] It would seem the only reason for holding on to these two domain names would be for defensive registrations and/or to put an HTTP redirect to ripe.net. Either way, there doesn't seem much point in signing these zones and far less populating DLV with DS records for them. Maybe I've missed something. I appreciate your understandable need for caution here Anand and to avoid surprises. However, there hasn't been a need to use DLV for NCC-managed zones for a few years now. So I think it's about time to pull the plug on the NCC's DLV involvement forever. After giving everyone sufficient notice of course. I hope your email is the start of that process Of course what happens to DLV once the NCC's stuff is removed remains a decision for ISC. My views on that are well known.
Anand, all, On Thu, Nov 13, 2014 at 03:54:54PM +0100, Anand Buddhdev wrote:
151.76.62.in-addr.arpa ripe.int ripen.cc
On Tuesday, 11 November 2014, we rolled our DNSSEC Key Signing Keys and added the new trust anchors for these three zones to the ISC DLV TAR. Because we believe manual configuration of trust anchors is very rare these days, we are taking this opportunity to stop publishing trust anchors for these three zones on our website. The trust anchors remain available via the ISC DLV TAR. Of course, as soon as we are
Thanks for this note. I'd rather not see the RIPE NCC further endorse the DLV technology and service by continuing to submit key material there. DLV was meant as a temporary deployment aid and might have been a good idea at its time. Nowadays, I consider it detrimental to deployment because it complicates matters for everybody deciding to actually validate (getting those figures up is the real challenge). Manually configured trust anchors aren't the ultimate wisdom, either, so with regard to the three zones above I wonder a) what is the actual benefit of extra steps for publishing the KSK out of band (continued signing obviously stremlines processes)? b) what steps could be taken to get the TA published the "natural" way? This is probably most interesting for the INT TLD, given all the current transition debate. Regards, Peter (no hat)
On 13 Nov 2014, at 17:38, Peter Koch <pk@DENIC.DE> wrote:
I'd rather not see the RIPE NCC further endorse the DLV technology and service by continuing to submit key material there.
+100 What's this? Peter and myself in agreement? Something is wrong. :-)
Peter Koch <pk@DENIC.DE> wrote:
I'd rather not see the RIPE NCC further endorse the DLV technology and service by continuing to submit key material there. DLV was meant as a temporary deployment aid and might have been a good idea at its time.
We would like to stop using the DLV but some of our reverse zones cannot be validated without it because JANET has only signed ac.uk. Tony. -- f.anthony.n.finch <dot@dotat.at> http://dotat.at/ Rockall, Malin: Cyclonic 7 to severe gale 9, becoming southeast 6 to gale 8. Rough or very rough. Rain at first, then thundery showers. Moderate or poor, becoming mainly good.
On 14 Nov 2014, at 10:19, Tony Finch <dot@dotat.at> wrote:
Peter Koch <pk@DENIC.DE> wrote:
I'd rather not see the RIPE NCC further endorse the DLV technology and service by continuing to submit key material there. DLV was meant as a temporary deployment aid and might have been a good idea at its time.
We would like to stop using the DLV but some of our reverse zones cannot be validated without it because JANET has only signed ac.uk.
Although you know I very much want to see DLV killed, that is not the matter at hand. What we are discussing is the NCC's use of DLV for stuff that either has no reason to be there or for domain names that have little or no relevance/use to the NCC and the community. I would like to keep the focus on that. In that context, Peter's comments go to the heart of the matter. There's a meta-issue too. Some years ago, long before the root was signed, the NCC shoved stuff into DLV as a short-term kludge. It's continuing to do that even though there seems to be no good reason for doing that any more. So have the NCC reviewed its processes for DLV population or assessed whether this activity is necessary or worthwhile? If you wish to continue discussing DLV's worth and relevance to the local problem you mentioned, go ahead. But please do so on another thread.
Paul Mockapetris (pvm) == Original maintainer of .INT, Bill Manning (wcm) == second maintainer of .INT, ICANN == Current Maintainer of .INT. DLV == DNS Lookaside Validation, a kludge to deal with islands of trust, published by Sam Weiler and productized by Internet Systems (nee Software) Consortia I think you have the NCC & RIPE & JANET acronyms … Now can you tell me what a PSL is? /bill PO Box 12317 Marina del Rey, CA 90295 310.322.8102 On 14November2014Friday, at 2:59, Jim Reid <jim@rfc1035.com> wrote:
On 14 Nov 2014, at 10:19, Tony Finch <dot@dotat.at> wrote:
Peter Koch <pk@DENIC.DE> wrote:
I'd rather not see the RIPE NCC further endorse the DLV technology and service by continuing to submit key material there. DLV was meant as a temporary deployment aid and might have been a good idea at its time.
We would like to stop using the DLV but some of our reverse zones cannot be validated without it because JANET has only signed ac.uk.
Although you know I very much want to see DLV killed, that is not the matter at hand. What we are discussing is the NCC's use of DLV for stuff that either has no reason to be there or for domain names that have little or no relevance/use to the NCC and the community. I would like to keep the focus on that. In that context, Peter's comments go to the heart of the matter.
There's a meta-issue too. Some years ago, long before the root was signed, the NCC shoved stuff into DLV as a short-term kludge. It's continuing to do that even though there seems to be no good reason for doing that any more. So have the NCC reviewed its processes for DLV population or assessed whether this activity is necessary or worthwhile?
If you wish to continue discussing DLV's worth and relevance to the local problem you mentioned, go ahead. But please do so on another thread.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 11/13/14 6:54 AM, Anand Buddhdev wrote: | Dear colleagues, | | Most of the zones that the RIPE NCC signs with DNSSEC have trust | anchors in their parent zones, with the exception of these three | zones: | | 151.76.62.in-addr.arpa ripe.int ripen.cc As others have already pointed out, I would love to see explanations of why the first and third zones cannot have proper trust anchors. The NCC should simply release ripe.int, as the historical reasons for it no longer apply. (FWIW, same goes for apnic.int. None of the other RIRs have similar domains.) Doug -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQEcBAEBCAAGBQJUZPMDAAoJEFzGhvEaGryE3PQIAL1pP7xmGW69C6AC9VzJbupZ 068Dau7lR9RiqXpPPe+sZdpMwXs3Q1Bf+aa8rZ6CNcQw/fTuGYtWd9f9x04DhVgo dIvNctoxSf0PHbGtCqJ/9pb8a+r29wkY67JwKgNy30x5SGg/Z3yMoit49ftD3DqI bMfhWL1037J6YuXz7UnaRWe52OhdbPDVMVO1J9jEV8dWqFcO1DDiP2ATWG3YQQ/l mDSxo7WG9Oja9mgk1zMjldc0NJo1XqmrJRnsy/k6hEkG/F+QJdIWMNH8VDqZC3wB 6l54wvljRgVEbNeZc5ToVGDoWY+nsQ3wJvA+GDkLNjpdzwa1TAXOeoJMP1UT/VM= =vmmW -----END PGP SIGNATURE-----
On Nov 13, 2014, at 7:44 AM, Randy Bush <randy@psg.com> wrote:
I'd rather not see the RIPE NCC further endorse the DLV technology and service by continuing to submit key material there.
thank you
DLV was meant as a temporary deployment aid and might have been a good idea at its time.
or not
randy
+1 On Nov 13, 2014, at 8:05 AM, Doug Barton <dougb@dougbarton.us> wrote:
The NCC should simply release ripe.int, as the historical reasons for it no longer apply. (FWIW, same goes for apnic.int. None of the other RIRs have similar domains.)
+1 Regards, -drc
On Thu, Nov 13, 2014 at 10:28:32AM -1000, David Conrad wrote:
On Nov 13, 2014, at 8:05 AM, Doug Barton <dougb@dougbarton.us> wrote:
The NCC should simply release ripe.int, as the historical reasons for it no longer apply. (FWIW, same goes for apnic.int. None of the other RIRs have similar domains.)
+1
this might be the exact wrong point in time. The NCC likely does not fulfill the eligibility criterie laid out in <http://www.iana.org/domains/int/policy/>, but obviously the registrations in INT benefit from a genaral protection of confidence. Also, the 'policy' document linked above does not provide for a revocation mechanism. So, there is a registrant in INT interested in having key material published. What does it take to get INT sigend? What is the governing body? The 'policy' document bases itself on RFC 1591 but also says "The IANA no longer _grants_ .int domain names [...]". While this particular issue is out of scope, the text may be read as if "the IANA" was acting with its own authority rather than being a registry operator bound by some policy set by the competent body. So, again: who is to be convinced to make INT signed? -Peter
On 13 Nov 2014, at 20:50, Peter Koch <pk@DENIC.DE> wrote:
So, again: who is to be convinced to make INT signed?
Runs away screaming... The politics around .int and its oversight are... well... interesting. It might be inadvisable to dive into that while the IANA arrangements are in flux.
Peter, On Nov 13, 2014, at 10:50 AM, Peter Koch <pk@DENIC.DE> wrote:
On Thu, Nov 13, 2014 at 10:28:32AM -1000, David Conrad wrote:
On Nov 13, 2014, at 8:05 AM, Doug Barton <dougb@dougbarton.us> wrote:
The NCC should simply release ripe.int, as the historical reasons for it no longer apply. (FWIW, same goes for apnic.int. None of the other RIRs have similar domains.)
+1
this might be the exact wrong point in time.
Or, given the IANA Functions transition, the exact right point in time if people want to avoid a pointless political food fight.
The NCC likely does not fulfill the eligibility criterie laid out in <http://www.iana.org/domains/int/policy/>, but obviously the registrations in INT benefit from a genaral protection of confidence.
What's a "general protection of confidence"?
Also, the 'policy' document linked above does not provide for a revocation mechanism.
If an entity does not meet the documented policy criteria, then it should not be in the zone. However, IANA does not unilaterally remove zones. Traditionally, the entity simply says "please remove my entry". Are you recommending RIPE knowingly and intentionally violate a documented policy?
So, there is a registrant in INT interested in having key material published. What does it take to get INT signed?
Currently, .INT is part of the IANA Functions contract. My understanding (which is NOT authoritative) is that efforts are underway to get .INT signed, but that it requires approval by NTIA.
What is the governing body?
As mentioned, management of .INT is part of the IANA Functions contract, specifically section C.2.9.4 of http://www.ntia.doc.gov/files/ntia/publications/sf_26_pg_1-2-final_award_and....
The 'policy' document bases itself on RFC 1591 but also says "The IANA no longer _grants_ .int domain names [...]".
Um, yeah. 1591 also says "Second level names in INT are registered by the PVM at ISI.EDU." Good luck with that. I personally find the cherry picking of RFC 1591 quite fascinating. The Internet has changed a bit since 1994 and it has never been clear to me that relying on that document in contravention to existing evolved policies makes a lot of sense.
While this particular issue is out of scope, the text may be read as if "the IANA" was acting with its own authority rather than being a registry operator bound by some policy set by the competent body.
It may be read that way, but doing so would simply be wrong. My understanding is that the policy used for .INT registrations was created by Mike St. Johns when he was at DARPA. The fact that there are historical anomalies (e.g., tpc.int, ripe.int, apnic.int, ymca.int, etc), are, in my personal view, things that should be cleaned up, not things that should be used to stir up the political muck.
So, again: who is to be convinced to make INT signed?
Until the IANA Functions transition, NTIA. After the transition: that's an interesting question. Can we just ask for RIPE.INT to be dropped from the .INT zone? Does RIPE actually use it for anything other than a redirect to RIPE.NET? Regards, -drc (ICANN CTO, but speaking only for myself. Really.)
On 13/11/2014 21:21, David Conrad wrote:
Can we just ask for RIPE.INT to be dropped from the .INT zone?
there isn't enough bikeshed in the universe to handle a suggestion like this. Nick
On 11/13/14 2:07 PM, Nick Hilliard wrote:
On 13/11/2014 21:21, David Conrad wrote:
Can we just ask for RIPE.INT to be dropped from the .INT zone?
there isn't enough bikeshed in the universe to handle a suggestion like this.
Nick, But that's just the point, it doesn't have to be a bikeshed. RIPE and APNIC can simply ask ICANN to un-delegate the names, and then we're done. And regarding Peter's point, this is the *perfect* time for them to do so. It helps reinforce the point that the bottom-up stakeholder model works, because people of good will are willing and able to do the right thing. There is no reason for those names to exist now, in spite of the historical reasons that they were created in the past. The only way this turns into a bikeshed is if RIPE and APNIC don't agree to do the right thing and drop the names. Doug PS, I'm not sure you're using the term 'bikeshed' in the right context there. Have a look at http://en.wikipedia.org/wiki/Parkinson%27s_law_of_triviality
Hi David, On Thu, Nov 13, 2014 at 11:21:00AM -1000, David Conrad wrote:
Or, given the IANA Functions transition, the exact right point in time if people want to avoid a pointless political food fight.
well, we hopefully agree that 'unasking' the questions isn't the right thing to do. Whether ripe.int is OK to continue to exist is a detail that only triggered the subsequent questions, that being the 'registration policy' for the INT TLD and the governing body for other decisions (like the deployment of DNSSEC, the DPS, choice of name server operators). We don't need responses instatntly (although you, Kim, and Barbara were helpful in providing those), but the questions need to be listed.
What's a "general protection of confidence"?
That's my, apparently failed, attempt to translate a legalese clause from my mother tongue into English legalese with the help of this Internet. It should have described a general priciple that anyone is entitled to maintain their status, provided they got there bona fide and before rules existed.
Also, the 'policy' document linked above does not provide for a revocation mechanism.
If an entity does not meet the documented policy criteria, then it should not be in the zone. However, IANA does not unilaterally remove zones. Traditionally, the entity simply says "please remove my entry". Are you recommending RIPE knowingly and intentionally violate a documented policy?
Even if the NCC (or any other entity) did (or "do") not fulfill today's eligibility criteria, the current policy does not include a revocation clause (see above). Even if it did, the policy at the time of registration would prevail and unless that had had a clause submitting the registrant to future changes, there'd be no handle. So, my response to the question is "no", because there is no "documented policy" to "knowingly and intentionally violate". Whether the registrant gives up the domain name is a different issue.
As mentioned, management of .INT is part of the IANA Functions contract, specifically section C.2.9.4 of http://www.ntia.doc.gov/files/ntia/publications/sf_26_pg_1-2-final_award_and....
Thanks.
Um, yeah. 1591 also says "Second level names in INT are registered by the PVM at ISI.EDU." Good luck with that. I personally find the cherry picking of RFC 1591 quite fascinating. The Internet has changed a bit since 1994 and it has never been clear to me that relying on that document in contravention to existing evolved policies makes a lot of sense.
For obvious reasons I will refrain from a discussion re: the applicability of RFC 1591 in the general case. For the INT TLD I do not see any cherry picking in action. I had only quoted from the IANA's website.
Until the IANA Functions transition, NTIA. After the transition: that's an interesting question.
Thanks, that was one important point to raise. Regards, Peter
Hi Peter,
So, there is a registrant in INT interested in having key material published. What does it take to get INT sigend?
It is our desire to sign .INT and we are working on making it happen. It is the only zone we manage that isn’t signed and we are keen to reach 100%. There is probably not a lot more I can say beyond that at this time. kim
ICANN inherited a number of INT registrations when it assumed management of the zone. Since 2005, at least, and probably since 1998, only treaty-based organizations who meet the other criteria have been given registrations, to the best of my knowledge. I believe that ICANN uses an outside expert who has experience with UN treaty organizations to evaluate the requests for .INT registrations. -Barb Sent from my mobile.
On Nov 13, 2014, at 10:51 AM, Peter Koch <pk@DENIC.DE> wrote:
On Thu, Nov 13, 2014 at 10:28:32AM -1000, David Conrad wrote:
On Nov 13, 2014, at 8:05 AM, Doug Barton <dougb@dougbarton.us> wrote: The NCC should simply release ripe.int, as the historical reasons for it no longer apply. (FWIW, same goes for apnic.int. None of the other RIRs have similar domains.)
+1
this might be the exact wrong point in time. The NCC likely does not fulfill the eligibility criterie laid out in <http://www.iana.org/domains/int/policy/>, but obviously the registrations in INT benefit from a genaral protection of confidence. Also, the 'policy' document linked above does not provide for a revocation mechanism.
So, there is a registrant in INT interested in having key material published. What does it take to get INT sigend? What is the governing body? The 'policy' document bases itself on RFC 1591 but also says "The IANA no longer _grants_ .int domain names [...]". While this particular issue is out of scope, the text may be read as if "the IANA" was acting with its own authority rather than being a registry operator bound by some policy set by the competent body. So, again: who is to be convinced to make INT signed?
-Peter
On 11/13/14 2:22 PM, Barbara Roseman wrote:
ICANN inherited a number of INT registrations when it assumed management of the zone. Since 2005, at least, and probably since 1998, only treaty-based organizations who meet the other criteria have been given registrations, to the best of my knowledge. I believe that ICANN uses an outside expert who has experience with UN treaty organizations to evaluate the requests for .INT registrations.
FWIW, that policy definitely predates 2003, although I can't speak authoritatively as to how long it was in place before I joined the staff. Doug
On Nov 13, 2014, at 2:32 PM, Doug Barton <dougb@dougbarton.us> wrote:
On 11/13/14 2:22 PM, Barbara Roseman wrote:
ICANN inherited a number of INT registrations when it assumed management of the zone. Since 2005, at least, and probably since 1998, only treaty-based organizations who meet the other criteria have been given registrations, to the best of my knowledge. I believe that ICANN uses an outside expert who has experience with UN treaty organizations to evaluate the requests for .INT registrations.
FWIW, that policy definitely predates 2003, although I can't speak authoritatively as to how long it was in place before I joined the staff.
.INT was historically slated for dual purposes, intergovernmental treaty organisations and “international databases”. I believe the point of departure was the formalisation of .ARPA for the latter purpose, as documented in RFC 3712 in 2001. IAB produced guidance that infrastructure domains no longer be housed in .INT, see https://web.archive.org/web/20021005001140/http://www.iab.org/iab/DOCUMENTS/... Since then new .INT registrations have been limited to intergovernmental treaty organisations, but existing registrations like this (and others, the tpc.int gateway from RFC 1529 comes to mind as another example, as does sol.int for interplanetary Internet) were grandfathered. kim
i could , since i managed .INT after pvm and before it was given to ICANN /bill PO Box 12317 Marina del Rey, CA 90295 310.322.8102 On 13November2014Thursday, at 14:32, Doug Barton <dougb@dougbarton.us> wrote:
On 11/13/14 2:22 PM, Barbara Roseman wrote:
ICANN inherited a number of INT registrations when it assumed management of the zone. Since 2005, at least, and probably since 1998, only treaty-based organizations who meet the other criteria have been given registrations, to the best of my knowledge. I believe that ICANN uses an outside expert who has experience with UN treaty organizations to evaluate the requests for .INT registrations.
FWIW, that policy definitely predates 2003, although I can't speak authoritatively as to how long it was in place before I joined the staff.
Doug
participants (14)
-
Anand Buddhdev -
Barbara Roseman -
Carsten Schiefner -
David Conrad -
Doug Barton -
Jim Reid -
Kim Davies -
manning bill -
Nick Hilliard -
Peter Koch -
Randy Bush -
Rob Blokzijl -
Tony Finch -
Wilfried Woeber