WatchCat Standard sample

# RFC 
RFC 5649 Advanced Encryption Standard (AES) Key Wrap with Padding Algorithm 

https://www.rfc-editor.org/rfc/rfc5649

RFC 3539   Authentication, Authorization and Accounting (AAA) Transport Profile

https://www.rfc-editor.org/rfc/rfc3539

rfc6733 Diameter Base Protocol

https://www.rfc-editor.org/rfc/rfc6733.html

>5.5.  Transport Failure Detection
   Given the nature of the Diameter protocol, it is recommended that
   transport failures be detected as soon as possible.  Detecting such
   failures will minimize the occurrence of messages sent to unavailable
   agents, resulting in unnecessary delays, and will provide better
   failover performance.  The Device-Watchdog-Request and Device-
   Watchdog-Answer messages, defined in this section, are used to pro-
   actively detect transport failures.
5.5.1.  Device-Watchdog-Request
   The Device-Watchdog-Request (DWR), indicated by the Command Code set
   to 280 and the Command Flags' 'R' bit set, is sent to a peer when no
   traffic has been exchanged between two peers (see Section 5.5.3).
   Upon detection of a transport failure, this message MUST NOT be sent
   to an alternate peer.
      Message Format
         <DWR>  ::= < Diameter Header: 280, REQ >
                    { Origin-Host }
                    { Origin-Realm }
                    [ Origin-State-Id ]
                  * [ AVP ]
5.5.2.  Device-Watchdog-Answer
   The Device-Watchdog-Answer (DWA), indicated by the Command Code set
   to 280 and the Command Flags' 'R' bit cleared, is sent as a response
   to the Device-Watchdog-Request message.
      Message Format
         <DWA>  ::= < Diameter Header: 280 >
                    { Result-Code }
                    { Origin-Host }
                    { Origin-Realm }
                    [ Error-Message ]
                    [ Failed-AVP ]
                    [ Origin-State-Id ]
                  * [ AVP ]



 RFC7360  Datagram Transport Layer Security (DTLS)  as a Transport Layer for RADIUS

https://www.rfc-editor.org/rfc/rfc7360.html

p.14 
> Once a DTLS session is established, a RADIUS/DTLS server SHOULD use
   DTLS Heartbeats [RFC6520] to determine connectivity between the two
   servers.  A server SHOULD also use watchdog packets from the client
   to determine that the session is still active.
   As UDP does not guarantee delivery of messages, RADIUS/DTLS servers
   that do not implement an application-layer watchdog MUST also
   maintain a "Last Traffic" timestamp per DTLS session.  The
   granularity of this timestamp is not critical and could be limited to
   one-second intervals.  The timestamp SHOULD be updated on reception
   of a valid RADIUS/DTLS packet, or a DTLS Heartbeat, but no more than
   once per interval.  The timestamp MUST NOT be updated in other
   situations.
   When a session has not received a packet for a period of time, it is
   labeled "idle".  The server SHOULD delete idle DTLS sessions after an
   "idle timeout".  The server MAY cache the TLS session parameters, in
   order to provide for fast session resumption.
   This session "idle timeout" SHOULD be exposed to the administrator as
   a configurable setting.  It SHOULD NOT be set to less than 60 seconds
   and SHOULD NOT be set to more than 600 seconds (10 minutes).  The
   minimum useful value for this timer is determined by the application-
   layer watchdog mechanism defined in the following section.

p.15

