Subject: Last Call: IPv4 over IEEE 1394 to Proposed Standard

From: The IESG <[email-masked]>
Date: Tue, 22 Jun 1999 15:28:05 -0400

The IESG has received a request from the IP Over IEEE 1394 Working
Group to consider IPv4 over IEEE 1394 <draft-ietf-ip1394-ipv4-15.txt>
as a Proposed Standard.

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action.  Please send any comments to the
[email-masked] or [email-masked] mailing lists by July 6, 1999.

Files can be obtained via
http://www.ietf.org/internet-drafts/draft-ietf-ip1394-ipv4-15.txt

---

From: Peter Johansson <[email-masked]>
Date: Wed, 23 Jun 1999 22:30:26 EDT

In a message dated 99-06-22 17:44:08 EDT, [email-masked] writes:

<<The IESG has received a request from the IP Over IEEE 1394 Working Group to
consider IPv4 over IEEE 1394 <draft-ietf-ip1394-ipv4-15.txt> as a Proposed
Standard.

The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action.  Please send any comments to the [email-masked] or
[email-masked] mailing lists by July 6, 1999.>>

The Editor advises interested parties of pending changes for the
Internet-Draft. These changes are believed to be essentially editorial and
are the result of conversation between the Chairs, the Editor and the Area
Director.

It seems likely that some of these questions might arise independently during
LAST CALL; the Editor reports the changes below in the hope that they are
helpful to anyone reviewing the Internet-Draft.

Clause 2.1
==========

The phrases "SHALL NOT" and "SHOULD NOT" are explicitly mentioned (as opposed
to permitting the reader to puzzle out the meaning of "not" on her own).

The definition of RESERVED went back into the shop for additional
wordsmithing; the revised definition is: "A keyword used to describe either
objects---bits, octets, quadlets and fields---or the code values assigned to
these objects; the object or the code value is set aside for future
standardization. A RESERVED object has no defined meaning and SHALL be zeroed
by its originator or, upon development of a future standard, set to a value
specified by such a standard. The recipient of a RESERVED object SHALL NOT
check its value. The recipient of an object whose code values are defined by
this standard SHALL check its value and reject RESERVED code values."

Clause 2.2 (and throughout the document)
========================================

The phrase "multicast group" has been everywhere changed to "IP multicast
group".

Section 4
=========

The word "default" has been added to the description of MTU: "For either of
these reasons, the maximum data payload transmissible between IP-capable
nodes MAY be less than the default 1500 octet maximum transmission unit (MTU)
specified by this document. This requires that the encapsulation format also
permit 1394 link-level fragmentation and reassembly of IP datagrams."

The subtle intent of this change is to make sure that implementations that
use other MTU sizes (for example, as the result of manual configuration) are
compliant with the standard.

Clause 4.1
==========

Although a number has not yet been selected for Unit_SW_Version (see clause
6.2), the value used in the version field in the GASP header will be updated
to reflect the same value.

Section 5
=========

In the paragraph above Table 2 (the definition of the sspd field) the last
sentence has been revised to "The table below specifies the encoding used for
sspd; all values not specified are RESERVED for future standardization."

Clause 9.3
==========

The last paragraph of this clause has been revised as follows: "Once a
multicast recipient has observed an advertisement for the desired group
address, it MAY receive multicast data on either the default broadcast
channel or the channel number(s) indicated but it SHALL continue to monitor
the default broadcast channel for MCAP advertisements for the same group
address in order to refresh the expiration time of channel number(s) in use."

Section 10
==========

This material on IANA considerations is to be rewritten for the sake of
clarity and to give explicit instructions to IANA on the management of the
new number space. The Chairs and the Editor are collaborating on the revision
and it will be posted on the working group reflector.

Regards,

Peter Johansson
Editor, IPv4 over 1394

Congruent Software, Inc.
98 Colorado Avenue
Berkeley, CA  94707

(510) 527-3926
(510) 527-3856 FAX

[email-masked]