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

[Paul Duffy <[e-mail]>]

Hello Thomas,

Please be aware that a rev 5 was sent to internet-drafts and to yourself 
several weeks back...it still has not appeared in the DHC WG list.  It 
looks like you're still looking at rev 4.  I will re-send the email.

At 10:47 AM 12/20/2002 -0500, Thomas Narten wrote:
>I was about to put this document back before the IESG formally, but I
>notice that the IANA considerations section still talks about future
>cablelabs suboptions being assigned via "expert review". I thought
>there was agreement to make this "IETF Consensus". I.e., see:
>
>http://www1.ietf.org/mail-archive/working-groups/dhcwg/current/msg01416.html
>
>I haven't checked the other edits carefully. Is this document *really*
>ready for advancement, or did some other things get left out?

This is not my understanding.  My understanding is that early on, with 
Ralph's guidance, we had general consensus for the text as it stands.  Some 
months later a couple questions were raised (noted above).

Cablelabs intends to place any new sub-option additions before IETF for 
approval (witness the recent submission of sub-option 51), but we STRONGLY 
would prefer to be allowed to assign the sub-option codes.  It will make 
life a bit easier for the component manufacturers, compliance testing, etc.

>Also, general comment (not to single this ID out, though it occurs
>here). When making changes to documents in response to issues that
>have been raised (especially on the mailing list), it is generally
>preferable to respond to such comments not just by saying "OK, will be
>fixed in the next rev", but by saying "OK, here are the text changes I
>propose -- do they look OK?"
>
>The advantage of this approach is you get instant review/feedback on
>whether the changes are ideal. I mention this here because  there was
>discussion about whether to include a normative reference to the
>dhc-concat draft, in the case where options are too long to fit in a
>single option. There was no indication on the mailing list that this
>change would be made, but there is new text to that effect in the
>document:

I will adhere to these recommendations in any further correspondence with 
the list.  I would also suggest that this be added to the authors guidelines.

>    {+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.+}
>
>My immediate reaction to the text is that this should be a MUST, not a
>SHOULD. If one goes and reads the definition of SHOULD, it say:
>
> > 3. SHOULD   This word, or the adjective "RECOMMENDED", mean that there
> >    may exist valid reasons in particular circumstances to ignore a
> >    particular item, but the full implications must be understood and
> >    carefully weighed before choosing a different course.
>
>In this case, if the CCC option exceeds 255, under what conditions
>should the SHOULD be ignored? I can't think if any right off.

The SHOULD resulted from discussions with the device manufacturers.  The 
intent of the SHOULD was to accommodate devices that existed long before 
this RFC.  By making this a MUST, these devices will be 
non-compliant.  PacketCable has been in the works for several years...early 
field trials are starting.

Helps ?  Please lets keep this discussion going.  With your help, I want to 
close this draft/RFC up ASAP.

Cheers,


>It would have been more efficient to have iterated on this text on the
>mailing list the point the issue orignally came up. That way, we might
>have avoided the need for another revision of the document. Note that
>the same applies for the point above that seems to have been missed.
>Thomas
>_______________________________________________
>dhcwg mailing list
>[e-mail]
>https://www1.ietf.org/mailman/listinfo/dhcwg

--

Paul Duffy
Cisco Systems, Inc.
[e-mail]


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