RFC Series Editor Nominees (Feedback Requested) and Independent Stream Editor Process

2009-08-14 Thread IAB Chair



Dear Colleagues,


With reference to the call for nominations [1,2] for an RFC Series
Editor (RSE) and Independent Stream Editor (ISE) and the extension for
the of the call [3], there are two two things I would like to bring to
your attention.


= RFC Series Editor Nominations

I would like to inform you that at the close of the extended
nomination period  we received 4 nominations:


  - Shreedeep Rayamajhi
  - Paul Hoffman
  - David E. Martin
  - Ole Jacobsen


The IAB invites community feedback on these candidates, specifically
in relation to the how the expertise and profile of the candidates
maps to the function as described in
http://iaoc.ietf.org/rfced-procurement.html and
http://tools.ietf.org/html/draft-iab-rfc-editor-model

Please send your feedback to the Ad Hoc Advisory Committee (ACEF)
 by August 23, 2009. Your feedback will be shared with
the members (see [4]) of the ACEF and, at a later stage, with the IAB.

We understand there may be potential candidates that are still
contemplating 
their nomination. Therefore, and without reflection on the current
candidates, 
we will continue to entertain nominations for the RSE position for a short
time.


= Independent Series Editor Nominations and selection process


After consulting with the ACEF (who assist the IAB in the selection of
candidates) the IAB has decided that we will first work through the
RSE candidates and then proceed with assessment of the ISE candidates.
Nominations for the ISE are still welcome during the period in which
the ACEF is formulating its advice on the RSE appointment. Please
refer to [2] for the exact nomination procedure.


The timeline for the selection of the RSE remains as published in our
extensions for the call[2] while the timeline for the selection and
appointment of the ISE will shift a little more than a month. This may
mean that there is little or no overlapping time for transition of the
ISE. While

this is not the optimum situation, the IAB and the ACEF believe that
there will not be significant problems by shifting the timescale and
thereby potentially not having an overlap.

Modified ISE timeline:

 1st week of October - ISE Nominees announced; community input solicited
   
 mid-October - Community input ends

 mid-October through end October - IAB appointed Advisory Committee
conducts interviews

 begin November - Advisory Committee recommends individuals to IAB for
  ISE position

 mid November - IAB appoints ISE

 end Nov - Agreement Executed with IAD for expenses and transition begins


 1 Jan - Appointments take effect




With kind regards,

--Olaf Kolkman

  IAB chair.



[1] RSE call for nomination:
   
http://www.ietf.org/mail-archive/web/ietf-announce/current/msg06167.html

[2] ISE call for nomination:
   
http://www.ietf.org/mail-archive/web/ietf-announce/current/msg06168.html

[3] Extension of the call for nominations:
   
http://www.ietf.org/mail-archive/web/ietf-announce/current/msg06303.html

[4] RFC Editor related appointments:
   
http://www.ietf.org/mail-archive/web/ietf-announce/current/msg06260.html
___
IETF-Announce mailing list
IETF-Announce@ietf.org
https://www.ietf.org/mailman/listinfo/ietf-announce


Last Call: draft-ietf-sipcore-presence-scaling-requirements (Scaling Requirements for Presence in SIP/SIMPLE) to Informational RFC

2009-08-14 Thread The IESG
The IESG has received a request from the Session Initiation Protocol Core 
WG (sipcore) to consider the following document:

- 'Scaling Requirements for Presence in SIP/SIMPLE '
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
i...@ietf.org mailing lists by 2009-08-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.

The file can be obtained via
http://www.ietf.org/internet-drafts/draft-ietf-sipcore-presence-scaling-requirements-01.txt


IESG discussion can be tracked via
https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=18507&rfc_flag=0

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


RFC 5613 on OSPF Link-Local Signaling

2009-08-14 Thread rfc-editor

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


RFC 5613

Title:  OSPF Link-Local Signaling 
Author: A. Zinin, A. Roy,
L. Nguyen, B. Friedman,
D. Yeung
Status: Standards Track
Date:   August 2009
Mailbox:alex.zi...@alcatel-lucent.com, 
a...@cisco.com, 
lhngu...@cisco.com,
bar...@google.com, 
mye...@cisco.com
Pages:  12
Characters: 23092
Obsoletes:  RFC4813

I-D Tag:draft-ietf-ospf-lls-08.txt

URL:http://www.rfc-editor.org/rfc/rfc5613.txt

OSPF is a link-state intra-domain routing protocol.  OSPF routers
exchange information on a link using packets that follow a
well-defined fixed format.  The format is not flexible enough to
enable new features that need to exchange arbitrary data.  This
document describes a backward-compatible technique to perform
link-local signaling, i.e., exchange arbitrary data on a link.  This
document replaces the experimental specification published in RFC 4813
to bring it on the Standards Track.

This document is a product of the Open Shortest Path First IGP Working Group of 
the IETF.

This is now a Proposed Standard Protocol.

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 Internet
Official Protocol Standards (STD 1) 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
  http://www.ietf.org/mailman/listinfo/ietf-announce
  http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist

For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html.
For downloading RFCs, see http://www.rfc-editor.org/rfc.html.

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
USC/Information Sciences Institute


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


RFC 5614 on Mobile Ad Hoc Network (MANET) Extension of OSPF Using Connected Dominating Set (CDS) Flooding

2009-08-14 Thread rfc-editor

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


RFC 5614

Title:  Mobile Ad Hoc Network (MANET) 
Extension of OSPF Using Connected Dominating 
Set (CDS) Flooding 
Author: R. Ogier, P. Spagnolo
Status: Experimental
Date:   August 2009
Mailbox:rich.og...@earthlink.net, 
phillipspagn...@gmail.com
Pages:  71
Characters: 170106
Updates/Obsoletes/SeeAlso:   None

I-D Tag:draft-ietf-ospf-manet-mdr-05.txt

URL:http://www.rfc-editor.org/rfc/rfc5614.txt

This document specifies an extension of OSPFv3 to support mobile ad
hoc networks (MANETs).  The extension, called OSPF-MDR, is designed
as a new OSPF interface type for MANETs.  OSPF-MDR is based on the
selection of a subset of MANET routers, consisting of MANET
Designated Routers (MDRs) and Backup MDRs.  The MDRs form a connected
dominating set (CDS), and the MDRs and Backup MDRs together form a
biconnected CDS for robustness.  This CDS is exploited in two ways.
First, to reduce flooding overhead, an optimized flooding procedure
is used in which only (Backup) MDRs flood new link state
advertisements (LSAs) back out the receiving interface; reliable
flooding is ensured by retransmitting LSAs along adjacencies.
Second, adjacencies are formed only between (Backup) MDRs and a
subset of their neighbors, allowing for much better scaling in dense
networks.  The CDS is constructed using 2-hop neighbor information
provided in a Hello protocol extension.  The Hello protocol is
further optimized by allowing differential Hellos that report only
changes in neighbor states.  Options are specified for originating
router-LSAs that provide full or partial topology information,
allowing overhead to be reduced by advertising less topology
information.  This memo defines an Experimental Protocol for the 
Internet community.

This document is a product of the Open Shortest Path First IGP Working Group of 
the IETF.


EXPERIMENTAL: This memo defines an Experimental Protocol for the
Internet community.  It does not specify an Internet standard of any
kind. Discussion and suggestions for improvement are requested.
Distribution of this memo is unlimited.

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

For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html.
For downloading RFCs, see http://www.rfc-editor.org/rfc.html.

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
USC/Information Sciences Institute


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