[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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