1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
|
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE chapter SYSTEM "chapter.dtd" [
<!ENTITY % also SYSTEM "seealso.ent" >
%also;
]>
<chapter xmlns:xi="http://www.w3.org/2001/XInclude">
<header>
<copyright>
<year>2011</year>
<year>2016</year>
<holder>Ericsson AB. All Rights Reserved.</holder>
</copyright>
<legalnotice>
Licensed under the Apache License, Version 2.0 (the "License");
you may not use this file except in compliance with the License.
You may obtain a copy of the License at
http://www.apache.org/licenses/LICENSE-2.0
Unless required by applicable law or agreed to in writing, software
distributed under the License is distributed on an "AS IS" BASIS,
WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
See the License for the specific language governing permissions and
limitations under the License.
</legalnotice>
<title>Standards Compliance</title>
<prepared></prepared>
<responsible></responsible>
<docno></docno>
<approved></approved>
<checked></checked>
<date></date>
<rev></rev>
<file>diameter_soc.xml</file>
</header>
<p>
Known points of questionable or non-compliance.</p>
<!-- ===================================================================== -->
<section>
<title>&the_rfc;</title>
<list>
<item>
<p>
There is no support for DTLS over SCTP.</p>
</item>
<item>
<p>
There is no explicit support for peer discovery (section 5.2).
It can possibly be implemented on top of diameter as is but this is
probably something that diameter should do.</p>
</item>
<item>
<p>
The peer state machine's election process (section 5.6.4) isn't
implemented as specified since it assumes knowledge of a
peer's Origin-Host before sending it a CER. (The identity becoming known
upon reception of CEA.)
The possibility of configuring
the peer's Origin-Host could be added, along with handling of the case
that it sends something else, but for many applications this will
just be unnecessary configuration of a value that it has no control over.</p>
</item>
<!-- Transport protocol plus address/port, which we do know when
sending and receiving CER, is enough to definitely identify
the peer. However, there's nothing stopping a peer from using
different identities on different transport protocols, even
if it's maybe a bit far-fetched. -->
</list>
<xi:include href="diameter_soc_rfc6733.xml"/>
</section>
<!-- ===================================================================== -->
<section>
<title>RFC 3539</title>
<p>
RFC 3539 is more difficult to comply to since it discusses
problems as much as it requires functionality but all the MUST's are
covered, the watchdog state machine being the primary one.
Of the optional functionality, load balancing is left to the
diameter user (since it's the one deciding who to send to) and
there is no Congestion Manager.</p>
</section>
</chapter>
|
