Subject: [Rserpool] ASAP Nits (Minor comments and questions)

From: Karl Knutson <[email-masked]>
Date: Tue, 17 Jul 2001 16:43:28 -0500 (CDT)

Some minor comments and/or questions on draft-ietf-rserpool-asap-00.txt.

1.1

*** The definition of Home ENRP Server mentions "Pool Element" but not
*** "Pool User".  Doesn't a Pool User have an ENRP home server?

1.1 

*** Caretaker ENRP Server is defined but not used. (It seems to be
*** used in ENRP.)

1.1 

*** "PU channel" is the same as the "ENRP client channel" in ENRP,
*** but for PU's where the ENRP client channel is for PE's.

*** I suggest that "ENRP client channel" be used for both PU's and PE's in
*** both ASAP and ENRP.  This would also change the definition of the ENRP
*** name domain.

1.1

*** There should be a definition of "transport address", since it's
*** mentioned in both the PU channel (or ENRP client channel) and the
*** ENRP server channel definitions.

3.3

"The endpoint sending the DEREGISTRATION..."  

*** Either endpoint should be defined and/or it should be replaced by PE or PU
*** where appropriate.  See also 5.2 (Timeout-server-hunt), and
*** others.  The use of "ENRP endpoint message identifier" in section 3 implies
*** that endpoint ought to be defined, or at least "ENRP endpoint".

4

"An ASAP User (PU or PE)..." 

*** Shouldn't this be in section 1.1, as in:

*** ASAP User
***     Either a PE or PU.

*** Also, "ASAP-user" is used below, shouldn't this be "ASAP User"?

4.1

*** Currently, the Registration.Request takes an endpointName.  Shouldn't
*** this be a poolName?  If not, where does the endpointName go in the
*** REGISTRATION message?

4.1 

"...the ASAP layer shall start the Server Hunt procedure..."

*** There is no description of the Server Hunt procedure in the ASAP
*** draft.   The description in the ENRP draft (from section 4.2.3)
*** should be copied over, probably as a subsection of 4.10.

4.2

*** If the Registration.Request actually takes a poolName, shouldn't the
*** Deregistration.Request also take a poolName?  This would facilitate a
*** PE's membership in multiple pools.

4.5.2.1

"...large server pool, the ENRP daemon may NOT send ..."

*** This should be server, not daemon.

4.5.5 (ASAP_SEND_FAILOVER)

    Endpoint unreachable is normally indicated by the Communication Lost
    or Send Failure notification from SCTP.

*** This should be:

*** Endpoint unreachable is normally indicated by the SCTP COMMUNICATION.LOST
*** or SCTP SEND.FAILURE notifications.

4.5.5 (ASAP_SEND_NO_FAILOVER)

...
with an Error.Indication and any unsent data.

*** This should be:

*** ...
*** with an Error.Report and any unsent data.

4.8.5 (SCTP SEND.FAILURE notification)

*** The text here is somewhat inconsistent with ENRP Section 4.2.1 2),
*** which says:

    "Whenever a PE finds a peer PE unreachable (e.g., via an SCTP
     SEND.FAILURE Notification, see section 10.2 of [RFC2960]), the
     former shall send an ENDPOINT_UNREACHABLE message over the ENRP
     client channel to its home ENRP server. The message shall contain
     one of the transport addresses of the unreachable peer PE and have
     the 'Severity' flag set to NORMAL_REPORT in the message."

*** A solution would be to copy the second paragraph from 4.8.6 into 4.8.5:

    "When handling this notification ASAP shall report this event to its
     ENRP server via an ENDPOINT_UNREACHABLE message with the severity
     level set to NORMAL_REPORT (see ?)."

5.2

*** The Timeout-server-hunt threshold mentions an "endpoint", which
*** should probably be changed to PE, since we are waiting here for a
*** REGISTRATION_RESPONSE.

Karl
--
[email-masked]
[email-masked]
[email-masked]

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

