RE: more comments from the IESG

["Hollenbeck, Scott" <shollenbeck@verisign.com>]

Got it; thanks, Ed.

-Scott-

> -----Original Message-----
> From: Edward Lewis [mailto:edlewis@arin.net]
> Sent: Wednesday, October 30, 2002 12:32 PM
> To: ietf-provreg@cafax.se
> Cc: edlewis@arin.net
> Subject: more comments from the IESG
> 
> 
> 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
>