from:"Abdussalam Baryun"

Hi Don, and All,

I would like to know your opinion about why we don't define subnets for MANET?

On 6/3/12, Don Sturek d.stu...@att.net wrote:
 +1

 On 6/2/12 11:21 PM, Charles E. Perkins charl...@computer.org wrote:

Could we discuss why we don't define subnets models? I don't
understand adding (+1). I hope the chair does not ask me to close this
thread too :)

The ad hoc autoconfig was proposed in 2005 and proposed-ended in 2011
so living for about 6 years only. What was the reason for the proposed
close of it? please read the DA Jari's reasons below.

IMO it because it had low/no useful discussions and only produced one
RFC which is RFC5889, why only one? what happend within 6 years?  IMO
any WG should have more discussions, discussions are mandatory
activity for WG. Not discussing issues is like ignoring the value
input to group progress. Healthy discussions are more important than
producing more documents produced, because discussions are really the
source of correct documents (don't mean it has to be perfect, but
should not be misleading). WGs should be compared in terms of the
amount of discussions not in amount of documents forwarded/submitted.

According to Chakeres and Maker (2006) [1] quoated below:

[The autoconf WG is chartered to initially develop
two documents. The first document is a document
defining the MANET architecture and how MANET
relates to IP networks and the Internet. The second
document is to define the terminology, problem statement
and goals for autoconf. These autoconf documents
will be discussed on the autoconf mailing list.]

That WG did not produce the definition of MANET architecture. Which I
think is related to the subnet-model definition importance for MANET.
So i understand the authors see the importance of defining something
for MANET in 2006. Now, Do we have a network architecture definition
of MANET in one RFC?

 On 6/2/12 11:21 PM, Charles E. Perkins charl...@computer.org wrote:
Hello folks,

I would be opposed to requiring the subnet model as a mandatory
component of any current [manet] working group charter item.

We have had at least ten years of experience showing that requiring
subnets can derail practically any wireless network discussion within
the sphere of applicability of manet protocols.  The reasons are many
and varied -- and, I must admit, really very interesting.

It was the death of another working group which really should have
been allowed to go forward except for disagreements about certain
subnet-related constructs.  Let's not consign ourselves to the same
fate.

In future the death of the WG will be because they don't discuss
things on the list, or don't have what to discuss, please read the
reasons mentioned by Jari Arkko below. IMO for the future, some day
any WGs possibly will close and other days new WGs comes.


Regards,
Charlie P.

References:
[1] Chakers, I., and Maker, J., 'Mobile Ad Hoc Networking and the
IETF', Mobile Computing and communication review, volume 1, Number 2,
2006.

Best regards

Abdussalam Baryun
University of Glamorgan, UK
+++
+++
To: autoconf at ietf.org autoconf at ietf.org
Subject: [Autoconf] closing the working group?
From: Jari Arkko jari.arkko at piuha.net
Date: Tue, 29 Mar 2011 08:48:47 +0200


I have looked at the discussions on the list (or lack thereof). I also
cannot see too many internet drafts on the topics belonging to the
group's charter. I am very happy with the RFC that has been produced
by the working group, but we also seem to have some actual protocol
work happening elsewhere (e.g., in the context of the ROLL WG).

I discussed this matter with the chairs and my co-AD, and we are
wondering if it would be time to close the working group. I do know
that there is at least one implementation team that is still in the
process of describing their DHCP-based solution, maybe there are
similar efforts on the distributed solution space. My proposal is that
we close the working group and I'be VERY happy to AD sponsor all such
solutions to Experimental RFCs as soon as we have those proposals in
some reasonable shape.
Thoughts?

Jari
+++
To: IETF-Announce at ietf.org
Subject: WG Review: Ad Hoc Network configuration (autoconf)
From: The IESG iesg-secretary at ietf.org
Date: Wed, 27 Jul 2005 14:28:49 -0400
Cc: manetautoconf at ml.free.fr
List-help: mailto:ietf-announce-requ...@ietf.org?subject=help
List-id: ietf-announce.ietf.org
List-post: mailto:ietf-annou...@ietf.org
List-subscribe:
https://www1.ietf.org/mailman/listinfo/ietf-announce,
mailto:ietf-announce-requ...@ietf.org?subject=subscribe
List-unsubscribe:
https://www1.ietf.org/mailman/listinfo/ietf-announce,
mailto:ietf-announce-requ...@ietf.org?subject=unsubscribe
Reply-to: iesg at ietf.org
Sender: ietf-announce

draft-ietf-roll-terminology-06.txt

Hi Vasseur,

I want to ask about the draft of ROLL terminology, when will it be
re-activated? because expired, and if it is completed should we make
it go forward, or is it better to wait for other drafts to come in,
not sure, please advise, thanking you,

Abdussalam Baryun,
University of Glamorgan, UK
+++

Re: Making the Tao a web page

Dear Paul Hoffman

Simpler than the above: make it a web page
 (as Brian points out, we already have a good URL),
 have one editor, have one leadership person who
 approves non-trivial changes (I think IETF Chair fits here well),
 have a last modified date on it, and update it as needed. If there
 is consensus in the community to do this, I'm happy to take on
 the HTMLizing and skip the RFCizing for this round.


I thank you for this opportunity. I think we need both the webpage and
the RFCs to make it more understood to all volunteer members around
the world. As a new comer to IETF my volunteer process experience was
started not good so far (see below attached), as I feel lost some
times by group-practice-policy, I think list leaders/holders should
help in such situations. I am reviewing the draft
draft-hoffman-tao4677bis-15 and will comment on the changes and
future updates. Please note that practice may not always be perfect
like documents/webs procedures.

In conclusion, All policy procedures of IETF SHOULD be perfect, hope
we do our best together for this. I will write my comments on
some-points of overall procedures and for your draft, I also will try
to include New-Comers consideration by chairs and memebrs, so
procedure consider their experience and that do not be blocked by
informal directions a group takes over.

Abdussalam Baryun
University of glamorgan, UK
+++
To: manet manet at ietf.org
Subject: Re: [manet] I-D Action: draft-ietf-manet-olsrv2-15.txt
From: Abdussalam Baryun abdussalambaryun at gmail.com
Date: Sat, 19 May 2012 09:41:33 +0200

Dear All,

I beleive that we are all informally equal in terms of rights and
responsibilities, but in organisations we have formal responsibilities
and rights to make work-processes progress to the direction of the aim
and objectives of the organisation, not in the direction of some
individuals decisions. I beleive the best practice for IETF groups is
in RFC2418 and RFC3934.

On 5/18/12, Stan Ratliff sratliff at cisco.com wrote:
 It has never been the process (at least in the MANET working group) to
 formally track each and every comment coming in on a draft and actively
 notify/dispose of said items. This is rooted in the notion that the IETF is
 a volunteer organization; as such, we've all got day jobs, and do the best
 we can. Another reason for this (slightly informal) process model is to keep
 the group from spinning ad-nauseum, generating vast amounts of email on
 trivial topics. This discussion is a reasonably good example of that very
 thing.

The process for MANET WG SHOULD follow the RFC2418. IMHO the IETF is a
formal organisation, and yes it is structured of volunteering members,
but it is not informal organisation. Please note that number of emails
SHOULD not be restricted, but the content of messages MAY be
restricted. Yes our relationships are RECOMMENDED to be friendly and
informally social to inhance the group activities.

All informal models give chances of more power to organisation
managers. I don't agree with the informal-process model, but agree
with RFC2418-process model.


 You made some comments/suggestions on OLSRv2. They were considered by the
 authors, and by the working group members. The authors didn't agree with you
 in all cases, and the working group, via its silence, indicated *they*
 didn't agree with you either. And now, apparently, you want to re-litigate
 all or part of that. I for one am not interested.


Silence is not a reaction (e.g. not an indication), because as you
mentioned we are volunteers and we have jobs, therefore, silence most
possibility means I am bussy, not meaning I agree nor disagree.

 My opinion is that OSLRv2-15 has cleared WGLC, and will be forwarded to the
 AD's/IESG for review and publication. If the working group members *DO NOT*
 agree with me, then let the fire-storm of emails commence.


I reply to this call that I *DO NOT* agree to give forward to
OLSRv2-14 or OLSRv2-15 until I comment on it, or only after concensus
collected for the decision (i.e. it is easy to collect electronically,
as in RFC2418 does not have to be face-to-face collecting). Regarding
the OLSRv2-15 draft it is better than OLSRv2-14 because it reduced my
confusions, but I will need some time to review OLSRv2-15 and comment
on it as well. Regarding fire-storm emails, it seems it will not be
happening in MANET WG, maybe active memebrs are about 60, not sure.

In conclusion, from the group chair last message, I understand that
there was no concensus collected for OLSRv2 to go forward, so the
MANET-WG still didn't make last decision yet.

I am sorry if I made any disturbing to any. In the end of all
processes I am interested in understanding and participating in IETF.
If the group or group chairs decides that I stop emailing in MANET, I
will stop without any complains to higher levels, and go to another
IETF group. Thanking you,

Best Regards,
Abdussalam
+

Re: Making the Tao a web page

Hi

I agree with you, and would add we need the web and RFC so that we get
things right. However, to make quick progress in RFC is not to wait
for discussions to end, but to open a restricted period/window for
discussion which MUST end some date and make the changes/updates, then
take the final consensus,

Best regards
AB

+
On Jun 3, 2012, at 6:34 PM, John C Klensin wrote:

 ... I further guess that
 on an ongoing basis will be better for the document than
 getting a new snapshot out as an RFC and seeing how long it
 takes to get stale and how long after that it takes the
 community to notice. ...

I second the above statement
(my apology to John for quoting this single sentence out of his whole msg)

Lixia

Discussions in IETF WGs

2012-06-11 Thread Abdussalam Baryun

   Possible Duplication  +++

Hi Folks,

IMHO, there are difference between discussion that MAY become
argumentable and/or debatable. In a healthy-discussion you produce new
ideas and educate yourself and others, but in unproductive-discussion
you MAY block any progress and waste time.  I define productive
discussion as the posting/speaking of a point of view referenced by
scientific facts or RFCs. I define debates as the posting/speaking of
points without good-referencing or without good-reasoning. IMHO these
debating inputs with no good reference will not provide progress in
discussions, even though it may (in low probability) start indirectly
an interest/input to a work-in-progress.

For example, in one of the WG discussion on list, two members of WG
have referenced a history-discussion and informed me to read them
regarding some subject, I did do that but was *lost in translation*. I
now think that the memebrs' advise was to a wrong direction. We SHOULD
NOT refer in our current discussions to any other
history-subjected-discussions (thoes discussion had no approve by WG
consensus nor IESG review) in any WGs.  Also referring to old
discussions in the list result to waste time and MAY make current
arguments long (i.e. long means more than 5 working days), or even
makes the current argument unproductive.Old-discussions MAY be
misleading/incorrect/invalid, even if they are helpful to gain some
knowledge.

We should *reference* mostly RFCs in our discussion, because RFCs are
correct resource. The reason is because only RFCs are productions of
healthy discussions and reviewed by experts in IESG. IMHO the IETF
sees that RFCs are the correct-progress-reference. All Discussions are
important for the IETF processes and to produce RFCs. Memebers of the
WG should try to direct their discussions in the direction of progress
without discouraging debate-input. Discussions that produce I-D that
in the end submits I-Ds are work-in-progress are the most productive
discussions. IMO it is accepted in discussions to reference scientific
research papers, reviewed publications, industry experience, or RFCs,
but please don’t accept in discussion the validity of ; a) a reference
to a specific historic discussion that possibly were with wrong
arguments, or b) a reference to unproductive discussions.

In conclusion, we should try with the help of the WGs chairs to direct
our discussions to become more productive, and within a reasonable
time, and if we see any good-correct ideas, we SHOULD react quickly
and input in a informational I-D and submit to WG for approval so we
don't repeat refering to wrong-argumental-discussion.

If you feel differently please advise, thanking you :)

Best regards

Abdussalam Baryun
University of Glamorgan, UK.

+
 In discussions one may be wrong, or may be right, but it does not
matter if we work together as a group to progress and resolve all
issues. IETF WGs are always right

Re: Discussions in IETF WGs

2012-06-11 Thread Abdussalam Baryun

   Possible Duplication  +++

Hi Folks,

IMHO, there are difference between discussion that MAY become
argumentable and/or debatable. In a healthy-discussion you produce new
ideas and educate yourself and others, but in unproductive-discussion
you MAY block any progress and waste time.  I define productive
discussion as the posting/speaking of a point of view referenced by
scientific facts or RFCs. I define debates as the posting/speaking of
points without good-referencing or without good-reasoning. IMHO these
debating inputs with no good reference will not provide progress in
discussions, even though it may (in low probability) start indirectly
an interest/input to a work-in-progress.

For example, in one of the WG discussion on list, two members of WG
have referenced a history-discussion and informed me to read them
regarding some subject, I did do that but was *lost in translation*. I
now think that the memebrs' advise was to a wrong direction. We SHOULD
NOT refer in our current discussions to any other
history-subjected-discussions (thoes discussion had no approve by WG
consensus nor IESG review) in any WGs.  Also referring to old
discussions in the list result to waste time and MAY make current
arguments long (i.e. long means more than 5 working days), or even
makes the current argument unproductive.Old-discussions MAY be
misleading/incorrect/invalid, even if they are helpful to gain some
knowledge.

We should *reference* mostly RFCs in our discussion, because RFCs are
correct resource. The reason is because only RFCs are productions of
healthy discussions and reviewed by experts in IESG. IMHO the IETF
sees that RFCs are the correct-progress-reference. All Discussions are
important for the IETF processes and to produce RFCs. Memebers of the
WG should try to direct their discussions in the direction of progress
without discouraging debate-input. Discussions that produce I-D that
in the end submits I-Ds are work-in-progress are the most productive
discussions. IMO it is accepted in discussions to reference scientific
research papers, reviewed publications, industry experience, or RFCs,
but please don’t accept in discussion the validity of ; a) a reference
to a specific historic discussion that possibly were with wrong
arguments, or b) a reference to unproductive discussions.

In conclusion, we should try with the help of the WGs chairs to direct
our discussions to become more productive, and within a reasonable
time, and if we see any good-correct ideas, we SHOULD react quickly
and input in a informational I-D and submit to WG for approval so we
don't repeat refering to wrong-argumental-discussion.

If you feel differently please advise, thanking you :)

Best regards

Abdussalam Baryun
University of Glamorgan, UK.

+
 In discussions one may be wrong, or may be right, but it does not
matter if we work together as a group to progress and resolve all
issues. IETF WGs are always right

Re: Discussions in IETF WGs

2012-06-12 Thread Abdussalam Baryun

Hi Martin,

I thank you for your help and comments, it will help me for future.

comments in line:

On 6/11/12, Martin Rex m...@sap.com wrote:

 There is no substiantial difference between old discussions and recent
 discussions.  Referencing an argument from an earlier discussion rather
 than repeating it is often an improvement with a significant potential to
 actually save time, and zero risk to waste time (compared to repeating
 the exact same previous arguments in a new message).


I agree with you, but only if the reference was pointed by date or
subject, so the all readers can follow the current discussion and
reference. also if the it was copied from the history (if short
discussion) forward to the current it will be useful, but overall
mentioning the subject/date of discussion is important.


 We should *reference* mostly RFCs in our discussion, because RFCs are
 correct resource.

 If RFCs were correct, we would neither need an Errata process, nor
 maturity levels, nor -bis documents.

 RFCs are correct is a bold and dangerous presumption.  Many RFCs
 are vague or even ambigous, and they may contain numerous implications
 that are non-obvious to a number of readers, and sometimes non-obvious
 to implementors and document authors).

I just mentioned that to compare RFC with discussion list. In your
refering if the RFC maybe vague and it is the product of the
discussions, so what about the discussion as a reference.


 All that can be said about standard track RFCs, is that they're the result
 of the IETF consensus process.  And the primary focus of the IETF consensus
 process is to resolve dissent (technical or procedural objections),
 _not_ correctness.  Some level of confidence about correctness can be
 obtained
 by creating independent implementations and demonstrate that they interop
 on the implemented features, but results are mixed, and most interop
 tests are lacking (test only a fraction of the features and only a fraction
 of the implementations in the installed base, and rarely border cases
 of unusual encodings).


IMO the RFC is result of both; WG discussions first, and then
consensus process. Regarding confidence issue I agree with you,


 -Martin


Best regards
Abdussalam
==

Last Call: draft-hoffman-tao-as-web-page-02.txt (Publishing the Tao of the IETF as a Web Page) to Informational RFC

2012-06-17 Thread Abdussalam Baryun

I suggest to have both webpage and RFC

AB

On Fri, Jun 15, 2012 at 9:29 PM, The IESG iesg-secret...@ietf.org wrote:


 The IESG has received a request from an individual submitter to consider
 the following document:
 - 'Publishing the Tao of the IETF as a Web Page'
  draft-hoffman-tao-as-web-page-02.txt as Informational RFC

 The IESG plans to make a decision in the next few weeks, and solicits
 final comments on this action. Please send substantive comments to the
 ietf@ietf.org mailing lists by 2012-07-13. Exceptionally, comments may be
 sent to i...@ietf.org instead. In either case, please retain the
 beginning of the Subject line to allow automated sorting.

 Abstract


   Discussion of the Tao of the IETF during 2012 made it clear that
   many people want the document published only as a web page, not as an
   RFC that needs to be periodically updated.  This document specifies
   how the Tao will be published as a web page.




 The file can be obtained via
 http://datatracker.ietf.org/doc/draft-hoffman-tao-as-web-page/

 IESG discussion can be tracked via
 http://datatracker.ietf.org/doc/draft-hoffman-tao-as-web-page/ballot/


 No IPR declarations have been submitted directly on this I-D.

Comments for I-D of Publishing the Tao of the IETF as a Web Page

2012-06-17 Thread Abdussalam Baryun

The abstract mentions 'many people',  because many people may mean 4 to 10
people. The annonced I-D lacks the method of discussion in the community
(discussing such change), the draft mentions the input from any community
individual to be accepted by editor and then approved by IESG, but does not
mention the methodology of discussion between community members nor between
editor and members, also no announcements of such updates mentioned in
draft.

suggest amend in abstract the word 'many' to the word  'some', or mention
like in the introduction the desire of community.

suggest to add to the draft that a discussion group to discuss
inputs/suggestions before the editors undertakes changes. The draft to
specify the discussion ( may be either on-List or during the IETF
meetings). I prefer to mention; the face-to-face IETF meeting discussion in
this procedure issue.

suggest to add  the announcement for last call of Tao changes by the
IESG,

suggest replace in section2 line 7 The editor of the Tao decides which
proposed changes should be submitted to the IESG for the next version of
the Tao.

 replace with The editor of the Tao decides which proposed changes
should be
  submitted to the IESG for the next version of the
Tao after
  the community discussed the changes.

suggest A time period of updates to be made, and input from the community
to be collected, and editor to submit to IESG. It will be helpful also to


AB
==

On Fri, Jun 15, 2012 at 9:29 PM, The IESG iesg-secret...@ietf.org wrote:


 The IESG has received a request from an individual submitter to consider
 the following document:
 - 'Publishing the Tao of the IETF as a Web Page'
  draft-hoffman-tao-as-web-page-02.txt as Informational RFC

 The IESG plans to make a decision in the next few weeks, and solicits
 final comments on this action. Please send substantive comments to the
 ietf@ietf.org mailing lists by 2012-07-13. Exceptionally, comments may be
 sent to i...@ietf.org instead. In either case, please retain the
 beginning of the Subject line to allow automated sorting.

 Abstract


   Discussion of the Tao of the IETF during 2012 made it clear that
   many people want the document published only as a web page, not as an
   RFC that needs to be periodically updated.  This document specifies
   how the Tao will be published as a web page.




 The file can be obtained via
 http://datatracker.ietf.org/doc/draft-hoffman-tao-as-web-page/

 IESG discussion can be tracked via
 http://datatracker.ietf.org/doc/draft-hoffman-tao-as-web-page/ballot/


 No IPR declarations have been submitted directly on this I-D.

Re: Comments for I-D of Publishing the Tao of the IETF as a Web Page

2012-06-18 Thread Abdussalam Baryun

Hi Barry,

I think from your message, you agree that discussion is important in
the decision of updates, which I share. I agree to not repeat any
unnecessary info, but if contradictions appear to procedure, it then
needs a reference or repeat.

The problem is that the I-D does not mention in the
publish-procedure-section-2 *discussion* as an important procedure
factor for submission nor even refers to what you call
process-of-discussion. I think mentioning that editor decides to
submit and accept input is a new thing that is not in the procedure
you refer to. Therefore, to be clear in the I-D it MUST clarify, is
there community consensus with editor decision, OR is their only
decision of editor.

It is clear from the draft if you read it, that the decision *is not*
for the internet-community in two issues: a) editor decision of
accepting a propose change, b) editor decision of change-updates to
submit to IESG. The discussion in the I-D is mentioned as just for
information not as decision making of submission.

