I have reviewed this document as part of the Operational directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written with the intent of improving the operational aspects of the IETF drafts. Comments that are not addressed in last call may be included in AD reviews during the IESG review. Document editors and WG chairs should treat these comments just like any other last call comments. Document: draft-ietf-manet-credit-window-07 Status: Ready with issues The document is overall well written. My main concern is item b) below, i.e., I am missing a discussion of the more global effect of throttling traffic between the router and the modem. Is the router supposed to do something special or is the whole idea that dropping packets by the router is fundamentally better than dropping packets by the modem (which may technically be a router as well if some form of IP is used over the wireless link as well). a) Please spell out DLEP in the title and the abstract. b) The scenario seems to be as follows Ethernet Wireless -- router ------------ modem ------------ receiver The proposal aims to regulate traffic between the router and the modem so that the router does not overload the model, which may have problems forwarding traffic to the wireless receiver. Assuming that the router is not the source of the traffic, what happens at the other side of the router? Are you not just pushing the problem one step further, away from the model to the router? c) Section 9.2 discusses that knowledge about credits may get inconsistent. Mismatches may also include situations where packets are lost or dropped (e.g. checksum failures) - should this be mentioned as well? d) In the security considerations, I read 'The extension does not introduce any additional threats above those documented in [DLEP].' I wonder whether this is correct. Unless I have a secure transport for DLEP, can I not rather easily inject false window sizes to say prevent communciation or to let a router overflow a modem? e) IANA considerations: Perhaps add clear instructions to the RFC editor that TBD[1-6] in the text need to be updated once IANA has made assignments. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103