BTW Eric, my views here are just comments and shouldn't be taken as
if these are showstoppers for your doc's progression.
James
At 02:38 PM 10/28/2010, James M. Polk wrote:
At 02:06 PM 10/28/2010, Eric Rosen wrote:
James> perhaps this needs to be stated (that the Type 4 is created by this
James> doc for your purpose)?
I think the doc already makes this clear, maybe I'm not sure what you are
asking.
you may be right (that I'm not being clear). This is all about the
wording in Section 3. You doc creates and IANA registers this Type 4
message (in the second paragraph), but you state in the doc that
'...(this) may be used to assign a v6 customer to a P-tunnel in
a PIMv4 SP.'
To me, and this has been beaten into me over the 340+ IDs I've
written, that anytime one uses lowercase "may", it actually needs to
be replaced with "can". If I do that in my head, this usage of a
Type 4 is wishy-washy, in other words, something else is obviously
available to do the same thing, otherwise the "can" meaning would
have been stronger - like a "SHOULD be used to" or "MUST be used to"
or even "will be used to", or the easiest "is used to".
And yes, I see that in the first paragraph you state that in some other doc a
'...Type 1 may be used to to assign a v4 customer to a P-tunnel
in a PIMv4 SP.'
so the wording is consistent, but I still don't like the lowercase
use of a 2119 word, especially "may", because that means there are
alternatives known, but here, they are not stated.
James> You can probably imagine how many SIP and RSVP protocol extensions
James> there are (70+ and about 20 respectively off the top of my head), and
James> yet every one of them have to state "Session Initiation Protocol
James> (SIP)" and "ReSource ReserVation Protocol (version-1) (RSVPv1)" the
James> first time they appear, no matter how big the community of interest
James> is.
And this makes sense to you?
no, but it is the way it has been and continues to be, at least in
the areas I'm authoring in. So you can take this one with the grain
of salt, because those of mine that have slipped through to the
RFC-Editor have always been caught there, but now that I've pointed this out...
Okay, I will expand the occurrence of "S-PMSI" in the abstract.
On the issue of the maximum UDP packet size, I think that is an
implementation issue and I don't think it is appropriate to raise it in this
document.
It would normally be ok, but your doc says effectively "go ahead and
stick as many Joins as you want and something/where else will deal
with the consequences"... and that doesn't make a good spec to
me. I recommend that at least a warning of link MTU causing
fragmentation be mentioned as a potential inefficient side effect.
James
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf