IETF Participat Position

[Abdussalam Baryun]

Hi folks

The IESG has evaluation process positions as DISCUSS and others, which
is part of examining the I-D before making a decision. IMO also IETF
participants have positions which may name process positions (includes
the WG-chairs and IESG members' positions, because they are also
IETF-participants), I think this message can be a good recommendation
point of view to add-to/update RFC4144,

I agree that after submission of the I-D to IESG by the authors or WG,
the reviewer SHOULD NOT discuss with the authors after his review only
if the reviewer is a user of the I-D. We can define the reviewer is in
REVIEW position, and there is possibility of DISCUSS if he/she is a
user. On the other hand, I think the authors/WGs MUST reply to the
review, because they are in SUBMIT position, they reply to all
comments on the submitted I-D.

I beleive that at any time/place any participant may comment on any
document or input in IETF and may open discussion, but it helps if it
known where the participant poster stands. I remember that once
related to one I-D a participant was commenting in WG and the author
misunderstood him and thought he was in object position but he was in
agree position, he just commented for the best.

Therefore, I may not reply to the below, for all the best reasons :)

AB
++

Sub: Re: Last Call:  (Depth-First
Forwarding in Unreliable Networks (DFF)) to Experimental RFC
On 2/12/13, Ulrich Herberg  wrote:
> AB,
>
> thank you for the review. See my answer below:
>
> On Sun, Feb 10, 2013 at 3:08 AM, Abdussalam Baryun
>  wrote:
>>
>> Reply to your request dated 07/02/2013
>> Also following AD advice.
>> Draft Reviewed By: Abdussalam Baryun (AB)   Dated: 10/02/2013
>>
>> Reviewer Comment #AB1: Related to Aim and Terminology.
>> 
>>
>> Overall I support the work, but subject to amendments.
>>
>> The Abstract is interesting but seem general
>
> Do you have any specific suggestions what you would like to add/change
> in the abstract?
>
>
>
>> >This document specifies the "Depth-First Forwarding" (DFF) protocol
>> >for IPv6 networks,
>>
>> AB> do you mean all IPv6 networks, if some please mention *some*
>
> I don't think this is relevant to add in the abstract. As stated in
> section 3 of the draft, it can be used for all IPv6 networks, but for
> some the protocol is not very beneficial (and examples are given for
> such situations).
>
>
>> >a data forwarding mechanism that can increase
>> >reliability of data delivery in networks with dynamic topology
>> > and/or
>> >lossy links.
>>
>> AB> IPv6 considers dynamic topology, does the paragraph mean that some
>> networks are static topology.
>
> I am not quite sure what you mean by IPv6 "considers topology". In a
> static topology (i.e. with no or very few changes of links) and with
> low packet loss rate, the DFF protocol would have little (or no)
> benefit, because most likely the packets would be sent from the source
> to the destination according to the information provided by the
> routing protocol, and no packets would be lost.
>
>
>
>> Suggest to clarify the dynamic
>> frequency.
>
> I am not sure what you would like to see clarified. Can you be more
> specific?
>
>
>> Also not clear what is missing with IPv6 protocol in such
>> nets that needs DFF.
>
> If you mean data forwarding, I think the draft is pretty clear about
> which cases it is beneficial in. The motivation for DFF is explained
> in section 1.1.
>
>
>> >  The protocol operates entirely on the forwarding plane,
>> >but may interact with the routing plane.
>>
>> AB> amend> entirely on the forwarding plane,
>>to; entirely within the forwarding plane,
>
> I am not a native English speaker, but "to operate on" seems a valid
> usage of the word. But maybe a native speaker could suggest which is
> the right usage.
>
>
>>
>> >The routing plane may be informed of
>> >failures to deliver a packet or loops.
>>
>> AB> Amend> routing plane may be informed
>>   to;   routing plane protocols may be informed
>
> I think the current sentence is sufficient; I don't see the benefit of
> adding the word "protocols".
>
>
>
>> Terminology section>
>>
>> AB> you need to define that all routers have the DFF protocol, even
>> though it is known by heart that any forwarder needs to run DFF but
>> you MUST mention that at least to the reader,
>
> I think this is actually a good point. I was wondering whether to
> enforce all routers in a routing domain to run DFF. That does not seem
> like a reasonable approach. I found only one case that could be a
> problem when using both DFF and non-DFF routers in the network that
> results in a loop, but I think I found an easy fix. Here is the
> problem illustrated using an example:
>
> ...--- A - B  C --- ...
>
> Assume routers A and C use DFF, but not B. When B receives a packet
> from A, it would ignore the DFF header and skip over it, and then
> forward the packet to C (assuming

Re: Last Call: (Depth-First Forwarding in Unreliable Networks (DFF)) to Experimental RFC

[Ulrich Herberg]

AB,

thank you for the review. See my answer below:

On Sun, Feb 10, 2013 at 3:08 AM, Abdussalam Baryun
 wrote:
>
> Reply to your request dated 07/02/2013
> Also following AD advice.
> Draft Reviewed By: Abdussalam Baryun (AB)   Dated: 10/02/2013
>
> Reviewer Comment #AB1: Related to Aim and Terminology.
> 
>
> Overall I support the work, but subject to amendments.
>
> The Abstract is interesting but seem general

Do you have any specific suggestions what you would like to add/change
in the abstract?



> >This document specifies the "Depth-First Forwarding" (DFF) protocol
> >for IPv6 networks,
>
> AB> do you mean all IPv6 networks, if some please mention *some*

I don't think this is relevant to add in the abstract. As stated in
section 3 of the draft, it can be used for all IPv6 networks, but for
some the protocol is not very beneficial (and examples are given for
such situations).


> >a data forwarding mechanism that can increase
> >reliability of data delivery in networks with dynamic topology and/or
> >lossy links.
>
> AB> IPv6 considers dynamic topology, does the paragraph mean that some
> networks are static topology.

I am not quite sure what you mean by IPv6 "considers topology". In a
static topology (i.e. with no or very few changes of links) and with
low packet loss rate, the DFF protocol would have little (or no)
benefit, because most likely the packets would be sent from the source
to the destination according to the information provided by the
routing protocol, and no packets would be lost.



> Suggest to clarify the dynamic
> frequency.

I am not sure what you would like to see clarified. Can you be more specific?


> Also not clear what is missing with IPv6 protocol in such
> nets that needs DFF.

If you mean data forwarding, I think the draft is pretty clear about
which cases it is beneficial in. The motivation for DFF is explained
in section 1.1.


> >  The protocol operates entirely on the forwarding plane,
> >but may interact with the routing plane.
>
> AB> amend> entirely on the forwarding plane,
>to; entirely within the forwarding plane,

I am not a native English speaker, but "to operate on" seems a valid
usage of the word. But maybe a native speaker could suggest which is
the right usage.


>
> >The routing plane may be informed of
> >failures to deliver a packet or loops.
>
> AB> Amend> routing plane may be informed
>   to;   routing plane protocols may be informed

I think the current sentence is sufficient; I don't see the benefit of
adding the word "protocols".



> Terminology section>
>
> AB> you need to define that all routers have the DFF protocol, even
> though it is known by heart that any forwarder needs to run DFF but
> you MUST mention that at least to the reader,

I think this is actually a good point. I was wondering whether to
enforce all routers in a routing domain to run DFF. That does not seem
like a reasonable approach. I found only one case that could be a
problem when using both DFF and non-DFF routers in the network that
results in a loop, but I think I found an easy fix. Here is the
problem illustrated using an example:

...--- A - B  C --- ...

Assume routers A and C use DFF, but not B. When B receives a packet
from A, it would ignore the DFF header and skip over it, and then
forward the packet to C (assuming C is the next hop in its RIB). Now,
it is possible that C returns  the packet (RET==1) to B, e.g. because
it does not have any other neighbor. B receives the returned packet
and would resend the packet to C (because it does not care about the
DFF header), and thus RET would still be 1. C, having tried already
all neighbors would return the packet to B (and so on, loop between B
and C until hop-limit == 0).

I see the following options:
1) Change the options header type from something starting with 001
(i.e. "skip over this option and continue processing the header.") to
011 ("discard the packet.") in IPv6 to discard the packet if the
header is unknown. This would avoid the problem, but I don't think
that's possible for 6lowpan mesh-under.
2) Mandate that all routers in the routing domain "MUST use DFF" for
forwarding packets.
3) Add a rule that if a packet is returned (RET==1) from P_prev_hop
(i.e. the original previous hop when first received a packet), it is
discarded, e.g. if router C receives a packet from B with RET==1 and B
is the P_prev_hop.

