[DNA] Re: Last Call: 'Link-layer Event Notifications for Detecting NetworkAttachments' to Informational RFC (draft-ietf-dna-link-information)

[Greg Daley <Greg.Daley@eng.monash.edu.au>]

Dear Pekka,

I understand your point about review by peer organizations, if this
were a standards or BCP document.

It is purely informational, and has been reviewed by several people who
have worked both within IETF and other organizations, without formal liaison
with other organizations.

The document has received extensive review, as described in:

https://datatracker.ietf.org/public/pidtracker.cgi?command=view_comment&id=45426

No document would be compliant with an informational RFC in any case,
so I can't really see the point of your comment regarding implementation 
compliance.

Informational documents are often used to provide technical guidance based
on the behaviour of particular protocols (rather than the standards
bodies that
originally developed them).  This is the case with this document, and I
can't
see that there's a particular reason to avoid that if the guidance
is generally useful.

Regarding the value of implementation hints in general: identification
of the
applicability, and delineating what is useful in some situations, is perhaps
worthwhile.  At this late stage though, any particular guidance or text you
can provide to assist this would be illustrative.

I'm not sure that this would be absolutely necessary to block the document,
but if there's a straightforward resolution, perhaps changes could be made.

(Sorry, but I will be incommunicado again until 8 jan).

Greg

----- Original Message -----
From: Pekka Savola <pekkas@netcore.fi>
Date: Thursday, December 21, 2006 5:05 pm
Subject: Re: Last Call: 'Link-layer Event Notifications for Detecting
Network Attachments' to Informational RFC  (draft-ietf-dna-link-information)
To: Suresh Krishnan <suresh.krishnan@ericsson.com>
Cc: iesg@ietf.org, dna@eng.monash.edu.au, dna-chairs@tools.ietf.org

> On Wed, 20 Dec 2006, Suresh Krishnan wrote:
> >  I do not see what you mean by "implementation hints should be 
> removed or 
> > reworded". Do you mean not using normative language?
> 
> I mean that if the intent of this document is just to describe the 
> specifications or implementations in general (for general 
> background), 
> it should not try to give advice on implementations.  Doing so is 
> problematic for multiple reasons; first, the IETF is not in charge 
> of 
> developing these techniques, and any 'hints' we give need to be 
> carefully reviewed (via the liaison process) by the authoritative 
> organizations.  Second, it confuses the meaning of this draft if 
> you 
> expect that implementations would say "compliant with 
> draft-ietf-dna-link-information".  Third, giving these hints may 
> not 
> be appropriate in an Informational document, i.e., it might require 
> wider review (though I don't have a strong opinion on this).
> 
> All in all, it would be clearer if there were no implementation 
> hints 
> at all, but if those were clearly marked (example: the DKIM base 
> spec) 
> and in lowercase, it might be clear enough.
> 
> Another way to approach this is to remove recommendation about 
> implementation hints but describe them like 'Some implementations 
> implement FOO which has XXX benefit for DNA purposes, with YYY 
> drawbacks", i.e., more like what implementations are doing (and 
> why) rather than what they should do.
> 
> -- 
> Pekka Savola                 "You each name yourselves king, yet the
> Netcore Oy                    kingdom bleeds."
> Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings
>