Thanks, Adrian, for addressing my comments. All good. Barry
On Wed, Dec 18, 2019 at 10:42 AM Adrian Farrel <[email protected]> wrote: > > Hello Barry, > > Thanks for the comments. > > > — Section 1.2 — > > > > o Service Function Overlay Network. The logical network comprised > > of Classifiers, SFFs, and SFIs that are connected by paths or > > tunnels through underlay transport networks. > > > > You use “comprises” correctly four other times in the document, but this > > one is > > incorrect: “comprised of” should instead be either “comprising” or “composed > > of”. I only bother mentioning it because it’s right the four other times. > > I just consulted an English copy editor who says "comprised of" is correct. > Let's leave this to the RPC to apply house style. > > > — Section 3.1 — > > > > The Service Function Type identifies the functions/features of > > service function can offer, e.g., classifier, firewall, load > > balancer, etc. > > > > Should this be “a service function”, rather than “of service function”? > > And a > > Yes. Good catch. > > > nit: you don’t need both “e.g.” and “etc.” together: either one will do on > > its > > own. > > <Red face emoticon> > > > — Section 3.2.1 — > > > > o The errors listed above are treated as follows: > > > > 1., 2., 6., 7.: The attribute MUST be treated as malformed and > > the "treat-as-withdraw" approach used as per [RFC7606]. > > > > 3.: Unknown TLVs SHOULD be ignored, and message processing SHOULD > > continue. > > > > 4.: Treated as a malformed message and the "treat-as-withdraw" > > approach used as per [RFC7606] > > > > Why is 4 not included in the 1,2,6,7 group? It seems odd to separate it and > > not to make it “MUST”, like the others. > > IDR was very specific about how we treated error cases. We tried to comply > with what they wanted to see. > > 4 cannot be parsed further and already has 7606 describing it, so it was > appropriate to pull it out separately. In practice, item 4 is not defining > new behaviour: such issues will be treated as malformed by definition so > (arguably) using 2119 language is inappropriate as we are not defining this > behaviour. > > But, making 4 say "MUST be treated as described in RFC 7606" seems reasonable. > > > — Section 9 — > > > > Service Function Chaining provides a significant attack opportunity: > > packets can be diverted from their normal paths through the network, > > can be made to execute unexpected functions, and the functions that > > are instantiated in software can be subverted. > > > > The second item in the list appears to lack a subject: <what?> can be made > > to > > execute unexpected functions. > > Ah, yes. Originally it was going to be three things applying to packets. We > will fix it. > > Cheers, > Adrian > _______________________________________________ BESS mailing list [email protected] https://www.ietf.org/mailman/listinfo/bess
