Geographic Location/Privacy (geopriv)

The IESG | 17 Sep 2009 22:36

Protocol Action: 'Considerations for Civic Addresses in PIDF-LO - Guidelines and IANA Registry Definition' to BCP

The IESG has approved the following document:

- 'Considerations for Civic Addresses in PIDF-LO - Guidelines and IANA 
   Registry Definition '
   <draft-ietf-geopriv-civic-address-recommendations-03.txt> as a BCP

This document is the product of the Geographic Location/Privacy Working Group. 

The IESG contact persons are Cullen Jennings and Robert Sparks.

A URL of this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-geopriv-civic-address-recommendations-03.txt

Technical Summary

This document provides a guideline for creating civic address
consideration documents for individual countries, as required by RFC
4776. Since civic addresses may have a different format in individual
countries, such address considerations are necessary in order to map the
civic address fields to the PIDF Location Object (PIDF-LO) elements.

Working Group Summary

This document was reviewed by the GEOPRIV working group, where it has
reached consensus for publication as an IETF RFC.

Document Quality

XML examples in the document validate against relevant schemas.

(Continue reading)

headers

The IESG | 17 Apr 2006 19:45

Protocol Action: 'Constrained VPN Route Distribution' to Proposed Standard

The IESG has approved the following document:

- 'Constrained VPN Route Distribution '
   <draft-ietf-l3vpn-rt-constrain-02.txt> as a Proposed Standard

This document is the product of the Layer 3 Virtual Private Networks Working 
Group. 

The IESG contact persons are Mark Townsley and Margaret Wasserman.

A URL of this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-l3vpn-rt-constrain-02.txt

Technical Summary

This document addresses scaling issues for VPN routing information maintained
atroute reflectors. It extends the RFC2547bis approach using âCooperative
Route
Filteringâ between router reflectors for support multiple autonomous systems
and asymmetric VPN topologies such as hub-and-spoke. The solution uses MP-BGP
UPDATE messages to propagate Route Target membership information. Received
RouteTarget membership information can then be used to restrict advertisement
ofVPN
NLRI to peers that have advertised their respective Route Targets, effectively
building a route distribution graph. In this model, VPN NLRI routing
informationflows in the inverse direction of Route Target membership
information.

This mechanism is applicable to any BGP NLRI that controls the distribution of
routing information based on Route Targets, such as BGP L2VPNs [L2VPN] and VPLS

(Continue reading)