Subject: RE: [Sip] I-D ACTION:draft-ietf-sip-publish-02.txt

From: [email-masked]
Date: Tue, 3 Feb 2004 10:51:47 +0200

Hi Jonathan,

Thanks a lot for the excellent comments. Most of them I will directly fold into -03. Few clarifications below.

Cheers,
Aki

Jonathan Rosenberg wrote:

<snip />

 > * section 3, paragraph 3:
 > 
 > > That is, the steady-state of
 > >    this event package in the absence of, or in addition 
 > to, soft state
 > >    provided through the PUBLISH mechanism
 > 
 > this makes it sound like steady state is a function of the event 
 > packae only. the hard state is a function of the resource uRI and 
 > event package. Indeed, one may think of an event package as merely 
 > sub-resource within the full resource. I wonder if it wouldn't be 
 > useful to come up with a term for this - for example, "scoped 
 > resource" is a combination of a URI and event package, and 
 > identifies 
 > a particular piece of event state.

I don't quite follow,  but I agree the quoted text is rather vague. To me the hard state, or "preconfigured" state is just another source of event state to the composer. The mechanism to set that state might be other than PUBLISH. 

<snip />

 > * section 5.1:
 > 
 > > As with any other SIP message, the PUBLISH mechanism MAY use the
 > >    content indirection mechanism defined in [10].
 > 
 > this statement makes [10] a normative reference, I believe. It is 
 > listed as informative in the references section.

I'm not sure I agree. I've understood the RFC editor's policy so that an informative reference is not required for implementing the RFC. It's an interesting question as to how this relates to RFC 2119 terminology. But I think a MAY makes the feature optional so that it fits the informative reference definition.

<snip />

 > * section 5.3 is out of place. Section 5 is about generating 
 > requests. 
 > the subsections for the most part deal with the specific 4 sub-cases 
 > you identified in 5.1. However, 5.3 talks about setting expirations, 
 > which is something that is actually done for the cases in 5.2, 5.4, 
 > 5.5 and 5.6. I would suggest that eaech of those four 
 > sections rather 
 > describe how the Expires header field is constructed for each case. 
 > That is consistent with having a column in table 1 on 
 > expires. Indeed, 
 > each section should also talk about bodies and etag. Along those 
 > lines, section 5.2 does not actually say that a body has to be 
 > present; it shouold be stated given the importance of this fact from 
 > table 1.

I think the reason for this is that I envisioned a PUBLISH carrying state in some other place than the body. However, I don't know if such a case would ever exist, and other people have also commented on this. I think it is safe to assume that the state is always carried in the body, as opposed to "typically".

I'll change the text in 5.2 accordingly.
 
<snip />

 > * section 5.7 is out of place, since it has nothing to do with 
 > constructing publish at all. indeed, since the note basically says 
 > that this doesnt work, i would suggest removing the section entirely.

I think I agree with you. The separate email thread about querying the state of a particular publication ought to resolve this issue. 

 > It occurs to me that its a huge shame that etags are not 
 > URIs. If they 
 > weree, we would have a rerally neat way to find out the 
 > specific state 
 > of a particular publication - you woould subscribe to that etag. The 
 > next best thing might be to define a header field in the PUBLISH 
 > response that identifies this particular published instance. Hmm, 
 > Contact might even be a sensible choice there... worth discussing. 
 > I'll send a separate email on the topic.

I responded to this separately. 
 
<snip />
 
 > * section 6:
 > 
 > >  PUBLISH requests MUST be processed in the order that they are
 > >    received. 
 > 
 > isnt this only true for requuests with the same r-uri?

Correct. I will add some text to this effect.
 
<snip />

 > * the steps in section 6 omit handling for the case where 
 > there was no 
 > SIP-If-Match header field. step 6 says to check for it, and all the 
 > following steps assume it was there. I would suggest adding a bullet 
 > to step 6 which says, if there was no SIP-If-Match header field, the 
 > ESC creates a new etag, and associates it with as-yet empty event 
 > state. Processing continues in the steps below. This way, you always 
 > exit step 6 with an etag.

