Subject: RE: [rohc] Closing sigcomp issues - Instalment 2 [UPDATED]

From: "Lars-Erik Jonsson (EPL)" <[email-masked]>
Date: Fri, 26 Apr 2002 11:30:43 +0200

Dear all,
 
After closing most SigComp issues, as listed in Instalment 1, 
it is time to address the ones still open. I will not focus
on the technical content of these open issues, but mainly on
the status, as it looks from the discussions on the list.
Please ignore the previous posting of Instalment 2, since 
it was not complete. The issues discussed in this updated
version are those that will be considered as part of 
Instalment 2. The rest will be handled in a final Instalment 3.

The issues still open are:
  lejo-7
  lejo-8
  lejo-9*
  lejo-10*
  rp-1
  rp-8
  cabo-11
  cabo-8
  cabo-6*
  cabo-15*
  cabo-16
  sugar-3*
  sugar-6*

From what I have seen on the list, it should now be possible
to close some of these issues, since solutions have been
proposed without objections, or with rough consensus to go on
with the  proposed solution. These issues are (also marked 
with a "*" above):

lejo-9:

  The IANA section has been rewritten, with minor adjustments,
  based on discussions on the list.

  Resolution proposal: Replace current text with the following:

  "SigComp requires a 1-octet name space, the SigComp_version,
  to be created by the IANA. Upgraded versions of SigComp must
  be backwards-compatible with version 0x00, described in this
  document. Adding additional UDVM instructions and assigning
  values to the reserved UDVM memory addresses are two possible
  upgrades for which this is the case.

  Following the policies outlined in [RFC-2434], the IANA policy
  for assigning a new value for the SigComp_version shall require
  a Standards Action. Values are thus assigned only for Standards
  Track RFCs approved by the IESG."

lejo-10:
  
  Issue has been discussed and finally summarized by Hans in:
  
  http://www1.ietf.org/mail-archive/working-groups/rohc/current/msg00450.html
  There have been no objections to this summary.
 
  Resolution proposal: Clarify sender behavior if S-bit is
                       switched back to zero. The text of
                       Section 9.4.7 should be updated
                       based on the following text:
   
  "The sending endpoint is welcome to change its mind and switch
  the S-bit back to 0 in a later message. However, the receiving 
  endpoint is under no obligation to use the original
  state_memory_size for the session; it may choose to allocate
  less memory to the session or possibly none at all.
 
  Note: The format of Figure 13 is only for *local* presentation
  of parameters on the interface between UDVM and state handler,
  NOT a format for transmission between two endpoints."

cabo-6:
 
  Issue has been discussed on the list, and Richard has explained
  the purpose of the current proposal in the draft:
   
  http://www1.ietf.org/mail-archive/working-groups/rohc/current/msg00443.html
  Answer - "Feature", stick to what is in -05a
  There have been no objections to this proposal.

  Resolution proposal: Resolution proposed in current editors'
                       working document. 

cab0-15:
 
  Issue has been discussed on the list, and there seems to be
  rough consensus to stick to what is currently in the draft:
  http://www1.ietf.org/mail-archive/working-groups/rohc/current/msg00461.html

  Resolution proposal: Resolution proposed in current editors'
                       working document. 

  "decompression_memory_size: 2048 octets
  state_memory_size: 0 octets
  cycles_per_bit: 16
  SigComp_version: 0
  locally available state: none"

sugar-3:

  Issue has been discussed on the list, and a proposed action
  been provided by Carsten.

  Resolution proposal: Resolution proposed in current editor's
                       working document.

sugar-6:
 
  Issue has been discussed on the list, and there seems to be
  rough consensus that this functionality can already be
  provided, based on current editors' document.

  Resolution proposal: No action needed. Resolution provided
                       in current editors' working document. 

--------------------------------------
Lars-Erik Jonsson
IETF ROHC WG Chair
E-mail: [email-masked]
Phone: +46 920 20 21 07
Home: +46 920 999 57

My opinions are my personal opinions and should not be considered
as the opinions of my employer, if not explicitly stated. 

_______________________________________________
Rohc mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/rohc