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

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?

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:

   {+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.

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
dhcwg@ietf.org
https://www1.ietf.org/mailman/listinfo/dhcwg