You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@trafficcontrol.apache.org by "Rivas, Jesse" <Je...@comcast.com> on 2018/11/15 17:39:47 UTC
Removal of JDNSSEC dependency from Traffic Router
Hi Traffic Controllers,
Currently, the .pkg script is failing to build the Traffic Router rpm because the build_rpm.sh script for TR attempts to download jdnssec-tools.jar from verisign (http://www.verisignlabs.com/dnssec-tools/packages/old-releases), which is no longer available. Traffic Router used to leverage code from the jdnssec-tools.jar for zone signing, but it has since been replaced with our own implementation. All of the classes and subsequent tests that use the jdnssec package were previously moved from “core” to a separate module in Traffic Router (called “jdnssec”) that is not included in the maven build by default, and was kept for legacy and testing purposes. I would like to propose removing the JDNSSEC dependency from Traffic Router altogether; this would include removing the jdnssec module in Traffic Router and subsequent pom files, and removing the “installDnsSec” function from the build_rpm.sh script in Traffic Router that attempts to download jdnssec-tools.jar and fails if it is unsuccessful.
Please let me know if there is any opposition to removing the external JDNSSEC dependency from Traffic Router, as it is no longer used for zone signing and is no longer available for download from verisign.
-Jesse
Re: [EXTERNAL] Re: Removal of JDNSSEC dependency from Traffic Router
Posted by "Fieck, Brennan" <Br...@comcast.com>.
Well, I opened a PR to remove it from TR. I haven't actually tested DNSSEC yet, but the package builds and TR will install and run based on the changes.
https://github.com/apache/trafficcontrol/pull/3038
I'll add that note in the docs that Jonathan Gray suggested in a bit.
I'm not really a Java guy, so this is probably missing some things.
________________________________________
From: Rivas, Jesse <Je...@comcast.com>
Sent: Friday, November 16, 2018 11:38 AM
To: dev@trafficcontrol.apache.org
Subject: Re: [EXTERNAL] Re: Removal of JDNSSEC dependency from Traffic Router
What Dave said is accurate; the tests compare our own zone signing implementation to that of jdnssec.
On 11/16/18, 11:34 AM, "Fieck, Brennan" <Br...@comcast.com> wrote:
If what Dave said is true, then I'm changing my vote to "+1 for removing entirely - including from tests"
________________________________________
From: Schmidt, Andrew (Contractor) <An...@comcast.com>
Sent: Friday, November 16, 2018 8:49 AM
To: dev@trafficcontrol.apache.org
Subject: Re: [EXTERNAL] Re: Removal of JDNSSEC dependency from Traffic Router
+1 getting rid of jdnssec from the rpm. If someone out there still really needs it we could wrap it in its own rpm or just provide the documentation as suggested by Jesse.
On 11/15/18, 9:22 PM, "Dave Neuman" <ne...@apache.org> wrote:
If I recall correctly the “testing” is really just to compare our own
developed version vs the jdnssec version. As far as I am concerned we have
proven it is more than adequate by running in production so those tests are
no longer necessary. +1 on removing the now unnecessary dependency
completely.
On Thu, Nov 15, 2018 at 15:39 Rivas, Jesse <Je...@comcast.com> wrote:
> If consensus is to keep the jdnssec module for testing purposes, the
> download step could be removed from the build_rpm.sh script and
> documentation added on where to download the .jar and how to build with
> maven. That way, the .jar isn't downloaded by default, won't cause the
> build to fail, and it would be easier to maintain documentation on where to
> get the .jar than maintain the build script if the location changes.
> Alternatively, the URL for download could just be updated and continue to
> download and build as it has in the past.
>
> If you feel strongly one way another on updating the download URL in the
> build script, keeping the module in Traffic Router and removing the
> download step from build_rpm.sh, or removing the module completely, please
> share your viewpoint.
>
> -Jesse
>
> On 11/15/18, 12:39 PM, "Robert Butts" <ro...@apache.org> wrote:
>
> Just FYI, it looks like it's on Github, by the original author:
> https://github.com/dblacka/jdnssec-tools/releases/tag/0.12 . So it
> looks
> like it'd be trivial to fix and keep, if we wanted to.
>
>
> On Thu, Nov 15, 2018 at 12:29 PM Fieck, Brennan <
> Brennan_Fieck@comcast.com>
> wrote:
>
> > +1 on removing
> >
> > I'm not super familiar with Java/maven build systems, but I don't
> see a
> > problem with keeping it in the tests if that's possible - but code
> that
> > isn't used shouldn't be a dependency.
> > ________________________________________
> > From: Chris Lemmons <al...@gmail.com>
> > Sent: Thursday, November 15, 2018 12:24 PM
> > To: dev@trafficcontrol.apache.org
> > Subject: [EXTERNAL] Re: Removal of JDNSSEC dependency from Traffic
> Router
> >
> > I'm good with removing it entirely from any even optional use in the
> > code as it could run in production. But testing frameworks against
> one
> > another is absolutely of value, and falls squarely into an adequate
> > licensing exception for LGPL use. I'm -0 on removing it from the
> > tests. If we can't find an easy place for automatic download, we
> > should remove it, but if it's reasonable to swap out the source, or
> > allow folks to build and provide their own, I think we'd gain by
> > including it in our testing scheme.
> > On Thu, Nov 15, 2018 at 12:16 PM Rawlin Peters <
> rawlin.peters@gmail.com>
> > wrote:
> > >
> > > +1
> > > On Thu, Nov 15, 2018 at 10:56 AM Dan Kirkwood <da...@gmail.com>
> wrote:
> > > >
> > > > eliminate an unnecessary dependency? +1 (+1000 if I could...) .
> > > >
> > > > If it's kept around only for testing purposes, the tester
> should deal
> > > > with that separately: perhaps a documentation update is
> warranted in
> > that
> > > > case.
> > > >
> > > > -dan
> > > >
> > > > On Thu, Nov 15, 2018 at 10:40 AM Rivas, Jesse <
> Jesse_Rivas@comcast.com
> > >
> > > > wrote:
> > > >
> > > > > Hi Traffic Controllers,
> > > > >
> > > > > Currently, the .pkg script is failing to build the Traffic
> Router rpm
> > > > > because the build_rpm.sh script for TR attempts to download
> > > > > jdnssec-tools.jar from verisign (
> > > > > http://www.verisignlabs.com/dnssec-tools/packages/old-releases
> ),
> > which is
> > > > > no longer available. Traffic Router used to leverage code from
> the
> > > > > jdnssec-tools.jar for zone signing, but it has since been
> replaced
> > with our
> > > > > own implementation. All of the classes and subsequent tests
> that use
> > the
> > > > > jdnssec package were previously moved from “core” to a separate
> > module in
> > > > > Traffic Router (called “jdnssec”) that is not included in the
> maven
> > build
> > > > > by default, and was kept for legacy and testing purposes. I
> would
> > like to
> > > > > propose removing the JDNSSEC dependency from Traffic Router
> > altogether;
> > > > > this would include removing the jdnssec module in Traffic
> Router and
> > > > > subsequent pom files, and removing the “installDnsSec”
> function from
> > the
> > > > > build_rpm.sh script in Traffic Router that attempts to download
> > > > > jdnssec-tools.jar and fails if it is unsuccessful.
> > > > >
> > > > > Please let me know if there is any opposition to removing the
> > external
> > > > > JDNSSEC dependency from Traffic Router, as it is no longer
> used for
> > zone
> > > > > signing and is no longer available for download from verisign.
> > > > >
> > > > > -Jesse
> > > > >
> >
>
>
>
Re: [EXTERNAL] Re: Removal of JDNSSEC dependency from Traffic Router
Posted by "Rivas, Jesse" <Je...@comcast.com>.
What Dave said is accurate; the tests compare our own zone signing implementation to that of jdnssec.
On 11/16/18, 11:34 AM, "Fieck, Brennan" <Br...@comcast.com> wrote:
If what Dave said is true, then I'm changing my vote to "+1 for removing entirely - including from tests"
________________________________________
From: Schmidt, Andrew (Contractor) <An...@comcast.com>
Sent: Friday, November 16, 2018 8:49 AM
To: dev@trafficcontrol.apache.org
Subject: Re: [EXTERNAL] Re: Removal of JDNSSEC dependency from Traffic Router
+1 getting rid of jdnssec from the rpm. If someone out there still really needs it we could wrap it in its own rpm or just provide the documentation as suggested by Jesse.
On 11/15/18, 9:22 PM, "Dave Neuman" <ne...@apache.org> wrote:
If I recall correctly the “testing” is really just to compare our own
developed version vs the jdnssec version. As far as I am concerned we have
proven it is more than adequate by running in production so those tests are
no longer necessary. +1 on removing the now unnecessary dependency
completely.
On Thu, Nov 15, 2018 at 15:39 Rivas, Jesse <Je...@comcast.com> wrote:
> If consensus is to keep the jdnssec module for testing purposes, the
> download step could be removed from the build_rpm.sh script and
> documentation added on where to download the .jar and how to build with
> maven. That way, the .jar isn't downloaded by default, won't cause the
> build to fail, and it would be easier to maintain documentation on where to
> get the .jar than maintain the build script if the location changes.
> Alternatively, the URL for download could just be updated and continue to
> download and build as it has in the past.
>
> If you feel strongly one way another on updating the download URL in the
> build script, keeping the module in Traffic Router and removing the
> download step from build_rpm.sh, or removing the module completely, please
> share your viewpoint.
>
> -Jesse
>
> On 11/15/18, 12:39 PM, "Robert Butts" <ro...@apache.org> wrote:
>
> Just FYI, it looks like it's on Github, by the original author:
> https://github.com/dblacka/jdnssec-tools/releases/tag/0.12 . So it
> looks
> like it'd be trivial to fix and keep, if we wanted to.
>
>
> On Thu, Nov 15, 2018 at 12:29 PM Fieck, Brennan <
> Brennan_Fieck@comcast.com>
> wrote:
>
> > +1 on removing
> >
> > I'm not super familiar with Java/maven build systems, but I don't
> see a
> > problem with keeping it in the tests if that's possible - but code
> that
> > isn't used shouldn't be a dependency.
> > ________________________________________
> > From: Chris Lemmons <al...@gmail.com>
> > Sent: Thursday, November 15, 2018 12:24 PM
> > To: dev@trafficcontrol.apache.org
> > Subject: [EXTERNAL] Re: Removal of JDNSSEC dependency from Traffic
> Router
> >
> > I'm good with removing it entirely from any even optional use in the
> > code as it could run in production. But testing frameworks against
> one
> > another is absolutely of value, and falls squarely into an adequate
> > licensing exception for LGPL use. I'm -0 on removing it from the
> > tests. If we can't find an easy place for automatic download, we
> > should remove it, but if it's reasonable to swap out the source, or
> > allow folks to build and provide their own, I think we'd gain by
> > including it in our testing scheme.
> > On Thu, Nov 15, 2018 at 12:16 PM Rawlin Peters <
> rawlin.peters@gmail.com>
> > wrote:
> > >
> > > +1
> > > On Thu, Nov 15, 2018 at 10:56 AM Dan Kirkwood <da...@gmail.com>
> wrote:
> > > >
> > > > eliminate an unnecessary dependency? +1 (+1000 if I could...) .
> > > >
> > > > If it's kept around only for testing purposes, the tester
> should deal
> > > > with that separately: perhaps a documentation update is
> warranted in
> > that
> > > > case.
> > > >
> > > > -dan
> > > >
> > > > On Thu, Nov 15, 2018 at 10:40 AM Rivas, Jesse <
> Jesse_Rivas@comcast.com
> > >
> > > > wrote:
> > > >
> > > > > Hi Traffic Controllers,
> > > > >
> > > > > Currently, the .pkg script is failing to build the Traffic
> Router rpm
> > > > > because the build_rpm.sh script for TR attempts to download
> > > > > jdnssec-tools.jar from verisign (
> > > > > http://www.verisignlabs.com/dnssec-tools/packages/old-releases
> ),
> > which is
> > > > > no longer available. Traffic Router used to leverage code from
> the
> > > > > jdnssec-tools.jar for zone signing, but it has since been
> replaced
> > with our
> > > > > own implementation. All of the classes and subsequent tests
> that use
> > the
> > > > > jdnssec package were previously moved from “core” to a separate
> > module in
> > > > > Traffic Router (called “jdnssec”) that is not included in the
> maven
> > build
> > > > > by default, and was kept for legacy and testing purposes. I
> would
> > like to
> > > > > propose removing the JDNSSEC dependency from Traffic Router
> > altogether;
> > > > > this would include removing the jdnssec module in Traffic
> Router and
> > > > > subsequent pom files, and removing the “installDnsSec”
> function from
> > the
> > > > > build_rpm.sh script in Traffic Router that attempts to download
> > > > > jdnssec-tools.jar and fails if it is unsuccessful.
> > > > >
> > > > > Please let me know if there is any opposition to removing the
> > external
> > > > > JDNSSEC dependency from Traffic Router, as it is no longer
> used for
> > zone
> > > > > signing and is no longer available for download from verisign.
> > > > >
> > > > > -Jesse
> > > > >
> >
>
>
>
Re: [EXTERNAL] Re: Removal of JDNSSEC dependency from Traffic Router
Posted by "Gray, Jonathan" <Jo...@comcast.com>.
+1 - I'd leave a comment in the documentation to it as a reference implementation for functional comparison.
Jonathan G
On 11/16/18, 11:35 AM, "Fieck, Brennan" <Br...@comcast.com> wrote:
If what Dave said is true, then I'm changing my vote to "+1 for removing entirely - including from tests"
________________________________________
From: Schmidt, Andrew (Contractor) <An...@comcast.com>
Sent: Friday, November 16, 2018 8:49 AM
To: dev@trafficcontrol.apache.org
Subject: Re: [EXTERNAL] Re: Removal of JDNSSEC dependency from Traffic Router
+1 getting rid of jdnssec from the rpm. If someone out there still really needs it we could wrap it in its own rpm or just provide the documentation as suggested by Jesse.
On 11/15/18, 9:22 PM, "Dave Neuman" <ne...@apache.org> wrote:
If I recall correctly the “testing” is really just to compare our own
developed version vs the jdnssec version. As far as I am concerned we have
proven it is more than adequate by running in production so those tests are
no longer necessary. +1 on removing the now unnecessary dependency
completely.
On Thu, Nov 15, 2018 at 15:39 Rivas, Jesse <Je...@comcast.com> wrote:
> If consensus is to keep the jdnssec module for testing purposes, the
> download step could be removed from the build_rpm.sh script and
> documentation added on where to download the .jar and how to build with
> maven. That way, the .jar isn't downloaded by default, won't cause the
> build to fail, and it would be easier to maintain documentation on where to
> get the .jar than maintain the build script if the location changes.
> Alternatively, the URL for download could just be updated and continue to
> download and build as it has in the past.
>
> If you feel strongly one way another on updating the download URL in the
> build script, keeping the module in Traffic Router and removing the
> download step from build_rpm.sh, or removing the module completely, please
> share your viewpoint.
>
> -Jesse
>
> On 11/15/18, 12:39 PM, "Robert Butts" <ro...@apache.org> wrote:
>
> Just FYI, it looks like it's on Github, by the original author:
> https://github.com/dblacka/jdnssec-tools/releases/tag/0.12 . So it
> looks
> like it'd be trivial to fix and keep, if we wanted to.
>
>
> On Thu, Nov 15, 2018 at 12:29 PM Fieck, Brennan <
> Brennan_Fieck@comcast.com>
> wrote:
>
> > +1 on removing
> >
> > I'm not super familiar with Java/maven build systems, but I don't
> see a
> > problem with keeping it in the tests if that's possible - but code
> that
> > isn't used shouldn't be a dependency.
> > ________________________________________
> > From: Chris Lemmons <al...@gmail.com>
> > Sent: Thursday, November 15, 2018 12:24 PM
> > To: dev@trafficcontrol.apache.org
> > Subject: [EXTERNAL] Re: Removal of JDNSSEC dependency from Traffic
> Router
> >
> > I'm good with removing it entirely from any even optional use in the
> > code as it could run in production. But testing frameworks against
> one
> > another is absolutely of value, and falls squarely into an adequate
> > licensing exception for LGPL use. I'm -0 on removing it from the
> > tests. If we can't find an easy place for automatic download, we
> > should remove it, but if it's reasonable to swap out the source, or
> > allow folks to build and provide their own, I think we'd gain by
> > including it in our testing scheme.
> > On Thu, Nov 15, 2018 at 12:16 PM Rawlin Peters <
> rawlin.peters@gmail.com>
> > wrote:
> > >
> > > +1
> > > On Thu, Nov 15, 2018 at 10:56 AM Dan Kirkwood <da...@gmail.com>
> wrote:
> > > >
> > > > eliminate an unnecessary dependency? +1 (+1000 if I could...) .
> > > >
> > > > If it's kept around only for testing purposes, the tester
> should deal
> > > > with that separately: perhaps a documentation update is
> warranted in
> > that
> > > > case.
> > > >
> > > > -dan
> > > >
> > > > On Thu, Nov 15, 2018 at 10:40 AM Rivas, Jesse <
> Jesse_Rivas@comcast.com
> > >
> > > > wrote:
> > > >
> > > > > Hi Traffic Controllers,
> > > > >
> > > > > Currently, the .pkg script is failing to build the Traffic
> Router rpm
> > > > > because the build_rpm.sh script for TR attempts to download
> > > > > jdnssec-tools.jar from verisign (
> > > > > http://www.verisignlabs.com/dnssec-tools/packages/old-releases
> ),
> > which is
> > > > > no longer available. Traffic Router used to leverage code from
> the
> > > > > jdnssec-tools.jar for zone signing, but it has since been
> replaced
> > with our
> > > > > own implementation. All of the classes and subsequent tests
> that use
> > the
> > > > > jdnssec package were previously moved from “core” to a separate
> > module in
> > > > > Traffic Router (called “jdnssec”) that is not included in the
> maven
> > build
> > > > > by default, and was kept for legacy and testing purposes. I
> would
> > like to
> > > > > propose removing the JDNSSEC dependency from Traffic Router
> > altogether;
> > > > > this would include removing the jdnssec module in Traffic
> Router and
> > > > > subsequent pom files, and removing the “installDnsSec”
> function from
> > the
> > > > > build_rpm.sh script in Traffic Router that attempts to download
> > > > > jdnssec-tools.jar and fails if it is unsuccessful.
> > > > >
> > > > > Please let me know if there is any opposition to removing the
> > external
> > > > > JDNSSEC dependency from Traffic Router, as it is no longer
> used for
> > zone
> > > > > signing and is no longer available for download from verisign.
> > > > >
> > > > > -Jesse
> > > > >
> >
>
>
>
Re: [EXTERNAL] Re: Removal of JDNSSEC dependency from Traffic Router
Posted by "Fieck, Brennan" <Br...@comcast.com>.
If what Dave said is true, then I'm changing my vote to "+1 for removing entirely - including from tests"
________________________________________
From: Schmidt, Andrew (Contractor) <An...@comcast.com>
Sent: Friday, November 16, 2018 8:49 AM
To: dev@trafficcontrol.apache.org
Subject: Re: [EXTERNAL] Re: Removal of JDNSSEC dependency from Traffic Router
+1 getting rid of jdnssec from the rpm. If someone out there still really needs it we could wrap it in its own rpm or just provide the documentation as suggested by Jesse.
On 11/15/18, 9:22 PM, "Dave Neuman" <ne...@apache.org> wrote:
If I recall correctly the “testing” is really just to compare our own
developed version vs the jdnssec version. As far as I am concerned we have
proven it is more than adequate by running in production so those tests are
no longer necessary. +1 on removing the now unnecessary dependency
completely.
On Thu, Nov 15, 2018 at 15:39 Rivas, Jesse <Je...@comcast.com> wrote:
> If consensus is to keep the jdnssec module for testing purposes, the
> download step could be removed from the build_rpm.sh script and
> documentation added on where to download the .jar and how to build with
> maven. That way, the .jar isn't downloaded by default, won't cause the
> build to fail, and it would be easier to maintain documentation on where to
> get the .jar than maintain the build script if the location changes.
> Alternatively, the URL for download could just be updated and continue to
> download and build as it has in the past.
>
> If you feel strongly one way another on updating the download URL in the
> build script, keeping the module in Traffic Router and removing the
> download step from build_rpm.sh, or removing the module completely, please
> share your viewpoint.
>
> -Jesse
>
> On 11/15/18, 12:39 PM, "Robert Butts" <ro...@apache.org> wrote:
>
> Just FYI, it looks like it's on Github, by the original author:
> https://github.com/dblacka/jdnssec-tools/releases/tag/0.12 . So it
> looks
> like it'd be trivial to fix and keep, if we wanted to.
>
>
> On Thu, Nov 15, 2018 at 12:29 PM Fieck, Brennan <
> Brennan_Fieck@comcast.com>
> wrote:
>
> > +1 on removing
> >
> > I'm not super familiar with Java/maven build systems, but I don't
> see a
> > problem with keeping it in the tests if that's possible - but code
> that
> > isn't used shouldn't be a dependency.
> > ________________________________________
> > From: Chris Lemmons <al...@gmail.com>
> > Sent: Thursday, November 15, 2018 12:24 PM
> > To: dev@trafficcontrol.apache.org
> > Subject: [EXTERNAL] Re: Removal of JDNSSEC dependency from Traffic
> Router
> >
> > I'm good with removing it entirely from any even optional use in the
> > code as it could run in production. But testing frameworks against
> one
> > another is absolutely of value, and falls squarely into an adequate
> > licensing exception for LGPL use. I'm -0 on removing it from the
> > tests. If we can't find an easy place for automatic download, we
> > should remove it, but if it's reasonable to swap out the source, or
> > allow folks to build and provide their own, I think we'd gain by
> > including it in our testing scheme.
> > On Thu, Nov 15, 2018 at 12:16 PM Rawlin Peters <
> rawlin.peters@gmail.com>
> > wrote:
> > >
> > > +1
> > > On Thu, Nov 15, 2018 at 10:56 AM Dan Kirkwood <da...@gmail.com>
> wrote:
> > > >
> > > > eliminate an unnecessary dependency? +1 (+1000 if I could...) .
> > > >
> > > > If it's kept around only for testing purposes, the tester
> should deal
> > > > with that separately: perhaps a documentation update is
> warranted in
> > that
> > > > case.
> > > >
> > > > -dan
> > > >
> > > > On Thu, Nov 15, 2018 at 10:40 AM Rivas, Jesse <
> Jesse_Rivas@comcast.com
> > >
> > > > wrote:
> > > >
> > > > > Hi Traffic Controllers,
> > > > >
> > > > > Currently, the .pkg script is failing to build the Traffic
> Router rpm
> > > > > because the build_rpm.sh script for TR attempts to download
> > > > > jdnssec-tools.jar from verisign (
> > > > > http://www.verisignlabs.com/dnssec-tools/packages/old-releases
> ),
> > which is
> > > > > no longer available. Traffic Router used to leverage code from
> the
> > > > > jdnssec-tools.jar for zone signing, but it has since been
> replaced
> > with our
> > > > > own implementation. All of the classes and subsequent tests
> that use
> > the
> > > > > jdnssec package were previously moved from “core” to a separate
> > module in
> > > > > Traffic Router (called “jdnssec”) that is not included in the
> maven
> > build
> > > > > by default, and was kept for legacy and testing purposes. I
> would
> > like to
> > > > > propose removing the JDNSSEC dependency from Traffic Router
> > altogether;
> > > > > this would include removing the jdnssec module in Traffic
> Router and
> > > > > subsequent pom files, and removing the “installDnsSec”
> function from
> > the
> > > > > build_rpm.sh script in Traffic Router that attempts to download
> > > > > jdnssec-tools.jar and fails if it is unsuccessful.
> > > > >
> > > > > Please let me know if there is any opposition to removing the
> > external
> > > > > JDNSSEC dependency from Traffic Router, as it is no longer
> used for
> > zone
> > > > > signing and is no longer available for download from verisign.
> > > > >
> > > > > -Jesse
> > > > >
> >
>
>
>
Re: [EXTERNAL] Re: Removal of JDNSSEC dependency from Traffic Router
Posted by "Schmidt, Andrew (Contractor)" <An...@comcast.com>.
+1 getting rid of jdnssec from the rpm. If someone out there still really needs it we could wrap it in its own rpm or just provide the documentation as suggested by Jesse.
On 11/15/18, 9:22 PM, "Dave Neuman" <ne...@apache.org> wrote:
If I recall correctly the “testing” is really just to compare our own
developed version vs the jdnssec version. As far as I am concerned we have
proven it is more than adequate by running in production so those tests are
no longer necessary. +1 on removing the now unnecessary dependency
completely.
On Thu, Nov 15, 2018 at 15:39 Rivas, Jesse <Je...@comcast.com> wrote:
> If consensus is to keep the jdnssec module for testing purposes, the
> download step could be removed from the build_rpm.sh script and
> documentation added on where to download the .jar and how to build with
> maven. That way, the .jar isn't downloaded by default, won't cause the
> build to fail, and it would be easier to maintain documentation on where to
> get the .jar than maintain the build script if the location changes.
> Alternatively, the URL for download could just be updated and continue to
> download and build as it has in the past.
>
> If you feel strongly one way another on updating the download URL in the
> build script, keeping the module in Traffic Router and removing the
> download step from build_rpm.sh, or removing the module completely, please
> share your viewpoint.
>
> -Jesse
>
> On 11/15/18, 12:39 PM, "Robert Butts" <ro...@apache.org> wrote:
>
> Just FYI, it looks like it's on Github, by the original author:
> https://github.com/dblacka/jdnssec-tools/releases/tag/0.12 . So it
> looks
> like it'd be trivial to fix and keep, if we wanted to.
>
>
> On Thu, Nov 15, 2018 at 12:29 PM Fieck, Brennan <
> Brennan_Fieck@comcast.com>
> wrote:
>
> > +1 on removing
> >
> > I'm not super familiar with Java/maven build systems, but I don't
> see a
> > problem with keeping it in the tests if that's possible - but code
> that
> > isn't used shouldn't be a dependency.
> > ________________________________________
> > From: Chris Lemmons <al...@gmail.com>
> > Sent: Thursday, November 15, 2018 12:24 PM
> > To: dev@trafficcontrol.apache.org
> > Subject: [EXTERNAL] Re: Removal of JDNSSEC dependency from Traffic
> Router
> >
> > I'm good with removing it entirely from any even optional use in the
> > code as it could run in production. But testing frameworks against
> one
> > another is absolutely of value, and falls squarely into an adequate
> > licensing exception for LGPL use. I'm -0 on removing it from the
> > tests. If we can't find an easy place for automatic download, we
> > should remove it, but if it's reasonable to swap out the source, or
> > allow folks to build and provide their own, I think we'd gain by
> > including it in our testing scheme.
> > On Thu, Nov 15, 2018 at 12:16 PM Rawlin Peters <
> rawlin.peters@gmail.com>
> > wrote:
> > >
> > > +1
> > > On Thu, Nov 15, 2018 at 10:56 AM Dan Kirkwood <da...@gmail.com>
> wrote:
> > > >
> > > > eliminate an unnecessary dependency? +1 (+1000 if I could...) .
> > > >
> > > > If it's kept around only for testing purposes, the tester
> should deal
> > > > with that separately: perhaps a documentation update is
> warranted in
> > that
> > > > case.
> > > >
> > > > -dan
> > > >
> > > > On Thu, Nov 15, 2018 at 10:40 AM Rivas, Jesse <
> Jesse_Rivas@comcast.com
> > >
> > > > wrote:
> > > >
> > > > > Hi Traffic Controllers,
> > > > >
> > > > > Currently, the .pkg script is failing to build the Traffic
> Router rpm
> > > > > because the build_rpm.sh script for TR attempts to download
> > > > > jdnssec-tools.jar from verisign (
> > > > > http://www.verisignlabs.com/dnssec-tools/packages/old-releases
> ),
> > which is
> > > > > no longer available. Traffic Router used to leverage code from
> the
> > > > > jdnssec-tools.jar for zone signing, but it has since been
> replaced
> > with our
> > > > > own implementation. All of the classes and subsequent tests
> that use
> > the
> > > > > jdnssec package were previously moved from “core” to a separate
> > module in
> > > > > Traffic Router (called “jdnssec”) that is not included in the
> maven
> > build
> > > > > by default, and was kept for legacy and testing purposes. I
> would
> > like to
> > > > > propose removing the JDNSSEC dependency from Traffic Router
> > altogether;
> > > > > this would include removing the jdnssec module in Traffic
> Router and
> > > > > subsequent pom files, and removing the “installDnsSec”
> function from
> > the
> > > > > build_rpm.sh script in Traffic Router that attempts to download
> > > > > jdnssec-tools.jar and fails if it is unsuccessful.
> > > > >
> > > > > Please let me know if there is any opposition to removing the
> > external
> > > > > JDNSSEC dependency from Traffic Router, as it is no longer
> used for
> > zone
> > > > > signing and is no longer available for download from verisign.
> > > > >
> > > > > -Jesse
> > > > >
> >
>
>
>
Re: [EXTERNAL] Re: Removal of JDNSSEC dependency from Traffic Router
Posted by Dave Neuman <ne...@apache.org>.
If I recall correctly the “testing” is really just to compare our own
developed version vs the jdnssec version. As far as I am concerned we have
proven it is more than adequate by running in production so those tests are
no longer necessary. +1 on removing the now unnecessary dependency
completely.
On Thu, Nov 15, 2018 at 15:39 Rivas, Jesse <Je...@comcast.com> wrote:
> If consensus is to keep the jdnssec module for testing purposes, the
> download step could be removed from the build_rpm.sh script and
> documentation added on where to download the .jar and how to build with
> maven. That way, the .jar isn't downloaded by default, won't cause the
> build to fail, and it would be easier to maintain documentation on where to
> get the .jar than maintain the build script if the location changes.
> Alternatively, the URL for download could just be updated and continue to
> download and build as it has in the past.
>
> If you feel strongly one way another on updating the download URL in the
> build script, keeping the module in Traffic Router and removing the
> download step from build_rpm.sh, or removing the module completely, please
> share your viewpoint.
>
> -Jesse
>
> On 11/15/18, 12:39 PM, "Robert Butts" <ro...@apache.org> wrote:
>
> Just FYI, it looks like it's on Github, by the original author:
> https://github.com/dblacka/jdnssec-tools/releases/tag/0.12 . So it
> looks
> like it'd be trivial to fix and keep, if we wanted to.
>
>
> On Thu, Nov 15, 2018 at 12:29 PM Fieck, Brennan <
> Brennan_Fieck@comcast.com>
> wrote:
>
> > +1 on removing
> >
> > I'm not super familiar with Java/maven build systems, but I don't
> see a
> > problem with keeping it in the tests if that's possible - but code
> that
> > isn't used shouldn't be a dependency.
> > ________________________________________
> > From: Chris Lemmons <al...@gmail.com>
> > Sent: Thursday, November 15, 2018 12:24 PM
> > To: dev@trafficcontrol.apache.org
> > Subject: [EXTERNAL] Re: Removal of JDNSSEC dependency from Traffic
> Router
> >
> > I'm good with removing it entirely from any even optional use in the
> > code as it could run in production. But testing frameworks against
> one
> > another is absolutely of value, and falls squarely into an adequate
> > licensing exception for LGPL use. I'm -0 on removing it from the
> > tests. If we can't find an easy place for automatic download, we
> > should remove it, but if it's reasonable to swap out the source, or
> > allow folks to build and provide their own, I think we'd gain by
> > including it in our testing scheme.
> > On Thu, Nov 15, 2018 at 12:16 PM Rawlin Peters <
> rawlin.peters@gmail.com>
> > wrote:
> > >
> > > +1
> > > On Thu, Nov 15, 2018 at 10:56 AM Dan Kirkwood <da...@gmail.com>
> wrote:
> > > >
> > > > eliminate an unnecessary dependency? +1 (+1000 if I could...) .
> > > >
> > > > If it's kept around only for testing purposes, the tester
> should deal
> > > > with that separately: perhaps a documentation update is
> warranted in
> > that
> > > > case.
> > > >
> > > > -dan
> > > >
> > > > On Thu, Nov 15, 2018 at 10:40 AM Rivas, Jesse <
> Jesse_Rivas@comcast.com
> > >
> > > > wrote:
> > > >
> > > > > Hi Traffic Controllers,
> > > > >
> > > > > Currently, the .pkg script is failing to build the Traffic
> Router rpm
> > > > > because the build_rpm.sh script for TR attempts to download
> > > > > jdnssec-tools.jar from verisign (
> > > > > http://www.verisignlabs.com/dnssec-tools/packages/old-releases
> ),
> > which is
> > > > > no longer available. Traffic Router used to leverage code from
> the
> > > > > jdnssec-tools.jar for zone signing, but it has since been
> replaced
> > with our
> > > > > own implementation. All of the classes and subsequent tests
> that use
> > the
> > > > > jdnssec package were previously moved from “core” to a separate
> > module in
> > > > > Traffic Router (called “jdnssec”) that is not included in the
> maven
> > build
> > > > > by default, and was kept for legacy and testing purposes. I
> would
> > like to
> > > > > propose removing the JDNSSEC dependency from Traffic Router
> > altogether;
> > > > > this would include removing the jdnssec module in Traffic
> Router and
> > > > > subsequent pom files, and removing the “installDnsSec”
> function from
> > the
> > > > > build_rpm.sh script in Traffic Router that attempts to download
> > > > > jdnssec-tools.jar and fails if it is unsuccessful.
> > > > >
> > > > > Please let me know if there is any opposition to removing the
> > external
> > > > > JDNSSEC dependency from Traffic Router, as it is no longer
> used for
> > zone
> > > > > signing and is no longer available for download from verisign.
> > > > >
> > > > > -Jesse
> > > > >
> >
>
>
>
Re: [EXTERNAL] Re: Removal of JDNSSEC dependency from Traffic Router
Posted by "Rivas, Jesse" <Je...@comcast.com>.
If consensus is to keep the jdnssec module for testing purposes, the download step could be removed from the build_rpm.sh script and documentation added on where to download the .jar and how to build with maven. That way, the .jar isn't downloaded by default, won't cause the build to fail, and it would be easier to maintain documentation on where to get the .jar than maintain the build script if the location changes. Alternatively, the URL for download could just be updated and continue to download and build as it has in the past.
If you feel strongly one way another on updating the download URL in the build script, keeping the module in Traffic Router and removing the download step from build_rpm.sh, or removing the module completely, please share your viewpoint.
-Jesse
On 11/15/18, 12:39 PM, "Robert Butts" <ro...@apache.org> wrote:
Just FYI, it looks like it's on Github, by the original author:
https://github.com/dblacka/jdnssec-tools/releases/tag/0.12 . So it looks
like it'd be trivial to fix and keep, if we wanted to.
On Thu, Nov 15, 2018 at 12:29 PM Fieck, Brennan <Br...@comcast.com>
wrote:
> +1 on removing
>
> I'm not super familiar with Java/maven build systems, but I don't see a
> problem with keeping it in the tests if that's possible - but code that
> isn't used shouldn't be a dependency.
> ________________________________________
> From: Chris Lemmons <al...@gmail.com>
> Sent: Thursday, November 15, 2018 12:24 PM
> To: dev@trafficcontrol.apache.org
> Subject: [EXTERNAL] Re: Removal of JDNSSEC dependency from Traffic Router
>
> I'm good with removing it entirely from any even optional use in the
> code as it could run in production. But testing frameworks against one
> another is absolutely of value, and falls squarely into an adequate
> licensing exception for LGPL use. I'm -0 on removing it from the
> tests. If we can't find an easy place for automatic download, we
> should remove it, but if it's reasonable to swap out the source, or
> allow folks to build and provide their own, I think we'd gain by
> including it in our testing scheme.
> On Thu, Nov 15, 2018 at 12:16 PM Rawlin Peters <ra...@gmail.com>
> wrote:
> >
> > +1
> > On Thu, Nov 15, 2018 at 10:56 AM Dan Kirkwood <da...@gmail.com> wrote:
> > >
> > > eliminate an unnecessary dependency? +1 (+1000 if I could...) .
> > >
> > > If it's kept around only for testing purposes, the tester should deal
> > > with that separately: perhaps a documentation update is warranted in
> that
> > > case.
> > >
> > > -dan
> > >
> > > On Thu, Nov 15, 2018 at 10:40 AM Rivas, Jesse <Jesse_Rivas@comcast.com
> >
> > > wrote:
> > >
> > > > Hi Traffic Controllers,
> > > >
> > > > Currently, the .pkg script is failing to build the Traffic Router rpm
> > > > because the build_rpm.sh script for TR attempts to download
> > > > jdnssec-tools.jar from verisign (
> > > > http://www.verisignlabs.com/dnssec-tools/packages/old-releases),
> which is
> > > > no longer available. Traffic Router used to leverage code from the
> > > > jdnssec-tools.jar for zone signing, but it has since been replaced
> with our
> > > > own implementation. All of the classes and subsequent tests that use
> the
> > > > jdnssec package were previously moved from “core” to a separate
> module in
> > > > Traffic Router (called “jdnssec”) that is not included in the maven
> build
> > > > by default, and was kept for legacy and testing purposes. I would
> like to
> > > > propose removing the JDNSSEC dependency from Traffic Router
> altogether;
> > > > this would include removing the jdnssec module in Traffic Router and
> > > > subsequent pom files, and removing the “installDnsSec” function from
> the
> > > > build_rpm.sh script in Traffic Router that attempts to download
> > > > jdnssec-tools.jar and fails if it is unsuccessful.
> > > >
> > > > Please let me know if there is any opposition to removing the
> external
> > > > JDNSSEC dependency from Traffic Router, as it is no longer used for
> zone
> > > > signing and is no longer available for download from verisign.
> > > >
> > > > -Jesse
> > > >
>
Re: [EXTERNAL] Re: Removal of JDNSSEC dependency from Traffic Router
Posted by Robert Butts <ro...@apache.org>.
Just FYI, it looks like it's on Github, by the original author:
https://github.com/dblacka/jdnssec-tools/releases/tag/0.12 . So it looks
like it'd be trivial to fix and keep, if we wanted to.
On Thu, Nov 15, 2018 at 12:29 PM Fieck, Brennan <Br...@comcast.com>
wrote:
> +1 on removing
>
> I'm not super familiar with Java/maven build systems, but I don't see a
> problem with keeping it in the tests if that's possible - but code that
> isn't used shouldn't be a dependency.
> ________________________________________
> From: Chris Lemmons <al...@gmail.com>
> Sent: Thursday, November 15, 2018 12:24 PM
> To: dev@trafficcontrol.apache.org
> Subject: [EXTERNAL] Re: Removal of JDNSSEC dependency from Traffic Router
>
> I'm good with removing it entirely from any even optional use in the
> code as it could run in production. But testing frameworks against one
> another is absolutely of value, and falls squarely into an adequate
> licensing exception for LGPL use. I'm -0 on removing it from the
> tests. If we can't find an easy place for automatic download, we
> should remove it, but if it's reasonable to swap out the source, or
> allow folks to build and provide their own, I think we'd gain by
> including it in our testing scheme.
> On Thu, Nov 15, 2018 at 12:16 PM Rawlin Peters <ra...@gmail.com>
> wrote:
> >
> > +1
> > On Thu, Nov 15, 2018 at 10:56 AM Dan Kirkwood <da...@gmail.com> wrote:
> > >
> > > eliminate an unnecessary dependency? +1 (+1000 if I could...) .
> > >
> > > If it's kept around only for testing purposes, the tester should deal
> > > with that separately: perhaps a documentation update is warranted in
> that
> > > case.
> > >
> > > -dan
> > >
> > > On Thu, Nov 15, 2018 at 10:40 AM Rivas, Jesse <Jesse_Rivas@comcast.com
> >
> > > wrote:
> > >
> > > > Hi Traffic Controllers,
> > > >
> > > > Currently, the .pkg script is failing to build the Traffic Router rpm
> > > > because the build_rpm.sh script for TR attempts to download
> > > > jdnssec-tools.jar from verisign (
> > > > http://www.verisignlabs.com/dnssec-tools/packages/old-releases),
> which is
> > > > no longer available. Traffic Router used to leverage code from the
> > > > jdnssec-tools.jar for zone signing, but it has since been replaced
> with our
> > > > own implementation. All of the classes and subsequent tests that use
> the
> > > > jdnssec package were previously moved from “core” to a separate
> module in
> > > > Traffic Router (called “jdnssec”) that is not included in the maven
> build
> > > > by default, and was kept for legacy and testing purposes. I would
> like to
> > > > propose removing the JDNSSEC dependency from Traffic Router
> altogether;
> > > > this would include removing the jdnssec module in Traffic Router and
> > > > subsequent pom files, and removing the “installDnsSec” function from
> the
> > > > build_rpm.sh script in Traffic Router that attempts to download
> > > > jdnssec-tools.jar and fails if it is unsuccessful.
> > > >
> > > > Please let me know if there is any opposition to removing the
> external
> > > > JDNSSEC dependency from Traffic Router, as it is no longer used for
> zone
> > > > signing and is no longer available for download from verisign.
> > > >
> > > > -Jesse
> > > >
>
Re: [EXTERNAL] Re: Removal of JDNSSEC dependency from Traffic Router
Posted by "Fieck, Brennan" <Br...@comcast.com>.
+1 on removing
I'm not super familiar with Java/maven build systems, but I don't see a problem with keeping it in the tests if that's possible - but code that isn't used shouldn't be a dependency.
________________________________________
From: Chris Lemmons <al...@gmail.com>
Sent: Thursday, November 15, 2018 12:24 PM
To: dev@trafficcontrol.apache.org
Subject: [EXTERNAL] Re: Removal of JDNSSEC dependency from Traffic Router
I'm good with removing it entirely from any even optional use in the
code as it could run in production. But testing frameworks against one
another is absolutely of value, and falls squarely into an adequate
licensing exception for LGPL use. I'm -0 on removing it from the
tests. If we can't find an easy place for automatic download, we
should remove it, but if it's reasonable to swap out the source, or
allow folks to build and provide their own, I think we'd gain by
including it in our testing scheme.
On Thu, Nov 15, 2018 at 12:16 PM Rawlin Peters <ra...@gmail.com> wrote:
>
> +1
> On Thu, Nov 15, 2018 at 10:56 AM Dan Kirkwood <da...@gmail.com> wrote:
> >
> > eliminate an unnecessary dependency? +1 (+1000 if I could...) .
> >
> > If it's kept around only for testing purposes, the tester should deal
> > with that separately: perhaps a documentation update is warranted in that
> > case.
> >
> > -dan
> >
> > On Thu, Nov 15, 2018 at 10:40 AM Rivas, Jesse <Je...@comcast.com>
> > wrote:
> >
> > > Hi Traffic Controllers,
> > >
> > > Currently, the .pkg script is failing to build the Traffic Router rpm
> > > because the build_rpm.sh script for TR attempts to download
> > > jdnssec-tools.jar from verisign (
> > > http://www.verisignlabs.com/dnssec-tools/packages/old-releases), which is
> > > no longer available. Traffic Router used to leverage code from the
> > > jdnssec-tools.jar for zone signing, but it has since been replaced with our
> > > own implementation. All of the classes and subsequent tests that use the
> > > jdnssec package were previously moved from “core” to a separate module in
> > > Traffic Router (called “jdnssec”) that is not included in the maven build
> > > by default, and was kept for legacy and testing purposes. I would like to
> > > propose removing the JDNSSEC dependency from Traffic Router altogether;
> > > this would include removing the jdnssec module in Traffic Router and
> > > subsequent pom files, and removing the “installDnsSec” function from the
> > > build_rpm.sh script in Traffic Router that attempts to download
> > > jdnssec-tools.jar and fails if it is unsuccessful.
> > >
> > > Please let me know if there is any opposition to removing the external
> > > JDNSSEC dependency from Traffic Router, as it is no longer used for zone
> > > signing and is no longer available for download from verisign.
> > >
> > > -Jesse
> > >
Re: Removal of JDNSSEC dependency from Traffic Router
Posted by Chris Lemmons <al...@gmail.com>.
I'm good with removing it entirely from any even optional use in the
code as it could run in production. But testing frameworks against one
another is absolutely of value, and falls squarely into an adequate
licensing exception for LGPL use. I'm -0 on removing it from the
tests. If we can't find an easy place for automatic download, we
should remove it, but if it's reasonable to swap out the source, or
allow folks to build and provide their own, I think we'd gain by
including it in our testing scheme.
On Thu, Nov 15, 2018 at 12:16 PM Rawlin Peters <ra...@gmail.com> wrote:
>
> +1
> On Thu, Nov 15, 2018 at 10:56 AM Dan Kirkwood <da...@gmail.com> wrote:
> >
> > eliminate an unnecessary dependency? +1 (+1000 if I could...) .
> >
> > If it's kept around only for testing purposes, the tester should deal
> > with that separately: perhaps a documentation update is warranted in that
> > case.
> >
> > -dan
> >
> > On Thu, Nov 15, 2018 at 10:40 AM Rivas, Jesse <Je...@comcast.com>
> > wrote:
> >
> > > Hi Traffic Controllers,
> > >
> > > Currently, the .pkg script is failing to build the Traffic Router rpm
> > > because the build_rpm.sh script for TR attempts to download
> > > jdnssec-tools.jar from verisign (
> > > http://www.verisignlabs.com/dnssec-tools/packages/old-releases), which is
> > > no longer available. Traffic Router used to leverage code from the
> > > jdnssec-tools.jar for zone signing, but it has since been replaced with our
> > > own implementation. All of the classes and subsequent tests that use the
> > > jdnssec package were previously moved from “core” to a separate module in
> > > Traffic Router (called “jdnssec”) that is not included in the maven build
> > > by default, and was kept for legacy and testing purposes. I would like to
> > > propose removing the JDNSSEC dependency from Traffic Router altogether;
> > > this would include removing the jdnssec module in Traffic Router and
> > > subsequent pom files, and removing the “installDnsSec” function from the
> > > build_rpm.sh script in Traffic Router that attempts to download
> > > jdnssec-tools.jar and fails if it is unsuccessful.
> > >
> > > Please let me know if there is any opposition to removing the external
> > > JDNSSEC dependency from Traffic Router, as it is no longer used for zone
> > > signing and is no longer available for download from verisign.
> > >
> > > -Jesse
> > >
Re: Removal of JDNSSEC dependency from Traffic Router
Posted by Rawlin Peters <ra...@gmail.com>.
+1
On Thu, Nov 15, 2018 at 10:56 AM Dan Kirkwood <da...@gmail.com> wrote:
>
> eliminate an unnecessary dependency? +1 (+1000 if I could...) .
>
> If it's kept around only for testing purposes, the tester should deal
> with that separately: perhaps a documentation update is warranted in that
> case.
>
> -dan
>
> On Thu, Nov 15, 2018 at 10:40 AM Rivas, Jesse <Je...@comcast.com>
> wrote:
>
> > Hi Traffic Controllers,
> >
> > Currently, the .pkg script is failing to build the Traffic Router rpm
> > because the build_rpm.sh script for TR attempts to download
> > jdnssec-tools.jar from verisign (
> > http://www.verisignlabs.com/dnssec-tools/packages/old-releases), which is
> > no longer available. Traffic Router used to leverage code from the
> > jdnssec-tools.jar for zone signing, but it has since been replaced with our
> > own implementation. All of the classes and subsequent tests that use the
> > jdnssec package were previously moved from “core” to a separate module in
> > Traffic Router (called “jdnssec”) that is not included in the maven build
> > by default, and was kept for legacy and testing purposes. I would like to
> > propose removing the JDNSSEC dependency from Traffic Router altogether;
> > this would include removing the jdnssec module in Traffic Router and
> > subsequent pom files, and removing the “installDnsSec” function from the
> > build_rpm.sh script in Traffic Router that attempts to download
> > jdnssec-tools.jar and fails if it is unsuccessful.
> >
> > Please let me know if there is any opposition to removing the external
> > JDNSSEC dependency from Traffic Router, as it is no longer used for zone
> > signing and is no longer available for download from verisign.
> >
> > -Jesse
> >
Re: Removal of JDNSSEC dependency from Traffic Router
Posted by Dan Kirkwood <da...@gmail.com>.
eliminate an unnecessary dependency? +1 (+1000 if I could...) .
If it's kept around only for testing purposes, the tester should deal
with that separately: perhaps a documentation update is warranted in that
case.
-dan
On Thu, Nov 15, 2018 at 10:40 AM Rivas, Jesse <Je...@comcast.com>
wrote:
> Hi Traffic Controllers,
>
> Currently, the .pkg script is failing to build the Traffic Router rpm
> because the build_rpm.sh script for TR attempts to download
> jdnssec-tools.jar from verisign (
> http://www.verisignlabs.com/dnssec-tools/packages/old-releases), which is
> no longer available. Traffic Router used to leverage code from the
> jdnssec-tools.jar for zone signing, but it has since been replaced with our
> own implementation. All of the classes and subsequent tests that use the
> jdnssec package were previously moved from “core” to a separate module in
> Traffic Router (called “jdnssec”) that is not included in the maven build
> by default, and was kept for legacy and testing purposes. I would like to
> propose removing the JDNSSEC dependency from Traffic Router altogether;
> this would include removing the jdnssec module in Traffic Router and
> subsequent pom files, and removing the “installDnsSec” function from the
> build_rpm.sh script in Traffic Router that attempts to download
> jdnssec-tools.jar and fails if it is unsuccessful.
>
> Please let me know if there is any opposition to removing the external
> JDNSSEC dependency from Traffic Router, as it is no longer used for zone
> signing and is no longer available for download from verisign.
>
> -Jesse
>