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 BESS@ietf.org https://www.ietf.org/mailman/listinfo/bess
