Subject: [Gen-art] Gen-ART review for draft-ietf-sipcore-rfc4244bis-09.txt

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Thu, 13 Sep 2012 14:46:52 +0200

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)

---

From: Mary Barnes <[email-masked]>
Date: Thu, 13 Sep 2012 16:54:34 -0500

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

> prevent writing just 'does not make any changes' and 'the entries are
[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]

> 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]

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Fri, 14 Sep 2012 19:28:15 +0200

From: Mary Barnes [mailto:[email-masked]] 

Minor issues:

[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]

[[DR]] This looks fine to me. Thanks for addressing the comment. 

Regards,

Dan