CURRENT MEETING REPORT Minutes of the Guide for Internet Standards Writers Working Group (STDGUIDE) Reported by Peter Desnoyers / Midnight Networks Agenda The initial agenda was: - Presentation of draft document - Discussion of missing areas o suggestions from mailing list: MIBs, BNF, terms, examples o others - Document scope - Other topics o optional features ("SHOULD" / "MAY") o other Discussion of draft document The draft document which had been distributed before the meeting was presented. The main issues discussed were (a) the role of examples in specifications, and (b) the degree to which the context of a protocol should be identified in the specification. Although examples can be useful in explaining difficult points, several people pointed out problems that have occured in the past where examples have caused confusion. In particular, some readers may assume that parts of a specification not covered in an example are optional, and otherwise consider the examples to be definitive rather than illustrative. The issue of identifying the context in which a protocol is used was discussed, with BGP-4 used as an example. It was agreed that especially in such cases a specification cannot educate a reader in all the issues surrounding the use of a protocol. However, there did not appear to be agreement on whether an effort should be made in specifications to identify that context and reference other documents. Additional topics not in first draft MIBs: A suggestion was made on the list to add a section on MIBs. After some discussion it was decided that this would not be appropriate; to the extent to which this guide would apply to specifications in general, it would apply to MIB documents, while guidelines applying only to MIBs were felt to be within the domain of the Network Management Directorate. BNF notation: It was proposed on the list that the guide include a suggested form for BNF notation when used in specifying command--oriented protocols such as FTP. This was felt to be a good idea, such a section should describe the difference between lexical analysis and parsing as well. State machine descriptions: A section enumerating a number of good ways to describe a protocol state machine - including diagrams, tables, and languages - should be added. Implementation experience: A section briefly summarizing implementation experience could be added to specifications, and updated as the document moves through the standardization process or is updated by newer versions. (note that this is separate from any detailed implementation experience documents written by particular implementors) Document scope It was decided that the sample document outline included in the first draft should be removed. Due to the varying nature of the protocols which this guide would apply to, such an outline would be unlikely to apply equally well to all. In addition, the guide should specify a set of information that needs to be in a specification, rather than prescribing a format and mechanisms to be used in presenting that information. Optional features There was a great deal of discussion of optional protocol features. These were divided into behavioral options (e.g. whether you follow a "SHOULD" or not in an implementation), configurable options, and negotiable options. Much frustration was voiced at the existence of protocols which allow incompatible option sets, although consensus was not reached on (a) what level of option compatibility should be be met by any protocol specification, and (b) what guidelines can be used to produce this level of interoperability. Further work The authors will revise the document based on discussion from the meeting and submit it to the list.