Subject: Re: [Sip] Essential Corrections - invfix (was Re: Revised agenda for SIP -- needs more work yet)

From: Robert Sparks <[email-masked]>
Date: Mon, 10 Mar 2008 09:56:18 -0400

On Mar 10, 2008, at 12:52 AM, Jonathan Rosenberg wrote:

> I read through the new invfix draft. I think this new format allows  
> it to be understandable as a standalone document, which is good.
>
> Just a couple of comments:
>
> 1. section 7 (which has the standalone description) has normative  
> language in it. Thus, there is the possibility of conflict with the  
> actual formal spec, which is done via diff. One of the two needs to  
> be made non-normative.

Some conversation has happened around this point on list already -  
could you reply to the thread it was in?

>
> 2. 7.1 and 7.2 are a bit confusing in that they talk specifically  
> about UAC and UAS but of course the transaction machines apply to  
> proxies. Section 7.3 has proxy considerations but is very thin. I  
> think 7.1 and 7.2 should be restructured around client and server  
> transactions

Hrm - is this just a word-choice change rather than a restructure?

>
>
> I personally suspect the actual formal diffs in section 8 will be  
> too hard to apply for anyone to use them; everyone will work off of  
> the descriptive text in section 7. So I don't object to it being  
> there, but I think we should realize it will be ignored and section  
> 7 better be complete and accurate.

Having watched many implementors approach the specs, particularly  
updates to specs, I disagree that 8 will be ignored and that  
interoperability will suffer without it.
I do agree that 7 needs to be complete and accurate. Other than the  
one comment you have above, do you see a place where it isn't?

