Subject: Re: [mile] New Version Notification for draft-murillo-mile-cps-00.txt

From: "Martin J. Murillo" <[email-masked]>
Date: Sun, 25 May 2014 18:38:17 -0400

Eric, Takahashi, Kathleen,

Thanks for the ideas and opinions.  The points you raise are important 
and definitely we want to be comprehensive while at the same time not 
reinventing the wheel. I think this will become clear in the next 
revision that is incorporating all the feedbacks we have received. The 
path to either option should be a rearrangement of elements, among 
others.  I expect to get it ready in two weeks.

Thanks again for the feedback.

Martin

    ---------- Forwarded message ----------
    From: Kathleen Moriarty <[email-masked]>
    To: Takeshi Takahashi <[email-masked]>
    Cc: "<[email-masked]>" <[email-masked]>, Eric Burger
    <[email-masked]>
    Date: Thu, 22 May 2014 09:52:56 -0400
    Subject: Re: [mile] New Version Notification for
    draft-murillo-mile-cps-00.txt
    +1

    Sent from my iPhone

     > On May 22, 2014, at 9:03 AM, "Takeshi Takahashi"
    <[email-masked] <mailto:[email-masked]>>
    wrote:
     >
     > Hi Eric and Martin,
     >
     > Thank you for your kind comment.
     > We will keep in mind that we should avoid having two things that
    do the same
     > thing.
     >
     > In my humble opinion, the CPS draft hands issues that are outside
    the scope
     > of the SCI draft.
     > I think the next version of the CPS draft will sort out lots of
    this type of
     > questions.
     >
     > Kind wishes,
     > Take
     >
     >
     >> -----Original Message-----
     >> From: mile [mailto:[email-masked]
    <mailto:[email-masked]>] On Behalf Of Eric Burger
     >> Sent: Thursday, May 22, 2014 4:56 AM
     >> To: [email-masked] <mailto:[email-masked]>
     >> Subject: Re: [mile] New Version Notification for
     >> draft-murillo-mile-cps-00.txt
     >>
     >> And I do not think the world is eager to have two things that do
    the same
     >> thing. We already have that problem in this space. I would suggest
     > adopting
     >> one and only one way of doing this. I have no opinion as to
    whether it
     > should
     >> be CPS or SCI.
     >>
     >> On May 9, 2014, at 7:17 AM, Takeshi Takahashi
     >> <[email-masked]
    <mailto:[email-masked]>> wrote:
     >>
     >>> Hi Martin,
     >>>
     >>> Thank you for your kind comments.
     >>>
     >>>> There's one question that still lingers: whether we should not
     >>>> re-utilize other extensions or use the IODEF-extension for
    structured
     >>>> cybersecurity (draft-ietf-mile-sci-11.txt). Ideas? I believe the
     >>>> points above would be applicable to both scenarios.
     >>>
     >>> I like this CPS draft, but I also like IODEF-SCI's framework
    (well, I
     >>> am one of the authors).
     >>> I do not want to be the obstacle of developing this interesting
    work,
     >>> so I do not have any intention to stick to IODEF-SCI at all.
     >>> But I would like to understand the pros and cons of not using SCI
     >>> framework for the CPS extension more vividly.
     >>>
     >>> Section 1.7 of the CPS draft explains the reason for not using the
     >>> IODEF-SCI's framework, but it was not so clear to me..
     >>> Can we discuss this issue when we have got example XML documents of
     >>> the CPS extension? (I guess later version of the CPS draft will
    have
     >>> the example XML
     >>> documents?) Then we can compare how the XML documents will look
    like
     >>> for each case of using and not using IODEF-SCI framework on the CPS
     >> extension.
     >>>
     >>> Kind regards,
     >>> Take
     >>>
     >>>
     >>>> -----Original Message-----
     >>>> From: Martin Murillo [mailto:[email-masked]
    <mailto:[email-masked]>]
     >>>> Sent: Wednesday, April 30, 2014 12:30 PM
     >>>> To: Takeshi Takahashi; [email-masked] <mailto:[email-masked]>
     >>>> Subject: Re: [mile] Fwd: New Version Notification for
     >>>> draft-murillo-mile-cps-00.txt
     >>>>
     >>>> Dear Takeshi,
     >>>>
     >>>> Thanks for the feedback and highlighting various extraneous
    elements
     >>>> which have rich IODEF equivalents. This makes the reporting
    lighter
     >>>> and decreases implementation overhead. I have answered to each
    item
     >> below.
     >>>>
     >>>> 1. The IncidentType element specifies whether the incident is
     >>>> accidental, on purpose, or theresult of other actions. The
    IncdntType
     >>>> attribute is missplaced. Thanks for taking notice of that.
    However I
     >>>> wonder whether the IncidentType element should be renamed. I
    think we
     >>>> agree that we need a field where whether the incident is
    accidental,
     >>>> on purpose, or undetermined can be placed. While the nature of the
     >>>> incident is rarely known immediately, there are instances in which
     >>>> the operator or other local party causes accidental instances;
    these
     >>>> instances might cause repercussions in other locations (i.e.
     >>>> balancing in
     >>> an electric grid).
     >>>>
     >>>> 2. I agree with you, the IncidentTilte element is a perfect
    candidate
     >>>> to go to a shallower level, especially when it will be the first
     >>>> variable that an operator or appropriate party reads.
     >>>>
     >>>> 3. Given that the IODEF:Contact class is rich enough to
    differentiate
     >>>> between a reporting party and an additional contact
     >>>> person/institution, I believe that we should use such class.
    Because
     >>>> the different stakeholders responsible for the Corporate Network,
     >>>> Control Servers, and Field Devices, this class might need to be
     >>>> extended. This is also relevant when the attack has taken place at
     >>>> any of those levels: For instance, the Corporate Network (or a
    false
     >>>> impersonator) might instruct the control room (Control
    servers) wrong
     >>>> setpoint configurations. Or the Control Network might experience a
     >>>> breach and setpoints altered in such servers. In extreme
    situations,
     >>>> the
     >>> attacks might be directly to the field devices. In each of
    those cases.
     >>>> In each of those cases the contact person might be one or more.
     >>>>
     >>>> 4, 5, 6. I think the IODEF classes can be indeed used. Thank
    you. The
     >>>> extension capabilities fo the System Class makes it quite
    appropriate
     >>>> to offer rich information.
     >>>>
     >>>> Regarding your last point, SFK should indeed be used instead
    of SFC.
     >>>>
     >>>> There's one question that still lingers: whether we should not
     >>>> re-utilize other extensions or use the IODEF-extension for
    structured
     >>>> cybersecurity (draft-ietf-mile-sci-11.txt). Ideas? I believe the
     >>>> points above would be applicable to both scenarios.
     >>>>
     >>>> Martin
     >>>>
     >>>>> On 4/23/2014 4:42 AM, Takeshi Takahashi wrote:
     >>>>> Hi Martin,
     >>>>>
     >>>>> I've read through the drafts. Thank you very much for sharing
    your
     >>>>> expertise here.
     >>>>> It was a new use case for me, and was really interesting.
     >>>>>
     >>>>> I am wondering if we can minimize the number of extension
    fields by
     >>>>> using the existing IODEF fields.
     >>>>> By minimizing the number of similar fields, I hope we can
    simplify
     >>>>> the draft and minimize the burden of implementations.
     >>>>>
     >>>>>> From this viewpoint, let me ask several checking questions.
     >>>>>
     >>>>> 1. IncidentType element and IncdntType Attribute
     >>>>>  What are the difference between them? I think your current draft
     >>>>> has them as place holders. I would like to hear a bit further.
     >>>>>
     >>>>> 2. The IncidentTitle element
     >>>>>  Can we use the Description element inside the IODEF:Incident
    class
     >>>>> for this purpose, instead of having new field here?
     >>>>>  It would be useful to have title or such information that
    can hint
     >>>>> the content of the IODEF document, but I feel like that it
    would be
     >>>>> helpful to have this type of information at the shallower
    level of
     >>>>> IODEF document rather than having it in the deeper level of IODEF
     >>>>> document (inside
     >>>>> additionalData)
     >>>>>
     >>>>> 3. The ReportingParty element
     >>>>>  Can we use the IODEF:contact class instead of having new field?
     >>>>> We could extend it further if needed.
     >>>>>
     >>>>> 4. The ReportReliability element
     >>>>>  Can we use the IODEF:confidence class instead of having new
    field?
     >>>>> We could extend it further if needed.
     >>>>>
     >>>>> 5. The TargetSystems element
     >>>>>  Can we extend the IODEF:system class instead of having new
    field?
     >>>>> We could extend it further if needed.
     >>>>>
     >>>>> 6. type attribute of the IODEF:Impact class
     >>>>>  When we use this extension, what value should be set for the
    type
     >>>>> attribute of the IODEF:Impact class?
     >>>>>
     >>>>> By the way, here are small questions.
     >>>>>
     >>>>> 1. should [SFC] be [SFK], since the acronym seems to come
    from the
     >>>>> initials of the authors of the reference (Stouffer, K.,
    Falco, J.,
     >>>>> and
     >>>> K. Scarfonw) ?
     >>>>>
     >>>>> I might have misunderstood your draft, so please correct me
    if I am
     >>> wrong.
     >>>>>
     >>>>> Kind regards,
     >>>>> Take
     >>>>>
     >>>>>
     >>>>>> -----Original Message-----
     >>>>>> From: mile [mailto:[email-masked]
    <mailto:[email-masked]>] On Behalf Of Martin
     >>>>>> Murillo
     >>>>>> Sent: Wednesday, January 29, 2014 10:11 AM
     >>>>>> To: Johnson, Blake; Jerome Athias
     >>>>>> Cc: [email-masked] <mailto:[email-masked]>
     >>>>>> Subject: Re: [mile] Fwd: New Version Notification for
     >>>>>> draft-murillo-mile-cps-00.txt
     >>>>>>
     >>>>>> Have read the links posted by Jerome and info on the Experience
     >>>>>> Sharing Tool (EST). It is my impression that a revision
    under the
     >>>>>> light of the EST would be very appropriate, and one of the first
     >>>>>> uses of the extension, given its report-based nature.  Look
    forward
     >>>>>> to seeing
     >>>>> the reviews in this light.
     >>>>>> As Jerome mentioned, focusing on referencing already existing
     >>>>>> taxonomies (and when necessary reusing them and referencing
    their
     >>>>>> xml implementations, if publicly available) would be the best
     >>>>>> approach; given the early stages in the field, I tend to
    think that
     >>>>>> atomic data will
     >>>>> need to be used.
     >>>>>> Regarding the term "Asset" vs "System", I believe system
    provides a
     >>>>>> more general connotation, while asset, seem to focus more on
     >>>>>> mainstream infrastructure; because the inclusion of IoT-related
     >>>>>> infrastructure (anywhere from centralized home control to
     >>>>>> self-driving cars), I wonder whether "Asset" is too an
    specific term.
     >>>>>>
     >>>>>> Martin
     >>>>>>
     >>>>>> Martin
     >>>>>>
     >>>>>>> On 1/24/2014 2:09 PM, Johnson, Blake wrote:
     >>>>>>> This is an interesting application of IODEF that I had not
     > considered.
     >>>>>> Most industry sharing that takes place in this space, from my
     >>>>>> perspective, is in the form of in person and telephone threat
     >>>>>> briefings. These are facilitated by the FBI, DHS, and the
    ISAC's.
     >>>>>>> At least a handful of the ISAC's have started sharing
    structured
     >>>>>>> threat
     >>>>>> indicator data, and the taxonomy for this extension could cover
     >>>>>> what the Electric Sector ISAC currently refers to as 'Experience
     >>> Sharing.'
     >>>>>> I can review this proposal as it relates to information
    captured by
     >>>>>> the ES-ISAC's Experience Sharing tool, using IEC/ANSI 62443
    (ISA99)
     >>>>>> as an informative reference.
     >>>>>>> Blake Johnson
     >>>>>>> Threat Intelligence Analyst
     >>>>>>> Alliant Energy | Infrastructure Secruity
     >>>>>>> Office: 608-458-6320 <tel:608-458-6320> | Cell:
    608-843-2790 <tel:608-843-2790>
     >>>>>>>
     >>>>>>>
     >>>>>>> -----Original Message-----
     >>>>>>> From: mile [mailto:[email-masked]
    <mailto:[email-masked]>] On Behalf Of Jerome
     >>>>>>> Athias
     >>>>>>> Sent: Friday, January 24, 2014 3:18 AM
     >>>>>>> To: [email-masked] <mailto:[email-masked]>
     >>>>>>> Cc: [email-masked] <mailto:[email-masked]>
     >>>>>>> Subject: Re: [mile] Fwd: New Version Notification for
     >>>>>>> draft-murillo-mile-cps-00.txt
     >>>>>>>
     >>>>>>> Hi,
     >>>>>>>
     >>>>>>> from what I know (which is limited), and as you mention,
    this ICS
     >>>>>>> area is often also called Critical Infrastructures (CIs),
    or SCADA
     >>>>>>>
     >>>>>>> for a little bit of background, we could explore the
    Cybersecurity
     >>>>>>> Framework Example references
     >>>>>>> http://www.nerc.com/pa/Stand/Pages/CIPStandards.aspx
    <http://www.nerc.com/pa/Stand/Pages/CIPStandards.aspx>
    http://www.ictqatar.qa/en/documents/download/National%20Industrial%20 <http://www.ictqatar.qa/en/documents/download/National%20Industrial%20>
     >>>>>> C
     >>>>>>> ontrol%20Systems%20Security%20Standard-English.pdf
     >>>>>>> ANSI/ISA-99.02.01-2009
     >>>>>>>
     >>>>>>> I don't have enough knowledge about the status and adoption
    of the
     >>>>>>> different efforts in term of XML
    representation/format/standards
     >>>>>>> http://xml.coverpages.org/emergencyManagement.html
    <http://xml.coverpages.org/emergencyManagement.html>
     >>>>>>> and resilience
     >>>>>>>
     >>>>>>> It would maybe be possible to obtain information from there
     >>>>>>> http://ics-cert.us-cert.gov http://ics-isac.org/
     >>>>>>>
     >>>>>>> My first feedback is that it looks like an interesting
    extension.
     >>>>>>>
     >>>>>>> I would suggest to focus on the reuse of existing
    Taxonomies, or
     >>>>>>> references to them.
     >>>>>>>
     >>>>>>> As such, for [Industry], maybe
     >>>>>>>
    http://www.census.gov/cgi-bin/sssd/naics/naicsrch?chart=2012
    <http://www.census.gov/cgi-bin/sssd/naics/naicsrch?chart=2012>
     >>>>>>> ISO 3166 (Country Codes)
     >>>>>>>
     >>>>>>>
     >>>>>>> [TargetSystems], I (personally) don't like the word
    "system" and
     >>>>>>> prefer
     >>>>>> "asset"
     >>>>>>> [CompromisedPhysicalInfrastrucute] (with a typo ;p) seems
    to be a
     >>>>>>> category of "Infrastructure" (or group of assets)
     >>>>>>>
     >>>>>>>
     >>>>>>> [EntryPoint] could be ok since it could be a little bit
    different
     >>>>>>> from "endpoint"
     >>>>>>>
     >>>>>>> [PerpetratingParty] seems to reference "Threat Actor" or
    "Threat
     >>>>>>> Agent" or "Attacker"
     >>>>>>>
     >>>>>>> [RecurrencePreventionMeasures] is this Security Controls? (and
     >>>>>>> Mitigations/Remediations)
     >>>>>>> Reference:
     >>>>
    https://web.nvd.nist.gov/view/800-53/control?controlName=AC-3&type=1
    <https://web.nvd.nist.gov/view/800-53/control?controlName=AC-3&type=1>
     >>>>>>>
     >>>>>>>
     >>>>>>> Describing an [Exploit] is not so easy (depending on the
    level of
     >>>>>>> details wanted/needed)
     >>>>>>>
     >>>>>>> Figure 1 (or "Diagram 1") is interesting, (of course it is
     >>>>>>> different from, i.e. CAESARS), it MAYBE could be more layered
     >>
    http://www.isa.org/InTechTemplate.cfm?template=/ContentManagement/Con <http://www.isa.org/InTechTemplate.cfm?template=/ContentManagement/Con>
     >>>>>> t
     >>>>>>> entDisplay.cfm&ContentID=94401
     >>>>>>>
     >>>>>>> (To follow: ENISA CDXI)
     >>>>>>>
     >>>>>>>
     >>>>>>> Some typos
     >>>>>>>
     >>>>>>>
     >>>>>>>
     >>>>>>> Next step: more XML focused ;)
     >>>>>>>
     >>>>>>>
     >>>>>>> My 2 bitcents
     >>>>>>>
     >>>>>>> 2014/1/24 Martin Murillo <[email-masked]
    <mailto:[email-masked]>>:
     >>>>>>>> Dear all,
     >>>>>>>>
     >>>>>>>> Please find below a link to a proposed draft for extending
    IODEF
     >>>>>>>> for the reporting of cyber-physical system incidents. These
     >>>>>>>> systems are often referred as  Operational Technology Systems,
     >>>>>>>> Industrial Control Systems, Automatic Control  Systems, or
    simply
     >>>>>>>> Control
     >>>> Systems.
     >>>>>>>>
     >>>>>>>> Cyber-Physical systems have been around for decades.  However,
     >>>>>>>> they are now at a higher risk to be  the target of attacks by
     >>>>>>>> individual highly-skilled attackers, organized groups,
     >>>>>>>> nation-states, or simply suffer repercussions of mainstream IT
     >>>>>>>> cyber-attacks. While over 90% of critical control system
     >>>>>>>> infrastructure is currently owned by private enterprises,
    these
     >>>>>>>> can have direct repercussions on national security of world
     >>>>>>>> nations.  Indeed, various of these systems are key parts of
     >>>>>>>> nuclear reactor facilities, transportation systems, electric
     >>>>>>>> power distribution, oil and natural gas distribution, health
     >>>>>>>> care, water
     >>>>>> and waste-water treatment, dam infrastructure, missile
     >>>>>>>> and defense systems, and others.   The disruption of these
    control
     >>>>>> systems
     >>>>>>>> could have a significant impact on public health, safety, and
     >>>>>>>> lead to large economic losses.
     >>>>>>>>
     >>>>>>>> Among the issues that catalyze this higher risk are:
     >>>>>>>>
     >>>>>>>> i) these systems are gradually becoming more
    interconnected, ii)
     >>>>>>>> legacy systems do not have proper cybersecurity
    protection, iii)
     >>>>>>>> the existence of highly-skilled individuals and
    motivations, iv)
     >>>>>>>> some these systems are generally considered critical, v) these
     >>>>>>>> are a natural extension of IT cyber-attacks, vi) the
    emergence of
     >>>>>>>> the Internet of Things (IOT), and vi) these attacks can be
     >>>>>>>> carried out
     >>>>>> remotely and quite inexpensively.
     >>>>>>>> While there might exist national approaches to deal with
     >>>>>>>> incidents, there's the need of a global international approach
     >>>>>>>> that will engulf governments, private organizations and other
     >>> stakeholders.
     >>>>>>>> IETF, as a leading global Internet standards organization,
    seeks
     >>>>>>>> to satisfy this need through open standards that seek to
     >>>>>>>> encompass issues that are critical for the global community.
     >>>>>>>>
     >>>>>>>> Feedback at two levels are welcome:
     >>>>>>>>
     >>>>>>>> 1. On the existence and inclusion either by utilizing any
    already
     >>>>> existing
     >>>>>>>> industry formats (XML- encoded) and/or by utilizing atomic
    data
     >>>>>>>> 2. Contributions on making the extension (and background
     >>>>>>>> information) more comprehensive, accurate and principally
    useful
     >>>>>>>> for the community
     >>>>>>>>
     >>>>>>>> Look forward to feedback and other input!
     >>>>>>>>
     >>>>>>>> Martin Murillo
     >>>>>>>>
     >>>>>>>> A new version of I-D, draft-murillo-mile-cps-00.txt has been
     >>>>>>>> successfully submitted by Martin Murillo and posted to the
    IETF
     >>>>>>>> repository.
     >>>>>>>>
     >>>>>>>> Name: draft-murillo-mile-cps
     >>>>>>>> Revision:       00
     >>>>>>>> Title:          IODEF extension for Reporting Cyber-Physical
     >> System
     >>>>>>>> Incidents
     >>>>>>>> Document date:  2014-01-21
     >>>>>>>> Group:          Individual Submission
     >>>>>>>> Pages:          24
     >>>>>>>> URL:
     >>
    http://www.ietf.org/internet-drafts/draft-murillo-mile-cps-00.txt
    <http://www.ietf.org/internet-drafts/draft-murillo-mile-cps-00.txt>
     >>>>>>>> Status:
     >>>>>> https://datatracker.ietf.org/doc/draft-murillo-mile-cps/
    <https://datatracker.ietf.org/doc/draft-murillo-mile-cps/>
     >>>>>>>> Htmlized:
     >>>> http://tools.ietf.org/html/draft-murillo-mile-cps-00
    <http://tools.ietf.org/html/draft-murillo-mile-cps-00>
     >>>>>>>>
     >>>>>>>>
     >>>>>>>> Abstract:
     >>>>>>>>   This draft document will extend the Incident Object
    Description
     >>>>>>>>   Exchange Format (IODEF) defined in [RFC5070] to support the
     >>>>>> reporting
     >>>>>>>>   of incidents dealing with attacks to physical infrastructure
     >>>>> through
     >>>>>>>>   the utilization of IT means as a vehicle or as a tool.
      These
     >>>>> systems
     >>>>>>>>   might also be referred as Cyber-Physical Systems (CPS),
     >>>> Operational
     >>>>>>>>   Technology Systems, Industrial Control Systems, Automatic
     >>>> Control
     >>>>>>>>   Systems, or simply Control Systems.  These names are used
     >>>>>>>>   interchangeably in this document.  In this context, an
     >>>>>>>> incident
     >>>> is
     >>>>>>>>   generally the result of a cybersecurity issue whose main
    goal
     >>>>>>>> is
     >>>>>> to
     >>>>>>>>   affect the operation of a CPS.  It is considered that any
     >>>>>>>>   unauthorized alteration of the operation is always
    malign.  This
     >>>>>>>>   extension will provide the capability of embedding
    structured
     >>>>>>>>   information, such as identifier- and XML-based information.
     >>>>>>>> In
     >>>> its
     >>>>>>>>   current state, this document provides important
    considerations
     >>>> for
     >>>>>>>>   further work in implementing Cyber-Physical System incident
     >>>>>> reports,
     >>>>>>>>   either by utilizing any already existing industry
    formats (XML-
     >>>>>>>>   encoded) and/or by utilizing atomic data.
     >>>>>>>>
     >>>>>>>>   In addition, this document should provide appropriate
    material
     >>>> for
     >>>>>>>>   helping making due considerations in making an appropriate
     >>>> decision
     >>>>>>>>   on how a CPS reporting is done: 1) through a data format
     >>>>>>>> extension
     >>>>>> to
     >>>>>>>>   the Incident Object Description Exchange Format
    [RFC5070], 2)
     >>>>>> forming
     >>>>>>>>   part of an already existing IODEF-extension for structured
     >>>>>>>>   cybersecurity information (currently draft
     >>>>>>>>   draft-ietf-mile-sci-11.txt), or others.  While the
    format and
     >>>>>>>>   contents of the present document fit more the earlier
    option,
     >>> these
     >>>>>>>>   can also be incorporated to the later.
     >>>>>>>>
     >>>>>>>>
     >>>>>>>>
     >>>>>>>> Please note that it may take a couple of minutes from the
    time of
     >>>>>>>> submission until the htmlized version and diff are
    available at
     >>>>>> tools.ietf.org <http://tools.ietf.org>.
     >>>>>>>> The IETF Secretariat
     >>>>>>>>
     >>>>>>>>
     >>>>>>>>
     >>>>>>>>
     >>>>>>>>
     >>>>>>>> _______________________________________________
     >>>>>>>> mile mailing list
     >>>>>>>> [email-masked] <mailto:[email-masked]>
     >>>>>>>> https://www.ietf.org/mailman/listinfo/mile
    <https://www.ietf.org/mailman/listinfo/mile>
     >>>>>>> _______________________________________________
     >>>>>>> mile mailing list
     >>>>>>> [email-masked] <mailto:[email-masked]>
     >>>>>>> https://www.ietf.org/mailman/listinfo/mile
    <https://www.ietf.org/mailman/listinfo/mile>
     >>>>>> _______________________________________________
     >>>>>> mile mailing list
     >>>>>> [email-masked] <mailto:[email-masked]>
     >>>>>> https://www.ietf.org/mailman/listinfo/mile
    <https://www.ietf.org/mailman/listinfo/mile>
     >>>
     >>> _______________________________________________
     >>> mile mailing list
     >>> [email-masked] <mailto:[email-masked]>
     >>> https://www.ietf.org/mailman/listinfo/mile
    <https://www.ietf.org/mailman/listinfo/mile>
     >
     >
     > _______________________________________________
     > mile mailing list
     > [email-masked] <mailto:[email-masked]>
     > https://www.ietf.org/mailman/listinfo/mile
    <https://www.ietf.org/mailman/listinfo/mile>

    _______________________________________________
    mile mailing list
    [email-masked] <mailto:[email-masked]>
    https://www.ietf.org/mailman/listinfo/mile
    <https://www.ietf.org/mailman/listinfo/mile>