>5.2.  Client Session Management
   Clients SHOULD use PMTU discovery [RFC6520] to determine the PMTU
   between the client and server, prior to sending any RADIUS traffic.
   Once a DTLS session is established, a RADIUS/DTLS client SHOULD use
   DTLS Heartbeats [RFC6520] to determine connectivity between the two
   systems.  RADIUS/DTLS clients SHOULD also use the application-layer
   watchdog algorithm defined in [RFC3539] to determine server
   responsiveness.  The Status-Server packet defined in [RFC5997] SHOULD
   be used as the "watchdog packet" in any application-layer watchdog
   algorithm.
   RADIUS/DTLS clients SHOULD proactively close sessions when they have
   been idle for a period of time.  Clients SHOULD close a session when
   the DTLS Heartbeat algorithm indicates that the session is no longer
   active.  Clients SHOULD close a session when no traffic other than
   watchdog packets and (possibly) watchdog responses has been sent for
   three watchdog timeouts.  This behavior ensures that clients do not
   waste resources on the server by causing it to track idle sessions.
  A session MUST be deleted when non-RADIUS traffic is received over
   it.  This specification is for RADIUS, and there is no reason to
   allow non-RADIUS traffic over a RADIUS/DTLS session.  A session MUST
   be deleted when RADIUS traffic fails to pass security checks.  There
   is no reason to permit insecure networks.  A session SHOULD NOT be
   deleted when a well-formed, but "unexpected", RADIUS packet is
   received over it.  Future specifications may extend RADIUS/DTLS, and
   we do not want to forbid those specifications.
   The goal of the above requirements is to ensure security, while
   maintaining flexibility.  Any security-related issue causes the
   connection to be closed.  After the security restrictions have been
   applied, any unexpected traffic may be safely ignored, as it cannot
   cause a security issue.  There is no need to close the session for
   unexpected but valid traffic, and the session can safely remain open.
   Once a DTLS session is established, a RADIUS/DTLS server SHOULD use
   DTLS Heartbeats [RFC6520] to determine connectivity between the two
   servers.  A server SHOULD also use watchdog packets from the client
   to determine that the session is still active.
   As UDP does not guarantee delivery of messages, RADIUS/DTLS servers
   that do not implement an application-layer watchdog MUST also
   maintain a "Last Traffic" timestamp per DTLS session.  The
   granularity of this timestamp is not critical and could be limited to
   one-second intervals.  The timestamp SHOULD be updated on reception
   of a valid RADIUS/DTLS packet, or a DTLS Heartbeat, but no more than
   once per interval.  The timestamp MUST NOT be updated in other
   situations.
   When a session has not received a packet for a period of time, it is
   labeled "idle".  The server SHOULD delete idle DTLS sessions after an
   "idle timeout".  The server MAY cache the TLS session parameters, in
   order to provide for fast session resumption.
   This session "idle timeout" SHOULD be exposed to the administrator as
   a configurable setting.  It SHOULD NOT be set to less than 60 seconds
   and SHOULD NOT be set to more than 600 seconds (10 minutes).  The
   minimum useful value for this timer is determined by the application-
   layer watchdog mechanism defined in the following section.



[RFC] watchdog: Adding softwatchdog

https://patchwork.kernel.org/project/linux-watchdog/patch/20210424102555.28203-2-peter.enderborg@sony.com/#24137949

[RFC,V2,21/21] Documentation/rv: Add watchdog-monitor documentation

https://patchwork.kernel.org/project/linux-trace-devel/patch/347942775f8c2b6badd9796d1fd75f574dd0ce95.1644830251.git.bristot@kernel.org/

[RFC v2 0/2] Add driver for PAPR watchdog timers

https://www.spinics.net/lists/linux-watchdog/msg22606.html

[RFC,19/23] watchdog/hardlockup: Make arch_touch_nmi_watchdog() to hpet-based implementation

https://patchwork.ozlabs.org/project/linuxppc-dev/patch/1528851463-21140-20-git-send-email-ricardo.neri-calderon@linux.intel.com/

RFC: API Change: watchdog: wdt_feed error codes #26708

https://github.com/zephyrproject-rtos/zephyr/issues/26708

PATCH RFC] Watchdog: Load module for only active watchdog in kdump kernel

https://lists.fedoraproject.org/archives/list/kexec@lists.fedoraproject.org/thread/SJX5242ILATREDCZ5KRQLLGQWGHM47WA/



# Watchcat
Watchcat is not a standard now.

Watchcat is hardware only.
There are no software watchcat.

I am planning wtchcat standard as RFC(request for comment) 

## sample documentation

 watchcat as monitor with pwer saving.


Abstract
   internet inactivation has become a major concern over the past few years.
   Users are becoming more aware that their online activity can be ussed or
   not to used.  The communication can be easily begun, but can not maintain 
   connection. One of usefull function are watchdog, and watch cat is more
　 power saving. 

   There have been several watchdog timers. This is watchcat, not watchdog. 
   This document provides an overview of this actity , with the intention
   to inform the technical community about this, and help coordinate between 
   present and futures  standardization activities.

Status of This Memo

 Nothing.