Re: [dhcwg] draft-ietf-dhc-packetcable-05.txt

[Thomas Narten <[e-mail]>]

Paul Duffy <[e-mail]> 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.

> 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
_______________________________________________
dhcwg mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/dhcwg