1) "I'm not sure that the model really expands from netflows to IP flows (or TOR)
in the future." => not addressed here.
2) re-using the same credentials with different protocols/auth mechanisms. => I think the fourth paragraph of the -arch Security Considerations speaks to this; instead of repeating it, I thought it would be better to point at this document (similar to how the implementation draft does it), as its security considerations should apply to all of the API draft anyway.
3) not using an FQDN punts a security risk mostly to the application: I more or less copied the wording about the no-FQDN security risk from section 6.1, it seems fair to repeat this here as a warning.
1460 raises three points:
1) "I'm not sure that the model really expands from netflows to IP flows (or TOR) in the future." => not addressed here.
2) re-using the same credentials with different protocols/auth mechanisms. => I think the fourth paragraph of the -arch Security Considerations speaks to this; instead of repeating it, I thought it would be better to point at this document (similar to how the implementation draft does it), as its security considerations should apply to all of the API draft anyway.
3) not using an FQDN punts a security risk mostly to the application: I more or less copied the wording about the no-FQDN security risk from section 6.1, it seems fair to repeat this here as a warning.