Re: [Detnet] WG Review: Rewording in scope statement

"S.V.R.Anand" <anand@ece.iisc.ernet.in> Sat, 19 September 2015 16:12 UTC

Return-Path: <anand@ece.iisc.ernet.in>
X-Original-To: detnet@ietfa.amsl.com
Delivered-To: detnet@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0EE9C1B2E52 for <detnet@ietfa.amsl.com>; Sat, 19 Sep 2015 09:12:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.917
X-Spam-Level:
X-Spam-Status: No, score=-0.917 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RELAY_IS_203=0.994, SPF_HELO_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f4pjFZFt1p47 for <detnet@ietfa.amsl.com>; Sat, 19 Sep 2015 09:12:34 -0700 (PDT)
Received: from relay.iisc.ernet.in (relay.iisc.ernet.in [203.200.35.70]) by ietfa.amsl.com (Postfix) with ESMTP id 4DCE21B601D for <detnet@ietf.org>; Sat, 19 Sep 2015 09:12:31 -0700 (PDT)
Received: from ece.iisc.ernet.in (mail.ece.iisc.ernet.in [10.32.1.10]) by relay.iisc.ernet.in (8.13.1/8.13.1) with ESMTP id t8JGCJ18014455 for <detnet@ietf.org>; Sat, 19 Sep 2015 21:42:19 +0530
Received: from ece.iisc.ernet.in (localhost [127.0.0.1]) by ece.iisc.ernet.in (8.14.7/8.14.7) with ESMTP id t8JGDUnk003936 for <detnet@ietf.org>; Sat, 19 Sep 2015 21:43:30 +0530
Received: (from apache@localhost) by ece.iisc.ernet.in (8.14.7/8.14.7/Submit) id t8JGDUBI003935; Sat, 19 Sep 2015 21:43:30 +0530
X-Authentication-Warning: ece.iisc.ernet.in: apache set sender to anand@ece.iisc.ernet.in using -f
Received: from 10.16.40.13 (proxying for 117.192.104.1) (SquirrelMail authenticated user anand) by ece.iisc.ernet.in with HTTP; Sat, 19 Sep 2015 21:43:30 +0530
Message-ID: <7c5193585214941ade5b0c56c15f2888.squirrel@ece.iisc.ernet.in>
Date: Sat, 19 Sep 2015 21:43:30 +0530
From: "S.V.R.Anand" <anand@ece.iisc.ernet.in>
To: detnet@ietf.org
User-Agent: SquirrelMail/1.4.22
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
X-Priority: 3 (Normal)
Importance: Normal
X-IISc-MailScanner-Information: Please contact the ISP for more information
X-IISc-MailScanner: Found to be clean
X-IISc-MailScanner-SpamCheck: not spam, SpamAssassin (not cached, score=-1.798, required 6.5, ALL_TRUSTED -1.00, BAYES_00 -1.90, FSL_RCVD_USER 0.00, URIBL_BLOCKED 0.00, _LOCAL_RCVD_THRU_RPROXY 1.10)
X-IISc-MailScanner-From: anand@ece.iisc.ernet.in
Archived-At: <http://mailarchive.ietf.org/arch/msg/detnet/W7gsyqnWlsWCxk2tw9mqPS5D1uA>
Subject: Re: [Detnet] WG Review: Rewording in scope statement
X-BeenThere: detnet@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Discussions on Deterministic Networking BoF and Proposed WG <detnet.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/detnet>, <mailto:detnet-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/detnet/>
List-Post: <mailto:detnet@ietf.org>
List-Help: <mailto:detnet-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/detnet>, <mailto:detnet-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 19 Sep 2015 16:12:38 -0000

Pascal,

Yes, the centrlized approach is very appropriate in heterogeneous
environment.

Covering heterogeneous paths makes the routing and scheduling problems
statement very challenging as the determinism will then have deal with
the path comprising of network segments having different attributes in
terms of L2 access and native L3 protocol support. My feeling is that
handling node mobility scenario is by no means an easy task. What do you
think ?

We have work on hands :)

Anand

