Re: [Gen-art] Gen-ART review of draft-ietf-sip-rph-new-namespaces-03.txt

[Suresh Krishnan <[e-mail]>]

Hi James,
   Your proposed fixes address all the issues I raised in my review. 
Thanks for taking care of these quickly.

Cheers
Suresh

James M. Polk wrote:
> Suresh
> 
> Thank you for the review, and I'm sorry I hadn't replied earlier.  My 
> real job had recently thrown me for a loop, and I'm still recovering 
> from that.  I hope that won't happen again!
> 
> I also discovered a few changes that should have happened when I reduced 
> the list of namespaces from 50 to 40 (between the last to revs of the 
> ID). I apologize for not catching these - but I did thanks to Suresh's 
> review.
> 
> Comments in-line
> 
> At 03:44 PM 10/10/2008, Suresh Krishnan wrote:
>> I am the assigned Gen-ART reviewer for
>> draft-ietf-sip-rph-new-namespaces-03.txt
>>
>> For background on Gen-ART, please see the FAQ at
>> <http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html>.
>>
>> Please resolve these comments along with any other Last Call comments
>> you may receive.
>>
>> Summary: Almost ready for publication but I have a few comments.
>>
>> Major
>> =====
>>
>> * The draft assumes some kind of ordering requirement between 
>> namespaces. From my reading of RFC4412, this is not the case.
>>
>> "Thus, a message (or a call) with the following Resource-Priority
>>  header value:
>>
>>  dsn-000001.8
>>
>>  for example, MUST NOT ever receive preferential treatment over a
>>  message, for example, with this Resource-Priority header value:
>>
>>  dsn-000010.0
> 
> In the movement from -02 to -03, I changed the new namespace request 
> structure from
> 
>       dsn-000000 through dsn-000032,
> to
>       dsn-000000 through dsn-000009 plus
>       drsn-000000 through drsn-000009 plus
>       rts-000000 through rts-000009 plus
>       crts-000000 through crts-000009
> 
> There are still 40 namespace requests, but the ASCII values changed, and 
> I haven't done all the changes.
> 
> The IANA section had the right namespaces.
> 
> What this means is dsn-000010 doesn't exist any more, therefore needed 
> to be changed. In attempting to rewrite what I had, which was only 
> restating the point of section 8 of RFC 4412, I soon realized section 8 
> shouldn't be restated, because it is right the way it is written, and 
> restating it could lose interpretation between the two documents.
> 
> Therefore, my conclusion is to remove the inserted text (i.e., from what 
> you start with "Thus..." all the way to just before the paragraph that 
> begins with"The dash..."
> 
> I believe leaving anything in that makes any of these points in these 
> few paragraphs is poorly written, and shouldn't restate what is in RFC 
> 4412.
> 
> 
>>  because they are two difference namespaces"
>>
>> e.g.
>>
>> Consider an RP actor that supports both the namespaces, dsn-000001 and 
>> dsn-000010. It could maintain an ordered list which contains
>>
>> dsn-000001.9
>> dsn-000001.8
>> dsn-000010.9
>> ...
>> dsn-000010.0
>>
>> and this is a valid priority order according to section 8.2 of 
>> RFC4412. Given this, why would this be considered invalid behavior if 
>> dsn-000001.8 DID receive preferential treatment over dsn-000010.0? 
>> This might be a major misunderstanding on my part. If so please 
>> correct me.
>>
>> Editorial
>> =========
>>
>> * Introduction
>>
>> Replace
>> "Each will be preemption in nature"
>> with
>> "Each will be preemptive in nature"
> 
> done
> 
> 
>> Nits
>> ====
>>
>> * Form feed characters missing between Pages
> 
> my editor doesn't allow these to be inserted
> 
> 
>> Opinion(feel free to ignore)
>> ============================
>>
>> * Why so many 0's in the name of the namespace? It is really easy for 
>> someone to miss a 0 or two.
> 
> This is exactly what the customer (DISA) wants because most of their 
> very large network is based on ISDN, and the 0s are included there.  
> They felt they didn't want the possibility of a tech misinterpreting 
> different values (perhaps upon translation) when moving from ISDN values 
> and SIP values.
> 
> I tried quite hard to talk them out of this idea, that it can easily be 
> something that is programmed into whatever analyzer display they use. 
> But I was shot down in flames -- pretty bigtime!
> 
> 
>> * Maybe you have been asked this question million times before, but 
>> are these many namespaces really necessary?
> 
> They want to be able to have these namespaces for use between military 
> branches (army, navy, air force, marines, coast guard), whether the 
> units are the size of the military branch, or a single unit within any 
> branch, or a multi-branch unit of various branches).  This really does 
> beg for a larger number that what most would consider normal -- but 
> given our military's size, they don't want to come asking for new 
> namespaces every couple of years when they've figured out they need more.
> 
> 
>> From RFC4412
>>
>> "Jurisdictions SHOULD
>>  attempt to reuse existing IANA registered namespaces where possible,
>>  as a goal of this document is not to have unique namespaces per
>>  jurisdiction serving the same purpose, with the same usage of
>>  priority levels."
> 
> hopefully, this is the last time we will hear from DISA for namespaces; 
> though I know of one other group within the US gov that will likely want 
> namespaces - but that group isn't ready to ask for more at this time.
> 
> Now, that said - should I submit -04 with these minor changes before 
> Thursday's meeting?
> 
> The changes are mostly deletions, with 3 or 4 other parts that I changed 
> a word or two.
> 
> I also corrected the middle 20 namespaces listed at the beginning of 
> section 2.
> 
> I'm waiting until someone tells me to do something
> 
> James
> 
> 
> 
>> Cheers
>> Suresh
> 

_______________________________________________
Gen-art mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/gen-art