Last Call: 'Link-layer Event Notifications for Detecting Network Attachments' to Informational RFC (

The IESG has received a request from the Detecting Network
Attachment WG
to consider the following document:

- 'Link-layer Event Notifications for Detecting Network
Attachments '
   <draft-ietf-dna-link-information-05.txt> as an
Informational RFC

The IESG plans to make a decision in the next few weeks, and
solicits
final comments on this action.  Please send any comments to
the
iesgietf.org or ietfietf.org mailing lists by 2006-12-31.

The file can be obtained via
http://www.ietf.org/internet-drafts/dr
aft-ietf-dna-link-information-05.txt

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

Thanks
Suresh

Sam Hartman wrote:
> 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 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.

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

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

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

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

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.