Subject: Changes since draft 15

From: "Hattig, Myron" <[email-masked]>
Date: Wed, 8 Sep 1999 15:16:36 -0700

These are the changes with annotations from draft 15 to draft 18.
There is only one change I consider a technical change; its 7) under
version 17. I used the change bars on the Acrobat files to find
the changes. If someone finds additional changes, please post to
the list.

Version 16:
1) included MCAP when IPv4 and ARP are mentioned.
2) added SHALL NOT and SHOULD NOT to key words
3) clarified definition of RESERVED
4) defined MCAP in glossary
5) globally changed multicast to IP multicast
6) globally defined ARP in this document to be specific to 1394
7) globally changed ARP to 1394 ARP
8) updated references from IRM in 1394-1995 to IRM in 1394.a
   and removed references to BCM because the IRM in 1394.a
   performs the replacement for this function
9) callout the 1500 byte MTU as the "default" MTU; state
   that larger than 1500 byte MTUs are not covered by this
   spec
10) Version in GASP header equals one.
11) States that IESG not IANA is responsible Unit_Spec_Id numbers
12) Globally specifies Unit_Spec_id in GASP header is one.
13) Last paragraph section 9.3 now states "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 ..." This was simply a clarification.
14)9.4 paragraph 3 states "once such an advertisement has been made".
The "an" is new to clarify that more than one is not necessary.
15) "10. IANA considerations" clarifies that IANA will create a
name space called "CSR Protocol identifiers", etc. etc.

Version 17)
1) Removed terms key_type and key_value.
2) States that IETF not IESG is responsible Unit_Spec_Id numbers
3) changed target_max_rec to sender_max_rec because there is no
longer a target_max_rec.
4) Condensed discussion of "Async unicast IP" and "Isoch unicast IP"
to remove any restrictions on how 1394 isochronous services may be
used.
5) Removed restrictions on the use of isoch streams for IP multicast
in section 9)
6) In section 9.1 re-enforced that fact that MCAP is carried inside
MCAP header.
7) 9.6 fixed bug. Bug existed because during the 60-0 secs when a
mapping owner was counting down to give up ownership of a mapping
it was still among the device performing contention. Thus if this
node had a larger phy id than the others, it would win the
contention process and proceed to deallocate the channel.
8) Adjusted how the words MAY and may are used to accurately
reflect when the standard is explicitly being flexible or is just
having good manners.

Draft 18
1) Added comments about the existence of IP over 1394 devices and
bridges. See page 3.
2) In section 7, the bullet item relating to sender_max_rec is
changed so comments about the value of 8 and its meaning of
256 bytes is removed.

As Peter said, we expect this draft to be submitted to the IESG.

-myron

---

From: Thomas Narten <[email-masked]>
Date: Thu, 9 Sep 1999 14:31:51 -0400

> contention process and proceed to deallocate the channel.

One if the issues I raised when reviewing the document was that it
wasn't entirely clear how "transfer of channel ownership" takes
place. My specific comment was:

> > 9.7 Transfer of channel ownership
>
> I don't understand how this works. Specifically:
>
> > 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 9.6. If the original owner observes an
>
> But section 9.6 says if two nodes advertise the same group, all but
> the highest numbered one shuts up. This doesn't resolve anything.  It
> specifically doesn't say anything about looking at the expiration time
> and doing something if the time is less than 30.
>
> Or is the term "transfer" misleading? Seems like what this algorithm
> does is let the owner deallocate, then eventually someone else will
> allocate a new (and different) one. Is that what is meant by
> "transfer"? If so, the text about 30 seconds doesn't seem to do
> anything.

Paragraph 2 of version -18 of the document was changed to address my
comment via the addition of the line marked by {+ ... -}:

> Multicast channel owners SHALL monitor MCAP advertisements in order to
> detect overlapped channel mappings. {+MCAP advertisements whose expiration
> field has a value less than 60 SHALL be ignored for the purpose of
> overlapped channel detection.+} When an overlapped channel mapping is
> detected, the owner with the largest physical ID (as determined by the
> least significant six bits of source_ID from the GASP header) is NOT
> REQUIRED to take any action. The owner(s) with smaller physical IDs
> SHALL cease transmission of MCAP advertisements for the overlapped
> channel number. As soon as these channel mapping(s) are no longer valid,
> their owners SHALL deallocate any unused channel numbers as described in
> 9.8 below.

However, my understanding of "overlapped channel detection" is that it
refers to the case where the same IP multicast address has been
assigned different 1394 channels (i.e., if two nodes independently
allocate a 1394 channel for the same IP multicast group).  In
contrast, the transfer of ownership case refers to a situation where
there is only one channel allocated. So it appears to me that the
change doesn't really address my concern.

Thomas