Thanks for your comments.
Please see responses in line,
Eddie Kohler wrote:
The document's basic outline seems fine. Using a new packet type for
this purpose seems fine. The document is not ready to publish yet,
because of a high typo load and lack of specificity in how packets are
processed (i.e. no explicit pseudocode changes). These problems can
probably be addressed soon. My opinion should have little weight as I
am no longer an active member of the WG
Noted, and will make sure this is brought up at the WG.
Comments and suggestions.
- 2.2.1: Do not refer to the "Allow Short Seqno" feature, simply say
that X must equal 1.
Done.
- "both Sequence Number fields" => There is only one Sequence Number field.
Changed test.
- "option values" probably was intended to be "feature values."
Done.
- It is not reasonable to restrict Listen packets to carry no options.
A use may be found for Listen options one day. It suffices to say that
Listen packets are currently ignored. This includes any options on
Listen packets.
My understanding was that the suggested outcome of the last IETF was
that Options were allowed - but were not defined. This allowed some
subsequent evolution of the method if this were to be needed and text
was suggested to this effect (I think by Colin). If you think the text
says different, please do let us know.
- "MUST NOT carry payload data" => No other DCCP packet has this
restriction. Simply say, as for the other packet types, that payload
data is ignored.
This was discussed at the last two IETF meetings, and the thinking at
the time was since the packet contained no sequence number (because the
protocol machine has not yet reached this stage), it could not be used
to carry data.
- 2.2.1 "Data Offset is zero" => Wrong!! Data Offset is the header
length. 0 does not mean no payload, it means no header. This should be
5 (20 bytes). But as mentioned above this is not a reasonable
restriction either. Data Offset must be >= 5, allowing packets to
contain options.
Correct, thanks for spotting this, my editorial mistake.
- 2.2.1 "CsCov MUST be zero" => Unreasonable restriction.
Implied by data restriction above.
- 2.2.2 should state that, except for the generation of DCCP-Listen
packets, the INVITED state is treated exactly like the LISTEN state in
the pseudocode.
>
Done.
It should probably include new pseudocode, additions
and modifications to RFC4340 Section 8.5, handling INVITED state and the
receipt of Listen packets.
Need to think.
- 2.2.3 "ection 8"?
Done.
- Re: Magnus's suggestion on triggered Request packets, this should at
most be MAY behavior, and should be specified with explicit changes to
the pseudocode in RFC4340 Section 8.5.
I agree - I see this as a MAY also - this needs to be discussed at the
meeting this week.
- Typos throughout.
Eddie
Best wishes,
Gorry