Option 1) would be possible, but not for 6lowpans, only for IPv6
route-over. Option 2) is probably not very good. Option 3) would fix
the loop issue, and thus allows non-DFF and DFF routers in the same
network. I will provide some updated text in the next revision of the
draft.



>
> AB> you missed to define the Router, which is mentioned many times but
> I don't know which one. I think it is a must because you refer to two
> planes forwarding and routing planes. Please define th

Re: Last Call: (An Overview of Operations, Administration, and Maintenance (OAM) Mechanisms) to Informational RFC

[Thomas Narten]

I agree with many of the comments that others have raised on this
thread. Just a couple of things to add that I don't recall seeing
mentioned.

   An OAM protocol is run in the context of a Maintenance Domain,
   consisting of two or more nodes that run the OAM protocol, referred
   to as Maintenance Points (MP).

This defintion could be better. I assume an MD is really more like a
"region", that is a collection of nodes within which (or across which)
some OAM function is run. You might run, e.g., a ping. While that ping
may be between to MPs, it also involves other nodes (MIs). But MIs seem
to be excluded per the above.

   o Continuity Checking (CC):
  Used for verifying the liveness of a connection between two MPs.

What is "liveness" and what is "connection"?  Please define these
terms or point to the defintions in other documents. (I have looked
and have not found a precise definition.)

