Standards

Navigation

Comments on DRAFT AES74-xxxx

last updated 2019-12-16

Comments to date on DRAFT AES74-xxxx AES standard for audio applications of networks - Requirements for Media Network Directories and Directory Services ,
published 2019-10-09 for comment.


The comment period has closed. The draft has been republished.

Comment received from Kevin Gross, 2019-11-23

4.1 - "network interface" is ambiguous and could refer to a physical network connection or an API over the network. I suspect the latter is intended here.

4.5 Point 2 appears to require persisting queries. Point 3 makes subscriptions optional. 4.4 indicates that if you have persisting queries, you must have subscriptions. The logic is broken somewhere.

7 First paragraph: "it may be registered in another directory" might be read as conformance language implying (with "may") that nesting is optional. Similar issue in last paragraph. Is there a "shall" associated with the ability to nest directories? I did not find it but it appears to be an assumed capability.

10 "The directory standard shall define a range of mechanisms" is implementation advice. This is out of scope for a standard that is setting requirements.

A.2 "using IP hostnames" is not well defined. Change to "using hostnames" or "using DNS hostnames".

A.4 Use RFC 2606 for examples. Suggest change to "directory1.example.com"

Kevin Gross - AVA Networks



Response from R. Cabot, 2019-12-17

Kevin,

Thank you for your comments on the draft.

Section 4.1 has been changed to read "A directory should provide a network API for registration of entities."

Section 4.5 has been changed to
The directory service may support discovery. If supported, discovery:
1. Shall accept entity self-registration and de-registration;
2. Shall support queries;
3. Should support persisting queries, particularly including queries that detect entries added to or deleted from the Directory;
4. Should provide timely automatic detection of entity departure from the media network.

Section 7 was revised to read:
A directory should allow registration of other directories as entities. A directory so registered is called a nested directory, and the directory holding the registration is called the parent directory. A directory in a chain of nested directories that ultimately leads to an entity is called an ancestor of that entity; the entity itself is called a descendant of all its ancestors.
No directory shall be registered in any of its descendants.
Note: In common discourse, a nested directory may be described as being contained by its parent. The term "contained by" is metaphoric, and is not intended to reflect actual implementation structure. The nested directory's entry is contained in the parent, but the nested directory itself may reside anywhere on the media network.

Section 10 has been changed to read:
A directory should support:
• Both local and wide-area applications;
• Network populations ranging from two to many thousands of entities;
• Network infrastructures at all levels of complexity, ranging from simple single-subnet cases to complex cases with many subnets.
Plug-and-play, zero-administration operation shall not be required for larger networks.
Note 1: It is acknowledged that some directory implementations will forever be confined to small environments and need not be scalable. However, scalable designs should be used wherever possible, to forestall future integration problems.
Note 2: Polling implementations are strongly discouraged in all cases.

Appendix A2 has been changed to read "using hostnames"

Appendix A4 has been changed to read:
To avoid conflicts when multiple directory services share the same IP network, each directory service shall have a unique DNS domain, e.g.
"directory1.example.com" and
"directory2.example.com" and
"Domains are described and defined in [RFC 1034], [RFC 1035], and [RFC 2606]."

Also,
Application Program Interface (API) was defined
The note referring to the definition of Entity was shortened to "Note: Entities are described by directory entries. An entity can be a network host, or a software element running in a network host, or a network service, or some other element with an identity in the network. A directory is itself an entity."
RFC 2606 was added to the list of references.

Best regards,

Richard Cabot
AES Standards Manager

AES - Audio Engineering Society