Constrained RESTful Environments (core) WG Interim Meeting Cancelled (was 2022-06-22)

[IESG Secretary]

The Constrained RESTful Environments (core) virtual 
interim meeting for 2022-06-22 from 16:00 to 17:30 Europe/Stockholm
has been cancelled.





___
IETF-Announce mailing list
IETF-Announce@ietf.org
https://www.ietf.org/mailman/listinfo/ietf-announce

BCP 45, RFC 9245 on IETF Discussion List Charter

[rfc-editor]

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

BCP 45
RFC 9245

Title:  IETF Discussion List Charter 
Author: L. Eggert,
S. Harris
Status: Best Current Practice
Stream: IETF
Date:   June 2022
Mailbox:l...@eggert.org
Pages:  7
Obsoletes:  RFC 3005
Updates:RFC 3683
See Also:   BCP 45

I-D Tag:draft-eggert-bcp45bis-08.txt

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

DOI:10.17487/RFC9245

The Internet Engineering Task Force (IETF) discussion mailing list
furthers the development and specification of Internet technology
through the general discussion of technical, procedural, operational,
and other topics for which no dedicated mailing lists exist. As this
is the most general IETF mailing list, considerable latitude in terms
of topics is allowed, but there are posts and topics that are
unsuitable for this mailing list. This document defines the charter
for the IETF discussion list and explains its scope.

This document obsoletes RFC 3005 and updates RFC 3683.


BCP: This document specifies an Internet Best Current Practices for the
Internet Community, and requests discussion and suggestions for 
improvements. 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-Announce mailing list
IETF-Announce@ietf.org
https://www.ietf.org/mailman/listinfo/ietf-announce

RFC 9243 on A YANG Data Model for DHCPv6 Configuration

[rfc-editor]

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


RFC 9243

Title:  A YANG Data Model for 
DHCPv6 Configuration 
Author: I. Farrer, Ed.
Status: Standards Track
Stream: IETF
Date:   June 2022
Mailbox:ian.far...@telekom.de
Pages:  92
Updates/Obsoletes/SeeAlso:   None

I-D Tag:draft-ietf-dhc-dhcpv6-yang-25.txt

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

DOI:10.17487/RFC9243

This document describes YANG data models for the configuration and
management of Dynamic Host Configuration Protocol for IPv6 (DHCPv6)
(RFC 8415) servers, relays, and clients.

This document is a product of the Dynamic Host Configuration 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-Announce mailing list
IETF-Announce@ietf.org
https://www.ietf.org/mailman/listinfo/ietf-announce

RFP for UI/UX Services

[IETF Executive Director]

The IETF Administration LLC is soliciting bids for UI/UX Services.

Overview:

The IETF has a web presence spanning multiple sites controlled by different 
bodies within the IETF and with different but overlapping sets of purposes and 
users.  The sites use a range of underlying platforms and content/design 
management processes.  The most actively used sites are developed and 
maintained by in-house and contracted developers.  Some of these sites have 
been through a design refresh that incorporates user experience objectives, 
while others have grown entirely organically.

The IETF is seeking a specialist UI/UX service provider to support our 
developers and content managers in all aspects of UI/UX with a view to driving 
a significant improvement in the user experience of these sites.  We expect 
this assistance to include formally scoped projects and ad-hoc advice and 
consultancy.  The initial term of the contract will be for three years with the 
option to renew for a further three year term by mutual agreement.

Timeline:

21 June 2022 RFP Issued
06 July 2022 Questions and Inquiries deadline
13 July 2022 Answers to questions issued and RFP updated if required
03 August 2022   Bids due
17 August 2022   Preferred bidder selected and negotiations begin
31 August 2022   Contract execution and work begins

Bids are due by 22:00 UTC on the day noted above.


Full details of the RFP, including instructions on how to submit a bid and how 
to ask questions, can be found at 
https://www.ietf.org/about/administration/rfps/.

Please note that in order to maintain a fair and transparent RFP process, all 
questions or feedback regarding this RFP should be made to the email address 
specified in the RFP.

-- 
Jay Daley
IETF Executive Director
exec-direc...@ietf.org

___
IETF-Announce mailing list
IETF-Announce@ietf.org
https://www.ietf.org/mailman/listinfo/ietf-announce

Seeking volunteers for NomCom

[NomCom Chair 2022]

The IETF NomCom appoints people to fill the open slots on the IETF LLC, IETF
Trust, the IAB, and the IESG.  Ten voting members for the NomCom are selected
in a verifiably random way from a pool of volunteers. The more volunteers,
the better chance we have of choosing a random yet representative cross
section of the IETF population.

To volunteer click on this link: ttps://datatracker.ietf.org/nomcom/volunteer
Note that if you are selected for NomCom you are ineligble to be a candidate
for any position.

The primary activity for this NomCom will begin in shortly after IETF 114 in
July 2021 and should be completed by January 2022.  The NomCom will have
regularly scheduled conference calls to ensure progress. There will be
activities to collect requirements from the community, review candidate
responses, review feedback from community members about candidates, and
talk to candidates.

The details of the operation of the NomCom can be found in RFC 8713. RFC 3797
details the selection algorithm. Note that the IESG has already decided to
repeat the experiment detailed in RFC 8989 for this cycle. That is, in
addition to the traditional "Path 1" of eligibility (three out of the last
five meetings), there are two other ways to become eligible:
Path 2. WG chair or Secretary within the past three years
Path 3. Author of Editor (as listed on the front page) of two
   IETF stream RFC's within the past five years. An approved
   draft in the RFC Editor queue counts as an RFC.

