A Uniform Resource Name (URN) Namespace for the 3rd Generation Partnership Project (3GPP)
draft-monrad-sipping-3gpp-urn-namespace-03

Approval announcement
Draft of message to be sent after approval:

Announcement

From: The IESG <iesg-secretary@ietf.org>
To: IETF-Announce <ietf-announce@ietf.org>
Cc: Internet Architecture Board <iab@iab.org>,
    RFC Editor <rfc-editor@rfc-editor.org>
Subject: Document Action: 'A Uniform Resource Name (URN) 
         Namespace for the 3rd Generation Partnership Project (3GPP)' to 
         Informational RFC 

The IESG has approved the following document:

- 'A Uniform Resource Name (URN) Namespace for the 3rd Generation 
   Partnership Project (3GPP) '
   <draft-monrad-sipping-3gpp-urn-namespace-04.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 Lisa Dusseault.

A URL of this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-monrad-sipping-3gpp-urn-namespace-04.txt

Ballot Text

Technical Summary

   This document describes the Namespace Identifier (NID) for Uniform
   Resource Namespace (URN) resources published by the 3rd Generation
   Partnership Project (3GPP). 3GPP defines and manages resources that
   utilize this URN name model.  Management activities for these and
   other resource types are provided by the 3GPP Support Team.


Working Group Summary

   This is not a WG document. 

Document Quality

   This document is a URN-NID registration request.

Personnel

   The responsible Area Director is Lisa Dusseault

RFC Editor Note

  Since 3GPP will manage the registration of sub-namespaces, they 
  will need to provide a persistent URL for the registration site 
  or tables.

  Replace one sentence as follows.  OLD:

     As experimental usage is only
     intended for testing purposes, this should not be a real issue.

  NEW:
      Unregistered type values will only
      be allowed in sub-namespaces clearly marked as experimental,
      to help implementors avoid "leaking" experimental values into
      real use.

RFC Editor Note