Tero Kivinen <kivi...@iki.fi> writes:
Don Fedyk writes:https://www.ietf.org/rfcdiff?url2=draft-ietf-ipsecme-yang-iptfs-03.txtWhile answering the shepherd writeup question "Briefly describe the review of this document that was perfmed by the Document Shepherd", I had to read this document too, so here are some of my comments to this document: ---------------------------------------------------------------------- leaf dont-fragment { type boolean; default "false"; description "Disable packet fragmentation across consecutive iptfs tunnel packets"; My understanding this only disables small packet fragmentation between two outer fragments, i.e., does not disable it when the inner packet is so big it does not fit on the outer packet?
It means what the description says, which is dont fragment. This option was added early on based on comments from Valery indicating that some simple implementations would not want to support reassembly.
If so adding text "Inner packets that does not fit to outer packets will always be fragmented regardless of this setting, but if dont-fragment is true those fragments do not include any other inner packets". Or if it is other way then add text saying "If this is true then inner packets that are larger than what can be tranmitted in outer packets will be dropped.".
"Disable packet fragmentation across consecutive iptfs tunnel packets; inner packets larger than what can be transmitted in outer packets will be dropped.";
---------------------------------------------------------------------- I would suggest adding text to some settings telling whether they affect transmission or receive. My understanding is that outer-packet-size, tunnel-rate, dont-fragment, and max-aggregation-time are for transmission end.
Yes.
window-size, send-immediately and lost-packet-timer-interval are for the receiver end.
Right.
Some of those do have the text that explains this clearly, but some of them do not. And then there are settings which affect both, i.e., I think congestion-control is such. Having clear text whether it affects transmission, reception or both in description would make things easier to understand.
Seems reasonable to me.
---------------------------------------------------------------------- Add comment to the lost-packet-timer-interval to say that "If not using send-immediately then each lost packet will be delayed until this expires", or something like that. It is important that adminstrators understand that this will affect delay visibile through the system.
OK.
---------------------------------------------------------------------- Add text to the security considerations section that as IPTFS tries to hide the traffic flows through the network, then of course to be able to read yang/mib statistics of the traffic flows is bad idea... I.e., even read only access to the IPTFS statistics can be used to find out traffic patterns.
Good point.
https://www.ietf.org/rfcdiff?url2=draft-ietf-ipsecme-mib-iptfs-01.txtSame changes than in Yang document is needed here too. Also remove the last sentence of the abstract, i.e. I do not think there is no need to say "This is an unpublished work in progress.", in internet drafts, as they are working documents anyways...
Thanks, Chris.
signature.asc
Description: PGP signature
_______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
