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.com>wrote: > > 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 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) >
_______________________________________________ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
