Subject: [rohc] WG last-call for ROHC MIB and related documents

From: [email-masked] (Carsten Bormann)
Date: Wed, 15 Jan 2003 17:20:59 +0100

ROHCers,

In Atlanta, we said we were going to have another re-spin of the ROHC
MIB to include LLA.  This has now been available for nearly a month,
and we believe the document has received enough review to issue the WG
last-call.  Together with this goes the terminology and examples
document as additional explanatory material that at some point is
expected to become part of the ROHC draft standard.

Therefore, we are now issuing a WG last-call for the following two
documents:

  draft-ietf-rohc-mib-rtp-05.txt
      (for publication as Proposed Standard)

  draft-ietf-rohc-terminology-and-examples-01.txt
      (for publication as Informational)

This is a regular two-week WG last-call.

Please direct WG last-call comments to the ROHC mailing list
[email-masked] before Wed, 2003-01-29, 18:00 UTC.

Gruesse, Carsten

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

---

From: Juergen Quittek <[email-masked]>
Date: Fri, 17 Jan 2003 10:55:32 +0100

ROHCers,

In order to facilitate your review of draft-ietf-rohc-mib-rtp-05.txt,
I point out the changes between version -04 and -05 below.

The draft contains three MIB modules: ROHC-MIB, ROHC-UNCOMPRESSED-MIB,
and ROHC-RTP-MIB. The ROHC-MIB module defines properties of ROHC instances,
ROHC channels, ROHC profiles, and ROHC compressor and decompressor contexts.
All managed objects in this module are assumed to be shared by all profiles.

