headers
The IESG | 10 Feb 01:38
Picon
Favicon

Last Call: <draft-desruisseaux-caldav-sched-10.txt> (CalDAV Scheduling Extensions to WebDAV) to Proposed Standard


The IESG has received a request from an individual submitter to consider
the following document:
- 'CalDAV Scheduling Extensions to WebDAV'
  <draft-desruisseaux-caldav-sched-10.txt> as a 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
ietf <at> ietf.org mailing lists by 2012-03-08. Exceptionally, comments may be
sent to iesg <at> ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract

   This document defines extensions to the CalDAV "calendar-access"
   feature to specify a standard way of performing scheduling
   transactions with iCalendar-based calendar components.  This document
   defines the "calendar-auto-schedule" feature of CalDAV.

The file can be obtained via
http://datatracker.ietf.org/doc/draft-desruisseaux-caldav-sched/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-desruisseaux-caldav-sched/

No IPR declarations have been submitted directly on this I-D.
Permalink | Reply | 0 comments |
headers
The IESG | 10 Feb 00:40
Picon
Favicon

Last Call: <draft-ietf-pcn-3-in-1-encoding-08.txt> (Encoding 3 PCN-States in the IP header using a single DSCP) to Proposed Standard


The IESG has received a request from the Congestion and Pre-Congestion
Notification WG (pcn) to consider the following document:
- 'Encoding 3 PCN-States in the IP header using a single DSCP'
  <draft-ietf-pcn-3-in-1-encoding-08.txt> as a 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
ietf <at> ietf.org mailing lists by 2012-02-23. Exceptionally, comments may be
sent to iesg <at> ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract

   The objective of Pre-Congestion Notification (PCN) is to protect the
   quality of service (QoS) of inelastic flows within a Diffserv domain.
   The overall rate of the PCN-traffic is metered on every link in the
   PCN domain, and PCN-packets are appropriately marked when certain
   configured rates are exceeded.  Egress nodes pass information about
   these PCN-marks to decision points which then decide whether to admit
   or block new flow requests or to terminate some already-admitted
   flows during serious pre-congestion.

   This document specifies how PCN-marks are to be encoded into the IP
   header by re-using the Explicit Congestion Notification (ECN)
   codepoints within a PCN-domain.  This encoding provides for up to
   three different PCN marking states using a single DSCP: not-marked
   (NM), threshold-marked (ThM) and excess-traffic-marked (ETM).  Hence,
   it is called the 3-in-1 PCN encoding.  This document obsoletes
   RFC5696.
(Continue reading)

Permalink | Reply | 0 comments |
headers
The IESG | 10 Feb 00:39
Picon
Favicon

Document Action: 'The 'disclosure' Link Relation Type' to Informational RFC (draft-yevstifeyev-disclosure-relation-02.txt)

The IESG has approved the following document:
- 'The 'disclosure' Link Relation Type'
  (draft-yevstifeyev-disclosure-relation-02.txt) as an Informational RFC

This document has been reviewed in the IETF but is not the product of an
IETF Working Group.

The IESG contact person is Peter Saint-Andre.

A URL of this Internet Draft is:
http://datatracker.ietf.org/doc/draft-yevstifeyev-disclosure-relation/

Technical Summary

   RFC 5988 standardized a means of indicating the relationships
   between resources on the Web. This document specifies the 
   'disclosure' Link Relation Type.  It designates a list of patent 
   disclosures or a particular patent disclosure itself made with 
   respect to material for which such relation type is specified.

Working Group Summary

   This document is not the product of a working group.  It emerged
   from discussion on the link-relations <at> ietf.org list and received
   review there and on the apps-discuss <at> ietf.org list. No objections
   were raised and there was no controversy about publication.

Document Quality

   Reviews occurred on the link-relations <at> ietf.org list, resulting in
(Continue reading)

Permalink | Reply | 0 comments |
headers
The IESG | 10 Feb 00:20
Picon
Favicon

Last Call: <draft-ietf-l3vpn-mvpn-wildcards-02.txt> (Wildcards in Multicast VPN Auto-Discovery Routes) to Proposed Standard


The IESG has received a request from the Layer 3 Virtual Private Networks
WG (l3vpn) to consider the following document:
- 'Wildcards in Multicast VPN Auto-Discovery Routes'
  <draft-ietf-l3vpn-mvpn-wildcards-02.txt> as a 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