>
> Thanks,
> Jonathan R.
>
> Robert Sparks wrote:
>> Folks -
>> Lets try to get the Essential Corrections and -invfix- discussion  
>> off the agenda since there are clearly gnarlier things to talk about.
>> I sent in a revision to inv-fix attempting to address Jonathan's  
>> concern about stand-alone readability.
>> Jonathan - is the new format better? Can we go with this?
>> I sent a separate message showing what it would look like to build  
>> a diff against 3261 that we could put in the document. You'll
>> remember that on looking at it, its my opinion that going down  
>> that path is a very bad idea.
>> So far, there's only been one response on list to those messages.
>> Please, everyone (especially those that have expressed strong  
>> opinions in the past), look those over and let us know if we're
>> past the primary concerns, or if we still have something to work  
>> through that needs face time to do so.
>> RjS
>> On Feb 29, 2008, at 5:00 AM, DRAGE, Keith ((Keith)) wrote:
>>> (As SIP WG cochair)
>>>
>>> As Dean already said, we spend 3 hours last night trying to plan  
>>> a 2 1/2
>>> hour session based on input we do not completely have. We don't  
>>> think we
>>> finished, but this was the best we could reach so far in the time
>>> available. Things can move up, but they don't solve the fundamental
>>> problem that we don't have enough time. It was not our idea to  
>>> limit SIP
>>> to a single session - this was forced on us by the ADs.
>>>
>>> Modification of this agenda is more likely to occur not by  
>>> complaining
>>> about the time allocated, but by the presence of technical  
>>> discussion on
>>> list over the next 8 days.
>>>
>>> Some generals:
>>>
>>> We have taken the principle that if discussion time is needed on
>>> chartered items specifically, then they come first, and more
>>> specifically highest priority for any discussion needed to get  
>>> something
>>> out of WGLC and into publication request. This is then followed by
>>> documents that we envisaged could hold up chartered items (in  
>>> this and
>>> other groups) if not discussed. Then follow the other items where  
>>> time
>>> has been requested.
>>>
>>> Some specifics based on comments received so far:
>>>
>>> Domain-certs and eku are in WGLC which ends of Friday next week.  
>>> These
>>> are a dependency from other chartered items where we are ready to  
>>> submit
>>> the publication request. We will not have a view of what  
>>> specifically
>>> needs discussion on these in the meeting until the end of the  
>>> WGLC, when
>>> all the comments are in. Many of the comments made will not need
>>> discussion in the SIP session and can be discussed on list by the
>>> editors after the end of last call. If any comment does need SIP WG
>>> session time, then we will give it on the above basis.
>>>
>>> Outbound is in WGLC and has no time. We are still waiting for  
>>> input to
>>> know if it needs time - not helped by the authors dropping yet  
>>> another
>>> new version in the inbox 3 minutes before the -xx deadline when it
>>> should have been there a month ago. Our current view is to issue a
>>> refreshed WGLC on this following the meeting but that can change.
>>>
>>> Location conveyance is in WGLC and has no time. Again author  
>>> drops new
>>> version in inbox 3 minutes before -xx document deadline. This  
>>> document
>>> is impacted by:
>>>
>>> http://www.ietf.org/internet-drafts/draft-peterson-geopriv- 
>>> retransmissio
>>> n-00.txt
>>>
>>> Which will be discussed in the GEOPRIV group, but if followed  
>>> reverses
>>> the decision we made in the location-conveyance breakout at the last
>>> meeting. We hope the GEOPRIV discussion does not force  
>>> rediscussion in
>>> SIP, but please bear in mind that it could do so.
>>>
>>> RPH in responses is not chartered. 2 meetings back the WG  
>>> expressed a
>>> wish to work on this. The AD pushed back to our request to  
>>> charter. As
>>> the AD makes the decision, it is not chartered and has no  
>>> milestones.
>>> That's why we had the further discussion in the last meeting - where
>>> again we came to no conclusions, and I assume the AD is still
>>> unconvinced. Fundamental problem - convince the AD. Put him in a  
>>> corner
>>> somewhere in Philadelphia and kick hell out of him, but we don't  
>>> need
>>> the SIP session to watch you do that - although it may be  
>>> entertaining!
>>>
>>> Media security requirements is holding up other chartered items  
>>> in both
>>> SIP and AVT. When we considered this for inclusion, we believed  
>>> there
>>> were two items that may need agenda item. Overnight Dean seems to  
>>> have
>>> taken the time away at the moment, but I remain unconvinced that  
>>> this
>>> does not need time.
>>>
>>> This is the media-security requirements milestones:
>>>
>>> Sep 2007    Requirements for media keying to WGLC (Informational)
>>> Nov 2007    Requirements for media keying to IESG (Informational)
>>>
>>> Which provides the requirements for the mechanism in these  
>>> charter items
>>> in SIP.
>>>
>>> Dec 2007    Establishment of secure media sessions using DTLS- 
>>> SRTP to
>>> WGLC (PS)
>>> Feb 2008    Establishment of secure media sessions using DTLS- 
>>> SRTP to
>>> IESG (PS)
>>>
>>> And these chartered items in AVT:
>>>
>>> Dec 2007    Submit in band keying mechanism for SRTP draft for  
>>> Proposed
>>> Standard
>>>
>>>
>>> Regards
>>>
>>> Keith
>>>
>>>> -----Original Message-----
>>>> From: [email-masked] [mailto:[email-masked]] On
>>>> Behalf Of Cullen Jennings
>>>> Sent: Friday, February 29, 2008 5:33 AM
>>>> To: Dean Willis
>>>> Cc: IETF SIP List
>>>> Subject: Re: [Sip] Revised agenda for SIP -- needs more work yet
>>>>
>>>>
>>>> On Feb 28, 2008, at 8:57 PM, Dean Willis wrote:
>>>>
>>>>>
>>>>> On Feb 28, 2008, at 5:00 PM, Jonathan Rosenberg wrote:
>>>>>
>>>>>> 10 minutes on the phone number dichotomy thing isn't going to be
>>>>>> even close enough to cut it. It should be either zero or a more
>>>>>> significant number.
>>>>>>
>>>>>> We have 30 minutes on media security. The only chartered
>>>> item there
>>>>>> is the requiremetns document which I thought was mostly
>>>> done. Why is
>>>>>> there so much time dedicated to this? I would rather move that to
>>>>>> INFO or the identity mess.
>>>>>
>>>>> Me too. But hey, the media security requirements document is
>>>>> CHARTERED. We have permission to work on it and a commitment to a
>>>>> deliverable, with a published milestone. We don't have that
>>>> for INFO
>>>>> or the identity mess (even though I think media security is
>>>> blocked on
>>>>> the identity mess -- our AD currently disagrees).
>>>>>
>>>>
>>>> Dean - I think we must be having some serious
>>>> miscommunications - many times in the past I have had enough
>>>> typos in my emails that no one could understand what I might
>>>> have been thinking but ....
>>>>
>>>> I don't think I said that. The two things I thought I said
>>>> that might have been confused are:
>>>>
>>>> 1) I don't think the E.164 discussion is holding up milestone
>>>> items in MEDIACTRL or SIMPLE
>>>>
>>>> 2) I don't think a problem in some mechanism such as 4474
>>>> should be holding up the media security requirements draft.
>>>> (If I could bold requirements in the previous sentences I would)
>>>>
>>>> I certainly do think it is important that we have a clear
>>>> understanding of how E.164 numbers fit into the overall SIP
>>>> security picture.  Sorry if I said something that made you
>>>> think otherwise.
>>>>
>>>>
>>>> _______________________________________________
>>>> Sip mailing list  https://www.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
>>>>
>>> _______________________________________________
>>> Sip mailing list  https://www.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
>
> -- 
> Jonathan D. Rosenberg, Ph.D.                   499 Thornall St.
> Cisco Fellow                                   Edison, NJ 08837
> Cisco, Voice Technology Group
> [email-masked]
> http://www.jdrosen.net                         PHONE: (408) 902-3084
> http://www.cisco.com

