ID-NITS [ was: RE: Re: More IESG comments on draft-ietf-ipsec-ciph-aes-cbc]

["Wijnen, Bert (Bert)" <bwijnen@lucent.com>]

I am willing to let go. But....

My main concern is that we have these ID-nits and we seem 
unwilling to enforce (for valid and sometimes invalid reasons).
And so we set precedents for others to ignore these specific
NITS and for people to question if any of the NITS are really
hard rules or just "buraucracy". 

I have been saying for quite a while... 

  We need (as short as possible) a set of NITs that we really care
about and that we're willing to enforce. All the others that we are
willing to relax on we should relax on and only show them as
guidelines or "it would be nice if"... and such... but on that latter
set we should then never hold up a document.

Thanks,
Bert 

> -----Original Message-----
> From: Russ Housley [mailto:housley@vigilsec.com]
> Sent: dinsdag 22 april 2003 15:30
> To: bwijnen@lucent.com
> Cc: smb@research.att.com
> Subject: Fwd: Re: More IESG comments on draft-ietf-ipsec-ciph-aes-cbc
> 
> 
> Bert:
> 
> The authors are pushing back on your comment.  Do you want to 
> hold strong? 
> Or, are you willing to let this one go?
> 
> Russ
> 
> 
> >Date: Mon, 21 Apr 2003 16:04:35 -0700
> >From: "Scott G. Kelly" <scott@airespace.com>
> >To: Russ Housley <housley@vigilsec.com>
> >CC: sheila.frankel@nist.gov, byfraser@cisco.com, tytso@mit.edu
> >Subject: Re: More IESG comments on draft-ietf-ipsec-ciph-aes-cbc
> >
> >Hi Russ,
> >
> >I think I understand the general intent here, but I'm 
> wondering if it is
> >not slightly misguided. The addresses on pages 7-8-9 are 
> within sample
> >esp packets. These were provided because implementers asked for real
> >packets they could test their implementations with. One way to
> >reasonably provide such sample packets is by using RFC 1918 
> addressing,
> >although since they are taken from an actual network, almost any
> >addressing could be used.
> >
> >I guess I would frame the question this way: is the use of RFC 1918
> >addressing in such an example destructive? I don't see how 
> it could be,
> >since in order to actually test these packets, someone would 
> most likely
> >feed them into their implementation from a file or via a 
> direct function
> >call, rather than by first injecting them onto a production 
> network. I
> >also think (based on many years of implementation 
> experience) that if it
> >*were* important to get them directly from the lan, that the 
> implementer
> >would be using a private segment for such testing.
> >
> >Regenerating these examples with some other range of addresses seems
> >like make-work, and it is not clear to me that there is rational
> >justification. Am I missing something obvious here?
> >
> >Thanks,
> >
> >Scott'
> >Russ Housley wrote:
> > >
> > > Sheila, Scott & Rob:
> > >
> > > Here is another IESG comment.
> > >
> > > >Our ID-nits page at http://www.ietf.org/ID-nits.html says:
> > > >
> > > >  o Addresses used in examples should prefer use of fully
> > > >    qualified domain names to literal IP addresses, and prefer
> > > >    use of example fqdn's such as foo.example.com to real-world
> > > >    fqdn's. See RFC 2606 for example domain names that 
> can be used.
> > > >    There is also a range of IP addresses set aside for 
> this purpose.
> > > >    These are 192.0.2.0/24 (see RFC 3330). Private 
> addressess that
> > > >    would be used in the real world should be avoided in 
> examples.
> > > >
> > > >So to me that means that the IP addressses used on pages 
> 7-8-9 are
> > > >not acceptable.
> > >
> > > Russ
>