[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: Documents on Agenda for the February 17 Telechat
I am a somehow confused by Section 2.18 in draft-sinnreich-sipdev-req-05.txt
2.18. Web Based Feature Management
Req-85: SIP telephony devices SHOULD support an internal web server
to allow users the option to manually configure the phone
and to set up personal phone applications such as the
address book, speed-dial, ring tones, and last but not least
the call handling options for the various lines, aliases, in
a user friendly fashion. Web pages to manage the SIP
telephony device SHOULD be supported by the individual
device, or MAY be supported in managed networks from
centralized web servers. Managing SIP telephony devices
SHOULD NOT require special client software on the PC or
require a dedicated management console. SIP telephony
devices SHOULD support https transport for this purpose.
My problems with this section:
- this is as far as I get the only requirement that deals with management and specifically with configuration. I am wondering what kind of interoperable management is being achieved, and why Web Based Feature management is preferred to other applicable protocols for configuration (CLI, RADIUS extensions, etc.)
- what exactly is a centralized web server, and how it interacts with the SIP IP phones?
- SNMP is not mentioned with the exception of requirement Req-63 where it is included in the list of protocols that have the capability to be disabled for security reasons. Why should not SNMP be used for performance monitoring and faults management purposes?
Regards,
Dan
> -----Original Message-----
> From: owner-mreview@ops.ietf.org [mailto:owner-mreview@ops.ietf.org]On
> Behalf Of David Kessens
> Sent: 12 February, 2005 3:02 AM
> To: mreview@ops.ietf.org
> Subject: Documents on Agenda for the February 17 Telechat
>
>
>
> Please see below for a list of documents on the next IESG telechat
> agenda.
>
> I would be interested in reviews and comments on any of these
> documents.
>
> It would be best if I could receive comments by Wed 3pm Pacific Time.
>
> Thanks,
>
> David Kessens
> ---
>
> ------
>
>
> 2. Protocol Actions
> Reviews should focus on these questions: "Is this document a
> reasonable basis on which to build the salient part of
> the Internet
> infrastructure? If not, what changes would make it so?"
>
>
> 2.1 WG Submissions
> 2.1.1 New Item
> o draft-ietf-fax-gateway-protocol-12.txt
> Internet FAX Gateway Functions (Proposed Standard) - 1 of 7
> Token: Scott Hollenbeck
> o draft-ietf-idr-bgp-ext-communities-08.txt
> BGP Extended Communities Attribute (Proposed Standard) - 2 of 7
> Token: Bill Fenner
> o draft-ietf-mmusic-kmgmt-ext-13.txt
> Key Management Extensions for Session Description
> Protocol (SDP) and Real
> Time Streaming Protocol (RTSP) (Proposed Standard) - 3 of 7
> Token: Jon Peterson
> o draft-ietf-mmusic-sdescriptions-09.txt
> Session Description Protocol Security Descriptions for
> Media Streams
> (Proposed Standard) - 4 of 7
> Token: Jon Peterson
> o draft-ietf-rohc-context-replication-06.txt
> RObust Header Compression (ROHC):Context Replication for
> ROHC Profiles
> (Proposed Standard) - 5 of 7
> Token: Allison Mankin
> o draft-ietf-simple-xcap-06.txt
> The Extensible Markup Language (XML) Configuration Access
> Protocol (XCAP)
> (Proposed Standard) - 6 of 7
> Token: Ted Hardie
> o draft-ietf-simple-xcap-list-usage-05.txt
> Extensible Markup Language (XML) Formats for Representing
> Resource Lists
> (Proposed Standard) - 7 of 7
> Token: Ted Hardie
>
> 2.1.2 Returning Item
> o draft-ietf-sip-sctp-06.txt
> The Stream Control Transmission Protocol (SCTP) as a
> Transport for the
> Session Initiation Protocol (SIP) (Proposed Standard) - 1 of 1
> Token: Allison Mankin
>
>
> 2.2 Individual Submissions
> 2.2.1 New Item
> o draft-lee-tls-seed-01.txt
> Addition of SEED Ciphersuites to Transport Layer Security
> (TLS) (Proposed
> Standard) - 1 of 3
> Token: Russ Housley
> o draft-strombergson-shf-05.txt
> The Standard Hexdump Format (Proposed Standard) - 2 of 3
> Note: Needs revision to handle last call comments
> Token: Ted Hardie
> o draft-bellovin-mandate-keymgmt-03.txt
> Guidelines for Cryptographic Key Management (BCP) - 3 of 3
> Token: Sam Hartman
>
> 2.2.2 Returning Item
> NONE
>
> 3. Document Actions
>
> 3.1 WG Submissions
> Reviews should focus on these questions: "Is this
> document a reasonable
> contribution to the area of Internet engineering which
> it covers? If
> not, what changes would make it so?"
>
> 3.1.1 New Item
> o draft-ietf-mip6-ro-sec-02.txt
> Mobile IP version 6 Route Optimization Security Design Background
> (Informational) - 1 of 3
> Note: 2005-02-08: ready for full IESG review
> Token: Thomas Narten
> o draft-ietf-rohc-tcp-field-behavior-04.txt
> TCP/IP Field Behavior (Informational) - 2 of 3
> Note: Sent to tcpm wg for their look
> Token: Allison Mankin
> o draft-ietf-l3vpn-mgt-fwk-03.txt
> Framework for L3VPN Operations and Management
> (Informational) - 3 of 3
> Note: 2005-02-09: only minor comments, will put before
> the full IESG.
> Token: Thomas Narten
>
> 3.1.2 Returning Item
> o draft-ietf-fax-gateway-options-08.txt
> Guideline of optional services for Internet FAX Gateway
> (Informational) - 1
> of 1
> Token: Scott Hollenbeck
>
> 3.1.3 For Action
> o draft-ietf-rohc-tcp-requirements-08.txt
> Requirements for ROHC IP/TCP Header Compression
> (Informational) - 1 of 1
> Token: Allison Mankin
>
> 3.2 Individual Submissions Via AD
> Reviews should focus on these questions: "Is this
> document a reasonable
> contribution to the area of Internet engineering which
> it covers? If
> not, what changes would make it so?"
>
> 3.2.1 New Item
> o draft-sinnreich-sipdev-req-05.txt
> SIP Telephony Device Requirements and Configuration
> (Informational) - 1 of
> 4
> Note: RFC-Editor note forthcoming to respond to a few
> last-minute comments.
> Token: Jon Peterson
> o draft-hall-mime-app-mbox-04.txt
> The APPLICATION/MBOX Media-Type (Informational) - 2 of 4
> Token: Scott Hollenbeck
> o Three-document ballot: - 3 of 4
> - draft-katz-submitter-00.txt
> SMTP Service Extension for Indicating the Responsible
> Submitter of an
> E-mail Message (Experimental)
> Note: Sent to dea-dir
> - draft-lyon-senderid-core-00.txt
> Sender ID: Authenticating E-Mail (Experimental)
> Note: Sent to dea-dir
> - draft-lyon-senderid-pra-00.txt
> Purported Responsible Address in E-Mail Messages
> (Experimental)
> Note: Sent to dea-dir
> Token: Ted Hardie
> o draft-schlitt-spf-classic-00.txt
> Sender Policy Framework: Authorizing Use of Domains in E-MAIL
> (Experimental) - 4 of 4
> Note: Sent to dea-dir for review
> Token: Ted Hardie
>
> 3.2.2 Returning Item
> o draft-kindberg-tag-uri-07.txt
> The 'tag' URI scheme (Informational) - 1 of 1
> Token: Ted Hardie
>
> 3.3 Individual Submissions Via RFC Editor
> Reviews should focus on these questions: "Does this document
> represent an end run around the IETF's working groups
> or its procedures? Does this document present an incompatible
> change to IETF technologies as if it were compatible?" Other
> matters may be sent to the RFC Editor in private review.
>
> 3.3.1 New Item
> o draft-zeilenga-ldup-sync-06.txt
> LDAP Content Synchronization Operation (Experimental) - 1 of 2
> Note: Via RFC-Editor
> Token: Ted Hardie
> o draft-melsen-mac-forced-fwd-03.txt
> MAC-Forced Forwarding: A Method for Traffic Separation on
> an Ethernet
> Access Network (Informational) - 2 of 2
> Token: Thomas Narten
>
> 3.3.2 Returning Item
> o draft-carroll-dynmobileip-cdma-04.txt
> Verizon Wireless Dynamic Mobile IP Key Update for
> cdma2000(R) Networks
> (Informational) - 1 of 4
> Note: 2005-02-08: IESG: this document violates a MUST NOT
> in radius, one
> that is not insignificant. I.e., it relates to security
> aspects/assumptions
> underlying radius. So, it 'extends and embraces' an
> IETF protocol in
> a way that warrants IETF review/acceptance.
> Token: Thomas Narten
> o Two-document ballot: - 2 of 4
> - draft-sjkoh-rmt-bb-tree-config-03.txt
> Reliable Multicast Transport Building Block: Tree
> Auto-Configuration
> (Informational)
> Note: There is a note of concern from an RMT WG Chair
> in the ballot
> comments:ïï these documents retain all the RMT WG
> boilerplate.ïï
> History:ïï they were not handled by the WG because the
> authors stopped
> work on them (stopped doing any updates, did not
> appear for over a
> year), so their work item was dropped by consensus.
> - draft-chiu-rmt-bb-track-03.txt
> Reliable Multicast Transport Building Block:Tree based
> ACK (TRACK)
> Mechanisms (Informational)
> Note: Note sent to RMT Chairs reminding them of these
> and suggesting
> reminder to WG (to avoid surprise).ï IESG ex-WG note
> to be put on.ï
> Token: Allison Mankin
> o draft-klensin-idn-tld-04.txt
> National and Local Characters for DNS Top Level Domain
> (TLD) Names
> (Informational) - 3 of 4
> Note: 2005-02-10: I've reviewed this and do not believe
> it conflicts with.
> any IETF work. I think is fine to be published as an Independent.
> Submission
> Token: Thomas Narten
> o draft-shirasaki-dualstack-service-04.txt
> A Model of IPv6/IPv4 Dual Stack Internet Access Service
> (Informational) - 4
> of 4
> Note: 2005-02-09: This seems fine to have the RFC Editor
> publish as an.
> independent submission..
> Token: Thomas Narten
>
> 3.3.3 For Action
> o draft-ford-midcom-p2p-03.txt
> Peer-to-Peer communication across Middleboxes
> (Informational) - 1 of 1
> Note: Author has informed me that they are no longer
> persuing this draft.
> Token: Jon Peterson
>
> ------
>
>