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: Qiaobing Xie <[email-masked]>
Date: Fri, 29 Mar 2002 13:10:44 -0600

Hi, Harrie,

Please see my comments in-line....

-Qiaobing

> There should be no references in the abstract.

ok

> what is the 'abstract' is.

ok, will try to improve in next revision

> arch document and are ENRP specific.

good point. will improve

> in this document, which makes it not a term.

Agree, it is a statement, not a term. will move it into the text below.

> to an ENRP protocol entity.

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.

> specifically drawn in the packet layout above??

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

> but could be made more clear.

An alternative is to move "ENRP Operation Procedures" up and put message
format definitions to the end of the document. Not sure which way is
better.

> another level of operations.

agree. there used to be another level but it's gone. will change it.

> Is it part of ASAP or ENRP??

The two protocols are closely related to each other in both definitions
and operations. This is the challenge facing us in writing the docs.
will try to improve on this.

> I don't understand where this fits into the ENRP protocol.

This will be further clarified in later revisions.

---

From: Qiaobing Xie <[email-masked]>
Date: Fri, 29 Mar 2002 13:10:44 -0600

Hi, Harrie,

-Qiaobing

ok

good point. will improve

---

From: "La Monte Henry Piggy Yarroll" <[email-masked]>
Date: Fri, 29 Mar 2002 18:49:27 -0600

> > I apologize if some items are already discussed some time ago.
...
> IETF RFCs. We would like to keep it the same for consistence.

It makes the code for looping through TLV's very simple.  You need
only keep adding the length field.  This is a big win in both software
AND hardware implementations.

---

From: "La Monte Henry Piggy Yarroll" <[email-masked]>
Date: Fri, 29 Mar 2002 18:49:27 -0600

...