Subject: [lmap] On Management, Privacy and Use Case Points

From: James Miller <[email-masked]>
Date: Tue, 20 Nov 2012 13:00:43 -0500

DISCLAIMER:  The opinions expressed are those of the author and do not
necessarily represent the views of the Federal Communications Commission or
the United States Government.   or necessarily co-authors or others on the
list!

Barbara / Nick,

Thanks for everyone's discussions.  I wanted to chime in on some related
points that seem to have congealed.  IMHO, the first three points relate
more to operational concerns for implementing a LMAP program and go to
scope of IPPM and LMAP.  The point on metrics would be a good topic of an
IPPM-directed draft.  If I misunderstand any of the points quoted in these
chains below please clarify but I've picked up the following topics:

1) No large-scale management is necessary to collect metrics
2) No carrier or other's business case requires large scale management
standard
3) Privacy concerns do not permit large scale management
4) Metrics are largely sufficient or within scope of IPPM.

1) Management is Relevant to Evaluating the Quality of Data Collected.

Barbara references some sources for "speed data" available to consumers and
Nick Weaver also chimed on his great work.  The FCC view, perhaps shared by
others, is that data collected from a managed platform provides a basis for
making comparisons of broadband providers performance and supports an
evaluation of offerings.  Where the technical conditions and methods of the
tests (maybe defined as metrics) are executed by parties committed (and
audited) to act in good faith in methodologically sounds ways, the data
produced is useful for consumers, academics, and broadband providers for
many purposes, including for the FCC's review of the state of consumer
broadband performance.  Thus understanding the architecture and how it
supports the collection of metrics I think is something people care deeply
about, and a focus solely on "metrics" without understanding the platform
is flawed.  The distinctions being asserted between metrics and
architecture dissolve when we scrutinize the conditions defining accuracy
and precision for performance measurements.  You can't expect to use a
kindergarten 12" ruler for all purposes or expect what they taught you in
kindergarten as process would be sufficient for every measurement case, and
the case holds for broadband measurement. </humour>

Data that isn't managed and subjected to scrutiny presents undefined
conditions, and may not be suitable for many analytic purposes.
 Collections that I am aware of that are widely referenced employ some
management structure and this effort is to explore how
the architectures could be standardized to reduce the costs and burdens of
scaling programs.  For FCC purposes we subject collected results to
significant review in preparing our reports that have documented consumer
fixed broadband performance over the last two years.  In the LMAP draft
we've put down some of the major conditions that were relevant in the FCC
studies, control of the test schedule, protection of customer privacy, etc.
 Implementation as a "federated" or other architecture is an issue of who
schedules tests and collects the data, and as the draft states, is only one
of several scenarios but in the least *requires* authentication and other
management functions in the platform.

Nick makes the point that protocols may be an easier problem than metrics,
but wanted to pull out he implements three architectural management
structures "depending on whether quick & easy or server side or mutual
authentication is require[d]."  So maybe extending the point, the LMAP
structure would at minimum support three classes of client server
authentication:  Light and Easy (L&E), Server Side (SS), and Mutual
Authentication (MA).  I don't agree that you can ignore the problem with a
focus on metrics as the same problems with then pop up with how the tests
are implemented, and the same problems will occur across tests,
demonstrating that there's a modularity in design that needs to be
leveraged.

:: Standards around LMAP offer benefits such as reducing costs of
components and management, and may otherwise be essential to scaling
large-scale measurement to larger numbers.  As a baseline, do we agree on
the cost and burden reducing benefit of standards generally, and that a
standard around LMAP would reduce costs and make scalablity of
large-scale measurement more feasible for the categories of users defined
in the document?

2) Performance Measurement is a Developing Business Requirement.

Prior to the FCC program that began in 2010, we are aware that several
broadband providers of consumer broadband services were contracting for
technical solutions substantially similar or identical to the ones we
contracted for in the FCC program but I can't speculate what carriers had
some sort of similar measurement program in place.   On the questions about
how relevant large-scale measurement is for the industry, I would suggest
that there's plenty of evidence of adoption of "LMAP" style programs in the
US prior to the FCC program, and interest has only grown both in the US and
Internationally.

