NFD

Do we really need "query" operation be that complex? The only usage I know for now it to be used during "unregister" in nfdc. What's a point of this complexity?

This filter will be useful:

• nfdc operations can take all kinds of FaceUris with remoteUri and localUri conditions
• a monitoring tool can retrieve the counters on a single face with FaceId condition; it's more efficient than requesting faces/list, when only one face is needed
• ndn-autoconfig can use isMultiAccess condition to find out all multicast faces without filtering itself in faces/list

20140718 conference call approves the proposal in note-3.

IsMultiAccess? should probably replaced with Flags?. This would include ability to select multi-access links, but would also provide ability to select faces based on other flags.

I thought about using Flags and defining isMultiAccess as a flag.

The problem is, the filter could specify one of the following for each flag:

• 1
• 0
• don't care

With a single Flags field, there is only one bit per flag, and it's not possible to represent three possible values in one bit.

One option is to have a FlagsMask field in addition to Flags, but that's less understandable.

20140818 conference call decides to eliminate FaceFlags field.

• In FaceStatus block, FaceFlags field is replaced with three boolean fields.
• In FaceQueryFilter block, presence of a boolean field indicates a condition, omission of a boolean field indicates "don't care".

Please review FaceMgmt revision 39.

20140820 conference call approves the design for face query operation.

We have further decided that DNS resolution should not be performed within NFD.
Therefore, DNS names are not supported in face query operation.

DNS names are currently allowed in faces/create command, but it's not recommended.

How important is it for the response to be defined as a StatusDataset? Can we define a new protocol type (query) that uses unsigned requests?

I think not responding sets a bad precedent and I'm not sure a NACK would be the right thing either. If there's an error, then the response should be an error so that the application/user can correct the issue.

It's desirable to minimize the number of artifacts in a protocol.

What's wrong with responding with producer-generated NACK (suppose it's available in packet format)?

My answer to this problem would have been an appropriate error control response if the protocol was not a StatusDataset. The query feels like a command: you're asking NFD to do something on your behalf (but it's not modifying its state).

I don't have a good answer for why not producer NACK so much as control response seems like the natural answer to me. This may be due to me not understanding the exact usage of the NACK in this scenario. If the NACK informs the sender there is a specific error rather than just a generic error state, then I guess it would be equivalent/better. I just want to make sure there is meaningful feedback.

Are you planning to change the error control responses for ControlCommand protocols to producer NACKs, too?

Producer generated NACK indicates the authentic non-existence of some Data.
The reason could be carried in the NACK packet.

ControlCommand shouldn't use producer generated NACK for most errors, because the error condition is due to some execution failure, not the non-existence of a command processor.

Junxiao Shi wrote:
Producer generated NACK indicates the authentic non-existence of some Data.
The reason could be carried in the NACK packet.

Is the producer generated NACK just a "NACK" type field/flag in a Data packet? If so, would an acceptable temporary solution be to respond with a "normal" Data packet with the reason? The requester could identity the failure by recognizing that the response doesn't begin with a FaceStatus TLV and maybe some sanity checks on the message (ex: begins with "Error", null terminated, etc.).

I would split the implementation into two stages:

1. don't respond
2. respond with producer generated NACK

The second stage is blocked by ndn-cxx's support of producer generated NACK.

This could be included as an experimental feature in ndn-cxx without NDN-TLV spec update; an example of such an update is #2021.

It's NOT ACCEPTABLE to represent producer generated NACK with BLOB Data, because that sets a bad example.

Why NACK is blocked? There is nothing that prevents us from creating a producer-generated NACK by assigning NACK code to MetaInfo.ContentType and leaving content empty. Wouldn't that be sufficient?

The only choices for ContentType are: BLOB, LINK, KEY.

Other codes are forbidden.

I'm fine with adding this as a protocol-violating experimental feature in ndn-cxx.
But the producer behavior in this case cannot be defined in NFD Management protocol; it is rather an implementation choice.

Fine with me.

+1 for experimenting with the NACK code in ndn-cxx.

To echo Alex's earlier question, what is blocking us from standardizing the producer NACK? Is there really much more to discuss for this specific NACK type or are we trying to hold off until we have all NACK related things decided?