Last Call: (Keyed IPv6 Tunnel) to Proposed Standard

[The IESG]

The IESG has received a request from the Layer Two Tunneling Protocol
Extensions WG (l2tpext) to consider the following document:
- 'Keyed IPv6 Tunnel'
   as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
i...@ietf.org mailing lists by 2016-10-28. Exceptionally, comments may be
sent to i...@ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract


   This document describes an Ethernet over IPv6 tunnel encapsulation
   with mandatory 64-bit cookie for connecting L2 Ethernet attachment
   circuits identified by IPv6 addresses.  The encapsulation is based on
   L2TPv3 over IP and does not use the L2TPv3 control plane.





The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-l2tpext-keyed-ipv6-tunnel/

IESG discussion can be tracked via
https://datatracker.ietf.org/doc/draft-ietf-l2tpext-keyed-ipv6-tunnel/ballot/


No IPR declarations have been submitted directly on this I-D.

RFC 8003 on Host Identity Protocol (HIP) Registration Extension

[rfc-editor]

A new Request for Comments is now available in online RFC libraries.


RFC 8003

Title:  Host Identity Protocol (HIP) Registration 
Extension 
Author: J. Laganier,
L. Eggert
Status: Standards Track
Stream: IETF
Date:   October 2016
Mailbox:julien.i...@gmail.com, 
l...@netapp.com
Pages:  16
Characters: 34717
Obsoletes:  RFC 5203

I-D Tag:draft-ietf-hip-rfc5203-bis-11.txt

URL:https://www.rfc-editor.org/info/rfc8003

DOI:http://dx.doi.org/10.17487/RFC8003

This document specifies a registration mechanism for the Host
Identity Protocol (HIP) that allows hosts to register with services,
such as HIP rendezvous servers or middleboxes.  This document
obsoletes RFC 5203.

This document is a product of the Host Identity Protocol Working Group of the 
IETF.

This is now a Proposed Standard.

