Subject: [Rserpool] Comments on ASAP internet draft

From: [email-masked]
Date: Thu, 14 Jun 2001 10:32:42 -0500

a) 4.5.1 Sending to a Pool

C)if no association exists towards the destination, establish a new SCTP
association, NOTE: if the underlying SCTP implementation supports implicit
association setup, this step is not needed (see [RFC2960]). 
D) send out the queued message to the SCTP association using the SEND
primitive (see [RFC2960]), and, ....

*** Text everywhere assumes that SCTP is the transport.

b) 4.5.5 Options

ASAP_SEND_FAILOVER: 0x0001 Enables PE fail-over on this message. In case
where the first selected PE or the PE pointed to by the handle is found
unreachable, this option allows the sender's ASAP layer to re-select an
alternate PE from the same Pool if one exists, and silently re-send the
message to this newly selected endpoint. Endpoint unreachable is normally
indicated by the Communication Lost or Send Failure notification from SCTP. 

*** Does this mean you have exactly one extra chance to resend the message?
Can it be tried again?

Nits:

1) 3.1 PE Parameter Definition

*** "represent a PEP" should be PE.

2) 4.3 Cache.Populate.Request Primitive 
Format: cache.populate.request(destinationAddress, typeOfAddress)

*** destinationAddress and typeOfAddress are not defined unless I missed it
somewhere.  How many types are there and what are they?

3) 4.3 Cache.Populate.Request Primitive 

If the address type is a Pool handle (or name) and a local name translation
cache exists, the ASAP layer should initiate a mapping information query on
the Pool handle and update it local cache when the response comes back from
the ENRP server.

*** I was confused the first time I read this.  I think you need to break
this into two sentences for clarification.  What is a mapping information
query?  Is this the same as sending the Name Resolution message to the ENRP
server?  I'm not sure why this term "mapping information query" is
introduced (see nit #5).  

4) section 4.5.1

This is the simplest form of data.request primitive. By default, this
directs ASAP to send the message to one of the pool elements in the server
pool.

*** This should say ,,, simplest form of data.send primitive...

5)4.5.1 Sending to a Pool

If the sender's ASAP implementation does not support a local cache of the
translation information or if it does not have the translation information
on that Pool in its local cache, it will transmit a request for the name
mapping information to the ENRP server, and MUST hold the outbound message
in queue while awaiting the response from the ENRP server (any further send
request to this Pool before the ENRP server responds SHOULD also be queued).

*** Now it is called "name mapping information".  We should just pick two
terms and use them consistently.  I know this is very picky.
I found in the document:
name resolution
translation information
mapping information query
name mapping information
mapping information, etc.

6) 4.5.3 Sending to a Pool Element Handle
If local cache is supported and the mapping information for the Pool found
in the pool element handle is not available in the local cache, the sender's
ASAP layer SHOULD, after sending the message, also transmit a request for
the Pool handle mapping information to the ENRP server. Once the necessary
mapping information arrives from the ENRP server, the sender's ASAP will
update its local cache with the newly received mapping information for that
Pool handle.

*** I'm having trouble with this very long sentence.  ".... after sending
the message, ...."  I got lost here.  Oh, I see.

a) if caching is supported, determine if there is any info on the pool
handle in the cache
b) if not,
     i) send out the message to the endpoint designated by the pool element
handle.
     ii) ask ENRP for name resolution on pool handle
     iii) use the response to update the local cache.  

Right???  What is done if there is information in the cache?  This paragraph
is confusing.

7) 4.5.5 Options 
The Options parameter passed in the various forms of the above data.request
primitive gives directions to the sender's ASAP layer on special handling of
the message delivery. 

*** data.request should be data.send

-- maureen

Maureen Stillman
Nokia
Member of Scientific Staff             Voice: (607)273-0724 x62
Internet Commerce Enhancement  Fax: (607)275-3610
127 W. State Street                     Mobile: (607)227-2933
Ithaca, NY 14850
e-mail: [email-masked]
www.nokia.com

_______________________________________________
rserpool mailing list
[email-masked]
http://www.ietf.org/mailman/listinfo/rserpool

---

From: Randall Stewart <[email-masked]>
Date: Tue, 26 Jun 2001 13:05:40 -0500

Maureen:

Comments inter-spersed below...

Sorry for the delayed response but I have been quite busy :)

> *** Text everywhere assumes that SCTP is the transport.

Yes, this is true. I don't know if I have changed that
assumption either :)

In general for this first cut Qiaobing and I pledged to
make  No signifigant technical changes. We wanted to
align the wording more to the requirements on pools etc
without changing anything technical. Now

1) Changing to generic transport is in my mind more
   than just a wording change.

and

2) I don't think I am yet convinced I want to add tcp :)

> *** Does this mean you have exactly one extra chance to resend the message?

What this means is that it will keep failing over silently. The next
time if fails it recurses back through this wording again. Now may 
need to be clearer here... since I can see that it is not explicit
in saying it recurses ... 

I will fix your nits pretty much verbatim..

Thanks for the close read...

> somewhere.  How many types are there and what are they?

I will add something like this..

"
    The destinationAddress field contains the address for which the
    cache needs to be populated. The typeOfAddress indicates the address
    type. Allowable types are Pool handle and Pool element handle.  In
    the case of a Pool element handle, the Pool handle is extracted from
    the Pool element handle and sent used to form a NAME.RESOLUTION
    message (see Section 3.5).
  
"

that should help :) (it may need some word smithing)

> server?  I'm not sure why this term "mapping information query" is

Yes it should be NAME.RESOLUTION mesage.

How about:

"
    If the address type is a Pool handle (or name) and a local name
    translation cache exists, the ASAP layer should initiate a mapping
    information query by sending a NAME.RESOLUTION message on the Pool
    handle and update it local cache when the response comes back from
    the ENRP server.
"
> *** This should say ,,, simplest form of data.send primitive...

What is ",,," I don't get it :/

> *** Now it is called "name mapping information".  We should just pick two

Hows this?
 
"
    If the sender's ASAP implementation does not support a local cache
    of the translation information or if it does not have the
    translation information on that Pool in its local cache, it will
    transmit a request NAME.RESOLUTION message to the ENRP server, and
    MUST hold the outbound message in queue while awaiting the response
    from the ENRP server (any further send request to this Pool before
    the ENRP server responds SHOULD also be queued).

"

> mapping information, etc.

I will try to go through and find these and make them
either refer to the same thing :0

We tried.. not perfect but we will get there :0

> Right???  What is done if there is information in the cache?  This paragraph

Yes, it is AWFUL... I will break it has you say only I will
add a c) if it is in the cache... Here I will also add a
stale.cache parameter .. which may need further work :/
"
    If a translation cache is supported the endpoint will:

    a) Determine if the pool handle is in the cache.

    b) if it is NOT, the endpoint will:
       i) send out the message to the endpoint designated by the pool 
          element handle.
       ii) ask ENRP for name resolution on pool handle by sending
           a NAME.RESOLUTION message, and
       iii) use the response to update the local cache.

    c) if the pool handle is in the cache the endpoint will
       send out the message and only update the cache if
       the cache is stale. A stale cache is indicated by
       it being older than the protocol parameter 
       'stale.cache.value'.

"

> *** data.request should be data.send

ok

R

-- 
Randall R. Stewart
[email-masked] 815-342-5222 (cell phone)