Subject: [Int-area] Apps Directorate Review of draft-ietf-intarea-ipv4-id-update-05

From: Eliot Lear <[email-masked]>
Date: Sat, 02 Jun 2012 15:00:47 +0200

Document: draft-ietf-intarea-ipv4-id-update-05
Title: Updated Specification of the IPv4 ID Field
Reviewer: Eliot Lear
Review Date: 2 June 2012
IETF Last Call Date: 31 May  2012

Summary: This draft is quite well written, and is *very* nearly ready
for publication.

This draft is well written, and from the applications perspective
represents an important step to improving performance and error
reduction.  It uses a new requirements call-out style that I would class
as experimental, but not bad.  It is worth people reading this draft and
deciding if they agree with Joe's approach.

Major issues:

None (Yay!).

Minor issues:

Section 4 needs to be reconciled a bit with Section 6.1.  Specifically:

>  The IPv4 ID field can be useful for other purposes. 

And

  >> IPv4 ID field MUST NOT be used for purposes other than
   fragmentation and reassembly.

My suggestion is to drop the above sentence from Section 4.

In Section 6.1:

>    Datagram de-duplication can be accomplished using hash-based
>    duplicate detection for cases where the ID field is absent.

Under what circumstances would the ID field be absent?

>    >> Sources of non-atomic IPv4 datagrams using strong integrity checks
>    MAY reuse the ID within MSL values smaller than is typical.

Is the issue really the source using strong integrity checks or the
destination in this context?  What is typical?

Nit:

Shouldn't Sections 3, 4, and 5, really be Sections 2.1, 2.2, and 2.3?

Eliot

---

From: Joe Touch <[email-masked]>
Date: Sat, 2 Jun 2012 07:50:14 -0700

Hi, Eliot,

On Jun 2, 2012, at 6:00 AM, Eliot Lear wrote:

> Summary: This draft is quite well written, and is very nearly ready for publication.
> 
> This draft is well written, and from the applications perspective represents an important step to improving performance and error reduction.  It uses a new requirements call-out style that I would class as experimental, but not bad.  It is worth people reading this draft and deciding if they agree with Joe's approach.
> 
> Major issues:
> 
> None (Yay!).
> 
> Minor issues:
> 

The two are not contradictory - the ID can be useful, but generating it correctly is prohibitive and typically not done.

> Under what circumstances would the ID field be absent?

Replace "absent" with "known not unique".

> Is the issue really the source using strong integrity checks or the destination in this context?  What is typical?

The onus is on the source (of non-atomic datagrams) - if it includes strong integrity checks (that are presumably validated by the receiver), it then has more flexibility in its generation of the iD values.

> Shouldn't Sections 3, 4, and 5, really be Sections 2.1, 2.2, and 2.3?

Not subsections of 2, but perhaps "3, 3.1, 3.2"? 

Joe

---

From: "C. M. Heard" <[email-masked]>
Date: Sat, 2 Jun 2012 21:21:38 -0700 (PDT)

On Sat, 2 Jun 2012, Joe Touch wrote:
> > This draft is well written, and from the applications 
> > perspective represents an important step to improving 
> > performance and error reduction.  It uses a new requirements 
> > call-out style that I would class as experimental, but not bad.  
> > It is worth people reading this draft and deciding if they agree 
> > with Joe's approach.

FWIW, I thought it was helpful.

> The two are not contradictory - the ID can be useful, but 
> generating it correctly is prohibitive and typically not done.

After re-reading the text I agree with Eliot that it is confusing.  
Dropping the sentence in Section 4 would be fine.  Another 
possibility would be to reword it along the following lines:

  Other uses have been envisioned for the IPv4 ID field.

> Replace "absent" with "known not unique".

Better, I think, would be "not known to be unique".

> > Is the issue really the source using strong integrity checks or 
> > the destination in this context?  What is typical?
> 
> The onus is on the source (of non-atomic datagrams) - if it 
> includes strong integrity checks (that are presumably validated by 
> the receiver), it then has more flexibility in its generation of 
> the iD values.
> 
> > Nit:
> > 

That would be fine but I'm also OK with leaving the document the way 
it is (especially if it would get it into the publication queue 
faster).

//cmh

---

From: "C. M. Heard" <[email-masked]>
Date: Sat, 2 Jun 2012 22:00:01 -0700 (PDT)

On Sun, 3 Jun 2012, Glen Zorn wrote:
> On Sat, 2012-06-02 at 21:21 -0700, C. M. Heard wrote:
> 
> ...
> 
> > > > In Section 6.1:
> > > > 
> > > > 
> Except that the two are not semantically equivalent.

Indeed.  That was why I suggested the change.

//cmh

---

From: Glen Zorn <[email-masked]>
Date: Sun, 03 Jun 2012 11:53:57 +0700

...

...

---

From: Joe Touch <[email-masked]>
Date: Tue, 05 Jun 2012 17:42:15 -0700

Hi, all,

>    Other uses have been envisioned for the IPv4 ID field.

That's much better, IMO.

> Better, I think, would be "not known to be unique".

Sure.

> it is (especially if it would get it into the publication queue

I'll check. I'm not sure if it matters whether I do a rev inbetween IETF 
LC and final RFC Editor processing. If so, I'll check on this to see if 
it can be done with minimal content impact (maybe some fluff to explain 
the flow, but no semantic changes).

Joe

---

From: Joe Touch <[email-masked]>
Date: Tue, 05 Jun 2012 17:45:52 -0700

>> Except that the two are not semantically equivalent.

Sorry - I didn't catch that. When the datagram is atomic, under the new 
rules, we would *assume* that the ID field was not unique for a 
src/dst/protocol triple within the expected time (120 seconds).

I.e., the ID field is "assumed to not be useful for such purposes", 
which might be more accurate.

Joe

> _______________________________________________
> Int-area mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/int-area