Fernando,

may I suggest you keep ranting to a minimum.

>>>> That aside, this document aims to update RFC 2460. Where else should
>>>> that be done, if not in 6man??
>>> 
>>> That's a technicality. What's more important is that the relevant expertise 
>>> is in 6man.
>> 
>> when this document was presented in 6man at IETF84, there were suggestions 
>> that a more generic
>> document could be written. e.g. in intarea.
> 
> We have beaten this one to death -- but you still bring this one up:
> Most folks agreed that a general document (in *addition* to this one)
> would be useful, but this one would be valuable and *needed*.

<chair>
that is not evident from this thread, nor the minutes from IETF84.
</chair>

[...]

> In a more broader sense, I wonder what's the point of having a
> "maintenance" working group when it looks like you seem to do anything
> to avoid formally updating existing standards (this is not the first
> instance of that).

yes, and I think it is also our responsibility to limit too much tinkering.
in this case fixing what appears to be a marginal problem, in descriptive
text of RFC2460.

[...]

> Besides, you'll realize that the document is a bit larger than
> one-paragraph long. And there's much more valuable information that
> would could put in an errata, or a node requirements update.

"It is recommended to use unpredictable values in protocol fields"?

the above is good advice, I do not think it necessary to publish a document
to update non-normative text in 2460.

cheers,
Ole
--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email protected]
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

Reply via email to