[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Comments from the meeting on Monday and the draft



I just wanted to make a few comments that I took away from the meeting, as well as a few comments on the current draft (-01).  Hopefully they can spark some discussions.

First I think that a lot of the confusion that I sensed at the meeting was because of a clear lack of scope in the document.  I have been there at 2, 3, 4 in the morning balancing the laptop on whatever semiflat surface was available so I have a pretty good idea where this is coming from, but I suspect that a lot of people are having problems with this.  I think adding a fair amount of text to the introduction would solve the problem.

It should (IMHO) include the following discussions:

1.  A brief discussion of the specific problem being addressed.  
2.  A brief discussion of an overall network management framework and how this little piece fits into the overall picture.  (For example, mention SNMP, MIBs, Route Servers, Routing Registries, Policy based systems, COPS, etc.)
3.  Scope of the types of 

I know it sounds like an ambitious task but it doesn't have to be more than a few paragraphs to put everything into perspective.  I would even be happy to contribute the text.

A general comment on the use of terms like MUST, SHOULD, MAY, etc...  I found the use to be somewhat loose.  On a similar note.  When you specify things then you should also provide alternatives and make sure you have complete details.  Like in the section on console ports.  It says RJ45 connector running at 9600 baud.  First, give the pin layouts for the RJ45 pins.  I am guessing that you want them to be the same as Cisco's console port.  If there is a standard pin layout defined in another standard that I am not aware of just reference it.  Second, you may want to add something like "MAY support other standard baud rates."  The way it is written it implies that no other speeds are acceptible.

I think that it owuld help to move discussions of security to its own section.  Some of the logic is also flawed.  For example, I don't think it is consistent to "SHOULD NOT" the use of FTP because it sends passwords in the clear and still allow telnet which also sends the passwords in the clear.  Don't allow telnet because MS does not come with an SSH client by default.  There are plenty of freely available SSH clients for all windows platforms.  Either allow both or disallow both.  

It also says "This configuration MUST contain any private keys, passwords, or shared secrets associated with the device, in strongly-encrypted form."  Define "strongly-encrypted".  

I would add a comment in the section on RECOMMENDING that prelogin banner not be displayed I would add a note that REQUIRES the ability to turn them off if the vendor does not follow the RECOMMENDATION.

On the use of numerical codes (ala SMTP) its hard to see how the current text can lead to anything but confusion.  Recommending it to vendors will only result in *maybe* someone implementing it and then there would be no standard response codes.  Either take it on as a work item and define at least the general classifications or drop it.  Don't leave it in as an off the cuff comment.  It doesn't have to be in this document, it could be in another.

Also as to the document final status.  I want to know if people have seriously considered different status than Informational.  There are plusses and minus in my mind about both Proposed and BCP.

Just my initial observations.  Hopefully some discussion can start.

--->  Phil