Skip to main content

2015-01-21: Potential Areas for IETF/IEEE802 Coordination v15
slides-interim-2021-ietfieee-04-sessa-2015-01-21-potential-areas-for-ietfieee802-coordination-v15-00

Meeting Slides IETF-IEEE (ietfieee) IAB ASG
Date and time 2021-12-31 20:00
Title 2015-01-21: Potential Areas for IETF/IEEE802 Coordination v15
State Active
Other versions plain text
Last updated 2022-06-10

slides-interim-2021-ietfieee-04-sessa-2015-01-21-potential-areas-for-ietfieee802-coordination-v15-00
Potential Areas for IETF/IEEE802 Coordination

0. Revision History
0.0 Initial Revision - 9/4/2012
0.1 revised for the period between 9/5 and 10/29
0.2 revised according to input received on 01, still reflects the 9/5-10/29 time interval
0.3 revised after the 10/29/12 meeting
0.4 revised for the period between 10/29 and 12/12
0.5 revised after the 12/17/12 meeting
0.6 revised for the period between 12/17/12 and 2/5/13
0.7 revised for the period between 2/5/13 and 4/30/13
0.8 revised after the 5/2/13 meeting
0.9 revised for the period between 5/2/13 and 9/22/13
0.10 revised after the 9/30 meeting
0.11 revised for the period between 9/30/13 and 1/22/14
0.12 revised after the 1/27/14 meeting
0.13 revised after the 6/18/14 meeting
0.14 revised with updates before the 9/29/14 f2f meeting
0.15 revised for the period between 9/29/14 and 1/20/15


1. IETF TRILL Fine-grained labeling and IEEE 802.1 tags
1.1 Description - CLOSED

-------------------------------------------------------------------------

2. IETF BFD and IEEE 802.1AX
2.1 Description - CLOSED
(Note: draft-ietf-bfd-on-lags was approved by the IESG on 12/19/2013 and 
published as RFC 7130)

-------------------------------------------------------------------------

3. IETF NVO3 and IEEE 802.1 DCB
3.1. Description
IEEE 802.1Qbg VDP might be used as the basis for the communication that 
NVO may need between an end system and an external box (e.g. bridge or 
router) doing the NVO encapsulation. Coordination will help determine if 
VDP is a suitable candidate and possibly to make any amendment needed in 
VDP for NVO usage.

3.2. Relevant Documents
https://datatracker.ietf.org/liaison/1219/
http://datatracker.ietf.org/wg/nvo3/charter/
http://datatracker.ietf.org/doc/draft-ietf-nvo3-overlay-problem-
statement - RFC 7364
http://datatracker.ietf.org/doc/draft-ietf-nvo3-framework - RFC 7365
http://datatracker.ietf.org/doc/draft-ietf-nvo3-use-case
http://datatracker.ietf.org/doc/draft-ietf-nvo3-gap-analysis
http://datatracker.ietf.org/doc/draft-ietf-nvo3-arch/
http://datatracker.ietf.org/doc/draft-ietf-nvo3-nve-nva-cp-req/
http://datatracker.ietf.org/doc/draft draft-ietf-nvo3-dataplane-
requirements
http://datatracker.ietf.org/doc/draft-ietf-nvo3-security-requirements/


3.3. Owners - Adrian Farrel, Pat Thaler

3.4. Action Items
- follow-up and send documents for review as they are adopted as WG 
items, WGLC and IETF LC.

-------------------------------------------------------------------------

4. IETF awareness of IEEE 802.1Q-2011
4.1. Description - CLOSED

-------------------------------------------------------------------------

5 .Enabling use of Local Addresses for virtualization and IoT (was: 
Effect of virtualization on IEEE 802 architecture)
5.1. Description

At the 7/25/12 f2f meeting Glenn Parsons presented a brief overview of 
the IEEE Registration Authority Committee (RAC) mission, highlighting 
the current RAC policy on virtualization and asking what virtualization 
policy would reduce the consumption of EUI-48 addresses.  Norman Finn 
suggested this could be an area of collaboration between the IETF and 
the IEEE 802.

Status 4/30/13 - Glenn Parsons submitted an I-D and gave presentations 
at IETF-86 in the Technical Plenary, OPS and INT area meetings. The IEEE 
RAC will finalize and approve the proposal by June.

9/9/13: draft-ieee-rac-oui-restructuring-01.txt submitted

