Hi Dan,
Thanks for your careful review. We will fix the nits in the next version.
I have some comments and new proposed for the minor issue below.
Mary
On Thu, Sep 13, 2012 at 7:46 AM, Romascanu, Dan (Dan) droma...@avaya.comwrote:
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.
Please wait for direction from your document shepherd or AD before
posting a new version of the draft.
Document: draft-ietf-sipcore-rfc4244bis-09.txt
Reviewer: Dan Romascanu
Review Date: 9/13/2012
IETF LC End Date: 9/20/2012
IESG Telechat date:
Summary:
The document is ready for publication. There is one minor issue that
could benefit from clarifications and a few nits worth cleaning up.
Major issues:
Minor issues:
1. Last paragraph in 16.1:
In cases where an entity that is compliant to this document, receives
a request that contains hi-entries compliant only to RFC4244 (i.e,
the hi-entries do not contain any of the new header field
parameters), the entity should not make any changes to the hi-entries
- i.e., the entries should be cached and forwarded as any other
entries are. As with RFC4244 compliant entities, applications must
be able to function in cases of missing information. The same
applies to this document as specified in Section 11.
I am a little confused by the language used here. It's OK if it is not
capitalized if the functionality is described someplace else. However,
why ' should not make any changes to the hi-entries' and ' the entries
should be cached and forwarded '? Are there any exception cases that
prevent writing just 'does not make any changes' and 'the entries are
cached and forwarded'?
[MB] The intent was to state that the entity MUST NOT add any of the new
header parameter values to the hi-entry to make it look like a 4244bis
hi-entry. But, rather the hi-entry is processed in the exact same manner as
4244bis compliant entries. I think we do need normative behavior as I
don't think we have specified the behavior for this scenario
elsewhere. [/MB]
Also - I did not understand to what the last sentence refers (the same
applies to this document...)
[MB] It was trying to refer to section 11 which specifies that applications
must
be able to function in cases of missing information. Really, we could
probably just delete that sentence and add the section 11 reference to the
previous sentence. [/MB]
[MB] Based on my comments above, I would propose the following rewording
for that text:
In cases where an entity that is compliant to this document, receives
a request that contains hi-entries compliant only to RFC4244 (i.e,
the hi-entries do not contain any of the new header field
parameters), the entity MUST NOT add
any of the new header field parameters to the hi-entries.
The hi-entries MUST be cached and forwarded as any other
entries are as specified in section 9.1.
As with RFC4244 compliant entities, applications must
be able to function in cases of missing information, as specified in
Section 11.
[/MB]
Nits/editorial comments:
1. In the IANA Considerations section - add a note to the RFC Editor
that requires that in [RFC xxx] be replaced with the RFC number
allocated for this document.
2. [RFC3969] is unused.
3. In Section 2, 3rd paragraph s/are used consistent/ are used
consistently/
4. In section 4:
This specification also defines three new SIP header field
parameters, rc, mp and np, for the History-Info and Contact
header fields, to tag the method by which the target of a request is
determined. Further detail on the use of these header field
parameters is provided in Section 10.4.
Actually the parameters rc, mp and np are defined in section 5.
5. The readability of the document could be improved by adding a short
terminology and abbreviations section or by expanding terms and acronyms
at first occurrence (e.g. UAC, SWS, B2BUA)
___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art