For the FCC program, 13 national ISPs providing residential fixed service
to consumers comprising 85% of the US market are tested and participate in
the program.  These companies were signatories to the Code of Conduct and
regularly participate in meetings and other aspects of the program.  For
reference, signatories to the 2012 Code of Conduct were Adtran, AT&T,
Cablevision, CenturyLink, Charter, Comcast, Corning, Cox, Fiber to the Home
Council,  Frontier, Georgia Tech, Genband, Insight (by TWC), Internet
Society, Mediacom, Motorola, Qwest, Time Warner Cable, US Telecom, Verizon,
Viasat and Windstream.

I cannot speak to the specifics of carrier's independent broadband
performance efforts but there are references in the press and national
advertising that indicate that carriers do employ programs like those
described in the LMAP draft.  LMAP should support many use cases, including
the cases described in section 2 of the draft at a minimum, but the three
discussed have been industry, regulator and researcher lead efforts.  That
there is established, strong interest in broadband metrics from industry,
academia and researchers, and regulators seems well founded, in any event.

http://transition.fcc.gov/cgb/measuringbroadbandreport/2012/Technical-Appendix.pdf
http://transition.fcc.gov/cgb/measuringbroadbandreport/technical_appendix/Technical_Appendix_Full.pdf

3) Privacy is Crucially Important and Can Be Protected.

Without straying from the technical focus of the list, let me first say
that privacy issues are a serious topic that everyone in the field takes
very seriously, but that they need not preclude a well conceived and
*managed* program.  While a best-practice list might be helpful in some
fora, I think it's sufficient here to discuss how to ensure that the
technical pieces are capable of enforcing whatever data integrity policy an
implementor may adopt.  This is not the correct forum to define a
monolithic privacy policy, but is a good place to discuss the resiliency of
approaches to protecting a variety of policies, IMHO.  The draft observes
that existing authentication protocols and approaches could be adopted for
LMAP.

Barbara referenced US and EU law specifically, but I'd point out that in
the FCC program, governed by US law, the terms and conditions that
volunteers agree to were crafted after much review that incorporated the
input of many stakeholders, and worked together with other mechanisms to
protect privacy.  The FCC is conducting a review of the existing privacy
components for the mobile program and I would believe that any large-scale
program would likely tailor the specifics of a privacy strategy to the
specifics of the particular program and nature of the data to be collected.

4) Broadband Performance Metric Needs are Diverse and Growing.

While Ping tests are valuable, there are limits to the value of ICMP ping
for measurement purposes, but it's clear that hundreds of thousands of
consumers expressed interest in volunteering to be a part of the FCC
efforts and other parties discussing consumer interest in more detailed
broadband statistics support a clear demand for data in this area. The
FCC's panel of U.S. broadband subscribers is drawn from a pool of over
145,000 volunteers following an ongoing recruitment campaign that ran from
May 2010 through February 2012.  As we discussed in the BOF, it was the
FCC's view,  largely confirmed by the participation and results of the
study and echoed by other regulators globally, researchers like those
supporting M-LAB, and other stakeholders, that more information about
broadband performance is valuable, in many cases necessary, and has been
insufficient.

</lunchbreak>

 [combing threads referenced above]

On Wed, Nov 14, 2012 at 5:20 PM, STARK, BARBARA H <[email-masked]> wrote:

> Shane suggested that the draft is a good start and asked me to provide
> comments against it. I've been avoiding doing that, because I'm not very
> fond of this draft, and am not sure if it can be "fixed", or if it should
> be completely overhauled, or totally scrapped. But others apparently do
> like it, so let me explain some of my objections to the current draft.
>

[Barbara's email was the start for much of the following discussion and
included specifics spurred discussion of the topics above]

On Tue, Nov 20, 2012 at 9:16 AM, STARK, BARBARA H <[email-masked]> wrote:

>
> > [--snip--]
> > > Data collector: I do not see this as a necessary architectural
> element, either.
> > > As with the Measurement controller, it has been assigned the role of
> > > providing multiple, separable functions: collecting data, storing
> data, and
> > > providing access to the data.
> >
> > I'm not sure I understand your concern.  Given the resource constraints
> on
> > some classes of measurement clients, doesn't it make sense for the
> > measurement client to send it's performance measurement results to "the
> > cloud" (a.k.a.: data collector) for longer-term archival, storage and
> centralized
> > access by the ISP and/or 3rd-parties?
>
> <bhs> For the end user on-demand tests, I don't see that a distinct data
> collector necessarily needs to exist. The Measurement Client could present
> collected data to the end user directly through a local user interface. The
> end user may or may not want to have the data saved for future use. The end
> user may not have a requirement for on-demand test data to be shared with
> others. Also, since the LMAP Data Collector definition insists that many
> functions be combined together (data collection function, data storage
> function, and providing access to the data function), I do not agree that
> this combined-function Data Collector architectural element, as defined in
> the draft, is necessary to providing functionality that some of the use
> cases do call for. I agree that a data collection function, a data storage
> function, and a data access function are needed by some of the use cases. I
> believe it is possible for data collection and storage functions to be
> internal to a single entity's
>   management architecture, and am not convinced that deployers and
> implementers of these functions are asking for IETF help in defining them.
>
> > > Network parameter server: I do not see this as a necessary
> architectural
> > element. If there is a need for an externally-facing function that
> provides
> > access to access-provider-collected data for the regulatory use case to
> > include corresponding (anonymous) information related to subscribed line
> > rate, etc., then that is a requirement on that external-facing function.
> If an
> > access provider wants help in figuring out how to get this information
> to the
> > external-facing function, then I would prefer for that access provider
> (or
> > their proxy) to ask for such help.
> >
> > I would think that if, say, an ISP already has a "network parameter
> server"
> > they already own & operate, then that's fine ... they can continue to
> run it as
> > they do today.  However, the key aspect we probably want to work on is
> > defining a _standards-based_ "data model" (e.g.: XML or JSON schema?)
> > that can encapsulate appropriate/relevant bits of data about subscribed
> lines
> > in that (existing) Network Parameter Server.  This would allow for much
> > more straightforward access to and parsing of "network parameters" by,
> for
> > example, 'authorized parties' as the draft states (Section 3.4).
>
> <bhs> I don't object to data model definition. I do think it may be
> premature, in the absence of a good understanding of the metrics. Without
> understanding the metrics, I believe the data model would need to be very
> abstract. Metrics, to me, could include an expression of "subscribed line
> rate" that has consistent meaning across all access technologies. This
> information is something I would consider a "network parameter". I would
> prefer to see IETF focus on metrics, rather than a measurement management
> and control architecture. Metrics can drive a data model that is
> independent of the architecture used to deliver the data.
>
> > > If there is a desire to define an interworking function that would
> allow a 3rd
> > > party to get (not anonymous) customer-specific line information
> directly
> > > from the access provider (so the 3rd party could correlate it with
> data they
> > > collect from their own Measurement client(s)), then that would be a
> distinct
> > > function, as well. Personally, I would shy away from trying to define
> this
> > > function. But if someone else wants to tackle it, I might be willing
> to provide
> > > comments on it.
> >
> > Hrm.  You raise a good point above about a 3rd-party acquiring "non-
> > anonymous" customer line information from the access provider so that the
> > 3rd-party could correlate it with data they collect from their own
> (3rd-party)
> > measurement clients.
> > 1)  I'm not sure what, if any, technical mechanisms the IETF could
> develop to
> > prevent such a thing from happening, other than to NOT specify any data-
> > models/schemas that encapsulate such sensitive, non-anonymous
> > information in a 'standards-based' data-model in the first place.
> > 2)  That said, I would think that "privacy laws" in place in the U.S.
> and other
> > parts of the world (perhaps most significantly, the EU) would prevent the
> > ISPs from [ever] offering access to that data for fear of violating both
> the law
> > and, more importantly, their customer's trust as well.
>
> <bhs> I'm not aware of any access provider who *wants* to do this. I
> couldn't quite tell if some of the requirements were trying to provide
> support for this use case -- I could read some of the statements either
> way. I'm glad we agree that this is not a use case that we need to support.
> Barbara
> _______________________________________________
> lmap mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/lmap
>

On Mon, Nov 19, 2012 at 5:12 PM, STARK, BARBARA H <[email-masked]> wrote:

> > > Measurement controller: This is not a necessary architectural element.
> This
> > > is an element specific to this proposed physical architecture.
> >
> > I'm unclear if your concern is related to:
> > 1) having _strictly_ a single measurement controller be part of, or in
> control
> > of a single measurement "panel" (e.g.: group of measurement clients &
> > measurement server); or,
> > 2) two, or more, measurement controllers (likely owned/operated by
> > different parties) acting in concert to coordinate the rendezvous
> between an
> > appropriate panel of measurement clients with measurement servers.  See
> > my previous e-mail re: "Section 3" for an example of what I'm trying to
> > describe here.
> >
> > If neither of those are what concern you, can you point me in the right
> > direction?  :-)
>
> <bhs> Measurement Controllers are not required by all use cases (e.g., end
> user on-demand testing that is controlled and managed by the end user,
> using devices under the direct control and management of the end user,
> doesn't call for the existence of a Measurement Controller).
> I do not find the use case of allowing 3rd party management and control of
> test infrastructure to be a compelling use case. IMO, this is not a
> necessary function of any of the more general use cases for support of
> end-user specific on-demand testing and large scale performance
> measurements.
> Outside of this 3rd party use case, none of the other use cases really
> care about how control is achieved -- it's a function internal to an
> architecture of a single entity. And as I mentioned in my other emails, not
> all Measurement Clients or Measurement Servers need to allow for
> measurement-specific remote control.
> We have no clue as to what the desired metrics are, or the recommended
> measurements and tests to achieve those metrics; so assuming a Measurement
> Controller is needed to coordinate any of these tests is premature.
> Therefore, I don't consider it to be a necessary element of an architecture.
> Barbara
> _______________________________________________
> lmap mailing list
> [email-masked]
>
https://www.ietf.org/mailman/listinfo/lmap

On Tue, Nov 20, 2012 at 11:01 AM, Nicholas Weaver <[email-masked]
> wrote:

>
> On Nov 20, 2012, at 7:31 AM, STARK, BARBARA H wrote:
> >> -----Original Message-----
> >> From: Marc Linsner [mailto:[email-masked]]
> >> As far as metrics, my assumption is any metric defined by IPPM or
> related
> >> SDO body, with additions as desired. From the plenary presentation I
> would
> >> expect at least the following metrics: Sustained Download, Sustained
> Upload,
> >> Web Browsing Download, UDP Packet Loss, VoIP Measure, DNS Failures,
> >> ICMP Packet Loss, Total Bytes Downloaded, Burst Download, Burst Upload,
> >> UDP Latency, Video Streaming Measure, DNS Resolution, Latency Under
> >> Load, Total Bytes Uploaded.  Obviously, extensibility is a key feature.
> >
> > <bhs> How key is extensibility, how dynamic does extensibility have to
> be, and are various approaches to achieving extensibility allowed? Can
> extensibility be achieved by firmware upgrades that happen maybe once a
> year? Do all clients and servers have to be extensible, or is it ok to
> achieve extensibility through the addition of new clients and servers,
> potentially in new/different/separate physical devices/elements? Does
> extensibility imply near infinite extensibility or is it reasonable for
> extensibility to be constrained by lack of resources available on the
> device that hosts a client?
> > Barbara
>
> I've said it once, I'll say it one final time:
>
> This focus on architecture is deeply misguided.  As someone who's built
> one such architecture (Netalyzr), working on two others (Fathom, a browser
> extension, and techniques using GuruPlugs/Raspberry Pis), the architecture
> is the easy part.
>
> In all this work, having some "standard" way to communicate between my
> measurement clients and servers is useless.  I just use HTTP, HTTPS, or SSH
> depending on whether quick & easy or server side or mutual authentication
> is required, with whatever load-balancing is needed handled by random
> assignment of remote test node.
>
> The internal data store is whatever is appropriate for the project (eg.
> for Netalyzr its python pickled objects for storage on our web server, data
> in a Postgress database for analysis).
>
> Updates are handled appropriately (Netalyzr is updateless, its an applet
> so its always up-to-date.  Our android version will just use the app store
> update mechanism.  Fathom we use Firefox's update mechanism.  The plugs are
> a hack using SSH, but its a fair amount of custom goop, and they update
> nightly).
>
> And all three end up having rather different architectural requirements.
>
>
>
> The hard part is developing the test metrics and measurements, both in the
> abstract and within the API constraints of the target platform.  E.g. why I
> like the GuruPlugs and Raspberry Pi is that I can run Java, so therefore I
> can just "Run Netalyzr" for all Netalyzr tests.  But the same isn't the
> case for the Ripe Atlas or Bismark platform.
>
> And Marc's list is actually just a start: you also have generic proxy
> presence & location detection, application specific proxy detection and
> analysis, packet injection detection, differential application behavior
> detection, application agnostic traffic shaping detection, DNSSEC support,
> DNS manipulation detection, path MTU, IPv6 for all of the previous, and a
> ton of others.  Netalyzr is currently composed of >100 distinct tests.  And
> this amount just continues to grow.
>
>
> If the IETF actually wants to have an impact in this area, don't bother
> focusing on protocols for communication, focus on tests with given
> attributes.  Because people like me who actually build these things are
> going to ignore an architectural focus because that has no value.  But
> having ACCEPTED STANDARD tests would be very valuable.
>
> E.g. a good, standard latency-under-load test that can be written in Flash
> (so TCP/UDP connections only to cooperating servers) would be great.  Our
> current one in Netalyzr is only OK: we believe that one could do a lot
> better.
>
> If you could then figure out WHERE the bottleneck is (using a server that
> can also do simultaneous traceroutes), this would be even more valuable.
>
> _______________________________________________
> lmap mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/lmap

On Mon, Nov 19, 2012 at 1:58 PM, STARK, BARBARA H <[email-masked]> wrote:

>  [--snip--]
> > > Here are some specific comments on the architectural elements:
> > > Measurement client: I agree that if measurements (active or passive)
> are
> > > going to be made, then one or more Measurement clients are a mandatory
> > > element. I agree with the first 3 sentences of the Measurement client
> > > definition.
> >
> > Well 3 out of 4 (sentences) is a good start. :-)
> >
> >
> > > But the idea that *all* Measurement clients must be manageable and
> > > "provide for communications within different network segments" is not
> > > something I agree with.
> >
> > I'm not sure I detect an implication that all measurement clients must be
> > manageable.  What the fourth sentence says is the following:
> > "Client measurement functionality must be implementable in a variety of
> > user contexts ..."
>
> <bhs> As I mentioned, I thought it was possible to agree on the existence
> of a Measurement Client (as defined by the first 3 sentences) as an
> architectural element. The problem really arises with the assumptions as to
> the nature of this element that are implied by certain of the requirements:
>
>    A-2:  Measurement clients and servers MUST support an extensible set
>       of performance metrics.
>    A-4:  Measurement clients MUST be able perform both active and
>       passive measurements.
>    M-3:  A measurement client MUST be able to register with the data
>       collection platform automatically, announcing its availability and
>       relevant system parameters.  (For example, a cable or DSL modem
>       may indicate its make and model number.)
>    M-4:  A measurement client MUST be able to declare what kind of
>       measurements it can perform, e.g., by enumerating a set of
>       measurement identifiers.
>    C-4:  A measurement client MUST be able to authenticate and authorize
>       the measurement controller.
>
> As I mentioned in my last email, I believe Measurement Clients may exist
> inside ONTs, DSLAMs, and even very, very simple DSL modems (some of which
> are nothing more than a USB dongle that connects to a PC, and many of which
> are completely unmanaged, except locally by the end user). The idea that
> these devices / network elements must support these requirements in order
> to participate in a holistic scheme/architecture to collect meaningful
> performance data is something I do not agree with. I also believe that it
> is possible for a Management Client to be directly under the control of the
> end user, and potentially not be upgradable or capable of an extensible set
> of tests. I believe that the Windows Command Prompt is a very effective
> (for me) end-user-controlled Measurement Client for performing a variety of
> tests. But it does not meet the above requirements. Nor should it be
> expected to. I use it often, though, for my on-demand connectivity and
> performance testing.
>
> To me, this architecture draft assumes that a "federated" architecture is
> necessary for useful collection of performance measurements and conducting
> tests. I disagree with that premise. There also seems to be an assumption
> that a "federated" architecture must be defined prior to defining
> appropriate metrics. I disagree. I believe that a federated architecture
> (that allows for all sorts of management and control and updating of
> tests/schedules/etc.) is unnecessary. I believe it is possible to re-use a
> lot of what exists, with minimal additions, to accomplish large scale
> performance testing and on-demand diagnostics, that meet the basic "needs"
> (not to be confused with "wants") of various parties. I believe it is
> possible for 3rd parties and ANPs to develop one-to-one relationships with
> an end user, to allow for on-demand and scheduled testing and collection of
> test data. The end user can even allow for 3rd parties to access tools
> under end-user control, which interact with ANP
>   Measurement Servers (taking advantage of the end user to ANP
> relationship). For large scale performance data -- I believe it is possible
> to collect such data and provide access to the resulting anonymized data
> without enabling 3rd party management and control of the elements involved
> in data collection.
>
> My recommendation would be to focus on defining appropriate metrics. Once
> we understand the metrics, we can work on understanding the appropriate
> measurements and tests, and the set of Measurement Clients and Measurements
> Servers that could be used to perform those measurements and tests. If
> something else is needed from a standards organization, that should become
> evident once the metrics are identified.
> Barbara
> _______________________________________________
> lmap mailing list
> [email-masked]
>
https://www.ietf.org/mailman/listinfo/lmap

