Subject: Re: [Sip] -resource-priority-05.txt: Comments and Recommendations (1)

From: [email-masked]
Date: Wed, 17 Nov 2004 08:03:57 EST

In a message dated 11/16/2004 7:42:29 PM W. Europe Standard Time, 
[email-masked] writes:

> 
> 
> I removed any comment about dependency because there may be a dependency in 
> a domain - based on local policy, and this document should not make any 
> comment that could contradict local policy.
> 
> >[MAP] What I think is needed is a very clear statement something like 
> "neither 
> >this document nor namespaces specify the interrelationship or interworking 
> >between namespaces, such as mapping from one namespace to another at 
> >domain boundaries".
> 
> What you have above is unnecessary. If the document does not state a 
> dependency, there is not one defined.
> 
> 
> >[MAP] As a result, the first bullet in Section 7.1, which states "There 
> MUST be 
> >one order of priorities a SIP element has to process to", while talking 
> >about multiple namespaces in a message, seems to be wrong (or 
> misunderstood),
> 
> It is not wrong, and I'm sorry if it is misunderstood.
> 
> The section is about *ordering* of namespaces, and gives clear examples of 
> ordering that is in line with this specification (to be) and clear examples 
> of ordering that is not allowed in this specification (to be).
> 
> >  [MAP] since it seems to require something about the relationship.
> 
> no it does not. It either does, or it does not - there is no "seems".
> 
> >[MAP] In fact the example following this bullet list is trying to say 
> something 
> >about the "acceptable" ways that the SIP element may process multiple 
> >namespaces.
> 
> That it does, as it is a violation to reorder priority values just because 
> another namespace is introduced. It primarily gives examples of how 
> multiple namespaces can be interleaved in acceptable and unacceptable orders.
> 
> >[MAP] The part about what is "not acceptable" is not needed.
> 
> I do not agree
> 
> >[MAP] The examples of incorrect order within each individual namespace are 
> not 
> >allowed even without multiple namespaces.
> 
> Well, how many coders have you spoken or emailed with that understood this 
> from the previous version(s)? I'll bet none. I have fielded many such 
> communications - and in each given them an explanation just like what is in 
> 7.1 and it becomes clear fairly quickly what was meant in previous versions 
> (that was not explained well enough).
> 
> 
> >[MAP] Since the document should say that it does not address interworking 
> >between namespaces, it should not contain this material.
> 
> giving examples to clarify a known area of confusion is a good thing - and 
> will stay in the document.
> 
> 

[MAP] The above results in a serious contradiction. You agree that the 
document should not describe dependencies, then include material that certainly 
describes dependencies (what combinations are and are not allowed). This will 
confuse more readers into thinking that there are some dependencies.

> 
> 
> it will not be deleted, though it might be modified to add or clarify meaning
> 
> 

[MAP] It's too bad that you're taking the position that you have the final 
say on what is and is not included in the document regardless of the comments 
and results of any e-mail discussion. As far as I'm concerned, you must get the 
WG consensus for anything that you added in -05 in order to retain it in -06. 
Contrary to what Jon Peterson stated at the meeting, RFC2418 defines the 
responsibilities of the editor as follows:

   Most IETF working groups focus their efforts on a document, or set of
   documents, that capture the results of the group's work.  A working
   group generally designates a person or persons to serve as the Editor
   for a particular document.  The Document Editor is responsible for
   ensuring that the contents of the document accurately reflect the
   decisions that have been made by the working group.

Mike

_______________________________________________
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: "James M. Polk" <[email-masked]>
Date: Wed, 17 Nov 2004 14:36:16 -0600

At 08:03 AM 11/17/2004 -0500, [email-masked] wrote:
>document should not describe dependencies, then include material that 
>certainly describes dependencies (what combinations are and are not allowed).

Mike, pay attention to the ordering of two namespaces in the section - 
there are ZERO dependencies between namespaces, just that the order within 
each namespace MUST be maintained regardless of where one value from one 
namespace is places in relative priority order to one or more from another 
namespace. Implementors MUST have one order - no matter how many namespaces 
are supported at a server/endpoint - to relieve confusion of which is 
prioritized over or under another. This is the same rule that applies 
within a namespace: there MUST be one order of priority, period (No 
wildcards) to ensure interoperability.

>This will confuse more readers into thinking that there are some 
>dependencies.

Because it is confusing you does not mean it is confusing others. Every 
single coder I've talked to on this subject understands once they have seen 
these examples. That makes them worthy for inclusion.

>say on what is and is not included in the document regardless of the 
>comments and results of any e-mail discussion.

This email discussion is from you, not from a rough consensus of the list.

>As far as I'm concerned, you must get the WG consensus

The IETF mantra is "rough consensus and running code"

You don't represent rough consensus - despite taking over the microphone 
last week

>  for anything that you added in -05 in order to retain it in -06.

Are you saying I cannot submit a document without getting consensus from 
the list?

>Contrary to what Jon Peterson stated at the meeting

Contrary to what an Area Director said to you in a meeting.... was that 
before or after you threatened the IETF with US Government force if the 
IETF didn't comply with your demands?  remember - about 15 people heard you 
do this

>, RFC2418 defines the responsibilities of the editor as follows:
>

If you feel this way, you have a right to complain to the WG chairs

>Mike

cheers,
James

                                *******************
                 Truth is not to be argued... it is to be presented