Re: draft-ietf-dhc-packetcable-05.txt
Paul Duffy <paduffy <at> cisco.com>
2003-01-04 00:38:12 GMT
...inline...
At 12:00 PM 1/2/2003 -0500, Thomas Narten wrote:
>Paul Duffy <paduffy <at> cisco.com> writes:
>
> > At 06:45 PM 12/30/2002 -0500, Ted Lemon wrote:
> > >>Future proposed sub-options will be assigned a numeric code chosen by
> > >>CableLabs immediately following IESG approval of the draft.
> > >
> > >What does "IETF approval of the draft" mean? If it means that the draft
> > >has been adopted by the WG, sounds fine, but if it means that the draft
> > >has passed the IESG review, then what's the point of the expert review?
> > >
>
> > Hi Ted,
>
> > The point I am trying to get across is that the DHC WG, ADs, IESG, etc.
> > approve the technical content/semantics of the sub-option, then Cablelabs
> > would assign the sub-option code.
>
>Note: "IETF Consensus" as defined by RFC 2434, basically means "IESG
>approves the document". That implies all of the above reviews.
>
>Once the IESG has approved the document, it gets shipped to the RFC
>editor, and IANA can *immediately* assign any IANA numbers that are
>needed. I say "immediately" in that IANA is authorized to assign he
>values as soon as the document is approved. They typically do so long
>before the RFC is actually published. In cases where there is a really
>time critical need, this can be done in a day or two (so long as folks
>are given advance warning that this is coming along). I.e., the IANA
>just needs to be asked to prioritize the request. This has happened in
>the past, so getting IANA to assign a number quickly once a document
>has been approved for publication is not a problem.
>
>Hence, the need for cablelabs to actually pick and assign the actual
>value to be used doesn't seem to buy much time. IMO, its simpler and
>adequate to let IANA do it
Please do not forget the second reason for Cablelabs assigning the
code....the desire to partition the sub-option code space amongst its
various projects. If IANA does the assigning, how will this be possible?
> > I'm trying to balance CableLab's need for speed with IETF's review
> > of the content of the sub-option. The expert review would be only
> > for the choice of sub-option code assignment(?), not the actual
> > technical content of the draft.
>
>The problem is that if one *really* needs the code assignment in order
>to put it in a spec, but the technical contents of the spec have not
>been nailed down, it seems premature to be saying implement option X
>using code point Y.
>
> > So the order of events would be:
>
> > 1. CCC sub-option draft submitted to DHC WG.
> > 2. DHC WG, AD, IESG review/approve sub-option format and content.
> > 3. Cablelabs assigns sub-option code.
> > 4. IETF expert reviewer approves code assignment.
>
>I don't see the need for 3 & 4 if they don't happen until after the
>document is approved for publication.
>
> > 5a. Cablelabs compliant vendors start implementing sub-option for testing
> > and shipment to customer.
> > 5b. Draft is simultaneously submitted to RFC editor Q.
>
> > If all goes well, field shipments can commence just about the time the RFC
> > exits the editor Q.
>
> > I'm grasping for a compromise here. Any suggestions?
>
>More thoughts.
>
>If you are worried about odd situations where you really need a number
>assignment, but the document isn't quite ready yet, but folks do think
>it is OK to go ahead and assign a value (because the ID is really
>close, or ...) include in the IANA considerations that assignment of
>sub options can (also) be made via "IESG approval" [RFC 2434], i.e.,
>something like:
>
> IANA is requested to register codes for future CableLabs Client
> Configuration Sub-options via "IETF Consensus" or "IESG Approval"
> [RFC 2434].
>
>IESG approval doesn't require a document or anything. It is really
>intended as an escape for dealing with exceptional situations, with
>one of the other approval mechanisms (e.g., "IETF Consensus") handling
>the vast majority of assignments in practice.
>
>Also, note that "IETF Consensus" means "ID is approved to publish
>RFC". They can be experimental/info as well as standards track. So
>again, if there is a situation where something just absolutely needs
>to get done, another option is publish as info. The bar is generally
>lower for such documents.
>
>Thomas
--
Paul Duffy
Cisco Systems, Inc.
paduffy <at> cisco.com
RSS Feed