NOTE: This charter is a snapshot of that in effect at the time of the 38th IETF Meeting in Memphis, Tennessee. It may now be out-of-date.
Greg Scott <email@example.com>
Operations and Management Area Director(s):
Scott Bradner <firstname.lastname@example.org>
Michael O'Dell <email@example.com>
Deirdre Kostick <firstname.lastname@example.org>
Mike O'Dell <email@example.com>
To Subscribe: firstname.lastname@example.org
In Body: subscribe stdguide
Description of Working Group:
This working group will provide a forum for implementers, testers, and users of current Internet standard protocols to provide feedback on the standards themselves; i.e., on what aspects of the documents defining the standards have assisted or hindered the implementation, test, and use of those protocols.
The purpose of the group is to collect this information, much of which survives today as word-of-mouth knowledge in the Internet community, and present it as a BCP document. This document will cover definitions, guidelines, and a list of heuristic rules for avoiding common mistakes in writing Internet protocol standards documents.
Note: This working group is jointly chartered by the Operational Requirements Area and the User Services Area.
Goals and Milestones:
Post a detailed outline for the document and a call for participation.
Post guide for standards writers as an Internet-Draft.
Meet at Dallas IETF.
Issue revised Internet-Draft based on input from list and working group meeting.
Submit Internet-Draft to IESG for consideration as a BCP RFC.
· Guide for Internet Standards Writers
No Request For Comments
Minutes of the Guide for Internet Standards Writers (STDGUIDE) Working Group
Reported by: Gregor Scott
The meeting consisted of a presentation and discussion of the latest changes made to the draft.
The discussion on Section 2.1, "Discussion of Security," covered the following points:
· In addition to direct attacks, there is a danger that disclosure of information could be used to attack another system or reveal patterns of behavior that could be used against an individual or organization.
· The user interface could provide an avenue of attack. Also, deliberate or inadvertent user behavior may open the system to attack.
· That the document does not address the broad MIB security issues, or the implications of the compromise of MIB information.
· Discussion of the threat model and assumptions should appear early in the standard.
· That discussion of security throughout the document would insure the integration of security during protocol development.
· The security considerations section of the standard should include a discussion of the security mechanisms that were not selected and the rationale for those decisions.
Concern was expressed that the current wording of Section 2.11, "Notational Conventions," could be interpreted as mandating the use of ABNF defined in STD 11 and the ASN.1 subset defined in STD 16. The intent of the paragraph was to require writers who use a variation of a standard notational convention to define that variation in the standard. The STD 11 and STD 16 citations were only meant as examples of editors who had done so. The editor will review the text to insure this is clear.
The discussion on Section 2.12, "IANA Considerations," covered the following points:
· The point was made that defining the procedures by which IANA assigns parameter values is outside the scope of this work.
· The purpose of this Working Group's RFC is to advise standards writers to coordinate with IANA. It is IANA's responsibility to inform editors of the procedures it uses.
IETF Working Groups do not have the authority to assign parameter numbers themselves.
Section 2.15, "Network Stability," was originally targeted at routing protocols. During the discussion it was pointed out that applications could also have dynamic behavior that would affect the network. An example could be a messaging protocol suddenly dumping a large number of messages onto the network. The current text needs to be expanded to cover such dynamic behavior.
The comments from the meeting will be incorporated into the draft. A new version will be prepared by the end of April 1997. A Working Group last call will be issued upon the release of the next Internet-Draft. The goal is to submit the Internet-Draft to the IESG NLT the end of May 1997.