- Nov 14, 2013View SourceRegards, -K-the road on that issue.length checks for Encoded Frames and may run into interop problems downto revisit starting with the frame type assignments for Encoded BACnet DataIf we decide question #1 in the negative, then we have a number of questionsallocating frame types from the top of the range (starting with 127 for IPv6range? I'd argue in favor of allocating new ASHRAE (BACnet) frame typesEncoded Frames, then question #2 is how to allocate frame types from thisreserved range should be "Encoded Frames" (new terminology) and we alwaysWe have now discussed many times whether all future frames in the ASHRAEThanks Carl. I have integrated your suggestions into r4.Re: 7449, I didn't have any further detail about this decision in my notes.
seem to decide in the affirmative. The arguments in favor are technical; MS/TPEncoded Frames solve the long-standing issues of a) loss of frame sync caused
by preamble sequences in the Data or Data CRC fields, and b) a weak Data CRC.That's question #1. I guess #1a is how likely are we to allocate new MS/TPIf we decide again in favor of mandating that frame types 10 - 127 shall be
control frames at this stage?
from the bottom of the range (as we have done for frame types 8 & 9) and
encapsulation) to other SDOs. This will not require any change in the existing
and Data Expecting Reply. We will also need to revisit if/how to do min/maxOn Thu, Nov 14, 2013 at 4:16 PM, Carl Neilson <cneilson@...> wrote:
Here are my comments on the responses:
For comment 7423, more of description is needed for the response.
The committee’s position is that routers should support the maximum routable NPDU given the directly connected media types. In doing so, the end user need not concern themselves with the details of the intervening routers, other than to ensure that the router supports the protocol revision in which MSTP extended frames were added (i.e. the user need only purchase “newer” MS/TP routers.)
For comment 7425, the response does not speak to the complete comment. Given that we know how we intend to “highlight” the procedure, I think it is reasonable to state what will be done. To this end, I suggest the following comment response:
The committee decided to include this procedure in the standard as it has been discussed within the committee for many years as method an implementer could use to determine the inverted network problem. Given that there are alternative approaches that can be used, the committee feels it would be inappropriate to allow for the specification of this optional functionality given that there are numerous organizations that inappropriately specify functionality due to a lack of understanding of its applicability. For this reason, no BIBBs will be created for this functionality; it will remain completely optional.
The next PPR draft will separate this new procedure into a separate section of the addendum to highlight its addition separately from the MS/TP extended frames functionality.
Comment 7427, should be Accepted as Submitted.
For comment 7428, the response seems to imply that we would be allowing routers to not support extended frames. I would prefer the follow:
The committee will look into approaches to clarify NPDU size requirements for routing and non-routing MS/TP nodes for the next PPR.
The response text for comment 7449 is insufficient. It does not state whether the proposed changes will be made or not and seems to allow future rejection of the idea. The general notes also provide no indication of what we decided to do with the comment so I cannot offer alternate language.
Chair, ASHRAE SSPC 135 (aka The BACnet Committee)
P Please consider the environment before printing this e-mail.
This email message is directed in confidence solely to whom it is addressed. If you are not the intended recipient, you may not use or disclose any information contained here. If you received this email message in error, please reply to the sender immediately and delete the message along with any associated attachments. While every effort is made to ensure safe transmissions, it is still recommended that you scan any attachments for viruses.
[Attachment(s) from Kerry Lynn included below]
The new format of the Yahoo groups is pretty broken. There's a menu
called "More" and "Files" is below that. After you select it, "Files" becomes
a menu, but this doesn't seem to persist across sessions.
Comments doc is attached for your reviewing pleasure...
On Thu, Nov 14, 2013 at 12:10 PM, Carl Neilson <cneilson@...> wrote:
I can’t find the file on Yahoo. Can you send it as an attachment to an email.
A new version of the PPR1 comment responses, Add-135-2012an-PPR1-Comments-r3.docx, has been uploaded to the bacnet-mstpwg files area. I'm sure some of the responses need work, so please look it over before tomorrow's call if you have time.
The MSTP-WG will have a teleconference Friday, 15-Nov-2013 at 11:30 AM EST.
The teleconference will be one hour and the agenda is as follows:
1) Review outstanding PPR comment responses, if any, and vote to move the comment response document to the SSPC.
2) Identify any technical issues that were uncovered during the PPR and discuss how to move forward on those issues.
3) Review Add. AN draft language if available.
Please note that there will be a follow-up teleconference scheduled for the week of 25-Nov to discuss the final draft of Add. AN for the SSPC to consider it for the next PPR cycle. The deadline for that vote is 10-Dec. The definitive date for the next teleconference will be discussed during Friday’s meeting.
Dial in information
Conference dial-in number: (209) 647-1600
Participant access code: 868312
Once prompted for the access code, locate the dial pad and enter the conference access code followed by the pound (#) key to successfully join the conference call.
For additional Skype support: http://www.freeconferencecallhd.com/skypeinstructions.html