Please note that this I-D informs:

1) The Tao will be published at http://www.ietf.org/tao.html and
https://www.ietf.org/tao.html. The initial content for the Tao web
page will come from the last Internet-Draft that was meant to replace
RFC 4677.

2) RFC4677 is not a formal IETF process document but instead an
informational overview. Therefore, the proposed Tao-webpage is the
same.

Abdussalam


On 6/17/12, Barry Leiba barryle...@computer.org wrote:
 The abstract mentions 'many people',  because many people may mean 4 to
 10
 people. The annonced I-D lacks the method of discussion in the community
 (discussing such change), the draft mentions the input from any community
 individual to be accepted by editor and then approved by IESG, but does
 not
 mention the methodology of discussion between community members nor
 between editor and members, also no announcements of such updates
 mentioned in draft.

 On this, as well as on the rest of the comments in the same message:
 The IETF already has a process for discussion, review, and consensus, and
 this document neither changes any of it nor, I think, needs to repeat it.

 Barry

Re: Last Call: draft-hoffman-tao-as-web-page-02.txt (Publishing the Tao of the IETF as a Web Page) to Informational RFC

2012-06-18 Thread Abdussalam Baryun

It will be better to have both webpage and RFC

AB

On Fri, Jun 15, 2012 at 9:29 PM, The IESG iesg-secret...@ietf.org wrote:


 The IESG has received a request from an individual submitter to consider
 the following document:
 - 'Publishing the Tao of the IETF as a Web Page'
  draft-hoffman-tao-as-web-page-02.txt as Informational RFC

 The IESG plans to make a decision in the next few weeks, and solicits
 final comments on this action. Please send substantive comments to the
 ietf@ietf.org mailing lists by 2012-07-13. Exceptionally, comments may be
 sent to i...@ietf.org instead. In either case, please retain the
 beginning of the Subject line to allow automated sorting.

 Abstract


   Discussion of the Tao of the IETF during 2012 made it clear that
   many people want the document published only as a web page, not as an
   RFC that needs to be periodically updated.  This document specifies
   how the Tao will be published as a web page.




 The file can be obtained via
 http://datatracker.ietf.org/doc/draft-hoffman-tao-as-web-page/

 IESG discussion can be tracked via
 http://datatracker.ietf.org/doc/draft-hoffman-tao-as-web-page/ballot/


 No IPR declarations have been submitted directly on this I-D.

Re: Protocol Definition

2012-06-18 Thread Abdussalam Baryun

IMO the important issue in any definition is to include how the IETF
defines protocol,
this may be find in some RFCs :)

The IP is the main protocol, and all protocols in IETF are based on IP
and Internet.

AB


On 5 Jan 2012, todd glassey tglassey at earthlink.net wrote
 On 1/5/2012 6:48 AM, Dave CROCKER wrote:

 (One can quibble about the difference between algorithm and
 program. An algorithm is a component of a program.

 The program is the code-based implementation of the alg?

 The distinction is relevant here because a protocol is typically
 a complete mechanism rather than being a component of the
 mechanisms.

 I.e. A complete method of doing something...

I noticed no disagreement between method and mechanism, at the
time.  In retrospect, those two terms might seem to allude to a
different depth of semantic explanations.  Rereading that thread, I
find that the same ambiguity holds for algorithm descriptions:  one
can give a full description (or coding) of, say, sqrt, without
actually saying that the square of the result will match its argument
up to some rounding error.  The specification does not have to relate
the underlying mathematical abstraction.

Protocol specifications, especially when dealing with policies, do not
have to describe the exact meaning of the relevant tokens.  To do that
would often look like mandating a state or a reaction, neither of
which is needed to ensure interoperability.  In fact, the protocol
just has to ensure that a policy can be transmitted correctly.  Many
would rather leave a policy token underspecified than get involved in
its details.

In that respect, a protocol is not a complete method.  The upper
layer, where policies and politics are dealt with, seems to be too
fuzzy to be specified.  I think this limitation is consistent with the
etymological meaning of the term, that refers to forms of conduct that
don't betray intentions.  Is that right?

Re: Comments for I-D of Publishing the Tao of the IETF as a Web Page

2012-06-19 Thread Abdussalam Baryun

Hi Melinda, and All,

This is consistent with how individual, non-WG documents are
progressed in the IETF.  I don't see a conflict or discontinuity.

Conflict process if we consider the I-D process as a IETF process. It
is not consistent with the IETF procedures. It can be consistent if
the IESG amend the I-D submission-process or take my suggestions.

Yes I agree that non-WGs documents take different submission stream
than IETF-WGs documents. One is named non-IETF submission and the
other IETF submission streams (two only streams so far). In the I-D we
are discussing of [publishing the Tao of the IETF], the submission
stream was not refered to which of two submission streams. It is most
likely understood as a new second IETF submission stream (I may name
it IETF-Tao stream), because this I-D affect the community (it must be
a group production not an individual production).

Please note that:
1) The subject I-D obsoletes RFC4677 if approved. The RFC4677 is a
IETF WG's procedure overview.

2) RFC4677 is not a formal IETF process document but instead an
informational overview.

The IETF procedures are only done in the IETF WGs or IETF community,
how can an individual decide for the community!!! That is why we are
discussing it in a IETF-list, not in a non-WG-list.

AB

On 6/17/12, Abdussalam Baryun abdussalambar...@gmail.com wrote:
 The abstract mentions 'many people',  because many people may mean 4 to 10
 people. The annonced I-D lacks the method of discussion in the community
 (discussing such change), the draft mentions the input from any community
 individual to be accepted by editor and then approved by IESG, but does not
 mention the methodology of discussion between community members nor between
 editor and members, also no announcements of such updates mentioned in
 draft.

 suggest amend in abstract the word 'many' to the word  'some', or mention
 like in the introduction the desire of community.

 suggest to add to the draft that a discussion group to discuss
 inputs/suggestions before the editors undertakes changes. The draft to
 specify the discussion ( may be either on-List or during the IETF
 meetings). I prefer to mention; the face-to-face IETF meeting discussion in
 this procedure issue.

 suggest to add  the announcement for last call of Tao changes by the
 IESG,

 suggest replace in section2 line 7 The editor of the Tao decides which
 proposed changes should be submitted to the IESG for the next version of
 the Tao.

  replace with The editor of the Tao decides which proposed changes
 should be
   submitted to the IESG for the next version of the
 Tao after
   the community discussed the changes.

 suggest A time period of updates to be made, and input from the community
 to be collected, and editor to submit to IESG. It will be helpful also to


 AB
 ==

 On Fri, Jun 15, 2012 at 9:29 PM, The IESG iesg-secret...@ietf.org wrote:


 The IESG has received a request from an individual submitter to consider
 the following document:
 - 'Publishing the Tao of the IETF as a Web Page'
  draft-hoffman-tao-as-web-page-02.txt as Informational RFC

 The IESG plans to make a decision in the next few weeks, and solicits
 final comments on this action. Please send substantive comments to the
 ietf@ietf.org mailing lists by 2012-07-13. Exceptionally, comments may be
 sent to i...@ietf.org instead. In either case, please retain the
 beginning of the Subject line to allow automated sorting.

 Abstract


   Discussion of the Tao of the IETF during 2012 made it clear that
   many people want the document published only as a web page, not as an
   RFC that needs to be periodically updated.  This document specifies
   how the Tao will be published as a web page.




 The file can be obtained via
 http://datatracker.ietf.org/doc/draft-hoffman-tao-as-web-page/

 IESG discussion can be tracked via
 http://datatracker.ietf.org/doc/draft-hoffman-tao-as-web-page/ballot/


 No IPR declarations have been submitted directly on this I-D.

Re: Comments for I-D of Publishing the Tao of the IETF as a Web Page

2012-06-20 Thread Abdussalam Baryun

I got a request to clarify (language and reference) my message:

 Conflict process if we consider the I-D process as a IETF process. It
 is not consistent with the IETF procedures. It can be consistent if
 the IESG amend the I-D submission-process or take my suggestions.

 I refere to the IETF process of: preparing the I-D by WG,
Community-accepting, Submitting, and IESG-approval. The new
Tao-update-process of the draft is not including the community. The
IETF process in draft is as : individual preparing, individual submit
to Editor, Editor decides and accepts, Editor submitting, and
IESG-approval.

The above are two different IETF submission streams, which may be
consistent if we include *the community* in accepting submission to
IESG.



RFC4844section 4.1.3

4.1.3. Process Change
From time to time, it may be necessary to change the approval
processes for any given stream, or even add or remove streams. This
may occur when the RFC Editor, the IAB, the body responsible for a
given stream of documents, or the community determines that there are
issues to be resolved in general for RFC approval or for per-stream
approval processes.
In this framework, the general approach is that the IAB will work
with the RFC Editor and other parties to get community input and it
will verify that any changes appropriately account for community
requirements.

RFC4844section 5
The subsections below identify the streams that exist today. There
is no immediate expectation of new streams being created and it is
preferable that new streams NOT be created. Creation of streams and
all policies surrounding general changes to the RFC Series are
discussed above in Section 4.

5.1. RFC Approval Processes
5.1.1. IETF Document Stream
5.1.2. IAB Document Stream
5.1.3. IRTF Document Stream
5.1.4. Independent Submission Stream

===

To understand IETF procedures of processes and document-streams I
refer you to sections 4 and 5 in [RFC4844], and section 4 in [RFC5378]
, may read also RFC5741, RFC5742, and FC2418.

However, if you still don't understand my language or if I
misunderstood, please advise/comment :)

Regards
AB

+++

On 6/19/12, Abdussalam Baryun abdussalambar...@gmail.com wrote:
 Hi Melinda, and All,

This is consistent with how individual, non-WG documents are
progressed in the IETF.  I don't see a conflict or discontinuity.

 Conflict process if we consider the I-D process as a IETF process. It
 is not consistent with the IETF procedures. It can be consistent if
 the IESG amend the I-D submission-process or take my suggestions.

 Yes I agree that non-WGs documents take different submission stream
 than IETF-WGs documents. One is named non-IETF submission and the
 other IETF submission streams (two only streams so far). In the I-D we
 are discussing of [publishing the Tao of the IETF], the submission
 stream was not refered to which of two submission streams. It is most
 likely understood as a new second IETF submission stream (I may name
 it IETF-Tao stream), because this I-D affect the community (it must be
 a group production not an individual production).

 Please note that:
 1) The subject I-D obsoletes RFC4677 if approved. The RFC4677 is a
 IETF WG's procedure overview.

 2) RFC4677 is not a formal IETF process document but instead an
 informational overview.

 The IETF procedures are only done in the IETF WGs or IETF community,
 how can an individual decide for the community!!! That is why we are
 discussing it in a IETF-list, not in a non-WG-list.

 AB
 
 On 6/17/12, Abdussalam Baryun abdussalambar...@gmail.com wrote:
 The abstract mentions 'many people',  because many people may mean 4 to
 10
 people. The annonced I-D lacks the method of discussion in the community
 (discussing such change), the draft mentions the input from any community
 individual to be accepted by editor and then approved by IESG, but does
 not
 mention the methodology of discussion between community members nor
 between
 editor and members, also no announcements of such updates mentioned in
 draft.

 suggest amend in abstract the word 'many' to the word  'some', or
 mention
 like in the introduction the desire of community.

 suggest to add to the draft that a discussion group to discuss
 inputs/suggestions before the editors undertakes changes. The draft to
 specify the discussion ( may be either on-List or during the IETF
 meetings). I prefer to mention; the face-to-face IETF meeting discussion
 in
 this procedure issue.

 suggest to add  the announcement for last call of Tao changes by the
 IESG,

 suggest replace in section2 line 7 The editor of the Tao decides which
 proposed changes should be submitted to the IESG for the next version of
 the Tao.

  replace with The editor of the Tao decides which proposed changes
 should be
   submitted to the IESG for the next version of
 the
 Tao after

Re: Comments for I-D of Publishing the Tao of the IETF as a Web Page

Hi SM,

I thank you for your comments and input,

The I-D being discussed (draft-hoffman-tao-as-web-page-02), does
mention the discussion on a list, but it does not mention the
community or consensus. The point of this I-D is to make the process
easier and valuable for users and memebrs, so I don't suggest to make
such discussion on the list mandatory for this webpage process.

 RFC 4844 discusses about RFC Series and the streams used by the
 various communities to publish a RFC.  One of those streams is for
 IETF Documents.

Please note that the milestone/aim of the I-D and the webpage is to
produce a RFC in the end of its progress. I think the webpage is a
IETF document published and edited differently than IETF-drafts. So
RFC4844 should be considered. Furthermore the I-D avoids to reference
or mention IETF procedure documents (mentions obslete documents), I
don't know why?

  In the I-D being discussed, the document will be
 published on a web page.  The IESG will choose Paul Hoffman as the
 editor.  I gather that those details are not a problem.

The problem is not choosing editor, but the webpage process. The Tao
webpage is a document but the question was is this document an IETF
document or a non-IETF document. Under the procedure IETF-documents
have a process. The draft-hoffman-tao-as-web-page-02 draft has a
different process even though it is an IETF-document. The draft if
approved will Obsletes RFC4677 (this document went through IETF
process, and will be replaced by webpage with different process) so
the only reference is the webpage and its progress is through new
stream of Tao-process.

  Are you suggesting that the changes should
 be discussed in a Working Group or something else?

I suggested the below message:

http://www.ietf.org/mail-archive/web/ietf/current/msg73750.html

I think that discussions should be limited times (in hours or few
days) which I prefer to take place in the IETF meetings and getting a
community consesus on the updates of the webpage. Because if we have
all individual-submissions with discussions and consensus of working
group then it will be disaster not making things easier. That is why I
suggest Editor acceptance with community consesus, and limited
discussions to solve the purpose of this I-D.

 BTW, RFC 4677 should be moved to Historic instead of Obsolete.

I agree with this suggestions.

Regards,
AB

++
On 6/20/12, SM s...@resistor.net wrote:
 Hi Abdussalam,
 At 03:51 20-06-2012, Abdussalam Baryun wrote:
  I refere to the IETF process of: preparing the I-D by WG,
Community-accepting, Submitting, and IESG-approval. The new
Tao-update-process of the draft is not including the community. The
IETF process in draft is as : individual preparing, individual submit
to Editor, Editor decides and accepts, Editor submitting, and
IESG-approval.

The above are two different IETF submission streams, which may be
consistent if we include *the community* in accepting submission to
IESG.

 RFC 4844 discusses about RFC Series and the streams used by the
 various communities to publish a RFC.  One of those streams is for
 IETF Documents.  In the I-D being discussed, the document will be
 published on a web page.  The IESG will choose Paul Hoffman as the
 editor.  I gather that those details are not a problem.

 draft-hoffman-tao-as-web-page-02 mentions that the changes will be
 discussed on an open, Tao-specific mailing list.  The second
 paragraph of Section 2 and the third paragraph are not so clear about
 changes, i.e. the editor accepts proposed changes and the IESG
 accepts proposed changes.  Are you suggesting that the changes should
 be discussed in a Working Group or something else?

 BTW, RFC 4677 should be moved to Historic instead of Obsolete.

 Regards,
 -sm

Re: Comments for I-D of Publishing the Tao of the IETF as a Web Page

Hi All

Discussing the draft draft-hoffman-tao-as-web-page-02

Can you say what was not so clear? I absolutely want that bit to be clear. 
Proposed text is appreciated here.

-Why the document/draft does not mention/reference other descriptive
related works?

-Why the document/draft obsoletes RFC4677, is there a big reason?

-Why is the document/draft not clear of its aim, objectives,
sub-process-periods, and update-announcement-procedure?

In the introduction
[This document contains the procedure agreed to by the IESG. The Tao
has traditionally been an IETF consensus document,..]
-Why the document/draft in section 2 does not mention consesus while
mentioned in introduction.

-Why the document/draft does not include section about the Tao-list
and this discussion method and purposes.

-Why the document/draft has one section after the introduction,
avoiding important sections like in RFC2418 (WG procedures) or as:
   a) Roles of Tao-webpage update.
   b) Roles of Individual submission to Editor.
   c) The community input to the webpage.
   d) What is the Editor criteria of accepting and refusing such updates.

Earlier versions of the Tao were made obsolete, not moved to Historic, so I 
thought it was most appropriate to do that here as well. FWIW, the definition 
of Historic in RFC 2026 is for specifications, not descriptive documents 
like the Tao.

Yes the early versions were obsoleted by a new RFC, not obsoleted by
RFC-that-references-webpage. I am not against the webpage, but against
to obsolete RFC4677. There should be a way to make one Tao RFC alive
while having the webpage. Maybe this I-D can update RFC4677 to add the
possibility of both RFC and webpage.

I'll +0 the draft to avoid changing the state of consensus.

I agree and want the *consesus* and *community* input to be clear in the draft

I hope my message language is good/ok to understand, if not please
advise and I will send another clarification,

Regards
AB
==

Re: Protocol Definition

I got help from a friend, to amend the definition statement to:

All protocols in IETF are based on the Internet or/and the IP.

AB

Defining any protocol has to consider somehow it's networks


On 6/18/12, Abdussalam Baryun abdussalambar...@gmail.com wrote:
 IMO the important issue in any definition is to include how the IETF
 defines protocol,
 this may be find in some RFCs :)

 The IP is the main protocol, and all protocols in IETF are based on IP
 and Internet.

 AB

Re: Protocol Definition

On 6/22/12, Randy Bush ra...@psg.com wrote:
 All protocols in IETF are based on the Internet or/and the IP.


RFC 826

read in first page

[The purpose of this RFC is to present a method of Converting
Protocol Addresses (e.g., IP addresses) to Local Network
Addresses (e.g., Ethernet addresses). This is a issue of general
concern in the ARPA Internet community at this time. The
method proposed here is presented for your consideration and
comment. This is not the specification of a Internet Standard.]



 randy

How IETF Protocols are Definition?

2012-06-22 Thread Abdussalam Baryun

Hi All,
+
Previos subject: Protocol Definition
Change the subject so we can focus on the reality of IETF purpose
+
The thing is that the definition has been discussed on the list and
they were very good overall. However, the first question is not
defining but how our IETF-WGs define protocols. If you cannot find a
definition then write a RFC about the definition and you will notice
that it will not pass through until you define it in the limits that I
tried to define.

There are RFC that were/are in IETF that didn't mention there
applicability statement or use cases, which I think is very important
is designing any protocol as:
1- what was it designed for? and  2- how will it be used?
But thoes RFCs/protocols are for the Internet network, so that is why
IETF is involved. I don't think that IETF is standardizing protocols
that are/can not used in Internet network.

Therefore, all protocols/RFCs in IETF SHOULD be produced in consistent
with IETF purpose, and RECOMMENDED to define its
use-case/applicability. However, it will be nice to think to write a
draft of defining *IETF protocols and technologies*, which I may do in
future interested, because this thread is going long :)

Thanks, Donald and Tony for your points/comments, but we may see the
RFCs that update your pointed-RFCs and in the future it may be updated
as well to invision IETF purpose.

AB
===

On 6/22/12, Donald Eastlake d3e...@gmail.com wrote:
 How about RFC 1661.

 Thanks,
 Donald
 =
  Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
  155 Beaver Street, Milford, MA 01757 USA
  d3e...@gmail.com

 On Fri, Jun 22, 2012 at 1:17 PM, Tony Finch d...@dotat.at wrote:
 Randy Bush ra...@psg.com wrote:

  All protocols in IETF are based on the Internet or/and the IP.

 what a laugh.  try, for example, RFC 826

 Perhaps a better example is RFC 6325.

 Tony.
 --
 f.anthony.n.finch  d...@dotat.at  http://dotat.at/
 Cromarty: Northeasterly backing westerly, 5 or 6. Moderate or rough.
 Occasional rain. Moderate or poor.

Proposing to create an IETF WG in the general area

2012-06-24 Thread Abdussalam Baryun

Hi All,

I think there is a need to have at least one WG in the General Area
(GA). The question is: why we have a GA without focused work or
community representation? I understand from the IETF procedures that
this organisation works through WGs, so it can make progresses through
WGs. The GA has no WG, therefore, Does that mean the area is not
progressing or there is no work done in the area? Furthermore, the
general area related RFCs cannot be found under such IETF-tool-trac
like in other areas.

Proposed WG: will look into RFCs related to the area and to find out
what is missing, or how to direct/organise the GA's input decisions or
I-D submitted by the IETF community.

Overall, IMHO there are work done for the GA purposes but it is not
directed/organised by a IETF-WG, therefore, I propose to create a WG
for GA with a trac.tool to make progress efficient and easy to follow
up :)

Regards,

Abdussalam Baryun,
University of Glamorgan, UK
+++
In discussions one may be wrong, or may be right, but it does not matter
  if we work together as a team to progress and resolve all open issues.
  IETF WGs are always right, and they represent the IETF community.

Re: Comments for I-D of Publishing the Tao of the IETF as a Web Page

2012-06-24 Thread Abdussalam Baryun

