Just two responses here, the rest of the comments I see you either
agreed with or spawned to a different thread.
Alper Yegin wrote:
When you state something is "optional" please be clear if it is optional
to implement, or optional for the operator to utilize. Things that are
optional to implement should be absolutely minimized - particularly for
messages that may be received unsolicited (e.g., an implementor in a
particular environment may choose to not allow the user/operator to send
a PANA-ping message, but that same implementation should always be able
to respond correctly to one).
The text said "usage is optional." We can reword as "PANA-Ping and
PANA-Termination messages are optional to use." I don't think we have any
"optional to implement" features.
Great, I certainly got the impression that some of these were "optional
to implement" -- the language I see here, along with some of the
"optimizations" defined, certainly implied that to me. Please, in your
next rev of the document, be clear that there are no "optional to
implement" items here - particularly when it comes to the various ways
the state machine may operate.
Forever is a very long time, so perhaps the default should be something
other than this?
We are borrowing this scheme from DHCPv6. I think this "try indefinitely
(unless stated otherwise)" is a common behavior when it comes to connecting
to networks. Events external to the protocol can always terminate the
action.
That's fine, the default MRT is reasonable enough to avoid orphaned
clients filling up the network with too much overhead.
_______________________________________________
Pana mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/pana
