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

[Paul Duffy <[e-mail]>]

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,

At 01:28 PM 12/20/2002 -0500, Thomas Narten wrote:
>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

--

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


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