Re: Gen-ART Last Call review of draft-ietf-rserpool-asap-19.txt

[Michael Tüxen <[e-mail]>]

Hi Spencer,

see my comments in-line.

Best regards
Michael

On Apr 17, 2008, at 12:51 AM, Spencer Dawkins wrote:

> I have been selected as the General Area Review Team (Gen-ART)
> reviewer for this draft (for background on Gen-ART, please see
> http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html).
>
> Please resolve these comments along with any other Last Call comments
> you may receive.
>
> Document: draft-ietf-rserpool-asap-19
> Reviewer: Spencer Dawkins
> Review Date: 2008-04-16
> IETF LC End Date: 2008-04-14 (sorry!)
> IESG Telechat date:
>
> Summary: This document is close to ready for publication as an  
> Experimental RFC. I have some specific comments below, but nothing  
> that's a show-stopper.
>
> If this document were to advance onto the standards track, I'd  
> recommend a very tight editing pass on 2119 language, especially  
> looking for anything that seems to be capitalized for emphasis, and  
> I'd recommend clearer statements for why some of the SHOULDs aren't  
> MUSTs. I don't see any reason to hold up for this when publishing as  
> Experimental.
>
> Comments:
>
> 1.1.  Definitions
>
>  Home ENRP server:  The ENRP server to which a PE or PU currently
>     sends all namespace service requests.  A PE MUST only have one
>
> Spencer (clarity): I'm not wild about 2119 language in terminology  
> sections, but at the very least, this section comes before you  
> describe the 2119 conventions in Section 1.4...
>
>     home ENRP server at any given time and both the PE and its home
>     ENRP server MUST know and keep track of this relationship.  A PU
>     SHOULD select one of the available ENRP servers as its Home ENRP
>     server but the collective ENRP servers may change this by the
>     sending or a ASAP_ENDPOINT_KEEP_ALIVE message.
Agreed. I changed it from SHOULD or MUST to should or must.
>
>
> 1.2.  Organization of this document
>
>  Section 2 details the ASAP message formats.  In Section 3 we provide
>  detailed ASAP procedures for for the ASAP implementer.  In Section 6
>
> Spencer (clarity): interesting jump from Sec 3 to Sec 6... ;-)
>
>  we give details of the ASAP interface, focusing on the communication
>  primitives between ASAP the applications above ASAP and ASAP itself,
>  and the communications primitives between ASAP and SCTP (or other
>  transport layers).  Also included in this discussion are relevant
>  timers and configurable parameters as appropriate.  Section 7
>  provides threshold and protocol variables.
I added appropriate text for section 4 and 5 (which were added lately)
and also cleaned up the text for section 7.
>
>
> 2.2.  ASAP Messages
>
>  0x0d       - ASAP_BUSINESS_CARD
>
> Spencer (clarity): it would be nice to see "business card" called  
> out in the terminology section, at a minimum.
I added a description to the terminology section.
>
>
> 3.5.  Unreachable endpoints
>
>  Optionally, an ENRP server may also periodically send point-to-point
>  ASAP_ENDPOINT_KEEP_ALIVE (with 'H' flag set to '0') messages to each
>  of the PEs owned by the ENRP server in order to check their
>  reachability status.  If the send of ASAP_ENDPOINT_KEEP_ALIVE to a PE
>  fails, the ENRP server MUST consider the PE as unreachable and MUST
>  remove the PE from its handlespace .  Note, if an ENRP server owns a
>  large number of PEs, the implementation should pay attention not to
>  flood the network with bursts of ASAP_ENDPOINT_KEEP_ALIVE messages.
>  Instead, the implementation MUST distribute the
>  ASAP_ENDPOINT_KEEP_ALIVE message traffic over a time period.
>
> Spencer (comment): Is this a requirement for application-level  
> behavior beyond what TCP or SCTP would do at the transport level? If  
> so ... I'd expect more guidance here (if everyone knew how to "pay  
> attention not to flood the network with bursts of messages", we'd  
> all be using UDP).
SCTP or TCP do congestion control per association or connection. Here  
the messages
are sent on multiple associations.
I've added a note that the time between ASAP_ENDPOINT_KEEP_ALIVE  
messages should
randomly varied by plus/minus 50 percent. This should work (At least  
this is
the way we handle the same situation in SCTP).
>
>
> 3.7.1.  SCTP Send Failure
>
>  In such a case, the ASAP endpoint should not re-send the
>  undeliverable message.  Instead, it should discard the message and
>  start the ENRP server hunt procedure as described in Section 3.6 .
>
> Spencer (comment): I'm not sure why these "should"s are non- 
> normative, and I'm not sure why the first "should" is not MUST.
Changed to MUST and SHOULD.
>
>
>  After finding a new Home ENRP server, the ASAP endpoint should
>  reconstruct and retransmit the request.
>
>  Note that an ASAP endpoint MAY also choose to NOT discard the
>  message, but to queue it for retransmission after a new Home ENRP
>  server is found.  If an ASAP endpoint does choose to discard the
>  message, after a new Home ENRP server is found, the ASAP endpoint
>  MUST be capable of reconstructing the original request.
>
> Spencer (comment): this seems way deep into implementation, not into  
> protocol interoperation (whether I discard a message and reconstruct  
> it, or queue it for retransmission, would be up to the implementer,  
> or do I misunderstand?).
Correct.

I have replaced it by

In such a case, the ASAP endpoint MUST not re-send the undeliverable
message. Instead, it SHOULD discard the message and start the
ENRP server hunt procedure as described in <xref  
target="servhuntproc" /> .
After finding a new Home ENRP server, the ASAP endpoint should
re-send the request.

>
>
> 3.8.  Cookie handling procedures
>
>  Note: a control channel is a communication channel between a PU and
>  PE that does not end in data passed to the user.  This is
>
> Spencer (clarity): s/does not end in/does not carry/ ?
Done.
>
>
>  accomplished with SCTP by using a PPID to separate the ASAP messages
>  (Cookie and Business Card) from normal data messages.
>
> 6.5.2.1.  Round Robin Policy
>
>  When an ASAP endpoint sends messages by Pool Handle and Round-Robin
>  is the current policy of that Pool, the ASAP endpoint of the sender
>  will select the receiver for each outbound message by round-Robining
>  through all the registered PEs in that Pool, in an attempt to achieve
>  an even distribution of outbound messages.  Note that in a large
>  server pool, the ENRP server MAY not send back all PEs to the ASAP
>
> Spencer (comment): is this supposed to be a 2119 MAY? Or is it more  
> like "might not"?
Changed to might not
>
>
>  client.  In this case the client or PU will be performing a round
>  robin policy on a subset of the entire Pool.
>
> 6.5.5.  Message Delivery Options
>
>     Note that this is a best-effort service.  Applications should be
>     aware that messages can be lost during the failover process, even
>     if the underlying transport supports retrieval of unacknowledged
>     data (e.g.  SCTP) (Example: messages acknowledged by the SCTP
>     layer at a PE, but not yet read by the PE when a PE failure
>     occurs.)  In the case where the underlying transport does not
>     support such retrieval (e.g.  TCP), any data already submitted by
>     ASAP to the transport layer MAY be lost upon failover.
>
> Spencer: ... I'm positive this isn't a 2119 MAY ;-)
Correct.

Thank you very much for your comments!

I've submitted a new version of the ID addressing all your comments
as described above.
>
>
>

_______________________________________________
IETF mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/ietf