1. IETF Perspective on Formal Languages Workshop - Framework and Scope of Formal Languages O. Monkewich Geneva, March 2, 2002

2. Geneva, March 2, 2002 - 1 Workshop on the Framework and Scope of Formal Languages What is IETF Develops open standards for the Internet. Resides under the umbrella of the Internet Society (ISOC) Open international community of –network designers –network operators –network vendors –network researchers. Open to any interested individual – no memberships. Responsible for the evolution of the Internet architecture and protocols and the smooth operation of the Internet.

3. Geneva, March 2, 2002 - 2 Workshop on the Framework and Scope of Formal Languages Relationships Among Internet Bodies Internet Society (ISOC) Internet Architecture Board (IAB) Internet Assigned Numbers Authority (IANA) Internet Research Task Force (IRTF) Internet Engineering Task Force (IETF) Umbrella Organization for IETF. Promotes the Internet. Discussion forum for social and regulatory issues. Policy and Appeal Board for IRTF and IETF Enables collaboration of researchers. Assign IP Numbers. Oversees DNS name registry. Internet Corporation For Assigned Names and Numbers (ICANN) Up to Sept. 1998 Since Sept. 1998

4. Geneva, March 2, 2002 - 3 Workshop on the Framework and Scope of Formal Languages IETF IESG Chair Area Director (IESG) Internet Engineering Steering Group... (WG) Working Group Chair Draft Editor Participants (BoF) Birds of a Feather Chair Participants IETF Chair IESG: -OKs standards at all stages -Approves new WGs WG: -Agenda to resolve some topic BOF: -Meeting(s) held to gauge level of interest in new WG IETF/IESG Chair: (Harald Alvestrand) Most influential and visible position ADs: (Area Directors) Very Influential WG Chairs: -Set meeting and work agendas -Determine consensus BOF Chairs: -Generate momentum toward a WG -Potential for influence Area Director

5. Geneva, March 2, 2002 - 4 Workshop on the Framework and Scope of Formal Languages IETF Standards (RFC) Process IESG Process IESG Approves x  “last call” >2 weeks later, decision issued Lack of voting procedures gives WG chairs and ADs great discretion Working Docs. x Working Group Process  Drafts edited and reviewed in email discussions and IETF meetings “Rough or working consensus” arrived at in opinion of chair WG Chair determines WG consensus Charter & Agenda WG IESG WG IESG WG Draft Internet Standard Proposed Internet Standard Standards Internet Draft (failed) Internet Standard

6. Geneva, March 2, 2002 - 5 Workshop on the Framework and Scope of Formal Languages Comparison – IETF vs. ITU -T Structure Management/Planning Length of meetings Plenary Areas Working Groups (WGs) Assembly Study Groups Working Parties (WP) IESG, IAB TSAG Plenary – ½ day every 4 months Areas – ½ day every 4 months Working Groups – ½ day every 4 months Assembly – 2 weeks every 4 years Study Groups – 1 or 2 days twice/year Working Parties – 10 days twice a year Plenary – current status, future plans Areas – current status, future plans WGs – current status, future plans Assembly – direction setting Study Groups – approvals WPs – standards development Meeting content Moderates the meeting Controls pace, builds consensus What does WG Chairman do? Where is the work done?Between meetings via email In the WP meetings What does the Editor do?Develops the RFC Records agreement in draft Recommendation MembershipsNo members; individual participants Member States, Sector Members, National Delegations Approval for new work or completion Within IESG Membership consensus subject to Member State veto Interoperate with reference implementation Conformance testing/formal methods Quality PhilosophyBottom up, issues driven Top down architectural model IETF ITU-T

7. Geneva, March 2, 2002 - 6 Workshop on the Framework and Scope of Formal Languages Importance of IETF The most influential body in the evolution of the Internet – it is the standards body for the Internet. Internet has become a commercial and public infrastructure. Internet growth is the most significant driver for the development of data network standards. IETF receives a large number of contributions –there are 2339 Internet Drafts (ID life is 6 months) IETF participation by country (London Meeting) –USA63%Sweden3% –Japan 8%UK3% –Canada 4%Finland2% –France 3%Korea2% –Germany 3%Other9%

8. Geneva, March 2, 2002 - 7 Workshop on the Framework and Scope of Formal Languages Members of ISOC 6 Platinum members ($100,000) –e.g., Cisco, Microsoft, Nortel Networks, 16 Sustaining-Gold members ($50,000) –e.g., British Telecom, Nokia, France Telecom, Oracle, Verizon, H-P, IBM, 1 Silver member ($25,000) –Morino Institute 59 Executive members ($10,000) –e.g., Alcatel, Ericsson, Fujitsu, Hitachi, Lucent, Marconi, NEC, Siemens, Telia, 10 Professional members ($5,000) –e.g., ECMA, ETRI, Swisscom, 34 Small Business members ($2,500) –e.g., ETSI, INTAP, INTELSAT, Stockholm University, 18 Startup Members (Free) –e.g., Aleron, Avici, 6000 Individual Members (Free)

