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

[Thomas Narten <[e-mail]>]

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

Paul Duffy <[e-mail]> writes:

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

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

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

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.

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

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

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

Agreed. Let's get closure and move on.

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