headers
Maureen.Stillman | 6 Sep 2002 17:24
Picon

Rserpool milestones

For some strange reason, someone on 9/4/2002 changed all of our Rserpool milestones to done.  I don't know
how this happened.   Last week the milestones indicated dates that needed to be changed to reflect the
current status.  In any case, we are not all done with the milestones.

Lyndon and I are working on updating the milestones.  There are a number of new documents that we need to add as
well.  I'll let you know when the page is updated.

-- maureen
Permalink | Reply | 0 comments |
headers
Maureen.Stillman | 6 Sep 2002 17:27
Picon

Rserpool WG Meeting in Atlanta - IETF # 55

I have requested a 2 hour time slot in Atlanta for Rserpool.   We will start working on an agenda in a few weeks.

-- maureen
Permalink | Reply | 0 comments |
headers
Maureen.Stillman | 16 Sep 2002 21:21
Picon

Draft Agenda for IETF #55

We don't know our time slot yet, but we should know soon.

Please send me any agenda items.

-- maureen
Permalink | Reply | 0 comments |
headers
Qiaobing Xie | 20 Sep 2002 00:34

Re: Comments on draft-ietf-rserpool-asap-04.txt

Hi, Thomas,

Sorry for the late response, both Randy and myself were taking vacation. Pls see
my comments in-line..

Thomas Dreibholz wrote:
...
> some comments on draft-ietf-rserpool-asap-04.txt:
> 
> - - DEREGISTRATION_RESPONSE:
> The "Pool Element Parameter" field must be optional, since the nameserver
> cannot generate this field if the pool element identified by Pool Handle
> Parameter and PE Identifier Parameter in a DEREGISTRATION message is not
> existing in the namespace.
> There should also be an error code (e.g. 7) for "Pool Element not found".

Agreed. In fact, I'd suggest to replace the PE TLV with a PE Identifier TLV in
both reg and de-reg responses. Building the PE TLV again from parsed attributes
when sending the response is really a pain, while simply mirroring the original PE
TLV back does not seem to serve any purpose. 

> - - There must be an error message type for the case of an unknown message type
> is received. For example, a client sends a message type 0xab to the
> nameserver. This type is unknown, therefore an error should be returned.
> Suggestion:
> +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
> ++++ Type = 0xff | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | Message Length +++++
> +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
> ++++ Error Parameter                                              +++++
> +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
(Continue reading)

Permalink | Reply | 1 comment |
headers
Maureen.Stillman | 25 Sep 2002 15:47
Picon

Tentative agenda slot for IETF # 55

We are tentatively scheduled for Monday, November 18 at 15:30 - 1730.

-- maureen
Permalink | Reply | 0 comments |
headers
Randall Stewart | 27 Sep 2002 14:48
Picon
Picon

Re: Comments on draft-ietf-rserpool-asap-04.txt

Qiaobing Xie wrote:
> Hi, Thomas,
> 
> Sorry for the late response, both Randy and myself were taking vacation. Pls see
> my comments in-line..
> 
and overworked in other areas :-<

> Thomas Dreibholz wrote:
> ...
> 
>>some comments on draft-ietf-rserpool-asap-04.txt:
>>
>>- - DEREGISTRATION_RESPONSE:
>>The "Pool Element Parameter" field must be optional, since the nameserver
>>cannot generate this field if the pool element identified by Pool Handle
>>Parameter and PE Identifier Parameter in a DEREGISTRATION message is not
>>existing in the namespace.
>>There should also be an error code (e.g. 7) for "Pool Element not found".
> 
> 
> Agreed. In fact, I'd suggest to replace the PE TLV with a PE Identifier TLV in
> both reg and de-reg responses. Building the PE TLV again from parsed attributes
> when sending the response is really a pain, while simply mirroring the original PE
> TLV back does not seem to serve any purpose. 
>  

I agree too

>
(Continue reading)

Permalink | Reply | 0 comments |
headers
Qiaobing Xie | 27 Sep 2002 20:07

Re: Comments on draft-ietf-rserpool-asap-04.txt

Hi, Michael,

