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
[email protected]
https://www.ietf.org/mailman/listinfo/gen-art
