more comments from the IESG

[Edward Lewis <edlewis@arin.net>]

Due to a snafu these comments were separated from the original list. 
(It's not like the IESG is piling on comments, these were meant to be 
part of the previous list sent to the list).

>  From: Allison Mankin <mankin@psg.com>
>  Date: mån okt 21, 2002  20:20:55 Europe/Stockholm
>  To: iesg-secretary@ietf.org, mankin@psg.com, paf@cisco.com, sob@harvard.edu
>  Subject: Discuss on provreg-epp and provreg-epp-tcp
>
>  ********
>  ISSUES with draft-ietf-provreg-epp-07.txt
>  1.
>       The transport mapping MUST manage congestion.
>
>    This wording would be better replaced by the following (and
>    my comment takes into account both Scott's request and
>    the fact that the transport mapping may be over SMTP or
>    something other than a "transport" such as TCP or SCTP.
>
>       The transport mapping MUST be onto a transport such
>       as TCP or SCTP that provides congestion avoidance that
>       follows RFC 2914, or if it maps onto a protocol such
>       as SMTP or BEEP, then the performance issues need to
>       take into account issues of overload, server availability
>       and so forth.

I know that the above addresses my concerns.  (That's about all I 
will add as a comment as it's up to the WG to determine.)

>
>  2.
>
>  Within the optional dcp (data collection policy) element:
>  there is a non-technical spin in at least the
>  following label definition, what kind of marketing is meant?
>
>         <contact/>: Contact for marketing purposes.
>
>  Please add more to this definition so that is more neutral in
>  in its terminology.
>
>  About the recipient and data retention
>  elements - how would they provide a means to allow provisioning
>  a strick privacy policy in some use of EPP (they are not used
>  in one of the companion documents? The author is asked to
>  give a few sentences to encourage a view that they have teeth
>  (more so than their parent P3P) in EPP.

This will be discussed at the Atlanta meeting.  But don't hold back 
on dicussing this in email ('cause not everyone will be making it to 
Atlanta).

>  3.
>
>  This is a general question, but I would like the author, as
>  an expert on the topic, to send an written answer to the IESG,
>  not to make a change to this document set:
>
>     How does IESG and the community check the extensive XML in a
>     specification like this (analogous to the ABNF and MIB
>     checking described that is done regularly...)?  How did you
>     check what's here?  Why might it not matter?
>
>  ******
>  ISSUES with  draft-ietf-provreg-epp-tcp-05.txt
>  1.
>    An EPP client streams EPP commands to an EPP server on an established
>    TCP connection.  A client MAY establish multiple TCP connections to
>    create multiple command exchange channels.  A server MAY limit a
>    client to a maximum number of TCP connections based on server
>    capabilities and operational load.
>
>  It is not a good thing for the net for services to choose
>  this approach.  A MAY like this is problematic for congestion
>  control reasons.  I would like to change this language from
>  "MAY establish" to "MAY but SHOULD NOT" and from "A server MAY
>  limit" to "A server SHOULD limit"
>
>
>  2.
>
>  For references to TCP, besides RFC 793, you need:
>
>      RFC 2581, 2914.

-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                          +1-703-227-9854
ARIN Research Engineer