Thanks, Christer and Paul. Your proposed changes seem fine to me. Regards Brian
On 10/09/2012 10:45, Christer Holmberg wrote: > Hi Brian, > > Thanks for your review! Comments inline (<christer></christer>). > > (I also include Paul's comments) > > >> Comment: >> ------------- >> >> I have to say that this is a clear example of intentional feature creep >> in an already very complex protocol. I find it scary. I hope the WG has >> thought very carefully about the implications for successful >> interoperability. >> There's only a brief mention of this topic (Section 5.3.5). >> >> In future, I'd like to see this sort of document analysed against the >> RFC-to-be >> draft-iab-extension-recs, which is in AUTH48 right now. > > <paul> > > That is a nice draft! > > SIP already has many extension points. Most of them require standards > action. Now and then, after careful consideration, we add one with looser > requirements. One of those was RFC 3840 which introduced callee capabilities. > That RFC intentionally introduced an a looser extension mechanism that can > work for other SDOs, vendors, and end user organizations that would not use a > mechanism that requires standards action. In retrospect we could have done a > better job on that one - it allows use of feature tags that were > defined for an unrelated purpose, as well as definition of new ones with > minimal semantics. > > This draft is related to that. It is desired because of the widespread > use of back to back user agents in sip deployments - entities that were not > anticipated in the design of sip, that introduce new problems. > (Analogous to the problems introduced by NATs.) The earliest versions > of this draft were extensions in the use of that mechanism. > > The draft has subsequently been changed (in response to prodding by me > and others) to remedy some of the mistakes we made with 3840. It adds a > specification requirement so that the semantics of proxy feature tags will > always be available. And it only allows use of tags that were intended to be > used with it. > > So I think this draft honors draft-iab-extension-recs. > > </paul> > > <christer> > > I have nothing to add to Paul's reply regarding this issue. > > </christer> > > > Regarding interop and 5.3.5: This draft introduces a new extension > *mechanism*. Each newly defined tag is independent of all the others. So > interop considerations need to be dealt with separately for each. > > I guess this could be more specific about which sorts of things must be > discussed in this section of the profile. E.g. > - that the specification should make provision for its own revision > - what should be done if a sought-after tag is not present > - what should be done if a sought-after tag contains an unexpected value > > </paul> > > <christer> > > I could extend the paragraph: > > "If there are specific interoperability considerations that apply to > the feature capability indicator, the feature capability indicator > specification MUST document such considerations. > > Interoperability considerations can e.g. include procedures related > to cases where an expected feature capability indicator is not present, > or where it contains an unexpected value." > > </christer> > > > > ------------------------------------------------- > > >> Minor issues: >> ---------------- >> >> 4.2.1. General >> ... >> NOTE: It is not possible to, as a Feature-Caps header field value, >> convey the address of the SIP entity that inserted the Feature-Caps >> header field. >> >> I cannot parse this sentence. Does it mean this? >> >> NOTE: A Feature-Caps header field value cannot >> convey the address of the SIP entity that inserted the Feature-Caps >> header field. >> >> Or does it mean? >> >> NOTE: A Feature-Caps header field value MUST NOT >> convey the address of the SIP entity that inserted the Feature-Caps >> header field. > > <christer> > > The *first* alternative. I can replace the current note text with your > suggested text. > > </christer> > > > ------------------------------------------------- > > >> For a given fc-value, as defined in section 5.3.1, feature capability >> indicators are listed in a non-priority order, and any order of the >> listed SIP feature capability indicators have the same meaning. >> >> This is very hard to understand. Does it mean this? >> >> For a given fc-value, as defined in section 5.3.1, the order in which >> feature capability indicators are listed has no significance. > > <christer> > > Correct. I can replace the current text with your suggested text. > > </christer> > > > ------------------------------------------------- > > >>> 9. Security Considerations >>> ... >>> Therefore, mechanisms for guaranteeing confidentiality and >>> authenticity SHOULD be provided. >> Is this SHOULD consistent with SIP in general? It seems to me that >> this is a case for "MUST be defined and SHOULD be activated." > > <paul> > > This could be better. In general the security of these tags is > dependent on the security of the sip signaling. > There is little that the design of a particular tag can do to improve > on this. So for the most part the issue is > to avoid specifying and/or using tags that won't be adequately secured > by the signaling. I think this sentence > was trying to address information that might be carried as the value of > a tag. So this would be a matter of > choosing values that don't expose things that ought remain confidential. > > </paul> > > <christer> > > (The SHOULD is taken from RFC 3840.) > > In some cases the information itself might not be confidential, e.g. > because the procedures associated with the feature > will ensure that non-authorized users are able to use the feature. > > Maybe we could say something like: > > "Therefore, if the feature capability indicators provide sensitive > information, mechanisms for guaranteeing confidentiality > and authenticity MUST be provided." > > </christer> > > > ------------------------------------------------- > > >> Nits: >> ----- >> >> I don't think that the labels "Figure 1" to "Figure 6" are useful. >> They are not referred to in the text, and they distract the reader. > > <christer> > > I can remove the labels. > > </christer> > > > ------------------------------------------------- > > > Regards, > > Christer > > > _______________________________________________ Gen-art mailing list [email protected] https://www.ietf.org/mailman/listinfo/gen-art
