[arch-d] Review of: draft-iab-protocol-transitions-05

[Dave Crocker <[e-mail]>]

Review of:  draft-iab-protocol-transitions-05

Reviewer:  D. Crocker
Date:      16 Jan 2017


Summary:

    The draft provides an overview of the issues in achieving a 
transition from one capability to another. (It's worth considering 
whether this should include introduction of new capabilities -- that is, 
"transitioning" from no capability. Many adoption issues are the same.

    The topic is of fundamental importance to IETF work and is often 
overlooked or viewed idealistically.  So a document like this should be 
quite helpful (if folks will pay attention to it.)

    The document is well-organized and well-written.  There are some 
clarifications and expansions worth considering, as noted below, and 
some basic points cited here:

    The document tends to merely mention essential issues, such as 
incentives, without giving much insight into either methods for 
adequately assessing incentives or deciding how to consider them in 
protocol design.

    The document also seems to conflate "adoption" with "transition". 
Much of the content of the document applies to initial adoption of a 
protocol, as well as to later transitions to revisions.  While 
transitions carry significant additional burdens, beyond initial 
adoption, the IETF needs attention to initial adoption issues every bit 
as much as it needs attention to transition issues.

    Although the document references open source implementations and the 
challenges of having a timeline, it should emphasize the role of the 
former more and the severe problems with the latter.

    Might be worth adding some examples of highly successful 
transitions.  MIME is, predictably, my favorite example.  There had been 
multiple attempts to replace existing, text-based email with a new 
version that supported multi-media.  MIME instead created an overlay 
that required no change to the infrastructure.



    These above suggestions are in line with Eliot's call for more 
'meat'.  The document touches on essential issues.  But for the IETF to 
deal with the issues well, there needs to be more detailed basis giving 
guidance for how to attend to them. This is particularly important for 
issues such as incentives analysis and aligning to incentives, since 
they are topics not normally within the purview of Internet engineers. 
(If the feeling is that the meat should be added via later documents 
then there should at least, now, be development of some plan for those 
documents.)

    Stewart's call for considering the requirement of transition 
considerations -- I'd suggest 'adoption considerations' -- would press 
working groups to do far more due diligence about the barriers to 
adoption that is typically done now.




Detailed:


> 1.  Introduction
>
>    A "transition" is "the process or period of changing from one state
>    or condition to another".  There are several types of such

Use of quotation marks implies that the text comes from elsewhere.  Where?


>    transitions, including both technical transitions (e.g., changing
>    protocols or deploying an extension) and organizational transitions
>    (e.g., changing what organization manages the IETF web site, or the
>    RFC production center).  This document focuses solely on technical

It would be better for the examples to not be IETF-centric and 
especially not to require the reader to know about the internals of the 
IETF, such as about the RFC production center.

In this case, perhaps: changing what organization manages a web site 
that uses IETF specifications.  Would authorizing a new network 
management team constitute a transition?




> 2.  Transition vs. Co-existence
>
>    There is an important distinction between a strict "flag-day" style
>    transition where an old mechanism is immediately replaced with a new
>    mechanism, vs. a looser co-existence based approach where transition
>    proceeds in stages where a new mechanism is first added alongside an
>    existing one for some overlap period, and then the old mechanism is
>    removed at a later stage.
>
>    When a new mechanism is backwards compatible with an existing
>    mechanism, transition is easiest, and the difference between the two
>    types of transition is not particularly significant.  However, when

I suspect you don't mean quite what is written.  The differences still 
might be highly significant.  More likely:  transition is easiest 
because the timing of adoption by each party is not critical.


>    no backwards compatibility exists (such as in the IPv4 to IPv6
>    transition), a transition plan must choose either a "flag day" or a
>    period of co-existence.  When a large number of entities are
>    involved, a flag day becomes impractical.  Coexistence, on the other
>    hand, involves additional costs of maintaining two separate
>    mechanisms during the overlap period which could be quite long.
>    Furthermore, the longer the overlap period, the more the old
>    mechanism might get further deployment and thus increase the overall
>    pain of transition.

A phrase like "period of co-existence" encourages the reader to think 
that the period can be constrained.  Besides making flag days 
impractical, large scale operation renders control over the length of a 
transition impractical.  In fact it tends to ensure an extremely long 
adoption tail, measured in years and probably decades.  This is not a 
small point, when designing for transitions.  At base, 'transitions' for 
Internet scale are really long-term cohabitation.


>    Often the decision between a "flag day" and a sustained co-existence
>    period may be complicated when differing incentives are involved
>    (e.g., see the case studies in the Appendix).

For any IETF work, when has a flag day been specified and implemented 
successfully?  While the idea of a flag day is appealing, it isn't ever 
practical both because of Internet scale and because multiple, 
independent administrations are (nearly) always involved.


>
> 3.  Translation/Adaptation Location
>
>    A translation or adaptation mechanism is often required if the old
>    and new mechanisms are not interoperable.  Care must be taken when
>    determining whether one will work and where such a translator is best
>    placed.
>
>    A translation mechanism may not work for every use case.  For
>    example, if a translation from one protocol (or protocol version) to
>    another produces indeterminate results, translation will not work
>    reliably.  In addition, if translation always produces a downgraded
>    protocol result, the incentive considerations in Section 4.2 will be
>    relevant.
>
>    Requiring a translator in the middle of the path can hamper end-to-
>    end security and reliability.  For example, see the discussion of
>    network-based filtering in [RFC7754].
>
>    On the other hand, requiring a translation layer within an endpoint
>    can be a resource issue in some cases, such as if the endpoint could
>    be a constrained node [RFC7228].
>
>    In addition, when a translator is within an endpoint, it can can
>    attempt to hide the difference between an older protocol and a newer
>    protocol, either by exposing one of the two sets of behavior to
>    applications and internally mapping it to the other set of behavior,
>    or by exposing a higher level of abstraction which is then
>    alternatively mapped to either one depending on detecting which is
>    needed.  In contrast, when a translator is in the middle of the path,
>    typically only the first approach can be done since the middle of the
>    path is typically unable to provide a higher level of abstraction.
>
>    Any transition strategy for a non-backward-compatible mechanism
>    should include a discussion of where it is placed and a rationale.
>    The transition plan should also consider the transition away from the
>    use of translation and adaptation technologies.

This discussion should also consider the complexity of translation 
required.  It is sometimes  possible to make the new design easier to 
translate to/from the old, or to make it more difficult.  Enthusiasm for 
new features often causes this point to be ignored.

The original Deering IPv6 design was pretty easy to translate.  In fact, 
if IPv6 addressing had been made a superset of existing IPv4, 
translation would have been trivial.

The major challenge in translation is for semantic differences.  Often, 
syntactic differences can be translated seamlessly.  Semantic ones 
almost never.

Hence, attention to transition, when there is any interest in 
translation, should include documenting the syntactic and semantic 
differences;


>
> 4.  Transition Plans
>
>    A review of the case studies described in Appendix A suggests that a
>    good transition plan includes at least the following components: an
>    understanding of what is already deployed and in use, an explanation
>    of incentives for each entity involved, a description of the phases
>    of the transition along with a proposed timeline, a method for

Overall, quite a good list.

However for IETF efforts -- that is, for anything to be deployed at 
Internet scale -- any concept of a transition timeline is misleading, at 
best.  There is no history of succeeding with an attempt at timely 
transition, nevermind attempting to predict it.

Hence, trying to set a schedule distracts from the well-established 
track showing that transitions essentially take forever.  Hence the most 
practical approach is to talk about adoption milestones and, in 
particular, considering what constitutes 'critical mass'.  That is, when 
is it reasonable to consider adoption sufficient to ensure the continued 
use and further adoption of the capability?

Also, there is almost always need for an entity facilitating the 
transition.  The issue here isn't one of authority but of advocacy and 
focus.  Otherwise -- even with a good understanding of incentives -- the 
effort is left to happenstance.  This is an entity independent of the IETF.


>
>
> Thaler                    Expires July 8, 2017                  [Page 5]
>
>
> Internet-Draft           Planning for Transition            January 2017
>
>
>    measuring the transition's success, a contingency plan for failure of
>    the transition, and an effective method for communicating the plan to
>    the entities involved and incorporating their feedback thereon.  We
>    recommend that such criteria be considered when evaluating proposals
>    to transition to new or updated protocols.  Each of these components
>    is discussed in the subsections below.
>
> 4.1.  Understanding of Existing Deployment
>
>    Often an existing mechanism has variations in implementations and
>    operational deployments.  For example, a specification might include
>    optional behaviors that may or may not be implemented or deployed.
>    In addition, there may also be implementations or deployments that
>    deviate from, or include vendor-specific extensions to, various
>    aspects of a specification.  It is important when considering a
>    transition to understand what variations one is intending to
>    transition from or co-exist with, since the technical and non-
>    technical issues may vary greatly as a result.
>
> 4.2.  Explanation of Incentives
>
>    A transition plan should explain the incentives to each involved
>    entity to support the transition.  Note here that many entities other
>    than the endpoint applications and their users may be affected, and
>    the barriers to transition may be nontechnical as well as technical.
>    When considering these incentives, also consider network operations
>    tools, practices, and processes, personnel training, accounting and
>    billing dependencies, and legal and regulatory incentives.

It's worth noting that an analysis of incentives is too easily led 
astray by wishful thinking and by a failure to adequately consider the 
realities of the entities being described.

An obvious (and frequent) example of misjudging incentives is ever 
thinking that any commercial operation adopts something out of a sense 
of civic obligation or long-term benefit.  Although there are, of 
course, exceptions, the pattern is never encouraging.

Consequently, analysis of incentives should carefully justify the 
/basis/ for claiming the incentives.  This is aided by an honest 
consideration of the barriers to adoption for each entity.  What could 
cause them to fail to adopt or take longer?


>    If there is opposition to a particular new protocol (e.g., from
>    another standards organization, or a government, or some other
>    affected entity), various non-technical issues arise that should be
>    part of what is planned and dealt with.  Similarly, if there are
>    significant costs or other disincentives, the plan needs to consider
>    how to overcome them.

The pragmatics of the incentives analysis is facilitated by looking at 
whatever advocacy group has formed to promoted the adoption.  Who are 
the folk promoting the transition and what are their capabilities for 
making it likely to succeed.  Here, too, the challenge is to avoid 
wishful thinking...


>
> 4.3.  Description of Phases and Proposed Timeline
>
>    Transition phases might include pilot/experimental deployment,
>    coexistence, deprecation, and removal phases for a transition from
>    one technology to another incompatible one.

Hmmm.  Rather than attempting a timeline, it probably helps more to 
consider specifying criteria that need to be satisfied, to go from one 
phase to the next.  So a term like "phases" and "milestones" makes more 
sense.


>    Timelines are notoriously difficult to predict and impossible to
>    impose on uncoordinated transitions at the scale of the Internet, but
>    rough estimates can help all involved entities to understand the
>    intended duration of each phase.

So, yes, good that this is in the document, but I'll suggest it show up 
earlier and, if anything, even stronger.


>
>
>
>
> Thaler                    Expires July 8, 2017                  [Page 6]
>
>
> Internet-Draft           Planning for Transition            January 2017
>
>
> 4.4.  Measurement of Success
>
>    The degree of deployment of a given protocol or feature at a given
>    phase in its transition can be measured differently, depending on its
>    design.  For example, server-side protocols and options which
>    identify themselves through a versioning or negotiation mechanism can
>    be discovered through active Internet measurement studies.


>
> 4.5.  Contingency Planning
>
>    A contingency plan can be as simple as providing for indefinite
>    coexistence between an old and new protocol.

This seems an unusual enough topic to warrant more detail.

What types of contingency have been done and proved useful?  What other 
sorts might be considered?


>
> 4.6.  Communicating the Plan
>
>    Many of the entities involved in a protocol transition may not be
>    aware of the IETF or the RFC series, so dissemination through other
>    channels is key for sufficiently broad communication of the
>    transition plan.  While flag days are impractical at Internet scale,
>    coordinated "events" such as World IPv6 Launch may improve general
>    awareness of an ongoing transition.

Yes, but...  Is there any basis for believing that that event was 
actually useful in gaining wider adoption?  If so, it's worth citing the 
documentation.  How do the IPv6 statistics support this?

My point is that events should be considered with a skeptical eye 
towards pragmatics.  It is far too easy to conduct an event that feels 
encouraging to those putting it on but which has little practical 
benefit.  The downside of this is that, at the least, it drains energy 
from the community promoting adoption.




> Appendix A.  Case Studies
>
>    Appendix A of [RFC5218] describes a number of case studies that are
>    relevant to this document and highlight various transition problems
>    and strategies (see for instance the Inter-Domain Multicast case
>    study in Section A.4 of [RFC5218]).  We now include several
>    additional case studies that focus on transition problems and
>    strategies.  Many other equally good case studies could have been
>    included, but, in the interests of brevity, only a sampling is
>    included here that is sufficient to justify the conclusions in the
>    body of this document.
>
> A.1.  Explicit Congestion Notification

This one sounds more like "adoption" than "transition".  It's a new 
mechanism and the adjustments were to find a way to get /any/ stable use.


> A.2.  Internationalized Domain Names
 >
>    The deployment of Internationalized Domain Names (IDN) has a long and
>    complicated history.  This should not be surprising, since
>    internationalization deals with language and cultural issues
>    regarding differing expectations of users around the world, thus
>    making it inherently difficult to agree on common rules.
>    Furthermore, because human languages evolve and change over time,
>    even if common rules can be established, there is likely to be a need
>    to review and update them regularly.
>
>    There have been multiple technical transitions related to IDNs,

There have been multiple specifications.  From what I've seen, the 
specification process has paid little attention to transition.

(There's an ICANN initiative to get better /adoption/, but that's not 
strictly the same as is meant here for /transition/.)

This section highlights the challenge of distinguishing between the fact 
of specification evolution, versus the process of transitioning between 
versions.  This section seems to cite the specifications rather than 
transition details.


>    including the introduction of non-ASCII in DNS, the transition to
>    each new version of Unicode, and the transition from IDNA 2003 to
>    IDNA 2008.  A brief history of the introduction of non-ASCII in DNS
>
>
>
> Thaler                    Expires July 8, 2017                 [Page 12]
>
>
> Internet-Draft           Planning for Transition            January 2017
>
>
>    and the various complications that arose therein, can be found in
>    section 3 of [RFC6055].  While IDNA 2003 was limited to Unicode
>    version 3.2 only, one of the IDNA 2008 changes was to decouple its
>    rules from any particular version of Unicode (see [RFC5894],
>    especially section 1.4, for more discussion of this point, and see
>    [RFC4690] for a list of other issues with IDNA 2003 that motivated
>    IDNA 2008).  However, the transition from IDNA 2003 to IDNA 2008
>    itself presented a problem since IDNA 2008 did not preserve backwards
>    compatibility with IDNA 2003 for a couple of codepoints.
>    Investigations and discussions with affected parties led to the IETF
>    ultimately choosing IDNA 2008 because the overall gain by moving to
>    IDNA 2008 to fix the problems with IDNA 2003 was seen to be much
>    greater than the problems due to the few incompatibilities at the
>    time of the change, as not many IDNs were in use, and even fewer that
>    might see incompatibilities.
>
>    A couple browser vendors in particular were concerned about the

   couple of


>    differences between IDNA 2003 and IDNA 2008, and the fact that if a
>    browser stopped being able to get to some site, or unknowingly sent a
>    user to a different (e.g., phishing) site instead, the browser would
>    be blamed.  As such, any user-perceivable change from IDNA 2003
>    behavior would be painful to the vendor to deal with, and hence they
>    could not depend on solutions that would need action by other
>    entities.
>
>    Thus, to deal with issues like such incompatibilities, applications
>    and client-side frameworks often want to map one string into another
>    (namely, a string that would give the same result as when IDNA 2003
>    was used) before invoking DNS.

"want"?  this sounds more like prescription than about a case study of 
what actually was done.


>    To provide such mapping (and some other functioanlity), the Unicode
>    Consortium published [TR46] that continued down the path of IDNA 2003
>    with a code point by code point selection mechanism.  This was
>    implemented by some, but never adopted by the IETF.
>
>    Meanwhile, the IETF did not publish any mapping mechanism, but
>    [RFC5895] was published on the Independent Submission stream.  In
>    discussions around mapping, one of the key topics was about how long
>    the transition should last.  At one end of the duration spectrum is a
>    flag day where some entities would be broken initially but the change
>    would happen before IDN usage became even more ubiquitous.  At the
>    other end of the spectrum is the need to maintain mappings
>    indefinitely.  Local incentives at each entity who needed to change,
>    however, meant that a short timeframe was impractical.

I don't understand the above.

Again, it appears to be a discussion of possibilities rather than the 
details of something that was part of a case study.

>
>    There are many affected types of entities with very different
>    incentives.  For example, the incentives affecting browser vendors,
>    registries, domain name marketers and applicants, app developers, and
>
>
>
> Thaler                    Expires July 8, 2017                 [Page 13]
>
>
> Internet-Draft           Planning for Transition            January 2017
>
>
>    protocol designers are each quite different, and the various
>    solutions require changes by multiple types of entities, where the

The substance of listing these entities is in talking about actual 
incentives, not merely saying they will be different.  Readers need to 
see enough detail to learn something about applying the concern they 
should have.


>    benefits do not always align with the costs.  If there is some group
>    (or even an individual) that is opposed to a change/transition and
>    able to put significant resources behind their opposition,
>    transitions get a lot harder.


>
>    Finally, it is worth pointing out that there are multiple naming
>    contexts, and the protocol behavior within each naming context can be

Huh?  How is this statement relevant to IDN?


>    different.  Hence applications and frameworks often encounter a
>    variety of behaviors and may or may not be designed to deal with
>    them.  See sections 2 and 3 of [RFC6055] for more discussion.
>
>    In summary, all this diversity can cause problems for each affected
>    entity, especially if a competitor does not have such a problem,
>    e.g., for browser vendors if competing browsers do not have the same
>    problems, or for an email server provider if competing server
>    providers do not have the same problems.
>
> A.3.  IPv6
...

>    Indeed, not until a few years after IPv4 runout in various Regional
>    Address Registry (RIR) regions did IPv6 deployment significantly
>    increase.  The RIRs and others conducted surveys of different
>    industries and industry segments to learn why people did not deploy
>    IPv6 [IPv6Survey2011] [IPv6Survey2015], which commonly listed lack of
>    a business case, lack of training, and lack of vendor support as
>    primary hurdles.  Arguably forward-looking companies collaborated
>    with ISOC on World IPv6 Day and World IPv6 Launch to jump start
>    global IPv6 deployment, and arguably their work gave vendors

What incentives did it give them?


>    incentives to support IPv6 well.  Key aspects of World IPv6 Day and
>    World IPv6 Launch that contributed to their successes were the
>    communication mechanism, and the measurement metrics and contingency
>    plans that were announced in advance.

As a case study it will help to describe what constituted success for 
these events and why those criteria were the right ones.


>    Several efforts have been made to mitigate the lack of a business
>    case.  Some governments (South Korea, Japan) provided tax incentives
>    to include IPv6.  Other governments (Belgium, Singapore) mandated
>    IPv6 support by private companies.  Few of these had enough value to
>    drive significant IPv6 deployment.
>
>    The concern about lack of training is often a common issue in
>    transitions.  Because IPv4 is so ubiquitous, its use is routine and
>    simplified with common tools, and it is taught in network training
>    everywhere.  While IPv6 deployment was low, ignorance of it was no
>    obstacle to being hired as a network administrator or developer.
>
>    Organizations with the greatest incentives to deploy IPv6 are those
>    which continue to grow quickly, even after IPv4 free pool exhaustion.
>
>
>
> Thaler                    Expires July 8, 2017                 [Page 15]
>
>
> Internet-Draft           Planning for Transition            January 2017
>
>
>    Thus, ISPs have had varying levels of commitment, based on the growth
>    of their user base, services being added (especially video over IP),

Really?  That makes theoretical sense, but what is the data to support it?


>    and the number of IPv4 addresses they had available.  Cloud-based
>    providers, including CDN and hosting companies, have been major
>    buyers of IPv4 addresses, and several have been strong deployers and
>    advocates of IPv6.

As an example, this fact mostly serves to highlight how difficult it is 
to figure who has what incentive.


>
>    Different organizations will use different transition models for
>    their networks, based on their needs.  Some are electing to use
>    IPv6-only hosts in the network with IPv6-IPv4 translation at the
>    edge.  Others are using dual-stack hosts with IPv6-only routers in
>    the core of the network, and IPv4 tunneled or translated through them
>    to dual-stack edge routers.  Still others are using native dual-stack
>    throughout the network, but that generally persists as an interim
>    measure: adoption of two technologies is not the same as
>    transitioning from one technology to another.  Finally, some walled
>    gardens or isolated networks, such as management networks, use
>    IPv6-only end-to-end.

Again, knowing that there is such variance highlights a problem but does 
not offer insight into dealing with it.


>
>    It is impossible to predict with certainty the path IPv6 deployment
>    will have taken when it is complete.  Lessons learned so far include
>    aligning costs and benefits (incentive), and ensuring incremental
>    benefit (network effect, or backward compatibility).
>
> A.4.  HTTP/2
>
>    HTTP/2 [RFC7540] is a new version of the popular HTTP protocol
>    [RFC7230].  The original versions of HTTP (0.9 [HTTP0.9], 1.0
>    [RFC1945], and 1.1 [RFC2616]) have only small differences; each
>    iteration made small improvements over the previous version without
>    making major changes.
>
>    The changes in HTTP/2 are largely aimed at improving performance.
>    The primary improvement is request multiplexing, which is supported

    is to


>    by request prioritization and flow control.  HTTP/2 includes
>    efficiency improvements with header compression [RFC7541] and binary
>    framing.
>
> A.4.1.  Bundling of Features with New Versions
>
>    The bundling of additional constraints on a new version of a protocol
>    could affect adoption by making the transition more costly.  However,
>    the transition to a new version also represents an opportunity to
>    improve multiple aspects of a protocol at the same time.
>
>    The HTTP working group decided that a new version of the protocol
>    represented an opportunity to improve security posture.  HTTP/2 is
>    much stricter about its use of TLS.  In particular, a long list of

"to improve security posture"? is a word missing?


>
>
>
> Thaler                    Expires July 8, 2017                 [Page 16]
>
>
> Internet-Draft           Planning for Transition            January 2017
>
>
>    TLS cipher suites are prohibited, constraints are placed on the key
>    exchange method, and renegotiation is prohibited.  These changes did
>    cause deployment problems.  Though most were minor and transitory,
>    disabling renegotiation caused problems for deployments that relied
>    on the feature to authenticate clients and prompted new work to
>    replace the feature.
>
>    A number of other features or characteristics of HTTP were identified
>    as potentially undesirable.  Several such features were considered
>    for removal during the design process.  This included trailers, the
>    1xx series of responses, certain modes of request forms, and the
>    unsecured (http://) variant of the protocol.  For each of these, the
>    risk to the successful deployment of the new version was considered
>    to be too great to justify removing the feature.  However, deployment
>    of the unsecured variant of HTTP/2 remains extremely limited.

I'm not understanding the basis for having the 'However' here.

How does that sentence connect with the preceding text?  For that 
matter, what is the 'unsecured variant'?


>
> A.4.2.  Planning for Replacement
>
>    HTTP/1.1 provides a mechanism, Upgrade, to transition to an entirely
>    different protocol.  That same facility was little used other than to
>    enable the use of WebSockets [RFC6455].  However, with performance
>    being a primary motivation for HTTP/2, a new mechanism was needed to
>    avoid spending an additional round trip on this negotiation.  A new
>    mechanism was added to TLS to permit the negotiation of the new
>    version of HTTP: Application Layer Protocol Negotiation (ALPN)
>    [RFC7301].  Upgrade was used only for the unsecured variant of the
>    protocol.

This highlights a problem with a mechanism that is put into a protocol 
'for future use' and without having adequate sense of how it will be 
used.  It tends not to work very well (or at all.)  This also happened 
with SNMP's original 'security' field.


>
>    ALPN was identified as the way in which future protocol versions
>    would be negotiated.  The mechanism was well-tested during
>    development of the specification, which proved that new versions
>    could be deployed safely and easily using ALPN.  Several draft
>    versions of the protocol were successfully deployed during protocol
>    development, and version negotiation was never shown to be an issue.
>
>    Confidence that new versions would be easy to deploy if necessary
>    lead to a particular design stance that might be considered unusual
>    in light of the advice in RFC 5218 [RFC5218], though is completely
>    consistent with RFC 6709 [RFC6709]: many of the ways in which the
>    protocol might be extended were removed unless an immediate need was
>    understood.  This decision was made on the basis that it would be
>    easier to revise the entire protocol than it would be to ensure that
>    an extension point was correctly specified and implemented such that
>    it would be available when needed.

This is far to important an observation to have it buried at the end of 
the appendix.



-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net

-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net