Subject: [rohc] Closed: Closing sigcomp issues - Instalment 2

From: "Lars-Erik Jonsson (EPL)" <[email-masked]>
Date: Thu, 2 May 2002 10:37:20 +0200

Since we have not heard any objections to Instalment 2,
we should now be able to consider these issues as closed.

CLOSED: lejo-9, lejo-10, cabo-6, cabo-15, sugar-3, sugar-6

BR
/Lars-Erik

> -----Original Message-----
> From: Lars-Erik Jonsson (EPL) 
> [mailto:[email-masked]]
> Sent: den 26 april 2002 11:31
> To: [email-masked]'
> Subject: RE: [rohc] Closing sigcomp issues - Instalment 2 [UPDATED]
> 
> 
> 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

---

From: Carsten Bormann <[email-masked]>
Date: Sun, 05 May 2002 22:43:31 +0200

ROHCers,

the ROHC CVS site now has a version of the SigComp draft that should 
have the edits resulting from all remaining issues:

http://www.dmn.tzi.org/cgi-bin/cvsweb.cgi/udvm/udvm.nr

Due to the wonders of CVS, the sequence of edits is documented and can 
be related to the issues -- of course you can also just review the 
end-result.

(There is one possible exception; the authors need to decide whether to 
revert to -05 on section 4.2.2 (record marking) or to live with the 
result of the changes from revision 1.21 to 1.22. This decision should 
be reached tomorrow morning.)

We intend to submit -06 before noon UTC, i.e., before the I-D editor 
arrives at work.

So now would be a good time to have that last look at the document that 
is slated for WG last-call very soon.

Gruesse, Carsten