Subject: WG Last Call - closed

From: "Hattig, Myron" <[email-masked]>
Date: Wed, 7 Apr 1999 11:33:46 -0700

Today marks the end of the WG last call. We will not be
advancing the spec to IESG until the next version of the
draft addresses the following issues:

1) Add "and RESPONSES" so that ARP responses from a remote
bus are not processed.

2) Remove the reference to section X in section 11, page 23.

3) State that a node that wishes to urgently relinquish ownership
of a IP mcast address to 1394 channel mapping must instigate a bus
reset.

Also, we will not attempt another WG Last call until the below
points have resolution and the resolution is documented in a draft.
The points that remain under debate are:

1) Decide whether or not to remove the reference to sharing a
multiple IP mcast addrs with a single 1394 channel.

2) Find a solution for the error in MCAP where a 1394 channel is deallocated
yet the channel continues to be used for IP mcast.

-myron
WG Co-Chair

---

From: Peter Johansson <[email-masked]>
Date: Mon, 12 Apr 1999 02:06:16 EDT

In a message dated 99-04-07 14:33:58 EDT, [email-masked] writes:

<<1) Add "and RESPONSES" so that ARP responses from a remote bus are not
processed.>>

In advance of the publication of the next draft, here's the relevant text:

"ARP requests and responses transported by asynchronous stream packets SHALL
be encapsulated within the GASP format specified by IEEE P1394a (see also
5.1). The recipient of an ARP request or response SHALL ignore it unless the
most significant ten bits of the source_ID field (whether obtained from the
GASP header of an asynchronous stream packet or the packet header of a block
write request) are equal to either 0x3FF or the most significant ten bits of
the recipient's NODE_IDS register."

<<2) Remove the reference to section X in section 11, page 23.>>

Corrected for the next draft.

<<3) State that a node that wishes to urgently relinquish ownership of a IP
mcast address to 1394 channel mapping must instigate a bus reset.>>

Here's the proposed replacement text in clause 10.7:

"The owner of an existing channel mapping that wishes to release the mapping
SHALL commence a timer to measure the time remaining before the anticipated
release of the mapping and its associated channel. Until the timer counts
down to zero, the owner SHOULD continue to transmit MCAP advertisements for
the affected channel but SHALL adjust expiration in each advertisement to
reflect the time remaining until the channel is to be deallocated. If the
owner is unable to transmit MCAP advertisements until the timer reaches zero,
it shall initiate a bus reset. Otherwise, the sequence of expiration times
transmitted by the owner intending to release the mapping SHALL decrease with
each succeeding advertisement. If other multicast source(s) are using the
same channel mapping and observe an expiration time less than or equal to 30
seconds, they SHALL commence transmitting MCAP advertisements for the channel
mapping with refreshed expiration times greater than or equal to 30 seconds
that maintain the channel mapping. Any contention that occurs between
multiple sources that attempt to claim ownership of the channel mapping SHALL
be resolved as described in 10.6. If the original owner observes an MCAP
advertisement for the channel to be relinquished before its own timer has
expired, it SHALL NOT deallocate the channel number."

The relevant changes are that a) the first SHOULD in the paragraph above is a
SHALL in Draft-IETF-IP1394-IPv4-14 and b) the sentence that follows is new.

Regards,

Peter Johansson

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

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

[email-masked]

---

From: "Hattig, Myron" <[email-masked]>
Date: Thu, 15 Apr 1999 09:25:17 -0700

Peter,

This text reads great.

A minor point, there is a lower case shall in "it shall initiate a bus
reset".
I don't know upper case is required, but it's inconsistent with the upper
case
of other SHALLs.

Other comments?

Thanks,

-myron