Status 1/14/14 (Bob Grow): Right now that would just be a RAC document,

7/14/14 - Pat Thaler and Don Pannell gave presentations on regarding 
concerns about potential global address consumption by IoT devices and 
feasibil8ity of using local MAC addresses for such devices. Virtual 
machines usually have a hypervisor with a physical port with a global 
address to use to acquire a local MAC address for the VM and an 
orchestration system to provide the address. In contrast, a protocol for 
IoT devices should work without a global address for the physical port 
and should allow for operation with or without an address server.

http://www.ieee802.org/1/files/public/docs2014/New-pannell-MAC-Address-
Usage-0714-v1.pdf
http://www.ieee802.org/1/files/public/docs2014/new-addresses-thaler-
local-address-acquisition-0714-v2.pdf

9/13/14 IEEE 802.1 drafted a PAR for an Amendment to IEEE 802 Overview 
and Architecture, P802c Local Media Access Control (MAC) Addressing. If 
the PAR is approved, the amendment will describe using a portion of the 
address space for protocols assigning local addresses out of a CID block 
associated with the protocol. A portion of the local address space will 
continue to be used for assignment by local administrators.  Forwarding 
the PAR will be considered at the November IEEE 802 meeting.

IEEE 802.1 is also considering a project to define a protocol for local 
address claiming (i.e. without an address server) and local address 
distribution using blocks from the CID space. The protocol would be 
usable by IoT devices that do not have a global address assignment.

November 2014 - IEEE 802.1 approved the formation of the IEEE 802.1 
Local Address Study Group (LASG)

January 2015 - First meeting of the LASG at the Atlanta IEEE 802.1 
Interim. PARs and CSDs for the SG formation and a possible Local Address 
Assignment Protocol were drafted for discussions.


5.2. Relevant Documents
http://www.iab.org/2012/12/13/proposed-ieee-registration-authority-
committee-oui-tier-restructuring/
http://www.ietf.org/proceedings/86/slides/slides-86-iab-
techplenary-5.pdf
https://datatracker.ietf.org/doc/draft-ieee-rac-oui-restructuring/
http://standards.ieee.org/develop/regauth/tut/eui.pdf
http://www.ieee802.org/1/files/public/docs2014/new-addresses-thaler-local-address-par-v01.pdf
http://www.ieee802.org/1/pages/lasg.html
http://www.ieee802.org/1/files/public/docs2015/lasg-mjt-par-csd-
update-0115-v01.pdf
http://www.ieee802.org/1/files/public/docs2015/lasg-mjt-protocol-par-
csd-0115-v01.pdf



5.3. Owners - Glenn Parsons, Pat Thaler

5.4. Action Items
- Liaison to IETF when relevant SG materials are available - Glenn 
Parsons

-------------------------------------------------------------------------

6. IETF EMU and IEEE 802.1X, 802.11 and 802.16 security based on EAP
6.1. Description - CLOSED

-------------------------------------------------------------------------

7. IETF Ethernet MIB, ADSL MIB and IEEE 802.3
7.1. Description
In the transition process between the IETF and the IEEE the following 
documents were taken over by IEEE 802.3:
RFC 2108 - Ethernet Repeater Devices
RFC 3621 - Power Ethernet MIB
RFC 3635 - Ethernet-like Interface Types
RFC 3637 - Ethernet WAN Interface Sublayer
RFC 4836 - Ethernet Medium Attachment Units (MAUs)
RFC 4837 - Ethernet Passive Optical Networks (EPON)
RFC 4878 - Operations, Administration, and Maintenance (OAM) Functions 
on Ethernet-Like Interfaces
RFC 5066 - Ethernet in the First Mile Copper (EFMCu) Interfaces MIB

The IF-CAP-STACK-MIB in RFC 5066 is generic and the IETF proposed to 
continue to be maintained by the IETF in a separate new document

The IEEE 802.3 proposed to create an RFC that documents the issues 
related to the transition of the Ethernet MIB work to IEEE 802.3 similar 
to RFC 4663 which documents the transition of the Bridge MIB work to 
IEEE 802.1
- The OPSAWG was rechartered in October 2012 to include the two relevant documents
- Status 6/18/14 Benoit Claise): draft-ietf-opsawg-rfc5066bis has been
published as RFC 7124  but that the initial transition document has not
been completed.  They have identified a new editor (Tom Taylor) for the 
proposed document. The current draft of the transition document has been 
posted as draft-taylor-opsawg-mibs-to-ieee80231.
- Status 9/23/14 (Dan): https://datatracker.ietf.org/doc/draft-ietf-
opsawg-mibs-to-ieee80231/ was sent to WGLC, and the announcement was 
forwarded to the ietf-ieee coordination mail list
- Status 1/20/15 (Dan): document in RFC Editor Queue


