Subject: I-D ACTION:draft-ietf-netconf-beep-01.txt

From: [email-masked]
Date: Mon, 07 Jun 2004 15:43:20 -0400

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Network Configuration Working Group of the IETF.

	Title		: BEEP Application Protocol Mapping for NETCONF
	Author(s)	: E. Lear, K. Crozier
	Filename	: draft-ietf-netconf-beep-01.txt
	Pages		: 15
	Date		: 2004-6-7
	
This document specifies an application protocol mapping for the
NETCONF protocol over the Blocks Extensible Exchange Protocol (BEEP).

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-netconf-beep-01.txt

To remove yourself from the I-D Announcement list, send a message to 
[email-masked] with the word unsubscribe in the body of the message.  
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-netconf-beep-01.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-ietf-netconf-beep-01.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

---

From: Steve Berl <[email-masked]>
Date: Tue, 08 Jun 2004 09:38:22 -0700

Hi Ken and Eliot,

A few little comments on the draft.

Section 2.1 Session Initiation

In the 3rd paragraph it says that the initiator starts the SASL exchange to authenticate itself. Is there also a way for the listener to authenticate itself? Is that part of the TLS exchange that happened earlier or is it part of the SASL exchange which is not mentioned here?

This is important because in the next paragraph you say that there is no longer a need to distinguish initiator from listener. But for purposes of authorization of commands, it is important that the agent know the identity of the manager. So I think there should be some text in here to help keep straight that somehow during the setup of the channel, whoever it is that is going to end up being the manager, whther they are initiator or listener, must have authenticated themselves.

In paragraph 5 of section 2.1 there needs to be a space in "capabilitiesexchange".

Also in that same paragraph, my web browser didn't properly expand the &dquot; around the word "operational". Not sure if this is my web browser or the document that has a problem.

- pg 6 in "Profile summaries" there seems to be a tab or space issue where the data doesn't line up in the columns properly. Again this could be an issue with the web browser.

- pg 6 in "Entity Definitions "PRC" should probably be "RPC".

Have fun,

-steve

At 12:43 PM 6/7/2004, [email-masked] wrote:
>-------------------------------------------------------------------------
>In order to maintain computing infrastructure integrity, Cisco Systems
>Enterprise Messaging Services and InfoSec teams have set a mail policy
>disallowing executable attachments in email.
>
>This message contained an executable attachment type that is prohibited 
>by this policy. The attachment has been removed from this message and 
>copied to quarantine by our systems. It will be held in quarantine for
>seven days in the event that the content needs to be retrieved.
>
>
>-------------------------------------------------------------------------
>For further reference information about viruses and email antivirus 
>efforts within Cisco, please visit:
>
>http://wwwin.cisco.com/it/ems/services/antiviral
>
>
>If your concern isn't addressed by the information in this notification 
>or the above web page, you may open a support request:
>
>http://wwwin.cisco.com/support/
>
>Select "Messaging", "Email-Related", "Mail Routing"
>
>Please include in the text of your case the following information:
>
>* Full headers of the message. Documentation on displaying the full 
>headers is available at this URL:
>
>http://wwwin.cisco.com/support/library/faqs/solution002471.html 
>
>* This unique quarantine identifier: i57L9MXl028403
>
>If the matter is urgent, you may follow up by calling one of the below 
>referenced numbers. Please make every effort to provide the above 
>requested information via the support web tool prior to calling as it 
>will greatly aid the resolution of your issue.
>
>Americas:
>1 408 526 8888
>
>Asiapac
>+61 2 8446 8888
>
>EMEA
>+31 20 485 4888
>
>Japan
>+81 3 5549 6888
>
>US (Toll Free)
>1| 800| 888| 8187| (ext.68888)
>
>Thank you for your cooperation,
>
>Enterprise Messaging Services
>Cisco Systems, Inc
>Content-Type: Multipart/Alternative; Boundary="OtherAccess"
>
>
>NextPart
>s, Inc
> Services
>
>f your issue.
>rior to calling as it 
>e
>sage.  
>
>--OtherAccess--
>c
> Services
>
>f your issue.
>rior to calling as it 
>e
>sage.  

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/netconf/>