Subject: [Gen-art] gen-art LC review of draft-ietf-tcpm-1323bis-19

From: Scott Brim <[email-masked]>
Date: Mon, 10 Feb 2014 11:49:56 -0500

I am the assigned Gen-ART reviewer for this draft. For background on
Gen-ART, please see the FAQ at

<http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.

Please resolve these comments along with any other Last Call comments
you may receive.

Document: draft-ietf-tcpm-1323bis-19
Reviewer: Scott Brim
Review Date: 2014-02-10
IETF LC End Date: 2014-02-18
IESG Telechat date: not yet

Summary: Ready with a minor issue

Major issues: none

Minor issues:

> For brevity, the full discussions of the merits and history behind
> the TCP options defined within this document have been omitted.
> [RFC1323] should be consulted for reference.

  The reader is referred to RFC 1323 for background information
  (basically an informative reference) ... but if this draft obsoletes
  RFC 1323, can it refer the reader to it?

Nits/editorial comments: none

Thanks ... Scott

---

From: Scott Brim <[email-masked]>
Date: Mon, 10 Feb 2014 13:17:53 -0500

---------- Forwarded message ----------
From: Scott Brim <[email-masked]>
Date: Mon, Feb 10, 2014 at 11:49 AM
Subject: gen-art LC review of draft-ietf-tcpm-1323bis-19
To: gen-art <[email-masked]>

Major issues: none

Thanks ... Scott

---

From: "Scheffenegger, Richard" <[email-masked]>
Date: Mon, 10 Feb 2014 19:08:49 +0000

Hi Scott,

Thanks for your review!

It was our understanding that obsoleted and historic rfcs can still be referenced...

During the discussion in the WG, much of the discussion, and historic conjecture was decided to have to go, to be replaced with "lessons learned". But for someone not familiar, the old text describing some of the thoughts that went into the design of the options, might still be useful to know..

It's unclear to me how to address your comment.

Do you propose to remove the 2nd sentence? 

Or is the question you actually ask in your comment something to be answered by IESG, and either requires no change, or potentially the removal of all 1323 references throughout the document...

Richard Scheffenegger

> -----Original Message-----
> From: Scott Brim [mailto:[email-masked]]
> Sent: Montag, 10. Februar 2014 19:18
> To: gen-art; [email-masked]
> Subject: Fwd: gen-art LC review of draft-ietf-tcpm-1323bis-19
> 
> I am the assigned Gen-ART reviewer for this draft. For background on Gen-
> ART, please see the FAQ at
> 
> Please resolve these comments along with any other Last Call comments you
> may receive.
> 
> > For brevity, the full discussions of the merits and history behind the
> > TCP options defined within this document have been omitted.

---

From: Scott Brim <[email-masked]>
Date: Mon, 10 Feb 2014 14:58:35 -0500

On Mon, Feb 10, 2014 at 2:45 PM, David Borman <[email-masked]> wrote:
> Scott,
>
> This is an informative reference, not a normative reference.  I'd only see this as an issue if it was the latter, which it isn't.  The protocol specification in 1323bis stands on its own, which is why it obsoletes 1323.  This is just an informative reference so the reader knows that the original background material in 1323 was omitted in 1323bis, and they should look at 1323 if they want that additional history.  We decided there wasn't much value in rewriting the background material to reflect current terminology and situations, and instead just refer the reader to 1323, which can be read within the 20+ year old context in which it was originally written.
>
>                         -David

It's a "structure of our documents" question. I don't know the answer
because I've never seen this done before. Obsoleted RFCs are included
in informational references all the time, but explicitly saying "if
you want a more in-depth understanding, go look at the RFC that we are
replacing with this one" made me wonder, and I didn't find an answer
in a quick search.

If you've investigated and this is normal, then great. Otherwise I'm
sure one of my gen-art colleagues will have an answer for us very
soon. If not, the IESG will.

... Scott

---

From: David Borman <[email-masked]>
Date: Mon, 10 Feb 2014 19:45:36 +0000

Scott,

This is an informative reference, not a normative reference.  I’d only see this as an issue if it was the latter, which it isn’t.  The protocol specification in 1323bis stands on its own, which is why it obsoletes 1323.  This is just an informative reference so the reader knows that the original background material in 1323 was omitted in 1323bis, and they should look at 1323 if they want that additional history.  We decided there wasn’t much value in rewriting the background material to reflect current terminology and situations, and instead just refer the reader to 1323, which can be read within the 20+ year old context in which it was originally written.

			-David

> Nits/editorial comments: none

----------------------------------------------------------------------
The information contained in this transmission may be confidential. Any disclosure, copying, or further distribution of confidential information is not permitted unless such privilege is explicitly granted in writing by Quantum. Quantum reserves the right to have electronic communications, including email and attachments, sent across its networks filtered through anti virus and spam software programs and retain such messages in order to comply with applicable data security and retention requirements. Quantum is not responsible for the proper and complete transmission of the substance of this communication or for any delay in its receipt.