ietf <at> ietf.org mailing lists by 2012-02-23. Exceptionally, comments may be
sent to iesg <at> ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract

   In "Multicast Virtual Private Networks" (MVPNs), customer multicast
   flows are carried in "tunnels" through a service provider's network.
   The base specifications for MVPN define BGP multicast VPN
   "auto-discovery routes", and specify how to use an auto-discovery
   route to advertise the fact that an individual customer multicast
   flow is being carried in a particular tunnel.  However, those
   specifications do not provide a way to specify, in a single such
   route, that multiple customer flows are being carried in a single
   tunnel.  Those specifications also do not provide a way to advertise
   that a particular tunnel is to be used by default to carry all
   customer flows, except in the case where that tunnel is joined by all
   the provider edge routers of the MVPN.  This document eliminates
   these restrictions by specifying the use of "wildcard" elements in
   the customer flow identifiers.  With wildcard elements, a single
   auto-discovery route can refer to multiple customer flows, or even to
   all customer flows.
(Continue reading)

Permalink | Reply | 0 comments |
headers
The IESG | 9 Feb 23:52
Picon
Favicon

Last Call: <draft-ietf-pcn-encoding-comparison-08.txt> (Overview of Pre-Congestion Notification Encoding) to Informational RFC


The IESG has received a request from the Congestion and Pre-Congestion
Notification WG (pcn) to consider the following document:
- 'Overview of Pre-Congestion Notification Encoding'
  <draft-ietf-pcn-encoding-comparison-08.txt> as an Informational RFC

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
ietf <at> ietf.org mailing lists by 2012-02-23. Exceptionally, comments may be
sent to iesg <at> ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract

   The objective of Pre-Congestion Notification (PCN) is to protect the
   quality of service (QoS) of inelastic flows within a Diffserv domain.
   On every link in the PCN domain, the overall rate of the PCN-traffic
   is metered, and PCN-packets are appropriately marked when certain
   configured rates are exceeded.  Egress nodes provide decision points
   with information about the PCN-marks of PCN-packets which allows them
   to take decisions about whether to admit or block a new flow request,
   and to terminate some already admitted flows during serious pre-
   congestion.

   The PCN Working Group explored a number of approaches for encoding
   this pre-congestion information into the IP header.  This document
   provides details of all those approaches along with an explanation of
   the constraints that had to be met by any solution.

The file can be obtained via
(Continue reading)

Permalink | Reply | 0 comments |
headers
internet-drafts | 9 Feb 21:19
Picon
Favicon

I-D Action: draft-ietf-krb-wg-pad-01.txt


A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item
of the Kerberos Working Group of the IETF.

	Title           : POSIX Authorization Data
	Author(s)       : Simo Sorce
                          Tom Yu
                          Thomas Hardjono
	Filename        : draft-ietf-krb-wg-pad-01.txt
	Pages           : 16
	Date            : 2012-02-09

   This document proposes a Kerberos Authorization Data element
   containing user and group directory information similar to that
   provided by RFC 2307, typically used by POSIX and POSIX-like systems
   in the course of login type activities.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-krb-wg-pad-01.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

This Internet-Draft can be retrieved at:
ftp://ftp.ietf.org/internet-drafts/draft-ietf-krb-wg-pad-01.txt
Permalink | Reply | 0 comments |
headers
internet-drafts | 9 Feb 21:17
Picon
Favicon

I-D Action: draft-ietf-krb-wg-cammac-01.txt


A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item
of the Kerberos Working Group of the IETF.

	Title           : Container Authenticated by Multiple MACs
	Author(s)       : Simo Sorce
                          Tom Yu
                          Thomas Hardjono
	Filename        : draft-ietf-krb-wg-cammac-01.txt
	Pages           : 7
	Date            : 2012-02-09

   Abstract: This document proposes a Kerberos Authorization Data
   container similar to AD-KDC-ISSUED, but that allows for multiple MACs
   or signatures on the contained Authorization Data elements.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-krb-wg-cammac-01.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

This Internet-Draft can be retrieved at:
ftp://ftp.ietf.org/internet-drafts/draft-ietf-krb-wg-cammac-01.txt
Permalink | Reply | 0 comments |
headers
internet-drafts | 9 Feb 21:03
Picon
Favicon

I-D Action: draft-iab-rfc-editor-model-v2-03.txt


