Hi, Below are my replies to Avshalom's comments. >Minor issues: > >11. Security section >Seems too short for this type of proposal. May need to reference security >sections in relevant other RFCs.
[Christer] I will add the references to the security section. As far as the content of the section is concerned, I am not really sure what else I could add. But, I will think about it. ------------- >Nits/editorial comments: > >Section 3: Requirements >A single requirement is listed without any wording around it. A bit of >explanantion may help. [Christer] Based on other comments, I have suggested to remove the whole section, because I don't know if it belongs to the spec. ------------- >Section 4.1 Examples of resource types >Some benefits from resourc types are listed and then there are several >paragraphs whose context is not very clear. [Christer] I will double check the text, but I would be happy if you could point to some specific text which you think is unclear :) Based on Cullen's comments, I will at least take a second look on the sentence related to latching. ------------- > Line 380: > the 199 response unreliable, or include an SDP offer with no m- > lines > -> the 199 response unreliably, or include an SDP offer with no m- > lines [Christer] I'll fix that. ------------- > Line 381: > in the reliable 199 response. > -> in a reliable 199 response. [Christer] I'll fix that. ------------- > Line 384: > is only used for information purpose, the UAS SHOULD send it > -> is only used for information purposes, the UAS SHOULD send it > (not sure if it should be fixed, current wording not fluent either) [Christer] I suggest: "Since the 199 provisional response is used only for information purpose a UAS SHOULD, when sending the response, send it unreliably even if the 100rel option tag [RFC3262] is present in the Require header of the associated request." Regards, Christer _______________________________________________ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art