Subject: [rohc] WG last-call for the RFC 3095 Implementer's Guide

From: "Lars-Erik Jonsson \(LU/EAB\)" <[email-masked]>
Date: Wed, 14 Dec 2005 10:34:01 +0100

ROHCers,

The RFC 3095 Implementer's Guide has evolved based on input
from implementer's of RFC 3095, starting at the first ROHC
interop in August 2001. Since the document now tends to be
stable, we believe it is ready for publication as an RFC.

Originally, we did not intend to ever publish this document,
but since we later on changed our plans regarding the bis
work for RFC 3095 (which will be a revised standard set),
we also changed our plans for this document. The Implementer's
Guide actually defines "how to implement RFC 3095 in an
interoperable way", i.e. by publishing it we provide what is
needed to get interoperable profile implementations, although
we do not plan to do more work on the profiles of RFC 3095.
The document category is not yet clear. One could say that
this document updates RFC and should be Standards Track, but
one could also consider simply making it Informational, i.e.
by publishing it we are just making sure this knowledge is
documented and made available.

The target document category will be further discussed with
the AD and the IESG, but we believe the WG has now finalized
its work on the document, and we are therefore now
last-calling the following document:

            draft-ietf-rohc-rtp-impl-guide-16.txt
                 (for publication as [To be discussed with AD])

This will be the usual two-week WG last-call as suggested in
RFC2418. Please direct last-call comments to the ROHC mailing
list [email-masked] before Wed, 2005-12-28, 18:00 UTC.

Committed document reviewers are Carl Knutsson and Biplab Sarkar.

Rgds,
/L-E

--------------------------------------
Lars-Erik Jonsson
IETF ROHC WG Chair
E-mail: [email-masked]
Phone: +46 8 404 29 61

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: "Sarkar, Biplab" <[email-masked]>
Date: Mon, 26 Dec 2005 16:38:27 +0530

Erik,

Please find my comments on the doc below:

[1] Ref: [8.4]
How does an UOR-2* packet with an Extension-3 differ from the IR/IR-dyn
packet?  Both seem to have same profile updation capability. When does
the compressor decide to send UOR-2*+Ext-3 packet over IR/IR_Dyn packet?

[2] Ref: [8.10]
Do you mean to say that we shall be having a new packet type for
UDP-Profile? Can you please elaborate upon the format of that packet? As
per RFC3095 [5.11.3] there is already an UOR-2 packet defined.

 [3] Ref: [2.2]
 I am just curious to know why we thought of having padding which
precedes the original information. In doing so we had to incorporate a
predefined pattern as padding. Any bit error in that padding will result
in dropping the entire packet.  Can't we incorporate padding at the end
of the packet (i.e. after the payload)?

[4]
The RFC doesn't seem to have any value for timers. Should there be any
prescribed values of timers for interoperability. 

Thanks
Biplab.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Lars-Erik Jonsson (LU/EAB)
Sent: Wednesday, December 14, 2005 3:04 PM
To: [email-masked]
Subject: [rohc] WG last-call for the RFC 3095 Implementer's Guide

ROHCers,

Rgds,
/L-E

"This email message and any attachments are confidential information of Starent Networks, Corp. The information transmitted may not be used to create or change any contractual obligations of Starent Networks, Corp.  Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon this e-mail and its attachments by persons or entities other than the intended recipient is prohibited. If you are not the intended recipient, please notify the sender immediately -- by replying to this message or by sending an email to [email-masked] -- and destroy all copies of this message and any attachments without reading or disclosing their contents. Thank you."

---

From: "Lars-Erik Jonsson \(LU/EAB\)" <[email-masked]>
Date: Fri, 30 Dec 2005 12:04:46 +0100

Biplab,

Thanks for the review!

You had a few questions, and answers can be found below.

/L-E

> [1] Ref: [8.4]
> How does an UOR-2* packet with an Extension-3 differ from the
> IR/IR-dyn packet?  Both seem to have same profile updation
> capability. When does the compressor decide to send UOR-2*+Ext-3
> packet over IR/IR_Dyn packet?

The decision is an implementation issue. The difference in content
is however that an UOR-2 with extension 3 does not have to carry
all the information carried by an IR-DYN. Extension 3 is a flexible
and variable format. If you want to update most of the dymanic
data, IR-DYN is probably the best choice, but this is something
an implementer has to decide how to handle.

->> No change needed!

> UDP-Profile? Can you please elaborate upon the format of that
> packet? As per RFC3095 [5.11.3] there is already an UOR-2 packet
> defined.

Yes, and this is the only thing section 8.10 points out.
...i.e. that there is only one single UOR-2 format with profile 2.

->> No change needed!

> predefined pattern as padding. Any bit error in that padding
> will result in dropping the entire packet.  Can't we incorporate
> padding at the end of the packet (i.e. after the payload)?

Well, ROHC padding IS NOT supposed to be used if the underlying 
technology is a good one. Only if the underlying technology is not
capable of being flexible should ROHC padding be used. I do not think
there had been any difference when it comes to error handling if the
padding had been at the end. Anyway, the implementer's guide is not
supposed to make changes to the standard.

->> No change needed!

> prescribed values of timers for interoperability.

The state machine itself is not a normative part of the standard,
neither are the timers. Further, even if the timers were considered
normative, they would be independent between compressor and 
decompressor, and no values must be specified to ensure
interoperability.

->> No change needed!