Subject: Routing Area Draft Minutes

From: "BRUNGARD, DEBORAH A" <[email-masked]>
Date: Thu, 14 Nov 2013 19:08:14 +0000

Hi,

Draft minutes are uploaded at:
http://www.ietf.org/proceedings/88/minutes/minutes-88-rtgarea

Comments welcome.

Much thanks everyone for submitting your WG status slides-

Deborah

---

From: Abdussalam Baryun <[email-masked]>
Date: Sat, 16 Nov 2013 11:13:50 +0100

My respond comment about area management meeting of routing. This message
is just a comment, but I know that I was not active to participate in
meetings, so this is my effort or opinion and it may improve the meeting in
future if you agree.

It seems that meeting discussions (as from minutes) only for routing area
documents, does not mention influences of other works outside routing area.
What about WG chairs managing of groups or DTs? I think the meeting is not
covering all important concerns or activities within Routing Area. What
about documents that are delayed for a year to become RFC like OLSRv2?

I request that if a DT is created in this area (Manet WG has one now and
maybe others) then it is good to mention it in the meeting, also
mentioning the community complains related to area-work if there are.

AB

On Thursday, November 14, 2013, BRUNGARD, DEBORAH A wrote:

> *http://www.ietf.org/proceedings/88/minutes/minutes-88-rtgarea*<http://www.ietf.org/proceedings/88/minutes/minutes-88-rtgarea>
>
> Comments welcome.
>

---

From: Thomas Heide Clausen <[email-masked]>
Date: Sat, 16 Nov 2013 12:38:30 +0100

Abdussalam,

I will leave others to address the other points of your email, but I can speak to part of this:

On 16 nov. 2013, at 11:13, Abdussalam Baryun <[email-masked]> wrote:

> It seems that meeting discussions (as from minutes) only for routing area documents, does not mention influences of other works outside routing area. What about WG chairs managing of groups or DTs? I think the meeting is not covering all important concerns or activities within Routing Area. What about documents that are delayed for a year to become RFC like OLSRv2?

OLSRv2 is not published as it has normative references to other documents, currently being finalized - and that, with the help of both SEC and RTG ADs.

Indeed, the RFC Editor not publishing a document as long as its normative references have not stabilized (which, for IETF documents, means that they themselves have been published as RFCs) is both normal procedure, and is highly desirable: you would, for example, not be able to claim conformance to a standard, if the standard had "not yet stable normative references", as these might change (and, render your implementation non-conformant)

The issue was that the SEC ADs, in reviewing OLSRv2, uncovered the need for some more security work to be undertaken. I am sure that you agree that "security is good", right? The decision at the time was to handle that in separate documents, add a normative reference to these documents from OLSRv2, move OLSRv2 to the RFC Editor, and then focus on the security  documents.

The authors of OLSRv2, the relevant WG, and the responsible ADs (RTG and SEC) are all aware of the state of advancement, and the authors and the ADs are working hard (and, in unison) to move forward. Indeed, the WG did its work and did WGLC the security documents a while back, the IESG reviewed them, gave their comments. The SEC ADs raised, each, a discuss - discusses which, essentially, amounts to helping the authors get a couple of (important) details right. Incidentally, I believe, resolution of these discuss'es is immanent.

So this particular point is very much normal - and desirable - IETF process. I'd almost say that it's proof that the IETF process works ;)

Best,

Thomas

Sent from my iPad
> 
> My respond comment about area management meeting of routing. This message is just a comment, but I know that I was not active to participate in meetings, so this is my effort or opinion and it may improve the meeting in future if you agree.
> 
> It seems that meeting discussions (as from minutes) only for routing area documents, does not mention influences of other works outside routing area. What about WG chairs managing of groups or DTs? I think the meeting is not covering all important concerns or activities within Routing Area. What about documents that are delayed for a year to become RFC like OLSRv2?
> 
> I request that if a DT is created in this area (Manet WG has one now and maybe others) then it is good to mention it in the meeting, also mentioning the community complains related to area-work if there are.
> 
> AB
> 
> _______________________________________________
> routing-discussion mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/routing-discussion

---

From: Abdussalam Baryun <[email-masked]>
Date: Sat, 16 Nov 2013 16:16:25 +0100

Thanks Thomas. I am part of WG/area but no information when OLSRv2 is RFC,
sorry I may missed to find it, but if there is no expectation time then it
may be delayed. The IETF process always work but the aim is to improve it
without delays, or providing time period of such process.

AB

On Saturday, November 16, 2013, Thomas Heide Clausen wrote:

> On 16 nov. 2013, at 11:13, Abdussalam Baryun <[email-masked]<javascript:_e({}, 'cvml', [email-masked]');>>
> wrote:
>
> OLSRv2 is not published as it has normative references to other documents,
> currently being finalized - and that, with the help of both SEC and RTG ADs.
>
> Indeed, the RFC Editor not publishing a document as long as its normative
> references have not stabilized (which, for IETF documents, means that they
> themselves have been published as RFCs) is both normal procedure, and is
> highly desirable: you would, for example, not be able to claim conformance
> to a standard, if the standard had "not yet stable normative references",
> as these might change (and, render your implementation non-conformant)
>
> The issue was that the SEC ADs, in reviewing OLSRv2, uncovered the need
> for some more security work to be undertaken. I am sure that you agree that
> "security is good", right? The decision at the time was to handle that in
> separate documents, add a normative reference to these documents from
> OLSRv2, move OLSRv2 to the RFC Editor, and then focus on the security
>  documents.
>
> The authors of OLSRv2, the relevant WG, and the responsible ADs (RTG and
> SEC) are all aware of the state of advancement, and the authors and the ADs
> are working hard (and, in unison) to move forward. Indeed, the WG did its
> work and did WGLC the security documents a while back, the IESG reviewed
> them, gave their comments. The SEC ADs raised, each, a discuss - discusses
> which, essentially, amounts to helping the authors get a couple of
> (important) details right. Incidentally, I believe, resolution of these
> discuss'es is immanent.
>
> So this particular point is very much normal - and desirable - IETF
> process. I'd almost say that it's proof that the IETF process works ;)
>
> Best,
>
> Thomas
>
> Sent from my iPad
>
> [email-masked] <javascript:_e({}, 'cvml',
> [email-masked]');>