View
226
Download
0
Category
Tags:
Preview:
Citation preview
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.
Geneva, March 2, 2002 - 3Workshop on the Framework and Scope of Formal Languages
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
Geneva, March 2, 2002 - 4Workshop on the Framework and Scope of Formal Languages
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
Geneva, March 2, 2002 - 5Workshop on the Framework and Scope of Formal Languages
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
Geneva, March 2, 2002 - 6Workshop on the Framework and Scope of Formal Languages
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
Geneva, March 2, 2002 - 7Workshop 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)– USA 63% Sweden 3%– Japan 8% UK 3%– Canada 4% Finland 2% – France 3% Korea 2%– Germany 3% Other 9%
Geneva, March 2, 2002 - 8Workshop 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)
Geneva, March 2, 2002 - 9Workshop 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.
Geneva, March 2, 2002 - 10Workshop 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
Geneva, March 2, 2002 - 11Workshop 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.
Geneva, March 2, 2002 - 12Workshop 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.
Geneva, March 2, 2002 - 13Workshop 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.
Geneva, March 2, 2002 - 14Workshop 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.
Geneva, March 2, 2002 - 15Workshop 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.
Geneva, March 2, 2002 - 16Workshop 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, …
Geneva, March 2, 2002 - 17Workshop 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.
Geneva, March 2, 2002 - 18Workshop 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
Geneva, March 2, 2002 - 19Workshop on the Framework and Scope of Formal Languages
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.
Geneva, March 2, 2002 - 20Workshop 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
Geneva, March 2, 2002 - 21Workshop 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.
Recommended