Note: later in document:

   Continuity checks are used to verify the liveness of a connection or
   a path between two MPs, and are typically sent proactively, though
   they can be invoked on-demand as well.

Here "path" and "connection" are used interchangably.   

   o Connectivity Verification (CV):
  Allows an MP to check whether it is connected to a peer MP, and to
  verify that messages from the peer MP are received through the
  expected path.

what is "connected to a peer"? Does that mean "there is a working
path?" Or something else?

   o Path Discovery / Fault Localization:
  An MP uses this mechanism to trace the route to a peer MP, i.e.,

s/the route/the path/ ???

  to identify the nodes along the path to the peer MP. When a
  connection fails, this mechanism also allows the MP to detect the
  location of the failure.

   o Performance Monitoring:
  Consists of 3 main functions

o Loss Measurement (LM) - monitors the packet loss rate of a
  connection.

what is "connection" in the context of technologies like TRILL (or IP
for that matter)?, which do hop-by-hop forwarding and/or may do load
balancing via ECMP?

   o "Ping" mode: In this mode LSP ping is used for end-to-end
  connectivity verification between two LERs.

What's an LER?

Thomas

One Week Left To Nominate YOUR Choice for the Internet Hall Of Fame!

[IETF Chair]

A reminder that the deadline for the Internet Hall of Fame nominations is 18 
February 2013. Individuals who have played a significant role in the 
conceptualization, building, and development of the Internet in any region or 
country are considered for induction.  Please take this opportunity to 
participate; your involvement will result in a highly diverse and 
well-qualified group of nominees!  

More details and the nomination form are available here: 
http://www.internethalloffame.org/nominations

Thanks for all you do for the Internet,
  Russ

Re: Remote Participation Services

[Dave Crocker]

On 2/11/2013 7:05 PM, Michael Richardson wrote:

It's not the slides that are the problem.
It's the "presentation" itself.



+1.


If a meeting has good structure, management and content, the presence or 
absence of slides doesn't matter.


If a meeting has poor structure, management or content, the presence or 
absence of slides doesn't matter.