Last year, there were no NomCom members from Path 2 or Path 3.  If you
qualify under those criteria, please consider volunteering.  The list of
positions will be announced soon, well before the NomCom is chosen, so you
can "back out" if you need to.

You can check your eligibility by logging in and viewing your profile page at
https://datatracker.ietf.org/accounts/profile/ Note that the code is being
reviewed, so if you dispute it please let me know.  Again, should you wish
To volunteer, click on this link: https://datatracker.ietf.org/nomcom/volunteer

While being a NomCom member does require some time commitment it is also
immeasurably important to the short-term future of the IETF.  I hope that one
outcome from this year's NomCom is that future volunteers will have much
better information about the commitment.  All NomCom meetings and candidate
interviews will be hybrid (a mix of virtual and remote).

You can find a detailed timeline on the NomCom web site shortly:
https://datatracker.ietf.org/nomcom/2022/

Within the next week or two, I will add more details on the timeline, as
well as details of the randomness seeds to be used for the RFC 3797
selection process.
   
Thank you! I will be in-person for IETF 114 (arriving Saturday, leaving early 
Friday morning) if you want to chat.

Rich Salz
nomcom-chair-2...@ietf.org

___
IETF-Announce mailing list
IETF-Announce@ietf.org
https://www.ietf.org/mailman/listinfo/ietf-announce

Document Action: 'Recommendations on the Filtering of IPv6 Packets Containing IPv6 Extension Headers at Transit Routers' to Informational RFC (draft-ietf-opsec-ipv6-eh-filtering-10.txt)

[The IESG]

The IESG has approved the following document:
- 'Recommendations on the Filtering of IPv6 Packets Containing IPv6
   Extension Headers at Transit Routers'
  (draft-ietf-opsec-ipv6-eh-filtering-10.txt) as Informational RFC

This document is the product of the Operational Security Capabilities for IP
Network Infrastructure Working Group.

The IESG contact persons are Warren Kumari and Robert Wilton.

A URL of this Internet Draft is:
https://datatracker.ietf.org/doc/draft-ietf-opsec-ipv6-eh-filtering/





Technical Summary

   This document analyzes both
   the general security implications of IPv6 Extension Headers and the
   specific security implications of each Extension Header and Option
   type.  Additionally, it discusses the operational and
   interoperability implications of discarding packets based on the IPv6
   Extension Headers and IPv6 options they contain.  Finally, it
   provides advice on the filtering of such IPv6 packets at transit
   routers for traffic *not* directed to them, for those cases in which
   such filtering is deemed as necessary.

Working Group Summary

  At the beginning, there was a controversy about filtering in the Internet.
  The authors took the right decisions to limit the purpose of the document to
   transit routers as well as using a black list approach (in order to prevent 
the ossification).

  The OPSEC WG consensus is that it is a useful document (albeit informational 
only) and 
  the current approach is the right one. 

 The WGLC was sent to OpSec, 6MAN and V6OPS t oget better coverage:
 

Document Quality

   The document is clear and easy to read. There are some minor nits / typos,
  but (unusually) I decided it wasn't worth asking for a respin for these.

Personnel

   The document shepherd is Eric Vyncke.
   Warren Kumari is RAD!

___
IETF-Announce mailing list
IETF-Announce@ietf.org
https://www.ietf.org/mailman/listinfo/ietf-announce

Protocol Action: 'The Resource Public Key Infrastructure (RPKI) to Router Protocol, Version 2' to Proposed Standard (draft-ietf-sidrops-8210bis-10.txt)

[The IESG]

The IESG has approved the following document:
- 'The Resource Public Key Infrastructure (RPKI) to Router Protocol,
   Version 2'
  (draft-ietf-sidrops-8210bis-10.txt) as Proposed Standard

This document is the product of the SIDR Operations Working Group.

The IESG contact persons are Warren Kumari and Robert Wilton.

A URL of this Internet Draft is:
https://datatracker.ietf.org/doc/draft-ietf-sidrops-8210bis/





Technical Summary

   This document, which updates RFC 8210, describes version 2 of the 
RPKI-Router protocol 
   (RFC 6810 described version 0, and RFC 8210 described version 1).

   In order to verifiably validate the origin Autonomous Systems and
   Autonomous System Paths of BGP announcements, routers need a simple
   but reliable mechanism to receive Resource Public Key Infrastructure
   (RFC 6480) prefix origin data and router keys from a trusted cache.


Working Group Summary

  This -bis document got some solid review in WG mailing-list discussions, 
nothing stood out as controversial.
  After the IETF LC the authors addressed the directorate reviews. Mohamed 
Boucadair's routing directorate review
  pointed out that there were changes to flags definitions in 8210bis, which 
required a change to this document. 
  This was discussed with the WG 
(https://mailarchive.ietf.org/arch/msg/sidrops/3gCFV9yj5dHxljFP8ksNTLe1w8M/) 
and 
  the least bad option selected.


Document Quality

There are existing implementations for the rpki-rtr protocol, this -bis changes 
the protocol version, and adds support for
ASPA PDU types, and fixes some race-conditions in ROA PDUs. 

Personnel

  Chris Morrow (morr...@ops-netman.net) is DS
  Warren Kumari (war...@kumari.net) is RAD!

___
IETF-Announce mailing list
IETF-Announce@ietf.org
https://www.ietf.org/mailman/listinfo/ietf-announce