7.2. Relevant Documents
- IEEE 802.3.1-2013
- http://datatracker.ietf.org/wg/opsawg/charter/
- https://datatracker.ietf.org/doc/draft-ietf-opsawg-rfc5066bis/
- http://datatracker.ietf.org/doc/draft-ietf-opsawg-mibs-to-ieee80231/

7.3. Owners - Benoit Claise

7.4. Action Items ? CLOSE the item at publication of http://
datatracker.ietf.org/doc/draft-ietf-opsawg-mibs-to-ieee80231/
 as RFC

-------------------------------------------------------------------------

8. IETF 6LOWPAN and IEEE 802.15
8.1. Description - CLOSED

-------------------------------------------------------------------------

9. IETF PAWS WG and 802.11, 802.19, 802.22
9.1 Description

- coordination between IETF PAWS and IEEE 802.11af, 802.19 and 802.22

Status 1/20/14 (Dorothy, Gabor): Version 8 of the paws protocol document 
was uploaded - no significant changes are expected, good time to send to 
IEEE 802.11 for review
Status 6/18/14 (Pete): the protocol document (draft-ietf-paws-protocol) 
has been stuck, but expect an IETF Last Call soon.  They haven't 
completed the bootstrapping part of the protocol, and are waiting on 
whether that is necessary.  Pete mentioned that he will forward the Last 
Call to the list so it can be disseminated from there.

Status 9/23/14 (Pete): - draft-ietf-paws-protocol *should* be approved 
by the time we arrive in Newark.

- After that, the WG should wrap-up. It does not look like the bootstrap 
protocol has garnered enough interest to get done.

Status 1/9/15 (Pete): draft-ietf-paws-protocol in RFC Editor queue with 
an unsolved dependency upon draft-ietf-uta-tls-bcp, which has completed 
WGLC and should soon go to IETF Last Call. With luck, everything will 
get unstuck in the next few weeks



9.2 Relevant Documents
- http://datatracker.ietf.org/wg/paws/charter/
- http://www.rfc-editor.org/rfc/rfc6953.txt
- https://datatracker.ietf.org/doc/draft-ietf-paws-protocol/
- http://www.ietf.org/mail-archive/web/paws/current/msg01535.html

9.3 Owners: Pete Resnick

9.4 Action Items ? The Action Item will be CLOSED after the publication 
of the protocol RFC

-------------------------------------------------------------------------

10. IETF IPPM and LMAP, and IEEE 802.16 Metrology Study Group- CLOSED, 
will reopen if/when it becomes clear that interaction is needed

-------------------------------------------------------------------------


11. IETF and IEEE 802.1 OmniRAN TG
11.1. Description
The 802.1 OmniRAN TG (IEEE 802.1CF)was authorized in March 2014 to 
create a recommended practice on Network Reference Model and Functional 
Description of IEEE 802 Access Network. The project specifies an access 
network reference model, including entities and reference points along 
with behavioral and functional descriptions of communications among 
those entities to provide a generic model of IEEE 802 access network for 
connecting terminals to their access routers over a link based on the 
family of IEEE 802 Standards. The specification describes the use of 
IEEE 802 technologies to build heterogeneous access networks, which may 
include multiple network interfaces, multiple network access 
technologies, and multiple network subscriptions, aimed to unify the 
support of different interface technologies, enabling shared network 
control and use of software defined network (SDN) principles.

11.2. Relevant Documents
Project status: http://www.ieee802.org/1/pages/802.1cf.html
OmniRAN TG Wiki: https://mentor.ieee.org/omniran/bp/StartPage

11.3. Owners - Max Riegel

11.4. Action Items ? The IEEE with send relevant documents for review by 
the IEEE


-------------------------------------------------------------------------

12. IETF HOKEY and IEEE 802.21
12.1. Description CLOSED

-------------------------------------------------------------------------

13. IETF MIF and IEEE 802.21 - CLOSED, a new shared work item on naming 
in layer 2 networks will be open.  Ted and Juan Carlos Zuniga to draft a 
description for the new shared work item.

-------------------------------------------------------------------------

