IN(ternet) class is the default one.
I know another useful one, CHAOS :
censurfridns :
% dig #91.239.100.100 version.bind TXT CHAOS +short
"9.11.4-P2+dampening"
Are the other ones have a use case ?
CS aka CSNET class (Obsolete)
HS aka Hesiod [Dyer 87]
From http://www.faqs.org/rfcs/rfc2929.html
RR CLASS IANA Considerations
DNS CLASSes have been little used but constitute another dimension
of the DNS distributed database. In particular, there is no
necessary relationship between the name space or root servers for
one CLASS and those for another CLASS. The same name can have
completely different meanings in different CLASSes although the
label types are the same and the null label is usable only as root
in every CLASS. However, as global networking and DNS have
evolved, the IN, or Internet, CLASS has dominated DNS use.
There are two subcategories of DNS CLASSes: normal data containing
classes and QCLASSes that are only meaningful in queries or updates.
The current CLASS assignments and considerations for future
assignments are as follows:
Decimal Hexadecimal
0 0x0000 - assignment requires an IETF Standards Action.
1 0x0001 - Internet (IN).
2 0x0002 - available for assignment by IETF Consensus as a data CLASS.
3 0x0003 - Chaos (CH) [Moon 1981].
4 0x0004 - Hesiod (HS) [Dyer 1987].
5 - 127 0x0005 - 0x007F - available for assignment by IETF Consensus as data
CLASSes only.
128 - 253 0x0080 - 0x00FD - available for assignment by IETF Consensus as
QCLASSes only.
254 0x00FE - QCLASS None [RFC 2136].
255 0x00FF - QCLASS Any [RFC 1035].
256 - 32767 0x0100 - 0x7FFF - assigned by IETF Consensus.
32768 - 65280 0x8000 - 0xFEFF - assigned based on Specification Required as defined
in [RFC 2434].
65280 - 65534 0xFF00 - 0xFFFE - Private Use.
65535 0xFFFF - can only be assigned by an IETF Standards Action.
All other ones are basically now obsolete and not used.
See https://miek.nl/2009/july/31/dns-classes/ for some explanations, like:
The CH class has its use in the Chaosnet, which is a network implementation that didn’t make it, unlike the current Ethernet + TCP/IP combo. [..] Today the CH class is missused by BIND, for the following neat tricks: ...
and
The HS class has its origins Project Athena (also see Wikipedia. Which is a naming server ala nis or more recent ldap. With HS class you can put user and group data in your DNS, so you can do without an ldap server. The package hesiod still can be installed if you want to play with this.
Section 3.2 of RFC2929 (september 2000!) already says:
DNS CLASSes have been little used but constitute another dimension of
the DNS distributed database. [..] However,
as global networking and DNS have evolved, the IN, or Internet, CLASS
has dominated DNS use.
It is widely believed now that the DNS specification is not clear enough regarding classes and how much they are isolated one from another.
This latest document (https://tools.ietf.org/id/draft-sullivan-dns-class-useless-03.html) in July 2016 gives explanations on the current status and what to do in the future:
Domain Name System Resource Records are identified in part by their class. The class field is not effective, and it is not used the way it appears to have been intended. This memo makes no recommendation about the DNS parameters registry, but urges those defining new RRTYPEs to define them for all classes.
[..]
As of this writing, there are only three "ordinary" classes assigned. Class 1 is the Internet or IN class. Class 3 is the Chaos or CH class. Class 4 is the Hesiod or HS class. Class 2 is noted in [RFC1035] as the CSNET or CS class, but the current registry (at http://www.iana.org/assignments/dns-parameters/dns-parameters.xml#dns-parameters-2) no longer includes the assignment.
[..]
DNS classes are effectively vestigial
Given the considerations above, it is plain that DNS classes are unlikely to be useful in the future. Designers of new name systems should consider the design of classes in the DNS. If a similar feature is desirable, its design needs to be different in order to be useful. Given the the way the DNS has managed to thrive effectively without classes, however, it would be worth asking whether the feature is useful at all.
You can find a lot of discussions on it, specifically in the IETF Working Group dnsop that cater for these topics:
https://www.mail-archive.com/dnsop#ietf.org/msg14877.html
https://www.iab.org/mail-archive/web/inip-discuss/current/msg00060.html
This specific Internet-Draft is also referenced in RFC 8324 - DNS Privacy, Authorization, Special Uses, Encoding, Characters, Matching, and Root Structure: Time for Another Look?
as [Sullivan-Class] in:
In recent years, demand for new and extended services and uses of the
DNS have, in turn, led to proposals for DNS extensions or changes of
various sorts. [..] A
few features of the original DNS specification, such as the CLASS
property and label types, have also been suggested to be so badly
specified that they should be deprecated [Sullivan-Class].
and
3.6. Alternate Namespaces for Public Use in the DNS Framework: The
CLASS Problem
The DNS standards include specification of a CLASS value, which "identifies a protocol family or instance of a protocol" (RFC 1034, Section 3.6, and elsewhere). While CLASS was used effectively in the early days of the DNS to manage different protocol families within the same administrative environment, recent attempts to use it to either partition the DNS namespace in other ways such as for non-ASCII names (partially to address the issues in Sections 3.2 and 3.3) or use DNS mechanisms for entirely different namespaces have exposed fundamental problems with the mechanism [Sullivan-Class]. Perhaps the most fundamental of those problems is disagreement about whether multiple CLASSes were intended to exist within a given zone (with records within RRSETs) or whether different CLASSes implied different zones. Different implementations make different assumptions [Faltstrom-2004] [Vixie-20170704]. These problems have led to recommendations that it be dropped entirely [Sullivan-Class], but discussions on the IETF list and in WGs in mid-2017 made it clear that there is no clear consensus on that matter.
Related
Is this UML consistent with the text below?
Instead of trying to either define many subclasses or introduce
multiple inheritance, we can instead define a set of roles that the
device is meant to play. (It should be noted that this is another
reason why the concept of a managed device is a good one – now, we can
define a base concept of a managed device, and model its functionality
by associating one or more roles to it as appropriate). This solves
the mess of having the same generic function (such as routing)
assigned to two different types of devices that implement that same
generic function in different ways, producing different subsets of
functionality.
I believe that the UML specifies that each Device can have 0 or 1 DeviceRoles. A colleague asserts that the UML specifies that each DeviceRole can belong to a maximum of one Device. In either case, the UML seems to not reflect that a Device can aggregate a set of roles.
The UML and text is extracted from TMForum's Information Framework (SID):
Physical Resource Business Entities
Information Framework Suite
GB922 Physical Resource
Release 15.0.1
November 2015
Thanks, Greg
The UML diagram is consistent with the text. It clearly says that the device aggregates zero or more device roles and a device role can be played by zero or one device. In UML, multiplicity is notated adjacent to the type it quantifies.
It would help if the property names were written at the ends of the associations.
I have worked on this document and created a data model from it. In real world experience a resource, for example a physical resource like a mikrotik router can have roles of a router and firewall at the same time. So the model has to let you fulfill the need of several roles for a single resource.
I hope this example will clarify the subject.
From my understanding, SysML 1.4 allows to have itemFlows between Block as well as Part
Here is an excerpt from pag 75 of the SysML 1.4 specs
which shows that it is possible to have itemFlow(s) between Blocks.
I am not sure about the semantic of this.
For example, referring to the excerpt from the SysML 1.4 specs, does it mean that every instance of Engine block requires an "itemFlow" connection to an instance of a Transmission block and that a Torque will flow between every Instance of Engine block to the associated instance of Transmission Block?
Yes, of course. At least if the Engine/Transmission are blocks instantiated from this model.
You are free to define other Engines/Transmissions where not Torque is transported (e.g. if you see a copper cable as transmission where current is transported rather than torque).
An item flow in general tells that "something physical" is moved from source to target. The above transports torque. You can also transport current, gas, fluid, etc. Even abstract information can be transported, though SysML is designed to map physical objects, rather than abstract things (where UML will be sufficient).
There is an association between Engine and Transmission. Since we don't see any multiplicity, we may assume that it is 1. That means every Engine instance must be linked to a Transmission instance and vice versa. This is not realistic, but hey, who wants models of reality ;-). In the real world the multiplicity is 0..1.
The item flow just says, that Torque can potentially flow across a link between the two instances.
By the way: This is also not realistic, since torque is the potential to flow, not the item flowing. The item is rather angular momentum. For reasons I don't understand, the potential (e.g. Torque) or the rate (e.g. Current) is often used in place of the item that is flowing in reality.
I would like to have one or more libraries of reusable classes that are basically value objects, such as Address, PhoneNumber, EmailAdress, containing mostly properties and a few supporting methods. How can my Domain layer use these without breaking the rule that the Domain Layer should not contain external references, and without defining them as interfaces/abstract classes in the Domain Layer?
... without breaking the rule that the Domain Layer should not contain external references
I think your definition of 'external references' requires some reevaluation. It is hard to imagine a domain layer that does not reference anything. In C# and Java you will reference at least basic numeric types, dates and strings. I also don't see any harm in referencing external libraries like Noda/Joda time. On the other hand, you of course would not want to reference any heavy technical libraries like persistence, communication, UI etc.
So I would say that you can build your own reusable library referenced from domain but it requires a very careful consideration, and is often not worth the coupling that it will create. I would use a following criteria for every type:
Should be context-independent. EmailAddress for example is relatively independent of the context it is used from. Address on the other hand may have a different meaning depending on a Bounded context.
Should be stable (does not change often).
Should not hide any out-of-process communication (db, network etc)
Should not have any dependencies of its own (other than standard Java/C#)
I think that what you're referring to is a shared kernel.
Shared Kernel – This is where two teams share some subset of the
domain model. This shouldn’t be changed without the other team being
consulted.
While this looks great at first, since we are drilled not to repeat ourselves, be aware of the pitfalls:
The concepts should have the same meaning in every context. Some of these concepts hold subtle nuances depending on the context. Ask your domain expert.
Changes are more expensive; it might be cheaper to duplicate these few classes so that you can change them on your own than to have to consult multiple teams when something changes.
Stability cuts both ways. If you pull an entity out into each domain, then any changes have to be executed across multiple projects. If you don't, then changes have to be coordinated across multiple domains. The logistics of the former are easier than the latter, but the work involved in the latter can be greater. Either way, you have to test the changes on each platform.
And unless the entity is mature with a relatively well-defined semantics, my experience is that almost everything changes. So stability is nice, but might be a bit of a red herring.
That being said, I like (and +1) #Dmitry.
1)
Evan's book, pg. 415:
Also, the critical aspects of the domain model may span multiple
Bounded Contexts, but by definition these distinct models can't be
structured to show their common focus.
a) I assume the quote is implying that Core Domain CD can span several Bounded Contexts BCs?
b) I assume BCs within CD should only contain core elements, but no generic elements? If so, doesn't that mean we should always design BCs ( those contained by CD ) with Core Domain in mind? In other words, we should have some general idea what CD is even before we begin designing BCs?
c)
... but by definition these distinct models can't be structured to
show their common focus
I realize that BCs shouldn't be structured such that outside world would be able to immediately figure out how all the parts ( ie BCs ) fit together and what their common purpose is, but is author implying that such a structure ( which would implicitly convey the common purpose of different BCs ) couldn't happen even by accident? If so, why?
2) Domain Model may have several Generic Subdomains GSs , but can a single GS span multiple BCs?
UPDATE:
1)
b)
I assume BCs within CD should only contain core elements, but no
generic elements? ...
One should certainly have an idea of what the core domain is when
defining BCs. As stated, ideally, they should be one-one. However, a
BC may be defined to fulfill needs of of a system in a non-ideal
state.
I assume you're implying that in non-ideal situation BC within CD may also contain some non-core elements and also in non-ideal situation CD may contain more than one BC?
c)
A domain spans multiple BCs but despite explicit boundaries, domain
behavior can certainly span BCs. A context map can describe such
cross-BC interactions. The quote itself is based around the idea of a
domain vision statement the purpose of which is to highlight the value
of the core domain and possibly explain the relationship to BCs.
But why is author using the term "by definition", as if to imply there is no way that BCs could accidentally also be structured such that they would show their common focus?
2)
Domain Model may have several Generic Subdomains GSs , but can a
single GS span multiple BCs?
Multiple BCs can make use of a single generic sub-domain. I would
avoid the term "spans" here because that overemphasizes the importance
of the generic sub-domain for the entire domain model.
a)
Multiple BCs can make use of a single generic sub-domain
Not sure I understand your reply. Are you saying that a single GS can contain multiple *BCs*?
b)
I would avoid the term "spans" here because that overemphasizes the
importance of the generic sub-domain for the entire domain model.
Perhaps a useless question, but could you elaborate on why using the term "span" would make Generic Subdomain appear more important than it actually is?
REPLYING TO Giacomo Tesio:
1)
b)
No, some generic elements often play a key role in the Core Domain.
See for example Time, Currency and Money that are present in many
Shared Kernel: they are really generic but important to the Core
Domain rules.
So if generic element ( such as Time, Currency and Money ) is also used by Core Domain, then only implementation option is Shared Kernel ( ie this generic element is shared by both Core Domain and any other subdomain(s) that needs it ), but if generic element is used only by Core Domain, then we shouldn't bother with Shared Kernel, but should instead define this generic element directly within Core Domain ?
1)
c) Context boundaries are defined after term's semantics. In a BC, no
term should mean more than one thing (see SRP). When you see that a
class has more than one meaning in the domain expert's mind, you know
that you have mixed differnt BC.
Could you expand on your answer a bit, since I fail to understand how your answer relates to my question?
SECOND UPDATE:
1)
b)
It may also be that a single BC contains multiple sub-domains. This is
usually not ideal because it likely indicates a conflated BC.
When reading the book, I haven't pay much attention to author's usage of the term "subdomain", but I'm pretty certain that the book doesn't offer a thorough definition of what a subdomain is. So what exactly is considered a subdomain? Just a bunch of logically related domain concepts? If yes, then I assume a subdomain should never span several BCs?
2)
a)
A signle GS can be used by multiple BCs. This is so because the
sub-domain is generic. So the GS doesn't contain the BCs; instead, it
is referenced by the BCs.
From your reply it seems you're implying that Generic Subdomains are never implemented as BCs? Why not, since in my opinion different Generic Subdomains may contain distinct models and BCs seem ideal solution to separate those generic models?!
3)
Could you also help me with the following question, since it's confusing me quite a bit: if generic element ( such as Time, Currency and Money ) is also used by Core Domain, then only implementation option is Shared Kernel ( ie this generic element is shared by both Core Domain and any other subdomain(s) that needs it ), but if generic element is used only by Core Domain, then we shouldn't bother with Shared Kernel, but should instead define this generic element directly within Core Domain ?
thank you
1a) In that quote the author is referring to the entire domain, not the core domain. The entire domain can span multiple BCs. The relationship between a BC and core domain can be more complicated. Domains, sub-domains and the core domain are elements of the problem space. A BC is an artifact of the solution space. In reality, they may not always be one-to-one, however that is the ideal.
1b) One should certainly have an idea of what the core domain is when defining BCs. As stated, ideally, they should be one-one. However, a BC may be defined to fulfill needs of of a system in a non-ideal state.
1c) A domain spans multiple BCs but despite explicit boundaries, domain behavior can certainly span BCs. A context map can describe such cross-BC interactions. The quote itself is based around the idea of a domain vision statement the purpose of which is to highlight the value of the core domain and possibly explain the relationship to BCs.
2) Multiple BCs can make use of a single generic sub-domain. I would avoid the term "spans" here because that overemphasizes the importance of the generic sub-domain for the entire domain model.
UPDATE
1b) It may be that a core-domain is implemented with multiple bounded contexts. This isn't necessarily a defect and in some instances is the ideal. It may also be that a single BC contains multiple sub-domains. This is usually not ideal because it likely indicates a conflated BC.
1c) By definition BCs are physically partitioned and shouldn't have direct dependencies. I think this is what the author is referring to. The issue he's highlighting is that you can have multiple BCs at play which warrants explanation, especially when a single sub-domain is addressed.
2a) A signle GS can be used by multiple BCs. This is so because the sub-domain is generic. So the GS doesn't contain the BCs; instead, it is referenced by the BCs.
2b) Having a generic sub-domain "span" the system may be an indication that it isn't really a generic sub-domain, but a core domain. This is not to say that a generic component can't be used throughout the system, quite the contrary. However in that case, the component spanning the system is only a technical axis.
UPDATE 2
1b) Yes a sub-domain is a cohesive component of the entire domain. A sub-domain can span multiple BCs. This can be acceptable because a BC is a solution space artifact and there can be technical reasons or even organizational issues for its existence. For example, in the domain of an online retailer there is a product catalog sub-domain. This would have a corresponding products BC. However, additional functionality regarding product search can be placed into a product search BC. This is still part of the catalog sub-domain, but a new BC for technical reasons. On the other hand, when a single BC contains multiple sub-domains, this can be problematic.
2a) I think I got overly semantic on the use of the word span. A generic sub-domain can be a BC. However, care must be taken to ensure that a generic sub-domain is in fact used in a generic way.
3) Yes. Beyond that, base classes like Money can be implemented uniquely for each sub-domain even if they are used in multiple places. Sometimes copy-and-paste is the best pattern.
1a) Yes, the Core Domain essentially is the set of bounded contexts that worth the application's development from the customer point of view.
1b) No, some generic elements often play a key role in the Core Domain. See for example Time, Currency and Money that are present in many Shared Kernel: they are really generic but important to the Core Domain rules.
1c) Context boundaries are defined after terms' semantics. In a BC, no term should mean more than one thing (see also SRP). They are almost linguistic boundaries! When you see that a class has more than one meaning in the domain expert's mind, you know that you have mixed different BC.
2) Yes, Generic Subdomains are those part of the domain model (or, the set of the bounded contexts) that are useful but not central in the application. I've built several applications with generic subdomains: when they add some value that the customer wish to pay (and I can't provide such value with a simple CRUD component).
Note that what's "Core Domain" in your application is a qualitative definition: I've seen many times secondary parts of successful applications to achieve importance when the customer's corporate organization changed. Thus, what is Core Domain today might be not tomorrow.
Does anyone know the difference between Credit-Control-Application and Ro application in the diameter protocol? Their implementation in Mobicents diameter stack is almost identical.
I have searched within corresponding RFCs and 3GPP documents but couldn't find out which one must be used for online charging process.
Put in a simple way: IETF specifies the protocol while 3GPP specifies how to use the protocol in a very specific context. 3GPP may have additional requirements or recommendations in place when specifying a reference point (or "interface"), but normally this is done w/o violating any IETF RFCs (otherwise conflicts with be liaised to IETF for resolution).
The above usually describes most of the relationship between an IETF-specified protocol and their corresponding use in 3GPP.
For Diameter applications, 3GPP sometimes may also extends IETF RFCs with additional application IDs, AVPs, as well as defining how to map Information Elements (IEs) from other 3GPP interfaces into the AVPs.
Now down to the Credit-control diameter application and Ro interface. The former is defined in RFC 4006, while the latter is defined in 3GPP TS 32.299. I haven't gone through the 3GPP spec in great details, but it's not too difficult to find just a few differences. For example, Credit-Control-Request (CCR) Message for Ro Interface does not used Requested-Service-Unit AVP and a few others as pointed out in Table 6.4.2 of 32.299; but the CCR message may contain QoS-Information, a group AVP defined in 29.212, and this is Ro-specific. Table 6.4.3 of 32.299 describes similar for Credit-Control-Answer message, and look out for more differences laid out by the document.
As for Mobicents, I don't have experiences with its implementation but it won't surprise me that an open-sourced version is not fully-compliant with 3GPP specifications and omits some of the additional features.