STANDARDS TRACK: This document specifies an Internet Standards Track
protocol for the Internet community, and requests discussion and suggestions
for improvements.  Please refer to the current edition of the Official
Internet Protocol Standards (https://www.rfc-editor.org/standards) for the 
standardization state and status of this protocol.  Distribution of this 
memo is unlimited.

This announcement is sent to the IETF-Announce and rfc-dist lists.
To subscribe or unsubscribe, see
  https://www.ietf.org/mailman/listinfo/ietf-announce
  https://mailman.rfc-editor.org/mailman/listinfo/rfc-dist

For searching the RFC series, see https://www.rfc-editor.org/search
For downloading RFCs, see https://www.rfc-editor.org/retrieve/bulk

Requests for special distribution should be addressed to either the
author of the RFC in question, or to rfc-edi...@rfc-editor.org.  Unless
specifically noted otherwise on the RFC itself, all RFCs are for
unlimited distribution.


The RFC Editor Team
Association Management Solutions, LLC

RFC 8005 on Host Identity Protocol (HIP) Domain Name System (DNS) Extension

[rfc-editor]

A new Request for Comments is now available in online RFC libraries.


RFC 8005

Title:  Host Identity Protocol (HIP) Domain 
Name System (DNS) Extension 
Author: J. Laganier
Status: Standards Track
Stream: IETF
Date:   October 2016
Mailbox:julien.i...@gmail.com
Pages:  18
Characters: 39146
Obsoletes:  RFC 5205

I-D Tag:draft-ietf-hip-rfc5205-bis-10.txt

URL:https://www.rfc-editor.org/info/rfc8005

DOI:http://dx.doi.org/10.17487/RFC8005

This document specifies a resource record (RR) for the Domain Name
System (DNS) and how to use it with the Host Identity Protocol (HIP).
This RR allows a HIP node to store in the DNS its Host Identity (HI),
the public component of the node public-private key pair; its Host
Identity Tag (HIT), a truncated hash of its public key (PK); and the
domain names of its rendezvous servers (RVSs).  This document
obsoletes RFC 5205.

This document is a product of the Host Identity Protocol Working Group of the 
IETF.

This is now a Proposed Standard.

STANDARDS TRACK: This document specifies an Internet Standards Track
protocol for the Internet community, and requests discussion and suggestions
for improvements.  Please refer to the current edition of the Official
Internet Protocol Standards (https://www.rfc-editor.org/standards) for the 
standardization state and status of this protocol.  Distribution of this 
memo is unlimited.

This announcement is sent to the IETF-Announce and rfc-dist lists.
To subscribe or unsubscribe, see
  https://www.ietf.org/mailman/listinfo/ietf-announce
  https://mailman.rfc-editor.org/mailman/listinfo/rfc-dist

For searching the RFC series, see https://www.rfc-editor.org/search
For downloading RFCs, see https://www.rfc-editor.org/retrieve/bulk

Requests for special distribution should be addressed to either the
author of the RFC in question, or to rfc-edi...@rfc-editor.org.  Unless
specifically noted otherwise on the RFC itself, all RFCs are for
unlimited distribution.


The RFC Editor Team
Association Management Solutions, LLC

IETF 97 Preliminary Agenda

[IETF Agenda]

The IETF 97 Preliminary Agenda has been posted. The final agenda will be 
published on Friday, October 21, 2016. 

https://datatracker.ietf.org/meeting/97/agenda.html 
https://datatracker.ietf.org/meeting/97/agenda.txt 


More information regarding IETF 97 in Seoul is located here: 
https://www.ietf.org/meeting/97/index.html

Thank you! 

IETF Secretariat

RFC 8002 on Host Identity Protocol Certificates

[rfc-editor]

A new Request for Comments is now available in online RFC libraries.


RFC 8002

Title:  Host Identity Protocol Certificates 
Author: T. Heer,
S. Varjonen
Status: Standards Track
Stream: IETF
Date:   October 2016
Mailbox:h...@hs-albsig.de, 
samu.varjo...@helsinki.fi
Pages:  13
Characters: 26613
Obsoletes:  RFC 6253
Updates:RFC 7401

I-D Tag:draft-ietf-hip-rfc6253-bis-09.txt

URL:https://www.rfc-editor.org/info/rfc8002

DOI:http://dx.doi.org/10.17487/RFC8002

The Certificate (CERT) parameter is a container for digital
certificates.  It is used for carrying these certificates in Host
Identity Protocol (HIP) control packets.  This document specifies the
certificate parameter and the error signaling in case of a failed
verification.  Additionally, this document specifies the
representations of Host Identity Tags (HITs) in X.509 version 3 (v3).

The concrete use cases of certificates, including how certificates
are obtained and requested and which actions are taken upon
successful or failed verification, are specific to the scenario in
which the certificates are used.  Hence, the definition of these
scenario-specific aspects is left to the documents that use the CERT
parameter.

This document updates RFC 7401 and obsoletes RFC 6253.

This document is a product of the Host Identity Protocol Working Group of the 
IETF.

This is now a Proposed Standard.

STANDARDS TRACK: This document specifies an Internet Standards Track
protocol for the Internet community, and requests discussion and suggestions
for improvements.  Please refer to the current edition of the Official
Internet Protocol Standards (https://www.rfc-editor.org/standards) for the 
standardization state and status of this protocol.  Distribution of this 
memo is unlimited.

This announcement is sent to the IETF-Announce and rfc-dist lists.
To subscribe or unsubscribe, see
  https://www.ietf.org/mailman/listinfo/ietf-announce
  https://mailman.rfc-editor.org/mailman/listinfo/rfc-dist

For searching the RFC series, see https://www.rfc-editor.org/search
For downloading RFCs, see https://www.rfc-editor.org/retrieve/bulk

Requests for special distribution should be addressed to either the
author of the RFC in question, or to rfc-edi...@rfc-editor.org.  Unless
specifically noted otherwise on the RFC itself, all RFCs are for
unlimited distribution.


The RFC Editor Team
Association Management Solutions, LLC

RFC 7904 on A SIP Usage for REsource LOcation And Discovery (RELOAD)

[rfc-editor]

A new Request for Comments is now available in online RFC libraries.


RFC 7904

Title:  A SIP Usage for REsource 
LOcation And Discovery (RELOAD) 
Author: C. Jennings, 
B. Lowekamp,
E. Rescorla, 
S. Baset,
H. Schulzrinne, 
T. Schmidt, Ed.
Status: Standards Track
Stream: IETF
Date:   October 2016
Mailbox:flu...@cisco.com, 
b...@lowekamp.net, 
e...@rtfm.com,  
saba...@us.ibm.com, 
h...@cs.columbia.edu,  
t.schm...@haw-hamburg.de
Pages:  20
Characters: 41978
Updates/Obsoletes/SeeAlso:   None

I-D Tag:draft-ietf-p2psip-sip-21.txt

URL:https://www.rfc-editor.org/info/rfc7904

DOI:http://dx.doi.org/10.17487/RFC7904

This document defines a SIP Usage for REsource LOcation And Discovery
(RELOAD).  The SIP Usage provides the functionality of a SIP proxy or
registrar in a fully distributed system and includes a lookup service
for Address of Records (AORs) stored in the overlay.  It also defines
Globally Routable User Agent URIs (GRUUs) that allow the
registrations to map an AOR to a specific node reachable through the
overlay.  After such initial contact of a Peer, the RELOAD AppAttach
method is used to establish a direct connection between nodes through
which SIP messages are exchanged.

This document is a product of the Peer-to-Peer Session Initiation Protocol 
Working Group of the IETF.

This is now a Proposed Standard.

STANDARDS TRACK: This document specifies an Internet Standards Track
protocol for the Internet community, and requests discussion and suggestions
for improvements.  Please refer to the current edition of the Official
Internet Protocol Standards (https://www.rfc-editor.org/standards) for the 
standardization state and status of this protocol.  Distribution of this 
memo is unlimited.

This announcement is sent to the IETF-Announce and rfc-dist lists.
To subscribe or unsubscribe, see
  https://www.ietf.org/mailman/listinfo/ietf-announce
  https://mailman.rfc-editor.org/mailman/listinfo/rfc-dist

For searching the RFC series, see https://www.rfc-editor.org/search
For downloading RFCs, see https://www.rfc-editor.org/retrieve/bulk

Requests for special distribution should be addressed to either the
author of the RFC in question, or to rfc-edi...@rfc-editor.org.  Unless
specifically noted otherwise on the RFC itself, all RFCs are for
unlimited distribution.


The RFC Editor Team
Association Management Solutions, LLC

WG Review: Security Events (secevent)

[The IESG]

A new IETF WG has been proposed in the Security 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 (i...@ietf.org) by 2016-10-24.

Security Events (secevent)
---
Current status: Proposed WG

Chairs:
  TBD

Assigned Area Director:
  Kathleen Moriarty 

Security Area Directors:
  Stephen Farrell 
  Kathleen Moriarty 
 
Mailing list:
  Address: id-ev...@ietf.org
  To subscribe: https://www.ietf.org/mailman/listinfo/id-event
  Archive: https://mailarchive.ietf.org/arch/browse/id-event/

Charter: https://datatracker.ietf.org/doc/charter-ietf-secevent/

Many identity related protocols require a mechanism to convey messages 
between systems in order to prevent or mitigate security risks, or to 
provide out-of-band information as necessary. For example, an OAuth 
authorization server, having received a token revocation request 
(RFC7009) may need to inform affected resource servers; a cloud provider 
may wish to inform another cloud provider of suspected fraudulent use of 
identity information; an identity provider may wish to signal a session 
logout to a relying party.

It is expected that several identity and security working groups and
organizations will use Identity Event Tokens to describe area-specific
events such as: SCIM Provisioning Events, OpenID RISC Events, and
OpenID Connect Backchannel Logout, among others.

The Security Events working group will produce a standards-track Event 
Token specification that includes:
 - A JWT extension for expressing security events
 - A syntax that enables event-specific data to be conveyed
This Event Token specification will be event transport independent.

The working group will also develop a simple standards-track Event 
Delivery specification that includes:
 - A method for delivering events using HTTP POST (push)
 - Metadata for describing event feeds
 - Methods for subscribing to and managing event feeds
 - Methods for validating event feed subscriptions


Milestones:
  Oct 2016 - Initial adoption of event token and event delivery drafts
  Feb 2017 - WG last call of event token draft
  Apr 2017 - Event token draft to IESG as a Proposed Standard
  Jul 2017 - WG last call of event delivery draft
  Sep 2017 - Event delivery draft to IESG as a Proposed Standard
  Nov 2017 - Recharter or Conclude

WG Review: L2VPN Service Model (l2sm)

[The IESG]

A new IETF WG has been proposed in the Operations and Management 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 (i...@ietf.org) by
2016-10-24.

L2VPN Service Model (l2sm)
---
Current status: Proposed WG

Chairs:
  TBD

Assigned Area Director:
  Benoit Claise 

Operations and Management Area Directors:
  Benoit Claise 
  Joel Jaeggli 
 
Mailing list:
  Address: l...@ietf.org
  To subscribe: https://www.ietf.org/mailman/listinfo/l2sm
  Archive: https://mailarchive.ietf.org/arch/browse/l2sm/

Charter: https://datatracker.ietf.org/doc/charter-ietf-l2sm/

The IETF and the industry in general is currently specifying a set of
YANG models for network element and protocol configuration. This is an
essential first step, but the end goal is full system configuration that
enable service agility to speed service creation and delivery and allows
the deployment of innovative new services across networks. Services are
built from a combination of network element and protocol configuration,
but are specified to service users in more abstract terms.

The Layer Two Virtual Private Network Service Model (L2SM) working group
is a short-lived WG tasked to create a YANG data model that describes a
L2VPN service (a L2VPN service model) that can be used for communication
between customers and network operators, and to provide input to
automated control and configuration applications. The working group will
attempt to derive a single data model that includes support for
point-to-point Virtual Private Wire Services (VPWS), multipoint Virtual
Private LAN services (VPLS) that use Pseudowires signaled using the Label
Distribution Protocol (LDP) and the Border Gateway Protocol (BGP) as
described in RFC4761 and RFC6624, and Ethernet VPNs in RFC 7432.

It needs to be clearly understood that this L2VPN service model is not an
L2VPN configuration model. That is, it does not provide details for
configuring network elements or protocols (that work is expected to be
carried out in other protocol-specific working groups). Instead, the
L2VPN service model contains the characteristics of the service as
discussed between the operators and their customers. A separate process
is responsible for mapping this service model onto the protocols and
network elements depending on how the network operator chooses to realise
the service.

The deliverable from this working group will provide information to
evaluate the set of YANG models that have already been developed or are
under development, and will help identify any missing models or details.
The deliverable can be viewed as driving requirements for protocol
configuration model so that the service parameters can be mapped into
inputs used by the protocol models.

The working group will learn from the experience of the L3SM working
group and it is expected that the L2SM data model will have similar
structure to the L3SM data model.

The working group should consider draft-wen-l2sm-l2vpn-service-model as a
starting point.

The working group will coordinate with other working groups responsible
for L2VPN protocol work (most notably with BESS and PALS) and with the
MEF.

Milestones:
  Dec 2016 - Adopt WG draft for data model
  Oct 2017 - Request publication of data model as Standards Track RFC
  Dec 2017 - Close working group

WG Action: Formed IPv6 over Low Power Wide-Area Networks (lpwan)

[The IESG]

A new IETF WG has been formed in the Internet Area. For additional
information, please contact the Area Directors or the WG Chairs.

IPv6 over Low Power Wide-Area Networks (lpwan)
---
Current status: Proposed WG

Chairs:
  Alexander Pelov 
  Pascal Thubert 

Assigned Area Director:
  Suresh Krishnan 

Internet Area Directors:
  Terry Manderson 
  Suresh Krishnan 
 
Mailing list:
  Address: lp-...@ietf.org
  To subscribe: https://www.ietf.org/mailman/listinfo/lp-wan
  Archive: https://mailarchive.ietf.org/arch/browse/lp-wan/

Charter: https://datatracker.ietf.org/doc/charter-ietf-lpwan/

A new generation of wireless technologies has emerged under the generic 
name of Low-Power Wide-Area (LPWA), with a number of common 
characteristics, which make these technologies unique and disruptive for 
Internet of Things applications. 

Those common traits include an optimized radio modulation, a star 
topology, frame sizes in the order of tens of bytes transmitted
a few times per day at ultra-low speeds and sometimes variable MTUs, 
and, though downstream may be supported, a mostly upstream transmission 
pattern that allows the devices to spend most of their time in low-
energy deep-sleep mode.

This enables a range of several kilometers and a long battery lifetime, 
possibly ten years operating on a single coin-cell. This also enables 
simple and scalable deployments with low-cost devices and thin 
infrastructures.

Those benefits come at a price: the layer 2 frame formats are optimized 
and specific to each individual technology. There is no network layer 
and the application is often hard wired to the layer 2 frame format, 
leading to siloed deployments that must be managed, secured and operated 
individually. Migrating from one LPWA technology to another implies 
rebuilding the whole chain.

To unleash the full power of LPWA technologies and their ecosystems, 
there is a need to couple them with other ecosystems that will guarantee 
the inter-working by introducing a network layer, and enable common 
components for management and security, as well as shared application 
profiles. The IETF can contribute by providing IPv6 connectivity, and 
propose technologies to secure the operations and manage the devices and 
their gateways.

The Working Group will focus on enabling IPv6 connectivity over the 
following selection of Low-Power Wide-Area technologies: SIGFOX, LoRa, 
WI-SUN and NB-IOT.

These technologies present similar characteristics of rare and widely 
unbalanced over-the-air transmissions, with little capability to alter 
the frame formats to accommodate this work, which makes it so that 
existing IETF work (6lo) cannot be trivially applied.

The Working Group will leverage cross-participation with the associated 
set of stakeholders to ensure that the work taking place corresponds to 
real demands and that the proposed solutions are indeed applicable. 

The group will produce informational work describing LPWA
technologies and their needs as well as new standard work to optimize 
IPv6-based communications to the end device

The group will:

1. Produce an Informational document describing and relating some 
selected LPWA technologies. This work will document the common 
characteristics and highlight actual needs that the IETF could serve; 
but it is not intended to provide a competitive analysis. It is expected 
that the information contained therein originates from and is reviewed 
by people who work on the respective LPWA technologies.

2. Produce a Standards Track document to enable the compression and 
fragmentation of a CoAP/UDP/IPv6 packet over LPWA networks. This will be 
achieved through stateful mechanisms, specifically designed for star 
topology and severely constrained links. The work will include the 
definition of generic data models to describe the compression and 
fragmentation contexts. This work may also include to define technology-
specific adaptations of the generic compression/fragmentation mechanism 
wherever necessary.


Milestones:
  Nov 2016 - Adopt LPWAN specifications as WG item
  Dec 2016 - Adopt IP/UDP compression and fragmentation mechanism as a WG
item
  Jan 2017 - Adopt  CoAP compression mechanism as a WG item
  Apr 2017 - Submit LPWAN specification to the IESG for publication as an
Informational Document 
  May 2017 - Submit IP/UDP compression and fragmentation mechanism to the
IESG for publication as a Proposed Standard
  Jul 2017 - Submit CoAP compression mechanism to the IESG for
publication as a Proposed Standard