14. IETF IPFIX Information Elements for Data Link monitoring - CLOSED, 
see RFC 7133

-------------------------------------------------------------------------

15. IETF RADIUS attributes for IEEE 802 networks - CLOSED, see RFC 7268

-------------------------------------------------------------------------

16. IEEE802.1Q SRP (and Gen2 updates) and RSVP/SIP - CLOSED

-------------------------------------------------------------------------

17. IEEE 802.1AS/1588 and NTP - CLOSED

-------------------------------------------------------------------------

18. 802.1AS/1588, 802.1Q time aware shaper(s) and RTP - CLOSED

-------------------------------------------------------------------------

19. Common OAM proposal / Layer Independent OAM
19.1. Description - proposal made by Tissa Senevirathne and a group of 
TRILL contributors at the IEEE 802.1 meetings in July and September to 
reuse the IEEE 802.1ag frame format for TRILL OAM. Needs coordination 
and architectural consistency with the IEEE 802.1 architecture and OAM 
practice.
- 8/20/13: The TRILL WG re-chartered, new charter includes OAM. 
Rechartering was communicated on the mail list.
- 9/25/13: Liaison Statement sent by the TRILL chairs to the IEEE 802 
informing on the status of the work.
- 12/9/13: draft-ietf-trill-oam-framework approved by the IESG
- 1/22/14: new liaison statement sent by TRILL to IEEE 802.1
- Status 1/27/14 (Norman Finn, Donald): liaison from TRILL asking for 
code points from the Connectivity Fault Management protocol, Ethernet 
OAM, as was done with ITU a few years back. It allocates the blocks of 
code points to the IETF with the understanding that they will be 
assigned by IANA based on IETF Standards Actions and TRILL will be an 
early user of some values. Expected to pass.
- Status 9/15/14 (Dan Romascanu): New Non-WG Mailing List: Lime -- Layer 
Independent OAM Management in Multi-Layer Environment (LIME) discussion 
list -  https://www.ietf.org/mailman/listinfo/lime. Working on a 
charter, may request a BOF at IETF-91
- Status 1/20/15 (Dan): while most of the TRILL OAM work progresses, the 
LIME WG was formed and its charter explicitly calls for coordination 
with other SDOs including the IEEE

19.2. Relevant Documents

https://datatracker.ietf.org/doc/draft-ietf-trill-oam-req - published as 
RFC 6905
http://www.ieee802.org/1/files/public/docs2012/liaison-tissa-oam-ieee-trill-0912-v02.pptx
https://datatracker.ietf.org/doc/draft-ietf-trill-oam-framework/ - 
published as RFC 7174
https://datatracker.ietf.org/doc/draft-tissa-trill-oam-fm/
http://datatracker.ietf.org/wg/trill/charter/
http://ieee802.org/1/files/public/docs2014/new-senevirathne-trill-oam-liaison-0114-v01.pptx
http://datatracker.ietf.org/doc/draft-ietf-trill-yang-oam/
http://datatracker.ietf.org/doc/draft-ietf-trill-oam-mib/

https://datatracker.ietf.org/liaison/1302/
http://datatracker.ietf.org/wg/lime/charter/



19.3. Owners - Ted Lemon, Benoit Claise, Ben Mack-Crane

19.4. Action Items
Follow the TRILL OAM documents progress in the WG and send them for 
review to IEEE 802.1 when they reach milestones (WGLC, IETF LC)
This work item will remain open to monitor the status, as well as other 
more OAM-related I-Ds in the TRILL Working Group that should be reviewed 
by IEEE 802.1.
TRILL and LIME documents to be communicated for review when relevant to 
the IEEE 802 (at LC)


-------------------------------------------------------------------------

20. Area Name - use of TRILL as an alternative path selection protocol 
for use in 802.11 mesh networks

20.1. Description - CLOSED

-------------------------------------------------------------------------

21. 6tsch

21.1. Description:
Enable communication and cross-review between the 6tisch WG and IEEE 802
 - In IEEE 802.15: (Bob): Go to the 802.15 website and look for L2R 