Propose to include in the I-D draft-hoffman-tao-as-web-page-02.txt
an IETF-WG that is created in the IETF General Area to discuss Tao
document/webpage issues,

AB
===

Re: Proposing to create an IETF WG in the general area

2012-06-25 Thread Abdussalam Baryun

Hi Tidd and All,

The General Area WGs focus on IETF processes and policies, I don't
think projects are done there,

So then would this WG also be an incubator for projects?

The IETF-WG I propose is only to do with IETF processes and policies
(procedures, and best practices), not incubator projects,

All organisations in the world have defined Business Information
System (BIS) that organises its procedure-policy, information and
processes. In IETF we have the BIS as well, but I don't see a clear
focused group (like in other organisation) on that updates/follow-ups
on the BIS for the future. Other organisation have a management
committee for this issue of procedure-updates. Therefore, a WG for
this purpose is necessary for two things 1) The WG job is only to
follow up with policy issues and if there is a need for update 2) so
that when a memebr wants to submit a I-D for to update/replace a
policy I can submit to IETF and a focused WG.

Please advise or provide your comments,

AB
===

From: tglassey tglassey at earthlink.net
To: ietf at ietf.org
Date: Sun, 24 Jun 2012 06:22:53 -0700

Gen Area groups also functioned as reception gateways for projects too
meaning that the WG Manager in this group would be a lobbyist as well
in passing new projects to other WG's once set up.
So then would this WG also be an incubator for projects?

Todd

Re: Gen-ART review of draft-ietf-bliss-shared-appearances-11

2012-06-29 Thread Abdussalam Baryun

Hi David,

I was not aware of this wiki and review team. does this team review
IETF procedure and policies, please advise,

AB
===
I am the assigned Gen-ART reviewer for this draft. For background on
Gen-ART, please see the FAQ at
http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq.

Please resolve these comments along with any other Last Call comments
you may receive.

Document: draft-ietf-bliss-shared-appearances-11
Reviewer: David L. Black
Review Date: June 28, 2012
IETF LC End Date: June 28, 2012
IESG Telechat date: (if known)

Summary:

This draft is on the right track but has open issues, described in the review.

This draft describes support for shared appearances in support of multi-line
and shared-line telephone often found in businesses.  All of the open issues
are minor.  The draft is well-written and reasonably clear for the most part,
although significant SIP expertise is required to completely understand it.

Major issues:  None.

Minor issues:

4.1 - REQ-16:

   in this case, seizing the line is the same thing as dialing.

That seems wrong - I would have thought it was a prerequisite as
opposed to the same thing because seizing the line is immediately
followed by a dialing request.

5.3.

   A user may select an appearance number but then abandon placing a
   call (go back on hook).  In this case, the UA MUST free up the
   appearance number by removing the event state with a PUBLISH as
   described in [RFC3903].

What happens when that can't be done due to UA or network failure?

5.4.

   A 400 response is returned if the chosen appearance number is invalid,

Is that always a 400 (Bad Request) or is any 4xx response allowed?  If
it's always 400, add the words Bad Request after 400.

   If the Appearance Agent policy does not allow this, a 400 response
   is returned.

Same question.  In addition, is 403 Forbidden allowed here?

   If an INVITE is sent by a member of the group to the shared AOR (i.e.
   they call their own AOR), the Appearance Agent MUST assign two
   appearance numbers.  The first appearance number will be the one
   selected or assigned to the outgoing INVITE.  The second appearance
   number will be another one assigned by the Appearance Agent for the
   INVITE as it is forked back to the members of the group.

How does that interact with the single appearance UAs in 8.1.1 that won't
understand the second appearance number?  A warning that such a UA can't
pick up its call to its own AOR would suffice, either here or in 8.1.1.

9.1

   A UA that has no knowledge of appearances must will only have
   appearance numbers for outgoing calls if assigned by the Appearance
   Agent.  If the non-shared appearance UA does not support Join or
   Replaces, all dialogs could be marked exclusive to indicate that
   these options are not available.

Should that could be marked be changed to SHOULD be marked ?
Also, analogous questions for could in 9.2 and can in 9.3.

All three of these affect interoperability.

12. Security Considerations

In general, this section is weak on rationale - the second, third and
fourth paragraphs should all explain more about the purpose of and/or
rationale for their security requirements (e.g., what does the security
mechanism protect against and when/why might that protection be desired
and/or required?).

   NOTIFY or PUBLISH message bodies that provide the dialog state
   information and the dialog identifiers MAY be encrypted end-to-end
   using the standard mechanisms.

What are the standard mechanisms?  List them, and provide references,
please.

Please ensure that the section 6 XML and Section 7 ABNF are
syntax-checked with actual tools.

Nits/editorial comments:

p.10:

   The next section discusses the operations used to implement parts of
   the shared appearance feature.

The following list describes the operations ... would be better.

5.3.1.

   A UA wanting to place a call but not have an appearance number
   assigned publishes before sending the INVITE without an 'appearance'
   element but with the 'shared' event package parameter present.

I think I understand what was intended here, but this would be clearer
if publishes was replaced with language about sending a PUBLISH.
It's also not completely clear whether without applies to the
INVITE or the PUBLISH, so this sentence probably needs to be reworded.

5.4. - Expand B2BUA acronym on first use.

idnits 2.12.13 ran clean.

Thanks,
--David

David L. Black, Distinguished Engineer
EMC Corporation, 176 South St., Hopkinton, MA  01748
+1 (508) 293-7953 FAX: +1 (508) 293-7786
david.black at emc.comMobile: +1 (978) 394-7754

Re: [manet] MANET Terminology Update

2012-07-03 Thread Abdussalam Baryun

 by the attacker of the transmitted MANET routing
information or the transmitted data information from its neighbor's
transmitted radio packet. Attacker’s processes MANY be used by attacker
to mislead routing. Eavesdropping does not pose a direct threat to the
MANET or to its routing.

Identity Spoofing:
Attacker sends routing messages, pretending to have the MANET identity
of another node.

Link Spoofing:
Compromised MANET router sends routing messages to neighbor node(s)
providing incorrect set of link information.

Replay Attack:
A Compromised router in one MANET region records control traffic
information and replays the recorded information in a different MANET
region (this type of attack is also called the Wormhole attack).

Broadcast Storm:
Compromised MANET router may attack the MANET by attempting to change
the MANET flooding algorithm(s) to increase routing overheads or/and to
increase the route discovery delay. Broadcast storm degrades the data
traffic delivery and MANET performance.

Falsification in MANET:
The compromised MANET router sends false routing information into MANET.
False routing information received in MANET, MAY create unrealistic
information bases.

ICMP Attacks:
The generation of ICMPv6 error messages may be used by compromised MANET
router to attempt DoS attacks by sending an error-causing source routing
header in back-to-back datagrams. As the ICMP messages are passed to the
upper-layer processes, it is possible to perform attacks on the upper
layer protocols (e.g., UDP, TCP). Protocols at the upper layers are
RECOMMENDED to perform some form of validation to ICMP messages (using
the information contained in the payload of the ICMP message) before
acting upon them.

Source Routing Attacks: TBD

Acknowledgments:

This work has used/modified terms of the following documents: RFC2462,
RFC2501, RFC3561, RFC3626, RFC3753, RFC4728, RFC4861, RFC5444,
RFC6130,  RFC6621, [AODVv2], [OLSRv2], and [HERBERG],
Gratefully acknowledge to the IETF community and all contributions.

Reference:
   [HERBERG] Herberg, U., Yi, J., Clausen, T.,Security Threats for
 NHDP, Work in progress, March, 2012.
   [ANJUM]   Anjum, F. and Mouchtaris, P. Security for Wireless Ad Hoc
 Networks, John Wiley  Sons, March 2007.
 ISBN: 978-0-471-75688-0.


I hope to get some advise from the Internet community to make the
definitions more suitable/accurate, because I MAY misunderstood.
Thanking you,

Best Regards

Abdussalam Baryun
University of Glamorgan, UK
=

Re: IETF Nominations Committee Chair - 2012 - 2013

2012-07-05 Thread Abdussalam Baryun

+1

I agree to work with you, internet community and Mr.Matthew Lepinski,
to progress the process for nominations, and make it successful,

AB
==
If people work together as a team, best practices and success are reached
==

 Mehmet,


 In my experience, the most important characteristic for a nomcom chair
 is the ability to lead a group of 10 volunteers (usually with a
 significant variation of experience in IETF) through the process as
 defined by RFC  3777 (and 5680).It can be good for a chair to have
 past Nomcom experience, but I do not believe that is a hard
 requirement (I had never served on a Nomcom before I was chair).  It
 can be good for a Nomcom chair to have been a WG chair as they can
 understand more about the process. BUT, the chair is not the decision
 maker - the voting members are - the most important thing is for the
 chair to be able to facilitate the process as defined.  It's far more
 important for the voting members to have that knowledge than the
 chair.   Now, it can be more challenging if a chair hasn't been
 involved in IETF for a while, but AFAIK, Matt has been involved in the
 RAI area (as a participant/contributor) for a while and if you google
 you can find he's also been involved in the Security area on the
 SECDIR. You can see the work he's been involved in here in
 authorstats:
 http://www.arkko.com/tools/allstats/mattlepinski.html


 Honestly, one of the most important aspect of the Nomcom process is
 for the Nomcom to get community feedback. You can read my report from
 2009-2010 and that is an issue as the information that the nomcom is
 working with typically is extremely incomplete.  Many nomcom voting
 members have little experience with interviewing and hiring
 employees.  You also have to keep in mind that the past Nomcom chair
 serves as an advisor for the current Nomcom chair, which dramatically
 reduces the risk in the case that the appointed chair runs into
 problems.


 I sincerely thank Matt for his willingness to take on this task as it
 requires a tremendous time commitment and dedication to do well.


 Regards,
 Mary.


 On Wed, Jul 4, 2012 at 4:18 AM, Ersue, Mehmet (NSN - DE/Munich)
 mehmet.ersue at nsn.com wrote:

 Hi,



 it’s time again for Nomcom. Congrats and good luck to Matt Lepinski.

 I have to admit I don’t know him. I assume this is my issue as I’m an
 OPS guy and not much involved in atoca or geopriv.



 Having been active in two Nomcoms, I am wondering what a useful
 selection criteria for a Nomcom chair could be.

 Having experience as a WG chair or having been active as Nomcom voting
 member?

 I can imagine a retired AD would enjoy it and do an excellent job in
 this position.



 Cheers,
 Mehmet

Re: Last Call: draft-hoffman-tao-as-web-page-02.txt (Publishing the Tao of the IETF as a Web Page) to Informational RFC

2012-07-05 Thread Abdussalam Baryun

+1

I support all your suggestions (i.e. point 1 and 2, and nits i and ii
) , and hope that iesg, and editor agrees, and that the community
considers them for progress. I seen the change in the
draft-document-03 which I think getting better but still not satisfied

The new vesion 3 draft (dated 5 July) does not include all your
suggestion, please read and comment on draft-03 (the subject refers to
draft-02, did you read draft-03?).
http://tools.ietf.org/html/draft-hoffman-tao-as-web-page-03

AB
=
My previous input to the subject:
+++
http://www.ietf.org/mail-archive/web/ietf/current/msg73771.html
http://www.ietf.org/mail-archive/web/ietf/current/msg73776.html
http://www.ietf.org/mail-archive/web/ietf/current/msg73781.html
http://www.ietf.org/mail-archive/web/ietf/current/msg73782.html
http://www.ietf.org/mail-archive/web/ietf/current/msg73791.html
==

 The IESG has received a request from an individual submitter
 to consider the following document:
 - 'Publishing the Tao of the IETF as a Web Page'
   draft-hoffman-tao-as-web-page-02.txt as Informational RFC

 The IESG plans to make a decision in the next few weeks, and
 solicits final comments on this action. Please send
 substantive comments to the ietf at ietf.org mailing lists by
 2012-07-13.

 Hi.

 Just to make a pair of comments that I've sort of made in other
 contexts in the particular context of the Last Call.   I won't
 repeat the details.

 (1) As a general strategy, doing the Tao as a web page seems
 like exactly the right thing to do.  Some sort of staging
 process and opportunity for review of working drafts by the
 community as well as the IETF seems important.  As far as I can
 tell, the document covers that adequately although some details
 are not spelled out as well as some would perhaps prefer.

 (2) The document itself mixes a historical discussion of how
 things got to where they are with what is being done going
 forward.   I believe it would be desirable to more clearly
 separate that material, into either separate documents or into a
 brief core document that focuses of the three questions of what
 is the Tao, where can it be found, and what is the revision/
 update procedure and an appendix that includes whatever else is
 determined to be necessary.  In that regard, the abstract of the
 core (or only) document should not concentrate on when
 discussions occurred, etc., but simply on what the Tao is and
 why it might be useful.  Liberal borrowing from the abstract of
 RFC 4677 (or just copying it) would be, IMO, quite appropriate.

 This is less of a problem than it might otherwise be because the
 document is so short, but a document that obsoletes RFC 4677 and
 its predecessors should address the substances addressed by
 4677, not serve as a historical summary of a few months of
 community discussion.

 Nits:
 (i) In recent years, the IESG has insisted on specific
 documentation when one RFC obsoletes another.  This draft does
 not mention the obsoletes relationship in the Abstract,
 Introduction, or any other prominent place.

 (ii) Second paragraph of current Introduction, first sentence,
 should contain discussion that led... rather than discussion
 that lead  I believe that paragraph is part of the
 historical discussion that belongs somewhere else.

 thanks,
john

Re: Last Call: draft-hoffman-tao-as-web-page-02.txt (Publishing the Tao of the IETF as a Web Page) to Informational RFC

2012-07-06 Thread Abdussalam Baryun

Hi John,

Let's wait for the iesg and I trust they will find the solution after
they read our comments. I beleive that your comments are sound, and
will be taken by the iesg. If things turn against your suggestions
there are some procedure-options to go forward, but I don't think will
be in that direction.

AB

On 7/6/12, John C Klensin john-i...@jck.com wrote:


 --On Friday, July 06, 2012 07:16 +0200 Abdussalam Baryun
 abdussalambar...@gmail.com wrote:

 +1

 I support all your suggestions (i.e. point 1 and 2, and nits i
 and ii ) , and hope that iesg, and editor agrees, and that the
 community considers them for progress. I seen the change in the
 draft-document-03 which I think getting better but still not
 satisfied

 The new vesion 3 draft (dated 5 July) does not include all your
 suggestion, please read and comment on draft-03 (the subject
 refers to draft-02, did you read draft-03?).
 http://tools.ietf.org/html/draft-hoffman-tao-as-web-page-03

 Abdussalam,

 Paul's note about draft 03 indicates that he posted it partially
 in response to my comments.  Those comments were based on 02.
 From my point of view, there is always a question about how much
 energy a document like this is worth: it is not normative or
 authoritative and, while I'd prefer to see it done differently
 (and said so in a follow-up note after skimming -03), I've got
 other IETF work to do and would prefer to see Paul and the IESG
 working on the Tao text itself rather than fine-tuning this
 document.

 I personally believe that the document could be further improved
 by moving it toward my earlier suggestions.   I believe that
 more what is this about text belong in the Abstract and, in
 particular, that the relationship of the Tao (whether as an RFC
 or as a web page) deserves more explicit treatment than the
 second sentence of the Introduction.  And I believe that forcing
 another RFC if details of the revision process are changed is a
 bad idea and so think that Section 2 (of -03) should talk about
 an initial procedure and/or in much more general terms but
 should then push details and changes off to the Tao itself
 (perhaps as an appendix).  Ultimately, if we cannot trust the
 IESG and the Editor to be careful and sensible about this
 document, we are going to have problems that fine-tuning the RFC
 text can't prevent.

 But, if Paul and the IESG don't agree, I'm not convinced the
 subject justifies a lot more energy.

 best,
john

Updating RFC2119

2012-07-22 Thread Abdussalam Baryun

Hi All,

I am working on an I-D which is intended as proposed standard but need
some addition requirement language. Therefore, I want to propose to
write a draft to update RFC2119 to add some other language requirement
as below:

IF x, THEN y:

ELSE:

ELSE IF:

Please send your comments or advise, thanking you,

Regards

Abdussalam Baryun
University of Glamorgan, UK
+

Re: Updating RFC2119

2012-07-23 Thread Abdussalam Baryun

Hi Stewart,

Usually the (IF x, THEN y) means if x happens then y is a MUST, so I
don't see the important reflection of a MUST in many documentation
when using *if*. That is why I prefer to find requirements more easily
while skimming any IETF document, the MUST, SHOULD, and IF, these are
important requirement words in specifications. Please see below as
examples per your requested.

--
RFC4861page36 IMO suggest to use IF, THEN

If no entry exists, the sender creates one, sets its state
to INCOMPLETE, initiates Address Resolution, and then queues the data
packet pending completion of address resolution.
--
RFC4861page 49 IMO suggest to use IF and ELSE IF

If the router already has a Neighbor Cache entry for the
solicitation’s sender, the solicitation contains a Source Link-Layer
Address option, and the received link-layer address differs from that
already in the cache, then the link-layer address SHOULD be updated
in the appropriate Neighbor Cache entry, and its reachability state
MUST also be set to STALE. If there is no existing Neighbor Cache
entry for the solicitation’s sender, the router creates one, installs
the link- layer address and sets its reachability state to STALE as
specified in Section 7.3.3. If there is no existing Neighbor Cache
entry and no Source Link-Layer Address option was present in the
solicitation, the router may respond with either a multicast or a
unicast router advertisement. Whether or not a Source Link-Layer
Address option is provided, if a Neighbor Cache entry for the
solicitation’s sender exists (or is created) the entry’s IsRouter
flag MUST be set to FALSE.
--
RFC5715page 19

If R changes before T, then a loop will form
around R, T, and S.
---
RFC6052 page 10 suggest delete *will* and to add as IF, THEN

If a packet bound to
192.0.2.33 reaches the translator, the destination address will be
translated to 2001:db8:122:344:c0:2:2100::, and the packet will be
routed towards R and then to A.
---

There are many examples that ignore the use of IF , THEN requirements,
which I suggest to be in the I-D update of RFC2119 that I working on
and will submit in 30 July,

Regards

Abdussalam Baryun
University of Glamorgan, UK
==

Preferable with a list of RFC text snippets that would have been
more readable if these keywords had been used.

Stewart


 On Sun, Jul 22, 2012 at 7:17 AM, Abdussalam Baryun
 abdussalambar...@gmail.com wrote:
 Hi All,

 I am working on an I-D which is intended as proposed standard but need
 some addition requirement language. Therefore, I want to propose to
 write a draft to update RFC2119 to add some other language requirement
 as below:

 IF x, THEN y:

 ELSE:

 ELSE IF:

 Please send your comments or advise, thanking you,

 That doesn't have to be in 2119.  Lots of RFCs have pseudocode at
 various levels of rigor.  Just look around at some protocol specs for
 examples.

Re: Updating RFC2119

2012-07-23 Thread Abdussalam Baryun

comments in line

 I'd encourage you to not try change 2119.

thanks for your comment

 Instead, add whatever new definitions you feel
 you need to your own draft that addresses some
 technical, and not process, topic.

I agree that I will need to add to the technical draft for now.

 If people find your new definitions useful they'll
 say and if enough of that happens they'll be
 included in a 2119bis whenever that's done.


this is the reason for this thread to see the feedback of the
community including me (at this time and the comings) and IMO the
submission of the I-D to update RFC2119 that includes new definition
may help the discussion, in the end the community will decide

AB
===

 On 07/23/2012 12:08 PM, Abdussalam Baryun wrote:
 Hi Stewart,

 Usually the (IF x, THEN y) means if x happens then y is a MUST, so I
 don't see the important reflection of a MUST in many documentation
 when using *if*. That is why I prefer to find requirements more easily
 while skimming any IETF document, the MUST, SHOULD, and IF, these are
 important requirement words in specifications. Please see below as
 examples per your requested.

 --
 RFC4861page36 IMO suggest to use IF, THEN

 If no entry exists, the sender creates one, sets its state
 to INCOMPLETE, initiates Address Resolution, and then queues the data
 packet pending completion of address resolution.
 --
 RFC4861page 49 IMO suggest to use IF and ELSE IF

 If the router already has a Neighbor Cache entry for the
 solicitation’s sender, the solicitation contains a Source Link-Layer
 Address option, and the received link-layer address differs from that
 already in the cache, then the link-layer address SHOULD be updated
 in the appropriate Neighbor Cache entry, and its reachability state
 MUST also be set to STALE. If there is no existing Neighbor Cache
 entry for the solicitation’s sender, the router creates one, installs
 the link- layer address and sets its reachability state to STALE as
 specified in Section 7.3.3. If there is no existing Neighbor Cache
 entry and no Source Link-Layer Address option was present in the
 solicitation, the router may respond with either a multicast or a
 unicast router advertisement. Whether or not a Source Link-Layer
 Address option is provided, if a Neighbor Cache entry for the
 solicitation’s sender exists (or is created) the entry’s IsRouter
 flag MUST be set to FALSE.
 --
 RFC5715page 19

 If R changes before T, then a loop will form
 around R, T, and S.
 ---
 RFC6052 page 10 suggest delete *will* and to add as IF, THEN

 If a packet bound to
 192.0.2.33 reaches the translator, the destination address will be
 translated to 2001:db8:122:344:c0:2:2100::, and the packet will be
 routed towards R and then to A.
 ---

 There are many examples that ignore the use of IF , THEN requirements,
 which I suggest to be in the I-D update of RFC2119 that I working on
 and will submit in 30 July,

 Regards

 Abdussalam Baryun
 University of Glamorgan, UK
 ==

 Preferable with a list of RFC text snippets that would have been
 more readable if these keywords had been used.

 Stewart


 On Sun, Jul 22, 2012 at 7:17 AM, Abdussalam Baryun
 abdussalambar...@gmail.com wrote:
 Hi All,

 I am working on an I-D which is intended as proposed standard but need
 some addition requirement language. Therefore, I want to propose to
 write a draft to update RFC2119 to add some other language requirement
 as below:

 IF x, THEN y:

 ELSE:

 ELSE IF:

 Please send your comments or advise, thanking you,

 That doesn't have to be in 2119.  Lots of RFCs have pseudocode at
 various levels of rigor.  Just look around at some protocol specs for
 examples.