The attempt was to make etag generation part of step 9. This way, an entity-tag is generated for each successful publication and returned in 2xx, irrespective of whether the publication was an initial publication, a refresh, or a modification. Indeed, a 2xx to a removal could be treated the same, although such an entity-tag is useless at that point.

So I think it is ok to exit step 6 without an entity tag, as long as step 9 is clear that entity-tags are generated for all successful publications.

 > 
 > * step 8 of section 6:
 > 
 > >  The ESC processes the published event state, typically contained
 > >        in the body of the PUBLISH request. If the request 
 > contains no
 > >        body (when it should contain one), 
 > 
 > i think we need to list the conditions for when it should 
 > contain one. 
 > Indeed, since you are always allowed to publish without a body in 
 > order to refresh or delete, under what conditions is it illegal for 
 > the body to not be there?

I don't think there are any. I will reword and remove that part.

<snip />

 > * step 9:
 > 
 > > The response MUST also contain a SIP-ETag header field for
 > >        which the ESC MUST generate and store a locally 
 > unique entity-tag
 > >        for identifying the publication.
 > 
 > You should clarify that it generates a new one in each response, and 
 > does so for both initial and refreshes. Also, clarify that this etag 
 > replaces the previous, such that the previous etag is no 
 > longer valid 
 > for identifying the publication.

Good point.
 
<snip />

 > * sectiton 11.1:
 > 
 > > Authentication issues are discussed in SIP [2]. The exact 
 > methods for
 > >    creation and manipulation of the ESC authorization policies are
 > >    outside the scope of this document.
 > 
 > you will get dinged on this by Bellovin, guaranteed. He wants to see 
 > statements about baseline mandtory to implement mechahnisms. 
 > Its fine 
 > to say that this mechanism is digest, as mandated by rfc3261.
 > 
 > >  To prevent replay attacks, implementations SHOULD require
 > >    authentication with anti-replay protection. 
 > Authentication issues are
 > >    discussed in SIP [2].
 > 
 > as above.... does this mean digest with next-nonce or are 
 > you talking 
 > sips?
 > 
 > and section 11.4:
 > 
 > > To prevent such attacks, implementations SHOULD, at a minimum,
 > >    provide integrity protection across the To, From, Event,
 > >    SIP-If-Match, Route, and Expires headers and the bodies 
 > of PUBLISH
 > >    requests.
 > 
 > as above, he will ask for a mechanism. This requiurement makes the 
 > choice sips.
 > 
 > Same in 11.5.
 
I see what you are saying. But is it really so that each new method that gets added to SIP needs to explicitly mandate certain security mechanisms? At least going beyond the security considerations in RFC 3261 seems unnecessary, since the properties of PUBLISH are very similar to, say, REGISTER. 

I was hoping we could get by with discussing PUBLISH specific threats, and merely referencing relevant parts of RFC3261 when it comes to mitigating those threats.

Cheers,
Aki

<snip />

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [email-masked] for questions on current sip
Use [email-masked] for new developments on the application of sip

---

From: Jonathan Rosenberg <[email-masked]>
Date: Wed, 04 Feb 2004 00:54:24 -0500

[email-masked] wrote:

> Cheers, Aki
>>> That is, the steady-state of this event package in the absence
>>> of, or in addition
>> to, soft state
>> identifies a particular piece of event state.
> 
> I don't quite follow,  but I agree the quoted text is rather vague.
> To me the hard state, or "preconfigured" state is just another source
> of event state to the composer. The mechanism to set that state might
> be other than PUBLISH.

Right. I agree with that. Let me try again. Requoting the paragraph:

    PUBLISH requests create soft state in the ESC. This state has a
    defined lifetime and will expire after a negotiated amount of time,
    requiring the publication to be refreshed by subsequent PUBLISH
    requests. Local policy at the compositor may in turn define hard
    state for a particular event package. That is, the steady-state of
    this event package in the absence of, or in addition to, soft state
    provided through the PUBLISH mechanism. Setting this hard state or
    configuring the composer policy is out of the scope of this
    specification.