under public docs.  The group formed in March with a goal to spend 6 
months to end up at a project point.
- Status 9/22 - 6tisch charter in external review, on IESG agenda for 
9/26, external review message distributed
- Status 9/30/13 (Ted): WG was chartered
- Presentation by Pascal Hubert at the IEEE 802 plenary - https://
mentor.ieee.org/802.15/dcn/13/15-13-0685-00-wng0-6tisch-802-1-for-a-new-
ipv6-multilink-subnet.pptx
- Status 6/18/14: Bob Heile updated that they have set up a group in 
802.15 that would be the companion to the IETF 6TSCH. There has been a 
lot of cross-participation. Pat Kinney mentioned that they were 
participating with the weekly calls and a number of are planning to 
attend IETF 90.
- Status 9/14 (Bob Heile): IEEE 802.15.4 has formed an Interest group 
for 6TiSCH, the 6t IG. The group met at the IEEE with good feedback on 
the IETF WG work.
- Status 12/15: Mail from Michael Richardson asking about the need to 
establish a formal liaison between 6tisch and IEEE 802.15.4

21.2. Relevant Documents
- Mail list https://www.ietf.org/mailman/listinfo/6tsch
- https://datatracker.ietf.org/wg/6tisch/charter/
- https://datatracker.ietf.org/doc/draft-ietf-6tisch-architecture/
- https://datatracker.ietf.org/doc/draft-ietf-6tisch-minimal/
- https://datatracker.ietf.org/doc/draft-ietf-6tisch-terminology/
- https://datatracker.ietf.org/doc/draft-ietf-6tisch-tsch/

21.3. Owners: Ted Lemon, Bob Heile

21.4. Action Items
- follow the activities in the IETF and IEEE 802.15, share information 
informally until activities are chartered
- Follow the activities; send relevant documents from the 6tisch WG as 
they reach Last Call stages.
- Discuss establishing a formal liaison at the 1/15 meeting

-------------------------------------------------------------------------

22. CAPWAP extensions in OPSAWG

22.1. Description:
Extensions to the CAPWAP protocol are being defined in the IETF OPSAWG. 
The OPSAWG will send the documents that relate to IEEE 802.11 technology 
to the IEEE 802.11 WG for expert review.

Status 1/27/14 (Benoit Claise) - there are two relevant drafts in 
Working Group Last Call.  He sent out via email an updated description 
of this item, to be added to the next iteration of the shared work items 
list.  Dan Romascanu will edit the shared work items list accordingly.

Status 9/23/14 (Dorothy Stanley): Liaison requests have been made from 
the opsawg ?to IEEE 802.11 for review and comment on each of these 
documents. The IEEE 802.11 responded with the liaisons below. There are 
no open liaison requests from opsawg to IEEE 802.11 at this time.

Status 1/20/15 (Dan): 2 out of 3 documents were approved by the IESG and 
are now in RFC Editor Queue



22.2. Relevant Documents
- http://datatracker.ietf.org/doc/draft-ietf-opsawg-capwap-extension/
- http://datatracker.ietf.org/doc/draft-ietf-opsawg-capwap-hybridmac - 
approved
- http://datatracker.ietf.org/doc/draft-ietf-opsawg-capwap-alt-tunnel/ - 
approved
- https://datatracker.ietf.org/liaison/1312/
- https://mentor.ieee.org/802.11/dcn/14/11-14-0913-01-0000-liaison-
response-opsawg-capwap-extension.docx
- https://mentor.ieee.org/802.11/dcn/14/11-14-0684-01-0000-capwap-
hybridmac-liaison-response.docx
- Tunnel encapsulation response: slide 5 in https://mentor.ieee.org/
802.11/dcn/14/11-14-0500-00-0000-may-2014-liaison-to-ietf-report.pptx


22.3. Owners: Benoit Claise and Dorothy Stanley

22.4. Action Items
- Benoit to fill in the DESCRIPTION
- Benoit to ensure that OPSAWG chairs send documents at Last Call to 
IEEE 802.11
- Dorothy Stanley to channel requests for reviews and responses between 
the OPSAWG and IEEE 802.11

-------------------------------------------------------------------------

23. Area Name - naming in layer 2 networks

23.1. Description

To be provided by Juan Carlos Zuniga and Ted Lemon

23.2. Relevant Documents

23.3. Owners: Juan Carlos Zuniga and Ted Lemon

23.4. Action Items

-------------------------------------------------------------------------

