Subject: [Rserpool] comments on draft-ietf-rserpool-enrp-02.txt

From: Harrie Hazewinkel <[email-masked]>
Date: Mon, 25 Mar 2002 23:45:10 +0100

Hi,

Some comments below on draft-ietf.rserpool-enrp-02.txt.
I apologize if some items are already discussed some time ago.

1)
--- section Abstract
There should be no references in the abstract.

2)
--- 1. Introduction
Provide a 1 paragraph overview of RSERPOOL.
Make reading easier and its first 2 paragraphs are exactly
what is the 'abstract' is.

3)
--- 1.2 Definitions (there is no 1.1)
Defines the same terms as the architecture document.
Just refer to those and define only those not in the
arch document and are ENRP specific.

4)
"     Network Byte Order:
	  Most significant byte first, a.k.a Big Endian."
This definition seems odd. OK, big endian is used
in this document, which makes it not a term.

5)
-- 3.1 ENRP Parameter formats
Encoding seems not network efficient.
Also why does the parameter length include the
parameter type and the parameter length??
I suspect that while parsing or creating the
'type-length-value' item the extra length of
4 does not provide additional information
to an ENRP protocol entity.

Why are the 2 highest order bits of the type not
specifically drawn in the packet layout above??

6)
--- 3.2  ENRP Message Formats
IMHO, the messages defined do also need protocol
semantics indicating an order. If send what is the
response (if there is a response) or what action must
be taken by the receiving protocol entity.
This is somehow done in section '4. ENRP Operation Procedures',
but could be made more clear.

7)
--- 4.1 Basic ENRP Operations
IMHO, 'ENRP Operations' is better, this implies there is also
another level of operations.

This section also mentions various times ASAP as protocol.
More precise, for instance, section 4.1.1 'PE Registration' is confusing.
It first says:
"This action is part of the ASAP protocol and is defined in [ASAP]."
but it also says:
"To register itself with the name space, a PE sends a REGISTRATION
message over the ENRP client channel to its home ENRP server."

Is it part of ASAP or ENRP??

8)
--- 5.  Variables and Time Constants
I don't understand where this fits into the ENRP protocol.

Cheers,

Harrie

Internet Management Consulting
tel: +39-3474932300 / +31-625357135
mailto: [email-masked]                  http://www.lisanza.net/

_______________________________________________
rserpool mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/rserpool

---

From: Harrie Hazewinkel <[email-masked]>
Date: Sat, 30 Mar 2002 16:38:51 +0100

--On Friday, March 29, 2002 1:10 PM -0600 Qiaobing Xie 
<[email-masked]> wrote:
> This is kind of a popular way of defining parameter length in many other
> IETF RFCs. We would like to keep it the same for consistence.

I don't believe this is an argument, because I have seen also
IETF RFCs which do NOT have that part included in the length.
So you are inconsistent with those where the only the data
is indicated. :-))

Again I suggest dropping the inclusion of the 4 bytes of the
type and length in the length-value. IMHO, it lowers CPU
cycles and that is not influenced by hardware or software.

> Doing that may mislead people to think the 2 bits are not part of the
> type field.

I disagree. The text also suggests they are not part of the
type. Also they are not used for the type of the message, but
for the action that a receiving entity is allowed to take upon
reception of a not recognized type.

Now I come with some weird case:
A message type of binary value 01000001 is received.
The recepient does not understand this type, but how is he
going to understand the '01' part that are the 2 highest
order bits??

Resulting the recipeint does not know that it needs to report the
unrecognized message in an 'Unrecognized Parameter Type'.

Therefore, I suggest

1) mentioning those bits in the drawing
or
2) move those bits into the message flag.

I even prefer 2) since you already do this for

3.2.1 PEER_PRESENCE message

     0                   1                   2                   3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |   Type = 0x1  |0|0|0|0|0|0|0|R|        Message Length         |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    :                  Sender's Server ID param                     :
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    :              Receiver's Server ID param (optional)            :
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    :                Authorization Parameter (optional)             :
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

    The receiving server's ID does not need to be included if the
    message is being multicasted.

    "Reply_required" (R) flag shall be set to '1' if response to this
    message is required, otherwise set to '0'.

The Reply required bit requires also an action upon receiving the
message type 0x1.

Harrie

Internet Management Consulting
tel: +39-3474932300 / +31-625357135
mailto: [email-masked]                  http://www.lisanza.net/
Key fingerprint = F232 4B68 2B89 3ED7 FF41  F892 BCC9 CE9C 2F6D 51D7