On 2015-09-19 16:21, Pascal Thubert (pthubert) wrote:
> I agree that the change makes sense.
>
> My reading of the charter is that we will cover heterogeneous paths.
>
> This is actually one of the main reasons why the work is centralized
> out of, say, IEEE 802.1.
>
> Cheers,
>  Pascal
>
>  Le 19 sept. 2015 à 10:30, S.V.R.Anand <anand@ece.iisc.ernet.in> a
> écrit :
>
>> The change looks good to me. This said, I am wondering if the scope
>> automatically includes the possibility of (i) an heterogeneous
>> network
>> comprising of mix of L2 technologies, wired and wirelss, within its
>> administrative domain, rather than strictly a homogeneous one and
>> (ii) mobile
>> scenarios where the talker or listener or both can be mobile.
>>
>> Anand
>>
>> On Saturday 19 September 2015 01:45 AM, Grossman, Ethan A. wrote:
>>> I like this change.
>>> Ethan.
>>> ________________________________________
>>> From: Eric Gray [eric.gray@ericsson.com]
>>> Sent: Friday, September 18, 2015 12:16 PM
>>> To: Lou Berger; Andrew G. Malis
>>> Cc: detnet WG; IETF Discussion; IESG
>>> Subject: Re: [Detnet] WG Review: Deterministic Networking
>> (detnet)
>>>
>>> No objection from me.
>>>
>>> -----Original Message-----
>>> From: ietf [mailto:ietf-bounces@ietf.org] On Behalf Of Lou Berger
>>> Sent: Friday, September 18, 2015 3:14 PM
>>> To: Andrew G. Malis
>>> Cc: detnet WG; IETF Discussion; IESG
>>> Subject: Re: [Detnet] WG Review: Deterministic Networking
>> (detnet)
>>>
>>> I like this change.
>>>
>>> Any objections?
>>>
>>> Thank you!
>>> Lou
>>> On 9/18/2015 2:04 PM, Andrew G. Malis wrote:
>>>> Lou,
>>>>
>>>> I would suggest the following:
>>>>
>>>> OLD
>>>>
>>>> Candidate Layer 3 data plane
>>>> technologies that may be used, without modification, include: IP
>> and
>>>> MPLS.
>>>>
>>>> NEW
>>>>
>>>> Candidate IETF data plane
>>>> technologies that may be used, without modification, include IP,
>> MPLS,
>>>> and Layer 2 encapsulations that run over IP and/or MPLS,
>> including but
>>>> not limited to pseudowires and GRE.
>>>>
>>>>
>>>> (I changed "Layer 3" to "IETF" so that we don't get into the
>> debate
>>>> over whether MPLS is layer 3 or not).
>>>>
>>>> Cheers,
>>>> Andy
>>>>
>>>>
>>>>
>>>> On Fri, Sep 18, 2015 at 1:16 PM, Lou Berger <lberger@labn.net
>>>> <mailto:lberger@labn.net>> wrote:
>>>>
>>>> Andy,
>>>>
>>>> On 9/18/2015 12:52 PM, Andrew G. Malis wrote:
>>>> > Adrian and Lou,
>>>> >
>>>> > When I first read the draft charter, my immediate reaction was
>> that
>>>> > the scope of work would be deterministic IP and MPLS flows
>> layered
>>>> > over a deterministic Ethernet infrastructure as defined by
>> IEEE.
>>>> This
>>>> > would probably be pretty straightforward work.
>>>> >
>>>> > However, your conversation got me to read the charter more
>> closely,
>>>> > and while the word "pseudowire" isn't used, the inclusion of
>> the
>>>> PALS
>>>> > WG in the charter implies to me that the scope of work could
>> include
>>>> > the transport of deterministic Ethernet flows (as defined by
>> IEEE)
>>>> > within pseudowires carried by arbitrary IP and/or MPLS
>>>> infrastructures.
>>>>
>>>> PWs has been mentioned as an option, but section of (existing)
>>>> encapsulation to be used is the subject of the WG. So PALS is
>>>> included
>>>> really to cover this possibility.
>>>>
>>>> > All of a sudden, the work is much less straightforward. If
>> this is
>>>> > indeed part of the scope of work, it should be explicit in the
>>>> charter
>>>> > (or explicitly excluded if not).
>>>> >
>>>> Do you have any suggested changes? (It would help to understand
>> your
>>>> concern.)
>>>>
>>>> Thanks,
>>>> Lou
>>>>
>>>> > Cheers,
>>>> > Andy
>>>> >
>>>> >
>>>> > On Fri, Sep 18, 2015 at 12:26 PM, Adrian Farrel
>>>> <adrian@olddog.co.uk <mailto:adrian@olddog.co.uk>
>>>> > <mailto:adrian@olddog.co.uk <mailto:adrian@olddog.co.uk>>>
>> wrote:
>>>> >
>>>> > Thanks Lou,
>>>> >
>>>> > I think we're in agreement that a new WG would be helpful as a
>>>> > place to
>>>> > coordinate whatever work is needed and to provide a discussion
>>>> > forum. This is
>>>> > partly because there is no existing place where this work
>>>> wold not
>>>> > provide a
>>>> > distraction.
>>>> >
>>>> > It is possible that the location for the work is RTG if the
>>>> > applicability
>>>> > document is describing the applicability of some of the
>> control
>>>> > plane protocols,
>>>> > although applying RSVP would possibly put it in TSV. And if
>> the
>>>> > work is applying
>>>> > IP, it might be in INT. Not so sure that this is a really
>>>> > important issue.
>>>> >
>>>> > But I am still left looking at the current charter text and
>>>> > thinking it is not
>>>> > describing the applicability statement that we are
>>>> discussing. If
>>>> > my paragraph
>>>> > that you quoted describes the work well, can we do some
>> serious
>>>> > edits to the
>>>> > charter to make it substantially clearer what the WG is
>> actually
>>>> > doing. I might
>>>> > suggest removing nearly all of the text and replacing it with
>> a
>>>> > short paragraph
>>>> > that says something like what I wrote (with perhaps a few more
>>>> > words). Currently
>>>> > I find the text confusing in scope and very open to
>>>> misinterpretation.
>>>> >
>>>> > Thanks,
>>>> > Adrian
>>>> >
>>>> >
>>>> > > -----Original Message-----
>>>> > > From: Lou Berger [mailto:lberger@labn.net
>> <mailto:lberger@labn.net>
>>>> <mailto:lberger@labn.net <mailto:lberger@labn.net>>]
>>>> > > Sent: 18 September 2015 16:52
>>>> > > To: adrian@olddog.co.uk <mailto:adrian@olddog.co.uk>
>>>> <mailto:adrian@olddog.co.uk <mailto:adrian@olddog.co.uk>>;
>>>> > ietf@ietf.org <mailto:ietf@ietf.org> <mailto:ietf@ietf.org
>>>> <mailto:ietf@ietf.org>>; iesg@ietf.org <mailto:iesg@ietf.org>
>>>> > <mailto:iesg@ietf.org <mailto:iesg@ietf.org>>
>>>> > > Cc: 'detnet WG'
>>>> > > Subject: Re: WG Review: Deterministic Networking (detnet)
>>>> > >
>>>> > > Hi Adrian,
>>>> > > I have to say that there were times that I felt the
>>>> same as
>>>> > you, and
>>>> > > questioned what a DetNet WG would / should do. I think
>>>> you hit
>>>> > the key
>>>> > > points in your mail and the main work that needs to be done
>> is
>>>> > to say
>>>> > > how all the pieces fit together when operating over IETF
>>>> owned data
>>>> > > planes, i.e. IP and MPLS, without modification. I think
>>>> your last
>>>> > > paragraph summarizes the work to be done quiet well.
>>>> > >
>>>> > > > Are you sure that this work is more than an applicability
>>>> > statement that
>>>> > shows
>>>> > > > how existing tools are used to achieve the desired
>> function.
>>>> > This document
>>>> > > might
>>>> > > > cover data plane, OAM, packet classification,
>> configuration,
>>>> > control plane,
>>>> > > > security, etc. That would be useful work and would
>> probably
>>>> > need a WG to
>>>> > > achieve
>>>> > > > the necessary discussion.
>>>> > >
>>>> > > This answers the question that the work belongs in the IETF
>> in
>>>> > some WG,
>>>> > > but doesn't say that a new WG is needed. I came the
>>>> conclusion
>>>> > that a
>>>> > > new WG is needed to ensure that the overall solution
>>>> "works" and
>>>> > that
>>>> > > the data plane details are sufficiently defined.
>>>> > >
>>>> > > Does this help?
>>>> > >
>>>> > > Lou
>>>> > >
>>>> > > On 9/18/2015 11:38 AM, Adrian Farrel wrote:
>>>> > > > Hi IESG,
>>>> > > >
>>>> > > > I am struggling to understand why this work is being
>>>> proposed
>>>> > in the Routing
>>>> > > > Area. Actually, I am slightly struggling to understand
>>>> why it
>>>> > is being
>>>> > proposed
>>>> > > > for the IETF.
>>>> > > >
>>>> > > > This is not say I don't think a WG is needed, but the only
>>>> > work I see
>>>> > described
>>>> > > > here is a documentation of data plane work and an "overall
>>>> > architecture". I
>>>> > > > assume that any modification to a layer 2 data plane will
>> be
>>>> > carried out by
>>>> > the
>>>> > > > SDO that owns that data plane. In particular, if changes
>> to
>>>> > Ethernet are
>>>> > needed,
>>>> > > > they will be done in the IEEE. So, that leaves us with
>>>> work at
>>>> > L3 for which
>>>> > the
>>>> > > > proposed charter text says IP or MPLS. Now, it seems to me
>>>> > that any change
>>>> > to
>>>> > > IP
>>>> > > > or MPLS in the forwarding plane is alarming, and also
>>>> that any
>>>> > change to IP
>>>> > > > would need to be done in the Internet Area.
>>>> > > >
>>>> > > > At the same time, the charter explicitly puts discussion
>> of
>>>> > control plane
>>>> > out of
>>>> > > > scope.
>>>> > > >
>>>> > > > Are you sure that this work is more than an applicability
>>>> > statement that
>>>> > shows
>>>> > > > how existing tools are used to achieve the desired
>> function.
>>>> > This document
>>>> > > might
>>>> > > > cover data plane, OAM, packet classification,
>> configuration,
>>>> > control plane,
>>>> > > > security, etc. That would be useful work and would
>> probably
>>>> > need a WG to
>>>> > > achieve
>>>> > > > the necessary discussion.
>>>> > > >
>>>> > > > Adrian
>>>> > > >
>>>> > > >> -----Original Message-----
>>>> > > >> From: IETF-Announce
>>>> [mailto:ietf-announce-bounces@ietf.org
>>>> <mailto:ietf-announce-bounces@ietf.org>
>>>> > <mailto:ietf-announce-bounces@ietf.org
>>>> <mailto:ietf-announce-bounces@ietf.org>>] On Behalf Of
>>>> > > The
>>>> > > >> IESG
>>>> > > >> Sent: 18 September 2015 15:51
>>>> > > >> To: IETF-Announce
>>>> > > >> Cc: detnet WG
>>>> > > >> Subject: WG Review: Deterministic Networking (detnet)
>>>> > > >>
>>>> > > >> A new IETF working group has been proposed in the Routing
>>>> > Area. The IESG
>>>> > > >> has not made any determination yet. The following draft
>>>> > charter was
>>>> > > >> submitted, and is provided for informational purposes
>> only.
>>>> > Please send
>>>> > > >> your comments to the IESG mailing list (iesg at
>>>> ietf.org [1] <http://ietf.org> [1]
>>>> > <http://ietf.org> [1]) by 2015-09-28.
>>>> > > >>
>>>> > > >> Deterministic Networking (detnet)
>>>> > > >> ------------------------------------------------
>>>> > > >> Current Status: Proposed WG
>>>> > > >>
>>>> > > >> Assigned Area Director:
>>>> > > >> Deborah Brungard <dbrungard@att.com
>>>> <mailto:dbrungard@att.com> <mailto:dbrungard@att.com
>>>> <mailto:dbrungard@att.com>>>
>>>> > > >>
>>>> > > >> Mailing list
>>>> > > >> Address: detnet@ietf.org <mailto:detnet@ietf.org>
>>>> <mailto:detnet@ietf.org <mailto:detnet@ietf.org>>
>>>> > > >> To Subscribe:
>>>> https://www.ietf.org/mailman/listinfo/detnet [2]
>>>> > > >> Archive: https://mailarchive.ietf.org/arch/browse/detnet/
>> [3]
>>>> > > >>
>>>> > > >> Charter:
>>>> > > >>
>>>> > > >> The Deterministic Networking (DetNet) Working Group
>>>> focuses on
>>>> > > >> deterministic data paths that operate over Layer 2
>> bridged
>>>> > and Layer 3
>>>> > > >> routed segments, where such paths can provide bounds on
>>>> > latency, loss,
>>>> > > >> and packet delay variation (jitter), and high
>> reliability.
>>>> > The Working
>>>> > > >> Group addresses Layer 3 aspects in support of
>> applications
>>>> > requiring
>>>> > > >> deterministic networking. The Working Group
>>>> collaborates with
>>>> > IEEE802.1
>>>> > > >> Time Sensitive Networking (TSN), which is responsible
>>>> for Layer 2
>>>> > > >> operations, to define a common architecture for both
>>>> Layer 2
>>>> > and Layer
>>>> > > >> 3. Example applications for deterministic networks
>> include
>>>> > professional
>>>> > > >> and home audio/video, multimedia in transportation,
>> engine
>>>> > control
>>>> > > >> systems, and other general industrial and vehicular
>>>> > applications being
>>>> > > >> consider by the IEEE 802.1 TSN Task Group.
>>>> > > >>
>>>> > > >> The Working Group will initially focus on solutions for
>>>> > networks that
>>>> > > >> are under a single administrative control or within a
>>>> closed
>>>> > group of
>>>> > > >> administrative control; these include not only
>> campus-wide
>>>> > networks but
>>>> > > >> also can include private WANs. The DetNet WG will not
>> spend
>>>> > energy on
>>>> > > >> solutions for large groups of domains such as the
>> Internet.
>>>> > > >>
>>>> > > >> The Working Group will specify an overall architecture
>> that
>>>> > encompasses
>>>> > > >> the data plane, OAM (Operations, Administration, and
>>>> > Maintenance), time
>>>> > > >> synchronization, management, control, and security
>> aspects
>>>> > which are
>>>> > > >> required to enable a multi-hop path, and forwarding
>>>> along the
>>>> > path, with
>>>> > > >> the deterministic properties of controlled latency, low
>>>> > packet loss, low
>>>> > > >> packet delay variation, and high reliability. The work
>>>> applies to
>>>> > > >> point-to-point (unicast) and point-to-multipoint
>>>> (multicast)
>>>> > flows which
>>>> > > >> can be characterized in a manner that allows the network
>> to
>>>> > 1) reserve
>>>> > > >> the appropriate resources for the flows in advance, and
>> 2)
>>>> > release/reuse
>>>> > > >> the resources when they are no longer required. The work
>>>> > covers the
>>>> > > >> characterization of flows, the encapsulation of frames,
>> the
>>>> > required
>>>> > > >> forwarding behaviors, as well as the state that may
>>>> need to be
>>>> > > >> established in intermediate nodes. Candidate Layer 3
>>>> data plane
>>>> > > >> technologies that may be used, without modification,
>>>> include:
>>>> > IP and
>>>> > > >> MPLS.
>>>> > > >>
>>>> > > >> The working group will document which deployment
>>>> environments
>>>> > and types
>>>> > > >> of topologies are within (or outside) the scope of the
>>>> DetNet
>>>> > > >> architecture. This work focuses on the data plane
>>>> aspects and is
>>>> > > >> independent from any path setup protocol or mechanism.
>> The
>>>> > data plane
>>>> > > >> will be compatible with the work done in IEEE802.1 TSN.
>>>> > > >>
>>>> > > >> The Working Group's scope explicitly excludes
>> modifications
>>>> > of transport
>>>> > > >> protocols, OAM, Layer 3 forwarding, encapsulations, and
>>>> > control plane
>>>> > > >> protocols.
>>>> > > >>
>>>> > > >> DetNet is chartered to work in the following areas:
>>>> > > >>
>>>> > > >> Overall architecture: This work encompasses the data
>>>> > plane, OAM,
>>>> > > >> time synchronization, management, control, and security
>>>> > aspects.
>>>> > > >>
>>>> > > >> Data plane: This work will document how to use IP
>>>> and/or
>>>> > MPLS to
>>>> > > >> support a data plane method of flow identification
>>>> and packet
>>>> > > >> forwarding over Layer 3.
>>>> > > >>
>>>> > > >> Data flow information model: This work will
>>>> identify the
>>>> > information
>>>> > > >> needed for flow establishment and control and be
>>>> used by a
>>>> > > >> reservation protocol or by YANG data models. The
>>>> work will be
>>>> > > >> independent from the protocol(s) used to control
>>>> the flows
>>>> > > >> (e.g. YANG+NETCONF/RESTCONF, PCEP or GMPLS).
>>>> > > >>
>>>> > > >> Identification of additional YANG models: This work
>>>> will
>>>> > document
>>>> > > >> device and link capabilities (feature support) and
>>>> resources
>>>> > > >> (e.g. buffers, bandwidth) for use in device
>>>> configuration
>>>> > and status
>>>> > > >> reporting. Such information may also be used when
>>>> > advertising the
>>>> > > >> deterministic network elements to a control plane.
>>>> > Control plane
>>>> > > >> related information will be independent from the
>>>> > protocol(s) which
>>>> > > >> may be used to advertise this information (e.g.
>>>> IS-IS or
>>>> > GMPLS
>>>> > > >> extensions). Any new YANG models will be
>>>> coordinated with the
>>>> > > >> Working Groups that define any augmented base models.
>>>> > > >>
>>>> > > >> As needed, problem statement: This effort will
>>>> establish the
>>>> > > >> deployment environment and deterministic network
>>>> > requirements.
>>>> > > >>
>>>> > > >> As needed, vertical requirements: This effort will
>>>> detail the
>>>> > > >> requirements for deterministic networks in various
>>>> > industries, for
>>>> > > >> example, professional audio, electrical utilities,
>>>> building
>>>> > > >> automation systems, wireless for industrial
>>>> applications.
>>>> > > >>
>>>> > > >> To investigate whether existing data plane encryption
>>>> > mechanisms can
>>>> > > >> be applied, possibly opportunistically, to improve
>>>> > security and
>>>> > > >> privacy.
>>>> > > >>
>>>> > > >> The WG coordinates with other relevant IETF Working
>> Groups,
>>>> > including
>>>> > > >> CCAMP, PCE, PALS, TEAS, OSPF, IS-IS, TSVWG, and 6TisSCH.
>> As
>>>> > the work
>>>> > > >> progresses, requirements may be provided to the
>> responsible
>>>> > Working
>>>> > > >> Group, e.g. PCE, TEAS, and CCAMP, with DetNet acting as a
>>>> > focal point to
>>>> > > >> maintain the consistency of the overall architecture.
>>>> The WG
>>>> > will liaise
>>>> > > >> with appropriate groups in IEEE and other Standards
>>>> Development
>>>> > > >> Organizations (SDOs).
>>>> > > >>
>>>> > > >> WG deliverables include:
>>>> > > >>
>>>> > > >> As standard track or informational RFCs
>>>> > > >>
>>>> > > >> Overall architecture
>>>> > > >> Data plane specification
>>>> > > >> Data flow information model
>>>> > > >> YANG model augmentations
>>>> > > >>
>>>> > > >> WG sustaining/informational documents may include:
>>>> > > >>
>>>> > > >> These documents may not necessarily be published,
>>>> but may be
>>>> > > >> maintained in a draft form or on a collaborative
>>>> Working
>>>> > Group wiki
>>>> > > >> to support the efforts of the Working Group and
>>>> help new
>>>> > comers:
>>>> > > >>
>>>> > > >> Problem statement and (constrained) deployment
>>>> environments
>>>> > > >> User-driven use cases
>>>> > > >>
>>>> > > >>
>>>> > > >>
>>>> > > >> Milestones:
>>>> > > >
>>>> > > >
>>>> >
>>>> >
>>>> >
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> detnet mailing list
>>>> detnet@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/detnet [2]
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> detnet mailing list
>>> detnet@ietf.org
>>> https://www.ietf.org/mailman/listinfo/detnet [2]
>>>
>>
>> --
>> This message has been scanned for viruses and
>> dangerous content by MailScanner [4], and is
>> believed to be clean.
>
>> _______________________________________________
>> detnet mailing list
>> detnet@ietf.org
>> https://www.ietf.org/mailman/listinfo/detnet [2]
>
> --
> This message has been scanned for viruses and
> dangerous content by MAILSCANNER [4], and is
> believed to be clean.
>
> Links:
> ------
> [1] http://ietf.org
> [2] https://www.ietf.org/mailman/listinfo/detnet
> [3] https://mailarchive.ietf.org/arch/browse/detnet/
> [4] http://www.mailscanner.info/


-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.