24. Area Name - coordination between the IETF and IEEE 802 on Pervasive 
Monitoring
24.1. Description
The IETF has reached consensus in RFC7258 that pervasive monitoring 
ought be treated as with other threats in the development of IETF 
protocols. The IEEE 802 started an IEEE 802 Executive Committee (EC) 
Privacy Recommendation SG which will study privacy issues related to 
IEEE 802 technologies and consider the need for a recommended practice 
applicable to IEEE 802 protocols. Given that IETF protocols often run 
over IEEE protocols, their privacy properties are intertwined. It would 
therefore be useful if both organizations consider the privacy issues 
related to usages of combinations of their protocols. For example, 
consideration of how MAC addresses may impinge on the privacy properties 
of higher layer protocols seems like an obvious area to examine. This 
work item could identify how IEEE and IETF protocols together can make 
privacy better or worse and feed into the normal development processes 
of both organizations.


24.2. Relevant Documents
http://www.ieee802.org/PrivRecsg/index.html
https://mentor.ieee.org/privecsg/dcn/15/privecsg-15-0004-01-0000-
privacy-recommendation-par-csd-proposal.pptx

24.3. Owners: Stephen Farrell, Juan Carlos Zuniga

24.4. Action Items

-------------------------------------------------------------------------

25. Area Name - Layer2/Layer 3 Interaction for Time-Sensitive Traffic
25.1. Description
The generalization of the needs for more deterministic networks have led 
to the IEEE 802.1 AVB Task Group becoming the Time-Sensitive
Networking (TSN) Task Group (TG), with a much-expanded constituency
from the industrial and vehicular markets.  Along with this expansion, 
the networks in consideration are becoming larger and structured, 
requiring deterministic forwarding beyond the LAN
boundaries.  For instance, Industrial Automation segregates the
network along the broad lines of the Purdue Enterprise Reference
Architecture (PERA), using different technologies at each level, and
public infrastructures such as Electricity Automation require
deterministic properties over the Wide Area.  The realization is now
coming that the convergence of IT and OT networks requires Layer-3,
as well as Layer-2, capabilities.

In order to serve this extended requirement, the IETF and the IEEE
must collaborate and define an abstract model that can be applicable
both at Layer-2 and Layer-3, and along segments of different
technologies.  With this new work, a path may span, for instance,
across a (limited) number of 802.1 bridges and then a (limited)
number of IP routers.  In that example, the IEEE802.1 bridges may be
operating at Layer-2 over Ethernet whereas the IP routers may be
6TiSCH nodes operating at Layer-2 and/or Layer-3 over the
IEEE802.15.4e MAC.

The proposed model should enable a fully scheduled operation
orchestrated by a central controller, as well as a more distributed
operation with probably lesser capabilities.  In any fashion, the
model should not compromise the ability of a network to keep carrying
the sorts of traffic that is already carried today.


25.2. Relevant Documents
https://datatracker.ietf.org/doc/draft-finn-detnet-problem-statement/

https://datatracker.ietf.org/doc/draft-wetterwald-detnet-utilities-reqs/

25.3. Owners: Adrian Farrel, Norm Finn

25.4. Action Items


26. Area Name - IS-IS extensions for IEEE 802.1Qca
26.1. Description
The IEEE 802.1 Qca has two normative dependencies on IETF IS-IS 
documents. Communication and coordination needs to take place in order 
to avoid delays in the approval and publication of IEEE 802.1Qca

26.2. Relevant Documents
https://datatracker.ietf.org/doc/draft-farkas-isis-pcr/
https://datatracker.ietf.org/doc/draft-ietf-isis-te-metric-extensions/
https://datatracker.ietf.org/doc/draft-ietf-rtgwg-mrt-frr-algorithm/

26.3. Owners - Glen Parsons, Alia Atlas
26.4. Action Items
- Follow-up and expedite the approval process of the IETF documents


27. Area Name - development of YANG models in the IEEE 802
27.1. Description
Following the IESG statement in 2014 and the IETF YANG tutorial at the 
July 2014 IEEE 802 plenary, the IEEE 802.1 started to discuss the 
introduction of YANG modules, which may result soon in a IEEE 802.1 
project. Other IEEE 802 WGs may follow the same path. The IETF and IEEE 
will work to support the formation of YANG expertise in the IEEE 802.

27.2. Relevant Documents
http://www.ieee802.org/802_tutorials/2014-07/Tutorial_Berman_1407.pdf
http://www.ieee802.org/1/files/public/docs2015/new-802-mahesh-yang-0115-
v01.pdf

27.3. Owners - Benoit Claise, TBD IEEE
27.4. Action Items


28. Area Name
28.1. Description
28.2. Relevant Documents
28.3. Owners
28.4. Action Items