A new Request for Comments is now available in online RFC libraries.
RFC 9535
Title: JSONPath: Query Expressions for JSON
Author: S. Gössner, Ed.,
G. Normington, Ed.,
C. Bormann, Ed.
Status: Standards
The IESG has approved the following document:
- 'JSONPath: Query expressions for JSON'
(draft-ietf-jsonpath-base-21.txt) as Proposed Standard
This document is the product of the JSON Path Working Group.
The IESG contact persons are Murray Kucherawy and Francesca Palombini.
A URL
The IESG has received a request from the JSON Path WG (jsonpath) to consider
the following document: - 'JSONPath: Query expressions for JSON'
as Proposed Standard
The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive
A new Request for Comments is now available in online RFC libraries.
RFC 9156
Title: DNS Query Name Minimisation to
Improve Privacy
Author: S. Bortzmeyer,
R. Dolmans,
P. Hoffman
Status
The IESG has approved the following document:
- 'DNS Query Name Minimisation to Improve Privacy'
(draft-ietf-dnsop-rfc7816bis-11.txt) as Proposed Standard
This document is the product of the Domain Name System Operations Working
Group.
The IESG contact persons are Warren Kumari and Robert
A new Request for Comments is now available in online RFC libraries.
STD 95
RFC 9082
Title: Registration Data Access Protocol (RDAP)
Query Format
Author: S. Hollenbeck,
A. Newton
Status
The IESG has received a request from the Domain Name System Operations WG
(dnsop) to consider the following document: - 'DNS Query Name Minimisation to
Improve Privacy'
as Internet Standard
The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action
The IESG has approved the following document:
- 'Registration Data Access Protocol (RDAP) Query Format'
(draft-ietf-regext-rfc7482bis-03.txt) as Internet Standard
This document is the product of the Registration Protocols Extensions Working
Group.
The IESG contact persons are Murray Kucherawy
The IESG has received a request from the Registration Protocols Extensions WG
(regext) to consider the following document: - 'Registration Data Access
Protocol (RDAP) Query Format'
as Internet Standard
The IESG plans to make a decision in the next few weeks, and solicits final
comments
A new Request for Comments is now available in online RFC libraries.
RFC 8977
Title: Registration Data Access Protocol (RDAP)
Query Parameters for Result Sorting and
Paging
Author: M. Loffredo
The IESG has approved the following document:
- 'Registration Data Access Protocol (RDAP) Query Parameters for Result
Sorting and Paging'
(draft-ietf-regext-rdap-sorting-and-paging-20.txt) as Proposed Standard
This document is the product of the Registration Protocols Extensions Working
The IESG has received a request from the Registration Protocols Extensions WG
(regext) to consider the following document: - 'Registration Data Access
Protocol (RDAP) Query Parameters for Result
Sorting and Paging'
as Proposed Standard
The IESG plans to make a decision in the next few
A new Request for Comments is now available in online RFC libraries.
RFC 7901
Title: CHAIN Query Requests in DNS
Author: P. Wouters
Status: Experimental
Stream: IETF
Date: June 2016
Mailbox:pwout
A new Request for Comments is now available in online RFC libraries.
RFC 7816
Title: DNS Query Name Minimisation to
Improve Privacy
Author: S. Bortzmeyer
Status: Experimental
Stream: IETF
Date
The IESG has approved the following document:
- 'Chain Query requests in DNS'
(draft-ietf-dnsop-edns-chain-query-07.txt) as Experimental RFC
This document is the product of the Domain Name System Operations Working
Group.
The IESG contact persons are Benoit Claise and Joel Jaeggli.
A URL
The IESG has approved the following document:
- 'DNS query name minimisation to improve privacy'
(draft-ietf-dnsop-qname-minimisation-09.txt) as Experimental RFC
This document is the product of the Domain Name System Operations Working
Group.
The IESG contact persons are Benoit Claise and Joel
The IESG has received a request from the Domain Name System Operations WG
(dnsop) to consider the following document:
- 'Chain Query requests in DNS'
as Experimental RFC
The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send
A new Request for Comments is now available in online RFC libraries.
RFC 7724
Title: Active DHCPv4 Lease Query
Author: K. Kinnear, M. Stapp,
B. Volz, N. Russell
Status: Standards Track
Stream: IETF
The IESG has received a request from the Domain Name System Operations WG
(dnsop) to consider the following document:
- 'DNS query name minimisation to improve privacy'
as Experimental RFC
The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action
The IESG has received a request from the Dynamic Host Configuration WG
(dhc) to consider the following document:
- 'Active DHCPv4 Lease Query'
draft-ietf-dhc-dhcpv4-active-leasequery-05.txt as Proposed Standard
The IESG plans to make a decision in the next few weeks, and solicits
final
The IESG has approved the following document:
- 'Registration Data Access Protocol Query Format'
(draft-ietf-weirds-rdap-query-18.txt) as Proposed Standard
This document is the product of the Web Extensible Internet Registration
Data Service Working Group.
The IESG contact persons are Pete
The IESG has received a request from the Web Extensible Internet
Registration Data Service WG (weirds) to consider the following document:
- 'Registration Data Access Protocol Query Format'
draft-ietf-weirds-rdap-query-15.txt as Proposed Standard
The IESG plans to make a decision in the next
A new Request for Comments is now available in online RFC libraries.
RFC 7072
Title: A Reputation Query Protocol
Author: N. Borenstein, M. Kucherawy
Status: Standards Track
Stream: IETF
Date: November 2013
The IESG has approved the following document:
- 'A Reputation Query Protocol'
(draft-ietf-repute-query-http-11.txt) as Proposed Standard
This document is the product of the Reputation Services Working Group.
The IESG contact persons are Pete Resnick and Barry Leiba.
A URL of this Internet
CR LF was first adopted for the Telnet NVT (Network Virtual Terminal). I
think it was Jon
Postel's choice, and no one disagreed. Then when FTP was defined, it
seemed most economical
to use the same. In fact, doesn't the FTP spec explicitly say that the
conventions on the control
connection
John,
I don't think it would of been fun designing and testing a text-based
hosting protocol manually with your terminal/telecommunication/telnet
client New Line Mode (add LF to CR) option disabled or server text
responses only issue CR or LF.
It would of been very hard or confusing to do
--On Friday, August 30, 2013 09:56 -0700 Bob Braden
bra...@isi.edu wrote:
CR LF was first adopted for the Telnet NVT (Network Virtual
Terminal). I think it was Jon
Postel's choice, and no one disagreed.
A tad more complicated, IIR. It turns out that, with some
systems interpreting LF as
Hi Murray,
At 01:14 21-08-2013, Murray S. Kucherawy wrote:
Ah. I realize that CRLF is standard line termination for SMTP; is
it automatically the expected line termination for all line-oriented
protocols? I don't know about others.
I would have to write a long answer to that question. :-)
On Thu, Aug 29, 2013 at 8:57 AM, SM s...@resistor.net wrote:
Hi Murray,
At 01:14 21-08-2013, Murray S. Kucherawy wrote:
Ah. I realize that CRLF is standard line termination for SMTP; is it
automatically the expected line termination for all line-oriented
protocols? I don't know about
On Thu, Aug 15, 2013 at 10:13 AM, SM s...@resistor.net wrote:
The draft-iet-repute-model reference is a down-ref.
I agree, the model document should be considered for PS instead.
A server receiving a query about an application it does not
recognize or explicitly support support (e.g
would
conceivably give a new value for every query. If a client wants
that up-to-the-moment accuracy, then Expires is
counterproductive. On the other hand, an operator that calculates
reputation values daily could indicate this by setting an Expires
field of either a day (86400) or the total
On Wed, Aug 21, 2013 at 12:43 AM, SM s...@resistor.net wrote:
Why is that?
The media type is text/plain.
Ah. I realize that CRLF is standard line termination for SMTP; is it
automatically the expected line termination for all line-oriented
protocols? I don't know about others.
-MSK
At 07:41 15-08-2013, The IESG wrote:
The IESG has received a request from the Reputation Services WG (repute)
to consider the following document:
- 'A Reputation Query Protocol'
draft-ietf-repute-query-http-09.txt as Proposed Standard
The IESG plans to make a decision in the next few weeks
The IESG has approved the following document:
- 'Bulk DHCPv4 Lease Query'
(draft-ietf-dhc-dhcpv4-bulk-leasequery-07.txt) as Proposed Standard
This document is the product of the Dynamic Host Configuration Working
Group.
The IESG contact persons are Ralph Droms and Brian Haberman.
A URL
On Fri 11/May/2012 08:56:14 +0200 IETF Chair wrote:
We have identified space in Vancouver to hold the Bits and Bites event,
Would it be possible to design a _unified_ event board that mentions
_all_ the events at the location, including this one, WGs, BoFs, not
only IETF, but also IRTF, ISOC,
a single power strip and access to the IETF
wireless network. Additional power or wired network connections may require an
additional fee from the table sponsor.
Thanks,
Russ
On Apr 16, 2012, at 11:40 AM, IETF Chair wrote:
We sent a query to the community on March 16, 2012. There was a discussion
a single power strip and access to the IETF
wireless network. Additional power or wired network connections may require an
additional fee from the table sponsor.
Thanks,
Russ
On Apr 16, 2012, at 11:40 AM, IETF Chair wrote:
We sent a query to the community on March 16, 2012. There was a discussion
We sent a query to the community on March 16, 2012. There was a discussion on
the IETF mailing list. We also presented the topic in the IETF chair and IAOC
chair presentations at administrative plenary at IETF 83, and there was an
active discussion at the open mic that followed.
Our
From: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On Behalf Of Henk
Uijterwaal
We have had cases where the opening reception was sponsored by somebody other
than the host for the meeting (if there was a host). The sponsor didn't get
much more than the possibility to put a sign near
I think this is a good thing to try.
-Original Message-
From: ietf-announce-boun...@ietf.org [mailto:ietf-announce-boun...@ietf.org] On
Behalf Of IAOC Chair
Sent: Friday, March 16, 2012 4:14 PM
To: IETF Announcement List
Subject: Query to the community -- An additional IETF Meeting event
IAOC Chair
Lähet.: 16.03.2012, 22:14
V.ottaja: IETF Announcement List
Aihe: Query to the community -- An additional IETF Meeting event?
The IESG and IAOC are considering an addition to the IETF meeting week, and we
would like your views before we develop the idea further.
At NANOG, there is a Beer
Wes == Wes George George writes:
Wes That said, I don't think that this potential experiment
Wes requires a *separate* night. I'd much prefer to replace the
Wes current overpriced hotel cash bar arrangement at the welcome
Wes reception with something more like beer-n-gear. I'm
On Mon, 19 Mar 2012, Michael Richardson wrote:
+1. If it's really the social, or better, the Sunday night event, then
great. I've been at two NANOGs for beer-n-gear, and while I found it a
bit weak in gear, and not that well attended, I actually enjoyed it.
Must have been a while ago,
I have two comments on this.
1) I am in favor of allowing the IAOC to experiment with an event (or two)
like this for the purposes of developing running code with the associated
pros, cons and economics.
2) I would attend such an additional event if the gear on display was
related to
we proceed to do the research and
planning?
query.
I'm fine with the IAOC doing the research.
Henk
--
Henk Uijterwaal Email: henk(at)uijterwaal.nl
http
Hello everybody,
The beer and gear seems to work pretty well at Nanog, and therefore it is
a good idea to consider it for the IETF. However, I am a bit worried that
we are, however, not seeing the difference between the IETF and Nanog.
Nanog is a Network Operator Group. Hence, the name. Vendors
Those vendors who want to organize themselves into a beer gear
should do so and then coordinate with the IETF early in the planning
process in order to have space they can pay for. They can either pay
the IETF or pay the hotel for the incremental meeting cost. There is
no need for the IETF to
-announce-boun...@ietf.org] On
Behalf Of IAOC Chair
Sent: Friday, March 16, 2012 4:14 PM
To: IETF Announcement List
Subject: Query to the community -- An additional IETF Meeting event?
The IESG and IAOC are considering an addition to the IETF meeting week, and we
would like your views before we
The IESG and IAOC are considering an addition to the IETF meeting week, and we
would like your views before we develop the idea further.
At NANOG, there is a Beer and Gear reception one evening. There are exhibitor
tables with product vendors (hardware and software) and service providers
On Fri, Mar 16, 2012 at 8:49 PM, IAOC Chair bob.hin...@gmail.com wrote:
The IESG and IAOC are considering an addition to the IETF meeting week, and
we would like your views before we develop the idea further.
At NANOG, there is a Beer and Gear reception one evening. There are
exhibitor
The question I would ask is: who are the vendors marketing to, and what are
they selling? At NANOG, that's fairly clear; companies like Cisco and Juniper,
and resellers like Network Hardware, are selling to their customers, who are
often technical decision makers or senior staff in companies
On Mar 16, 2012, at 2:13 PM, David Meyer wrote:
On Fri, Mar 16, 2012 at 2:03 PM, Fred Baker f...@cisco.com wrote:
The question I would ask is: who are the vendors marketing to, and what are
they selling? At NANOG, that's fairly clear; companies like Cisco and
Juniper, and resellers like
the research and planning?
query.
Part of exploring is to develop a sense of the marketing issues, exactly as
you and others have raised.
But these are worth pursuing only if the community is comfortable with the basic
idea of doing this kind of event.
d/
--
Dave Crocker
Brandenburg
On Mar 16, 2012, at 2:23 PM, Dave Crocker wrote:
But these are worth pursuing only if the community is comfortable with the
basic idea of doing this kind of event.
I'm willing to do the experiment.
On 3/16/12 14:19 , Fred Baker wrote:
On Mar 16, 2012, at 2:13 PM, David Meyer wrote:
On Fri, Mar 16, 2012 at 2:03 PM, Fred Baker f...@cisco.com
wrote:
The question I would ask is: who are the vendors marketing to,
and what are they selling? At NANOG, that's fairly clear;
companies like
The IESG and IAOC are considering an addition to the IETF meeting week, and we
would like your views before we develop the idea further.
At NANOG, there is a Beer and Gear reception one evening. There are exhibitor
tables with product vendors (hardware and software) and service providers
The IESG has received a request from the Dynamic Host Configuration WG
(dhc) to consider the following document:
- 'Bulk DHCPv4 Lease Query'
draft-ietf-dhc-dhcpv4-bulk-leasequery-05.txt as a Proposed Standard
The IESG plans to make a decision in the next few weeks, and solicits
final comments
Would a general access policy lookup tool protocol be viable here? It
could bolt-on to both DHCP and NEA but seems like the same additions
would be good in both. The same is true with many other protocols.
Especially (from my perspective) those being used in automation and
testimony
On Mar 14, 2011, at 3:36 AM, Will Yu wrote:
Hello dear Michael,
Thank you for your reply. There is an additional query about your reply:
In our realization, the remote address is regarded as unreachable until the
Heartbeat Message from TWO different local address(IP1 and IP2) exceed PMR
Hello dear Michael,
Thank you for your reply. There is an additional query about your reply:
In our realization, the remote address is regarded as unreachable until the
Heartbeat Message from TWO different local address(IP1 and IP2) exceed PMR.
It means that IP1 sent 4(PMR value) Heartbeat
Hello,
I have a query on SCTP standard (RFC 4960). In section 8.2 Path Failure
Detection, it describes the action which end points should take in detecting
path unavailable.
* When its peer endpoint is multi-homed, an endpoint should keep an*
* error counter for each of the destination
On Mar 11, 2011, at 7:44 AM, Will Yu wrote:
Hello,
I have a query on SCTP standard (RFC 4960). In section 8.2 Path Failure
Detection, it describes the action which end points should take in detecting
path unavailable.
When its peer endpoint is multi-homed, an endpoint should keep
A new Request for Comments is now available in online RFC libraries.
RFC 6148
Title: DHCPv4 Lease Query by Relay
Agent Remote ID
Author: P. Kurapati, R. Desetti,
B. Joshi
Status: Standards Track
The IESG has approved the following document:
- 'DHCPv4 lease query by Relay Agent Remote ID'
(draft-ietf-dhc-leasequery-by-remote-id-09.txt) as a Proposed Standard
This document is the product of the Dynamic Host Configuration Working
Group.
The IESG contact persons are Ralph Droms and Jari
The IESG has received a request from the Dynamic Host Configuration WG
(dhc) to consider the following document:
- 'DHCPv4 lease query by Relay Agent Remote ID'
draft-ietf-dhc-leasequery-by-remote-id-07.txt as a Proposed Standard
The IESG plans to make a decision in the next few weeks
On Apr 15, 2010, at 3:30 AM, Sambasiva Rao Manchili wrote:
Hallo,
I have a query related to SCT Mulithoming communication paths.
Host-X: (IPpx IPax): Multihomed Association with Host-Y (IPpy
IPay).
Host-X SCTP Client is running with SCTP stack provided by Vendor X
Host-Y SCTP
From: ietf-boun...@ietf.org on behalf of Randy Presuhn
Sent: Fri 5/14/2010 11:58 PM
To: ietf@ietf.org
Subject: Re: Query on SNMP Error Fields
Hi -
From: deepak rajaram deepak.raja...@gmail.com
To: ietf@ietf.org
Sent: Friday, May 14, 2010 4:18 AM
Subject: Query on SNMP
Hi -
From: shivendra.ku...@wipro.com
To: randy_pres...@mindspring.com; ietf@ietf.org
Sent: Saturday, May 15, 2010 9:02 AM
Subject: RE: Query on SNMP Error Fields
...
This is an strict expectation as per SNMP RFC specs ,
that the Set/GEt/GetNext requests set the error status
and error-index
Hi,
While the SNMP RFC(1157/2571/SNMPv3) mentions the behavior of Error Status
and Error Index field as will be set in the response and the value of
these fields in all set/get/getnext request is zero, It does not mention if
it is *mandatory* for these fields to have zero in set/get/getnext. Could
Hi -
From: deepak rajaram deepak.raja...@gmail.com
To: ietf@ietf.org
Sent: Friday, May 14, 2010 4:18 AM
Subject: Query on SNMP Error Fields
...
While the SNMP RFC(1157/2571/SNMPv3) mentions the behavior of Error Status
and Error Index field as will be set in the response and the value
To: ietf@ietf.org
Cc: Antonio Gambin antonio.gam...@nexustelecom.com; Markus Locher
markus.loc...@nexustelecom.com
Sent: Thursday, April 15, 2010 6:30 PM
Subject: SCTP Mulithoming Communication PATHS Query
Hallo,
I have a query related to SCT Mulithoming communication paths.
Host-X: (IPpx IPax
Hi Samba,
It seems there is firewall between host-X and host-Y, so the cross path packets
can not reach the destination?
In my understanding, some aspects may impact the result.
As far as I know, different vendors maybe provide different implementation.
some provide parallel path, like
: Antonio Gambin; Markus Locher
Subject: Re: SCTP Mulithoming Communication PATHS Query
Hi Samba,
It seems there is firewall between host-X and host-Y, so the cross path packets
can not reach the destination?
In my understanding, some aspects may impact the result.
As far as I know, different
Hallo,
I have a query related to SCT Mulithoming communication paths.
Host-X: (IPpx IPax): Multihomed Association with Host-Y (IPpy IPay).
Host-X SCTP Client is running with SCTP stack provided by Vendor X
Host-Y SCTP Server is running with SCTP stack provided by Vendor Y.
Notation.
IPpx
Hi,
I have a query regarding sctp multihoming behavior.
I have setup a multihomed association and this is my observation
Host_A (IP a): Local single Homed endpoint
Host_B (IP b(Primary), IP c(secondary)): Remote multiHomed endpoint
During Heartbeat I see that even though the Heart beat req
On Dec 4, 2009, at 12:57 PM, Sudhanva Mudigere Narayana Gowda wrote:
Hi,
I have a query regarding sctp multihoming behavior.
I have setup a multihomed association and this is my observation
Host_A (IP a): Local single Homed endpoint
Host_B (IP b(Primary), IP c(secondary)): Remote
Hi,
you really want to be asking this on the TSVWG list. CC and Reply-To set
accordingly.
Lars
On 2009-12-4, at 1:57, Sudhanva Mudigere Narayana Gowda wrote:
Hi,
I have a query regarding sctp multihoming behavior.
I have setup a multihomed association and this is my observation
Host_A
Dear RoHC ers,
I am having ambiguity regarding Context memory feedback option.
RFC 3843/ 5225 says:
The CONTEXT_MEMORY option informs the compressor that the decompressor
does not have sufficient memory
resources to handle the context of the packet flow, as the flow is
currently
Dear RoHC ers,
I am facing ambiguity regarding handling of Mode Cancellation for IR
IR-Dyn Packets in Profile -0x0004 (RFC 3843).
RFC 3843 says:
The Mode parameter for the value mode = 0 (packet types UOR-2, IR
and IR-DYN) is redefined
to allow the compressor to
On Sat, Dec 06, 2008 at 06:23:02AM -0800,
Dave CROCKER [EMAIL PROTECTED] wrote
a message of 37 lines which said:
One could imagine producing a BCP about common DNS implementation and
operation errors or, more positively, recommendations for implementation
and operation.
One could
for implementation and operation.
One could equally imagine some group actively pursuing improvements to the major
implementations (and operations) that have problems.
I seem to recall seeing small forays in this direction, in the past. Your query
might encourage an organized effort
, Kapil; ietf@ietf.org
Subject: Re: Query
Yes.
For ports specifically see
http://www.iana.org/assignments/port-numbers
Most registrations with individuals listed as the contact applied
directly to IANA.
Other registrations were made through publication of RFCs.
Let us know if you have any
or it is valid for life long?
Regards,
Kapil
From: Michelle Cotton [mailto:[EMAIL PROTECTED]
Sent: Wednesday, March 26, 2008 9:15 AM
To: Gupta, Kapil
Subject: Re: Query
There is no fee.
It can be done as quickly as a few days if the application form
or it is valid for life long?
Regards,
Kapil
From: Michelle Cotton [mailto:[EMAIL PROTECTED]
Sent: Wednesday, March 26, 2008 9:15 AM
To: Gupta, Kapil
Subject: Re: Query
There is no fee.
It can be done as quickly as a few days if the application form
Good Day All,
I have a question. Did any one try to register any port for his/their
application/service through IANA?
Please help.
Thank You,
Kapil
The information contained in this electronic mail transmission
may be privileged and confidential, and therefore, protected
Lots of people have.
See http://www.iana.org/protocols/apply/
Regards,
-drc
On Mar 25, 2008, at 6:16 AM, Gupta, Kapil wrote:
Good Day All,
I have a question. Did any one try to register any port for his/
their application/service through IANA?
Please help.
Thank You,
Kapil
The
Yes.
For ports specifically see
http://www.iana.org/assignments/port-numbers
Most registrations with individuals listed as the contact applied directly to
IANA.
Other registrations were made through publication of RFCs.
Let us know if you have any further questions.
Thank you,
Michelle
A new Request for Comments is now available in online RFC libraries.
RFC 5133
Title: Terminal Endpoint Identifier (TEI) Query
Request Number Change
Author: M. Tuexen, K. Morneault
Status: Standards Track
Date
The IESG has approved the following document:
- 'TEI Query Request Number Change '
draft-ietf-sigtran-rfc4233update-02.txt as a Proposed Standard
This document is the product of the Signaling Transport Working Group.
The IESG contact persons are Jon Peterson and Cullen Jennings.
A URL
The IESG has received a request from the Signaling Transport WG
(sigtran) to consider the following document:
- 'TEI Query Request Number Change '
draft-ietf-sigtran-rfc4233update-01.txt as a Proposed Standard
The IESG plans to make a decision in the next few weeks, and solicits
final
The IESG has approved the following document:
- 'DHCP Lease Query '
draft-ietf-dhc-leasequery-09.txt as a Proposed Standard
This document is the product of the Dynamic Host Configuration Working Group.
The IESG contact persons are Margaret Wasserman and Mark Townsley.
A URL
to this query.
Sridhar Aemalla___
Ietf mailing list
[EMAIL PROTECTED]
https://www1.ietf.org/mailman/listinfo/ietf
--On 8. oktober 2002 17:54 + Ramkumar Sankar [EMAIL PROTECTED]
wrote:
besides DHCP, are there any other protocols that use this subnet
directed-broadcast address while sending out IP packets?
SMB, the Microsoft-derived filesharing protocol, can be (mis)configured to
use
Ramkumar Sankar wrote:
RS is there any server implementation that replies to client requests using the
RS 'subnet directed-broadcast' rather than the limited ip broadcast (i.e all
RS 1s)? ...
Joe Touch replied:
JT What would be the utility in doing so, e.g., given the fact that they're
JT no
Hi,
I have a Solid database and since Solid DB doesn't have much
flexibility as compared to other user friendly DB's like MS SQL or
Oracle, can anybody tell me how do you migrate the data from the Solid
Database to say MS SQL 7.0.
Thanking you all in advance.
Regards
Mohit Mathur
Aneuya wrote:
HI,
This query is regarding Kerberos V5.
I want to know in case of WAN, what the flow of
request starting from the client to the application
server will be when it doesnt have the ticket for it ?
Does client have to know the adrress of Kerberos
server ?
Your help
HI,
This query is regarding Kerberos V5.
I want to know in case of WAN, what the flow of
request starting from the client to the application
server will be when it doesnt have the ticket for it ?
Does client have to know the adrress of Kerberos
server ?
Your help will be immensly appreciated
Hi ,
This is Shivendra and I am working on SNMP interfaces for a optical
network NE.
We are providing row creation mechanism on SNMP tables using SMI v2
directives( using
RowStatus). In the Set Pdu , we want to allow the requests for
multiple row creations over
same/different tables. We
98 matches
Mail list logo
