EMAIL VOTING BALLOT 10/20/95 SUBJECT: P802/D21: Overview and Architecture (second edition) __X__ I approve (may attach non-binding comments below) Peter Wang peter_wang@3mail.3com.com 408-764-8155 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Sec. 1.2 - pg. 5, line 24: Use "end stations" instead of "stations"? Need consistant terminology. - pg. 5, line 25: add "and point-multipoint" after "point-point"; change "switch nodes" to "routing nodes". Sec. 1.3 - pg. 6, line 32: "IVD" is not referenced anywhere else nor explained. Suggest replacing acronym with full name. Sec. 1.4 - pg. 6, line 44-45: Delete "Integrated Service" before "ISLAN and MAN". It's redundant Sec. 4.2.2.1 - pg. 13, paragra 4: Mention SNMP? Sec. 4.2.2 - Move back to after Sec. 4.2.6 and before 4.2.7. This will keep all of the management discussion together and not divert attention to the layered model discussion. Sec. 5.1 - pg. 15: Swap 1st and 2nd paragraph. Providing term definitions first makes reading easier. Sec. 5.2 - pg. 16, line 4: change "entities van exchange" to "entities can exchange". Sec. 6 - Need to provide a paragraph on LLC header and address format somewhere to make this whole section complete. Sec. 6.2.1, paragraphs 2~4 - pgs 18-19: There is a good bit of redundant discussion here from Sec. 6 and 6.1. Move these paragraph to Sec. 6.0 and simply remainder of Sec. 6 and 6.1 to provide cleaner, easier to understand explanations. Sec. 6.3.1, paragraph 1 - pg. 20, line 37-38: Sentence is somewhat confusing. Try "uses its OUI within the Protocol Identification Field to identify its own protocols." EMAIL VOTING BALLOT 23 Oct 95 SUBJECT: P802/D21: Overview and Architecture (second edition) __X___ I approve (may attach non-binding comments below) Tony Jeffree 100271.522@compuserve.com +44-161-242-2221 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ The current text of section 4.2 & its subsections assumes that the LAN management world is based on OSI Management standards & related drivitives. Given the wide acceptance of SNMP in the LAN community, it would be appropriate for this to be taken on board in the document. To this end, I propose the following addition as introductory paras after heading 4.2.2: The provision of an adequate means of remote management is an important factor in the design of today's LAN equipment. Such management mechanisms fall into two broad categories; those that provide general purpose management capability, allowing control and monitoring for a wide variety of purposes, and those that provide specific capabilities aimed at a particular aspect of management. Section 4.2.2.1 describes the applicability of the OSI Management architecture and related standards to the needs of general purpose management in LANs, and gives a brief description of the IEEE 802 architecture for LAN/MAN management. It should, however, be noted that other approaches may be appropriate to meting this need; these may be based on proprietary mechanisms or other Industry Standard mechanisms. In particular, the high degree of penetration of the Simple Network Management Protocol (SNMP) into the LAN Management market means that for some IEEE 802 standards it will be appropriate to develop management specifications suitable for use with SNMP. EMAIL VOTING BALLOT 30 October 1995 SUBJECT: P802/D21: Overview and Architecture (second edition) __X__ I approve (may attach non-binding comments below) Robin Tasker r.tasker@dl.ac.uk +44 1925 603226 ------- comments attached here 1. Page 5, line27 Is "transit delay" the same as "latency" which seems to be the more widely used term. 2. Page 5, 3rd para The first sentence of this paragraph is logically connected to the previous paragraph so should be moved there. I suggest the remaining 2 sentences of this paragraph are linked as in "......as a public utility and also differs from networks ......." 3. Page 5, line 44 The word "delay" should be "transit delay" or even "latency"! 4. Page 7 line 11 IEEE Std 802.9-1994 is now a DIS and could therefore be quoted as ISO/IEC..... 5. Page 7 line 41 Might be worth a reference to the fact that this will in future be published as ISO/IEC 15802-3 6. Page 9, Section 2.3 Text required! 7. Page 12, Section 4.2.2 LAN/MAN Management Reference to the role and market position of snmp in network management must be made here. I quite agree with Tony Jeffree's comments. 8. Page 15, line 3 There should be a forward reference to Section 6 in the first sentence possible after "....the addressing" 9. Page 16, line 4 Change "van" to "can" ! 10. Page 18, line 43 The use of the word "node" is at variance with the rest of the document where "station" seems to be preferred. 11. Page 19, 3rd para The final sentence may read better if a reason were given for such an important note. Maybe by moving this sentence to the 5th paragraph might be the easiest solution where issues of misuse are discussed. 12. Page 19, line 21 Capitalise "H" in "however" 13. Page 24, Sections 7.1 - 7.7 Text required! EMAIL VOTING BALLOT SUBJECT: P802/D21: Overview and Architecture (second edition) __X__ I disapprove for the following reasons. __John Boal_____________ _100437,2500@compuserve.com _+44 1734 868601___________ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ This "NO" vote is based on those comments listed below with a "NO" - 1, 8, 9, 12 & 13. 1. pp5 line(s) 31-35 - "NO" This text, in "Key Concepts" provides almost all the description that there is on bridged LANs. I have no problem with this particular text. In an O&A document the absence of an adequate description of what is now a fundamental part of LAN/MANs is a setrious insufficiency. See other comments below. 2. pp6 line(s) 32-33 A proposed alternative text for this (my original) follows:-"Integrated Services devices including ISDN terminals and end systems supporting combined voice, video and data applications" 3. pp6 line(s) 49 "have" S/B "has" - I think!. 4 pp9 line(s) 16 JHB (et al) to supply text. 5 pp10 lines 21-29 Add a legend as per the following Figure 2 to include "LLC, MAC, LSAP, MSAP & PhSAP". Also in Figure 1 include "MSAP" in the figure. 6 pp11 line(s) 41 Move this line to pp10 line 54. 7 pp12 line(s) 6 Title Caps for Link Service Access Points. 8 pp12 line(s) 10 - "NO" Insert proposed text following to describe MSAPs. "The MAC Sublayer supporting the LLC Sublayer is identified by a MAC Service Access Point (MSAP), or MAC addresses. Each instance of a MAC has at least a universally unique address (MSAP), will respond to a network wide broadcast address (MSAP) and may also respond to several group addresses (MSAPs). It is by this means that communications between connected end points may be exclusively, by closed user group(s), or universally addressable. Clause 6 provides details of these addresses are constructed and used." 9 pp14 line(s) 24-28, and 30 - "NO" See comment "1". In an Overview and Architecture document there should be a clear statement of what repeaters and bridges are. For me this text is not enough! Not having ISO/IEC 10038 to hand I do not know what graphics there are therein but two exemplar models showing a Repeater and a Bridge would seem appropriate here. 10 pp15 line(s) 3-6 MACs also do filtering of MAC addresses etc. The MSAP text in lines 27-28 in "4.3" below suitably expanded would be appropriate. 11 pp15 line(s) 14 "channels, in" S/B "channels in" 12 pp15 line(s) 32 - "NO" This would be good place for a section "4.4" that provided an "Overview" of the IEEE 802 bridged LAN "Architecture". Clause 6 is full of stuff about MAC addresses and MSAPs but there is no "O&A" 13 pp24 - "NO" Unlucky "13"! He who produced this Draft 0 should get on and turn it into a complete Clause. __x__ I disapprove for the following reasons. r.v.slager_________________ rvslager@vnet.ibm.com______ 919-553-4017_______________ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Page 19 line 35: add comment in the rough order of: "(802.5 would quote this address as 35-7B-12-00-00-01. See section 6.4 for a discussion of bit-ordering and different MACs) " Page 23 Add a blurb regarding Functional addresses. Page 22 line 9: change to the new 802.5 standard. Page 16 figure 3, what is N ? Page 14 line 42, "clause 7" of which document? Page 10 Figure 1, Acronyms used before definition. EMAIL VOTING BALLOT November 2, 1995 SUBJECT: P802/D21: Overview and Architecture (second edition) ___X__ I approve (may attach non-binding comments below) Bob Watson rcw@rtp.connectware.com (919) 481-5017_______ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Page 10: Figure 1: MSAP definitely needs to be added to the figure. Page 11: Figure 2: The bracket (}) beside "MAU" must extend from the bottom of the AUI bracket to the top of the MDI bracket. EMAIL VOTING BALLOT 2 Nov 95___________ SUBJECT: P802/D21: Overview and Architecture (second edition) __X__ I disapprove for the following reasons. __Pat Thaler_____________ _pat@hprnd.rose.hp.com _916 785 4538___________ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ The following comments are the basis for my disapprove ballot: 2.3 pg 9 line 17 and 7 pg 24: There are several places where the draft indicates that more material (generally related to isochronous services) will be added later. It isn't made clear when the material will be added or how it will be balloted. If the material is to be added later as a supplement, then the notes should indicate that and there should be an existing PAR for the supplement at the time of publication. If the material is to be added as part of this revision of 802, then Working Group ballot should be repeated (or a confirmation ballot conducted) when the material is available. 1.2 pg 5 line 29-35: The term LAN is often used to mean a network of end-stations connected together through bridges as well as a single shared-medium LAN. This breadth of meaning is present here particularly in "a bridged or switched LAN operate just as though they were attached to a single LAN." As use of switching increases, the use of LAN to mean a switched LAN is increasing. In writing 802.3, we found it necessary to have a term that unambiguously meant a single shared-medium CSMA/CD network and we coined "collision domain" for that purpose. (Only one station within a collision domain can successfully transmit at a time. If two transmit a collision will occur.) In developing 802.12, we also found we needed a term for a single shared-access network and we generalized the term to "access domain." Within an access domain, only one station can successfully access the network (by transmitting) at a time. It would be helpful to introduce this term as a key concept.. It would help in the wording of this paragraph which currently uses "individual LAN," "single shared-medium LAN," and "single LAN" for that concept. A "bridged or switched LAN" is a "single LAN" and an "individual LAN." If it weren't it would be bridged or switched LANs. Please either use the term "single shared-medium LAN" consistantly or introduce the term "access domain" to cover this concept. 6.2.1 pg 18 line 48: Delete "locally" as this could be confused with locally administered addresses. Further, "locally" is not correct since the assignee is expected to administer the second 24 bits "globally" such that there exists no more than one instance of each universal address. Also change "locally" on line 51 to "globally" or "uniquely" or change the sentence to "and the value assigned by the asignee is contained in octets 3, 4, 5." (I like the aesthetics of the latter because it gives the sentence parallel construction.) 6.3.1 pg 20 line 42: Delete "locally". Also on line 45. (These line numbers are approximate. The line numbers on this page don't seem to line up with the text.) 6 pg 17-23: The comments on bit ordering are not true for some of the 100 Mb/s devices. For instance, with reference to 6.2.2, IEEE 802.3u 100BASE-T4 will transmit octets 0,1 and 2 simultaneously on three pairs and then repeat the process for octets 3, 4, and 5. IEEE 802.12 4-UTP will transmit parts of octets 0, 1, and 2 spread across 4 pairs at the same time. In both cases and in the case of IEEE 802.3u 100BASE-TX, the bits are encoded into block codes and can not be said to be transmitted in any particular order within the block. Also, multilevel signalling which may be used in future physical layers can encode multiple bits into a single symbol on the media. For instance, an eight level symbol may encode 3 bits. Please alter the descriptions of bit ordering to take into account the recent physical layers. __________________________________________________________ __________________________________________________________ Editorial comments which are not related to my disapprove: General: An abbreviations section would be a useful addition. That way a reader not reading the whole document (or who has forgotten the earlier expansion of the abbreviation) can find the expanded form quickly rather than having to search the whole document. 1.2 pg 5 line 26: Re: "from a few Mbit/s..." This comment is a real nit, but we have at least one LAN on our books that is at 1 Mb/s and therefore below your range for LANs: 802.3 1BASE5. It isn't used much if at all now, but the spec hasn't been obsoleted. Also, what is the lowest data rate for 802.11. You may want to start the range at 1 Mb/s. 1.2 pg 5 line 26 and elsewhere: The abbreviation for megabits per second should be Mb/s not Mbit/s. This is what the measurements gurus told us when we wrote 802.12. 1.2 pg 5 line 44: "Error rates and delay may be slightly higher than might be obtained on a LAN." Please delete this sentence as it seems awful short on meaning especially when the may, slightly and might are taken into account. LAN delays will vary a lot more than "slightly" depending on LAN data rate, loading, etc. Depending on the particular LAN and MAN technology under consideration, the delay might also be significantly higher or slightly to significantly lower. What is certain is that the propogation delay of a MAN is likely to be higher than that of a LAN because of the greater distance covered. However, that is often a small part of the total delay. Error rates may also be better on some MANs than on some LANs. For instance, a fiber optic MAN vs a copper LAN. 2.1 pg 7 line 17: The date is "1995". 2.2 pg 8 line 11: Perhaps there should also be a statement that some (many?) of the documents in 2.1 contain specifications of managed objects specific to themselves. 3. pg 9 line 32: There should be some mention of the Protocol Implementation Conformance Specification Proforma in this section. It is particularly relevant to claims of conformance for devices that implement a portion of a standard as the standards we produce now often have separate PICS Proformas to cover separate types of devices. The PICS can be a tool to simplify identifying the portions of the standard are implemented. Figure 2 pg 11: The CSMA/CD LAN/RM actually applies to 10 Mb/s CSMA/CD. 100 Mb/s CSMA/CD uses a different one. Also, the bracket for the MAU should include the MDI, the whole PMA and the AUI connector (represented by the shaded box on top of the PMA). Some depictions in 802.3 draw the MAU bracket up to the top of the AUI connector box and some to the middle of the box. 4.2.3 pg 14 line 22: A repeater does not fit the definition of internetworking. It is not connecting "a LAN to another network." It is providing connectivity within a network; "intranetworking" as opposed to "internetworking." Please remove repeater from the description of interworking and describe it as an element of a LAN rather than an element between LANs. Also, you may want to make the additional distinction that bridges can be used between LANs/MANs of different types. 4.2.4 pg 14 line 43: There is currently discussion of flow control within the full duplex task forces of 802.3 and 802.12. A number of the flow control methods that have been proposed (perhaps all of them) are independent of the type of LLC service being used. Therefore, the statement that type 1 operation does not include flow control procedures is currently true. It may not be strictly true in the future. Perhaps something should be said to the effect that connectionless or type independent flow control methods are under consideration. 4.2.5 pg 15 line 5: If flow control is implemented for a full duplex MAC, then the MAC Sublayer will also perform access control functions even though it is not using a shared communication resource. 5.2 pg 16 line 4: "van" should be "can" 5.3 pg 16 line 36. This information seems slightly out of place here. Also, I think it should be covered by a shall. I suggest modifying the first sentence of the paragraph to "All SNAP PDUs shall use the LLC address reserved for SNAP and conform to ... Information Field. The LLC address reserved for SNAP has the bit pattern 01010101." 6 pg 17 line 11: "cannot" should be "shall not." Unfortunately, some assignees have proved in the past that they can inadvertantly change them. Also, the text as it is does not explicitly cover someone who has not gotten an assignment appropriating someone else's. There has been at least one case where vendor A copied vendor B's driver and assigned MAC addresses from B's address space because the driver was written to only run with vendor B's OUI. Please state that one shall only use an OUI if it has been assigned to one or the use is allowed by the assignee. By the latter condition, I am trying to cover OEM relationships and situations where an OUI is used for a publically available protocol. 6 pg 17 : The acronym OUI is often used for Organizationally Unique Identifiers. I'm surprised you don't use it here as the repetition of the full name gets a bit tiresome. 6.1.2 pg 18 line 19: For the original 802.3 and 802.5 encodings, each bit is represented by a separate symbol on the media and bits can be said to travel in an order. I don't recall if that holds true for all 802.4 encodings. In any case, in the 802.3u and 802.12 encodings block codes covering 4, 5, and 8 bits per block are used. In some cases, the physical layer also sends bits on separate lines at the same time. The concept of bits being transmitted in a specific order does not apply to these block codes. Also, multilevel codes where multiple bits are represented by a single symbol are under consideration. Please modify the text to cover this situation. 6.2.1 pg 19 line 12: I think that "can have" would be better "may assign". 6.2.1 pg 19 line 16: Please change to "...used for purposes that would lead to skipping large numbers of them (for example as product identifiers...procedures)." There are other uses that might leave large blocks unused and the text should be broadened to cover them. Also, the last paragraph of the section (lines 25-27) covers the same ground. It would be preferable to move it up to here. 6.2.1 pg 19 line 21: Please capitalize "However." 6.2.1 pg 19 line 33: See my comment on 6.1.2 pg 18 line 19. 6.2.2 pg 19 line 45: See my comment on 6.1.2 pg 18 line 19. 6.2.2 pg 19-20: Please delete 6.2.2. It seems to me that this subclause repeats information that already is stated in 6.2 and adds nothing. Alternately, delete some of the duplicated information from the prior subclauses. Also, the comments on bit ordering are not entirely accurate. 6.3.1 pg 20 line 46-48: "assigned by the IEEE" is not exactly correct. The identifiers with the X bit set to 0 are assigned by the assignee of the OUI contained in the identifier. IEEE assigns the OUI not the identifier. 6.4 pg 22 line 5: "including all the data up to, but not including," is rather awkward phrasing. How about: "and ending directly before" instead? -------