Tuexen Michael wrote:
> 
> Dear Randy, Qiaobing,
> 
> see my comments below. However one remark: I tried to
> use the cvs diff command to find quickly Qiaobings changes.
> What I found was that the whole document (every line) was changed.
> The cvs diff is correct, the doc has now DOS line endings. After
> I have made my changes I will check it in with UNIX one again. Or
> should I try MacOS ones? Just kidding.

This is due to that I used emacs, diff, and cvs from my Windows side and I forgot
to 'vi' those new lines out before committing the files. Will remember that next
time :-)

...
> > > A PEER_ERROR message is defined in ENRP v04 already.
> > Probably the same needs to be
> > > done for ASAP. Since ENRP and ASAP are on different paths,
> > > they need to define their error message separately.
> >
> > Either that or more fodder for the common parameters document...
> >
> A error cause is already available in the Common Parameter doc.
> I will commit text for that and also for the error causes of
> the common parameter doc.

Thomas and I meant to say that we also need a stand-alone op error *message* on
(Continue reading)

Permalink | Reply | 0 comments |
headers
Maureen.Stillman | 27 Sep 2002 21:13
Picon

Milestones have been updated

The Rserpool milestones on the Rserpool WG web site have now been updated.
See http://www.ietf.org/html.charters/rserpool-charter.html

-- maureen
Permalink | Reply | 0 comments |
headers
Qiaobing Xie | 27 Sep 2002 23:39

Re: Comments on draft-ietf-rserpool-asap-04.txt

Hi, Michael,

....
> Hmmmm, OK, it seems that we agree that an ENRP server SHOULD always
> listen on a TCP and SCTP socket, MAY listen on a UDP multicast socket and always
> uses the same port number.  What is new (for me) that the response of the
> SERVER_HUNT is sent by TCP or SCTP. This would mean that the NS is a client. Hmm.
> In my understanding the SERVER_HUNT was sent as UDP unicast. Thats all. The PU 
> has to set up an SCTP assoc or TCP connection for doing name resolution requests. 
> If mutlicast is not available, the first step (send UDP multicast, receive UDP 
> unicasr) is omitted. For security this would be simpler, because in both case 
> would the PU start the communication.

I sense that more clarifications are needed for server hunt in both enrp
and asap. Let's lay it out with more details here (assuming the
to-be-defined well known asap port is 5151 for both TCP and SCTP, and
the well-known IP m-cast channel for asap is 244.1.2.3):

After an ENRP server (aka NS) finishes its initialization and 
enters the service, it:
1) MUST listen for incoming asap messages on SCTP/port=5151;
2) optionally also listens for incoming asap messages on TCP/port=5151;
3) optionally join m-cast group 244.1.2.3 (via a UDP or TCP socket, but 
   this shouldn't matter) for incoming m-cast asap messages.

If the NS choice not to support TCP-based PUs, it won't do 2).
Similarly, if m-cast is not available at the NS site, it won't do 3).

Now let's move on to the PE/PU side.
(Continue reading)

Permalink | Reply | 10 comments |
headers
Ong, Lyndon | 27 Sep 2002 23:50

RE: Comments on draft-ietf-rserpool-asap-04.txt

Dear Randy, Qiaobing,

see my comments below. However one remark: I tried to
use the cvs diff command to find quickly Qiaobings changes.
What I found was that the whole document (every line) was changed.
The cvs diff is correct, the doc has now DOS line endings. After
I have made my changes I will check it in with UNIX one again. Or
should I try MacOS ones? Just kidding. 

Best regards
Michael

Michael Tuexen   Tel.:   +49 89 722 47210
Siemens AG       Fax:    +49 89 722 48212
ICN WN CC SE 7   e-mail: Michael.Tuexen <at> siemens.com

> -----Original Message-----
> From: Randall Stewart [mailto:randall <at> stewart.chicago.il.us]
> Sent: Friday, September 27, 2002 2:48 PM
> To: Qiaobing Xie
> Cc: Thomas Dreibholz; rserpool <at> ietf.org
> Subject: Re: [Rserpool] Comments on draft-ietf-rserpool-asap-04.txt
> 
> 
> Qiaobing Xie wrote:
> > Hi, Thomas,
> > 
> > Sorry for the late response, both Randy and myself were 
> taking vacation. Pls see
> > my comments in-line..
(Continue reading)

Permalink | Reply | 0 comments |

Gmane