Re: Pointer to the Rules for Normative References?
this is defined in [RFC3967 i think that a standrard track document can point out to a BCP and this is not considered a downward reference Philip Matthews escribió: Can someone point me to the rules for when a document is allowed to normatively reference another document? I am seen them before, but cannot find them right now. In particular, I am wondering if a standards-track RFC is allowed to normatively reference a BCP? - Philip ___ IETF mailing list IETF@ietf.org https://www.ietf.org/mailman/listinfo/ietf ___ IETF mailing list IETF@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Pointer to the Rules for Normative References?
Thanks. On Mon, 12-May-08, at 09:29 , marcelo bagnulo braun wrote: this is defined in [RFC3967 i think that a standrard track document can point out to a BCP and this is not considered a downward reference Philip Matthews escribió: Can someone point me to the rules for when a document is allowed to normatively reference another document? I am seen them before, but cannot find them right now. In particular, I am wondering if a standards-track RFC is allowed to normatively reference a BCP? - Philip ___ IETF mailing list IETF@ietf.org https://www.ietf.org/mailman/listinfo/ietf ___ IETF mailing list IETF@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Protocol Action: 'Mobile IPv6 Fast Handovers' to Proposed Standard
The IESG has approved the following document: - 'Mobile IPv6 Fast Handovers ' draft-ietf-mipshop-fmipv6-rfc4068bis-07.txt as a Proposed Standard This document is the product of the Mobility for IP: Performance, Signaling and Handoff Optimization Working Group. The IESG contact persons are Jari Arkko and Mark Townsley. A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mipshop-fmipv6-rfc4068bis-07.txt Technical Summary Mobile IPv6 enables a Mobile Node to maintain its connectivity to the Internet when moving from an Access Router to another, a process referred to as handover. During this time, the Mobile Node is unable to send or receive packets due to both link switching delay and IP protocol operations. The handover latency resulting from standard Mobile IPv6 procedures, namely, movement detection, new Care of Address configuration and Binding Update, is often unacceptable to real-time traffic such as Voice over IP. Reducing the handover latency could be beneficial to non real-time, throughput-sensitive applications as well. This document specifies a protocol to improve handover latency due to Mobile IPv6 procedures. Working Group Summary The document has gone through WGLC in MIPSHOP WG. Document Quality This is a revision of an existing Experimental specification, RFC 4068. There are a few implementations of the proposed protocol available already. There has also been one interop event where two implementations were tested. This specification has been reviewed by Jari Arkko for the IESG. Note to RFC Editor Please insert Obsoletes: 4068 to the header. Change this text in Section 5.4: OLD: Whereas buffering can enable a smooth handover, the buffer size and the rate at which buffered packets are eventually forwarded are important considerations when providing buffering support. For instance, an application such as Voice over IP typically needs smaller buffers compared to high-resolution streamig video, which has larger packet sizes and higher arrival rates. This specification does not restrict implementations to providing buffering support for any specific application. However, the implementations should recognize that the buffer size requirements are dependent on the application characteristics (including the arrival rate, arrival process, perceived performance loss in the event buffering is not offered, and so on), and arrive at their own policy decisions. Particular attention must be paid to the rate at which buffered packets are forwarded to the MN once attachment is complete. Just as in any network event where a router buffers packets, forwarding buffered packets in a handover at a rate inconsistent with the policy governing the outbound interface can cause performance degradation to the existing sessions and connections. Implementations must take care to prevent such occurances, just as routers do with buffered packets on the Internet. NEW: Whereas buffering can enable a smooth handover, the buffer size and the rate at which buffered packets are eventually forwarded are important considerations when providing buffering support. There are a number of aspects to consider: o Some applications transmit less data over a given period of data than others, and this implies different buffering requirements. For instance, Voice over IP typically needs smaller buffers compared to high-resolution streaming video, as the latter has larger packet sizes and higher arrival rates. o When the mobile node re-appears on the new link, having the buffering router send a large number of packets in quick succession may overtax the resources of the router, the mobile node itself, or the path between these two. In particular, if a large number of packets are buffered, sending them out one after another may cause some of them to be dropped by routers on the path. Or they may stand in queue, blocking new packets reaching the mobile node. This would be problematic for real-time communications. o The routers are not one of the parties in the end-to-end communication, so they has no knowledge of transport layer conditions. o The wireless connectivity of the mobile node may vary over time. It may achieve a smaller or higher bandwidth on the new link, signal strength may be weak at the time it just entered the area of this access point, and so on. As a result, it is hard to design an algorithm that would send the packets out from the buffer properly spaced under all circumstances. Note that running out of resources due to too fast draining of the buffer can be harmful to both the mobile node itself or other nodes using the same path. The purpose of fast handovers is to avoid packet loss. Yet, too fast
Document Action: 'Applicability Statement for Layer 1 Virtual Private Networks (L1VPNs) Basic Mode' to Informational RFC
The IESG has approved the following document: - 'Applicability Statement for Layer 1 Virtual Private Networks (L1VPNs) Basic Mode ' draft-ietf-l1vpn-applicability-basic-mode-05.txt as an Informational RFC This document is the product of the Layer 1 Virtual Private Networks Working Group. The IESG contact persons are David Ward and Ross Callon. A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-l1vpn-applicability-basic-mode-05.txt Technical Summary This document provides an applicability statement on the use of Generalized Multiprotocol Label Switching (GMPLS) protocols and mechanisms to support Basic Mode Layer 1 Virtual Private Networks (L1VPNs). L1VPNs provide customer services and connectivity at layer 1 over layer 1 networks. The operation of L1VPNs is divided into the Basic Mode and the Enhanced Mode where the Basic Mode of operation does not feature any exchange of routing information between the layer 1 network and the customer domain. This document examines how GMPLS protocols can be used to satisfy the requirements of a Basic Mode L1VPN. Document Quality This is an Informational I-D with no protocol specifications. ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
Document Action: 'OSPF Database Exchange Summary List Optimization' to Informational RFC
The IESG has approved the following document: - 'OSPF Database Exchange Summary List Optimization ' draft-ogier-ospf-dbex-opt-03.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 David Ward. A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ogier-ospf-dbex-opt-03.txt ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
Protocol Action: 'PIM Bootstrap Router MIB' to Proposed Standard
The IESG has approved the following document: - 'PIM Bootstrap Router MIB ' draft-ietf-pim-bsr-mib-06.txt as a Proposed Standard This document is the product of the Protocol Independent Multicast Working Group. The IESG contact persons are David Ward and Ross Callon. A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-pim-bsr-mib-06.txt Technical Summary This document defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects used for managing the Bootstrap Router (BSR) mechanism for PIM (Protocol Independent Multicast). This document was created by moving some of the PIM BSR specific MIB tables from one of the earlier version of PIM MIB [RFC5060]. Working Group Summary Nothing of note. The WG is happy to have it completed. Protocol Quality Its been thorough reviewed and there are multiple, interoperable implementations. ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
GEOPRIV Interim Meeting, June 12, 2008
The IETF GEOPRIV WG is holding an Interim meeting June 12th in Dallas. Please see the geopriv mailing list for more details on location and draft agenda. ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
