Subject: MISTI gateway error sending mail

From: [email-masked]
Date: Fri, 7 May 1999 16:08:33 -0600

Following are INVALID MSG recipients:
DEK1%MIMI                   dek1%mimi@timsg

   ----- Original Message follows -----
Date:         Fri, 7 May 1999 14:59:17 -0500
Reply-To: "Wooten, David" <[email-masked]>
Sender: IETF IP over 1394 Working Group <[email-masked]>
From: "Wooten, David" <[email-masked]>
Subject:      Re: Revised BCM selection process
Comments: To: [email-masked]
To: [email-masked]

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_000_01BE98C9.0BD8B4F4
Content-Type: text/plain;
        charset="iso-8859-1"

Peter,

Is it true that the tags used for the asynchronous packets over the
broadcast channel are different from any of the currently defined
isochronous ones so that devices can still filter based on usage?  I don't
care much either way cause I think that if the AV folks can grab a default
broadcast channel (63) the other people who also have legitimate uses can
too. ;-)

David Wooten

> -----Original Message-----
> From: Peter Johansson [mailto:[email-masked]]
> Sent: Friday, May 07, 1999 12:59 PM
> To: [email-masked]
> Subject: Re: Revised BCM selection process
>
>
> In a message dated 99-05-06 12:22:53 EDT,
> [email-masked] writes:
>
> <<I agree with Kenji. This problem [of another requester
> allocating channel
> 31] certainly is theoretically possible if the BCM/Broadcast
> channel text
> does not explicitly state, the IRM/BCM node will not accept
> any read/lock
> requests until *after* it allocates channel 31. The concern
> increases  with
> nodes that implement the BCM in higher layer software modules
> while leaving
> the IRM implementation in lower layers.>>
>
> We're getting down to fine details here. Strictly speaking,
> the BCM/IRM may
> accept lread requests unconditionally---between the time some
> node reads
> CHANNELS_AVAILABLE and subsequently attempts a lock some
> other node may have
> beaten it to the punch. The BCM/IRM may accept lock requests,
> so long as it
> does not allocate channel 31 BEFORE it has marked it
> allocated in the bit
> mask. Of course, the simplest solution is for the bit that
> represents channel
> 31 to be set to one almost immediately after a bus
> reset---but this is an
> implementation choice that need not be constrained by the standard.
>
> I will work on some language that addresses your concern and
> post it to the
> reflector. In a naive sense, simply the requirement that the
> BCM "shall
> allocate channel 31" carries with it all of the considerations you
> raise---but I understand that it may be better to be overly
> cautious in the
> standard.
>
> <<BTW, I agree with your other comments that the BCM
> implementation should
> reside in lower layers with the IRM, but this is not reality
> today for many
> of the platforms on which IP/1394 will be first implemented.>>
>
> So let's examine the impact when the BCM doesn't reside there
> and determine
> the best approach to support migration to the better solution.
>
> Regards,
>
> Peter Johansson
>
> Congruent Software, Inc.
> 98 Colorado Avenue
> Berkeley, CA  94707
>
> (510) 527-3926
> (510) 527-3856 FAX
>
> [email-masked]
>

------_=_NextPart_000_01BE98C9.0BD8B4F4
Content-Type: application/ms-tnef
Content-Transfer-Encoding: base64

------_=_NextPart_000_01BE98C9.0BD8B4F4--

---

From: "Hattig, Myron" <[email-masked]>
Date: Fri, 7 May 1999 15:33:40 -0700

I'm not sure what this mail is about. I found an email address similar to
the source of this msg subscribed to the ip1394 list. I removed the below
email addr in hopes of stopping these mails from being sent back to the
ip/1394 list. David Kimble, please contact me if this is problem.

[email-masked]               David Kimble

-myron
[email-masked]