Re: [Technical Errata Reported] RFC3083 (4048)
Michael StJohns <[email protected]> Sat, 12 Jul 2014 09:29:19 -0400
| Newsgroups | gmane.ietf.ipcdn |
|---|---|
| Message-ID | <[email protected]> |
--===============3167270141298113850== Content-Type: multipart/alternative; boundary=Apple-Mail-8D77D726-CA02-4E97-9127-E058BCFB799E Content-Transfer-Encoding: 7bit --Apple-Mail-8D77D726-CA02-4E97-9127-E058BCFB799E Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Ok. That makes sense. I didn't realize Rich had posted an errata. The "st= art" 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]> wrote: >=20 > Hi Guys, >=20 > Thanks for your reply. >=20 > 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_sear= ch.php?rfc=3D3083 then you will see the comma is clearly omitted from the '= fixed' text: >=20 >> It should say: >>=20 >> docsBpiCmAuthState OBJECT-TYPE >> SYNTAX INTEGER { >>=20 >> start(1) >> authWait(2), >> authorized(3), >> reauthWait(4), >> authRejectWait(5) >=20 >=20 > Maybe what you are saying is that the above fix is not required? If so, i= t is misleading...and either way, syntactically incorrect! >=20 > Regards, >=20 > Mark >=20 >=20 >> On Fri, Jul 11, 2014 at 7:34 PM, Michael StJohns <[email protected]> w= rote: >> What a blast from the past. >>=20 >> This is "not an error" , at least as reported. Three are two places this= error 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 "start= (1)," - e.g. including the comma. So I'm not sure where he's actually see= ing the error. >>=20 >> The MIB was verified at submission. I would be surprised if there are a= ny obvious syntactic errors like this in the body of the MIB. >>=20 >> If I remember correctly, the reason the "start" state was excluded from t= he docsBpiCmAuthState enums is that its never a visible state - the state ma= chine doesn't actually exist until docsIfCmStatusValue is at least todEstabl= ished - (RFC4546) and the state would always be later than "start" so any qu= ery about baseline privacy will not necessarily give you valid information p= rior to todEstablished. >>=20 >> Mike >>=20 >>=20 >>=20 >> 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 Compl= iant 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]> >> > >> >Section: 4 >> > >> >Original Text >> >------------- >> >start(1) >> > >> >Corrected Text >> >-------------- >> >start(1), >> > >> >Notes >> >----- >> >errata # 334 for RFC3083 omits the necessary comma at the end of the ins= erted 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 B= ase 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] >> >https://www.ietf.org/mailman/listinfo/ipcdn >=20 >=20 >=20 --Apple-Mail-8D77D726-CA02-4E97-9127-E058BCFB799E Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable <html><head><meta http-equiv=3D"content-type" content=3D"text/html; charset=3D= utf-8"></head><body dir=3D"auto"><div>Ok. That makes sense. I di= dn't realize Rich had posted an errata. The "start" is extraneous but h= armless, but does need the comma if present. Mike<br><br>Sent from my i= Pad</div><div><br>On Jul 12, 2014, at 7:55, Mark Ellison <<a href=3D"mail= to:[email protected]">[email protected]</a>> wrote:<br><br></div><blockquot= e type=3D"cite"><div><div dir=3D"ltr"><div><div><div>Hi Guys,<br><br></div>T= hanks for your reply.<br><br>My submission is in regard to the docsBpiCmAuth= State object. If you look at the technical errata submitted here: <a h= ref=3D"http://www.rfc-editor.org/errata_search.php?rfc=3D3083">http://www.rf= c-editor.org/errata_search.php?rfc=3D3083</a> then you will see the co= mma 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>&= nbsp; docsBpiCmAuthState OBJECT-TYPE<br>= SYNTAX &nb= sp; INTEGER {<br> <br> = &nbs= p; start(1)<br> &= nbsp;  = ; &nb= sp; authWait(2),<br> &n= bsp; = &nbs= p; authorized(3),<br> &= nbsp;  = ; &nb= sp; reauthWait(4),<br> = &nbs= p; &n= bsp; authRejectWait(5)<br> </blockquote><br><br></div>Maybe what you are saying is that the above fix i= s not required? If so, it is misleading...and either way, syntacticall= y 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 S= tJohns <span dir=3D"ltr"><<a href=3D"mailto:[email protected]" target=3D= "_blank">[email protected]</a>></span> wrote:<br><blockquote class=3D"= gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-l= eft:1ex"> What a blast from the past.<br> <br> This is "not an error" , at least as reported. Three are two places th= is error might have been reported from - the definition of docsBpiCmAu= thState and the definition o fdocsBpiCmTEKState. The former - &n= bsp;I believe correctly -does not include "start (1)" as one of its states. &= nbsp;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 i= f there are any obvious syntactic errors like this in the body of the MIB.<b= r> <br> If I remember correctly, the reason the "start" state was excluded from the d= ocsBpiCmAuthState enums is that its never a visible state - the state machin= e doesn't actually exist until docsIfCmStatusValue is at least todEstablishe= d - (RFC4546) and the state would always be later than "start" so any query a= bout baseline privacy will not necessarily give you valid information prior t= o todEstablished.<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 Compl= iant 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&ei= d=3D4048" target=3D"_blank">http://www.rfc-editor.org/errata_search.php?rfc=3D= 3083&eid=3D4048</a><br> ><br> >--------------------------------------<br> >Type: Technical<br> >Reported by: Mark Ellison <<a href=3D"mailto:[email protected]">elliso= [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 ins= erted 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<br> >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 Privac= y Interface Management Information Base for DOCSIS Compliant Cable Modems an= d Cable Modem Termination Systems<br> >Publication Date : March 2001<br> >Author(s) : R. Woundy<br> >Category : INFORMATIONAL<br> >Source : IP over Cable D= ata Network<br> >Area : Operations= 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"_blank= ">https://www.ietf.org/mailman/listinfo/ipcdn</a><br> <br> <br> </blockquote></div><br><br clear=3D"all"><br></div></div> </div></blockquote></body></html>= --Apple-Mail-8D77D726-CA02-4E97-9127-E058BCFB799E-- --===============3167270141298113850== 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 --===============3167270141298113850==--