The ROHC-UNCOMPRESSED-MIB module extends the ROHC-MIB by managed objects
that are specific to the ROHC uncompressed profile 0x0000 defined in RFC 3095.
The ROHC-RTP-MIB module so far extended the ROHC-MIB by managed objects that
are specific to the three other profiles defined in RFC 3095 (ROHC RTP profile
0x0001, ROHC UDP profile 0x0002, and ROHC ESP profile 0x0003.

Since version -05 also the ROHC LLA profile 0x0005 (defined in RFC 3242) is
supported by the ROHC-RTP-MIB module. For this purpose, the following managed
objects were added to entries of the rohcRtpContextTable:

rohcRtpContextAlwaysPad:
        "Boolean, only applicable to compressor contexts using the
         LLA profile.  If its value is true, the compressor must
         pad every RHP packet with a minimum of one octet ROHC
         padding."
    REFERENCE
        "RFC 3242, Section 5.1.1"
    DEFVAL { false }

rohcRtpContextLargePktsAllowed:
        "Boolean, only applicable to compressor contexts using the
         LLA profile.  It specifies how to handle packets that do
         not fit any of the preferred packet sizes specified.  If
         its value is true, the compressor must deliver the larger
         packet as-is and must not use segmentation.  If it is set
         to false, the ROHC segmentation scheme must be used to
         split the packet into two or more segments, and each
         segment must further be padded to fit one of the preferred
         packet sizes."
    REFERENCE
        "RFC 3242, Section 5.1.1"
    DEFVAL { true }

rohcRtpContextVerifyPeriod OBJECT-TYPE
        "This object is only applicable to compressor contexts
         using the LLA profile.  It specifies the minimum frequency
         with which a packet validating the context must be sent.
         This tells the compressor that a packet containing a CRC
         field must be sent at least once every N packets, where N
         is the value of the object. A value of 0 indicates that
         periodical verifications are disabled."
    REFERENCE
        "RFC 3242, Section 5.1.1"
    DEFVAL { 0 }

rohcRtpContextNHPs OBJECT-TYPE
        "This object is only applicable to contexts using the
         LLA profile.  It contains the number of all no-header
         packets (NHP) sent or received in this context, respectively."
    REFERENCE
        "RFC 3242, Section 4.1.1."

rohcRtpContextCSPs OBJECT-TYPE
        "This object is only applicable to contexts using the
         LLA profile.  It contains the number of all context
         synchronization packets (CSP) sent or received in this
         context, respectively."
    REFERENCE
        "RFC 3242, Section 4.1.2."
rohcRtpContextCCPs OBJECT-TYPE
        "This object is only applicable to contexts using the
         LLA profile.  It contains the number of all context check
         packets (CCP) sent or received in this context, respectively."
    REFERENCE
        "RFC 3242, Section 4.1.3."

rohcRtpContextPktsLostPhysical OBJECT-TYPE
        "This object is only applicable to decompressor contexts
         using the LLA profile.  It contains the number of physical
         packet losses on the link between compressor and
         decompressor, that have been indicated to the decompressor."
    REFERENCE
        "RFC 3242, Section 5.1.2."

rohcRtpContextPktsLostPreLink OBJECT-TYPE
        "This object is only applicable to decompressor contexts
         using the LLA profile.  It contains the number of pre-link
         packet losses on the link between compressor and
         decompressor, that have been indicated to the decompressor."
    REFERENCE
        "RFC 3242, Section 5.1.2."

The rohcRtpPacketSizeTable was extended such that in addition to "allowed"
 and "used" packet sizes (RFC 3095), it may also contain "preferred" packets
sizes (RFC3242). If a packet sizes in the table is allowed, preferred,
and/or used is indicated by three boolean managed objects called
rohcRtpPacketSizeAllowed, rohcRtpPacketSizePreferred, and
rohcRtpPacketSizeUsed. Additionally, the new managed object
rohcRtpPacketSizeRestrictedType indicates restrictions of preferred sizes:

rohcRtpPacketSizeRestrictedType
    SYNTAX      INTEGER {
                    nhpOnly(1),
                    rhpOnly(2),
                    noRestrictions(3)
                }
    DESCRIPTION
        "This object is only applicable to preferred packet
         sizes of compressor contexts using the LLA profile.
         When retrieved, it will indicate whether the packet
         size is preferred for NHP only, for RHP only, or
         for both of them."
    REFERENCE
         "RFC 3242, Section 5.1.1"

Have fun with the review!

    Juergen

---

From: Martin Stiemerling <[email-masked]>
Date: Wed, 29 Jan 2003 18:49:08 +0100

Hi,

comments on draft-ietf-rohc-terminology-and-examples-01.txt by Juergen 
and me:

General:
The document is very good, it is clear and precise and it is very useful 
for understanding ROHC integration into network.

General:
The Title "Terminology and Examples for MIB Modules and Channel 
Mappings" addresses MIB Modules. But without knwoning the WG context of 
this document, the reader would not be able to find out what it has to 
do with MIB Modules. Therefore, we suggest choosing the Title that 
expresses the content of the document, rather than the context that led 
to its creation, e.g. (addapted from section 8, line 1-2):
"Terminology and Concept for Use in ROHC Network Integration".

General:
Figures are not numbered. Since there are many of them in the document, 
we suggest to number them and give them captions.

Section 2, Paragraph on "Co-located compressor/de-compressor":
Line 4  talks about "the link" (and so does the paragraph on "Associated 
compressor/de-compressor"). However, the term "link" is not introduced. 
Therefore, some ambiquity remains in the terminology section. Can we 
clarfiy this by a proper definition of the term "link"? The beginning of 
section 3.1 has some text coming close to a definition of "link".

Section 4, line 1:
  "For e.g. the purpose of " could perhaps be replaced by "For various 
purposes, such as".

Section 4, line 8:
  We suggest expanding the sentence on N compressors and M 
decompressors: Replace "are arbitrary numbers." by " are arbitrary 
numbers, and N+M is the number of instances present at the IP interface."

Section 7, paragraph 2, line 2:
"(but normally limitted on per Channel basis)" could perhaps be replaced 
by "(but limitted)".
Reasons:
- it is always limited, not just normally
- we are anyway talking on a instance basis, and we have a one-to-one 
mapping to channels.

Section 7, figures:
The terms "HC" and "HD" used in the figures should be either changed or 
explained.

Section 7, line 5:
Remove "state" (or alternatively remove "stream" in line 4). A packet 
stream relates to a context, not to a particular context state, because 
the state may change between packets.

Section 8, item 5, line 2:
The sentences is hard to read. We suggest replacing "logical layer two 
channels available" by "available logical layer two channels".

Juergen and Martin

-- 
Martin Stiemerling

NEC Europe Ltd. -- Network Laboratories  [email-masked]
IPv4: http://www.ccrle.nec.de  IPv6: http://www.ipv6.ccrle.nec.de

---

From: Juergen Quittek <[email-masked]>
Date: Thu, 30 Jan 2003 00:41:26 +0100

Dear ROHCers,

A little bit after the deadline, I have two more comments on
draft-ietf-rohc-mib-rtp-05.txt:

General:
  The boilerplate for documents specifying MIB modules
  has changed recently. We should try to update the document
  accordingly. This will include changes in the introduction
  (Section 1), the MIB definition itself (Section 5), and
  the Referneces (Section 8).

Section 8:
  The RFC editor suggests having two individual top level
  sections for normative and informative references
  instead of having them as subsections in a top level
  section on references.
  I suggest to adapt to this scheme transforming
  "8.Referneces
   8.1 Normative Referneces
   8.2 Informative References"
  into
  "8 Normative Referneces
   9 Informative References"

        Juergen
-- 
Juergen Quittek        [email-masked]        Tel: +49 6221 90511-15
NEC Europe Ltd.,       Network Laboratories        Fax: +49 6221 90511-55
Kurfuersten-Anlage 36, 69115 Heidelberg, Germany   http://www.ccrle.nec.de