ietf perspective on formal languages workshop - framework and scope of formal languages o. monkewich...

IETF Perspective on Formal LanguagesWorkshop - Framework and Scope ofFormal Languages

O. MonkewichGeneva, March 2, 2002

Geneva, March 2, 2002 - 2Workshop 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.


Relationships Among Internet Bodies

Internet Society(ISOC)

Internet ArchitectureBoard (IAB)

Internet AssignedNumbers Authority

(IANA)

Internet ResearchTask Force (IRTF)

Internet EngineeringTask 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 CorporationFor Assigned Names

and Numbers (ICANN)

Up to Sept. 1998 Since Sept. 1998


IETF

IESG Chair

Area Director

(IESG)InternetEngineeringSteering Group

. . .

(WG)WorkingGroup

Chair

DraftEditorParticipants

(BoF)Birds ofa 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

Area Director


IETF Standards (RFC) Process

IESGProcess

IESG Approves x

“last call”>2 weeks later, decision issued

Lack of voting procedures gives WG chairs and ADs great discretion

Working Docs.

x

WorkingGroupProcess

Drafts edited and reviewed in email discussions and IETF meetings

“Rough or working consensus” arrived at in opinion of chair

WG Chairdetermines

WG consensus

Charter & Agenda

WG

IESG

WG

IESG

IESG

WG

Draft InternetStandard

Proposed InternetStandard

Standards InternetDraft

(failed)Internet

Standard


Comparison – IETF vs. ITU -T

Structure

Management/Planning

Length of meetings

PlenaryAreasWorking Groups (WGs)

AssemblyStudy GroupsWorking Parties (WP)

IESG, IAB TSAG

Plenary – ½ day every 4 monthsAreas – ½ day every 4 monthsWorking Groups – ½ day every 4 months

Assembly – 2 weeks every 4 yearsStudy Groups – 1 or 2 days twice/yearWorking Parties – 10 days twice a year

Plenary – current status, future plansAreas – current status, future plansWGs – current status, future plans

Assembly – direction settingStudy Groups – approvalsWPs – standards development

Meeting content

Moderates the meeting Controls pace, builds consensusWhat 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

Memberships No members; individual participants Member States, Sector Members,National Delegations

Approval for new work orcompletion

Within IESG Membership consensus subject toMember State veto

Interoperate with reference implementation Conformance testing/formal methodsQuality

Philosophy Bottom up, issues driven Top down architectural model

IETF ITU-T


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%


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)


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.


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


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.


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.


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.


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.


…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.


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, …


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.


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


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.


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


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.

ietf perspective on formal languages workshop - framework and scope of formal languages o. monkewich...

Documents

scope of formal languageswhy

scope of formal languageswhat

scope of formal languagesbasic

scope of formal languagescurre

internet growth

internet architecture

internet bodiesgeneva

scope offormal languageso