Re: Last Call: draft-ietf-opsawg-automated-network-configuration-04.txt (Problem Statement for the Automated Configuration of Large IP Networks) to Informational RFC

2012-07-28 Thread Abdussalam Baryun

The draft-04 states in page-8:
---
5.1. Establishment of Link Layer Connectivity
The protocol aspects of this phase are out of scope, since it
involves non-IETF protocols only. While some link-layer technologies
may provide authentication and access control, this cannot be assumed
to be available in the general case.
---

If Link protocol is a non-IETF why it will be out of scope while used
by the IP devices? in the end the IP is over link protocols and
interacts with the below protocols. Why we need
applicability-statements or problem-statements if we think the link
layer is out of scope of IETF-RFCs?

Regards
AB

Fwd: New Version Notification for: draft-baryun-rfc2119-update-00.txt

Dear All,

I written this draft starting a RFC2119 update for the reasons of
discussion threads in [1] and [2]. Please check draft and feedback,
thanking you.

Best Regards
Abdussalam

[1] http://www.ietf.org/mail-archive/web/ietf/current/msg74048.html
[2] http://www.ietf.org/mail-archive/web/ietf/current/msg73338.html



From: internet-dra...@ietf.org
Date: Tue, 31 Jul 2012 23:31:10 -0700
Subject: New Version Notification for draft-baryun-rfc2119-update-00.txt

A new version of I-D, draft-baryun-rfc2119-update-00.txt
has been successfully submitted by Abdussalam Nuri Baryun and posted to the
IETF repository.

Filename:draft-baryun-rfc2119-update
Revision:00
Title:   Key Words of Conditional Language of Requirements Levels
Creation date:   2012-07-30
WG ID:   Individual Submission
Number of pages: 3
URL:
http://www.ietf.org/internet-drafts/draft-baryun-rfc2119-update-00.txt
Status:  http://datatracker.ietf.org/doc/draft-baryun-rfc2119-update
Htmlized:http://tools.ietf.org/html/draft-baryun-rfc2119-update-00


Abstract:
   In many standards track documents conditional words are used to
   signify the requirements in the specification. These words are
   prefered to be capitalized. This document defines these conditional
   words as they should be interpreted in IETF documents. Authors who
   follow these guidelines should incorporate this phrase near the
   beginning of their document. The additional key words to words
   described in RFC2119 are; IF, THEN, ELSE IF, ELSE.


The IETF Secretariat

Re: New Version Notification for: draft-baryun-rfc2119-update-00.txt

 This is a useless change to a very stable document. No one reading RFCs
 misunderstands what if and else mean.

We don't change the RFC2119 (IETF RFCs never can be changed) its only
update, no one before ever misunderstood may and should either but
capital letters made difference. However, thanks for your comments,

AB

Re: New Version Notification for: draft-baryun-rfc2119-update-00.txt

 I agree with what Paul and Melinda have said.  This document is pointless,
 as there is no actual problem that it's solving and no misunderstanding
 that it's clarifying.

It is solving the problem of specifications that don't specify
conditions in a easy manner that implementers/users need. Please note
that IF THEN is reducing the number of words in the draft as well
(more efficient). Please tell me what specification can specify a
conditional situation in less words than IF, THEN. Many RFC don't
follow the easy way properly,

 Further, it's actively *harmful*.

I implemented some RFC that don't specify if, then, and it was
harmful for me. I don't know what kind of harmful that the update will
make, please explain by an example. Do you mean harmful to the
reviewers or to the draft authors. Please note that we should make the
internet a better place for ALL not only for authors.

 It's arguable
 that 2119 already reserves too many words by giving them specific,
 normative meanings (SHALL *and* MUST; SHOULD *and* RECOMMENDED).  Adding
 IF, THEN, and ELSE would not only be unnecessary, but downright *bad*.


It is necessary, and the words in RFC2119 are not many if we compare
with our RFCs pages.

I thank you for your comments,

AB

Re: New Version Notification for: draft-baryun-rfc2119-update-00.txt

Hi Melinda,

I am already involved, and volunteering work, I done many reviews and
comments in two WGs, and will hopfuly continue if people are
welcoming. However, I thank you for your comments,

AB
==
The mission of the Internet Engineering Task Force is to make the
Internet work better by producing high-quality and relevant technical
documents that influence the way people design, use, and manage the
Internet
---

It's pretty clear that you'd like to be involved with the work
of the IETF in some way.  Allow me to suggest that a more productive
approach might be to identify a working group in your area of
expertise, review their documents, provide feedback on those
documents, and write text or new documents to address any gaps.
There is work to be done and there are problems to solve.  What
you are doing now is not helpful.

Melinda

Re: New Version Notification for: draft-baryun-rfc2119-update-00.txt

 Yes but that's an editing issue.  Go look at how process documentation
 and state machines are handled in serious protocol RFCs.  Some do use
 if/then in a formal way, but some are just informative.  The purpose
 of 2119 is clarity of terminology.

That is good when they use, I seen thoes, but how can we use
terminology so that don't collide, some people use 2119 terms that are
not condition, to describe conditions.

  Everyone knows what if and
 then mean - your concern is how they are used.

Yes my concern is how/when use terms not meaning of terms. Ok,  What
about MUST (every one know it), wasn't it clear as if then, please
explain why capital?

 The way to fix that
 is in the particular drafts you have an issue with.


 I did put that in one draft already as you say and one participant
before suggest. but I am thinking for the future works and to make the
authors document the specification they implemented more efficiently
without using 2119 terms in conditional and

I thank you for your comments, your email will be more concsidered,

AB

Re: New Version Notification for: draft-baryun-rfc2119-update-00.txt

2012-08-02 Thread Abdussalam Baryun

Hi SM,

Thanks for your comments, I will note your feedback and follow to read
into these issues as you advise, thanking you,

Best Regards
AB
==

On 8/1/12, SM s...@resistor.net wrote:
 At 11:19 AM 8/1/2012, Abdussalam Baryun wrote:
