[Re:] comment clause 5

Barry,

Below is my reply to your comments clause 5. Please let me know if you
have any questions.

Hemal

 

*	To: "RDDP" <[email protected]> 
*	Subject: [rddp] comment clause 5 of draft-ietf-rddp-ddp-01 
*	From: "Barry Reinhold" <[email protected]> 
*	Date: Mon, 17 Nov 2003 13:38:56 -0500 
*	Importance: Normal 
*	List-help: <mailto:[email protected]?subject=help> 
*	List-id: IETF Remote Direct Data Placement (rddp) WG
<rddp.ietf.org> 
*	List-post: <mailto:[email protected]> 
*	List-subscribe:
<https://www1.ietf.org/mailman/listinfo/rddp>,<mailto:rddp-request@ietf.
org?subject=subscribe> 
*	List-unsubscribe:
<https://www1.ietf.org/mailman/listinfo/rddp>,<mailto:rddp-request@ietf.
org?subject=unsubscribe> 
*	Sender: [email protected] 

  _____  

There are three comments on clause 5, (2 and 3) have technical content.
 
CLAUSE 5
 
NOTE: Given the effort associated with documenting the capitalization
issues and the frequency of capitalization issues these corrections are
no longer going to be documented. There may be some rule being applied
here that I am unaware of and if so this is a waste of time. 
 
It is suggested that the following terms have their capitalization
changed:
Message, Remote Peer, Local Peer, Untagged Buffer Model, Tagged Buffer
Model, Payload, Segment, Stream, Connection, Data Placement, Placement,
Delivery, Application.
 
[hvs] Change is not accepted. This is the convention being used in the
document.
 
1. Editorial, medium, 5 under item 4
 
Is:  4.  The LLP MUST preserve DDP Segment and Message boundaries at the
 
       Data Sink. 
Suggest:   4.  The LLP MUST preserve DDP Segment at the Data Sink.
 
Change: Removed reference to Message boundaries. Note that this is a
technical change if there is an actual requirement for the LLP to
understand DDP message boundaries. This change request is made as an
editorial request, believing that there is no requirement for the LLP to
understand message boundaries.
[hvs] Change is not accepted. This is an actual requirement.
 
2. Technical, medium, 5 under item 8 and 10
 
Issue: The concept of an erroneous LLP stream is not defined or
referenced in this specification. It occurs in item 8 and 10 of this
clause. The semantics associated with marking a stream as an erroneous
stream needs further definition.
 
Is: 
If an LLP does not support teardown of a LLP stream independent 
       of other LLP streams and a DDP error occurs on a specific DDP 
       Stream, then the LLP MUST label the associated LLP stream as an 
       erroneous LLP stream and MUST NOT allow any further data 
       transfer on that LLP stream after DDP requests the associated 
       DDP Stream to be torn down. 
 
Suggest:
 
Add a definition for erroneous LLP stream in clause 4.2
 
"LLP Erroneous Stream - The LLP layer may mark a stream as being
erroneous to indicate to the DDP layer that the stream may no longer be
used for transmission of DDP segments."
 
[hvs] Change is not accepted. The text clearly says what LLP must do
when the stream is marked errorneous. 
 
Change item 8 to the following:
 
If an LLP does not support teardown of a LLP stream independent 
of other LLP streams and DDP request that the LLP stream be shutdown,
then LLP shall mark the stream as being an erroneous LLP stream. LLP
MUST NOT allow any further data transmission on a LLP stream marked as
erroneous.
[hvs] Change is not accepted.
 
No change is necessary to item 10
 
Suggestion 2:
 
Remove both references to erroneous streams. It is unclear to me that
DDP needs to understand the concept of an erroneous stream. When DDP
requests to tear down the stream due to a DDP error and the LLP must
defer from de-allocating the resources associated with the stream the
LLP should hide the "erroneous stream" state. In this case item 8
becomes:
 
If an LLP does not support teardown of a LLP stream independent of other
LLP streams it must present the LLP stream to DDP as being terminated.
The LLP entity MUST NOT allow any further data transfer on the LLP
stream. The LLP entity is not obligated to free up resources associated
with the LLP stream at the time of the teardown request.
 
Item 10 becomes:
 
   10. For a specific LLP connection, when all LLP streams are
gracefully           torn down the LLP connection MUST be torn down. 
[hvs] Change is not accepted. Errorneous LLP streams do have a meaning
for DDP.
 
3 Editorial, Low, 5 under clause 9
 
Is:
 
   9.  For a specific LLP Stream, the LLP MUST provide a mechanism to 
       indicate that the LLP Stream has been gracefully torn down. For 
       a specific LLP Connection, the LLP MUST provide a mechanism to 
       indicate that the LLP Connection has been gracefully torn down. 
       Note that if the LLP does not allow an LLP Stream to be torn 
       down independently of the LLP Connection, the above requirements 
       allow the LLP to notify DDP of both events at the same time. 
Suggest:
   9.  For a specific LLP stream, the LLP MUST provide a mechanism to 
       indicate that the LLP stream has been gracefully torn down.
       Note that if the LLP does not allow an LLP stream to be torn 
       down independently of the LLP connection, the above requirements 
       allow the LLP to notify DDP of both events at the same time.
 
Changes: Removed duplicated sentence and changed capitalization.
[hvs] Change is accepted.
3 Editorial/technical, Low 5 under clause 11
 
Is:
The LLP MUST NOT pass a duplicate DDP Segment to the DDP Layer 
       after it has passed all the previous DDP Segments to the DDP 
       Layer and the associated ordering information for the previous 
       DDP Segments and the current DDP Segment. 
Suggest:
The LLP MUST NOT pass a duplicate DDP segment to the DDP layer.
 
Change: Removed qualifications. Do not understand the need for the
qualification. 
[hvs] Change is not accepted. The qualification says that LLP must not
pass a duplicate DDP segment if it falls into an ordered and already
delivered stream.
 
Barry Reinhold
Lamprey Networks
[email protected]
(603) 868-8411