Subject: RE: [rohc] Feedback on draft-ietf-rohc-hcoipsec-04

From: "Ertekin, Emre" <[email-masked]>
Date: Fri, 1 Jun 2007 11:30:36 -0400

Lars-Erik,

Thanks for taking the time to review our drafts!  I agree with all of
your comments.  We incorporated the changes that you proposed, and have
decided to modify all three of our drafts (e.g., Framework, IKEv2
Extensions, and IPsec extensions) to be RoHC specific.

I resubmitted all three of the drafts; they should be available shortly.

Best Regards,
Emre
 
> *  References: This document is intended to be informational, and I
>     would like to hear how one can argue for normative references
>     in an informative document.
> 
> * The document should either:
>   - be reformulated to focus on ROHC only, including document title
>       or
>   - take a slightly different perspective as more of a general problem
>     statement, as the solution envisioned is built on ROHC.
>   As it is now, the document gives the impression the solution
>   envisioned will in itself be realized for all HC schemes, which is
>   not the case.
> 
> * 6.1.1, replace "must be extended" with "may have to be extended"
> 
> * Reference to ROHC-over-reordering does not give a proper view
>    of the scope of that document, which is mainly a problem analysis.
>    The reference name should also properly match the title, "EXT" is
>    not a good chioce.
> 
> * ROHCv2 should be referenced as the only really proper HC scheme
>    for HCoIPsec.
> 
> * 6.1.2, the goal is not to remove HC lower layer dependency, but
>    to facilitate the traditional LL functions by other  means for this
>    scenario .
> 
> * When discussing the Protocol/Next Header approach, the
>    document talks about this as "a value" and gives the impression
>    this will provide a solution for all HC schemes, while it actually
>    will be a ROHC identifier. Just try to adjust to not give an
>    improper impression. Further, if you see this document as more
>    of a general problem statement (see second bullet above), it
>    should be made clear that the Protocol value solution is just one
>    "potential" solution. Consequences and restrictions with using
>    the protocol field could also be useful to have.
> 
> That was it, overall the document looks fine!!
> /L-E

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