Subject: Version 12 issues

From: "Hattig, Myron" <[email-masked]>
Date: Tue, 24 Nov 1998 14:31:15 -0800

Below is the list of current issues with version 12 of the draft followed by the previous list of issues with version 11. The version 12 issues are based on my comparison of the version 11 issues and the version 12 of draft.

-----------------------------------------------------

Version 12 issues:

1) In section 6.2, remove the text "Subsequent to reassembly, the
recipient shall verify the IP header checksum of the datagram."

STATUS: I changed this to closed, we had rough consensus to modify
the draft to remove the quoted text.

2) Add note to Table 1 on page 8 as follows:

NOTE: The maximum payload for both asynchronous and isochronous
packets at speeds of S800 and faster will be standardized by IEEE P1394b.
The values given in Table 1 are tentative and may be reduced but will not be
exceeded.

STATUS: A note was added to version 12, but the note mentions the current status of the p1394b WG. We should just point to the p1394b WG and not state their current status.

3) I propose to add following sentence in section 7.
    The recipient SHALL discard the entire ARP rqst/resp if the least
    significant 6 bits of sender_node_ID or target_node_Id is 0x3F.

STATUS: Closed draft should be modified.

4) Specify Multicast related actions after a bus reset.

STATUS: Closed draft should be modified.

-----------------------------------------------------

Version 11 issues:

1) Page 7 in the description of the valid bit. IP
broadcast packets are listed. I should be just IP packets.

STATUS: Closed, Peter's decision to change or not.

2) In section 6.2, remove the text "Subsequent to reassembly, the
recipient shall verify the IP header checksum of the datagram."

STATUS: Open

3) Adding the requirement that all IP devices MUST support block_bus_info.

STATUS: Closed, requirement will be added to draft.

4) Typo three figure 5's

STATUS: Closed, figure numbers will be changed.

5)  Improve the text in Section 10.6, para 2. It says:

"The owner of an existing channel mapping that wishes to
 release the mapping shall transmit an MCAP advertisement with an
expiration time at least 30 seconds in the future.

STATUS: Closed, Peter agreed to improve text. WG to review next version of draft.

6) Add note to Table 1 on page 8 as follows:

NOTE: The maximum payload for both asynchronous and isochronous
packets at speeds of S800 and faster will be standardized by IEEE P1394b.
The values given in Table 1 are tentative and may be reduced but will not be
exceeded.

STATUS: Closed, note will be added. While some objected to the actions of
p1394b, the actions of p1394b are not regulated by the ip/1394 WG.

7) In section 10.6 add contention resolution text or reference section
10.2.

STATUS: Closed, Peter will make appropriate change.

8) I propose to add following sentence in section 7.
    The recipient SHALL discard the entire ARP rqst/resp if the least
    significant 6 bits of sender_node_ID or target_node_Id is 0x3F.

STATUS: Close, spec will be modified.

9) Remove NodeID in ARP packet.

STATUS: Closed, ARP format remain unaffected by this discussion. Note
this issue is separate from issue 10).

10) Ignore ARP packets from remote buses.

STATUS: Open, no resolution in site. It is expected a poll will be required
to resolve this issue.

11) Specify Multicast related actions after a bus reset.

STATUS: Closed draft should be modified.

12) There should be a lower bound on the expiration time when a mapping owner
wishes to maintain ownership of the mapping. The value for the lower bound
should be 60 seconds.

STATUS: Closed draft should be modified.

13) A channel mapping owner should send an advertisment immediately after receiving a solicit msg.

14)
I noticed another thing in section "5. NETWORK PROTOCOL MANAGER (NPM)".
In step g) and i), there are desctiptions of "a broadcast write request"
for the NETWORK_CHANNELS register.
This "broadcast write request" SHALL NOT be propageted across the
bridge. I think it's better to add a note like the following:

   NOTE: The broadcast write request for the NETWORK_CHANNELS
   register SHALL NOT be propageted across the bridge. The NPM SHALL
   either
     set the most significant 10 bits of the NODE_IDS register
     in the destination_bus_ID,
   or
     set 0x3FF in the source_bus_ID.

This issue is irrelevant to the virtual node ids.

STATUS: Closed draft should be modified.