IETF Perspective on Formal Languages Workshop - Framework and Scope of Formal Languages

1
IETF Perspective on Formal LanguagesWorkshop -
Framework and Scope ofFormal Languages
O. Monkewich Geneva, March 2, 2002
2
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
Relationships Among Internet Bodies
4
IETF
5
IETF Standards (RFC) Process
6
Comparison IETF vs. ITU -T
7
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)
• USA 63 Sweden 3
• Japan 8 UK 3
• Canada 4 Finland 2
• France 3 Korea 2
• Germany 3 Other 9

8
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
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
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
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
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
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
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
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
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
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
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
How to bring Formal Languagesinto 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
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 Chairmans 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
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.

22
(No Transcript)