[rfc-i] Proper way to include examples with yet-to-be-assigned values?
paul.hoffman at vpnc.org
Thu Aug 12 17:00:14 PDT 2010
At 4:42 PM -0700 8/12/10, Bob Hinden wrote:
>On Aug 12, 2010, at 4:13 PM, Paul Hoffman wrote:
>> At 3:34 PM -0700 8/12/10, Joe Touch wrote:
>>> Ultimately, you would get the numbers and you would put them in during one of the edit phases, or at least you'd be responsible for checking during AUTH48 anyway.
>> This entails making significant technical changes during AUTH48. That is unseemly, to say the least. Thus my questions about a better way to do it.
>>From a draft in 6man:
> The IANA is requested to assign a new IPv6 Neighbor Discovery Option
> type for the DNSSL option defined in this document:
> Option Name Type
> DNSSL option (TBD)
>Usually by the time it gets to AUTH48 IANA has assigned the option value and the RFC editor has filled it in.
>These were for an existing registry.
>Or were you asking a different question?
A different question. Even if I use TBDs as above, we need to put some numbers in our examples because the examples use numeric entities. This means that the examples will possibly change at some point during the RFC editing process, and likely not until AUTH48.
This kind of technical change is probably acceptable in AUTH48 because it is inevitable; the basic question is how to flag it so that it stands out to the Production Center before then.
--Paul Hoffman, Director
More information about the rfc-interest