Hi, thanks for the comments, replies are inline. I will add those changes to the draft once the last call process is over.
Ciao, - - Jaime Jimenez > On 27 Apr 2015, at 19:07, Roni Even <[email protected]> wrote: > > <>I am the assigned Gen-ART reviewer for this draft. For background on > Gen-ART, please see the FAQ at < > <>http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq > <http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>>. > > Please resolve these comments along with any other Last Call comments you may > receive. > > Document: draft-jimenez-p2psip-coap-reload-08 > Reviewer: Roni Even > Review Date:2015–4-27 > IETF LC End Date: 2015–5-13 > IESG Telechat date: > > Summary: This draft is ready for publication as an Standard Track RFC. > > > Major issues: > Minor issues: > > > > Nits/editorial comments: > > Some questions about the terminology in section 3 > > Client – is this different from RFC6940, if not why repeat? -- You are correct, it is the same, we can just add a reference to RFC6940 > Router – this is a different name for a peer? I also noticed that it is used > once in the document (defining constrained node) where it does not provide > any value -- Also agree, we could simply leave it in peer. > Proxy and Proxy node – Why do you need both terms. In section 7 it uses > proxy(PN) like it is the same term. -- This was done to differenciate between physical node and the role they play functionally. For the spec itself only the functional roles are important, the others just give a better picture of the types of nodes you can have. We could just call both Proxy Node if it helps. > Constrained node the last sentence “In the latter case the node is often > connected to a continuous energy power supply” it is not clear what is the > latter case, also what type of node is meant. Note that there is a redundant > “either a” in the previous sentence. -- Correct it should be: "A CN is always either a Sensor or an Actuator. If it is an actuator, the node is often connected to a continuous energy power supply."
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ Gen-art mailing list [email protected] https://www.ietf.org/mailman/listinfo/gen-art
