[IPsec] IP-TFS YANG and MIB Updated

[Tero Kivinen <[e-mail]>]

Don Fedyk writes:
> https://www.ietf.org/rfcdiff?url2=draft-ietf-ipsecme-yang-iptfs-03.txt

While 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?

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.".

----------------------------------------------------------------------

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.

window-size, send-immediately and lost-packet-timer-interval are for
the receiver end.

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.

----------------------------------------------------------------------

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.

----------------------------------------------------------------------

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.

> https://www.ietf.org/rfcdiff?url2=draft-ietf-ipsecme-mib-iptfs-01.txt

Same 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... 
-- 
[e-mail]