_______________________________________________
Sip mailing list  https://www.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: Mon, 10 Mar 2008 00:52:02 -0400

I read through the new invfix draft. I think this new format allows it 
to be understandable as a standalone document, which is good.

1. section 7 (which has the standalone description) has normative 
language in it. Thus, there is the possibility of conflict with the 
actual formal spec, which is done via diff. One of the two needs to be 
made non-normative.

2. 7.1 and 7.2 are a bit confusing in that they talk specifically about 
UAC and UAS but of course the transaction machines apply to proxies. 
Section 7.3 has proxy considerations but is very thin. I think 7.1 and 
7.2 should be restructured around client and server transactions

I personally suspect the actual formal diffs in section 8 will be too 
hard to apply for anyone to use them; everyone will work off of the 
descriptive text in section 7. So I don't object to it being there, but 
I think we should realize it will be ignored and section 7 better be 
complete and accurate.

Thanks,
Jonathan R.

Robert Sparks wrote:
> Folks -
> 
> Lets try to get the Essential Corrections and -invfix- discussion off 
> the agenda since there are clearly gnarlier things to talk about.
> 
> I sent in a revision to inv-fix attempting to address Jonathan's concern 
> about stand-alone readability.
> I sent a separate message showing what it would look like to build a 
> diff against 3261 that we could put in the document. You'll
> remember that on looking at it, its my opinion that going down that path 
> is a very bad idea.
> 
> Please, everyone (especially those that have expressed strong opinions 
> in the past), look those over and let us know if we're
> past the primary concerns, or if we still have something to work through 
> that needs face time to do so.
> 
> RjS
> 
>> As Dean already said, we spend 3 hours last night trying to plan a 2 1/2
>> hour session based on input we do not completely have. We don't think we
>> problem that we don't have enough time. It was not our idea to limit SIP
>> Modification of this agenda is more likely to occur not by complaining
>> about the time allocated, but by the presence of technical discussion on
>> specifically highest priority for any discussion needed to get something
>> documents that we envisaged could hold up chartered items (in this and
>> other groups) if not discussed. Then follow the other items where time
>> has been requested.
>>
>> Domain-certs and eku are in WGLC which ends of Friday next week. These
>> are a dependency from other chartered items where we are ready to submit
>> the publication request. We will not have a view of what specifically
>> needs discussion on these in the meeting until the end of the WGLC, when
>> Outbound is in WGLC and has no time. We are still waiting for input to
>> know if it needs time - not helped by the authors dropping yet another
>> Location conveyance is in WGLC and has no time. Again author drops new
>> version in inbox 3 minutes before -xx document deadline. This document
>> is impacted by:
>>
>> http://www.ietf.org/internet-drafts/draft-peterson-geopriv-retransmissio
>> n-00.txt
>>
>> Which will be discussed in the GEOPRIV group, but if followed reverses
>> meeting. We hope the GEOPRIV discussion does not force rediscussion in
>> RPH in responses is not chartered. 2 meetings back the WG expressed a
>> wish to work on this. The AD pushed back to our request to charter. As
>> the AD makes the decision, it is not chartered and has no milestones.
>> unconvinced. Fundamental problem - convince the AD. Put him in a corner
>> somewhere in Philadelphia and kick hell out of him, but we don't need
>> the SIP session to watch you do that - although it may be entertaining!
>>
>> Media security requirements is holding up other chartered items in both
>> SIP and AVT. When we considered this for inclusion, we believed there
>> were two items that may need agenda item. Overnight Dean seems to have
>> taken the time away at the moment, but I remain unconvinced that this
>> does not need time.
>>
>> Which provides the requirements for the mechanism in these charter items
>> in SIP.
>>
>> Dec 2007    Establishment of secure media sessions using DTLS-SRTP to
>> WGLC (PS)
>> Feb 2008    Establishment of secure media sessions using DTLS-SRTP to
>> IESG (PS)
>>
>> Dec 2007    Submit in band keying mechanism for SRTP draft for Proposed
>> Standard
>>
>>
>> Regards
>>
>> Keith
>>