On Mon, Nov 19, 2012 at 4:52 PM, STARK, BARBARA H <[email-masked]> wrote:

> [...]
>
> This architecture seems to imply that it's relevant to the end user
> on-demand test case. My favorite test is "ping". I do my ping testing
> against a variety of Internet websites, but also my access/Internet
> provider's DNS servers and IP gateways. What I ping depends on what my
> problem is. Anything that responds to my ping is a Measurement Server in my
> book.
>
> As an end user, I have no need for the set of tests that such Measurement
> Servers support.
> I also have no need for my client to authenticate with them. I don't think
> they've ever required authentication of my client. I have no idea if they
> communicate with a Data Collector, and I really don't care.
>
> Similarly, I often use "bandwidth test" websites for on-demand bandwidth
> tests. I really don't care whether they're extensible, authentication has
> never been an issue, and I have no requirement for them to communicate with
> a Data Collector
>
> > ---snip---
> > The following requirements are applicable to the overall LMAP Reference
> > Architecture, as described in this document.  How each of these
> > requirements are applied to specific implementation of a particular type,
> > category or class of measurement client, server, etc. device is
> out-of-scope
> > for this document.
> > ---snip---
> > Is the above text good enough, for now?
>
> <bhs> No. Unless the described architectural elements are changed to be
> "LMAP Measurement Client" and "LMAP Measurement Server", with definition of
> these being that an LMAP Measurement Client/Server is one that meets the
> requirements enumerated in this document. I don't think it's possible to go
> from the generic architecture elements of Measurement Client/Server to the
> enumerated requirements that seem to have something very specific in mind
> that is not at all consistent with the generic definitions provided in the
> architecture section.
>
> > But, going back to Section 3.2, Measurement Server, I can see how it may
> be
> > useful to add some of the points you raised above.  How about suggesting
> to
> > add something like the following to Section 3.2?
> > ---snip---
> > Measurement servers likely will be owned and operated by a variety of
> > administrative entities, some of which may be unrelated to the ISP
> providing
> > service to a measurement client.  Therefore, measurement servers may
> > need a facility where they can describe their capability to perform one,
> or
> > more, suites of active performance measurement tests to a measurement
> > controller. In this way, the measurement controller may facilitate
> > coordination of measurement clients to measurement servers that have
> > matching active performance measurement capabilities.
> > ---snip---
>
> That still doesn't allow for a website that responds to a ping to be
> considered a Measurement Server. Or a website that provides bandwidth
> measurements. But they are Measurement Servers. They just aren't
> Measurement Servers that meet these "LMAP" requirements. Do any of the use
> cases create a need for all Measurement Servers (used by that use case) to
> meet these requirements? I don't think so. Even the 3rd party testing use
> case should allow for ping tests without insisting that the server
> supporting the ping tests meet these requirements.
>
> This LMAP architecture is assuming that a requirement of the architecture
> is to support all use cases, within a single architecture. I disagree with
> that premise.
> And I disagree that 3rd party management and control of "LMAP"
> architecture elements is a compelling use case. The protocols may be
> simple, but it's incredibly complex to manage and administer, and to put in
> all the controls needed to prevent end users from being negatively impacted
> by 3rd parties. A simple requirement of "make sure 3rd parties can't break
> anything" is insufficient and ignores the fact that ensuring this is
> incredibly complex and difficult.
> Barbara
> _______________________________________________
> lmap mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/lmap
>