RE: FEC ID allocation

"Michael Luby" <[email protected]>
Newsgroups gmane.ietf.rmt
Message-ID <200511292245.jATMjNsB009576@mail>
I prefer strategy A after reading through all the discussion so far on the
mailing list on this topic so far (thanks Rod, Mark, Lorenzo!), and really
don't like strategy C (for the reasons Lorenzo gave -- backed by some
evidence of other standards groups trying to define "standard" FEC schemes
and producing results that were incompatible with the FEC building block,
even though the attempts were to be compliant).

-----Original Message-----
From: [email protected] [mailto:[email protected]] On Behalf Of
Lorenzo Vicisano
Sent: Wednesday, November 23, 2005 9:47 AM
To: [email protected]
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
[email protected]
https://www1.ietf.org/mailman/listinfo/rmt
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.