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 IETF@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf