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. 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. > 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 PROTECTED] [mailto:[EMAIL PROTECTED] 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 PROTECTED] for questions on current sip >>> Use [EMAIL PROTECTED] 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 PROTECTED] for questions on current sip >> Use [EMAIL PROTECTED] 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 PROTECTED] 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 PROTECTED] for questions on current sip Use [EMAIL PROTECTED] for new developments on the application of sip
