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

From: Suresh Krishnan <[email-masked]>
Date: Fri, 10 Oct 2008 16:44:59 -0400

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

  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"

Nits
====

* Form feed characters missing between Pages

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.

* Maybe you have been asked this question million times before, but are 
these many namespaces really necessary?

 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."

Cheers
Suresh

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

---

From: Cullen Jennings <[email-masked]>
Date: Fri, 17 Oct 2008 13:10:54 -0600

James, could you have a look at the issue below and if possible send a  
reply before next wednesday as I put this draft on the agenda for next  
Thursdays IESG call.

Thanks, Cullen

On Oct 10, 2008, at 2:44 PM, Suresh Krishnan wrote:

> 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.

---

From: "James M. Polk" <[email-masked]>
Date: Fri, 17 Oct 2008 15:18:02 -0500

absolutely

James

---

From: "James M. Polk" <[email-masked]>
Date: Mon, 20 Oct 2008 17:00:51 -0500

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

>  message, for example, with this Resource-Priority header value:

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.

>"Each will be preemptive in nature"

done

>* Form feed characters missing between Pages

my editor doesn't allow these to be inserted

>* 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.

>  jurisdiction serving the same purpose, with the same usage of

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

---

From: Suresh Krishnan <[email-masked]>
Date: Tue, 21 Oct 2008 12:01:29 -0400

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:
> 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
> 
> There are still 40 namespace requests, but the ASCII values changed, and 
> I haven't done all the changes.
> 
> 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..."
> 
>> 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
> 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!
> 
> 
> 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
> 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.
> 
> The changes are mostly deletions, with 3 or 4 other parts that I changed 
> a word or two.
>

---

From: Cullen Jennings <[email-masked]>
Date: Tue, 21 Oct 2008 10:24:18 -0600

> I'm waiting until someone tells me to do something

If you can get the new version in today or tomorrow, please do that.

Thanks, Cullen

---

From: "James M. Polk" <[email-masked]>
Date: Tue, 21 Oct 2008 12:09:02 -0500

>If you can get the new version in today or tomorrow, please do that.

I'm trying - but the tool isn't letting me submit the ID.  First the 
tool tells me I don't have a submission date, or it is in the wrong 
format. Then, when I submit it manually (by adjusting the meta-data 
for the date ) it claims I need to put my given and family name in 
the ID before it will accept my submission.  Gee, I didn't think I 
had to tell any reader who wrote the doc... when did that become a 
requirement? In the ~240 previous IDs I've submitted it was never a 
requirement....

grrrrrrrrrrrrrr!!!!!!!!!!!!

I **HATE** that there is no "I want the tool to accept what I've 
submitted anyway" button...

FYI -- here's the first page of the ID, perhaps someone else can tell 
me what's wrong with this page (which is preventing this submission)?

SIP Working Group                                            James Polk
Internet-Draft                                            Cisco Systems
Expires: April 21st, 2009                              October 21, 2008
Intended Status: Standards Track (as PS)

        IANA Registration of New Session Initiation Protocol (SIP)
                       Resource-Priority Namespaces
                 draft-ietf-sip-rph-new-namespaces-04.txt

Status of this Memo

    By submitting this Internet-Draft, each author represents that any
    applicable patent or other IPR claims of which he or she is aware
    have been or will be disclosed, and any of which he or she becomes
    aware will be disclosed, in accordance with Section 6 of BCP 79.

    Internet-Drafts are working documents of the Internet Engineering
    Task Force (IETF), its areas, and its working groups.  Note that
    other groups may also distribute working documents as Internet-
    Drafts.

    Internet-Drafts are draft documents valid for a maximum of six
    months and may be updated, replaced, or obsoleted by other documents
    at any time.  It is inappropriate to use Internet-Drafts as
    reference material or to cite them other than as "work in progress."

    The list of current Internet-Drafts can be accessed at
    http://www.ietf.org/ietf/1id-abstracts.txt.

    The list of Internet-Draft Shadow Directories can be accessed at
    http://www.ietf.org/shadow.html.

    This Internet-Draft will expire on April 21, 2009.

Copyright Notice

    Copyright (C) The IETF Trust (2008).

Abstract

    This document creates additional Session Initiation Protocol (SIP)
    Resource-Priority namespaces to meet the requirements of the US
    Defense Information Systems Agency, and places these namespaces in
    the IANA registry.

Polk                     Expires April 21, 2009                [Page 1]
Internet-Draft       New SIP RPH Namespaces for DISA           Oct 2008