[Last-Call] Tsvart last call review of draft-ietf-lamps-rfc4210bis-14

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Reviewer: Colin Perkins
Review result: Ready with Issues

This document has been reviewed as part of the transport area review team's
ongoing effort to review key IETF documents. These comments were written
primarily for the transport area directors, but are copied to the document's
authors and WG to allow them to address any issues raised and also to the IETF
discussion list for information.

When done at the time of IETF Last Call, the authors should consider this
review as part of the last-call comments they receive. Please always CC
tsv-art@xxxxxxxx if you reply to or forward this review.

As noted at the end of Section 3.1.3, while this draft describes the message
syntax, the transfer protocols for conveying the messages in various
environments are specified separately. This seems reasonable but it would be
appropriate for the draft to either state, or to reference if described
elsewhere, the requirements for such transfer protocols. Some messages appear
to be quite large, so the transport presumably must provide reliable delivery,
support arbitrarily sized messages, handle fragmentation if the message is
larger than the path MTU, etc., and not all transport protocols provide these
services. There are presumably also requirements relating to security of the
transfer.

Section 5.3.22 discusses the use of polling to determine the status of an
outstanding response. The polling mechanism provides a checkAfter field to
indicate a time to wait before polling the resource again. It would be helpful
to provide, or reference, some guidance on setting that checkAfter value. It’s
unclear whether the polling interval should be set in some manner that depends
on the network conditions or server load, and so might need to be adaptive on
very short timescales, or if the interval is based on a person taking action to
provision a certificate with a much longer polling interval. The former might
interact poorly with the behaviour of the transfer protocol, and may need to be
set with care based on the chosen transport; the latter is perhaps less
dependent on the transport.

Overall, this seems broadly ready to progress from a transport perspective, but
would benefit from clarifications as noted above.

Colin


-- 
last-call mailing list -- last-call@xxxxxxxx
To unsubscribe send an email to last-call-leave@xxxxxxxx




[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Mhonarc]     [Fedora Users]

  Powered by Linux