Focus on the substance, not the form.  Slides are form.

d/

--
 Dave Crocker
 Brandenburg InternetWorking
 bbiw.net

Re: Gen-ART LC review of draft-ietf-ancp-pon-04

[Bitar, Nabil N]

Hi Roni,
Thanks. Will do the edit you pointed out.

Thanks,
Nbail

From: Roni Even mailto:ron.even@gmail.com>>
Date: Tuesday, February 12, 2013 1:46 AM
To: 
"draft-ietf-ancp-pon@tools.ietf.org"
 
mailto:draft-ietf-ancp-pon@tools.ietf.org>>
Cc: "ietf@ietf.org" 
mailto:ietf@ietf.org>>, 
"gen-...@ietf.org" 
mailto:gen-...@ietf.org>>
Subject: Gen-ART LC review of draft-ietf-ancp-pon-04
Resent-To: mailto:dr...@bucknell.edu>>, 
mailto:matthew.bo...@alcatel-lucent.com>>, 
"<, nabil.n.bi...@verizon.com>", 
mailto:sanjay.wad...@alcatel-lucent.com>>, 
mailto:w...@cisco.com>>

I am the assigned Gen-ART reviewer for this draft. For background on Gen-ART, 
please see the FAQ at .
Please resolve these comments along with any other Last Call comments you may 
receive.

Document: draft-ietf-ancp-pon-04

Reviewer: Roni Even

Review Date:2013–2–12

IETF LC End Date: 2013-2–19

IESG Telechat date:



Summary: This draft is ready for publication as an Informational RFC.





Major issues:



Minor issues:




Nits/editorial comments:

 1.  OMCI is expanded very late in the document and not on the first usage.

Re: Sunday IAOC Overview Session

[SM]

At 14:54 11-02-2013, The IAOC wrote:

Please let us know ahead of time if you have specific questions you would like
to see discussed.


The latest minutes posted by the IAB is dated January 9, 2013.  The 
latest minutes posted by the IESG is dated January 24, 2013.  The 
latest minutes posted by the IETF Trust is dated November 12, 
2012.  The latest minutes posted by the IAOC is dated November 7, 2012.


The IETF Trust stated previously that the "Trustees are fully in 
agreement with this requirement for openness, transparency, and 
accountability, and are making a conscious effort to increase their 
reporting and community interaction".  I leave it to the reader to 
assess the results of that effort.


There were more than three financial statements posted yearly by the 
IAOC in 2009 and 2010.  There are only three yearly after 2010.


According to a RFP posted in May 2012 "Any Agreement negotiated with 
a Vendor, excluding cost, will be made public after execution".  I 
don't see the agreement at http://iaoc.ietf.org/contracts.html  The 
latest contract for the Secretariat is dated 2006.


During a past IETF meeting someone mentioned that "BCP 101 does not 
specify this [transparency requirements] level of detail".  From 
Section 7 of BCP 101:


  "Transparency: The IETF community shall have complete visibility into
 the financial and legal structure of the ISOC activities that are
 related to, but not part of, the IASA standards support activity.
 In particular, a detailed budget for the entire related ISOC
 activity, quarterly financial reports, and audited annual
 financial reports shall all be available to the IETF community.
 In addition, key contract material and MOUs shall also be publicly
 available, subject to any reasonable confidentiality obligations
 approved by the IAOC."

According to the IAOC:

  "The month's financial statement will be posted within 30 days of the
   end of the month."

  "Minutes of IAOC meetings shall be published following their adoption
   by the IAOC, and in any event not later than 30 days after the meeting."

  "The IAD shall provide an Operations Report to the IAOC monthly, and to
   the ISOC Board as required; all such reports shall be published online.
   The report shall provide an update on the Budget, the performance of all
   contractors, and other relevant information as shall be decided."

  "Non-confidential agreements shall be posted upon execution. Public
   agreements include ICANN/IANA MoUs and SLAs."

  "When a contract contains confidential information, that information
   shall be summarized if possible to protect its confidentiality, or if not,
   extracted. The balance of the contract shall be published on the IASA
   website within 14 days of execution."

