[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Ecrit] ECRIT Status Update - December 2008 (esnet namespace)
Hi James,
I understand that you are quite excited about your work and that you want to
progress it as fast as possible. That's good. Marc and I, however, have to
consider all the other documents as well (e.g., PhoneBCP and framework).
In case you have not noticed, you are not treating me a bit unfair.
I tried my best to catch up in the meanwhile and will respond to the raised
issues in separate mails.
Ciao
Hannes
>-----Original Message-----
>From: James M. Polk [mailto:jmpolk at cisco.com]
>Sent: 02 January, 2009 21:55
>To: Tschofenig, Hannes (NSN - FI/Espoo); Hannes Tschofenig; ECRIT
>Subject: RE: [Ecrit] ECRIT Status Update - December 2008
>(esnet namespace)
>
>At 03:39 AM 12/31/2008, Tschofenig, Hannes (NSN - FI/Espoo) wrote:
>>Hi James,
>>
>> >At 05:53 PM 12/30/2008, Hannes Tschofenig wrote:
>> >>8) draft-ietf-ecrit-local-emergency-rph-namespace
>> >>
>> >>We had some discussions about this document triggered by mails
>> >>around
>> >>IETF#73 asking for the purpose and the scope.
>> >>I read through the e-mail exchange but I need to read through some
>> >>RFCs/drafts as well in order to summarize the topic.
>> >>
>> >>A few folks have provided feedback (James, Brian, Janet,
>Keith) but
>> >>more reviews from the rest of the group would be useful.
>> >>
>> >>Action item: Hannes to summarize the discussions and to draw
>> >a conclusion.
>> >
>> >Hannes - why are you artificially creating such a high hurdle for
>> >this ID to progress?
>>
>>Summarizing a discussion is not "a high hurdle".
>
>if you only said you would summarize this, then I wouldn't be
>writing anything here. You also include this comment above
>
> "...but more reviews from the rest of the
> group would be useful..."
>
>when did 6 or 7 reviewers saying one thing (in the positive)
>and 1 saying another thing (in the "I don't understand") mean
>anything other than _rough_consensus_?
>
>What we are hearing you say is "until I (Hannes) understand
>and agree with this, this ID will not progress".
>
>Jon admitted on the mic in Minn that he's "not the biggest fan
>of RP"... which is widely known, yet he decided to say into
>the mc in Minn that he is not going to fight this effort either.
>
>SIP has one defined way to mark the priority of a request -
>and that's in RFC 4412 (Resource-Priority).
>
>You have said a number of times that the To: field can be
>used, that the R-URI value can be used... claiming that using
>the RP header would add another meant of marking the priority
>of a request.
>
>Yet the SIP WG chair has confirmed to you in front of several
>others (including me, Brian, Marc (your co-chair)) that SIP
>has one, singular way to priority mark its requests - and that
>is defined by RFC 4412 (Resource-Priority).
>
>Anything else, (i.e., any other way of marking the priority of a SIP
>request) would in fact be an additional way SIP entities would
>have to be coded to perform this function.
>
>You have repeatedly refused to acknowledge that fact. I
>believe that is at least most of why you are resisting this ID
>from becoming a WG item, and are continuing to find
>manufactured faults with it.
>
>You are standing alone in your views, my friend - which is
>contrary to IETF procedures of rough consensus, and I ask that
>you agree with the core philosophy of the IETF that rough
>consensus makes decisions in the IETF, and move on.
>
>
>> >
>> >The WG hummed for this ID to become a WG item in Dublin.
>>
>>I know. Like the group did with a number of other items.
>>Officially, the document is not a WG item yet given that we would
>>require the charter to change as mentioned at the last meeting.
>
>Yeah, and that recharter - for whatever reason, didn't happen
>in the last 5 months since the Dublin meeting why?
>
>How long before the WG can expect this recharter? (a year?)
>
>
>> >
>> >There hasn't been one other opinion contrary to this (save for
>> >yours) on the list or at the Minneapolis meeting.
>>
>>Well. I raised several issues which I would like to summarize.
>
>you raised many issues, nearly all of which had the answer
>"this is not how SIP works", but you didn't seem to like that answer.
>
>>To pick one "PSAP callback" where there does not seem to be
>agreement,
>>referencing Brian:
>>http://www.ietf.org/mail-archive/web/ecrit/current/msg05686.html
>
>"PSAP Callback" - hmmmmmm..... let's see....
>
>You have a requirement that "priority" needs to be e2e in one
>direction but not the other?
>
>Where's that written down?
>
>Do you believe there's a chance in heck that all SIP UAs will
>have the code in them to process the priority of this PSAP Callback?
>
>Funny, that's the same argument that you gave me that
>(paraphrasing) "because most UAs will not have RFC 4412 code
>in them, why are you
>(James) pushing this solution on ECRIT?"
>
>the sword cuts both ways.
>
>This ID doesn't have the UAC needing to set the RP within the
>INVITE. Nor does it prioritize the RP in the received INVITE either.
>
>Therefore PSAP Callback is pointless at this point in time for
>UAs at all, right? It's more for the ESNET and perhaps one
>admin domain out from that network.
>
>Look at figure 1 of this ID, and tell me where (i.e., which
>element(s) in which domain(s)) PSAP Callback is mandatory to
>set the priority of that Callback INVITE?
>
>
>
>> > Therefore,
>> >it is impossible to conclude with evidence that anyone
>other than you
>> >are delaying this progression.
>>
>>Delaying? Given that we have to change the charter first
>
>hmmm.... again... that decision was made 2 meetings ago. How
>much longer should the WG have to wait for this recharter?
>
>>before this
>>document can actually be picked up as an item (like the other
>documents
>>as well) I am not delaying anything here.
>
>ok, so who is writing the recharter (if not the WG chair) and
>why are they taking so long? Let me know who this other person
>is and I'll ask them to inform the WG themselves (directly)
>with the ETA on this.
>
>
>>Getting the new charter approved is only possible if we are able to
>>finish our main items, as Jon says. Despite our pushing Phone BCP and
>>Framework are still not finished.
>
>yet, I can't help but notice that both
>http://tools.ietf.org/wg/ecrit/draft-ietf-ecrit-location-hiding-req/
>and
>http://tools.ietf.org/wg/ecrit/draft-ietf-ecrit-specifying-holes/
>are recent additions to the ECRIT charter...
>
>indeed, these two IDs weren't event though about when phoneBCP
>and Framework were WGLCd the first time, yet they made the
>charter within a few months from their hum by the WG...
>
>this is inconsistent with the stance you are taking now with
>the esnet namespace ID, Hannes.
>
>
>> >
>> >Many have expressed in email to the list, and in person at
>> >Minneapolis to you that you are not understanding the topic as
>> >much as you believe (SIP signaling and SIP header usage, and
>> >this includes the SIP chair that has given you his opinion in
>> >front of others), and each of the rest of us (that have voiced
>> >an opinion) are in unison in our understanding (and have
>> >attempted nearly countless times to explain how you have a
>> >misunderstanding of SIP communications).
>>
>>Maybe I don't understand this particular item well enough. If I don't
>>understand it given that I am working in this space already for many
>>years gives me the impression that maybe I am not the only one.
>
>So, bluntly, how much do you understand about SIP signaling
>and headers?
>
>This is the question. WG chairs do not need to understand everything
>within their WG perfectly, but need to trust a select few that do
>understand the topics you don't. Is Keith, the SIP WG chair, not a
>good enough person to trust in this instance?
>
>And from the point of view of "...maybe I am not the only one..."
>isn't it also the burden of those that do not understand something to
>voice their opinions at the meeting mic or on the mailing list (else
>they are to be considered in agreement with a proposal)?
>
>I believe this is another IETF procedure you are not adhering
>to on this case.
>
>>At least
>>in the past I was never wrong with such an assumption.
>
>Unless there is another who says so on the public list, you have no
>proof this is the case here.
>
>
>>I don't think it can be wrong to ask questions about documents we have
>>in the group (even if they appear irrelevant to the authors of the
>>mechanism as he knows it better than anybody else).
>
>Hannes, many individuals answered your questions as "you're wrong" or
>"you're not understanding SIP signaling" during the threads during
>the Minn IETF meeting. If everyone who has responded to you is
>saying "you're not right in this opinion", what does it take for you
>to consider the possibility *each* of them is right, and you are not?
>
>>
>> >Furthermore - your co-chair does not agree with you, and
>> >believes as others do that this ID is needed, necessary and
>> >wants it to progress
>> >- including other SDOs and organizations (NENA for one) that
>> >want to reference this document as an RFC.
>>
>>I am actually participating in various NENA conf. calls and have
>>participated in discussions around resource priority for
>>citizen-to-authority emergency calls. I have not heard you on those
>>calls.
>
>not being an active participant does not mean I don't understand the
>issues. Besides, I trust Brian Rosen here, the NENA WG chair (since
>the WG formed), who is one of the ones telling you that you don't
>understand what you are saying wrt RP esnet namespace ID.
>
>
>>In short, I am not delaying -- I am trying to understand. No reason to
>>worry.
>>
>>Ciao
>>Hannes
>>
>> >
>> >James
>
_______________________________________________
Ecrit mailing list
Ecrit at ietf.org
https://www.ietf.org/mailman/listinfo/ecrit