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

["Martin J. Murillo" <[e-mail]>]

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 <[e-mail]>
    To: Takeshi Takahashi <[e-mail]>
    Cc: "<[e-mail]>" <[e-mail]>, Eric Burger
    <[e-mail]>
    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"
    <[e-mail] <mailto:[e-mail]>>
    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:[e-mail]
    <mailto:[e-mail]>] On Behalf Of Eric Burger
     >> Sent: Thursday, May 22, 2014 4:56 AM
     >> To: [e-mail] <mailto:[e-mail]>
     >> 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
     >> <[e-mail]
    <mailto:[e-mail]>> 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:[e-mail]
    <mailto:[e-mail]>]
     >>>> Sent: Wednesday, April 30, 2014 12:30 PM
     >>>> To: Takeshi Takahashi; [e-mail] <mailto:[e-mail]>
     >>>> 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:[e-mail]
    <mailto:[e-mail]>] On Behalf Of Martin
     >>>>>> Murillo
     >>>>>> Sent: Wednesday, January 29, 2014 10:11 AM
     >>>>>> To: Johnson, Blake; Jerome Athias
     >>>>>> Cc: [e-mail] <mailto:[e-mail]>
     >>>>>> 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:[phone]> | Cell:
    608-843-2790 <tel:[phone]>
     >>>>>>>
     >>>>>>>
     >>>>>>> -----Original Message-----
     >>>>>>> From: mile [mailto:[e-mail]
    <mailto:[e-mail]>] On Behalf Of Jerome
     >>>>>>> Athias
     >>>>>>> Sent: Friday, January 24, 2014 3:18 AM
     >>>>>>> To: [e-mail] <mailto:[e-mail]>
     >>>>>>> Cc: [e-mail] <mailto:[e-mail]>
     >>>>>>> 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 <[e-mail]
    <mailto:[e-mail]>>:
     >>>>>>>> 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
     >>>>>>>> [e-mail] <mailto:[e-mail]>
     >>>>>>>> https://www.ietf.org/mailman/listinfo/mile
    <https://www.ietf.org/mailman/listinfo/mile>
     >>>>>>> _______________________________________________
     >>>>>>> mile mailing list
     >>>>>>> [e-mail] <mailto:[e-mail]>
     >>>>>>> https://www.ietf.org/mailman/listinfo/mile
    <https://www.ietf.org/mailman/listinfo/mile>
     >>>>>> _______________________________________________
     >>>>>> mile mailing list
     >>>>>> [e-mail] <mailto:[e-mail]>
     >>>>>> https://www.ietf.org/mailman/listinfo/mile
    <https://www.ietf.org/mailman/listinfo/mile>
     >>>
     >>> _______________________________________________
     >>> mile mailing list
     >>> [e-mail] <mailto:[e-mail]>
     >>> https://www.ietf.org/mailman/listinfo/mile
    <https://www.ietf.org/mailman/listinfo/mile>
     >
     >
     > _______________________________________________
     > mile mailing list
     > [e-mail] <mailto:[e-mail]>
     > https://www.ietf.org/mailman/listinfo/mile
    <https://www.ietf.org/mailman/listinfo/mile>



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