---

From: Randall Stewart <[email-masked]>
Date: Fri, 20 Jul 2001 07:38:44 -0500

Karl:

I think ASAP is on draft -01 not -00...

However, I will dig through and see if your "nits" and comments are
still applicable... they will be unless they intersected with
Maureens comments... since -01 fixed (or attempted to fix) Maureens
earlier comments on to the list..

R

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

---

From: Randall Stewart <[email-masked]>
Date: Mon, 23 Jul 2001 11:52:27 -0500

Karl:

Don't give up on me :-), after a 2 week vacation and 1 week at
networks I am finally digging out... I think I will get to
all of your comments tommorrow. 

I will start with taking care of all of your nit's you sent
me off-line.. then I will move to all your questions and
possible changes from all the ambiguity that I am sure is
in the document...

I will also be getting together a prioritized list of items
we (the working group) have agreed we need to do to ASAP/ENRP.. 
and then of course I will get that posted and start working
on each one... until we can get it all hammered out :-) Now
the real fun begins (I think :>)

For today though... sigh.. back to my backlog :-0

R

---

From: Randall Stewart <[email-masked]>
Date: Tue, 24 Jul 2001 07:43:31 -0500

Karl:

First, my apologies... I had THOUGHT I had sent off the -01
draft of asap to the drafts editor... sigh.. I dropped the ball..

The good news is your nits and comments will go in to the -01
draft once I can submit it again after the upcoming IETF ...

Now your nits (sent in private email) I will just fix... And as
to if you should put them to the list or in private it does not
matter... anything technical should probably be put on the list
but nits/mispellings or silly ommissions... all of which I am
sure I have a lot of.. can be sent, I think, either way :) I know
I appreciate the comments... as I think most authors do..

> *** "Pool User".  Doesn't a Pool User have an ENRP home server?

Well, no a PU may or may not be registered. I think we were attempting
to say that a PU does not necessarily have a home ENRP server since it
may not be part of any pool...  It can in effect use any of the
ENRP servers i.e. it could in theory load balance amongst
different ones if it so desired...

> *** Caretaker ENRP Server is defined but not used. (It seems to be
Yeah, this belongs in the ENRP document only, it is probably a
cleanup item I missed :) I see ENRP server takeover is also
a similar term that needs to be removed...

> *** both ASAP and ENRP.  This would also change the definition of the ENRP

Ok sounds fine..

> *** ENRP server channel definitions.

Ok, I think I can safely clone this out of RFC2960 :-)

> "The endpoint sending the DEREGISTRATION..."
I will change this to "The PE sending the DEREGISTRATION"

> *** that endpoint ought to be defined, or at least "ENRP endpoint".
Hmm...  we do have to have some term to identify the sender
of a message... i.e. PE or endpoint etc..

As far as the ENRP endpoint message identifier... lets wait until
the message structure re-format is complete.. I think these two
fields will either disappear or morph..

> *** Also, "ASAP-user" is used below, shouldn't this be "ASAP User"?
ok
> *** REGISTRATION message?
Yes, it is one of the things I must have missed (amongst many) in the
cleanup :-0

> *** should be copied over, probably as a subsection of 4.10.
ok, I do think we will be cleaning this up a bit too.. The orignial
ASAP/ENRP only used multicast.. but we will (as previously discussed)
be adding DNS and configured lists as well.

> *** PE's membership in multiple pools.
Hmm.. good point...

> *** This should be server, not daemon.

good catch.

> *** or SCTP SEND.FAILURE notifications.

Yeah, SCTP I think originally (way way back when the MDTP and DDP
drafts were first put together) different names for the failure
notifications.
Good catch...

> *** with an Error.Report and any unsent data.

ok

>      level set to NORMAL_REPORT (see ?)."

good catch... I will add a 

C) In either case, ....text above...

> *** REGISTRATION_RESPONSE.

Ok..

R