Yes my concern is how/when use terms not meaning of terms. Ok,  What
about MUST (every one know it), wasn't it clear as if then, please
explain why capital?

 You are probably receiving feedback on your draft because the WG
 sessions this week are boring. :-)  The is a thread about all caps
 at http://www.ietf.org/mail-archive/web/ietf/current/msg73338.html  I
 suggest reading RFC 1122 and RFC 1123 to get a view of how some
 specifications were written and why they were written in such a way.

 Melinda Shore provided some good advice (
 http://www.ietf.org/mail-archive/web/ietf/current/msg74191.html ).  I
 would not say that your draft is not helpful.  It is up to you to
 assess whether draft-baryun-rfc2119-update-00 can gain IETF Consensus.

 Regards,
 -sm

Re: RFC Errata: when to file, and when not to

2012-08-02 Thread Abdussalam Baryun

Hi Barry,

Could you refer to a RFC that states your below information or
procedure, if there is not, I recommend some one doing procedure
drafts to take it over. Please note that ALL reports from any
participant should be useful for IETF community and system. Even if
he/she misunderstood, this does not mean that he/she is not useful,
that means the IETF system/community needs to adjust to help
participants to understand and follow.

For me I will note your procedure so that I will not report wrongly,
but I will continue reporting my comments/views, and hope if some
thing is wrong I get a reply like your, thanking you,

AB
IETF Particpant
==
The mission of the Internet Engineering Task Force is to make the
Internet work better by producing high-quality and relevant technical
documents that influence the way people design, use, and manage the
Internet.
==

 We've been seeing a lot of inappropriate errata reports, made by
 well-meaning people who, surely, think their reports are useful, even
 important.  These aren't free: they take time to process, and they
 form clutter in the errata system, obscuring the ones that do fit into
 what errata are meant to be.


 So I wanted to clarify what's meant to be reported, and what's not.


 A valid erratum, one that the IESG will mark as Verified, mets two
 criteria:


 1. It is truly an *error* in the original document.  That is, it would
 have been considered an error *at the time the document was
 published*, had it been noticed at the time.


 2. It is important, an error that would cause someone to misread the
 document in a significant way, causing implementation or deployment
 problems, or other serious issues.


 Criterion 1 means that anything that is wrong because of situations
 or discussions that have come up since publication are not appropriate
 errata.  Consider the differences among these:


 - (a) Someone realizes that the document forgot to specify the valid
 range of a value.


 - (b) Someone realizes that the range specified did not correctly
 reflect the result of the discussion at the time (the change got
 missed and no one noticed).


 - (c) Someone realizes that the range specified causes problems in
 practice, but we didn't know that would happen when we published the
 document.


 (a) and (b) are valid errata, and should get marked as Verified.
 (c) is NOT valid for the errata system, and really ought to be marked
 as Rejected.


 Criterion 2 means that minor typos are NOT appropriate errata.  The
 IESG will mark these as Held for Document Update, but, really, there
 is no need to say that an should be and, that a comma is missing
 (unless it seriously affects the meaning and is likely to be
 mis-read), or that concensus is misspelled (as here).  Again,
 consider the differences:


 - (a) The server will now respond with an error code, where now
 should have been not.


 - (b) The server will not repond with an error code, where repond
 should have been respond.


 - (c) The server will not respond with and error code, where and
 should have been an.


 (a) is the only valid one here.  There's no real value in recording
 the others as errata.


 In particular, the errata system is NOT meant to be used as an issue
 tracker; please do not submit errata reports with the *intent* that
 they be marked as Held for Document Update, to be used as an issue
 list later.  We have mailing lists, issue trackers, and wikis for this
 purpose.


 Barry, Applications AD

Re: Last Call: Modern Global Standards Paradigm

2012-08-12 Thread Abdussalam Baryun

+1

AB


 On Aug 10, 2012, at 8:19 AM, IETF Chair wrote:

 The IETF Chair and the IAB Chair intend to sign the Affirmation
 of the Modern Global Standards Paradigm, which can be found
 here:

 http://www.ietf.org/proceedings/84/slides/slides-84-iesg-opsplenary-15.pdf

 An earlier version was discussed in plenary, and the IAB Chair called
 for comments on the IETF mail list.  This version includes changes
 that address those comments.

 Th IETF 84 Administrative plenary minutes have been posted, so that
 discussion can be reviewed if desired.  The minutes are here:

 http://www.ietf.org/proceedings/84/minutes/minutes-84-iesg-opsplenary

 On 8 August 2012, the IEEE Standards Association Board of Governors
 approved this version of the document.  The approval process is
 underway at the W3C as well.

 The IETF Chair and the IAB Chair intend to sign the Affirmation in the
 next few weeks. Please send strong objections to the i...@iab.org
 and the ietf@ietf.org mailing lists by 2012-08-24.

 Thank you,
  Russ Housley
  IETF Chair

Re: [IAB] Last Call: Modern Global Standards Paradigm

2012-08-13 Thread Abdussalam Baryun

Hi Dave,

I agree that procedure of ietf processes should be respected and
followed by all, and/or community should understand such difference in
process before asked its opinion. I hope your comments will be
considered by IETF and IAB in the future.

thanking you for your comments,

AB
 --

 From: Dave Crocker dcrocker at bbiw.net
 To: Barry Leiba barryleiba at computer.org
 Cc: IAB iab at iab.org, IETF ietf at ietf.org
 Date: Sun, 12 Aug 2012 08:50:10 -0700

 Two weeks is normal process for spontaneous consensus calls?

 When did the community approve that change in process?

 No he didn't:

  Please send strong objections...

 This asserts a forceful bias against general comments and criticisms by
 establishing a very high threshhold for relevance.  While no, no one is
 prevented from other kinds of postings, the bias is nonetheless
 established.

 Note that he didn't ask for support, although explicit support
 statements are exactly what is required for IETF consensus calls, absent

 a history to justify the kind of default yes assumption made in the
 announcement. We don't have any such documented history for this
 effort.
 Would any of us guess that the community would support the document?
 Sure.  But guessing isn't the point.


 That folks have chosen to ignore the stricture specified in the
 announcement and to post public support shows how deeply ingrained our
 model is. And, yeah, enough such postings overwhelm problems with the
 last call wording...

 d/

 --
  Dave Crocker
  Brandenburg InternetWorking
  bbiw.net

Re: FW: Affirmation of the Modern Global Standards Paradigm

2012-08-15 Thread Abdussalam Baryun

Hi John,

Does this document actually have a purpose, and if so, what is it?

IMO the document introduces important statements (purpose and objectives)
so that other organisations and SDOs recognise while interacting with IETF.
It may look simple or known, but necessary for IETF future cooperations.

I agree that your question is very important and that the best person to
answer is the Chair of IETF or IAB.

AB

Re: FW: Affirmation of the Modern Global Standards Paradigm

2012-08-15 Thread Abdussalam Baryun

John,

Could you suggest a solution to this issue or an additional statements to
the document, I think then the document may need amendment, to consider
your advise/experience.

AB

On Wed, Aug 15, 2012 at 2:46 PM, John E Drake jdr...@juniper.net wrote:

 AB,

 ** **

 I don’t think the principles articulated in this document will come as a
 surprise to any SDO with which the IETF interacts and I don’t think this
 document will prevent another SDO from acting badly wrt the IETF if it so
 chooses.  Also, bear in mind that ‘acting badly’ is entirely subjective.**
 **

 ** **

 For example, if you were to ask the ITU leadership if they ‘acted badly’
 during the MPLS-TP imbroglio, I think they would counter that it was the
 IETF that ‘acted badly’.  In fact, I have seen them say exactly this.

 ** **

 And lest we forget, we had a much more comprehensive agreement in place
 for MPLS-TP.

 ** **

 Thanks,

 ** **

 John

 ** **

 Sent from my iPhone

 ** **

 *From:* Abdussalam Baryun [mailto:abdussalambar...@gmail.com]
 *Sent:* Wednesday, August 15, 2012 6:29 AM
 *To:* John E Drake
 *Cc:* ietf
 *Subject:* Re: FW: Affirmation of the Modern Global Standards Paradigm

 ** **

 Hi John,

  

 Does this document actually have a purpose, and if so, what is it?

 IMO the document introduces important statements (purpose and objectives)
 so that other organisations and SDOs recognise while interacting with IETF.
 It may look simple or known, but necessary for IETF future cooperations.**
 **

  

 I agree that your question is very important and that the best person to
 answer is the Chair of IETF or IAB. 

  

 AB

Re: Last Call: draft-ietf-manet-olsrv2-15.txt (The Optimized Link State Routing Protocol version 2) to Proposed Standard

Reply to your request dated 29/08/2012

Draft Reviewed By: Abdussalam Baryun (AB)Dated:22/08/2012

Reviewer Comment  AB2:  Related to OLSRv2 Packets.


-The reviewer is not sure how/when the OLSRv2 generates packets
[RFC5444] or how it puts information in the packet. The I-D refers
back to the RFC5444 document but the document is a general
specification for all MANET routers, the reviewer thinks it is
important that OLSRv2-draft mentions what/how the OLSRv2 node puts
information in RFC5444 header or how a node uses the header
information.

-In OLSRv2-draft section 13.2  This specification does not define or
use any contents of the Packet Header.
The reviewer does not know why the router generates the packet and
does not use, or the reviewer does not know who generates it.

-RFC5444 specifies that IANA is registering namespaces for: Message
Types, Packet TLV Types, Message TLV Types, and Address Block TLV
Types.
OLSRv2-draft IANA consideration section does not mention any assign
for packet header related to OLSRv2 as in RFC5444 section 6.3 (e.g.
Packet TLV Types).

Regards
AB
---
This message and any attachments are confidential to the intended
recipient and may also be privileged. If you are not the intended
recipient please delete it from your system and notify the sender.
This message is in compliance with the IETF regulations.
---

On 7/29/12, The IESG iesg-secret...@ietf.org wrote:

 The IESG has received a request from the Mobile Ad-hoc Networks WG
 (manet) to consider the following document:
 - 'The Optimized Link State Routing Protocol version 2'
   draft-ietf-manet-olsrv2-15.txt as Proposed Standard

 The IESG plans to make a decision in the next few weeks, and solicits
 final comments on this action. Please send substantive comments to the
 ietf@ietf.org mailing lists by 2012-08-22. Exceptionally, comments may be
 sent to i...@ietf.org instead. In either case, please retain the
 beginning of the Subject line to allow automated sorting. This last call
 period has been extended to handle the fact that it spans the IETF-84
 meeting.

 This last call is being re-initiated to include a notice that this document
 includes a normative down reference to an Informational RFC:
 RFC5148, Jitter considerations in MANETs.

 Abstract

This specification describes version 2 of the Optimized Link State
Routing (OLSRv2) protocol for Mobile Ad hoc NETworks (MANETs).

 The file can be obtained via
 http://datatracker.ietf.org/doc/draft-ietf-manet-olsrv2/

 IESG discussion can be tracked via
 http://datatracker.ietf.org/doc/draft-ietf-manet-olsrv2/ballot/


 No IPR declarations have been submitted directly on this I-D.

Fwd: Last Call: draft-ietf-manet-olsrv2-15.txt (The Optimized Link State Routing Protocol version 2) to Proposed Standard

Reply to your request dated 29/07/2012

Draft Reviewed By: Abdussalam Baryun (AB)   Dated:
22/08/2012

Reviewer Comment  AB1: Terminology and Definition Related

In [1] the olsrv2-interface runs the NHDP, and some terms in [1] are
defined as in [2]:

Interface:
A router’s attachment to a communications medium. An interface is
assigned one or more addresses.

MANET interface:
An interface participating in a MANET and using this neighborhood
discovery protocol. A router may have several MANET interfaces.

Link:
A link between two MANET interfaces exists if either can be heard by the other.

These above terms’ definitions are different than in [4, 5, and 6].
The reviewer may understand links are logical or/and physical as
defined in [3].
Why definitions are not in consistent with other RFCs?

References
++
1- Clausen, T., Dearlove, C., Jacquet, P., Herberg, U., “The Optimized
Link State Routing Protocol version 2”, work in progress, IETF, May
2012.
2-Clausen, T., Dearlove, C., Dean, J., “Mobile Ad Hoc Network (MANET)
Neighborhood Discovery Protocol (NHDP)”, RFC6130, IETF, April 2011.
3-  Melia, T., Gundavelli, S., “Logical Interface Support for
multi-mode IP Hosts”, work in progress, IETF, April, 2012.
4- Manner, J., and Kojo, M., “Mobility Related Terminology”, RFC3753,
IETF, June 2004.
5- Narten, T., Nordmark, E., Simpson, W., Soliman, H., “Neighbor
Discovery for IP version 6 (IPv6)”, RFC4861, IETF, Sep. 2007.
6- Blanchet, M., Seite, P., “Multiple Interfaces and Provisioning
Domains Problem Statement”, RFC6418, IETF, Nov. 2011.
7- Corson, S., Macker, J., “Mobile Ad hoc Networking (MANET): Routing
Protocol Performance Issues and Evaluation Considerations”, RFC2501,
IETF, Jan. 1999.
===

Thanks
AB




+++
On 7/29/12, The IESG iesg-secret...@ietf.org wrote:

 The IESG has received a request from the Mobile Ad-hoc Networks WG
 (manet) to consider the following document:
 - 'The Optimized Link State Routing Protocol version 2'
   draft-ietf-manet-olsrv2-15.txt as Proposed Standard

 The IESG plans to make a decision in the next few weeks, and solicits
 final comments on this action. Please send substantive comments to the
 ietf@ietf.org mailing lists by 2012-08-22. Exceptionally, comments may be
 sent to i...@ietf.org instead. In either case, please retain the
 beginning of the Subject line to allow automated sorting. This last call
 period has been extended to handle the fact that it spans the IETF-84
 meeting.

 This last call is being re-initiated to include a notice that this document
 includes a normative down reference to an Informational RFC:
 RFC5148, Jitter considerations in MANETs.

 Abstract

This specification describes version 2 of the Optimized Link State
Routing (OLSRv2) protocol for Mobile Ad hoc NETworks (MANETs).

 The file can be obtained via
 http://datatracker.ietf.org/doc/draft-ietf-manet-olsrv2/

 IESG discussion can be tracked via
 http://datatracker.ietf.org/doc/draft-ietf-manet-olsrv2/ballot/


 No IPR declarations have been submitted directly on this I-D.

Re: Last Call: draft-ietf-manet-olsrv2-15.txt (The Optimized Link State Routing Protocol version 2) to Proposed Standard

Reply to your request dated 29/07/2012
Draft Reviewed By: Abdussalam Baryun (AB)Dated:22/08/2012

Reviewer Comment AB3:  Related to OLSRv2 Metric
++

OLSRv2-draft Note that the generation of (incoming) link metric
values is to be undertaken by a process outside this specification;
this
specification concerns only the distribution and use of those
metrics.

Comments The OLSRv2 uses dimensionless additive metric types. The
OLSRv2 link metric is unidirectional (in document mentions
directional).

Question The OLSRv2 specification uses dimensionless metric types,
which all nodes MUST support it. Does this mean that OLSRv2 doesn’t
support dimensional metric types?

-The Metric distribution and use:

Section 4.5 Each HELLO or TC message carrying link (or neighbor) metrics
thus indicates which link metric information it is carrying, allowing
routers to determine if they can interoperate. If link metrics
require additional signaling to determine their values, whether in
HELLO messages or otherwise, then this is permitted but is outside
the scope of this specification.

Question Where is metric defined in TC and hello messages between
neighbors or is it in the MPR message extension between MPRs. Does the
OLSRv2 router allow the both options or more others?

5.4.2 All routes found using this specification use a single link metric
type that is specified by the router parameter LINK_METRIC_TYPE,
which may take any value from 0 to 255, both inclusive.

Comment links are between MANET interfaces and each router may have
more than one interface, so how can we have only one link metric per
router. IMO, recommended single link metric per interface. However, in
the introduction of section 5 it mentions that routers’ parameters may
not be the same in MANET (does it contradict the single metric-type
parameter?).


-IANA Consideration for OLSRv2 Metric:

Comment Metric assigned in IANA (table 13) but recommended to be
defined as [additive dimensionless link metric]. In future use of
OLSRv2 there may be non-additive metric types, and dimensional types.

Regards
AB
---
This message and any attachments are confidential to the intended
recipient and may also be privileged. If you are not the intended
recipient please delete it from your system and notify the sender.
This message is in compliance with the IETF regulations.
---


On 7/29/12, The IESG iesg-secret...@ietf.org wrote:

 The IESG has received a request from the Mobile Ad-hoc Networks WG
 (manet) to consider the following document:
 - 'The Optimized Link State Routing Protocol version 2'
   draft-ietf-manet-olsrv2-15.txt as Proposed Standard

 The IESG plans to make a decision in the next few weeks, and solicits
 final comments on this action. Please send substantive comments to the
 ietf@ietf.org mailing lists by 2012-08-22. Exceptionally, comments may be
 sent to i...@ietf.org instead. In either case, please retain the
 beginning of the Subject line to allow automated sorting. This last call
 period has been extended to handle the fact that it spans the IETF-84
 meeting.

 This last call is being re-initiated to include a notice that this document
 includes a normative down reference to an Informational RFC:
 RFC5148, Jitter considerations in MANETs.

 Abstract

This specification describes version 2 of the Optimized Link State
Routing (OLSRv2) protocol for Mobile Ad hoc NETworks (MANETs).

 The file can be obtained via
 http://datatracker.ietf.org/doc/draft-ietf-manet-olsrv2/

 IESG discussion can be tracked via
 http://datatracker.ietf.org/doc/draft-ietf-manet-olsrv2/ballot/


 No IPR declarations have been submitted directly on this I-D.

Re: Last Call: draft-ietf-manet-olsrv2-15.txt (The Optimized Link State Routing Protocol version 2) to Proposed Standard

Reply to your request dated 29/07/2012
Draft Reviewed By: Abdussalam Baryun (AB)   Dated: 22/08/2012

Reviewer Comment AB4: Related to OLSRv2 Messages.


Section 13.2. Messages with different originating routers MAY be
combined for transmission within the same packet. Messages from other
protocols defined using [RFC5444], including but not limited to
[RFC6130], MAY be combined for transmission within the same packet.
This specification does not define or use any contents of the Packet
Header.

Comment the document describes the receive and processing of OLSRv2
messages, but not sure why not about processing of OLSRv2 packets.

Question in case of messages from other protocols, how the OLSRv2
router receives and processes the packet and/or different routing
messages?

Question is there possibility that OLSRv2 receives control messages
[RFC5444] which are not packed in RFC5444 packet, or is that not
allowed by the specification?

Regards
AB
---
This message and any attachments are confidential to the intended
recipient and may also be privileged. If you are not the intended
recipient please delete it from your system and notify the sender.
This message is in compliance with the IETF regulations.
---

On 7/29/12, The IESG iesg-secret...@ietf.org wrote:

 The IESG has received a request from the Mobile Ad-hoc Networks WG
 (manet) to consider the following document:
 - 'The Optimized Link State Routing Protocol version 2'
   draft-ietf-manet-olsrv2-15.txt as Proposed Standard

 The IESG plans to make a decision in the next few weeks, and solicits
 final comments on this action. Please send substantive comments to the
 ietf@ietf.org mailing lists by 2012-08-22. Exceptionally, comments may be
 sent to i...@ietf.org instead. In either case, please retain the
 beginning of the Subject line to allow automated sorting. This last call
 period has been extended to handle the fact that it spans the IETF-84
 meeting.

 This last call is being re-initiated to include a notice that this document
 includes a normative down reference to an Informational RFC:
 RFC5148, Jitter considerations in MANETs.

 Abstract

This specification describes version 2 of the Optimized Link State
Routing (OLSRv2) protocol for Mobile Ad hoc NETworks (MANETs).

 The file can be obtained via
 http://datatracker.ietf.org/doc/draft-ietf-manet-olsrv2/

 IESG discussion can be tracked via
 http://datatracker.ietf.org/doc/draft-ietf-manet-olsrv2/ballot/


 No IPR declarations have been submitted directly on this I-D.

Re: Last Call: draft-ietf-manet-olsrv2-15.txt (The Optimized Link State Routing Protocol version 2) to Proposed Standard

Reply to your request dated 29/07/2012
Draft Reviewed By: Abdussalam Baryun (AB)   Dated: 22/08/2012

Reviewer Comment AB5:  Related to OLSRv2 update to IP Routing Table.
+

Section 4.6 It is intended that the Routing Set can be used for IP packet
routing, by using its contents to update the IP routing table. That
update, and whether any Routing Tuples are not used in the IP routing
table, is outside the scope of this specification.

Question Why it is out of scope? For OLSRv2 router the *routing
table* update should be in-scope.

Regards
AB
---
This message and any attachments are confidential to the intended
recipient and may also be privileged. If you are not the intended
recipient please delete it from your system and notify the sender.
This message is in compliance with the IETF regulations.
---


On 7/29/12, The IESG iesg-secret...@ietf.org wrote:

 The IESG has received a request from the Mobile Ad-hoc Networks WG
 (manet) to consider the following document:
 - 'The Optimized Link State Routing Protocol version 2'
   draft-ietf-manet-olsrv2-15.txt as Proposed Standard

 The IESG plans to make a decision in the next few weeks, and solicits
 final comments on this action. Please send substantive comments to the
 ietf@ietf.org mailing lists by 2012-08-22. Exceptionally, comments may be
 sent to i...@ietf.org instead. In either case, please retain the
 beginning of the Subject line to allow automated sorting. This last call
 period has been extended to handle the fact that it spans the IETF-84
 meeting.

 This last call is being re-initiated to include a notice that this document
 includes a normative down reference to an Informational RFC:
 RFC5148, Jitter considerations in MANETs.

 Abstract

This specification describes version 2 of the Optimized Link State
Routing (OLSRv2) protocol for Mobile Ad hoc NETworks (MANETs).

 The file can be obtained via
 http://datatracker.ietf.org/doc/draft-ietf-manet-olsrv2/

 IESG discussion can be tracked via
 http://datatracker.ietf.org/doc/draft-ietf-manet-olsrv2/ballot/


 No IPR declarations have been submitted directly on this I-D.

Re: Last Call: draft-ietf-manet-olsrv2-15.txt (The Optimized Link State Routing Protocol version 2) to Proposed Standard

Reply to your request dated 29/07/2012
Draft Reviewed By: Abdussalam Baryun (AB)   Dated: 22/08/2012

Reviewer Comment AB6: Related to OLSRv2 Interfaces.


-Is NHDP a must for OLSRv2 routing?

Comment The relationship between RFC6130 and the [OLSRv2] was not
clear to reviewer (does OLSRv2 depend on NHDP or it may work without
it), is it only that Hello messages are defined in RFC6130 and router
interfaces. Reviewer may understood that the draft-OLSRv2 may extend
to define Hello messages by routers for its non-MANET interfaces.

Question is there a use case where OLSRv2 may work better without NHDP?

Section 5. As for the parameters in [RFC6130], parameters defined in this
specification MAY be changed dynamically by a router, and need not be
the same on different routers, even in the same MANET, or, for
interface parameters, on different interfaces of the same router.

Question but if routers may change parameters individually, what is
the consistency between routers, and how they cooperate?
Comment it is recommended to clarify some limits and use case to this
issue for stability purposes.

Section 5.1 TC messages and HELLO messages [RFC6130] MUST, in a given
MANET, both be using the same of either of IP or UDP, in order that it
is possible to combine messages of both protocols into the same
[RFC5444] packet for transmission.

Comment the words both protocols are they refering to IP and UDP or
they refer to OLSRv2 and NHDP. It should be clarified even though the
intention is NHDP/OLSRv2 (my add *port* to UDP, or replace *protocols*
with both names)

Question if there was two different Hellow messages in terms of
information, one of OLSRv2 type and the other NHDP type, what will the
OLSRv2 router take as valid neighbor information?

-OLSRv2 Interfaces' Addresses:

Section 10.5. R_local_iface_addr is an address of the local interface
over which
an IP packet MUST be sent to reach the destination by the selected
path.

Section 4.6 The purpose of the Routing Set is to determine and record routes
(local interface network address and next hop interface network
address) to all possible routable addresses advertised by this
protocol, as well as of all destinations that are local, i.e., within
one hop, to the router (whether using routable addresses or not).
Only symmetric links are used in such routes.

Question From above two sections, are the local interface addresses
routable or maybe routable. Are some local interfaces not network
addresses? Are all next hop interface addresses routable.

Regards
AB
---
This message and any attachments are confidential to the intended
recipient and may also be privileged. If you are not the intended
recipient please delete it from your system and notify the sender.
This message is in compliance with the IETF regulations.
---


On 7/29/12, The IESG iesg-secret...@ietf.org wrote:

 The IESG has received a request from the Mobile Ad-hoc Networks WG
 (manet) to consider the following document:
 - 'The Optimized Link State Routing Protocol version 2'
   draft-ietf-manet-olsrv2-15.txt as Proposed Standard

 The IESG plans to make a decision in the next few weeks, and solicits
 final comments on this action. Please send substantive comments to the
 ietf@ietf.org mailing lists by 2012-08-22. Exceptionally, comments may be
 sent to i...@ietf.org instead. In either case, please retain the
 beginning of the Subject line to allow automated sorting. This last call
 period has been extended to handle the fact that it spans the IETF-84
 meeting.

 This last call is being re-initiated to include a notice that this document
 includes a normative down reference to an Informational RFC:
 RFC5148, Jitter considerations in MANETs.

 Abstract

This specification describes version 2 of the Optimized Link State
Routing (OLSRv2) protocol for Mobile Ad hoc NETworks (MANETs).

 The file can be obtained via
 http://datatracker.ietf.org/doc/draft-ietf-manet-olsrv2/

 IESG discussion can be tracked via
 http://datatracker.ietf.org/doc/draft-ietf-manet-olsrv2/ballot/


 No IPR declarations have been submitted directly on this I-D.

Re: Your comments on draft-ietf-manet-olsrv2-15.txt

2012-08-24 Thread Abdussalam Baryun

Hi Adrian,

Yes my comments requested by last call to be submitted to IESG for the
subject (evaluation purpose) have been ended. However, if I get any
request/receive/read any new issue in IETF, I may comment again to IETF
discuss list. For the OLSRv2 in general comments will never end as long as
there are users and as long the internet mission is development/progress,
but to IESG I have ended the comments (one additional to ietf) which I
mentioned the *end* in my last comment to IESG. They were separate to focus
each comment on separate related view.

I don't know how is the practice of IESG process or Last Call process, but
I have tried many times with the authors before, to make the document
better but they think my comments are not important (which maybe they are
right). Therefore, I don't want to give any permission to share with them,
I will leave it to IESG. If IESG agrees to share any/all comments they
received to any/all author(s), I will have no objection.

Thanking you,

Best Regards

Abdussalam Baryun (AB)
University of Glamorgan, UK
++
On Thu, Aug 23, 2012 at 10:40 AM, Adrian Farrel adr...@olddog.co.uk wrote:

 Hi Abdussalam,

 Thank you for your review comments on draft-ietf-manet-olsrv2-15.txt

 I see seven separate points raised in separate emails. Can you confirm
 that this
 is the totality of your comments.

 I also note that the seventh email was sent to only the IESG. May I have
 your
 permission to share this email with the document authors.

 Thanks,
 Adrian

  -Original Message-
  From: iesg-boun...@ietf.org [mailto:iesg-boun...@ietf.org] On Behalf Of
  Abdussalam Baryun
  Sent: 22 August 2012 23:01
  To: i...@ietf.org
  Subject: Re: Last Call: draft-ietf-manet-olsrv2-15.txt (The Optimized
 Link
 State
  Routing Protocol version 2) to Proposed Standard
 
  Reply to your request dated 29/07/2012
  Draft Reviewed By: Abdussalam Baryun (AB)   Dated: 22/08/2012
 
  Reviewer Comment AB7: Comments on text in document history [*].
  https://datatracker.ietf.org/doc/draft-ietf-manet-olsrv2/history/
  
 
  A key difference between RFC3626 and OLSRv2 is the introduction of
  support for link metrics. An individual draft
  (draft-dearlove-olsrv2-metrics-00) was submitted in 2007, discussing
  the design options, culminating in 2010 with
  draft-dearlove-olsrv2-metrics-05 documenting Working Group consensus
  on this matter. Metrics support was, then, folded into OLSRv2.
 
  AB the reviewer thinks the difference is that OLSRv2 is a metric base
  router that uses NHDP and RFC5444 packets which are general MANET
  interface protocol and general MANET packet format respectively.
  OLSRv2 is applicable for more scenarios and routers that are
  constraint devices.
 
  This version of OLSRv2 was given a one month WGLC, so as to ensure
  sufficient time to review the document.
 
  AB my comments within the period was not considered by the authors
  and don't see any consensus from the WG.
 
  There was an issue concerning the differences between the -14 and -15
  revisions of the document, brought up by one WG member. The consensus
  opinion from the WG is that the document should proceed, without
  additional edits.
 
  AB yes there was a new version update after my comments and
  discussion with the authors, but still not happy with the outcome.
 
  Best Regards
  AB
  +
  The end of my comments (the comments were 7 including this, two only
  for the IESG and one addition for only IEFT).
  
 
  On 7/29/12, The IESG iesg-secret...@ietf.org wrote:
  
   The IESG has received a request from the Mobile Ad-hoc Networks WG
   (manet) to consider the following document:
   - 'The Optimized Link State Routing Protocol version 2'
 draft-ietf-manet-olsrv2-15.txt as Proposed Standard
  
   The IESG plans to make a decision in the next few weeks, and solicits
   final comments on this action. Please send substantive comments to the
   ietf@ietf.org mailing lists by 2012-08-22. Exceptionally, comments
 may be
   sent to i...@ietf.org instead. In either case, please retain the
   beginning of the Subject line to allow automated sorting. This last
 call
   period has been extended to handle the fact that it spans the IETF-84
   meeting.
  
   This last call is being re-initiated to include a notice that this
 document
   includes a normative down reference to an Informational RFC:
   RFC5148, Jitter considerations in MANETs.
  
   Abstract
  
  This specification describes version 2 of the Optimized Link State
  Routing (OLSRv2) protocol for Mobile Ad hoc NETworks (MANETs).
  
   The file can be obtained via
   http://datatracker.ietf.org/doc/draft-ietf-manet-olsrv2/
  
   IESG discussion can be tracked via
   http://datatracker.ietf.org/doc/draft-ietf-manet-olsrv2/ballot/
  
  
   No IPR declarations have been submitted directly on this I-D.

Is there: Discussions, Evaluations, Decisions, Acceptance, Progress?

2012-08-24 Thread Abdussalam Baryun

Hi All,

For any IETF WG discussion, we recommend reasons/references and equal
recognistion for progress.
For any IETF WG evaluation/review, we recommend two way discussions for
progress.
For any IETF WG decision, we recommend evaluation and then need rough
consensus for progress.
For any IESG decision, we recommend WG input and internet community input
and their consensus.

IMO, for any IETF-Participant's progress, he/she needs to know *why*
through discussions/questions, and he/she should make *decisions* for
the WG's I-Ds/RFCs with his/her community through rough consensus.
Decisions are accepted by community only if they are discussed or they
have clear reasons.

Please advise if you agree/disagree, thanks,

Best Regards
AB

Re: Minutes SHOULD include participants number

2012-08-29 Thread Abdussalam Baryun

Hi John,

Thanks for your advise and comments. I prefered that consensus is
documented to know its value/level as was it 60% or 70% or 80%...etc.
How do Chairs in IETF decide on the agree/disagree/no-reply from WGs

  Note that 51% of the working group does not qualify as rough consensus and
   99% is better than rough.  It is up to the Chair to determine if rough
  consensus has been reached.

I see that minutes just mention WG agreed to ..., but would suggest
the value, so it does not become below 51%. Also, most participants
need more time to decide on such request from Chairs because they use
their variable-available-volunteering time to do reading/work within
each 28 days.

Regards
AB
---
On 8/28/12, John C Klensin john-i...@jck.com wrote:


 --On Tuesday, August 28, 2012 11:17 +0100 Abdussalam Baryun
 abdussalambar...@gmail.com wrote:

 Hi

 Reading through some IETF WGs minutes of meetings, is it
 possible that we follow a procedure in writting minutes.
 I think the following items are important that SHOULD be
 included:

 1) name of the chair, minute taker, and jabber reader.
 2) number of participant in the meeting room.
 3) number of participants at jabber.

 It seems to me that the latter two would fall somewhere between
 useless and misleading.  I don't have any idea how to count
 participants in the meeting room.  The only numbers that are
 reasonably easy to capture are the number of people who signed
 the blue sheets, but that doesn't capture either non-signers or
 those who sign and then sit in the room and pay more attention
 to email or other topics than the meeting.  If we used the
 number of people signed into Jabber for anything, we'd create a
 count that was extremely easy to pack as well as not
 distinguishing between people who were on Jabber but in the
 room, on Jabber but elsewhere at the IETF meeting (conflicts or
 couldn't be bothered to attend), remote and actively following
 the meeting, or others (and there are likely to be some others).

 I could see somewhat more value if actual names and
 organizational affiliations were listed, but the community has
 (for plausible reasons, IMO) decided to not do that.

 This is just a personal opinion/request, but I would really
 appreciate it if you (or others making procedural
 suggestions/requests like this) would carefully think through
 the implications of what they are asking for and how the
 information would be used before making the request.  It would
 be even better if you then included an explanation of the value
 that you think would occur, and maybe the tradeoffs you see,
 with the request, not just is it possible that we follow a
 procedure

 That would have an advantage for you too because such
 suggestions are more likely to be taken seriously by more people
 in the IETF rather than, in the extreme case, going unread
 because you have developed a history of bad and/or unjustified
 ideas.

 regards,
john

Re: Last Call: draft-ietf-grow-ops-reqs-for-bgp-error-handling-05.txt (Operational Requirements for Enhanced Error Handling Behaviour in BGP-4) to Informational RFC

2012-08-31 Thread Abdussalam Baryun

Reply to your request dated 30/08/2012
Draft Reviewed By: Abdussalam Baryun (AB)   Dated: 31/08/2012

Reviewer Comment AB1: Editorial.


Overall the reviewer felt that this Informational I-D is difficult to
read/understand. Requirement level language [RFC2119] is not used,
while this I-D discusses; *requirements* of BGP error handling.

Page 3 Whilst a number of Internet Drafts
have been written to begin to enhance the behaviour of BGP-4 in terms
of the handling of erroneous messages,
AB please refer to those I-Ds within the paragraph
AB what is PE device?

Page 4 within a single sub-topology or service.
AB what is sub-topology? Do you mean subnet or domain!

Page 4-5 Both within Internet and multi-service routing architectures, a
number of BGP sessions propagate a large proportion of the required
routing information for network operation. For Internet routing,
these are typically BGP sessions which propagate the global routing
table to an AS - failure of these sessions may have a large impact on
network service, based on a single erroneous update. In an multiservice
environment, typical deployments utilise a small number of
core-facing BGP sessions, typically towards route reflector devices.
Failure of these sessions may also result in a large impact to
network operation.

AB BGP sessions don’t propagate within architectures, but within networks.
AB “typically BGP sessions which propagate the global routing
Table to …” not clear.
AB amend “In an multiservice” to “In a multi-service”
---

This is not the end of the comments

Best Regards,
AB
---
This message and any attachments are confidential to the intended
recipient and may also be privileged. If you are not the intended
recipient please delete it from your system and notify the sender.
This message is in compliance with the IETF regulations.
---

On 8/30/12, The IESG iesg-secret...@ietf.org wrote:

 The IESG has received a request from the Global Routing Operations WG
 (grow) to consider the following document:
 - 'Operational Requirements for Enhanced Error Handling Behaviour in
BGP-4'
   draft-ietf-grow-ops-reqs-for-bgp-error-handling-05.txt as
 Informational RFC

 The IESG plans to make a decision in the next few weeks, and solicits
 final comments on this action. Please send substantive comments to the
 ietf@ietf.org mailing lists by 2012-09-13. Exceptionally, comments may be
 sent to i...@ietf.org instead. In either case, please retain the
 beginning of the Subject line to allow automated sorting.

 Abstract


BGP-4 is utilised as a key intra- and inter-Autonomous System routing
protocol in modern IP networks.  The failure modes as defined by the
original protocol standards are based on a number of assumptions
around the impact of session failure.  Numerous incidents both in the
global Internet routing table and within Service Provider networks
have been caused by strict handling of a single invalid UPDATE
message causing large-scale failures in one or more Autonomous
Systems.

This memo describes the current use of BGP-4 within Service Provider
networks, and outlines a set of requirements for further work to
enhance the mechanisms available to a BGP-4 implementation when
erroneous data is detected.  Whilst this document does not provide
specification of any standard, it is intended as an overview of a set
of enhancements to BGP-4 to improve the protocol's robustness to suit
its current deployment.




 The file can be obtained via
 http://datatracker.ietf.org/doc/draft-ietf-grow-ops-reqs-for-bgp-error-handling/

 IESG discussion can be tracked via
 http://datatracker.ietf.org/doc/draft-ietf-grow-ops-reqs-for-bgp-error-handling/ballot/


 No IPR declarations have been submitted directly on this I-D.

Re: NomCom 2012-2013: Call for Nomination and Feedback

2012-09-07 Thread Abdussalam Baryun

On 9/6/12, NomCom Chair nomcom-ch...@ietf.org wrote:

 However, we also need the community's views and input on the jobs
 within each organization. If you have ideas on job responsibilities
 (more, less, different), please let us know.  Please send suggestions
 and feedback to nomco...@ietf.org.
Suggestion to assist; 1) the DA responsibility of The DA is to select
the WG chair
and 2) to assist the method of NomCom collection of feedback
information from community.
---
My suggestion is to add a report/questionnare for comments on WGs
performance, as just to collect comment/feedback on WG progress from
only the community. Usually community feedback on WGs' progresses are
very important for the IETF, which a lack of progress maybe due to
chair or DA position, which I think is the most important issue in all
nominations vote decision. The feedback can be named the
community-WG-progress-report or ietf-participants-feedback-report,
which has many advantages.

