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'? 

Also - I did not understand to what the last sentence refers (the same
applies to this document...)


Nits/editorial comments:

1. In the IANA Considerations section - add a note to the RFC Editor
that requires that xxxx 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)