draft-ietf-ecrit-phonebcp-12.txt   draft-ietf-ecrit-phonebcp-13.txt 
ecrit B. Rosen ecrit B. Rosen
Internet-Draft NeuStar Internet-Draft NeuStar
Intended status: BCP J. Polk Intended status: BCP J. Polk
Expires: January 10, 2010 Cisco Systems Expires: January 30, 2010 Cisco Systems
July 9, 2009 July 29, 2009
Best Current Practice for Communications Services in support of Best Current Practice for Communications Services in support of
Emergency Calling Emergency Calling
draft-ietf-ecrit-phonebcp-12 draft-ietf-ecrit-phonebcp-13
Status of this Memo Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
skipping to change at page 1, line 34 skipping to change at page 1, line 34
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on January 10, 2010. This Internet-Draft will expire on January 30, 2010.
Copyright Notice Copyright Notice
Copyright (c) 2009 IETF Trust and the persons identified as the Copyright (c) 2009 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents in effect on the date of Provisions Relating to IETF Documents in effect on the date of
publication of this document (http://trustee.ietf.org/license-info). publication of this document (http://trustee.ietf.org/license-info).
Please review these documents carefully, as they describe your rights Please review these documents carefully, as they describe your rights
skipping to change at page 9, line 11 skipping to change at page 9, line 11
value or by reference. An end device that receives location by value or by reference. An end device that receives location by
reference (and does not also get the corresponding value) MUST be reference (and does not also get the corresponding value) MUST be
able to perform a dereference operation to obtain a value. able to perform a dereference operation to obtain a value.
6.5. End system location configuration 6.5. End system location configuration
ED-21/INT-12 Devices MUST support both the DHCP location options ED-21/INT-12 Devices MUST support both the DHCP location options
[RFC4776], [RFC3825] and HELD [RFC4776], [RFC3825] and HELD
[I-D.ietf-geopriv-http-location-delivery]. When devices deploy a [I-D.ietf-geopriv-http-location-delivery]. When devices deploy a
specific access network interface in which that access network specific access network interface in which that access network
supports location discovery such as LLDP-MED or 802.11v, the device supports location discovery such as LLDP-MED [LLDP-MED] or 802.11v,
SHOULD support the additional respective access network specific the device SHOULD support the additional respective access network
location discovery mechanism. specific location discovery mechanism.
AN-12/INT-13 The access network MUST support either DHCP location AN-12/INT-13 The access network MUST support either DHCP location
options or HELD. The access network SHOULD support other location options or HELD. The access network SHOULD support other location
technologies that are specific to the type of access network. technologies that are specific to the type of access network.
AN-13/INT-14 Where a router is employed between a LAN and WAN in a AN-13/INT-14 Where a router is employed between a LAN and WAN in a
small (less than approximately 650 square meters) area, the router small (less than approximately 650 square meters) area, the router
MUST be transparent to the location provided by the WAN to the LAN. MUST be transparent to the location provided by the WAN to the LAN.
This may mean the router must obtain location as a client from the This may mean the router must obtain location as a client from the
WAN, and supply an LCP server to the LAN with the location it WAN, and supply an LCP server to the LAN with the location it
skipping to change at page 13, line 27 skipping to change at page 13, line 27
ED-46 S/MIME MUST NOT be used to encrypt the SIP Geolocation header ED-46 S/MIME MUST NOT be used to encrypt the SIP Geolocation header
or bodies. or bodies.
ED-47/SP-24 TLS MUST be used to protect location (but see ED-47/SP-24 TLS MUST be used to protect location (but see
Section 9.1). IPSEC [RFC3986] is an acceptable alternative. Section 9.1). IPSEC [RFC3986] is an acceptable alternative.
7. LIS and LoST Discovery 7. LIS and LoST Discovery
ED-48 Endpoints MUST support one or more mechanisms that allow them ED-48 Endpoints MUST support one or more mechanisms that allow them
to determine their public IP address. Examples include STUN to determine their public IP address. Examples include STUN
[RFC3489] and HTTP get. [RFC5389] and HTTP get.
ED-49 Endpoints MUST support LIS discovery as described in ED-49 Endpoints MUST support LIS discovery as described in
[I-D.ietf-geopriv-lis-discovery], and the LoST discovery as described [I-D.ietf-geopriv-lis-discovery], and the LoST discovery as described
in [RFC5223]. in [RFC5223].
ED-50 The device MUST have a configurable default LoST server ED-50 The device MUST have a configurable default LoST server
parameter. If the device is provided by or managed by a service parameter. If the device is provided by or managed by a service
provider, it is expected that the service provider will configure provider, it is expected that the service provider will configure
this option. this option.
skipping to change at page 22, line 14 skipping to change at page 22, line 14
Polk, J. and B. Rosen, "Location Conveyance for the Polk, J. and B. Rosen, "Location Conveyance for the
Session Initiation Protocol", Session Initiation Protocol",
draft-ietf-sip-location-conveyance-13 (work in progress), draft-ietf-sip-location-conveyance-13 (work in progress),
March 2009. March 2009.
[I-D.ietf-sip-outbound] [I-D.ietf-sip-outbound]
Jennings, C., "Managing Client Initiated Connections in Jennings, C., "Managing Client Initiated Connections in
the Session Initiation Protocol (SIP)", the Session Initiation Protocol (SIP)",
draft-ietf-sip-outbound-20 (work in progress), June 2009. draft-ietf-sip-outbound-20 (work in progress), June 2009.
[LLDP] IEEE, "IEEE802.1ab Station and Media Access Control",
Dec 2004.
[LLDP-MED] [LLDP-MED]
TIA, "ANSI/TIA-1057 Link Layer Discovery Protocol - Media TIA, "ANSI/TIA-1057 Link Layer Discovery Protocol - Media
Endpoint Discovery". Endpoint Discovery".
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3118] Droms, R. and W. Arbaugh, "Authentication for DHCP [RFC3118] Droms, R. and W. Arbaugh, "Authentication for DHCP
Messages", RFC 3118, June 2001. Messages", RFC 3118, June 2001.
skipping to change at page 22, line 47 skipping to change at page 22, line 44
with Session Description Protocol (SDP)", RFC 3264, with Session Description Protocol (SDP)", RFC 3264,
June 2002. June 2002.
[RFC3265] Roach, A., "Session Initiation Protocol (SIP)-Specific [RFC3265] Roach, A., "Session Initiation Protocol (SIP)-Specific
Event Notification", RFC 3265, June 2002. Event Notification", RFC 3265, June 2002.
[RFC3428] Campbell, B., Rosenberg, J., Schulzrinne, H., Huitema, C., [RFC3428] Campbell, B., Rosenberg, J., Schulzrinne, H., Huitema, C.,
and D. Gurle, "Session Initiation Protocol (SIP) Extension and D. Gurle, "Session Initiation Protocol (SIP) Extension
for Instant Messaging", RFC 3428, December 2002. for Instant Messaging", RFC 3428, December 2002.
[RFC3489] Rosenberg, J., Weinberger, J., Huitema, C., and R. Mahy,
"STUN - Simple Traversal of User Datagram Protocol (UDP)
Through Network Address Translators (NATs)", RFC 3489,
March 2003.
[RFC3515] Sparks, R., "The Session Initiation Protocol (SIP) Refer [RFC3515] Sparks, R., "The Session Initiation Protocol (SIP) Refer
Method", RFC 3515, April 2003. Method", RFC 3515, April 2003.
[RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V.
Jacobson, "RTP: A Transport Protocol for Real-Time Jacobson, "RTP: A Transport Protocol for Real-Time
Applications", STD 64, RFC 3550, July 2003. Applications", STD 64, RFC 3550, July 2003.
[RFC3551] Schulzrinne, H. and S. Casner, "RTP Profile for Audio and [RFC3551] Schulzrinne, H. and S. Casner, "RTP Profile for Audio and
Video Conferences with Minimal Control", STD 65, RFC 3551, Video Conferences with Minimal Control", STD 65, RFC 3551,
July 2003. July 2003.
skipping to change at page 24, line 30 skipping to change at page 24, line 22
[RFC5222] Hardie, T., Newton, A., Schulzrinne, H., and H. [RFC5222] Hardie, T., Newton, A., Schulzrinne, H., and H.
Tschofenig, "LoST: A Location-to-Service Translation Tschofenig, "LoST: A Location-to-Service Translation
Protocol", RFC 5222, August 2008. Protocol", RFC 5222, August 2008.
[RFC5223] Schulzrinne, H., Polk, J., and H. Tschofenig, "Discovering [RFC5223] Schulzrinne, H., Polk, J., and H. Tschofenig, "Discovering
Location-to-Service Translation (LoST) Servers Using the Location-to-Service Translation (LoST) Servers Using the
Dynamic Host Configuration Protocol (DHCP)", RFC 5223, Dynamic Host Configuration Protocol (DHCP)", RFC 5223,
August 2008. August 2008.
[RFC5389] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing,
"Session Traversal Utilities for NAT (STUN)", RFC 5389,
October 2008.
[RFC5491] Winterbottom, J., Thomson, M., and H. Tschofenig, "GEOPRIV [RFC5491] Winterbottom, J., Thomson, M., and H. Tschofenig, "GEOPRIV
Presence Information Data Format Location Object (PIDF-LO) Presence Information Data Format Location Object (PIDF-LO)
Usage Clarification, Considerations, and Recommendations", Usage Clarification, Considerations, and Recommendations",
RFC 5491, March 2009. RFC 5491, March 2009.
19.2. Informative References 19.2. Informative References
[I-D.barnes-geopriv-lo-sec] [I-D.barnes-geopriv-lo-sec]
Barnes, R., Lepinski, M., Cooper, A., Morris, J., Barnes, R., Lepinski, M., Cooper, A., Morris, J.,
Tschofenig, H., and H. Schulzrinne, "An Architecture for Tschofenig, H., and H. Schulzrinne, "An Architecture for
skipping to change at page 29, line 45 skipping to change at page 29, line 39
significant. significant.
ED-46 S/MIME MUST NOT be used to encrypt the SIP Geolocation header ED-46 S/MIME MUST NOT be used to encrypt the SIP Geolocation header
or bodies. or bodies.
ED-47 TLS MUST be used to protect location (but see Section 9.1). ED-47 TLS MUST be used to protect location (but see Section 9.1).
IPSEC [RFC3986] is an acceptable alternative. IPSEC [RFC3986] is an acceptable alternative.
ED-48 Endpoints MUST support one or more mechanisms that allow them ED-48 Endpoints MUST support one or more mechanisms that allow them
to determine their public IP address. Examples include STUN to determine their public IP address. Examples include STUN
[RFC3489] and HTTP get. [RFC5389] and HTTP get.
ED-49 Endpoints MUST support LIS discovery as described in ED-49 Endpoints MUST support LIS discovery as described in
[I-D.ietf-geopriv-lis-discovery], and the LoST discovery as described [I-D.ietf-geopriv-lis-discovery], and the LoST discovery as described
in [RFC5223]. in [RFC5223].
ED-50 The device MUST have a configurable default LoST server ED-50 The device MUST have a configurable default LoST server
parameter. If the device is provided by or managed by a service parameter. If the device is provided by or managed by a service
provider, it is expected that the service provider will configure provider, it is expected that the service provider will configure
this option. this option.
 End of changes. 9 change blocks. 
17 lines changed or deleted 13 lines changed or added

This html diff was produced by rfcdiff 1.35. The latest version is available from http://tools.ietf.org/tools/rfcdiff/