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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 




   Values for the IPv6 Hop-by-Hop Options and Destination Options fields
   are allocated using an IESG Approval, IETF Consensus or Standards
   Action processes.

I read that as suggesting, in order, the groups who could _allocate_ a new
codepoint without requiring further review. But _not_ allocating would mean
escalating to the next group along (i.e. if the IESG do not feel it appropriate
to allocate a codepoint immediately, they'd 'redirect' the requestor to the
process for gaining IETF Consensus, etc)

This seems logical to me in so far as it optimises the approval path for
uncontentious requests (IESG approval is presumably a quicker process than
IETF Consensus, etc).

What piqued my interest with the original announcement rejecting this particular
codepoint was the IESG's editorialising, which came across as "don't bother trying
for IETF consensus, it'll be a long time coming and we've got some similar/better
work of our own going on". Which just didn't seem like a fair or reasonable rider on
a rejection message.

(In my confused opinion, naturally.)

cheers,
gja

_______________________________________________

Ietf@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/ietf

[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]