Thomas Narten wrote:
Some of other standards track documents have extended ND. Some of
these extensions should be mentioned in this document, as some of them
seem to actually update this document.


I don't see how we can do that in a Draft Standard, since those
documents are presumably only Proposed Standard.


I think some of them can be mentioned in a non-normative way. For
example, the definition of additional bits out of the reserved
field. There is no reason why we can't point out that those bits have
been used by other documents and point to them. The ND spec doesn't
have to say "you SHOULD or MUST" do those specs as part of ND. Just
saying the "bits are used by foo" with an informative reference seems
fine.

For changes to the router intervals, that seems like the kind of minor
change/clarification that has been allowed in other documents. And
note that we are _recycling_ at draft, not _advancing_ to draft.

If the process does _not_ allow us to make those kind of changes, I
think we've got an even bigger problem that I had thought. It defies
logic to have two different standards track document basically
contradict each other on what is allowed for timers.

Yes. But it is a formal problem caused by the downref rules.

But to be specific, which of the issues I flagged as "substantive"
(which I used to flag changes that the WG needed to see) do you think
would prevent reissuing the document at draft?

I haven't done that analysis. I agree that informative pointers will
probably work. I'm not sure that Jari will get the RFC Editor notes
worked out before today's IESG call, though...

    Brian

--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

Reply via email to