RE: [bacnet-ip-wg] Teleconference
· that this is last minute,
· that I haven’t been an active member of the WG,
· if I dredge up stuff that has already been discussed to death.
But I am nominally on vacation this week, meaning that I finally have time to read and comment on the draft.
If I get annoying, just tell me to shut up.
· Table 12-X: Footnote 6 has "IP_Mode", should be "BACnet_IP_Mode"
· Table 12-X: Not all the DHCP-related properties have footnote 3
· Table 12-X: I know it's a pain, but the footnote indices should generally increase down the page (versus current 12 and 13, then 1,4,5,3)
· Table 12-X: Footnote 7 says when the properties are required WRITABLE, but there is no flag of when these properties are REQUIRED. Presumably should have TWO footnotes?
· Table 12-X: Footnote 7 seems to require NAT support for ALL BBMD. Is that intended? If so, where does the standard require it? The text under 12.X.26 BBMD_NAT_Traversal seems to imply that NAT support is optional.
· Table 12-X: Since we have BACnet_IP... and BBMD_... prefixes, should we have MSTP_Max_Master etc? We might choose to RENAME Max_Masters, keeping the same numeric value. That was done some years back – see “enable” and “event-parameters” in clause 21.
· Why does BACnetNetworkType / 12.X.8 have "RESERVED" in the middle of it? The proposed update to clause 21 says "reserved for a future addendum". Let the future addendum take care of itself and add its number at the end of the line like everyone else in the bakery. (How about listing them in clause-chronological order?)
· 12.X.14 APDU_Length. Why not call this Max_APDU_Length, since that is what the value IS for each port? I don't see any confusion (as cited in the comment) with Max_APDU_Length in the Device object, except perhaps to ask: what value should be in I-Am and Max_APDU_Length in the Device Object? Does the value depend on the port from which I receive my answer? That is certainly the most useful, although it violates the Holy Seven Layer Model by requiring the Application Layer to know about the Datalink layer. 12.11.18 and 126.96.36.199.2 don't say.
Note that the proposed use in 15.5.2 of a wildcard instance for the Port object requires the same layer violation, and in a rather more arcane form, so if you like it for Port, why not for I-Am and in the Device Object. Yes, I can see the Single Home people coming to get me.
· 12.X.13 mentions VMAC. This should reference the defining clause H.7.1. It seems odd that this definition is in "COMBINING BACnet NETWORKS WITH NON-BACnet NETWORKS", but that is where it is...
· 12.X.15. "10 megabit Ethernet" should probably be "10 megabits per second Ethernet".
· 12.X.15 talks about "autonegotiation" of MS/TP link speed. I know many people have implemented this, but:
1) 135-2010 doesn't mention it.
2) A device that implements it won't pass a BTL conformance test, since it won't create a token according to the timeout rules in clause 9
3) It isn't a "negotiation", in that a group of devices can't decide on the fastest common speed, as Ethernet or modem autonegotiation does. Rather, each node "LEARNS" or "DISCOVERS" the speed by observing the link.
If this meaning of zero is to be used, shouldn't the standard define what this is?
· 12.X.18 says "if this is writable", but footnote 4 REQUIRES it to be writable.
· 12.X.18 If a device is not a BBMD, and does not support foreign registration with a BBMD, can it say this is "writable" even if it only accepts one value (NORMAL)?
· 12.X.18 Doesn't BACnet's NAT support allow one BBMD to register as a foreign device with another? Should BACnet_IP_Mode indicate that – that a device may be BOTH a BBMD and NAT-registered? This might affect the conditionality of FD_BBMD_IP_Address.
· The numbering repeats after 12.X.27, then a second .24, .25. a couple .26 etc.
· 12.X.23, .25, .26 etc., don't specify byte order like other IP address properties.
· 12.x.27 should say (like 12.X.22) "If present, this property shall be writable" Probably as the start of a second paragraph before the current "Writing a value..." analogous to 12.X.22
· 12.X.28 BBMD_Accept_FD_Registrations. Why is this required writable? Can't a BBMD ALWAYS accept foreign registrations? Comment 2-5 could be satisfied by a BBMD with this property read-only but TRUE. The clause could rule out read-only and FALSE. Comment 3-11 doesn't seem to relate to this clause.
· 12.X.30 Max_Masters why required writable, rather than "127 or writable" like 135-2010, or 12.X.31 Max_Info_Frames?
· 12.X.32 Slave_Proxy_Enable. If present, it would seem this should be writable
· 12.X.34 Auto_Slave_Discovery. If present, it would seem this should be writable
· 12.X.36 Virtual_MAC_Address_Table. Are you SURE you want this to persist? On ZigBee, the information in this table might be LEARNED from the network. If it is persisted, then obsolete data may persist for nodes that are no longer present.
· 12.X.37 Routing_Table. Combining the ULTIMATE network number with the MAC address of the NEXT HOP as a BACnetAddress seems like a bad idea. Network number, and the address of the next router TO or TOWARDs that network are separate items, as is conveyed by comment 5-073's BACnetRoutingEntry.
I note that unlike the BDT, which for which the same information may be obtained via BVLL message or APDU, this "Router Table" is NOT the same information as the table returned by the network message, which includes only networks directly connected to the router.
Come to think of it, why is this part of a port object? Even a non-routing device with only one port will need have a table to map destination network numbers to a first-hop router address. Any device with one port will use the table to find the router address. A device with multiple ports will use the table to find the PORT and the router address on that port. Think of the *nix or Windows "route" command. This property belongs in the Device object.
· 9.5.3 has Max_Info_Frames in the device object. Shouldn't this clause it also mention the Port object? (Comment 3-14 says to retain the presence in the Device object for single-port devices)
· The proposed change to J.5.2 "BBMD Operation - Foreign Devices" adds the significant new requirement that any non-BBMD node MUST be able to register as a foreign device. Addendum ai claims "The proposed changes are summarized below”, then lists only “Add Network Port Object Type".
My opinion is that the language in J.5.2 has nothing to do with the Port object, and should be in a separate addendum, or at least called out at the top of the review document. I don't think this was an intentional stealth change (see: US Congressional budget bills), but I for one missed this during the public review.
However it got there, J.5.2 "BBMD Operation - Foreign Devices" is an easy-to-miss place to put the significant new requirement that any non-BBMD node MUST be able to register as a foreign device: someone implementing a simple node may not read that section. This should be in J.4.
Significant changes are required elsewhere in J.4, which currently assumes that "normal" operation is one BBMD per subnet, and only "special" devices register as foreign. Since "IT friendliness" seems to be moving us away from the BBMD per subnet model and towards "mostly foreign registrations" instead, some of the explanatory text from J.4.1, J.4.2, etc. needs to be pulled together into an introductory section in J.4.
The information contained in this message is privileged and intended only for the recipients named. If the reader is not a representative of the intended recipient, any review, dissemination or copying of this message or the information it contains is prohibited. If you have received this message in error, please immediately notify the sender, and delete the original message and attachments.