The words "hard state for a particular event package" read to me like it 
meant that hard state was defined on a package by package basis. But, 
its not. There would be hard state generally for a particular 
URI/package basis. So, I'd suggest:

     There may also be hard state provisioned for each resource for
     a particular event package. This hard state represents the resource
     state that is present at all times, and does not expire.

My other comment was that the concept of "for each resource for each 
package" is a common concept, for which I was looking for a term to define.

> I'm not sure I agree. I've understood the RFC editor's policy so that
> an informative reference is not required for implementing the RFC.
> It's an interesting question as to how this relates to RFC 2119
> terminology. But I think a MAY makes the feature optional so that it
> fits the informative reference definition.

No - Keith is right in his note. Think of it this way - would the 
feature interop if, one day, the referenced I-D evaporated and people 
implemented it differently? In this case, no. If they chose to implement 
the content indirection, and there was no spec, they would do it 
differently and there would be no interop.

I would just drop the text to avoid the dependency.

>> requests. the subsections for the most part deal with the specific
>> 4 sub-cases you identified in 5.1. However, 5.3 talks about setting
>> expirations, which is something that is actually done for the cases
>> in 5.2, 5.4, 5.5 and 5.6. I would suggest that eaech of those four
>>  sections rather describe how the Expires header field is
>> constructed for each case. That is consistent with having a column
>> in table 1 on expires. Indeed, each section should also talk about
>> bodies and etag. Along those lines, section 5.2 does not actually
>> say that a body has to be present; it shouold be stated given the
>> importance of this fact from table 1.
> 
> I think the reason for this is that I envisioned a PUBLISH carrying
> state in some other place than the body. However, I don't know if
> such a case would ever exist, and other people have also commented on
> this. I think it is safe to assume that the state is always carried
> in the body, as opposed to "typically".

Yes.

>> * the steps in section 6 omit handling for the case where there was
>> no SIP-If-Match header field. step 6 says to check for it, and all
>> the following steps assume it was there. I would suggest adding a
>> bullet to step 6 which says, if there was no SIP-If-Match header
>> field, the ESC creates a new etag, and associates it with as-yet
>> empty event state. Processing continues in the steps below. This
>> way, you always exit step 6 with an etag.
> 
> The attempt was to make etag generation part of step 9. This way, an
> entity-tag is generated for each successful publication and returned
> in 2xx, irrespective of whether the publication was an initial
> publication, a refresh, or a modification. Indeed, a 2xx to a removal
> could be treated the same, although such an entity-tag is useless at
> that point.
> 
> So I think it is ok to exit step 6 without an entity tag, as long as
> step 9 is clear that entity-tags are generated for all successful
> publications.
> 

Step 8 requires an entity tag to be defined, however.

>> you will get dinged on this by Bellovin, guaranteed. He wants to
>> see statements about baseline mandtory to implement mechahnisms. 
>> Its fine to say that this mechanism is digest, as mandated by
>> rfc3261.
>> 
>> as above.... does this mean digest with next-nonce or are you
>> talking sips?
>> 
>> and section 11.4:
>> 
> I see what you are saying. But is it really so that each new method
> that gets added to SIP needs to explicitly mandate certain security
> mechanisms? At least going beyond the security considerations in RFC
> 3261 seems unnecessary, since the properties of PUBLISH are very
> similar to, say, REGISTER.

I have made this same comment in past discussions of specs going through 
iesg. However, the security ADs believe strongly in reptition of 
security requirements in specifications. Trust me, you WILL get dinged 
on this. It is much easier to just add text stating the same normative 
requiremetns as in rfc3261, then to get a discuss during iesg evaluation.

-Jonathan R.

-- 
Jonathan D. Rosenberg, Ph.D.                600 Lanidex Plaza
Chief Technology Officer                    Parsippany, NJ 07054-2711
dynamicsoft
[email-masked]                     FAX:   (973) 952-5050
http://www.jdrosen.net                      PHONE: (973) 952-5000
http://www.dynamicsoft.com