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

From: Suresh Krishnan <[email-masked]>
Date: Wed, 20 Dec 2006 18:14:40 -0500

Hi Pekka,
   I do not see what you mean by "implementation hints should be removed 
or reworded". Do you mean not using normative language?

Cheers
Suresh

Pekka Savola wrote:
> On Tue, 19 Dec 2006, Suresh Krishnan wrote:
>>>  I do however have one bigger "meta-comment".  The draft is aiming
>>>  Informational, but includes normative specification (also in 
>>> uppercase).
>>>  What is the goal of this draft?  Offer information on how various link
>>>  layers specify L2 notifications (aimed at the general public/background
>>>  for DNA WG, and possibly implementors), and/or to make implementation
>>>  specifications of its own (aimed at implementors)?
>>
>> It is the former.
> 
> In that case I think the recommendations ("implementation hints") should 
> be removed or reworded in such a way impact (or lack thereof) is 
> clearer.  For example, draft-ietf-dkim-base-07.txt includes some similar 
> text but it's clearly separated from the rest; that might be one way to 
> go, but other approaches are probably also possible.
>

---

From: Greg Daley <[email-masked]>
Date: Fri, 22 Dec 2006 15:22:39 +1100

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 <[email-masked]>
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 <[email-masked]>
Cc: [email-masked], [email-masked], [email-masked]

> 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
>

---

From: Greg Daley <[email-masked]>
Date: Mon, 08 Jan 2007 09:38:50 +1100

Hi Sam,

The document has not been aimed at informational to reduce the
requirements for review.

The document has always been viewed as informational as it was intended
to provide context for implementors of DNA solutions which require
link-up indications.

There are no standards recommendations in the document.  No packets are
transferred and no protocol is defined.

What is provided are pointers for constructing internal APIs, which as I
understand, are not normally defined in IETF standards documents.

The difference with this document is that it relies upon packet transfer
behaviour of lower layer protocols.  The descriptions of protocols have
been provided to illustrate where packet transfer is available, and each
has been reviewed by
experts on the subject matter.

The decision of whether to make liaisons with other organizations formal or
informal was made with the ADs.

So is the question you have regarding the quality of the review, or on
the process itself?

Greg

----- Original Message -----
From: Sam Hartman <[email-masked]>
Date: Monday, December 25, 2006 1:56 pm
Subject: Re: Last Call: 'Link-layer Event Notifications for Detecting
Network Attachments' to Informational RFC (draft-ietf-dna-link-information)
To: Greg Daley <[email-masked]>
Cc: Pekka Savola <[email-masked]>, [email-masked],
[email-masked], Suresh Krishnan
<[email-masked]>, [email-masked]

> >>>>> "Greg" == Greg Daley <[email-masked]> writes:
> 
>    Greg> Dear Pekka, I understand your point about review by peer
>    Greg> organizations, if this were a standards or BCP document.
> 
>    Greg> It is purely informational, and has been reviewed by several
>    Greg> people who have worked both within IETF and other
>    Greg> organizations, without formal liaison with other
>    Greg> organizations.
> 
> I'm uncomfortable with the practice of marking a document
> informational to reduce the review required and to avoid coming to
> consensus on important issues.
> 
> 
> I'd like to understand in this instance why informational requires
> less review than for another document category?  Do you intend this to
> be an ietf consensus recommendation?  If so, why does it require less
> review?  If not, what is the value in publishing?
> 
>

---

From: Suresh Krishnan <[email-masked]>
Date: Mon, 15 Jan 2007 18:45:37 -0500

Hi Sam,
   Thanks for the review. Sorry I could not reply earlier since I was on 
vacation. Please find comments inline.

Thanks
Suresh

> consensus on important issues.

I can assure you this is not the case. The document has had extensive 
review both within the WG and outside the WG. Greg was talking about a 
formal liaison review (with related SDOs) not being done.

> review?  If not, what is the value in publishing?

As I said earlier, this document has had extensive review. It is indeed 
a consensus recommendation from the dna wg.

---

From: Suresh Krishnan <[email-masked]>
Date: Mon, 15 Jan 2007 19:12:16 -0500

Hi Matt,

Thanks
Suresh

Matt Mathis wrote:
> This document is an informational catalog of link state information available
> from well-known access technologies, yet many portions read like a standard,
> including the use of prescriptive language and RFC 2119 terminology. This is
> likely to be confusing to future implementers.
> 
> For example:
> 
>    "If a link up with the R-flag set was generated, another link up MUST
>    follow up as soon as....   The event attributes MUST indicate
>    whether the packets transmitted since the previous notification were
>    presumed to be blocked (B-flag) or allowed (A-flag) ...
> 
> Where "R-flag", "B-flag" and "A-flag" are constructs of this draft and not
> some other document.
> 
> In many parts of the document, standards language is used to emphasize
> relationships that are implicit in the definitions.  For example it defines
> "Link up" to be an event signifying that the interface has become capable of
> communicating data packets (my paraphrase).  The document tends to say
> something like "Event X MUST generate Link-Up ..... which MUST be signaled to
> the IP layer" (my rewrite), rather than "The [device] becomes capable of
> communicating data packets on event X, so (by definition) it is Link-Up."

Do you feel strongly about the normative language in the document? If so 
we can spend some time to rewrite the text. But since it is an 
informational document, no one can really claim compatibility to 
draft-ietf-dna-link-information, can they?

> 
> For some of the specific link technologies, this language seems to be an
> after-the-fact specification of how current implementations actually work.
> Most of the document is written in an appropriate observational language:
> "Since the [device] becomes capable of communicating data packets on event
> [X], this is an appropriate indication of link up."   This "observational"
> style is by far best for an Informational document.
> 
> It would be appropriate to rewrite all paragraphs using 2119 language, as well
> as the less formal "must" used in 3 places.
> 
> Some specific comments:
> PDP is not defined

OK. Will take care of this.

> 
> It says: "The activation of a such secondary PDP Context MUST NOT generate
> another link up event notification."  Given that other device types permit
> link-up events that do not require new IP parameters, it seems out of place to
> forbid this case.  (even ignoring the MUST) Perhaps something like "it is not
> desirable treat every new PDP context as a link change because...."

OK. How about

"The activation of such a secondary PDP context does not usually 
generate a link up event since it does not require new IP parameters".

---

From: Suresh Krishnan <[email-masked]>
Date: Wed, 17 Jan 2007 18:48:31 -0500

Hi Matt,
   Please find comments inline.

Thanks
Suresh

Matt Mathis wrote:
> Well, people can quote normative language out of context, which is likely to
> be very confusing.  At the very least MUST->must (etc) everywhere.  I don't
> know how picky the IESG is about this.  They should be because it dilutes all
> standards to allow documents that resemble standards but are not.

The document aims to be informational and will be indicated as such in 
the Category field of the eventual RFC(if any). If you have strong 
feelings about upper case MUSTs or if the IESG has any problems with 
this, this would be an easy change to make.

> 
> Defining R-flag etc bother me too, when there are also observational ways to
> address this.  E.g. device X has multiple up states that have different rules
> regarding legal traffic types (e.g link management vs other).  "The stack
> needs to be informed of which traffic classes are permitted at any given
> time...."   The risk here is that your text partially describes one particular
> implementation, which may not be the only way to solve the problem.  Do you
> meant to imply other solutions are incorrect?

No. The R-flag just implies that the link up event is not deterministic 
and the link layer is not sure whether the packet will get through.