Re: [RPRWG] IPoRPR initial draft
Title: IPoRPR initial draft
Hi Glenn,
I think it would really help readability if you can find
a
way to put the PHB names in...just maybe in
parenthesis
or even on the line following the DSCP. All that
is
needed is something like:
110000 -
EF
xxxxxxx - AF11, etc.
Otherwise, the reader would be forced to have a copy of
the DiffServ RFC handy in
order to understand this table.
Yes, a clarification with respect to what the
table
applies to is needed. In fact, you might need a
second
table to talk about L-LSPs since they encode 3
levels
of drop precedence in the EXP bits for AF which then
need to be mapped to the 2-levels supported in
802.17.
I think it would be better to reword the security
section
as follows.
"This draft does not introduce any new security
concerns
for IEEE 802.17 networks. Some of the existing
vulnerabilities
of IEEE 802.17 networks include:
...".
Anoop
Anoop,
On Table 3 we could not really fit the PHB in the ASCII
table without making it look too squished, so it was left
out.
On LSPs, do you simply want to note that mapping
applies to E-LSPs?
And the security section is intentionally thick since
we cannot say there are no risks. But perhaps the line you are looking for
is the second sentence in item 4 which should be the closing paragraph of
section 7.
Cheers,
Glenn
Hi Glenn, Mark,
In Table 3, I think it would be useful to also have
the PHB name alongwith the DSCP since
the
DSCP values are hard to remember...e.g.
000000 (BE), xxxxxx (AF11) ,etc., in the
first
column of the table.
In Sec 5.1.1, I think a distinction needs to be
made
for E-LSP and L-LSP. With L-LSPs only the
drop
precedence is encoded in the EXP bits.
I'm curious as to why the draft has such a
detailed
security considerations section even though by
itself
the draft doesn't introduce any new security
concerns.
At a minimum, I think a statement to that effect should
appear in the security
section.
Anoop
Thanks David,
We can fix most of these I think.
Some of them though (e.g., the sections with no section
numbers) are part of the IETF front/back matter and cannot be changed (without
changing their style).
Cheers,
Glenn.
Glen,
I got of a few of the excessive capitalization, but I
suspect
not all.
The 802.3 environment seems very hazardous: everyone
there seems
to get a sticky caps key(:>).
Its on the attached pdf. Feel free to discuss, call me
into the
meeting, or forward as appropriate.
DVJ
David V. James
3180 South Ct
Palo Alto, CA 94306
Home:
+1.650.494.0926
+1.650.856.9801
Cell:
+1.650.954.6906
Fax: +1.360.242.5508
Base:
dvj@alum.mit.edu
Folks,
The first draft of the IPoRPR basic mapping is
attached.
This version is slightly different from the IETF
officially posted version <draft-ietf-iporpr-basic-00.txt> -- there are
some minor corrections to tables 2 & 3. As a result, I'd prefer the
group reviews this version.
Note that the primary review mechanism to submit
comments to the IETF IPoRPR mailing list -- and you must be a member to post
(and get past the spam filter :-).
There is currently no plan for an IPoRPR WG meeting
at IETF 63 in Paris.
However, there is agenda time at the IEEE 802.17
meeting in San Francisco next week to discuss this draft.
Cheers,
Glenn
<<draft-ietf-iporpr-basic-00a.html>> <<draft-ietf-iporpr-basic-00a.txt>>