In abstract the advantages are; firstly, the
community-WG-progress-report will be attached to an optional DA-report
that will be given to the new DA. The new DA will be able to decide
how to select/advise/follow-up-with the WGs chairs for the next year.
Secondly, the community-wg-progress-report will help NomCom12 to vote
on the nominated positions, if previous chairs or DAs are going for a
position as IESG or other.

I am not sure if we already have this community feedback about WG
progress. IMO, no IETF member can vote efficiently without information
or feedback from internet-community.

Best Regards
AB


 Thank you for your help in identifying qualified nominees, and in providing

 feedback about individuals we are considering for IETF leadership
 positions.

 Matt Lepinski
 nomcom-ch...@ietf.org

Re: Draft IESG Statement on Removal of an Internet-Draft from the IETF Web Site

Hi Russ,

I think that statement you made is very reasonable which I would prefer
groups work to the best of IETF purposes, but also we need to know the
reason why some individuals fail to convince an IETF WG. It is important
that individuals get to make input to new standards not only companies. I
am afraid that only companies are controlling the Internet standards which
seems bad and does not follow the IETF mission. Therefore, there SHOULD be
a procedure to make participants follow to convince WG and a procedure that
WGs follow to accept with reason, not just blocking excellent I-D because
they group think it is bad with no reason or knowledgable discussion. If
there is no procedure then individuals or other organisations will look for
another way to standards their work.

AB
---

 but is this Why not? I thought any I-D can be standard track,


Todd:

The Independent Submission Stream cannot be used to produce standards
track RFCs.

Russ

Re: Draft IESG Statement on Removal of an Internet-Draft from the IETF Web Site

Hi Dave,

Independent Stream authors well might not be part of the IETF -- always
a strange line of thinking, given that the IETF doesn't have members -- but
that doesn't mean that the Stream itself is outside the IETF.
Any I-D author MUST be part of IETF otherwise what is IETF then, how do we
define it? I think we should not make simple facts complicated. The most
important part of IETF is the participant that does volunteer his work
effort and time for the IETF. However I assume you agree with me because
you mentioned might.

AB

Re: Failing to convince an IETF WG (was: Draft IESG Statement on Removal of an Internet-Draft from the IETF Web Site)

Hi SM,

I ment to say that if independent stream cannot submit a standard track
document, then do we have a procedure for the WG to accept or not consider?
The last call that you refered to was a WG not independent.

On Tue, Sep 25, 2012 at 6:08 PM, SM s...@resistor.net wrote:

Hi Abdussalam,
At 08:50 25-09-2012, Abdussalam Baryun wrote:

I think that statement you made is very reasonable which I would prefer
groups work to the best of IETF purposes, but also we need to know the
reason why some individuals fail to convince an IETF WG. It is important
that individuals get to make input to

Failing to convince a WG can happen for any of the following reasons:

(i) The arguments are unconvincing.

(ii) The arguments are unrelated to the topic being discussed.

(iii) The arguments look good on paper. Unfortunately, they won't
work in the real world.

(iv) The other individuals do not like the individual. :-)

The above reasons may not even be valid.

Internet standards which seems bad and does not follow the IETF mission.
Therefore, there
SHOULD be a procedure to make participants follow to convince WG and a
procedure that
WGs follow to accept with reason, not just blocking excellent I-D
because they group think it is bad with no reason or knowledgable
discussion. If there is no procedure then

If the group thinks that an I-D is bad, you can either accept that
conclusion or you can try to convince the group that it is wrong. If you
cannot convince the WG, there is always the Last Call where you get a
second opportunity to raise your issues. There are procedures if a third
opportunity is necessary.

Around a month ago, Adrian Farrel asked the following question [1]:

May I have your permission to share this email with the
document authors.

The answer [2] was:

Therefore, I don't want to give any permission to share with them, I
will
leave it to IESG. If IESG agrees to share any/all comments they received
to any/all author(s), I will have no objection.

That's basically a no. The above puts the IESG in an unenviable position
to decide whether to share the email.

Regards,
-sm

1.
http://www.ietf.org/mail-**archive/web/ietf/current/**msg74749.htmlhttp://www.ietf.org/mail-archive/web/ietf/current/msg74749.html
2.
http://www.ietf.org/mail-**archive/web/ietf/current/**msg74749.htmlhttp://www.ietf.org/mail-archive/web/ietf/current/msg74749.html

Re: Failing to convince an IETF WG (was: Draft IESG Statement on Removal of an Internet-Draft from the IETF Web Site)

SMThere is no such thing as an Independent Stream submitting a Standards
Track document. An author can submit an I-D through the IETF Stream if the
author would like the I-D to be published on the Standards Track. A WG can
adopt such an I-D.

RussThe Independent Submission Stream cannot be used to produce standards
track RFCs.

So if I follow the second input above, then independent submission cannot
be used to produce standard, then it should go through WG. The question was
if there was disagreement from WG to accept, is there a procedure for the
submitter to follow, or he must follow the WG and forget about his work
(many inventions in the world were not convined by groups/experts, but were
invented only when inventor didn't follow them but followed reasoning).
Sorry if not clear,

AB
On Tue, Sep 25, 2012 at 7:15 PM, SM s...@resistor.net wrote:

Hi Abdussalam,

At 10:19 25-09-2012, Abdussalam Baryun wrote:

There is no such thing as an Independent Stream submitting a Standards
Track document. An author can submit an I-D through the IETF Stream if the
author would like the I-D to be published on the Standards Track. A WG can
adopt such an I-D.

Regards,
-sm

P.S. I read your message [1] again. The first part seems to be about the
reason why some individuals fail to convince an IETF WG. The last part
seem to be about a procedure to make participants follow to convince WG
and a procedure that WGs follow to accept with reason. There was then an
AB and three hyphens on the next line. It is followed by but is this
Why not? I thought any I-D can be standard track,. It was difficult for
me to understand [2] the message.

1.
http://www.ietf.org/mail-**archive/web/ietf/current/**msg75097.htmlhttp://www.ietf.org/mail-archive/web/ietf/current/msg75097.html
2.
http://www.ietf.org/mail-**archive/web/ietf/current/**msg60902.htmlhttp://www.ietf.org/mail-archive/web/ietf/current/msg60902.html

Re: Failing to convince an IETF WG

Hi Dave, and All,

The beauty of the IETF is that it includes all Internet USERS
(i.e.people or organisations) around the world, no one should use it
in their interest, it should progress in the Internet
Society/Community interest following the *open* engineering knowledge
and practice. Engineers in IETF cannot disagree covering their reason
or reference they SHOULD be open. Comments in line below:
-
 The IETF needs total transparency and a way to process alternative
 standards
 so that it is not actively involved in anything dark and covert.

 That makes no sense ... something can't be an IETF standard if it doesn't
 get created and adopted using The IETF's processes. The word 'standard'
 implies the approval of some organization/standards body. The independant
 stream does allow publishing of alternatives to IETF Standards, but that
 doesn't make tham alternative standards. For that some other recognized
 group needs to declare it a standard and then it will be An XYZ Group
 Standard, not an IETF Standard.
---
I agree that the best practice is standards through WGs, because
*knowledge* is the core reason for the GROUP, not *politics*. IMHO,
the best practice is continue *open-discussions* with engineering and
technical knowledge to give progress to WGs, but if some participants
don't want to accept to discuss (by ignoring input) or don't want to
listen to technical/research reasons in IETF documents or  in
publications out IETF, how can the WG progress? Still thoes
participant MAY continue disagree (without discussing why) when
calling for group consensus, what will be the best practice?, will it
be that the submitter has to stop even if his/her has better arguments
in terms of engineering.

Some may fail to convice an IETF WG just because some active
participants reply that they think it is bad, without replying
*reasonably* to discussions. When I read the IETF procedure, I see
that it makes decisions at the *WG-consensus* (with no relation to
discussions and arguments) which I think not enough for progress in
the eyes of IETF mission statement.

Suggest: that if any participant disagree in I-D adoption in a WG,
then he/she take a DISCUSS position (similar to IESG memebrs process,
cannot just disagree), which they MUST have to take and reply to
messages including their good reasons for their positions (you don't
reply this idea/I-D is BAD). Any participant (submitter or who
disagrees with adoption) SHOULD have an engineering reference(s) for
such input.

If I am mistaken please advise, because I need to discuss to
understand, so we can help together make IETF better for the world
users.

Best Regards
Abdussalam Baryun

The mission of the Internet Engineering Task Force is to make the
Internet work better by producing high-quality and relevant technical
documents that influence the way people design, use, and manage the
Internet. See http://www.ietf.org.

Re: Failing to convince an IETF WG

Hi Todd,

I agree on your concerns but disagree with few issues, read my
disagree reason below:

Todd Most of the vetting happens between parties offlist and no capture .
AB any organisation may have this behavior, but what matters is as
long as you are participating to : monitoring input, questioning,
suggesting, convincing others, writing I-Ds for the IETF, and making
up your decisions.

ToddThe IETF process of today is based on a 'consensus' process from
a membership of zero. That in and of itself flies in the face of
reason and ethical clarity. If there were formal members who came
together in a framework that the IETF administered it would be OK but
the process today is too easily abused.

AB it is greate that we are not memebrs, we are participants, because
we become equal to any other, if memebrship then we will have a memebr
for 10 years and a memeber for 5 years (not measuring efforts but
time), but with the IETF we are just participants, the value or
difference between us is only how much you participate and author I-Ds
or IETF RFCs. There MAY be abuse to the consensus process only if the
CHAIR does not consider the healthy discussion related. So we need
something to avoid this.

Todd When the journey is completed the standard will automatically
issue... no IESG no IAB pain no extra administrative overhead for a
bunch of lifer type standards junkies... Just simple and clean access
to the standard process.

AB standard process is greate as we have IESG and WG reviews, first
because the authors will have to discuss through many things with the
focused/expert IETF group, then secondly the IESG have a more general
review which includes many other affects of the I-D with other WGs in
IETF. Yes painful but healthy.

Best Regards
Abdussalam Baryun

The mission of the Internet Engineering Task Force is to make the
Internet work better by producing high-quality and relevant technical
documents that influence the way people design, use, and manage the
Internet. See http://www.ietf.org.

Re: Is there: Discussions, Evaluations, Decisions, Acceptance, Progress?

I Suggest the following:

1) IF any participant disagree in I-D adoption in a WG or any other
decision, THEN, he/she takes a DISCUSS position.

2) Any participant with DISCUSS position related to a subject (he/she
refused)MUST have to take and reply to messages including their good
reasons for their positions, otherwise his/her disagreement has no
engineering value.

3) Any participant (submitter or who disagrees with adoption) SHOULD
have an engineering reference(s) for such input otherwise the Chair
MAY not accept his input in the meeting.

Best Regards
Abdussalam Baryun

The mission of the Internet Engineering Task Force is to make the
Internet work better by producing high-quality and relevant technical
documents that influence the way people design, use, and manage the
Internet. See http://www.ietf.org.


On 8/24/12, Abdussalam Baryun abdussalambar...@gmail.com wrote:
 Hi All,

 For any IETF WG discussion, we recommend reasons/references and equal
 recognistion for progress.
 For any IETF WG evaluation/review, we recommend two way discussions for
 progress.
 For any IETF WG decision, we recommend evaluation and then need rough
 consensus for progress.
 For any IESG decision, we recommend WG input and internet community input
 and their consensus.

 IMO, for any IETF-Participant's progress, he/she needs to know *why*
 through discussions/questions, and he/she should make *decisions* for
 the WG's I-Ds/RFCs with his/her community through rough consensus.
 Decisions are accepted by community only if they are discussed or they
 have clear reasons.

 Please advise if you agree/disagree, thanks,

 Best Regards
 AB

Re: Last Call: draft-leiba-extended-doc-shepherd-00.txt (Document Shepherding Throughout a Document's Lifecycle) to Informational RFC

Dated: 26/09/2012  By: Abdussalam
Baryun (AB)
This is a reply to below request call.

Reviewer Related Comment: The General Area Individual input


Overall the reviewer disagrees to accept the document only after
modifications mentioned below and with referencing discussions/surveys
if available. I will name the I-D as a reflection report, which is
helpful for organisations' progress. Comments below:

1) the Abstract and Title of the document should represent the real
purpose of the document, it is not understood from them that the
document is an opinion, or point of view, or two points of view, or is
this document argumental. Informational track document related to such
subject SHOULD include references to history and practices as the
author witnesses while his experience, as a reflection report.

2) How can an individual submitter make input to produce RFC relating
to the administrative work of IETF, this will be without community
agreement or consultant.

3) IF there was no consultant from community of the Internet by the
author, and the I-D concerns their process, THEN the I-D SHOULD
mention that clearly. IF there was a questionnair or survey done by
the author, THEN he/she should include in the I-D. IF no such survey
done, nor questionnair distributed to get feedback, THEN it SHUOLD be
stated that there was no survey, in addition to the above.

4) IF the document represents the authors views THEN the Absract of
the I-D SHOULD state clearly, that : this document is only the
opinion of the author(s) and not the Community. IF not mentioned THEN
the author must show prove of such claims/understandings.

Best regards
AB

End of Reply
++

On 9/25/12, The IESG iesg-secret...@ietf.org wrote:

 The IESG has received a request from an individual submitter to consider
 the following document:
 - 'Document Shepherding Throughout a Document's Lifecycle'
   draft-leiba-extended-doc-shepherd-00.txt as Informational RFC

 The author is documenting his own opinion, and he is presenting that
 opinion to the community for consideration.  The author is not
 proposing any formal change, but he is interested in community
 comments.  Since this is the authors opinions, changes to the document
 based on received comments be at the author's discretion.  As a
 result, the finished document will not claim to reflect IETF community
 consensus.

 The IESG plans to make a decision in the next few weeks, and solicits
 final comments on this action. Please send substantive comments to the
 ietf@ietf.org mailing lists by 2012-10-23. Exceptionally, comments may be
 sent to i...@ietf.org instead. In either case, please retain the
 beginning of the Subject line to allow automated sorting.

 Abstract

RFC 4858 talks about Document Shepherding from Working Group Last
Call to Publication.  There's a significant part of a document's
life that happens before working group last call, starting, really,
at the time a working group begins discussing a version of the idea
that's been posted as an individual draft.  It seems reasonable and
helpful to begin shepherding when there's a call for adoption as a
working group document, and this document gives one Area Director's
view of how that extended shepherding function might work, and what
tasks might be involved throughout the document's lifecycle.


 The file can be obtained via
 http://datatracker.ietf.org/doc/draft-leiba-extended-doc-shepherd/

 IESG discussion can be tracked via
 http://datatracker.ietf.org/doc/draft-leiba-extended-doc-shepherd/ballot/

 No IPR declarations have been submitted directly on this I-D.

Re: Antitrust FAQ

2012-10-12 Thread Abdussalam Baryun

I support the reminder, however, would like to add considerations,
suggestions and my questions.
-

I see that it only includes information related to antitrust

The *reminder-document* should be for both Companies (i.e.
managers/owners/share-holders) and IETF-participants, so we including
companies as well, there should not be any antitrust agreement against
a participant individual as well (i.e. All IETF input and output
decisions are from individual participants not companies).

ABAmend Antitrust law prohibits agreements that unreasonably
restrain trust, and business.

The word *trade* is more for companies, but *business* will include
participant individuals. The main issue is *trust* so should be in the
document.

ABsuggest Q2:  *Competitive information includes:* I recommend to
put some exclude examples to clarify the answer. The last line in the
answer is not enough.

AB My Questions: (as I still don't understand clearly from the document):
Qa) Is an information of technology advantages over another
competitive one prohibited?

Qb) Is an information of a standard advantages over another standard prohibited?
(e.g. many companies may hide technology analysis results from the market)

Qc) Do we as IETFers separate the product technology from the business
provider or we mix them? or does the customer/market-channels mix
between the two? I think we (i.e. participating in volunteering
standardising for the Internet Community) do that perfectly, maybe
companies (i.e. market profit makers, owner of percentage of market
share) don't understand that, and they MAY need reminder too.

Finally IMHO, The Qa and Qb questions are not understood from the
Antitrust FAQ doc. Participants on discussion lists always like to
argue/find-out technical advantages and disadvantages, and make clear
*HOW / WHEN* to use/not-use such technology/standard. I suggest to
include some information explaining Qc.

AB


 The IETF does not have a formal antitrust policy.  In fact, the
 ANTITRUST BOF concluded that a formal policy was not needed.  However,
 educational material is needed so that all IETF participants are aware
 of the the law.  The first draft of a FAQ to fill this need has been
 developed.  Please review the FAQ, and if you discover any issues
 raise them in response to this message.

 http://www.ietf.org/playground/antitrust-faq.html

 Thanks,
   Russ

Re: Newcomers [Was: Evolutionizing the IETF]

2012-11-11 Thread Abdussalam Baryun

 I don't think that thoes Canada and US participants are paying for
the attendance, but their organisations, therefore, are we reducing
the cost of other organisations, or we are interested to bring more
participants. IMHO, IF the reason of making the events in America
because participation is mostly declining when events in Europe or
other, THEN the action of IETF to make more events in America will be
reasonable. We need facts not just expectations.

 The important question is how many users of the Internet now are
spreed in the world, and should the IETF consider making attending
easier to users than to old participants? Is n't three meeting events
in America  per two years enough as you mentioned 51% participants are
from America, as IETF meet 4 times a year?

Now 66% of meetings is done in America, which I think it should be
less or equal to 50%.

AB

