Re: Informational RFC to be:

[The IESG]

The IESG has no problem with the publication of 'Media Description for
IKE in the Session Description Protocol (SDP)'
 as an Informational RFC.

The IESG would also like the RFC-Editor to review the comments in
the datatracker
(http://datatracker.ietf.org/doc/draft-saito-mmusic-sdp-ike/) related to
this document and determine whether or not they merit incorporation into
the document. Comments may exist in both the ballot and the comment log.

A URL of this Internet Draft is:
http://datatracker.ietf.org/doc/draft-saito-mmusic-sdp-ike/

The process for such documents is described at
http://www.rfc-editor.org/indsubs.html

Thank you,

The IESG Secretary



Technical Summary
  This document specifies how to establish a media session which
   represents a virtual private network using Session Initiation
   Protocol for the purpose of on-demand media/application sharing
   between peers.  It extends the protocol identifier of Session
   Description Protocol (SDP) so that it can negotiate the use of
   Internet Key Exchange Protocol (IKE) for media sessions in the SDP
   offer/answer model.  It also specifies a method to boot up IKE and
   generate IPsec security associations using a self-signed certificate.

Working Group Summary

   The document is an individual submission to the RFC Editor. 

Personnel

   Robert Sparks coordinated the RFC5742 IESG review.

IESG Note

  The IESG has concluded that this work is related to IETF work done
   in the MMUSIC working group, but this relationship does not prevent 
publishing.
___
IETF-Announce mailing list
IETF-Announce@ietf.org
https://www.ietf.org/mailman/listinfo/ietf-announce

Document Action: 'Requirements for a Protocol to Replace AppleTalk NBP' to Informational RFC (draft-cheshire-dnsext-nbp-09.txt)

[The IESG]

The IESG has approved the following document:
- 'Requirements for a Protocol to Replace AppleTalk NBP'
  (draft-cheshire-dnsext-nbp-09.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 Ralph Droms.

A URL of this Internet Draft is:
http://datatracker.ietf.org/doc/draft-cheshire-dnsext-nbp/



Technical Summary

   One of the goals of the authors of Multicast DNS (mDNS) and DNS-Based
   Service Discovery (DNS-SD) was the desire to retire AppleTalk and the
   AppleTalk Name Binding Protocol, and to replace them with an IP-based
   solution. This document presents a brief overview of the capabilities
   of AppleTalk NBP, and outlines the properties required of an IP-based
   replacement.

Working Group Summary

   This was originally slated for the ZeroConf Working Group, 
   though was abandoned a long time ago. This requirements
   document is part of the "Bonjour" protocol set from Apple,
   which is now fairly widely used with multiple interoperable
   implementations. This is being published for the good of
   those in the community that wish to have a stable reference
   of how the protocol works, and why it was designed the way
   it was. 

Document Quality
   
   An earlier revision of this document  was reviewed by the IETF
   and the IESG.  The current revision has been updated based
   on feedback from the earlier reviews.  Ralph Droms reviewed
   the current revision.

Personnel
   
   Ralph Droms is the responsible AD. 
___
IETF-Announce mailing list
IETF-Announce@ietf.org
https://www.ietf.org/mailman/listinfo/ietf-announce

Document Action: 'IPFIX Mediation: Framework' to Informational RFC (draft-ietf-ipfix-mediators-framework-09.txt)

[The IESG]

The IESG has approved the following document:
- 'IPFIX Mediation: Framework'
  (draft-ietf-ipfix-mediators-framework-09.txt) as an Informational RFC

This document is the product of the IP Flow Information Export Working
Group.

The IESG contact persons are Dan Romascanu and Ron Bonica.

A URL of this Internet Draft is:
http://datatracker.ietf.org/doc/draft-ietf-ipfix-mediators-framework/



Technical Summary

   This document describes a framework for IPFIX Mediation.  This
   framework extends the IPFIX reference model by defining the IPFIX
   Mediator components.

Working Group Summary

   The mediation framework was added to the IPIFX charter in 2008.
   There is a strong consensus in the IPFIX WG to publish this version
   of the document. The document had multiple individual reviews from key 
   WG members during two WG last calls. Several comments were made 
   and have been addressed when updating the document after the WGLCs.
   There are no particular issues in the document without strong consensus 
   in the IPFIX WG.

Document Quality

   The document underwent two WG last call in the IPFIX WG.
   This way, a high document quality has been achieved already.

Personnel

   Juergen Quittek is the Document Shepherd. Dan Romascanu is the
   Responsible Area Director.

RFC Editor Note

1.  Add to the document header: 

Updates: 5470 (if approved)

2. In the Abstract:

OLD: 

This document describes a framework for IPFIX Mediation.  This
framework extends the IPFIX reference model by defining the IPFIX
Mediator components.

NEW: 

This document describes a framework for IPFIX Mediation.  This
framework extends the IPFIX reference model specified in RFC5470
by defining the IPFIX Mediator components.

3. Add RFC 5470 and RFC 5655 as Normative References

4. In Section 8: 

OLD: 

 IPFIX Mediation reuses the general information models from [RFC5102]
 and [RFC5477].  However, several Intermediate Processes would
 potentially require additional Information Elements as follows:

NEW: 

IPFIX Mediation reuses the general information models from [RFC5102]
and [RFC5477], and, depending on the Intermediate Processes type, 
potentially Information
Elements such as:

5. Append at the end of Section 5.3 the following paragraph: 

   For example, an Intermediate Aggregation Process aggregating incoming
   Flow Records composed of the sourceIPv4Address and destinationIPv4Address
   Flow Keys into outgoing Flow Records with the destinationIPv4Address
   Flow Key, must the modify the incoming flowKeyIndicator to contain only 
the
   destinationIPv4Address.

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

Document Action: 'Extending YANG with Language Abstractions' to Experimental RFC (draft-linowski-netmod-yang-abstract-05.txt)

[The IESG]

The IESG has approved the following document:
- 'Extending YANG with Language Abstractions'
  (draft-linowski-netmod-yang-abstract-05.txt) as an Experimental RFC

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

The IESG contact person is Dan Romascanu.

A URL of this Internet Draft is:
http://datatracker.ietf.org/doc/draft-linowski-netmod-yang-abstract/



Technical Summary

 YANG - the NETCONF Data Modeling Language - supports modeling of a
 tree of data elements that represent the configuration and runtime
 status of a particular network element managed via NETCONF. 
 The document defines extensions for the modeling language YANG as
  new language statements, which introduce language abstractions to
  improve the model extensibility and reuse. A model example from an
  actual network management system is given to highlight the value of 
  proposed language extensions, especially class inheritance and 
  recursiveness.  

  The draft introduces object-oriented language features like class 
  inheritance and recursiveness and enables high-level modeling 
  and mapping of YANG models seamlessly to available information 
  models like TM Forum SID. As such the draft can enable easy adoption 
  of YANG language and YANG standard moduls by other SDOs (using 
  UML as modeling language) as well as using industry information 
  models as a basis for further detailed modeling and YANG module 
  development.

Working Group Summary

  The draft has been originally submitted as an individual draft to 
  the NETMOD WG addressing the gap for language abstractions 
  noted in NETMOD WG charter as an area of future work. After 
  finalizing YANG language specification the NETMOD WG decided 
  to focus on YANG module development rather than starting 
  additional work for language extensions. 

  Based on the feedback of the WG the draft specifies valuable 
  extensions to the YANG language, thus WG members proposed 
  to publish the document as an Experimental RFC. The draft
  might become a candidate for proposed standard once an 
  IETF WG starts working on an update of the YANG language
  specification as YANG 2.0.


Document Quality

  Several YANG experts from NETMOD WG and one expert 
  from IPFIX WG reviewed different versions of the draft.
  The document has been reviewed by the editor of the 
  YANG language specification Martin Bjorlund to make sure 
  the defined YANG extensions do not conflict with the YANG 
  language.

  The language extensions defined in the document have been 
  implemented with two open source tools with different code 
  base.  These tools have been used to validate the model 
  examples through the document. 

Personnel

Mehmet Ersue is the Document Shepherd for this document.
Dan Romascanu is the Responsible Area Director.

RFC Editor Note

Abstract:

OLD:
memo suggests to enhance

NEW:
memo suggests enhancing


 Section 1:

OLD: 
After successful usage this experimental specification can be republished at 
IETF as a 
proposed standard possibly as part of a future version of YANG.

NEW:
If this experimental specification results in successful usage, it is possible 
that the 
language extension defined herein could be updated to incorporate 
implementation 
and deployment experience, then pursued on the standards track, perhaps as 
part of a future version of YANG.


Section 1.2:

OLD:
1.2. Motivation

NEW:
1.2. Motivation

Following are non-exhaustive motivation examples highlighting usage scenarios 
for 
language abstractions.

OLD: 
(e.g.  TM Forum SID)

NEW:
(e.g.  TM Forum SID [SID V8])


Section 2.9:

OLD:
 file "ietf-complex-ty...@2010-10-05.yang"

NEW:
 file "ietf-complex-ty...@2010-12-10.yang"

OLD:
 "Editor:  Bernd Linowski
   
NEW:
 "Editor:  Bernd Linowski
   


Section 4:

OLD:
   Registrant Contact: See the 'Author's Addresses' section of this
   document.

NEW:
   Registrant Contact: 
   Bernd Linowski (bernd.linowski@nsn.com)
   Mehmet Ersue (mehmet.er...@nsn.com)
   Siarhei Kuryla (s.kur...@gmail.com)


Authors' Addresses:

OLD:
   EMail: bernd.linow...@ext.nsn.com
NEW:
   EMail: bernd.linowski@nsn.com

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

Protocol Action: 'Sieve Notification Using Presence Information' to Proposed Standard (draft-ietf-sieve-notify-presence-04.txt)

[The IESG]

The IESG has approved the following document:
- 'Sieve Notification Using Presence Information'
  (draft-ietf-sieve-notify-presence-04.txt) as a Proposed Standard

This document is the product of the Sieve Mail Filtering Language Working
Group.

The IESG contact persons are Alexey Melnikov and Peter Saint-Andre.

A URL of this Internet Draft is:
http://datatracker.ietf.org/doc/draft-ietf-sieve-notify-presence/



Technical Summary

   The SIEVE notify presence extension adds an option to the notify
   extension to allow sending SIEVE notifications based on
   the presence status of the owner of the SIEVE script.

   The security considerations section covers several identified
   security concerns.

Working Group Summary

   This document has been discussed and reviewed in the SIEVE Working
   Group. There is consensus in the Working Group to publish this
   document as a Proposed Standard.

Document Quality

   Several implementers have indicated they will implement
   this extension as time allows.

Personnel

   Document Shepherd: Cyrus Daboo 
   AD: Alexey Melnikov 

RFC Editor Note

Please add a reference to RFC 3921 in the first line of section 2 paragraph 3:

   Note that, while the items below are documented as similar to items in XMPP 
[RFC3921].

Please add the following text to the end of the 3rd paragraph of Section 4:

  When caching presence tests, the server must be careful not to violate
  access controls that the presence server might have.  Thus, cached results
  MUST NOT be used outside the context in which they were retrieved.  If,
  for example, a script running on behalf of Adam requests presence 
information
  for Barbara, that information MAY be cached for a future script running on
  behalf of Adam, but MUST NOT be used to satisfy the same query in a script
  running on behalf of Cindy -- because the presence server will have to 
decide
  whether Cindy has access to that information.
___
IETF-Announce mailing list
IETF-Announce@ietf.org
https://www.ietf.org/mailman/listinfo/ietf-announce

Protocol Action: 'Prohibiting SSL Version 2.0' to Proposed Standard (draft-ietf-tls-ssl2-must-not-04.txt)

[The IESG]

The IESG has approved the following document:
- 'Prohibiting SSL Version 2.0'
  (draft-ietf-tls-ssl2-must-not-04.txt) as a Proposed Standard

This document is the product of the Transport Layer Security Working
Group.

The IESG contact persons are Alexey Melnikov and Tim Polk.

A URL of this Internet Draft is:
http://datatracker.ietf.org/doc/draft-ietf-tls-ssl2-must-not/



Technical Summary

   This document requires that when TLS clients and servers establish 
connections
   that they never negotiate the use of Secure Sockets Layer (SSL) version 2.0.

Working Group Summary

   The draft was discussed on TLS WG mailing list and presented to the TLS WG at
   IETF 78. Initially, the draft (draft-turner-ssl-must-not) contained text that
   prohibited SSL 2.0 and 3.0 and provided guidance to use TLS 1.2. Based on SSL
   server implementation statistics provided by WG members (there's lots of SSL 
3.0
   implementations) and discussions that SSL 3.0 with its mixed SHA-1/MD5 KDF is
   still acceptable, the scope of the draft was significantly reduced to only
   prohibit negotiation of SSL 2.0.

Document Quality

   SSL 2.0 has in fact already been removed from many implementations. The 
intent
   here is to formalize the retirement of SSL 2.0.

   Most of the changes were based on reviews from Paul Hoffman, Simon Josefsson,
   Marsh Ray, and Martin Rex. Other reviewers are noted in the acknowledgments
   section.

Personnel

   The document shepherd for this document is Joe Salowey .
   The responsible Area Director is Alexey Melnikov 
. 
___
IETF-Announce mailing list
IETF-Announce@ietf.org
https://www.ietf.org/mailman/listinfo/ietf-announce

Protocol Action: 'With-defaults capability for NETCONF' to Proposed Standard (draft-ietf-netconf-with-defaults-14.txt)

[The IESG]

The IESG has approved the following document:
- 'With-defaults capability for NETCONF'
  (draft-ietf-netconf-with-defaults-14.txt) as a Proposed Standard

This document is the product of the Network Configuration Working Group.

The IESG contact persons are Dan Romascanu and Ron Bonica.

A URL of this Internet Draft is:
http://datatracker.ietf.org/doc/draft-ietf-netconf-with-defaults/



Technical Summary

   The NETCONF protocol defines ways to read and edit configuration data
   from a NETCONF server.  In some cases, part of this data may not be
   set by the NETCONF client, but rather a default value known to the
   server is used instead.  In many situations the NETCONF client has a
   priori knowledge about default data, so the NETCONF server does not
   need to save it in a NETCONF configuration datastore or send it to
   the client in a retrieval operation reply.  In other situations the
   NETCONF client will need this data from the server.  Not all server
   implementations treat this default data the same way.  This document
   defines a capability-based extension to the NETCONF protocol that
   allows the NETCONF client to identify how defaults are processed by
   the server, and also defines new mechanisms for client control of
   server processing of default data.

Working Group Summary

  The working group went over several versions of the document. The
comments and
  reviews helped improve the document a lot and brought us to consensus on
the 9th
  revision of the document.

Document Quality

  There are preliminary implementations of this protocol and
  updates to comply with this spec are in plan. Others are planning to
implement
  this spec too. 

Personnel

   Bert Wijnen is the Document Shepherd.  Dan Romascanu is the 
   Responsible Area Director.

RFC Editor Note

sec 1, para 1, add missing word

OLD:

A priori knowledge can be obtained, e.g., a document formally describing the
data models supported by the NETCONF server.

NEW:


A priori knowledge can be obtained, e.g., from a document formally 
describing the
data models supported by the NETCONF server.

-

sec 1.2 point 1: change word

OLD:

The actual nodes omitted depends on the defaults handling behavior
used by the server.

NEW:

The actual nodes omitted depend on the defaults handling behavior
used by the server.  
-

sec 2, para 1, new last sentence

OLD:

Instead of forcing a single implementation strategy, this document
allows a server to advertise a particular style of defaults handling,
and the client can adjust accordingly.

NEW:

Instead of forcing a single implementation strategy, this document
allows a server to advertise a particular style of defaults handling,
and the client can adjust accordingly.  Client implementations are
expected to be powerful enough to support all three of the
server basic defaults handling modes.

-

sec 8, para 2, sentence 2: change word

OLD:

The security consideration of [I-D.ietf-netconf-4741bis] apply
to this document as well.

NEW:

The security consideration of [I-D.ietf-netconf-4741bis] applies
to this document as well.
___
IETF-Announce mailing list
IETF-Announce@ietf.org
https://www.ietf.org/mailman/listinfo/ietf-announce

Approval of image/svg+xml Media Type

[IESG Secretary]

Media Type Registration Reviews - Standards Tree/No Internet Draft
The IESG has approved a request to register the "image/svg+xml" Internet
media type in the standards tree. This media type is a product of the W3C.


The IESG contact persons are Alexey Melnikov and Peter Saint-Andre. The
registration template can be found at this location:


Comments on ietf-ty...@iana.org mailing list were received and
addressed. An archive of the discussion can be found here:




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

Protocol Action: 'IMAP LIST extension for special-use mailboxes' to Proposed Standard (draft-ietf-morg-list-specialuse-06.txt)

[The IESG]

The IESG has approved the following document:
- 'IMAP LIST extension for special-use mailboxes'
  (draft-ietf-morg-list-specialuse-06.txt) as a Proposed Standard

This document is the product of the Message Organization Working Group.

The IESG contact persons are Alexey Melnikov and Peter Saint-Andre.

A URL of this Internet Draft is:
http://datatracker.ietf.org/doc/draft-ietf-morg-list-specialuse/



Technical Summary

   Some IMAP message stores include special-use mailboxes, such as those
   used to hold draft messages or sent messages.  Many mail clients
   allow users to specify where draft or sent messages should be put,
   but configuring them requires that the user know which mailboxes the
   server has set aside for these purposes.  This extension adds new
   mailbox attributes that a server MAY include in IMAP LIST command
   responses to identify special-use mailboxes to the client, easing
   configuration.

Working Group Summary 

   There were some concerns about the number of IMAP CAPABILITY strings and
   about moving of existing special-use attributes, but there have been no
   complaints about the end result.

Document Quality 

   This extension is based on Google's XLIST extension for GMail. Google has
   expressed interest in implementing this extension as well, among several
   other server vendors. Many clients have already implemented XLIST, and they
   will either automatically or with very small modifications gain support for
   this extension

Personnel

   Timo Sirainen is the Document Shepherd for this document.
   Alexey Melnikov is the Responsible Area Director.

RFC Editor Note

In Section 7, please replace the 1st paragraph to read:

OLD:
   LIST response: There are no security issues with conveying special-
   use information to a client.

NEW:
   LIST response:
   Conveying special-use information to a client exposes a small bit of
   extra information that could be of value to an attacker.  Knowing, for
   example, that a particular mailbox contains pointers to every message
   the user has (\All) might be of particular value.  If the IMAP channel
   is not protected from passive eavesdropping, this could be an issue.

In Section 8.6:

OLD:
   Name: /shared/specialuse

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

Protocol Action: 'Mobile Ad Hoc Network (MANET) Neighborhood Discovery Protocol (NHDP)' to Proposed Standard (draft-ietf-manet-nhdp-15.txt)

[The IESG]

The IESG has approved the following document:
- 'Mobile Ad Hoc Network (MANET) Neighborhood Discovery Protocol (NHDP)'
  (draft-ietf-manet-nhdp-15.txt) as a Proposed Standard

This document is the product of the Mobile Ad-hoc Networks Working Group.

The IESG contact persons are Stewart Bryant and Adrian Farrel.

A URL of this Internet Draft is:
http://datatracker.ietf.org/doc/draft-ietf-manet-nhdp/



Technical Summary

This document describes a 1-hop and symmetric 2-hop neighborhood
discovery protocol (NHDP) for mobile ad hoc networks (MANETs).


Working Group Summary

This document contains information that was originally in OLSRv2. It
was pulled out and generalized, since it can be used in conjunction
with several of the MANET WG protocols - specifically OLSRv2, SMF,
and DYMO.

Document Quality

Several interoperable implementations of NHDP exist, and many are
publicly available. Note: that these implementations are often
bundled with OLSRv2 implementations, as NHDP is a major component of
OLSRv2.

Personnel:

Ian Chakeres (ian.chake...@gmail.com) is the document shepherd.

Stewart Bryant  is the Responsible Area Director
___
IETF-Announce mailing list
IETF-Announce@ietf.org
https://www.ietf.org/mailman/listinfo/ietf-announce