Date: Wed, 9 Jul 2008 09:41:03 -0700 (PDT)
From: The IESG <iesg-secretary(_at_)ietf(_dot_)org>
Message-ID:
<20080709164103(_dot_)7733D28C1AF(_at_)core3(_dot_)amsl(_dot_)com>
| The IESG has received a request from an individual submitter to consider
| the following document:
|
| - 'IANA Considerations for the IPv4 and IPv6 Router Alert Option '
| <draft-manner-router-alert-iana-03.txt> as a Proposed Standard
Two comments.
First (last sentence of section 2):
It is unclear why nesting levels begin at 1 for IPv4 (described in
section 1.4.9 of [RFC3175]) and 0 for IPv6 (allocated in section 6 of
[RFC3175]).
isn't the kind of sentence that belongs in a doc like this. If the
authors are mystified, just omit the sentence, including it adds nothing.
Better, of course, would be to ask, and discover, and provide an
explanation.
But, this doc deletes aggregation level 0 from IPv6 anyway, which makes
all of this even stranger.
Second (section 4, security considerations):
Yet, as discussed in RFC 4727 [RFC4727] production networks do not
necessarily support the use of experimental code points in IP option
headers. The network scope of support for experimental values should
carefully be evaluated before deploying any experimental RAO value
[...]
This is the kind of thing we might have expected to see in a security
considerations section 15-20 years ago, when the network was a nice kind
friendly environment, where all the players would take great care not
to do anything that might cause a problem.
These days, if "the use of unsupported experimental code points" has the
"potential to disrupt the stable operation of the network" then that would
be something worthy of a CERT advisory and hasty code fixes by whatever
vendors are supplying the systems that would be disrupted.
It is never safe to assume that any random value won't appear in any
random field of a packet, and for just the same reason, there's no
reason for anyone to avoid using any particular value. This security
consideration paragraph should simply be deleted.
The following one is more just common sense, wrt general management, and
also exposes no security issues, and should probably be deleted as well.
All of this (except the first paragraph which is fine) smells very much
like an attempt to provide some meaningful security considerations section
just because meaningful security considerations sections are required
(by someone, for something) even where it's absurd to imagine any security
issues that can really apply.
If real security considerations were to be discussed in a doc that just
establishes an IANA registry, and does no more than that (doesn't create
new values with meanings that didn't already exist, etc) then about all
that could be really said would be abut spoofing messages to IANA
causing bogus values to be allocated, and/or adequately protecting the
registry content so it is known that what is observed there is in fact
correct - but none of that is really worth having in every RFC that
happens to create a new IANA object.
Personally I'd prefer to simply see the meaningless security considerations
section removed completely from this doc (but of course, there's a "rule"
that says it must always be present, even when it is stupid, and obeying the
rules is, of course, far more important than producing quality documents...)
kre
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf