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

From: Thomas Narten <[email-masked]>
Date: Fri, 20 Dec 2002 10:47:42 -0500

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
[email-masked]
https://www1.ietf.org/mailman/listinfo/dhcwg

---

From: Paul Duffy <[email-masked]>
Date: Fri, 20 Dec 2002 12:47:08 -0500

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.

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

>change would be made, but there is new text to that effect in the

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.

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

--

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

---

From: Thomas Narten <[email-masked]>
Date: Fri, 20 Dec 2002 12:49:14 -0500

> several weeks back...it still has not appeared in the DHC WG list.

You're right. For some reason it hasn't appeared yet. Assume it got
lost and needs to be resubmitted....

> It looks like you're still looking at rev 4.  I will re-send the
> email.

The version 05 document (that I have now found my private copy of)
seems to have the same issues I mentioned in my earlier note. 

Thomas

---

From: Paul Duffy <[email-masked]>
Date: Fri, 20 Dec 2002 13:04:50 -0500

>seems to have the same issues I mentioned in my earlier note.

We need to get Ralph involved re: IANA considerations section.

What's your feeling re: my discussion re:  SHOULD on RFC 3396?

--

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

---

From: Thomas Narten <[email-masked]>
Date: Fri, 20 Dec 2002 13:28:04 -0500

Oops, I didn't respond to the rest of your message. Sorry.

> months later a couple questions were raised (noted above).

Saying there was a consensus in the past, and then *not* responding to
the issue when it is raised again saying why you don't want to make
change is not consistent with the way the IETF works. In the thread I
referenced, there was discussion about how to maybe deal with the
concerns Cablelabs had.

Ave you had a chance to look at
draft-narten-iana-experimental-allocations-02.txt?  Does this address
any of your concerns? (Or do I still not really understand the
concerns behind this?)

> life a bit easier for the component manufacturers, compliance

In other words, you want the option number for implementations before
the ID has been reviewed and finallized by the community.  Isn't this
what led to the situation with the current document having sat around
for two years before it became urgent to finalize it (and then oops,
we've already done it this way, now it's painful to change...). I'll
note that the -00 version of this ID appeared in March of 2000.

We really need to avoid these types of problems in the future. (And
this is a bit of a plea to the WG in general: can we please just
finish some of the work that is going on in this WG? Things take a
long time becaue folks don't push for closure.)

The right way is:

1) propose the option
2) get it reviewed in DHC
3) ship the document to the IESG for approval
4) get a code point assigned.

None of the above needs to take years (even if we have examples to the
contrary).  But if people think a particular document/option is
important, then they need to drive it to closure in a timely
fashion. I am not a fan of early assignment of code points because I
have seen the problems this can lead to, and it futher reduces what
little incentive there already seems to be to actually finish a
document.

> field trials are starting.

It is not generally a goal of IETF IDs/RFCs to grandfather earlier
implementations. Doing so effectively prevents a document from
specifying the correct behavior. Surely you see the problems here.

Besides, how can a two year old implementation be compliant with the
*current* version of this ID? It seems like we've made a number of
signficant changes to it....

> close this draft/RFC up ASAP.

Agreed. Let's get closure and move on.

Thomas

---

From: Paul Duffy <[email-masked]>
Date: Fri, 20 Dec 2002 14:34:34 -0500

Thomas,

CableLabs/IETF seem to be down to two issues.

1. The IANA considerations section.
2. MUST/SHOULD re: RFC 3396.

I'm going to have to discuss this with Cablelabs.  I'll try to get these 
questions answered ASAP, but given the holidays...I'll do what I can.

Cheers,

--

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

---

From: Paul Duffy <[email-masked]>
Date: Fri, 20 Dec 2002 15:39:42 -0500

...inline....

>any of your concerns? (Or do I still not really understand the

Not sure this helps...

>note that the -00 version of this ID appeared in March of 2000.

Is the intent here that IETF wants to insure the sub-option number DOES 
change (from experimental to official) when a CCC sub-option draft reaches 
RFC?  Forcing a change in the implementations?  If that is the case, then 
this discussion is over and Cablelabs will need to agree to your proposal.

Cheers,

--

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

---

From: Thomas Narten <[email-masked]>
Date: Sat, 21 Dec 2002 10:47:53 -0500

> RFC?

The intent is that the option be reviewed by the community and
finalized *before* it becomes either a de facto standard, or one that
cablelabs has made a standard through its certification waves. Once it
is in effect a standard,

 - there is little incentive to finish the document
 - reasonable requests to change the option are rejected as "too late,
   it's already implemented"
 - the WG is stuck with a document they  may not like, but that they
   can't do anything about.

This is not the way we get good options defined.  What we need to
figure out how to do is get the IETF to review/bless the option
*before* it is needed by cablelabs.

> Forcing a change in the implementations?  If that is the case, then 

Note, the "change" we are talking about is potentially very
minor. Just use a different option number. If it is known in advance
that it will change, software can be designed to allow it to be
changed later.

My real concern with the above is the sense that "we can't change even
the option number", which to me means that if the IETF asks for
changes in the option, its too late  as well, since such changes would
be even *more* work to make. Right?

Thomas