Re: [Technical Errata Reported] RFC3083 (4048)
"Woundy, Richard" <[email protected]> Sat, 12 Jul 2014 14:44:29 +0000
| Newsgroups | gmane.ietf.ipcdn |
|---|---|
| Message-ID | <[email protected]> |
--===============3586991972644723168== Content-Language: en-US Content-Type: multipart/alternative; boundary="_000_4DAB961442244A0C8E681672B0A64572cablecomcastcom_" --_000_4DAB961442244A0C8E681672B0A64572cablecomcastcom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Wow. I don't even remember why I submitted that errata, 13 years ago. And I= left Cisco ([email protected]<mailto:[email protected]>) 12 years ago. In any case, I agree with this submission. -- Rich On Jul 12, 2014, at 9:29 AM, "Michael StJohns" <[email protected]<mailto= :[email protected]>> wrote: Ok. That makes sense. I didn't realize Rich had posted an errata. The "s= tart" is extraneous but harmless, but does need the comma if present. Mike Sent from my iPad On Jul 12, 2014, at 7:55, Mark Ellison <[email protected]<mailto:ellison@iee= e.org>> wrote: Hi Guys, Thanks for your reply. My submission is in regard to the docsBpiCmAuthState object. If you look a= t the technical errata submitted here: http://www.rfc-editor.org/errata_sea= rch.php?rfc=3D3083 then you will see the comma is clearly omitted from the= 'fixed' text: It should say: docsBpiCmAuthState OBJECT-TYPE SYNTAX INTEGER { start(1) authWait(2), authorized(3), reauthWait(4), authRejectWait(5) Maybe what you are saying is that the above fix is not required? If so, it= is misleading...and either way, syntactically incorrect! Regards, Mark On Fri, Jul 11, 2014 at 7:34 PM, Michael StJohns <[email protected]<mail= to:[email protected]>> wrote: What a blast from the past. This is "not an error" , at least as reported. Three are two places this e= rror might have been reported from - the definition of docsBpiCmAuthState = and the definition o fdocsBpiCmTEKState. The former - I believe correctl= y -does not include "start (1)" as one of its states. The latter has "star= t (1)," - e.g. including the comma. So I'm not sure where he's actually s= eeing the error. The MIB was verified at submission. I would be surprised if there are an= y obvious syntactic errors like this in the body of the MIB. If I remember correctly, the reason the "start" state was excluded from the= docsBpiCmAuthState enums is that its never a visible state - the state mac= hine doesn't actually exist until docsIfCmStatusValue is at least todEstabl= ished - (RFC4546) and the state would always be later than "start" so any q= uery about baseline privacy will not necessarily give you valid information= prior to todEstablished. Mike At 11:02 AM 7/11/2014, RFC Errata System wrote: >The following errata report has been submitted for RFC3083, >"Baseline Privacy Interface Management Information Base for DOCSIS Complia= nt Cable Modems and Cable Modem Termination Systems". > >-------------------------------------- >You may review the report below and at: >http://www.rfc-editor.org/errata_search.php?rfc=3D3083&eid=3D4048 > >-------------------------------------- >Type: Technical >Reported by: Mark Ellison <[email protected]<mailto:[email protected]>> > >Section: 4 > >Original Text >------------- >start(1) > >Corrected Text >-------------- >start(1), > >Notes >----- >errata # 334 for RFC3083 omits the necessary comma at the end of the inser= ted line 'start(1)' > >Instructions: >------------- >This errata is currently posted as "Reported". If necessary, please >use "Reply All" to discuss whether it should be verified or >rejected. When a decision is reached, the verifying party (IESG) >can log in to change the status and edit the report, if necessary. > >-------------------------------------- >RFC3083 (draft-ietf-ipcdn-mcns-bpi-mib-02) >-------------------------------------- >Title : Baseline Privacy Interface Management Information Ba= se for DOCSIS Compliant Cable Modems and Cable Modem Termination Systems >Publication Date : March 2001 >Author(s) : R. Woundy >Category : INFORMATIONAL >Source : IP over Cable Data Network >Area : Operations and Management >Stream : IETF >Verifying Party : IESG > >_______________________________________________ >IPCDN mailing list >[email protected]<mailto:[email protected]> >https://www.ietf.org/mailman/listinfo/ipcdn --_000_4DAB961442244A0C8E681672B0A64572cablecomcastcom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable <html> <head> <meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Dus-ascii"= > </head> <body dir=3D"auto"> <div>Wow. I don't even remember why I submitted that errata, 13 years ago. = And I left Cisco (<a href=3D"mailto:[email protected]">[email protected]</a= >) 12 years ago.</div> <div><br> </div> <div>In any case, I agree with this submission.<br> <br> -- Rich</div> <div><br> On Jul 12, 2014, at 9:29 AM, "Michael StJohns" <<a href=3D"mai= lto:[email protected]">[email protected]</a>> wrote:<br> <br> </div> <blockquote type=3D"cite"> <div> <div>Ok. That makes sense. I didn't realize Rich had posted an = errata. The "start" is extraneous but harmless, but does ne= ed the comma if present. Mike<br> <br> Sent from my iPad</div> <div><br> On Jul 12, 2014, at 7:55, Mark Ellison <<a href=3D"mailto:[email protected]= rg">[email protected]</a>> wrote:<br> <br> </div> <blockquote type=3D"cite"> <div> <div dir=3D"ltr"> <div> <div> <div>Hi Guys,<br> <br> </div> Thanks for your reply.<br> <br> My submission is in regard to the docsBpiCmAuthState object. If you l= ook at the technical errata submitted here: <a href=3D"http://www.rfc-editor.org/errata_search.php?rfc=3D3083">http://w= ww.rfc-editor.org/errata_search.php?rfc=3D3083</a> then you will see = the comma is clearly omitted from the 'fixed' text:<br> <br> <blockquote style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204= ,204,204);padding-left:1ex" class=3D"gmail_quote"> It should say:<br> <br> docsBpiCmAuthState OBJECT-TYPE<b= r> SYNTAX &n= bsp; INTEGER {<br> <br> &nb= sp; = start(1)<br> &nb= sp; = authWait(2),<br> &nb= sp; = authorized(3),<br> &nb= sp; = reauthWait(4),<br> &nb= sp; = authRejectWait(5)<br= > </blockquote> <br> <br> </div> Maybe what you are saying is that the above fix is not required? If s= o, it is misleading...and either way, syntactically incorrect!<br> <br> </div> Regards,<br> <br> Mark<br> <div class=3D"gmail_extra"><br> <br> <div class=3D"gmail_quote">On Fri, Jul 11, 2014 at 7:34 PM, Michael StJohns= <span dir=3D"ltr"> <<a href=3D"mailto:[email protected]" target=3D"_blank">mstjohns@comc= ast.net</a>></span> wrote:<br> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex"> What a blast from the past.<br> <br> This is "not an error" , at least as reported. Three are tw= o places this error might have been reported from - the definition of  = ;docsBpiCmAuthState and the definition o fdocsBpiCmTEKState. Th= e former - I believe correctly -does not include "start (1)"= ; as one of its states. The latter has "start (1)," - = e.g. including the comma. So I'm not sure where he's actually seeing = the error.<br> <br> The MIB was verified at submission. I would be surprised = if there are any obvious syntactic errors like this in the body of the MIB.= <br> <br> If I remember correctly, the reason the "start" state was exclude= d from the docsBpiCmAuthState enums is that its never a visible state - the= state machine doesn't actually exist until docsIfCmStatusValue is at least= todEstablished - (RFC4546) and the state would always be later than "start" so any query about baseline p= rivacy will not necessarily give you valid information prior to todEstablis= hed.<br> <br> Mike<br> <div> <div class=3D"h5"><br> <br> <br> At 11:02 AM 7/11/2014, RFC Errata System wrote:<br> >The following errata report has been submitted for RFC3083,<br> >"Baseline Privacy Interface Management Information Base for DOCSIS= Compliant Cable Modems and Cable Modem Termination Systems".<br> ><br> >--------------------------------------<br> >You may review the report below and at:<br> ><a href=3D"http://www.rfc-editor.org/errata_search.php?rfc=3D3083&e= id=3D4048" target=3D"_blank">http://www.rfc-editor.org/errata_search.php?rf= c=3D3083&eid=3D4048</a><br> ><br> >--------------------------------------<br> >Type: Technical<br> >Reported by: Mark Ellison <<a href=3D"mailto:[email protected]">ellis= [email protected]</a>><br> ><br> >Section: 4<br> ><br> >Original Text<br> >-------------<br> >start(1)<br> ><br> >Corrected Text<br> >--------------<br> >start(1),<br> ><br> >Notes<br> >-----<br> >errata # 334 for RFC3083 omits the necessary comma at the end of the in= serted line 'start(1)'<br> ><br> >Instructions:<br> >-------------<br> >This errata is currently posted as "Reported". If necessary, = please<br> >use "Reply All" to discuss whether it should be verified or<b= r> >rejected. When a decision is reached, the verifying party (IESG)<br> >can log in to change the status and edit the report, if necessary.<br> ><br> >--------------------------------------<br> >RFC3083 (draft-ietf-ipcdn-mcns-bpi-mib-02)<br> >--------------------------------------<br> >Title : Baseline Priva= cy Interface Management Information Base for DOCSIS Compliant Cable Modems = and Cable Modem Termination Systems<br> >Publication Date : March 2001<br> >Author(s) : R. Woundy<br> >Category : INFORMATIONAL<br> >Source : IP over Cable = Data Network<br> >Area : Operation= s and Management<br> >Stream : IETF<br> >Verifying Party : IESG<br> ><br> </div> </div> >_______________________________________________<br> >IPCDN mailing list<br> ><a href=3D"mailto:[email protected]">[email protected]</a><br> ><a href=3D"https://www.ietf.org/mailman/listinfo/ipcdn" target=3D"_blan= k">https://www.ietf.org/mailman/listinfo/ipcdn</a><br> <br> <br> </blockquote> </div> <br> <br clear=3D"all"> <br> </div> </div> </div> </blockquote> </div> </blockquote> </body> </html> --_000_4DAB961442244A0C8E681672B0A64572cablecomcastcom_-- --===============3586991972644723168== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ IPCDN mailing list [email protected] https://www.ietf.org/mailman/listinfo/ipcdn --===============3586991972644723168==--