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

In a message dated 11/16/2004 7:42:29 PM W. Europe Standard Time, 
jmpolk@cisco.com 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