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

[Gorry Fairhurst <gorry@erg.abdn.ac.uk>]

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]).


---