Subject: New rev of WG document following WGLC (draft-ietf-ipdvb-ar-05.txt)

From: Gorry Fairhurst <[email-masked]>
Date: Thu, 24 Aug 2006 16:15:35 +0100

The Editors of the WG draft draft-ietf-ipdvb-ar have now completed the 
corrections that resulted from the WGLC and a new I-D will shortly be 
issued. A summary of the changes is provided below. The I-D will then be 
sent to the IESG with a request to publish as an Informational RFC.

best wishes,

Gorry and Marie-Jose.

---

    WG-05 (following WGLC)

    * Fixed security issues noted by George Gross.

    * Added text on Mobility, topology changes with AR cache.

    * To be consistent with RFC4326, NPA = ULA address indicated by the
    D-bit, whereas MAC means IEEE-style address. I've reworked the text
    to make this clearer. Also made all "NPA/MAC" into "MAC/NPA".

    * Added notes on AR caches when used in mobile/ST topology changes.

    * Also note a mistake to section (iii) which was confusing about L2
    multicast addresses, this now reads:

    "  (iii) IP and other protocols may view sets of L3 multicast
            addresses as link-local. This may produce unexpected results
            if frames with the corresponding multicast L2 addresses are
            distributed to systems in a different L3 network or
            multicast scope (see sections 3.2 and 5.6)"

    * Section 2, Added:
    MAC Address: A 6 byte link layer address of the format described by
    the Ethernet IEEE 802 standard (see also NPA).

    * Section 3, Revised bullet into two points:
    A scalable architecture that may support large numbers of systems
    within the MPEG-2 network [RFC4259].
    A method for transmission of AR information from an AR Server to
    clients that minimise the transmission cost (link local multicast,
    is preferable to subnet broadcast).

    * Section 3, changed "context" to "scope".

    * Section 4.3. Revised wording on T Stream v. TS Logical Channel.

    * Section 5.4. 2nd para, added (mapping the IP address to the L2
    address)

    * Added:
    The default parameters specified in RFC 2461 for the ND protocol can
    introduce interoperability problems (e.g. a failure to resolve when
    the link RTT exceed 3 seconds) and performance degradation
    (duplicate ND messages with a link RTT > 1 second) when used in
    networks were the link RTT is significantly larger than experienced
    by Ethernet LANs. Tuning of the protocol parameters (e.g.
    RTR_SOLICITATION_INTERVAL) is therefore recommended when using
    network links with appreciable delay (Section 6.3.2 of [RFC2461]).

---