ietf
[Top] [All Lists]

Re: RFC 2434 term "IESG approval" (Re: IANA Action: Assignment of an IPV6 Hop-by-hop Option)

2005-07-04 00:01:47
    Date:        Fri, 1 Jul 2005 15:16:09 -0400
    From:        Margaret Wasserman <margaret(_at_)thingmagic(_dot_)com>
    Message-ID:  <p0620074abeeb3c7dc3ef(_at_)[10(_dot_)0(_dot_)0(_dot_)171]>

  | In what way would that differ from "Specification Required"?

See below.

  | No.  That one ("Specification Required") explicitly states that the 
  | document must be permanent, readily-available and in sufficient 
  | detail so that interoperability is possible.

And where do you see "permanent, readily-available" in the IESG
approval section?

  | There is absolutely no indication here regarding what criteria the 
  | IESG should use to approve (or not approve) an IANA allocation.

Everything in 2434 is about the amount of documentation required.
Why would the IESG approval section be any different?   It expressly
talks about documentation, and nothing else.   It says the IESG can
ask for more documentation, it doesn't say that it can ask for proof
that the option won't harm X or Y, or anything else.   There's a very
old principle of interpretation that says that if something is
expressed, everything else is inapplicable (it has a Latin name, if
I thought I could come even close to spelling it, I would).

  | You have arbitrarily decided that availability of the same documentation 
  | described in "Specification Required" is the only criteria that the 

Not the same documentation.   The same kind or standard perhaps, but
without requiring anything to be publically available.   Documentation
needs to exist, to show that there's a real option (in this case) being
registered, and so that others could implement it, in the right
circumstances.   But it could be private documentation, given to
the IESG under NDA.   The section expressly says that it does not need to
be published (as an RFC).

  | I personally believe that the IESG should use the same criteria that 
  | we use for all of the other IESG decisions in the IETF (absent other 
  | direction) -- we try to decide what is in the best interests of the 
  | IETF and the Internet.

I'll leave that rat hole for another time.

  | If you disagree with that decision (although I think you 
  | should read the document first before forming that opinion), 

No, that's exactly the point.   It cannot be in anyone's best interests
for option numbers to clash.   It does not matter what the use of the
option is.  Driving people who request options into inventing their own
code, rather than having one assigned by IANA helps the internet just how?
Now in this case the group who are requesting the option may be willing
to simply do nothing (or abandon use of IPv6) rather than going to the
extreme of inventing their own option code and using it.   But in another
case, the applicant will not.

Benefit to the IETF, maybe, after all, the IETF cannot possibly allow
another organisation, that is actually producing something, where the
IETF is just talking about the need to do so, to actually succeed, can it?
That wouldn't show the IETF in a very good light.

But IANA is not a function of the IETF, it never has been.   It asks
the IETF for advice, but the "best interests of the IETF" are certainly
not something that ought be relevant in IANA assignments.

  | The working group did _not_ make a decision about whether an IP 
  | option number should be allocated _for this purpose_ (i.e. for this 
  | particular option) without requiring an IETF consensus document. 

They did, or they would have specified that as a requirement.

Obviously the WG didn't consider this particular option, or any other
future option, which didn't exist when 2780 was written.   Instead they
(really us, since the WG just proposed, the IETF approves via the last
call process) decided that it should never be a requirement (though it
is an option) for anyone to go through the IETF consensus process for
IPv6 options.

  | They delegated that decision to the IESG by including "IESG Approval" 
  | as one option in their IANA considerations section.  If they  wanted 
  | to allocate a number to everyone who produces a permanent,
  | publicly available, detailed document, they would have chosen 
  | "Specification Required".

But everyone knows that options are sometimes needed for things that
are not to be documented that way.   Having the doc checked by someone
(an expert in some cases, the IESG in others) is a reasonable way to
allow that to happen.

What do you propose doing when someone comes to you with a propietary
option they're proposing using, and asks for an option code for that
one, but who refuses to make any documentation about the option public?

  | The fact that a document gives the IESG the authority to approve 
  | allocations in a particular registry does not obligate the IESG to 
  | say 'yes' to every request that is received for that registry -- what 
  | would be the point of that?

When did anyone ever claim that was required?   I have consistently
said that I have no idea whether the option actually should have been
registered.   What was wrong was the method used to reject it, not that
it was rejected.

  | IMO, this 
  | is not a case of the IESG over-exercising our authority, it is a case 
  | of us being conservative about exercising our authority in a complex 
  | situation.

There is nothing complex about this at all.   IPv6 options can be
inserted into any IPv6 packet by anyone, with or without any specification,
anywhere, of what the options mean.   That includes both desestination
and hop by hop options.   Whether the option will do anything useful or
not is another question, but they can certainly be added.

The only question here is whether someone who wants their particular
option listed in the registry, so others can avoid conflicting with it
should be able to do so.

What is complex?

No-one is asking you to approve their particular protocol.

The problem is that the IETF, and the IESG in particular, sees a protocol,
sees it is planned to be used with internet related protocols, and so
perhaps on some part of the internet, and decides "that's ours, we must
be the ones to decide whether that is any good or not, now how do we force
that to happen?"

That's intolerable.

kre

_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf