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
[email protected]
https://www.ietf.org/mailman/listinfo/gen-art
