[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: [Rmt] FEC ID allocation
All,
To answer Rod's first question, "IETF Consensus" is defined in RFC 2434
as follows:
"IETF Consensus - New values are assigned through the IETF
consensus process. Specifically, new assignments are made via
RFCs approved by the IESG. Typically, the IESG will seek
input on prospective assignments from appropriate persons
(e.g., a relevant Working Group if one exists)."
So, there is no _requirement_ that specific working groups are
consulted, but if we don't trust the IESG to consult appropriate working
groups before declaring that there is consensus in the IETF on
something, then we are in a bad way generally!
We have defined in quite some detail in the FEC Building Block what an
"FEC Scheme" is and what it must specify. So, at the very least requests
for new FEC Encoding ID allocations should be compliant to the FEC
Building Block and some IETF review will be needed to ensure this. If
you want that to be open review rather than a potentially closed review
by an appointed expert then we should stick with (A) (and that is my
preference).
Furthermore, the concept of "Under-specified" schemes was created
precisely for people who do not want to go through that review process.
Regards,
Mark
-----Original Message-----
From: rmt-bounces at ietf.org [mailto:rmt-bounces at ietf.org] On Behalf Of
Rod.Walsh at nokia.com
Sent: Thursday, November 24, 2005 8:09 PM
To: lorenzo at cisco.com; rmt at ietf.org
Subject: RE: [Rmt] FEC ID allocation
Do A and B assume 2 week RMT and FECFRAME WGLCs? (Since informational
RFCs can pass by hidden from real WG expert review). Informational or
standards track seems a fair requirement so that non IETF specification
do not need to hand over update rights to the IETF (i.e. I don't like
(B)).
Between A and C I'll take the week to think about it. (A is clearly
easier for IETF WGs and is better for transparency, C is clearly easier
for non IETF WGs and encourages harmony). Maybe C, with strong
recommendation for at least an informational RFC and the right for RMT
and FECFRAME (and IESG) to reject the initial requiest and require at
least an infomrtaional RFC if the non IETF document is overly alien and
cryptic? <C needs to state the "format" of the request to help external
organizations, but it can be quite trivial>. To be continued...
Cheers, Rod.
>-----Original Message-----
>From: rmt-bounces at ietf.org [mailto:rmt-bounces at ietf.org] On
>Behalf Of ext Lorenzo Vicisano
>Sent: 23 November, 2005 19:47
>To: rmt at ietf.org
>Subject: [Rmt] FEC ID allocation
>
>At the Vancouver meeting we had a discussion on possibly
>revising the strategy for allocating FEC Encoding IDs. The
>discussion was inconclusive and hence it was decided to bring
>this issue to the list, starting a 1-week WG last-call on it.
>
>The current strategy for allocating FEC Encoding IDs is
>
> A) IETF-Consensus, i.e. requiring an IETF RFC that specifies all the
> requested information (see
>draft-ietf-rmt-fec-bb-revised-02) and that
> instructs IANA to assign a specific ID.
>
>One alternative proposal on the table was to transform IETF
>consensus into
>
> B) Standard Action, i.e. requiring a Standard-Track IESG approved
> RFC
>
>Another was:
>
> C) IETF-Consensus OR [ Specification-Required AND Expert Review ],
> i.e. allow also non IETF specification to assign IDs
>subject to Expert
> Review.
>
>I would like to hear any opinion on these options by Wed November 30th.
>Please check the meeting minutes for additional background information.
>
>Note that the strategy for allocating FEC Instance IDs is
>"First Come First Served" and is not being discussed here.
>
> thank you,
> Lorenzo
>
>
>_______________________________________________
>Rmt mailing list
>Rmt at ietf.org
>https://www1.ietf.org/mailman/listinfo/rmt
>
_______________________________________________
Rmt mailing list
Rmt at ietf.org
https://www1.ietf.org/mailman/listinfo/rmt
_______________________________________________
Rmt mailing list
Rmt at ietf.org
https://www1.ietf.org/mailman/listinfo/rmt