|
Greg, On 26/05/18 20:49, Greg Mirsky wrote:
[BB]: Caveat: I am having to talk in generalizations, cos I don't actually know how you are going to get this protocol to work in a wide range of circumstances, given inherent problems like multipoint feedback implosion {Note 1}. My point was that, having broken up the drafts in this way, this draft on its own no longer defined a workable protocol. Therefore, it needed some references to other drafts (even if they are placeholders), so that the extent of the pre-requisite collection of work is clear. The refs you give later go a long way to fixing this issue. If each pre-requisite protocol is intended to only represent one example, the citation can say that and the ref can be informative. But with zero examples for all the prerequisite parts, all the reader sees is a dismembered octopus, not a protocol. [BB]: In my experience, informative refs to non-WG drafts as use-cases would be OK during doc development. However, if a non-WG draft fails to proceed, its citation has to be removed later. So choose those that are most likely to proceed. Nonetheless, if you cite some specs that turn this into a workable protocol (see previous issue) use-cases might not be necessary. [BB]: Fair enough. In some scenarios, this issue will not necessarily be so unlikely tho: * If asymmetric crypto is used to solve the group message authentication problem (see later), the processing burden on any lightweight endpoints might lead to message verification leaving less available processor resource than needed for the host's other tasks. * Each tail might be joined to a very large number of multipoint sessions. I would suggest a new section listing potential issues when there is no back channel. [BB]: Well, the point limits the applicability of the assumption about security in 5. 'Assumptions', so this would fit well there. Then "Security Considerations" should point to everywhere in the doc that discusses security, such as this (to save time for security reviewers). [BB]: Normally a MUST is applied to implementations. It would be rather odd to require users/operators to satisfy a spec requirement, particularly requiring them to trust each other. I think this should be written as an applicability statement not a normative requirement.
[BB]: If you are going to allow for cases where all tails are trusted not to spoof the head, then the assumption written in section 5 is no longer correct. [FYI, RFC4082 is only a generic description. Many RFCs have been written to authenticate specific protocols along TESLA lines.] [BB]: Yup. Except delete "received the". Also see above about whether this is now a correct assumption.
[BB]: I seem to have become co-opted into redesigning this protocol. I'd prefer to limit my involvement to reviewing :) [BB]: Good. Nonetheless, given you have confirmed that a reverse path is optional, the doc still needs to address the case where there is no reverse path. {Note 1} For the active tail draft, you might find the following ideas for scaling multipoint feedback useful: Statistical feedback: Nonnenmacher, Jö. & Biersack, E.W., "Scalable Feedback for Large Groups," IEEE/ACM Transactions on Networking 7(3):375--386 (June 1999) FUHRMANN, T., AND WIDMER, J. "On the scaling of feedback algorithms for very large multicast groups," Computer Communications 24, 5-6 (March 2001), 539 547; WIDMER, J., AND FUHRMANN, T. Extremum feedback for very large multicast groups. Tech. Rep. TR 12-2001, Prakfische Informatik IV, University of Mannheim, Germany, May 2001. Also, anycast can be used to select different representative feedback tails, e.g. for a certain time, which might overlap with the periods for which a few other tails are selected using subsequent anycasts. Logical 'AND' feedback: Burbridge, T., Soppera, A., Briscoe, R. and Jacquet, A. "Method and device for co-ordinating networked group members" Patent WO2004059479, (Jul 2004; Priority 24 Dec 2002) [AFAICT this patent is still being maintained, so use of it in a protocol would require an IPR declaration.] [BB]: And my response is same as #1. [BB]: Good. [BB]: See earlier comment about citing individual drafts (I don't have enough BFD knowledge to give a BFD-specific answer). Also, in my review I should also have said: when creating new encapsulations, pls see the common transport issues related to encapsulation: https://trac.ietf.org/trac/tsv/wiki/tsvdir-common-issues#TunnelingprotocolsandTransportRelatedIssues [BB]: And my response is same as #1. [BB]: On what basis will local policy decide? It's my job as a reviewer to ensure that this spec does not contain any loose ends (open issues). [BB]: OK.
[BB]: And my response is same as #6. [Sry, my embedded comments have broken your numbered list.] [BB]: OK. [BB]: Doesn't something need to be written (or referenced) to clarify all this? AFAIR, this spec. never made clear that multipoint is a fork in implementations. [BB]: I assume you will say all this in the next rev, not just in this email. [BB]: If I were an implementer, I would not know what this is saying I ought to implement. The spec needs to answer this question: If the head changes the packets what happens differently if it sets the P bit vs. if it doesn't? [BB]: As long as this represents the logic you want, fine. The point is that the indentation is the only clue to whether one 'if' is conditional on a previous 'if', or not. HTH Bob -- ________________________________________________________________ Bob Briscoe http://bobbriscoe.net/ |
