[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[rohc] RE: FW: I-D ACTION:draft-ertekin-rqts-hcoipsec-00.txt
Emre and others,
I agree with Kristofers comments, and he is completely correct when he
says I am not that fond of the use of 2119 keywords in requirements
documents, and the reason is very well exemplified by the point being
raised in this case. The 2119 keywords are defined to indicate to an
implementer what functionality to implement, but it is not at all clear
how to interpret such words in the context of a requirements document.
Some more comments from me:
* HC for SA transport mode
Re-using existing HC schemes sound like a good idea, but there is no
existing scheme that only compress transport layer headers. Further,
one could argue that the transport header overhead is too small to
justify compression of that alone. In any case, I believe compression
for the transport-SA case is not as easy to justify as for tunnel
mode, and would require much more work.
* 5. Goals and requirements
This is an essential part of the document, but I would prefer to
have a slightly different approach for it. The most important thing
here, in my mind, is to make clear what work is needed to have a
complete solution, considering what we already have. Some of these
would, in my mind, be work assumptions, while the rest of them are
"work items", as we are already into solution space, considering the
initial assumptions. We do not need strong words, we must understand
what work is needed.
- a. is actually an assumption that the HCoIPsec work is to be based
in existing HC protocols, with modifications/extensions.
- b. is stating the goal of the whole work, to develop a HC solution
for IPsec SA's. Also an initial assumption, or goal.
- c. talks about the HC protocol improvements needed to cope with
increased delays, loss, and reordering between compressor and
decompressor. This is specific work that must be done.
- d. is nothing new. As Kristofer noted, one can never guarantee
this without an infinite checksum, but existing HC schemes already
have this as a goal, ROHC has specifically addressed thus. I see
no reason to repeat that here.
- e. is obvious to me, although it is unclear exactly what one mean
with HC signalling. I do not think this is needed here, but if it
is kept, it must be explained what signalling this is about, more
specifically. Might be a requirement on the solution, but it would
be more useful with a discussion of the content of it.
- f. translates into two work items, which I would call defining:
1) Negotiation for HC scheme usage/support and HC scheme parameters
2) Encapsulation and identification
- g. means to me that a SA would constitute the HC point2point link,
i.e. the channel over which a corresponding compressor/decompressor
pair is operating, and the CID space would then obviously be local
to each SA. This is more of a work assumption than a requirement,
I think.
- h. is fine as a on the complete solution requirement!
>From this, I see 3 different work items:
# The improvements of existing HC schemes so that they can work over
this channel scenario, i.e. address c)
# Define negotiation mechanisms for HC over SA's
# Define encapsulation/identification of header compressed data over
SA's, i.e. within ESP or AH.
* Identification and encapsulation
Identification can be done either by negotiation (always on/always off)
and make use of e.g. ROHC "uncompressed", or by having new prot/nextHdr
identifier(s). Encapsulation would require type identifiers for all
schemes but ROHC (this should be made clear at various places in the
document), which is why more than one protocol number (otherwise one
useless octet will be added in the ROHC case, as ROHC handles its own
packet type identification).
Apart from this, I think the draft looks good!
Rgds,
/L-E
> -----Original Message-----
> From: Kristofer Sandlund [mailto:kristofer.sandlund at effnet.com]
> Sent: den 31 mars 2005 08:45
> Subject: Re: FW: I-D ACTION:draft-ertekin-rqts-hcoipsec-00.txt
>
>
> Hi Emre,
>
> Some comments from a quick read-through of the draft.
>
> Section 5:
> d. HCoIPsec MUST NOT allow incorrectly decompressed packets to be
> forwarded from the decompressor (i.e., decryptor)
> This actually implies that the HC scheme must have an
> inifintely long checksum, and it is not possible to actually
> fulfill this requirement. One alternative is to weaken the
> text to say "should try to avoid....", but maybe that's too
> weak. Instead, I would try to put this in comparison with
> "the same tunnel without HC" and say that it "..should not
> deliver a larger amount of incorrect headers than the same
> tunnel without HC" (using "must" instead of "should" would
> mean that there also has be a way to quantify this, and I
> don't think you want to go down that road).
>
> e. HCoIPsec MUST minimize the amount of header
> compression signaling between compressor and decompressor
> Do you mean feedback/header requests here or do you mean that
> one should not
> introduce any further signaling here? Clarify please. Also
> "MUST minimize", what
> does that mean? It does not really say how much signaling is
> reasonable. Again,
> weaken the text and say something like "...should attempt to
> minimize...". Point
> c) of the same section also has a similar wording that the
> same comment applies to.
>
> Editorial details:
> A minor thing that I'm sure that L-E will point out later is
> that some people (myself included) are not too fond of the
> use of "MUST", "MAY" etc in requirements drafts (I'd prefer
> just using "must" etc). But since a lot of people use the
> RFC2119 keywords in req-drafts, it is not an error, so you
> can keep it that way if you want to. And now I noticed that
> if you use them, you need to have a reference to 2119 :)
> Also, isn't it mandatory these days to split the references
> into normative and informative references?
>
>
> Other than those comments, the draft seems well-written and
> probably sufficient for its purpose.
>
> BR,
> Kristofer Sandlund, Effnet AB
_______________________________________________
Rohc mailing list
Rohc at ietf.org
https://www1.ietf.org/mailman/listinfo/rohc