9. Geneva, March 2, 2002 - 8 Workshop on the Framework and Scope of Formal Languages Basic Working Philosophy Specifications –Standards are written in ASCII characters to allow comments by anyone, without special tools. –The ASCII requirement is not likely to change or be seriously bent. –Specifications ambiguous, resolved by implementation Testing/Verification –Interoperability, reference implementation - not conformance testing. –Two implementations needed for a standards-track specification, interoperable for spec to be a standard. –Running code wins.

10. Geneva, March 2, 2002 - 9 Workshop on the Framework and Scope of Formal Languages Why Bring Formal Languages to IETF Specifications are ambiguous and favour the first implementor who resolves ambiguities to his satisfaction. Interoperability of subsequent implementations with those in the field is very difficult. Precise and unambiguous specifications would level the playing field for the implementors

11. Geneva, March 2, 2002 - 10 Workshop on the Framework and Scope of Formal Languages Current Specification Format in IETF Standards-Track RFCs –Must be capable of being expressed in ASCII. –Formal languages or notations expressed in ASCII: -Are acceptable -Have been used for years -No intention to stop using them There exist IESG guidelines on the use of formal languages.

12. Geneva, March 2, 2002 - 11 Workshop on the Framework and Scope of Formal Languages IESG View on Formal Languages Formal languages are useful tools for specifying parts of protocols. There is no well-known language that is able to capture the full syntax and semantics of reasonably rich IETF protocols. Expect that people will continue using English to describe protocols, with formal languages as a supporting mechanism.

13. Geneva, March 2, 2002 - 12 Workshop on the Framework and Scope of Formal Languages Pseudo-code (in ASCII) Specification may be written in a pseudo-code. Pseudo-code must be unambiguously defined in the document. Use of code in any known or intuitive language may be used to illustrate and support a specification which is in itself complete.

14. Geneva, March 2, 2002 - 13 Workshop on the Framework and Scope of Formal Languages Formal Languages (in ASCII)… A normative reference (RFC 2026) to the specification for that language is required. The language must be used correctly according to its specification. The specification must be verifiable and easy to extract from the document to run through a verification tool to check the syntax. The specification must be complete. Any modules referenced but not included in the specification are normative references.

15. Geneva, March 2, 2002 - 14 Workshop on the Framework and Scope of Formal Languages …Formal Languages (in ASCII) The specification must be reasonably implementation independent. It must be clear what parts of the specification are not in the language. Syntax checking tools need not be available before a specification is entered on the standards track. When such tools become available, they SHOULD be used. A specification that fails verification tools is not likely to progress.

16. Geneva, March 2, 2002 - 15 Workshop on the Framework and Scope of Formal Languages Arguments against Formal Languages They make one focus on the wrong part of the problem – on syntax, not semantics. They limit the review of specifications to those who can read the language. A home for a spec in graphical format has not been found – URL, RFC Annex, CD, …

17. Geneva, March 2, 2002 - 16 Workshop on the Framework and Scope of Formal Languages Where Formal Languages are Welcome in IETF Today Modelling and simulation of network or protocol parts to clarify or resolve unclear areas. Checking for syntax and semantic errors in specifications. Example: graphical SDL model of an OSPF- LSA network clarified traffic conditions in the network during routing table refreshment.

18. Geneva, March 2, 2002 - 17 Workshop on the Framework and Scope of Formal Languages Meeting IETF criteria Tools are needed that are capable of –viewing graphical format –syntax and semantic checking –validation and simulation capabilities Tools must be freely available to –amateur specification developers –individuals who comment on RFCs Simulation/validation results supporting standards development

19. Geneva, March 2, 2002 - 18 Workshop on the Framework and Scope of Formal Languages How to bring Formal Languages into IETF Find work in IETF where a formal language would be useful. Actively participate in solving specific Internet problems. Use formal languages and tools to speed up agreement and gain acceptance of the WG.

20. Geneva, March 2, 2002 - 19 Workshop on the Framework and Scope of Formal Languages SG 17 Initiative at IETF-52 About 1000 CD ROMs, entitled ITU-T Languages, have been distributed at IETF-52 in Salt Lake City –SDL viewer by Telelogic –SDL animated tutorial by Telelogic –INAP CS-1 and CS-2 and OSPF/LSA examples in SDL –ITU-T ASN.1, SDL, MCS and TTCN (URL) standards Two 1-hour demonstrations of SDL and CD ROM –Few attended, but those who did had only positive comments IETF Chairman’s remarks were positive –it was a nice gesture on the part of ITU –useful precision on what was agreed on –useful in catching mistakes prior to publication

21. Geneva, March 2, 2002 - 20 Workshop on the Framework and Scope of Formal Languages Summary The graphical or tabular form of any language cannot be included as part of the RFC body but is welcome as a tool for verifying or validating the RFC. The source of the difference between the IETF perspective on formal languages and that of ITU-T lies in “who contributes to standards development”, – individuals vs organizations Acceptance of formal languages would be greatly enhanced with free tools for reading, editing, syntax checking and simulation.