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

From: Paul Duffy <[email-masked]>
Date: Mon, 30 Dec 2002 18:13:55 -0500

Thomas/everyone,

Regarding the two remaining issues with this draft...

1. MUST/SHOULD re: RFC 3396.  There appears to be initial agreement within 
the Cablelabs community to change this to a MUST. I propose the following 
text change (top of page 4).

Old text...

"When the total length of a CCC option exceeds 255 octets, the procedure 
outlined in [4] SHOULD be employed to split the option into multiple, 
smaller options."

New text...

"When the total length of a CCC option exceeds 255 octets, the procedure 
outlined in [4] MUST be employed to split the option into multiple, smaller 
options."

2. Section 12 "Procedure for Adding Additional Sub-options".  The Cablelabs 
community desires input into the sub-option code assignments for a couple 
of reasons.  a) the need to get sub-option codes assigned as quickly as the 
IETF process will allow and b) Cablelabs wishes to partition the sub-option 
code space amongst various CableLabs projects.  For example: sub-options 1 
to 50 will  be assigned to the PacketCable project, sub-options 51 - 100 
assigned to the CableHome project, etc.

With these points in mind, I'd like to propose the following text changes 
to section 12.

Old text...

"IANA is requested to register codes for future CableLabs Client 
Configuration Sub-options with an "Expert Review" approval policy as 
described in RFC 2434 [2]. Future proposed sub-options will be assigned a 
numeric code chosen by CableLabs, which will be documented in the Internet 
Drafts that describe the sub-options. The code assignment will be reviewed 
by a designated expert from the IETF prior to publication in an RFC."

New text...

"IANA is requested to register codes for future CableLabs Client 
Configuration Sub-options with an "Expert Review" approval policy as 
described in RFC 2434 [2]. Future proposed sub-options will be assigned a 
numeric code chosen by CableLabs immediately following IESG approval of the 
draft.  This code assignment will then be reviewed by an IETF designated 
expert."

The intent of the this text change is to allow Cablelabs to choose the 
sub-option code assignment, but not until the sub-option draft has cleared 
IESG approval and the designated expert's review.

Thoughts?

--

Paul Duffy
Cisco Systems, Inc.
[email-masked]

_______________________________________________
dhcwg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/dhcwg

---

From: Ted Lemon <[email-masked]>
Date: Mon, 30 Dec 2002 18:45:54 -0500

> 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?

---

From: Paul Duffy <[email-masked]>
Date: Mon, 30 Dec 2002 23:27:00 -0500

At 06:45 PM 12/30/2002 -0500, Ted Lemon wrote:
>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.  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.

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.
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?

Cheers,

--

Paul Duffy
Cisco Systems, Inc.
[email-masked]