On 11/9/12, Yoav Nir y...@checkpoint.com wrote:

 On Nov 9, 2012, at 9:31 AM, Abdussalam Baryun wrote:

 There is a direct contribution of US $2.2 million by the Internet
 Society next year.  Is the plan to rely on Internet Society subsidies
 or to fix the deficit?  One argument made was that the fees have not
 been increased over the last years.  I'll point out that there hasn't
 been significant increase in paid attendance over the years.  Either
 the IETF is only relevant to the usual folks or else the meetings are
 not made relevant enough for (new) people to attend.

 I am newcomer and not able to attend because most of meeting in
 America instead of Europe.

 Adding US and Canada attendees (I counted last week, might have changed
 slightly) you get to about 51% of the attendees.
 When meetings are held in other parts of the world (like Taipei, Paris or
 Prague) Americans still make up over 40% of the attendees.
 Much as I prefer 4-hour flights to 12-hour flights, it minimizes the general
 pain to hold meetings in America.
 There's also the issue that finding good venues is considerably easier in
 America than in either Europe or Asia

 I am repeatedly struck by how many new people *do* attend.


 I don't know how long do they remain, for me I am feeling disapointed.

 Some come back, and some don't. Could you expand on what you're disappointed
 about?

 According to Russ's slides [1] 195/1098 are newcomers. And just to
 labour
 the
 point, a newcomer is not a returnee after 10 years, but someone who has
 never
 attended before.

 hope treated equal with all participants,

 The new attendee, same as the old attendee gets to have everyone shut up
 when they go to the mike. If you have a draft and a relevant presentation,
 you can usually get time at a WG meeting regardless of how many meetings
 you've attended. Knowing that you should do these things is the learning
 curve that every one of us must go through.

 This number (around 10%) seems consistent over all meetings. So naively,
 we
 should be growing our attendance by around 300 per year.


 agree

 But as both you and Adrian Farrel said, a lot of these don't come back.
 Maybe a more relevant statistic for the churn would be to count the
 third-time attendees.

 Millions of people go sailing for the first time each year. A huge
 proportion of those get sea sick or bored, and never do it again. That's not
 a useful metric to assess the size of the sailing community.

 That we are not reflects our inability to retain, not our inability to
 attract
 (assuming that we are not completely refreshing the IETF attendance
 every
 three
 or four years). Should not be rocket science to follow up with some
 newcomers to
 find out why they only attend once and never come back.


 For me I still did n't attend but understand that many old
 participants are biased and there seems no equal opportunity, people
 don't always follow the IETF mission and procedure, they just follow
 their ways as long there was no complain.

 I call all newcomers to open a new WG and start complaining because we
 have to discuss why we were disapointed of the IETF and IESG, and even
 the Internet Society.

 Please note that I will focus my volunteering work in complaining and
 fixing the discourage I found so far.

 OK, but if something or someone discouraged you, speak up. Existing members
 can't help you if you don't tell us what's wrong.

 Yoav

Re: Newcomers [Was: Evolutionizing the IETF]

2012-11-11 Thread Abdussalam Baryun

Amending one line

On 11/11/12, Abdussalam Baryun abdussalambar...@gmail.com wrote:
  The important question is how many users of the Internet now are
 spreed in the world, and should the IETF consider making attending
 easier to users than to old participants? Is n't three meeting events
 in America  per two years enough as you mentioned 51% participants are
 from America, as IETF meet 4 times a year?

as IETF meet 6 times per two years?


 Now 66% of meetings is done in America, which I think it should be
 less or equal to 50%.

 AB

 On 11/9/12, Yoav Nir y...@checkpoint.com wrote:

 On Nov 9, 2012, at 9:31 AM, Abdussalam Baryun wrote:

 There is a direct contribution of US $2.2 million by the Internet
 Society next year.  Is the plan to rely on Internet Society subsidies
 or to fix the deficit?  One argument made was that the fees have not
 been increased over the last years.  I'll point out that there hasn't
 been significant increase in paid attendance over the years.  Either
 the IETF is only relevant to the usual folks or else the meetings are
 not made relevant enough for (new) people to attend.

 I am newcomer and not able to attend because most of meeting in
 America instead of Europe.

 Adding US and Canada attendees (I counted last week, might have changed
 slightly) you get to about 51% of the attendees.
 When meetings are held in other parts of the world (like Taipei, Paris or
 Prague) Americans still make up over 40% of the attendees.
 Much as I prefer 4-hour flights to 12-hour flights, it minimizes the
 general
 pain to hold meetings in America.
 There's also the issue that finding good venues is considerably easier in
 America than in either Europe or Asia

 I am repeatedly struck by how many new people *do* attend.


 I don't know how long do they remain, for me I am feeling disapointed.

 Some come back, and some don't. Could you expand on what you're
 disappointed
 about?

 According to Russ's slides [1] 195/1098 are newcomers. And just to
 labour
 the
 point, a newcomer is not a returnee after 10 years, but someone who has
 never
 attended before.

 hope treated equal with all participants,

 The new attendee, same as the old attendee gets to have everyone shut up
 when they go to the mike. If you have a draft and a relevant
 presentation,
 you can usually get time at a WG meeting regardless of how many meetings
 you've attended. Knowing that you should do these things is the learning
 curve that every one of us must go through.

 This number (around 10%) seems consistent over all meetings. So
 naively,
 we
 should be growing our attendance by around 300 per year.


 agree

 But as both you and Adrian Farrel said, a lot of these don't come back.
 Maybe a more relevant statistic for the churn would be to count the
 third-time attendees.

 Millions of people go sailing for the first time each year. A huge
 proportion of those get sea sick or bored, and never do it again. That's
 not
 a useful metric to assess the size of the sailing community.

 That we are not reflects our inability to retain, not our inability to
 attract
 (assuming that we are not completely refreshing the IETF attendance
 every
 three
 or four years). Should not be rocket science to follow up with some
 newcomers to
 find out why they only attend once and never come back.


 For me I still did n't attend but understand that many old
 participants are biased and there seems no equal opportunity, people
 don't always follow the IETF mission and procedure, they just follow
 their ways as long there was no complain.

 I call all newcomers to open a new WG and start complaining because we
 have to discuss why we were disapointed of the IETF and IESG, and even
 the Internet Society.

 Please note that I will focus my volunteering work in complaining and
 fixing the discourage I found so far.

 OK, but if something or someone discouraged you, speak up. Existing
 members
 can't help you if you don't tell us what's wrong.

 Yoav

Re: IETF work is done on the mailing lists

2012-11-28 Thread Abdussalam Baryun

Hi Barry,

I thank you to open this discussion. I tried to open this discussion before
on the list but was ignored, however, seeing your input made me think that
there is importance to the subject. IMO I prefer the discussion list,
because we all integrate and we all are present in its domain. In F2F
meeting their is a certain time to meet and limited discussions and limited
input. Please note that most of the input of IETF is done on the list not
within F2F meetings. However, still we need F2F meetings to
insure/encourage the directions of work/discussions.

WG F2F meetings Main Purpose: Guidance, Directions, Sense Decisions,
Interact with other WGs, Exchanging ideas and questions, Marketing,
interaction with other organisations, etc.

WG Discussion List Participations Purpose: announcements, feedbacks, The
documented Work flow Processings, Making WG decisions, checking concensus,
questions and answers, editing work/drafts, arguments, etc.

I thought this is already in the IETF procedure that we are following, so
maybe the question is are we following best practices or we just are
following some people. I think so far that participants are sometimes
following and sometimes not, which is disapointment (some one asked me once
on the list why I was disapointed this is one reason).

Regards
AB

Re: When to adopt a draft as a WG doc (was RE: IETF work is done on the mailing lists)

2012-11-28 Thread Abdussalam Baryun

 It seems to me that these variants are dependent on the people in the WG,
 the workload of the group, the chairs, past precedent, AD preferences,
etc.
 It makes it difficult on both draft editors and those seeking to follow
the
 discussion for there to be such a disparity from WG to WG on when to adopt
 drafts. I'm not convinced that there is a one-size-fits-all solution
here, but it
 might be nice to coalesce a little from where we are today.

 So I wonder if perhaps we need clearer guidance on what the process is
 actually supposed to look like and why.
I think the IETF procedures are clear that the WG should authorise all
works, not the chairs nor the ADs. However, chairs guide the discussions on
the list (which in few times does not happen because we are volunteering),
and ADs guide the chairs and direct the WG output. The WG input is only
authorised by the participants through rough consensus.


So, yes, the chairs get to decide how they want to seed the document
development process, and they have a pretty free hand in making that
decision.  Your ADs are always there for further guidance if you need
or want it.
AB I disagree that chairs have such authority on process without checking
the WG if there was an objection or not. The ADs are there for the chairs
guidance too not only participants. The chairs role is important to
encourage/manage participants input time/effort in faivor of the WG
charters. However, I agree that chairs MAY take decision on behalf of WG
because they want to save time and they know the WG initial opinion by
experience (still they need to check if there is any objection).

But there's no formal process for that, and I think
that's how we want it to be.

I don't want no formal in a formal organisation, usually unformal process
only happen in unformal organisations, so is IETF a formal or non-formal. I
beleive we are in a formal so our managers (chairs and ADs) SHOULD follow
formal procedures and participants MAY do both.

I read the procedures and this is what I came out with if I am wrong please
refer me to where does the procedure mention that WG Chairs have such
authority.

AB

When do we ask community for opinion and When we produce an RFC for the community?

2012-11-28 Thread Abdussalam Baryun

http://www.ietf.org/mail-archive/web/ietf/current/msg76001.html
 Does the community want us to push back on those situations?

I think we follow the IETF RFCs or our community amend/change the procedure
related RFCs to be practical. We may need historical RFCs to understand why
such change (the change in opinion/practices as community opinion is
changing).

 Does the community believe that the real IETF work is done on
 the mailing lists, and not in the face-to-face meetings, to
 the extent that the community would want the IESG to refuse to
 publish documents whose process went as I've described above,
 on the basis that IETF process was not properly followed?

I think the community cannot answer that question.
Overall, could we depend on asking the IETF community about something that
is against the IETF procedure and then we claim that we are following the
community. I thought we are following our approved documents or RFCs its
the communities opinion as well. If it is very easy to ask question to the
community to make a procedure then why we need RFCs? I thought that
sometimes IETF managers ask the community questions to sense the rough
consensus for purposes of guidance, not for the purpose of processing the
IETF's work flow.

I once written an RFC to update 2119 but some participants don't want that,
but still I don't beleive that I need to ask them nor the community. I will
go through procedure because I feel I have right to do so. However, once I
asked community for feedback on a draft I will write, but participants
argued why do I ask while still did not write. I do ask only to sense the
community, but still have the right to decide my volunteering work/input.

My question is when do we ask community (from participant level, or
from managerial level) and when we produce an RFC (which purpose)?


Thanking you,
AB

Re: Creating an IETF Working Group Draft

Hi Dave,

Thanks for your work, please provide us with feedback while the process of
editing. I was thinking to do something in the future, but thanks that you
will do it.

AB

Folks, There is now an Internet Draft, based on Adrian's's slides, intended
to document common practice in the adoption of working group drafts:

Title:   Creating an IETF Working Group Draft
Status:  http://datatracker.ietf.org/doc/draft-crocker-id-adoption

Abstract:
   The productive output of IETF working groups is documents, as
   mandated by the working group's charter.  Working groups develop
   these documents based on initial input of varying levels of maturity.
   An initial working group draft might be a document already in wide
   use, or it might be a blank sheet, wholly created by the workiing
   group, or it might represent any level of maturity in between.  This
   document discusses the process of creating formal working group
   drafts that are targeted for publication.

Although it is not intended for a standards-track or bcp publication, it would
be helpful to have discussion that moves the document to represent good
agreement among the community.

d/

--
 Dave Crocker
 Brandenburg InternetWorking
 bbiw.net

Re: Presentation vs. Discussion sessions (was: PowerPoint considered harmful)

Hi Keith,

I hope that participant that travel to the f2f meeting and attend sessions,
do participate while they are there on the discussion lists of IETF WGs,
yes they attend and discuss which is reflected in the minutes report
document, but still there are some time they spend away from their work
which can be used for progress of our work. We are recommended to discuss
on the lists for the IETF work progress. Why don't the f2f participants
review all their interested WG drafts while they are in the 3 days for the
IETF and give their feedback on the list (within these important days).

If all participants attend remotely and physically in 2 hours per WG, why
not discuss on the list for 3 days or 12 hours interaction (if each
participant spends 4 hours on the list per day per WG).

 Still we need more encouragment to attract participants to review and
comment on the list or by an informational I-D.

AB


On 12/02/2012 01:06 PM, Melinda Shore wrote:

There's a whole nexus of connected issues here, I think, and what
a given person complains about depends on that person's pet peeves.
It seems to me that if we were better about moving work forward
between meetings (- peeve!) meeting time wouldn't be chewed up
with presenting the current state of the work.

While I fully agree that most WGs could be better at moving work
forward between
meetings, I don't think it would solve the problem of face to face meeting
time being filled up with presentations.

I suspect that most WG participants have difficulty keeping up with the traffic
on their WGs' mailing lists for various reasons (too much distraction
from normal work, the sad state of mail user agents, etc.). By forcing
people to travel away from work, face-to-face meetings serve as useful
interruptions from normal distractions and opportunities to catch up on
IETF work. If working groups moved forward even faster than they do now,
that might actually be seen to increase the need for presentations at
face-to-face meetings.

Occasionally I've wondered if IETF meetings should have presentation sessions
separate from (and in advance of) working sessions. The difference
between the two types of session would be clearly indicated in the
schedule. The presentation sessions would be geared toward presenting an
overview of current state of the proposals, including a summary of recent
changes. Perhaps participants would be allowed to ask questions for
clarification, but discussion should be discouraged and any kind of polling
of the room or other decision making would be forbidden. The presentation
meetings would therefore be optional for those who had kept up on the
mailing list. And presentations would be forbidden in discussion sessions.

I can imagine these being useful in several ways, e.g. in facilitating better
cross-group and cross-area review. People who were active participants in
working groups could attend presentation sessions of other groups, without
sacrificing their attendance in the discussion sessions of the groups in
which they were active.

Perhaps roughly the first 2(?) days of an IETF meeting could be largely devoted
to presentation sessions, and the remainder of the time to discussion
sessions. Having a strict allocation of time for each kind of session isn't
so important as having the presentation sessions for a particular group
well in advance of the discussion session for that group.

This is something that could be tried on a small scale, by a few working groups
(say one in each area) before being widely adopted. It might help, however,
to have explicit support for the idea in the tools that maintain and
display the meeting schedules.

Keith

Re: When to adopt a draft as a WG doc (was RE: IETF work is done on the mailing lists)

On Wed, Nov 28, 2012 at 6:53 PM, Abdussalam Baryun 
abdussalambar...@gmail.com wrote:


 But there's no formal process for that, and I think
 that's how we want it to be.

 I don't want no formal in a formal organisation, usually unformal process
 only happen in unformal organisations, so is IETF a formal or non-formal. I
 beleive we are in a formal so our managers (chairs and ADs) SHOULD follow
 formal procedures and participants MAY do both.

 I read the procedures and this is what I came out with if I am wrong
 please refer me to where does the procedure mention that WG Chairs have
 such authority.




Now we got an I-D to explain the creation of WG drafts and the formal
Chairs duties in this matter, please read below

http://tools.ietf.org/html/draft-crocker-id-adoption-00


AB

Re: When do we ask community for opinion and When we produce an RFC for the community?

On Wed, Nov 28, 2012 at 7:35 PM, Abdussalam Baryun 
abdussalambar...@gmail.com wrote:

 My question is when do we ask community (from participant level, or
 from managerial level) and when we produce an RFC (which purpose)?



I think the answer to this question should be through a
procedure/informational I-D to make things clear to all participants.

AB

Re: Creating an IETF Working Group Draft

2012-12-05 Thread Abdussalam Baryun

Hi Adrian,

 Dave and I will include what is reasonable and seek a consensus that agrees
 with our motivation for writing the document.

I agree totally that only reasonable inputs to Internet Society SHOULD
go through, that is why I am participating, but I when I see no
reasonable input discussed, so I try to fix in IETF and ask to
clarify. Your info-draft is an important information document/input to
clarify the reasons of such managerial decisions in IETF. Always
consensus follow reasonable decisions, because if any participant
(including chairs and ADs) refuse a decision they SHOULD provide a
good reason announced, if they fail then I recommend they are just put
noise against science and engineering.

In general, *Any IETF input SHOULD have an announced/discussed
reason*. I posted before about this [1]. I suggest here that the draft
should make clear *what* drives our documents/decisions which I
beleive is the *knowledgable reasons, science, and engineering*.
Hiding the reason of such decision SHOULD not be a process in our IETF
organisation, if we follow its principles. I think few of processes in
IETF (if not many) still have some non clear announcements by
managers, editors, or by processors. When I finish my overview and
complaints/documents I will be more clear of such processes. However,
my initial specific input as below.

ABAmend section 1.2to working group chairs who are charged with
running the process:
ABto to working group chairs who are assigned to run the process:

ABAdding Qs in section 1.2

-Who is authorise by IETF to make decision in WG to adopt or refuse
such I-D. Should it be in an announce reason or without announcement,
or with no understood reason?

-If the I-D is out of scope of the WG charter, still could the WG adopt it?

- Is the WG charter important influence for the reasons of any
decision made regarding documents, or the market interests and WG
consensus are the main influencer?

- Is a WG chair or AD authorise to call to re-charter WG if the WG
refuses to adopt an I-D, or WGs have power to direct their input to
the IETF WG?

AB Comments on 1.2 I don't think there is differences in adopt or
care or consideration of WG, if they are interested in such work they
will adopt it, and if they change their interest in future they can
refuse to submit it. The Chairs and ADs SHOULD not control such
decisions that the WG make [2]. If the WG don't get to a decision, the
Chairs and ADs SHOULD undersdtand the reasons and make them announced
and clear. IETF is an Engineering organisation, only good intelligent
engineering reason SHOULD maintain, and others SHOULD stop the noise
if no reason or value in such input. Therefore, only input with
known/documented reasons should progress [1][3].

[1] http://www.ietf.org/mail-archive/web/ietf/current/msg74750.html
[2] http://www.ietf.org/mail-archive/web/ietf/current/msg75119.html
[3] http://www.ietf.org/mail-archive/web/ietf/current/msg75118.html

AB
__

On 12/4/12, Adrian Farrel adr...@olddog.co.uk wrote:
 Abdussalam,

 By all means send text or suggestions for edits.

 Dave and I will include what is reasonable and seek a consensus that agrees
 with
 our motivation for writing the document.

 Thanks,
 Adrian

 From: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On Behalf Of
 Abdussalam Baryun
 Sent: 04 December 2012 13:33
 To: d...@dcrocker.net
 Cc: ietf
 Subject: Re: Creating an IETF Working Group Draft

 Hi Dave,

 Thanks for your work, please provide us with feedback while the process of
 editing. I was thinking to do something in the future, but thanks that you
 will
 do it.

 AB

 Folks, There is now an Internet Draft, based on Adrian's's slides, intended
 to
 document common practice in the adoption of working group drafts:
 Title:   Creating an IETF Working Group Draft
 Status:  http://datatracker.ietf.org/doc/draft-crocker-id-adoption

 Abstract:
The productive output of IETF working groups is documents, as
mandated by the working group's charter.  Working groups develop
these documents based on initial input of varying levels of maturity.
An initial working group draft might be a document already in wide
use, or it might be a blank sheet, wholly created by the workiing
group, or it might represent any level of maturity in between.  This
document discusses the process of creating formal working group
drafts that are targeted for publication.

 Although it is not intended for a standards-track or bcp publication, it
 would
 be helpful to have discussion that moves the document to represent good
 agreement among the community.
 d/

 --
  Dave Crocker
  Brandenburg InternetWorking
  bbiw.net

RE: Idea for a process experiment to reward running code...

2012-12-05 Thread Abdussalam Baryun

Hi Stephen,

I think it is great idea, I hope it does not die, we need fast-tracks,
without delays, however, giving a fixed time limit for WG feedback and
WG discussion is important  (suggested 6 months), because discussions
about running code should not be ignored. The draft seems to not give
chance to WG to make a formal decision on its adopted work, why you
put the chair to decide for WG of taking the fast track?

AB


Hi all,

I've just posted an idea [1] for a small process improvement.
If it doesn't seem crazy I'll try pursue it with the IESG as
an RFC 3933 process experiment. If its universally hated then
that's fine, it can die.

The IESG have seen (more-or-less) this already but it hasn't
be discussed, so this is just a proposal from me and has no
official status whatsoever.

Any comments, suggestions or better ideas are very welcome.
Feel free to send me comments off list for now, or on this
list I guess. If there's loads of email (always possible,
this being a process thing;-) we can move to some other list.

Regards,
Stephen.

[1] http://tools.ietf.org/id/draft-farrell-ft

Re: 30th Anniversary of Transition to TCP/IP

2013-01-01 Thread Abdussalam Baryun

