Subject: WG Last Call on v15

From: "Hattig, Myron" <[email-masked]>
Date: Tue, 18 May 1999 09:35:51 -0700

Hello,

Our editor, Peter, posted the IPv4 over 1394 draft version 15. Now its time
to start a WG Last Call. The WG Last call will end May 28th.  The purpose of
the WG Last Call is so IP/1394 WG members can review, comment on, and
discuss problems with the draft. The draft will not pass WG Last Call if
technical problems are found. At this point, we will only consider
alternative solutions that solve agreed-upon problems. If the draft passes
WG Last Call, the draft will be submitted to the IESG to become a Proposed
Standard RFC.

Thanks,

Tony & Myron
WG Co-Chairs

---

From: Venkat Tanikella <[email-masked]>
Date: Thu, 20 May 1999 10:54:23 -0700

Myron,

With respect to Peter's comments below, that the "root"'s capability
requirements could potentially go up in future, and given the tight
association of BCM & root And BCM & IP1394, I see interoperability issues
when some thing like that happens. When such a thing happens, existing
implementations may not work with out upgradation. To me this is a potential
problem and I would like the group to address this and want to know other
members view on this.

regards,
Venkat

In a message dated 99-05-20 04:32:59 EDT, [email-masked]
writes:

<<...in general the capability hierarchy (pg 9.23 in 99-005r1.pdf) seems to
be a bad idea altogether. If we start building on the 'more capable' node
concept, then new problems will soon be met.>>

I believe it's essential to create such a hierarchy, NOW, while we still
can.
The point is that there are going to be some future needs, not all of which
have been imagined yet, that can only be met by placing them in the root.
The
"adjustable cycle master" for P1394.1 needs is one such example, the
desirability of a P1394b node as root in a mixed environment is another.

If we don't have an orderly way to incrementally extend the root's
capabilities, as justified, we run a serious risk of boxing ourdelves into a
corner in future.

---

From: Peter Johansson <[email-masked]>
Date: Thu, 20 May 1999 15:13:48 EDT

In a message dated 99-05-20 13:54:31 EDT, [email-masked] writes:

<<With respect to Peter's comments below, that the "root"'s capability
members view on this.>>

Venkat, maybe I haven't explained the solution as clearly as necessary. I
don't foresee interoperability problems in the future. To the contrary, I see
the acceptance of a hierarchy of capabilities as a way to avoid future
problems.

You express the concern that "existing implementations might not work without
upgrade". I will assume that by "existing implementations" you mean
implementations that now and in the future comply with the guidelines for a
hierarchy.

If you implement a root/cycle master/IRM/BCM-capable node today that is NOT
"adjustable cycle master" capable (because P1394.1 has yet to define this
feature), your software investment is safe. The key ground rule is that your
node does not (ever) set its own force_root variable TRUE unless it knows,
for a certainty, that the current root is LESS capable than itself. If the
root has the same level of capabilities, your device is not permitted to take
over as root.

This protects your product because you do not have to know, in advance, what
these future capabilities may be. And you know, by prior agreement, that any
node that zeros your RHB and sets its own is promising to support all of the
functions you support.

These rules create a foundation to be able to extend root capabilities in the
future. First we need to have the foundation; then we can debate which root
features are worthy of inclusion in the hierarchy.

Perhaps we should split into two questions:

Should we create an extensible mechanism to add new functionality to the root
in the future?

Should BCM capability be one of the features in the root hierarchy?

All of you already know my answer to both questions is "YES!"

Regards,

Peter Johansson

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

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

[email-masked]

---

From: Venkat Tanikella <[email-masked]>
Date: Thu, 20 May 1999 12:57:46 -0700

Peter,
    Thanks for the explanation. I missed the conditional points on setting
the RHB.
    I have no issues on the interoperability/upgradation issues I talked
about
    below any more.
regards,
Venkat

---

From: "Hattig, Myron" <[email-masked]>
Date: Fri, 21 May 1999 08:48:59 -0700

Venkat,

Any solution must account for increased capability. I consider this a
requirement for any of these proposals. Without meeting this requirement, I
doubt the proposal will get very far. This addresses long term
interoperability issues for IP/1394. We should have this issue worked out
before we do any group interoperability testing; this addresses medium-term
IP/1394 interop issues. In the short-term, if anyone is doing any testing
they probably should check with their testing partners to verify both use
the same BCM election algorithm.

-myron