Signaling Compression (SigComp) Corrections and Clarifications
draft-ietf-rohc-sigcomp-impl-guide-10

[Ballot discuss]
I do not think that the title of this document is on target.
  This document provides normative updates to several RFCs, not
  just guidance to implementers.

  Section 12 identifies some "relatively low cost bugs".  Is the intent
  to warn people about the bugs without fixing them.  Please provide
  some rationale.  How (if at all) does an implementation change?

  To resolve this concern, the following text was proposed for
  Section 12, final paragraph

  OLD:
  These are seen to be relatively low cost bugs as only these 5 strings
  are affected and they are only affected under certain conditions.

  NEW:
  This document does not correct the dictionary, as any changes to the
  dictionary itself would be non-backwards-compatible, and require all
  implementations to maintain two different copies of the dictionary.
  Such a cost is far too high for a bug that is trivial to work around
  and has negligible effect on compression ratios.  Instead, we point
  out the flaw so as to allow implementers to avoid any consequent
  problems.  Specifically: if the bytecodes sent to a remote endpoint
  contain instructions that load only a sub-portion of the SIP/SDP
  dictionary, then the input stream provided to those bytecodes cannot
  reference any of these five offsets in the offset table unless the
  corresponding string portion of the dictionary has also been loaded.
  For example, if bytecodes loaded only the first three priorities of
  the dictionary (both string and offset table), use of the offset for
  "send" (at 0x089d) would be valid; however, use of the offset for
  "phone" (at 0x00f2) would not.

[Ballot comment]
The Title page header should include:
  "Updates: 3320, 3321, 3485 (once approved)"

  In section 1, there is a missing end quote.  It should say:
  >
  > "in section RFC-3320:3.4" refers to section 3.4 of RFC 3320 [1]
  >
  This syntax is not used consistently.  Some examples:
    - section RFC3320:7
    - section RFC3320-9.4.2
  Please fix the sentence in Section 1, and then use it consistently.

  Please pick one spelling: "Sigcomp" or "SigComp"

[Ballot discuss]
I do not think that the title of this document is on target.
  This document provides normative updates to several RFCs, not
  just guidance to implementers.

  Section 12 identifies some "relatively low cost bugs".  Is the intent
  to warn people about the bugs without fixing them.  Please provide
  some rationale.  How (if at all) does an implementation change?

[Ballot discuss]
In the security considerations section, the document says:

  This document updates SigComp [1], SigComp Extended [2] and the
  SigComp Static Dictionary [4].  The security considerations for [2]
  and [4] are the same as for [1]; therefore, this section discusses
  only how the security considerations for [1] are affected by the
  updates.

That seems to imply that an "Updates:  RFC 3320" is needed.  Brian
has asked a larger question, and I think it should be answered, but
this seems to be required for consistency.

[Ballot comment]
I have concerns about the ease-of-use of the document. After some hesitations I reached the conclusion that they are not critical to grant a DISCUSS, yet it may be well if the editors and WG would consider these:

1. The title of the document is mis-leading - it is more than an 'Implementer's Guide' as some changes alter normative text in other documents. I believe that 'SigComp - Implementer's Guide, Clarifications and Updates' may be more appropriate.

2. Because of changes (corrections and additions) of normative text the header should mention that the document updates RFC 3320 and RFC 3485. I could not find updates to normative text in 3321, but maybe I missed them.

3. The document is a mix of implementation hints, clarifications and updates. Future implementers of SigCom would have a hard time to find the changes affect normative text in other documents. Most of the updates are concentrated i believe in Sections 4 and 12. It would help I believe if an Appendix would resume in one place all those updates

4. The style of the document is inconsistent on respect to references to other documents, which may reflect different authorship. For example Section 5 prpvides no refereces to 3320 sections, as other sections in the document do.

[Ballot comment]
Does this or doesn't this formally update RFC 3320, RFC 3321, RFC 3485?

This should be stated very clearly in the Abstract if a formal "updates" is intended.

IANA Last Call Comment:

** Please pay attention to Action #2 **

Upon approival of this document IANA will take two actions:

Action #1:
Upon approval of this document, the IANA will make the
following assignments in the "SigComp Registry - per [RFC3320]"
registry located at

http://www.iana.org/assignments/sigcomp-namespace

OLD:
Value (in hex) Description Reference
-------------- ------------------------------ ---------
00 (Reserved) [RFC3320]
01 SigComp version 1 [RFC3320]
02 SigComp version 2 (NACK support) [RFC4077]



NEW:
Value (in hex) Description Reference
-------------- ------------------------------ ---------
00 (Reserved) [RFC3320,RFC-sigcomp-impl-
guide-09]
01 SigComp version 1 [RFC3320,RFC-sigcomp-impl-
guide-09]
02 SigComp version 2 (NACK support) [RFC4077,RFC-sigcomp-
impl-guide-09]

Action #2:
The IANA consideration of the document mentions that it
updates the reference for a static dictionary from RFC3485.
RFC3585 did not create a registry thus there is no action
for IANA. Unless RFC3585 IANA considerations where wrong.


We understand the above to be the only IANA Action for this document.

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 mainly been reviewed by active WG members and SigComp experts, but some passive WG participants were also asked to review the document prior to the WGLC.

(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, the document provides guidelines to SigComp implementers, and it has been written and reviewed by experienced implementers of the protocol. That should in my view ensure sufficient review.

(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 "SigComp camp" of 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, and there are no references to pending documents.

(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?

There are no such formal specifications in the document.

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


Technical Summary

  This document describes common misinterpretations and some
  ambiguities in the Signalling Compression Protocol (SigComp), and
  offers guidance to developers to clarify any resultant problems.

Working Group Summary

  This document has grown through concerns from implementers. The
  final document has been reviewed by the WG, and there is WG
  consensus that the document should now be published as an RFC.

Document Quality

  There are several independent implementations of SigComp, which
  are in general already implemented according to this document.
 
Personnel
       
  Document Sheperd for this document is Lars-Erik Jonsson, and Magnus
  Westerlund is the Responsible Area Director.