Happy new year to you and anniversary to IETF, thanks,
It is interesting to see the transition plan, but do we have a future
plan in an ID, not sure, I think the IETF future plans are noted the
IETF reports of meetings not in an ID discussed (which can be historic
after done).

AB

 On 12/31/12, IETF Chair ch...@ietf.org wrote:
 Happy New Year.  It is already 2013 in some part of the world.

 The ARPANET transitioned to TCP/IP on 1 January 1983.  That was 30 years
 ago, and it was a huge milestone in the journey toward the Internet as we
 know it.

 You can see the transition plan.  Like so many other historic networking
 documents, it is an RFC.  See http://www.rfc-editor.org/rfc/rfc801.txt

 Happy New Year,
   Russ

meaning RFC 2119 (was Re:I'm struggling with 2219 language again)

2013-01-04 Thread Abdussalam Baryun

Hi Dean

I agree with you which I suggested before an update to the RFC [*], I
actually writing a work in progress ID, you may give me your
suggestion if you like. I recommend you use for your work IF, THEN
rather than MUST. Easier to read.

*  http://tools.ietf.org/id/draft-baryun-rfc2119-update-00.txt

AB



 I've always held to the idea that RFC 2119 language is for defining
 levels of compliance to requirements, and is best used very sparingly
 (as recommended in RFC 2119 itself). To me, RFC 2119 language doesn't
 make behavior normative -- rather, it describes the implications of
 doing something different than the defined behavior, from will break
 the protocol if you change it to we have reason to think that there
 might be a reason we don't want to describe here that might influence
 you not to do this to here are some reasons that would cause you to
 do something different and on to doing something different might
 offend the sensibilities of the protocol author, but probably won't
 hurt anything else.

 But I'm ghost-editing a document right now whose gen-art review
 suggested replacing the vast majority of is does and are prose
 with MUST. The comments seem to indicate that protocol-defining text
 not using RFC 2119 language (specifically MUST) is not normative.

 This makes me cringe. But my co-editor likes it a lot. And I see smart
 people like Ole also echoing the though that RFC 2119 language is what
 makes text normative.

 For example, the protocol under discussion uses TLS or DTLS for a
 plethora of security reasons. So, every time the draft discusses
 sending a response to a request, we would say the node MUST send a
 response, and this response MUST be constructed by (insert some
 concatenation procedure here) and MUST be transmitted using TLS or
 DTLS.

 Or, a more specific example:

 For the text:

 In order to originate a message to a given Node-ID or
 Resource-ID, a node constructs an appropriate destination list.


 The Gen-ART comment here is:
 -First sentence: a node constructs - a node MUST construct


 We'll literally end up with hundreds of RFC 2119 invocations (mostly
 MUST) in a protocol specification.

 Is this a good or bad thing? My co-editor and I disagree -- he likes
 formalization of the description language, and I like the English
 prose. But it raises process questions for the IETF as a whole:

 Are we deliberately evolving our language to use RFC 2119 terms as the
 principle verbs  of a formal specification language?

 Either way, I'd like to see some consensus. Because my head is
 throbbing and I want to know if it MUST hurt, SHOULD hurst, or just
 hurts. But I MUST proceed in accordance with consensus, because to do
 otherwise would undermine the clarity of our entire specification
 family.

 --
 Dean

Re: meaning RFC 2119 (was Re:I'm struggling with 2219 language again)

2013-01-04 Thread Abdussalam Baryun

I guess the test is whether a reasonably
careful reader might interpret a sentence incorrectly while writing code;
and if so, would a normative keyword help?

I think the best key word used/help is *IF, THEN, ELSE* the programmer
will never miss that key for running code and specification.

AB

 Hi Dean

 I agree with you which I suggested before an update to the RFC [*], I
 actually writing a work in progress ID, you may give me your
 suggestion if you like. I recommend you use for your work IF, THEN
 rather than MUST. Easier to read.

 *  http://tools.ietf.org/id/draft-baryun-rfc2119-update-00.txt

 AB



 I've always held to the idea that RFC 2119 language is for defining
 levels of compliance to requirements, and is best used very sparingly
 (as recommended in RFC 2119 itself). To me, RFC 2119 language doesn't
 make behavior normative -- rather, it describes the implications of
 doing something different than the defined behavior, from will break
 the protocol if you change it to we have reason to think that there
 might be a reason we don't want to describe here that might influence
 you not to do this to here are some reasons that would cause you to
 do something different and on to doing something different might
 offend the sensibilities of the protocol author, but probably won't
 hurt anything else.

 But I'm ghost-editing a document right now whose gen-art review
 suggested replacing the vast majority of is does and are prose
 with MUST. The comments seem to indicate that protocol-defining text
 not using RFC 2119 language (specifically MUST) is not normative.

 This makes me cringe. But my co-editor likes it a lot. And I see smart
 people like Ole also echoing the though that RFC 2119 language is what
 makes text normative.

 For example, the protocol under discussion uses TLS or DTLS for a
 plethora of security reasons. So, every time the draft discusses
 sending a response to a request, we would say the node MUST send a
 response, and this response MUST be constructed by (insert some
 concatenation procedure here) and MUST be transmitted using TLS or
 DTLS.

 Or, a more specific example:

 For the text:

 In order to originate a message to a given Node-ID or
 Resource-ID, a node constructs an appropriate destination list.


 The Gen-ART comment here is:
 -First sentence: a node constructs - a node MUST construct


 We'll literally end up with hundreds of RFC 2119 invocations (mostly
 MUST) in a protocol specification.

 Is this a good or bad thing? My co-editor and I disagree -- he likes
 formalization of the description language, and I like the English
 prose. But it raises process questions for the IETF as a whole:

 Are we deliberately evolving our language to use RFC 2119 terms as the
 principle verbs  of a formal specification language?

 Either way, I'd like to see some consensus. Because my head is
 throbbing and I want to know if it MUST hurt, SHOULD hurst, or just
 hurts. But I MUST proceed in accordance with consensus, because to do
 otherwise would undermine the clarity of our entire specification
 family.

 --
 Dean

Making RFC2119 key language easier to Protocol Readers

2013-01-04 Thread Abdussalam Baryun

 formalization of the description language, and I like the English
 prose. But it raises process questions for the IETF as a whole:

 Are we deliberately evolving our language to use RFC 2119 terms as the
 principle verbs  of a formal specification language?

Is it *our language* or our specification language?

I agree that we use in IETF documents the English language but don't
think it is equal/close to all WORLD's language(s), so using RFC2119
will help programmers to read who may like the spoken language, but
like most the specification coding  language(s). However, the
specification/protocol language reader needs to be clear and in an
easy language. I think in the IETF the coding languages is OUR
language not only English.

AB

Re: Hello ::Please I need to know LEACH protocol standard???

Hi Mahmoud,

The LEACH is not a protocol worked on so far in IETF, not sure if it
standard yet elsewhere!

AB
-

Hello everybody,

I am a researcher of Master's degree , working on LEACH routing
protocol for wireless sensor networks and i need to know for which
standard does LEACH , its family ,or even Layer 3 belong to.

Thank you

Re: Making RFC2119 key language easier to Protocol Readers

Hi Hector,

I like your method, which beleive is the reason why the RFC2119 is
great help for implementors. As I mentioned before if the protocol
specification is long and complicated no doubt its language may make
it more difficult to readers or writters. Therefore, it will be nice
if the IETF surveys this matter as you and Scott suggested.

Thanking you
Abdussalam Baryun

+++
Date: Fri, 04 Jan 2013 22:24:50 -0500
From: Hector Santos hsantos at isdg.net
To: Scott Brim swb at internet2.edu
Sub:Re: I'm struggling with 2219 language again

We have implemented numerous protocols since the 80s. I have a
specific method of approaching a new protocol implementation which
allows for fastest implementation, testing proof of concept and above
all minimum cost. Why bother with the costly complexities of
implementing SHOULDs and MAYs, if the minimum is not something you
want in the end anyway?

A good data point is that for IP/Legal reasons, we do not use other
people's code if we can help it and in the early days, open source was
not as wide spread or even acceptable at the corporate level. In other
words, it was all done in-house, purchased or nothing. I also believe
using other people's code has a high cost as well since you don't have
an in-house expert understanding the inner workings of the externally
developed software.
o Step 1 for Protocol Implementation:


Look for all the MUST protocol features. This includes the explicit
ones and watchful of semantics where its obviously required or things
will break, perhaps it fell thru the crack.

An important consideration for a MUST is that operators are not given
the opportunity to disable these protocol required features. So from a
coding standpoint, this is one area you don't have to worry about
designing configuration tools, the UI, nor including operation
guidelines and documentation for these inherent protocol required
features.

This is the minimum coding framework to allow for all inteop testing
with other software and systems.

The better RFC spec is the one that has documented a checklist, a
minimum requirement summary table, etc. Good example is RFC 1113 for
the various internet hosting protocols. I considered RFC 1123 the
bible!

Technical writing tip: Please stay away from verbosity especially of
subjective concepts and please stop writing as if everyone is stupid.
I always viewed the IETF RFC format as a blend of two steps
of the SE process - functional and technical specifications.
Functional specs tell us what we want and technical specs
tell us how we do it.  So unless a specific functional requirements
RFC was written, maybe some verbosity is needed but it should
be minimized.


Generally, depending on the protocol, we can release code just on
using MUST requirements - the bottom line framework for client/server
communications. Only when this is completely successfully, can your
implementation consider moving on at extending the protocol
implementation with additional SHOULD, MAY features and its optional
complexities.
o Step 2


Look for the SHOULDs. This is the candies of the protocol. If the
SHOULD is really simple to implement, it can be lumped in with step 1.

I know many believe a SHOULD are really a MUST as an alternative
method perhaps - different version of MUST to be done nonetheless.

However, I believe these folks play down an important consideration
for implementing SHOULD based protocol features:
   Developers need to offer these as options to deployment operators.


In other words, if the operator can not turn it off then a SHOULD was
incorrectly used for a MUST which is required with no operator option
to disable.
o Step 3


Look for the MAYs. Very similar to SHOULD, a good way to consider a
SHOULD is as a default enabled (ON out of the box) option and a MAY as
a default disabled (OFF out of the box) option.
Summary:

  MUST   - required, no operator option to disabled. Of course,
   its possible to have a hidden, undocumented switch
   for questionable stuff.

  SHOULD - good idea, recommended. if implemented, enabled it
   out of the box.

  MAY- similar to SHOULD, does not have to be enabled out
   of box.


In both cases for SHOULD and MAY, the operator can turn these protocol
features off/on. For a MUST, the operator can not turn the MUST
feature. These SHOULD/MAY features are documented for operators and
support.

One last thing, I believe in a concept I call CoComp - Cooperative
Competition, where all competitive implementators, including the
protocol technology leader all share a common framework for a minimum
protocol generic to all parties and the internet community. It is
least required to solve the problem or provide a communication avenue.
All else, the SHOULDs, the MAYs, is added value for competing
implementators. It generally is what differentiate the various
implementators software.

I personally believe it is doable to write a new

Re: Making RFC2119 key language easier to Protocol Readers

IMO, too many specs seriously overuse/misuse 2119 language, to the
detriment of readability, common sense, and reserving the terms to
bring attention to those cases where it really is important to
highlight an important point that may not be obvious to a casual
reader/implementor.

also to highlight an important point that may not be obvious to
imlementors which are non-English speakers/writers.

AB

Re: Making RFC2119 key language easier to Protocol Readers

(was Re: I'm struggling with 2219 language again)

 Where you want to use MUST is where an implementation might be tempted
 to take a short cut -- to the detriment of the Internet -- but could
 do so without actually breaking interoperability. A good example is
 with retransmissions and exponential backoff. You can implement those
 incorrectly (or not at all), and still get interoperability. I.e.,
 two machines can talk to each other. Maybe you don't get good
 intereoperability and maybe not great performance under some
 conditions, but you can still build an interoperabile implementation.

 IMO, too many specs seriously overuse/misuse 2119 language, to the
 detriment of readability, common sense, and reserving the terms to
 bring attention to those cases where it really is important to
 highlight an important point that may not be obvious to a casual
 reader/implementor.

Sadly true.

We can fix that, by discussing it further, or as Scott mentioned the survey [*]

 two machines can talk to each other. Maybe you don't get good
 intereoperability and maybe not great performance under some
 conditions, but you can still build an interoperabile implementation.

As machines reads and writes may depend on conditions, I don't think
it is true that you can still interoperabile implementation by
ignoring using/documenting requirement keys language (i.e. all common
keys of all languages).

AB

Re: Making RFC2119 key language easier to Protocol Readers

We can fix that, by discussing it further, or as Scott mentioned make
a survey within IETF [*]

[*] http://www.ietf.org/mail-archive/web/ietf/current/msg76582.html

AB

On 1/5/13, Abdussalam Baryun abdussalambar...@gmail.com wrote:
 (was Re: I'm struggling with 2219 language again)

 Where you want to use MUST is where an implementation might be tempted
 to take a short cut -- to the detriment of the Internet -- but could
 do so without actually breaking interoperability. A good example is
 with retransmissions and exponential backoff. You can implement those
 incorrectly (or not at all), and still get interoperability. I.e.,
 two machines can talk to each other. Maybe you don't get good
 intereoperability and maybe not great performance under some
 conditions, but you can still build an interoperabile implementation.

 IMO, too many specs seriously overuse/misuse 2119 language, to the
 detriment of readability, common sense, and reserving the terms to
 bring attention to those cases where it really is important to
 highlight an important point that may not be obvious to a casual
 reader/implementor.

Sadly true.

 We can fix that, by discussing it further, or as Scott mentioned the survey
 [*]

 two machines can talk to each other. Maybe you don't get good
 intereoperability and maybe not great performance under some
 conditions, but you can still build an interoperabile implementation.

 As machines reads and writes may depend on conditions, I don't think
 it is true that you can still interoperabile implementation by
 ignoring using/documenting requirement keys language (i.e. all common
 keys of all languages).

 AB

Re: Making RFC2119 key language easier to Protocol Readers

I totally agree with you,

AB

+++
As an operator, I purchase equipment and need to write RFQs. I would
like to able to ask more than does the product implement RFC
whatever, I want to also ask Please document all instances where
you did not follow all MUST and SHOULD, and why.

Otherwise I think there needs to be better definition of what it means
to implement or support an RFC when it comes to completness and
what this means as per following SHOULD and MAY.
--
Mikael Abrahamssonemail: swmike at swm.pp.se

Re: Making RFC2119 key language easier to Protocol Readers

Hi Mikael

Also what it means following things in it that is not RFC2119 language.

It will mean, you should understand me/english/ietf/procedure even if
I don't have to explain, and you need to understand English well even
if you are a great implementor or great programming language speaker.

AB
===

On 1/5/13, Abdussalam Baryun abdussalambar...@gmail.com wrote:
 I totally agree with you,

 AB

 +++
 As an operator, I purchase equipment and need to write RFQs. I would
 like to able to ask more than does the product implement RFC
 whatever, I want to also ask Please document all instances where
 you did not follow all MUST and SHOULD, and why.

 Otherwise I think there needs to be better definition of what it means
 to implement or support an RFC when it comes to completness and
 what this means as per following SHOULD and MAY.
 --
 Mikael Abrahamssonemail: swmike at swm.pp.se

Re: A proposal for a scientific approach to this question [was Re: I'm struggling with 2219 language again]

2013-01-06 Thread Abdussalam Baryun

Hi Marc Petit-Huguenin ,

I read the responses so far, and what can be said today is that there is 2
philosophies, with supporters in both camps.  The goal of the IETF is to make
the Internet work better, and I do believe that RFC 2119 is one of the
fundamental tool to reach this goal, but having two ways to use it does not
help this goal.

I like the approach, and agree with you that we need a solution in
IETF which still is not solved or ignored by participants fo some
reasons. However, I agree of a survey or an experiment what ever we
call it, that makes IETF reflects to the RFC2119 performance on the
end-user of such product implementation of RFC protocols. I think many
old participants already have good experience to inform us of some
reality of IETF standards' end-user production.

AB

Re: [apps-discuss] Last Call: draft-ietf-appsawg-json-pointer-07.txt (JSON Pointer) to Proposed Standard

2013-01-06 Thread Abdussalam Baryun

Yes, you've brought that to our attention several times. If you wanted this 
spec to align with your software, it would have been much easier if you'd got 
involved before Last Call.

Why is it called Last Call if we don't accept any new input (e.g.,
draft-ietf-appsawg-json-pointer-07) . Why do we call RFC Request For
Comment if we don't want people to comment on (e.g. RFC2119).

We SHOULD discuss any input any time, thank the participant, and
accept only consensus on each input at any phase of time.

AB

Re: [apps-discuss] Last Call: draft-ietf-appsawg-json-pointer-07.txt (JSON Pointer) to Proposed Standard

2013-01-06 Thread Abdussalam Baryun

The same thing happend to me on one work last call, the WG chair and
authors didn't want to take my input or any minor change in the
document.  The good thing is that if the IESG request a change they
will be welling to change, so don't worry if the comments are
reasonable to IESG it is already heard (i.e. but just in case not
seen, send your comments again to iesg address) :-)

AB

On 1/6/13, Robert Sayre say...@gmail.com wrote:
 On Sun, Jan 6, 2013 at 12:59 AM, Abdussalam Baryun
 abdussalambar...@gmail.com wrote:
Yes, you've brought that to our attention several times. If you wanted
 this spec to align with your software, it would have been much easier if
 you'd got involved before Last Call.

 Why is it called Last Call if we don't accept any new input (e.g.,
 draft-ietf-appsawg-json-pointer-07) . Why do we call RFC Request For
 Comment if we don't want people to comment on (e.g. RFC2119).

 We SHOULD discuss any input any time, thank the participant, and
 accept only consensus on each input at any phase of time.

 This is true, and a timing objection is a pretty low-quality response
 to a substantive issue. This particular timing objection is also
 somewhat misleading, since it looks like more than one person provided
 this feedback prior to IETF Last Call without receiving a response:
 http://www.ietf.org/mail-archive/web/apps-discuss/current/msg08531.html.
 My message on the matter was sent on December 3rd, 2012.

 - Rob

Re: A proposal for a scientific approach to this question [was Re: I'm struggling with 2219 language again]

Hi John,

thank you for your reply (i.e. learned alot), so I understand that a
RFC standard track may have more than one implementation but same
behavior enough not to make an error. Regarding following 2119, I
understand most text follow it only when there are normative actions.
Regarding implementer claiming following a RFC, but the question of
error in process is does the RFC lack communication requirement with
the community?

AB

On 1/7/13, John Day jeanj...@comcast.net wrote:
 Strictly speaking, the language of 2119 should be followed wherever
 necessary in order for the text to be normative and make it mandatory
 that a conforming implementation meets some requirement.  Otherwise,
 someone could build an implementation and claim it was correct and
 possibly cause legal problems. However, in the IETF there is also a
 requirement that there be two independent but communicating
 implementations for an RFC to standards-track. Correct?

 For all practical purposes, this requirement makes being able to
 communicate with one of the existing implementations the formal and
 normative definition of the RFC.  Any debate over the content of the
 RFC text is resolved by what the implementations do.  It would seem
 to be at the discretion of the authors of the implementations to
 determine whether or not any problems that are raised are bugs or not.

 Then it would seem that regardless of whether 2119 is followed, the
 RFCs are merely informative guides.

 So while the comments are valid that RFC 2119 should be followed,
 they are also irrelevant.

 Given that any natural language description is going to be ambiguous,
 this is probably for the best.

 Take care,
 John Day

 At 9:41 AM +0100 1/6/13, Abdussalam Baryun wrote:
Hi Marc Petit-Huguenin ,

I read the responses so far, and what can be said today is that there is
 2
philosophies, with supporters in both camps.  The goal of the IETF is to
 make
the Internet work better, and I do believe that RFC 2119 is one of the
fundamental tool to reach this goal, but having two ways to use it does
 not
help this goal.

I like the approach, and agree with you that we need a solution in
IETF which still is not solved or ignored by participants fo some
reasons. However, I agree of a survey or an experiment what ever we
call it, that makes IETF reflects to the RFC2119 performance on the
end-user of such product implementation of RFC protocols. I think many
old participants already have good experience to inform us of some
reality of IETF standards' end-user production.

AB

Re: A proposal for a scientific approach to this question [was Re: I'm struggling with 2219 language again]

but the question of
 error in process is; does the RFC lack communication requirement with
 the community?


Sorry if not clear. I mean that as some participant are requesting a
scientific approach to struggling with 2119 (i.e. thread-subject),
does that mean in some RFCs the use or not use (i.e. we see that
participant use different approaches to follow the 2119) that it may
add communication confuse with some of community?

AB

Re: A proposal for a scientific approach to this question [was Re: I'm struggling with 2219 language again]

Why not participant follow one approach to use 2119 in IDs and done,
and if not/another, then please specify in the language section.

AB

Re: A proposal for a scientific approach to this question [was Re: I'm struggling with 2219 language again]