Formal Notation for RObust Header Compression (ROHC-FN)
draft-ietf-rohc-formal-notation-13

[Ballot discuss]
UNCOMPRESSED {
        version        [  4 ];
        header_length  [  4 ];
        tos            [  6 ];

tos is erroneous terminology; under RFC 2474 this should be dscp.
(If tos refers to anything, it refers to the whole octet, but then
according to RFC 2474 it would be called dsfield).

The same error occurs later in a slightly different form:

        tos_tc;        // 6 bits

[Note: this is only just a DISCUSS because it concerns examples, not
normative material. But it would be highly desirable to fix it,
to avoid the incorrect terminology being carried over into actual
profiles.]

[Ballot comment]
It would be useful if the document explained the level
of formality it actually provides. For instance, do we
have tools that given a formal definition, can generate
a full implementation of a compression profile? Or is
that only possible in some circumstances, or perhaps
not all? Are there checks that can be run on the
formal specification beyond satisfying syntactic
and basic semantic rules?

Note also the possibility that at least parts
of the specification can exist in natural
language only (see below) or be references
to external algorithms to computing specific
values.

> The ROHC-FN provides a library of commonly used encoding methods.
> Encoding methods can be defined using plain English, or using a
> formal definition consisting of e.g. a collection of expressions
> (Section 4.7) and "ENFORCE" statements (Section 4.9).

[Ballot comment]
(sorry, I missed a point the first time)

      UNCOMPRESSED {
        version        [  4 ];
        header_length  [  4 ];
        tos            [  6 ];

tos is erroneous terminology; under RFC 2474 this should be dscp.
(If tos refers to anything, it refers to the whole octet, but then
according to RFC 2474 it would be called dsfield).

The same error occurs later in a slightly different form:

        tos_tc;        // 6 bits

[Note: this is not a DISCUSS because it concerns examples, not
normative material. But it would be highly desirable to fix it,
to avoid the incorrect terminology being carried over into actual
profiles.]

Incidentally, I can't find this work anywhere in the charter or
milestones. Was there an explicit discussion whether standards
track is appropriate?

[Ballot comment]
UNCOMPRESSED {
        version        [  4 ];
        header_length  [  4 ];
        tos            [  6 ];

tos is erroneous terminology; under RFC 2474 this should be dscp.
(If tos refers to anything, it refers to the whole octet, but then
according to RFC 2474 it would be called dsfield).

The same error occurs later in a slightly different form:

        tos_tc;        // 6 bits

[Note: this is not a DISCUSS because it concerns examples, not
normative material. But it would be highly desirable to fix it,
to avoid the incorrect terminology being carried over into actual
profiles.]

PROTO Write-up

(1.a)  Who is the Document Shepherd for this document?  Has the
      Document Shepherd personally reviewed this version of the
      document and, in particular, does he or she believe this
      version is ready for forwarding to the IESG for publication?

I (Lars-Erik Jonsson) am the Document Sheperd for this document, and I have personally reviewed this version of the document, which I believe is ready for publication.

(1.b)  Has the document had adequate review both from key WG members
      and from key non-WG members?  Does the Document Shepherd have
      any concerns about the depth or breadth of the reviews that
      have been performed?

The document has been reviewed by both key WG members and by key non- WG members, and I am confident with the depth and breadth of the reviews.

(1.c)  Does the Document Shepherd have concerns that the document
      needs more review from a particular or broader perspective,
      e.g., security, operational complexity, someone familiar with
      AAA, internationalization or XML?

No concerns!

(1.d)  Does the Document Shepherd have any specific concerns or
      issues with this document that the Responsible Area Director
      and/or the IESG should be aware of?  For example, perhaps he
      or she is uncomfortable with certain parts of the document, or
      has concerns whether there really is a need for it.  In any
      event, if the WG has discussed those issues and has indicated
      that it still wishes to advance the document, detail those
      concerns here.

No concerns!

(1.e)  How solid is the WG consensus behind this document?  Does it
      represent the strong concurrence of a few individuals, with
      others being silent, or does the WG as a whole understand and
      agree with it?

There is strong consensus behind this document within the ROHC WG.

(1.f)  Has anyone threatened an appeal or otherwise indicated extreme
      discontent?

No!

(1.g)  Has the Document Shepherd personally verified that the
      document satisfies all ID nits?  (See
      http://www.ietf.org/ID-Checklist.html and
      http://tools.ietf.org/tools/idnits/).  Boilerplate checks are
      not enough; this check needs to be thorough.  Has the document
      met all formal review criteria it needs to, such as the MIB
      Doctor, media type and URI type reviews?

I have reviewed the document, and believe it satisfies all criterias.

(1.h)  Has the document split its references into normative and
      informative?  Are there normative references to documents that
      are not ready for advancement or are otherwise in an unclear
      state?  If such normative references exist, what is the
      strategy for their completion?  Are there normative references
      that are downward references, as described in [RFC3967]?  If
      so, list these downward references to support the Area
      Director in the Last Call procedure for them [RFC3967].

References are split into normative/informative. There is one pending normative reference to the ROHC Framework, which has just passed IETF last-call.

(1.i)  Has the Document Shepherd verified that the document IANA
      consideration section exists and is consistent with the body
      of the document?  If the document specifies protocol
      extensions, are reservations requested in appropriate IANA
      registries?  Are the IANA registries clearly identified?  If
      the document creates a new registry, does it define the
      proposed initial contents of the registry and an allocation
      procedure for future registrations?  Does it suggested a
      reasonable name for the new registry?  See
      [I-D.narten-iana-considerations-rfc2434bis].  If the document
      describes an Expert Review process has Shepherd conferred with
      the Responsible Area Director so that the IESG can appoint the
      needed Expert during the IESG Evaluation?

This document implies no IANA actions.

(1.j)  Has the Document Shepherd verified that sections of the
      document that are written in a formal language, such as XML
      code, BNF rules, MIB definitions, etc., validate correctly in
      an automated checker?

Reviewers have confirmed the correctness of the formal specifications.

(1.k)  The IESG approval announcement includes a Document
      Announcement Write-Up.  Please provide such a Document
      Announcement Writeup? 


Technical Summary

  This document defines ROHC-FN (RObust Header Compression - Formal
  Notation); a formal notation to specify field encodings for
  compressed formats when defining new profiles within the ROHC
  framework. Previous header compression profiles have been so far
  specified using a combination of English text together with ASCII
  Box notation. Unfortunately, this was sometimes unclear and
  ambiguous, revealing the limitations of defining complex structures
  and encodings for compressed formats this way. The primary
  objective of the Formal Notation is to provide a more rigorous
  means to define header formats -- compressed and uncompressed -- as
  well as the relationships between them. ROHC-FN offers a library of
  encoding methods that are often used in ROHC profiles and can
  thereby help simplifying future profile development work.

Working Group Summary

  This document has been in the workings for several years, it first
  appeared as part of of a header compression research proposal known
  as "EPIC", and became an official WG item 2002, to serve the ROHC
  TCP profile development. Its form has changed through the years,
  but it has now been rather stable for a long time and is used as
  a basis for both the ROHC TCP profile and the upcoming ROHCv2
  profiles. The document has been carefully reviewed by both the WG
  and externals, and there is WG consensus that the document should
  now be published as an RFC.

Document Quality

  The formal notation specified by this document has now been put in
  use for two ROHC profile specifications, the TCP and the ROHCv2
  profiles. The document has been both manually reviewed by several
  parties with different perspectives, and checked by automated
  tools. During WGLC, the document was reviewed by the committed WG
  reviewers Mark West, Carsten Bormann and Joe Touch, as well as by
  Sally Floyd, who provided a review at the request of the Transport
  Area Directorate.

Personnel
       
  Document Sheperd for this document is Lars-Erik Jonsson, and Magnus
  Westerlund is the Responsible Area Director.