I do not have any specific questions.

Regards,
-sm 

Re: Changing the value of RFCs not numbers (was Re: The RFC Acknowledgement)

[Yoav Nir]

On Feb 12, 2013, at 2:57 AM, Abdussalam Baryun  
wrote:

> Many said to me before as you do RFC don't change, it is already known
> in any org that documents don't change when published.

I think the reason this keeps coming up, is that the IETF documents are usually 
referenced by number rather than title. So you'd say that your system is 
compliant with RFC 5280 rather than saying that it is compliant with "Internet 
X.509 Public Key Infrastructure Certificate and Certificate Revocation List 
(CRL) Profile".

In other organizations, like the W3C, documents are referred to by name. So 
"Content Security Policy 1.0" is called that when it's proposed, when it's 
discussed, and when it's published. Even a later revision might be called 
"Content Security Policy 1.1", so version numbers, while they exist and are 
accessible, are mostly hidden from the users.

Yoav

Re: Remote Participation Services

[Abdussalam Baryun]

I agree with Michael and SM, the importance is what is gained from the
face to face (F2F) meeting, if presentation is needed then do it. As I
am usually remote participant I see that Chairs are different in
handling the meetings, and there may be many reasons I don't know
about, however, it is the chair that should guide for the best gain
for the participants in the room and whom are remotely. Piriority of
presentations or/and specific issues that need to be solved, to
encourage progress of the WG in its active works and future work.

Keith is right, we should not spend time much on presenting drafts (
5minutes MAX, inputs from room is more important, which should
encourage inputs on mail-list), info is already there in IETF, but
slides are valuable for showing performance-results, graphs, plans,
scenarios for readers/commenters. We have a large time of discussion
available if we continue participate on lists as well, which should be
encouraged.

IMHO, F2F meetings in IETF sometimes lack inputs from inplementors or
users in industry/market which we want to hear; what does these
companies/end-users think about the I-D or WG performance/direction?
The interaction/feedbacks between IETF and companies/community using a
standard or future standard, is the main purpose I think from F2F
meeting. Our IETF I-Ds don't go much into details of applicability
(i.e. they try to make their work general, which may not be real),
which is good to show scenarios/case-studies by slides and
presentations.

AB

On 2/11/13, Michael Richardson wrote:
> "Keith" == Keith Moore  writes:
Keith> Can we *please* discourage the habit of treating IETF WG
Keith> meetings as one series of PowerPoint presentations after
Keith> another?  This makes the meetings much less productive.

Keith> The notion that there are supposed to be slides for each
Keith> presentation, is IMO, a huge error.

It's not the slides that are the problem.
It's the "presentation" itself.


If we could, I would organize the rooms in circular style, but it doesn't
scale to several hundred people.

(If there are slides, we need to make sure that they are received early,
in a vendor-neutral archival happy format, and can be distributed in
advance.)


-- 
Michael Richardson , Sandelman Software Works


On 2/6/13, SM  wrote:
> Hi Abdussalam,
> At 18:14 05-02-2013, Abdussalam Baryun wrote:
>>In the previous ietf meeting in July, I have submitted an I-D in one
>>WG but had no chance to present my participation remotely, as you
>>mention in 2.5. I would like the solution and that I will be able to
>>present remotely. I asked the WG if someone can present for me but
>>only WG darfts are done the way mentioned in 2.5,
>>
>>Please amend the [1] to include that there is difference process in
>>IETF participation remotely for WG I-Ds and Individual I-Ds,
>
> I read a review written by Allison Mankin [1].  I doubt that anyone
> can get a review of that quality in an IETF meeting.
>
> It was mentioned previously on this mailing list that meetings were
> about discussing issues and not about presenting I-Ds.  If I have a
> chance to present my I-D either in person or remotely, what's do the
> people in the room gain from it?
>
> Regards,
> -sm
>
> 1. http://www.ietf.org/mail-archive/web/ietf/current/msg76903.html
>
>