--On Tuesday, May 21, 2013 08:46 -0700 joel jaeggli
<joelja@xxxxxxxxx> wrote:
> On 5/21/13 8:06 AM, John C Klensin wrote:
>>
>> All I'm asking for is that, if you
>> want this as a Proposed Standard you carefully and
>> convincingly describe your design rationale. I want that
>> both because it seems generally appropriate in this case and
>> because, if someone comes along and wants to register the
>> EUI64-with-embedding or EUI-with-48-64-switch RRTYPEs and
>> there is pushback because EUI48 and EUI64 are already
>> registered,
> It seems like we're still re-arguing the assignment of the
> rr-types.
I, at least, am not.
> It doesn't seem like future assignments are likely
> to have anymore pushback than present.
Unless you are going to join the group that says it is perfectly
ok to have multiple IETF standards-track documents that specify
conflicting ways to do almost the same thing, it seems to me
that pushback against other ways to handle EUI data is inherent
in the standards track designation. The last time the IETF had
the argument about conflicting standards, I think there was
rough consensus that it was generally a bad idea even if some of
us thought that exceptions might occasionally be desirable.
> With respect to the question of proposed standard. What
> changes if the requested status is informational?
I don't agree with Keith that the removal of the keywords
specified in 2119 is either necessary or sufficient (nor with
the generalization that such language should never appear in
Informational documents). Like Sam, I think that such language
may sometimes be entirely appropriate to an
informational/descriptive document although I also believe that
it should be used with care.
Since I don't have such an easy solution, answering your
question would require a paragraph-by-paragraph review of the
document, not the more overview-level reading I gave it before
participating in this thread. Having made that proposal, I feel
obligated to do that reading --essentially an editing pass-- but
only if
(i) you and Joe are inclined to process the document as
Informational if the edit is satisfactory and
(ii) it is understood that those edits will almost
certainly not resolve the security and privacy concerns
that have been raised, notably by Keith and Brian if the
simple change to Informational does not do so.
Note that (i) is not a request for a promise or decision, only a
good-faith willingness to move in that direction.
If I am going to do this, I'd prefer to make a pass and then
sort out residual editorial details off list with Joe and anyone
else who is significantly interested rather than trying to do
editing on this list. If that seems reasonable and appropriate,
I can commit to getting this done within the next week, maybe
sooner, but not today.
best,
john