A New Internet-Draft is available from the on-line Internet-Drafts directories.

	Title           : RFC Editor Model (Version 2)
	Author(s)       : Olaf M. Kolkman
                          Joel M. Halpern
	Filename        : draft-iab-rfc-editor-model-v2-03.txt
	Pages           : 20
	Date            : 2012-02-09

   The RFC Editor performs a number of functions that may be carried out
   by various people or entities.  The RFC Editor model described in
   this document divides the responsibilities for the RFC Series into
   three functions: The RFC Series Editor, the RFC Production Center,
   and the RFC Publisher.  The Internet Architecture Board (IAB)
   oversight by way of delegation to the RFC Series Oversight Committee
   (RSOC) is described, as is the relationship between the IETF
   Administrative Oversight Committee (IAOC) and the RSOC.  This
   document reflects the experience gained with RFC Editor Model version
   1, documented in [RFC5620] and obsoletes that document.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-iab-rfc-editor-model-v2-03.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

This Internet-Draft can be retrieved at:
ftp://ftp.ietf.org/internet-drafts/draft-iab-rfc-editor-model-v2-03.txt
(Continue reading)

Permalink | Reply | 0 comments |
headers
internet-drafts | 9 Feb 20:57
Picon
Favicon

I-D Action: draft-ietf-krb-wg-cammac-00.txt


A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item
of the Kerberos Working Group of the IETF.

	Title           : Container Authenticated by Multiple MACs
	Author(s)       : Simo Sorce
                          Tom Yu
                          Thomas Hardjono
	Filename        : draft-ietf-krb-wg-cammac-00.txt
	Pages           : 7
	Date            : 2012-02-09

   This draft proposes a new Authorization Data container for the
   Kerberos V5 protocol.  This container allows to Authenticate the
   contents using multiple MACs

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-krb-wg-cammac-00.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

This Internet-Draft can be retrieved at:
ftp://ftp.ietf.org/internet-drafts/draft-ietf-krb-wg-cammac-00.txt
Permalink | Reply | 0 comments |
headers
internet-drafts | 9 Feb 20:55
Picon
Favicon

I-D Action: draft-ietf-krb-wg-pad-00.txt


A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item
of the Kerberos Working Group of the IETF.

	Title           : Principal Authorization Data Containers
	Author(s)       : Simo Sorce
                          Tom Yu
                          Thomas Hardjono
	Filename        : draft-ietf-krb-wg-pad-00.txt
	Pages           : 17
	Date            : 2012-02-09

   This draft proposes a generalized authorization structure to transmit
   authorization data for the Kerberos V5 protocol.  Such an
   authorization structure would allow for greater interoperability
   among directory services and other related Kerberos services across
   differing realms.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-krb-wg-pad-00.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

This Internet-Draft can be retrieved at:
ftp://ftp.ietf.org/internet-drafts/draft-ietf-krb-wg-pad-00.txt
Permalink | Reply | 0 comments |
headers
internet-drafts | 9 Feb 20:45
Picon
Favicon

I-D Action: draft-ietf-l3vpn-mvpn-wildcards-02.txt


A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item
of the Layer 3 Virtual Private Networks Working Group of the IETF.

	Title           : Wildcards in Multicast VPN Auto-Discovery Routes
	Author(s)       : Eric C. Rosen
                          Yakov Rekhter
                          Ray (Lei) Qiu
	Filename        : draft-ietf-l3vpn-mvpn-wildcards-02.txt
	Pages           : 18
	Date            : 2012-02-09

   In "Multicast Virtual Private Networks" (MVPNs), customer multicast
   flows are carried in "tunnels" through a service provider's network.
   The base specifications for MVPN define BGP multicast VPN
   "auto-discovery routes", and specify how to use an auto-discovery
   route to advertise the fact that an individual customer multicast
   flow is being carried in a particular tunnel.  However, those
   specifications do not provide a way to specify, in a single such
   route, that multiple customer flows are being carried in a single
   tunnel.  Those specifications also do not provide a way to advertise
   that a particular tunnel is to be used by default to carry all
   customer flows, except in the case where that tunnel is joined by all
   the provider edge routers of the MVPN.  This document eliminates
   these restrictions by specifying the use of "wildcard" elements in
   the customer flow identifiers.  With wildcard elements, a single
   auto-discovery route can refer to multiple customer flows, or even to
   all customer flows.

A URL for this Internet-Draft is:
(Continue reading)

Permalink | Reply | 0 comments |

Gmane