IP Flow Information Export (ipfix)

headers Benoit Claise | 4 Mar 2009 09:14

_______________________________________________
IPFIX mailing list
IPFIX <at> ietf.org
https://www.ietf.org/mailman/listinfo/ipfix

Nevil,

I would like to request a slot to present 
draft-claise-structured-data-in-ipfix-00.txt
Thank you.

Regards, Benoit.
> Hi all:
>
> A first draft agenda for our IPFIX session in San Francisco is
> appended below.  Please send any additional agenda items, or
> suggestions for improvements to me.
>
> Cheers, Nevil
>

_______________________________________________
IPFIX mailing list
IPFIX <at> ietf.org
https://www.ietf.org/mailman/listinfo/ipfix

Hi Nevil and Benoit,

Nevil, thank you for assignment for 60 min time slot for IPFIX Mediation.
But, the agenda shows the total time slot for current WG drafts is 40 min.
Which one is correct?

I think that 60 min time slot is enough for IPFIX Mediation. Maybe 40
min is appropriate for me. Spare time can be assigned for new draft.

5. Current WG drafts                                    = 40 min
    a) IPFIX Per-Stream SCTP reporting (Benoit CLaise)       ( 5 min)
       - draft-ietf-ipfix-export-per-sctp-stream-02.txt
           26 Jan 09
    b) Configuration Data Model                              (10 min)
       - draft-ietf-ipfix-configuration-model-01.txt
            3 Nov 08
    c) IPFIX Mediation: (Kobayashi Atsushi)                  (25 min)
       - draft-ietf-ipfix-mediators-problem-statement-02.txt
            4 Feb 09
       - draft-ietf-ipfix-mediators-framework-02.txt         (35 min)

On Wed, 04 Mar 2009 09:15:45 +0100
Benoit Claise <bclaise <at> cisco.com> wrote:

> Nevil,
> 
> I would like to request a slot to present 
> draft-claise-structured-data-in-ipfix-00.txt
> Thank you.
> 
> Regards, Benoit.
> > Hi all:
> >
> > A first draft agenda for our IPFIX session in San Francisco is
> > appended below.  Please send any additional agenda items, or
> > suggestions for improvements to me.
> >
> > Cheers, Nevil
> >
> 
> _______________________________________________
> IPFIX mailing list
> IPFIX <at> ietf.org
> https://www.ietf.org/mailman/listinfo/ipfix

--- 
Atsushi KOBAYASHI  <akoba <at> nttv6.net>
NTT Information Sharing Platform Lab.
tel:+81-(0)422-59-3978 fax:+81-(0)422-59-5637

_______________________________________________
IPFIX mailing list
IPFIX <at> ietf.org
https://www.ietf.org/mailman/listinfo/ipfix

Hi Brian,

Benoit reminded me that you promised some input regarding (D)TLS
parameters that might be included into the configuration data model.
http://www.ietf.org/proceedings/08nov/minutes/ipfix.txt

Do you can still remember what you were thinking of?
Probably the Fully Qualified Domain Name?

If you are into this topic, maybe you can send a list with all common
parameters - just to get an overview - and those that are interesting to
have in the configuration data model. For example, I assume that it is
not interesting to configure certificates - these are probably provided
by different means to the devices.

Gerhard

--

-- 
Dipl.-Ing. Gerhard Münz
Chair for Network Architectures and Services (I8)
Department of Informatics
Technische Universität München
Boltzmannstr. 3, 85748 Garching bei München, Germany
Phone:  +49 89 289-18008       Fax: +49 89 289-18033
E-mail: muenz <at> net.in.tum.de    WWW: http://www.net.in.tum.de/~muenz

_______________________________________________
IPFIX mailing list
IPFIX <at> ietf.org
https://www.ietf.org/mailman/listinfo/ipfix

Hi, Gerhard,

The main parameters I was thinking of are keying and identity  
parameters. Perhaps we can state that CPs and EPs will be keyed  
offline, but at least it might be nice to change the names of the  
peers a device is willing to communicate with.

For TLS, at minimum, an EP or CP must know:

1. its CA certificates (PEM/DER)
2. CA certificates for its peers' certificates (PEM/DER) (if not using  
a single CA for all)
3. its own certificate and private key (PKCS#12)
4. the names of the peers it is willing to communicate with  
(subjectName string) (if not assuming signature by a known CA is  
sufficient)
5. CRL or OCSP peer for revocation, if supported (which it should be,  
though 5101 doesn't state this directly)

How much of that to support in config is an open question. Beyond that  
it gets a bit implementation-specific.

I hope to do a thorough review of the config work by San Francisco,  
though no promises, as it's a bit mad here at the moment. Will you be  
at the meeting?

Cheers,

Brian

On Mar 6, 2009, at 2:02 PM, Gerhard Muenz wrote:

>
> Hi Brian,
>
> Benoit reminded me that you promised some input regarding (D)TLS
> parameters that might be included into the configuration data model.
> http://www.ietf.org/proceedings/08nov/minutes/ipfix.txt
>
> Do you can still remember what you were thinking of?
> Probably the Fully Qualified Domain Name?
>
> If you are into this topic, maybe you can send a list with all common
> parameters - just to get an overview - and those that are  
> interesting to
> have in the configuration data model. For example, I assume that it is
> not interesting to configure certificates - these are probably  
> provided
> by different means to the devices.
>
> Gerhard
>
> -- 
> Dipl.-Ing. Gerhard Münz
> Chair for Network Architectures and Services (I8)
> Department of Informatics
> Technische Universität München
> Boltzmannstr. 3, 85748 Garching bei München, Germany
> Phone:  +49 89 289-18008       Fax: +49 89 289-18033
> E-mail: muenz <at> net.in.tum.de    WWW: http://www.net.in.tum.de/~muenz
>
>

_______________________________________________
IPFIX mailing list
IPFIX <at> ietf.org
https://www.ietf.org/mailman/listinfo/ipfix

Hi Brian,

Brian Trammell wrote:
> Hi, Gerhard,
> 
> The main parameters I was thinking of are keying and identity
> parameters. Perhaps we can state that CPs and EPs will be keyed offline,
> but at least it might be nice to change the names of the peers a device
> is willing to communicate with.

Who should restrict its willingness to communicate? The CP or the EP or
both?

Just using the name does not seem to be sufficient because the same name
could be used with several certificates, right?
So, it would be necessary to say: "CP accepts data from EP with name=X
authorized by certificate/CA Y".

Transporting certificates and keys to the devices does not seem to be
useful. However, if the device has several keys, it would be useful to
choose one of them.

It seems that we need kind of abstract identifiers for keys and
certificates saved on a device in order to refer to them in the
configuration.

> For TLS, at minimum, an EP or CP must know:
> 
> 1. its CA certificates (PEM/DER)
> 2. CA certificates for its peers' certificates (PEM/DER) (if not using a
> single CA for all)
> 3. its own certificate and private key (PKCS#12)
> 4. the names of the peers it is willing to communicate with (subjectName
> string) (if not assuming signature by a known CA is sufficient)
> 5. CRL or OCSP peer for revocation, if supported (which it should be,
> though 5101 doesn't state this directly)
> 
> How much of that to support in config is an open question. Beyond that
> it gets a bit implementation-specific.
> 
> I hope to do a thorough review of the config work by San Francisco,
> though no promises, as it's a bit mad here at the moment. Will you be at
> the meeting?

No, unfortunately not.

Cheers,
Gerhard

> 
> Cheers,
> 
> Brian
> 
> On Mar 6, 2009, at 2:02 PM, Gerhard Muenz wrote:
> 
>>
>> Hi Brian,
>>
>> Benoit reminded me that you promised some input regarding (D)TLS
>> parameters that might be included into the configuration data model.
>> http://www.ietf.org/proceedings/08nov/minutes/ipfix.txt
>>
>> Do you can still remember what you were thinking of?
>> Probably the Fully Qualified Domain Name?
>>
>> If you are into this topic, maybe you can send a list with all common
>> parameters - just to get an overview - and those that are interesting to
>> have in the configuration data model. For example, I assume that it is
>> not interesting to configure certificates - these are probably provided
>> by different means to the devices.
>>
>> Gerhard
>>
>> -- 
>> Dipl.-Ing. Gerhard Münz
>> Chair for Network Architectures and Services (I8)
>> Department of Informatics
>> Technische Universität München
>> Boltzmannstr. 3, 85748 Garching bei München, Germany
>> Phone:  +49 89 289-18008       Fax: +49 89 289-18033
>> E-mail: muenz <at> net.in.tum.de    WWW: http://www.net.in.tum.de/~muenz
>>
>>
> 

--

-- 
Dipl.-Ing. Gerhard Münz
Chair for Network Architectures and Services (I8)
Department of Informatics
Technische Universität München
Boltzmannstr. 3, 85748 Garching bei München, Germany
Phone:  +49 89 289-18008       Fax: +49 89 289-18033
E-mail: muenz <at> net.in.tum.de    WWW: http://www.net.in.tum.de/~muenz

_______________________________________________
IPFIX mailing list
IPFIX <at> ietf.org
https://www.ietf.org/mailman/listinfo/ipfix

On Mar 6, 2009, at 3:15 PM, Gerhard Muenz wrote:

>
> Hi Brian,
>
> Brian Trammell wrote:
>> Hi, Gerhard,
>>
>> The main parameters I was thinking of are keying and identity
>> parameters. Perhaps we can state that CPs and EPs will be keyed  
>> offline,
>> but at least it might be nice to change the names of the peers a  
>> device
>> is willing to communicate with.
>
> Who should restrict its willingness to communicate? The CP or the EP  
> or
> both?

Per 5101, both.

> Just using the name does not seem to be sufficient because the same  
> name
> could be used with several certificates, right?
> So, it would be necessary to say: "CP accepts data from EP with name=X
> authorized by certificate/CA Y".

By "name" I mean the Subject DN (Distinguished Name) defined by X.509  
is suited for this purpose (see 4, below). An example DN (from your  
Thawte cert :) follows:

SN=Muenz, GN=Gerhard, CN=Gerhard Muenz/emailAddress=muenz <at> informatik.uni-tuebingen.de 
/emailAddress=muenz <at> net.in.tum.de

A CA SHOULD _never_ sign two different certificates with the same  
validity for the same subject without an intervening revocation;  
likewise nobody should ever treat the same certificate as useful for  
multiple entities at the DN level.

> Transporting certificates and keys to the devices does not seem to be
> useful. However, if the device has several keys, it would be useful to
> choose one of them.
>
> It seems that we need kind of abstract identifiers for keys and
> certificates saved on a device in order to refer to them in the
> configuration.

X.509 DNs are used for this purpose. CNs (Common Names) can be used  
for this in practice, but this is not recommended.

Cheers,

Brian

>> For TLS, at minimum, an EP or CP must know:
>>
>> 1. its CA certificates (PEM/DER)
>> 2. CA certificates for its peers' certificates (PEM/DER) (if not  
>> using a
>> single CA for all)
>> 3. its own certificate and private key (PKCS#12)
>> 4. the names of the peers it is willing to communicate with  
>> (subjectName
>> string) (if not assuming signature by a known CA is sufficient)
>> 5. CRL or OCSP peer for revocation, if supported (which it should be,
>> though 5101 doesn't state this directly)
>>
>> How much of that to support in config is an open question. Beyond  
>> that
>> it gets a bit implementation-specific.
>>
>> I hope to do a thorough review of the config work by San Francisco,
>> though no promises, as it's a bit mad here at the moment. Will you  
>> be at
>> the meeting?
>
> No, unfortunately not.
>
> Cheers,
> Gerhard
>
>>
>> Cheers,
>>
>> Brian
>>
>> On Mar 6, 2009, at 2:02 PM, Gerhard Muenz wrote:
>>
>>>
>>> Hi Brian,
>>>
>>> Benoit reminded me that you promised some input regarding (D)TLS
>>> parameters that might be included into the configuration data model.
>>> http://www.ietf.org/proceedings/08nov/minutes/ipfix.txt
>>>
>>> Do you can still remember what you were thinking of?
>>> Probably the Fully Qualified Domain Name?
>>>
>>> If you are into this topic, maybe you can send a list with all  
>>> common
>>> parameters - just to get an overview - and those that are  
>>> interesting to
>>> have in the configuration data model. For example, I assume that  
>>> it is
>>> not interesting to configure certificates - these are probably  
>>> provided
>>> by different means to the devices.
>>>
>>> Gerhard
>>>
>>> -- 
>>> Dipl.-Ing. Gerhard Münz
>>> Chair for Network Architectures and Services (I8)
>>> Department of Informatics
>>> Technische Universität München
>>> Boltzmannstr. 3, 85748 Garching bei München, Germany
>>> Phone:  +49 89 289-18008       Fax: +49 89 289-18033
>>> E-mail: muenz <at> net.in.tum.de    WWW: http://www.net.in.tum.de/~muenz
>>>
>>>
>>
>
> -- 
> Dipl.-Ing. Gerhard Münz
> Chair for Network Architectures and Services (I8)
> Department of Informatics
> Technische Universität München
> Boltzmannstr. 3, 85748 Garching bei München, Germany
> Phone:  +49 89 289-18008       Fax: +49 89 289-18033
> E-mail: muenz <at> net.in.tum.de    WWW: http://www.net.in.tum.de/~muenz
>
>

_______________________________________________
IPFIX mailing list
IPFIX <at> ietf.org
https://www.ietf.org/mailman/listinfo/ipfix

Hi,

>>> The main parameters I was thinking of are keying and identity
>>> parameters. Perhaps we can state that CPs and EPs will be keyed offline,
>>> but at least it might be nice to change the names of the peers a device
>>> is willing to communicate with.
>>
>> Who should restrict its willingness to communicate? The CP or the EP or
>> both?
> 
> Per 5101, both.

Ok. Own name and accepted peer names could be configured per CP/EP.

>> Just using the name does not seem to be sufficient because the same name
>> could be used with several certificates, right?
>> So, it would be necessary to say: "CP accepts data from EP with name=X
>> authorized by certificate/CA Y".
> 
> By "name" I mean the Subject DN (Distinguished Name) defined by X.509 is
> suited for this purpose (see 4, below). An example DN (from your Thawte
> cert :) follows:
> 
> SN=Muenz, GN=Gerhard, CN=Gerhard
> Muenz/emailAddress=muenz <at> informatik.uni-tuebingen.de/emailAddress=muenz <at> net.in.tum.de
> 
> A CA SHOULD _never_ sign two different certificates with the same
> validity for the same subject without an intervening revocation;
> likewise nobody should ever treat the same certificate as useful for
> multiple entities at the DN level.

Ok, as long you have a single CA. With two CAs, there can be two
certificates with the same name for different subjects.
But you usually trust the CAs and their practice to issue certificates :)

Gerhard

>> Transporting certificates and keys to the devices does not seem to be
>> useful. However, if the device has several keys, it would be useful to
>> choose one of them.
>>
>> It seems that we need kind of abstract identifiers for keys and
>> certificates saved on a device in order to refer to them in the
>> configuration.
> 
> X.509 DNs are used for this purpose. CNs (Common Names) can be used for
> this in practice, but this is not recommended.
> 
> Cheers,
> 
> Brian
> 

--

-- 
Dipl.-Ing. Gerhard Münz
Chair for Network Architectures and Services (I8)
Department of Informatics
Technische Universität München
Boltzmannstr. 3, 85748 Garching bei München, Germany
Phone:  +49 89 289-18008       Fax: +49 89 289-18033
E-mail: muenz <at> net.in.tum.de    WWW: http://www.net.in.tum.de/~muenz

_______________________________________________
IPFIX mailing list
IPFIX <at> ietf.org
https://www.ietf.org/mailman/listinfo/ipfix

On Mar 6, 2009, at 4:08 PM, Gerhard Muenz wrote:

>
> Hi,
>
>>>> The main parameters I was thinking of are keying and identity
>>>> parameters. Perhaps we can state that CPs and EPs will be keyed  
>>>> offline,
>>>> but at least it might be nice to change the names of the peers a  
>>>> device
>>>> is willing to communicate with.
>>>
>>> Who should restrict its willingness to communicate? The CP or the  
>>> EP or
>>> both?
>>
>> Per 5101, both.
>
> Ok. Own name and accepted peer names could be configured per CP/EP.
>
>>> Just using the name does not seem to be sufficient because the  
>>> same name
>>> could be used with several certificates, right?
>>> So, it would be necessary to say: "CP accepts data from EP with  
>>> name=X
>>> authorized by certificate/CA Y".
>>
>> By "name" I mean the Subject DN (Distinguished Name) defined by X. 
>> 509 is
>> suited for this purpose (see 4, below). An example DN (from your  
>> Thawte
>> cert :) follows:
>>
>> SN=Muenz, GN=Gerhard, CN=Gerhard
>> Muenz/emailAddress=muenz <at> informatik.uni-tuebingen.de/emailAddress=muenz <at> net.in.tum.de
>>
>> A CA SHOULD _never_ sign two different certificates with the same
>> validity for the same subject without an intervening revocation;
>> likewise nobody should ever treat the same certificate as useful for
>> multiple entities at the DN level.
>
> Ok, as long you have a single CA. With two CAs, there can be two
> certificates with the same name for different subjects.
> But you usually trust the CAs and their practice to issue  
> certificates :)

In this case, you can qualify the DN of the Subject with the DN of the  
Issuer (CA), and you have a (theoretically :) ) globally unique  
identifier...

>
> Gerhard
>
>>> Transporting certificates and keys to the devices does not seem to  
>>> be
>>> useful. However, if the device has several keys, it would be  
>>> useful to
>>> choose one of them.
>>>
>>> It seems that we need kind of abstract identifiers for keys and
>>> certificates saved on a device in order to refer to them in the
>>> configuration.
>>
>> X.509 DNs are used for this purpose. CNs (Common Names) can be used  
>> for
>> this in practice, but this is not recommended.
>>
>> Cheers,
>>
>> Brian
>>
>
> -- 
> Dipl.-Ing. Gerhard Münz
> Chair for Network Architectures and Services (I8)
> Department of Informatics
> Technische Universität München
> Boltzmannstr. 3, 85748 Garching bei München, Germany
> Phone:  +49 89 289-18008       Fax: +49 89 289-18033
> E-mail: muenz <at> net.in.tum.de    WWW: http://www.net.in.tum.de/~muenz
>
>

_______________________________________________
IPFIX mailing list
IPFIX <at> ietf.org
https://www.ietf.org/mailman/listinfo/ipfix

Hi all:

If you have any further changes, please send them to me
pronto 

Cheers, Nevil

======================================================
Ip Flow Information Export WG (ipfix)
IETF #74, San Francisco
Monday, 23 Mar 09 at 1300-1500
======================================================

Chairs:
Juergen Quittek <quittek <at> netlab.nec.de>
Nevil Brownlee  <n.brownlee <at> auckland.ac.nz>

 >>> DRAFT <<<  AGENDA:

1. Agenda review WG Status                              = 5 min

2. Internet-Draft status                                = 5 min
      [In RFC Editor queue:
        - draft-ietf-ipfix-architecture-12.txt
        - draft-ietf-ipfix-as-12.txt
        - draft-ietf-ipfix-reducing-redundancy-04.txt
        - draft-ietf-ipfix-testing-04.txt
        - draft-ietf-psamp-framework-13.txt
        - draft-ietf-psamp-sample-tech-10.txt
        - draft-ietf-psamp-protocol-09.txt
        - draft-ietf-psamp-info-11.txt]

3. Information Element Registry status                 = 5 min
       IANA's XML page for this are now at
         http://www.iana.org/assignments/ipfix/ipfix.xhtml
       We are now handling errata found in RFC 5102, IANA should
       change the registry for such changes;  We need to establish
       a procedure for handling changes in other IEs

4. Drafts submitted to IESG                             = 15 min
    a) IPFIX File Format (Brian Trammell)                    ( 3 min)
       - draft-ietf-ipfix-file-03.txt  24 Oct 08
    b) Exporting Type Information for IPFIX IEs (Elisa Boschi)
       - draft-ietf-ipfix-exporting-type-02.txt  14 Jul 08   ( 3 min)

    c) IPFIX MIB (Thomas Dietz)
       - draft-dietz-ipfix-mib-05.txt  3 Nov 08
           MIB Doctors have requested a revised draft        ( 9 min)

5. Current WG drafts                                    = 50 min
    a) IPFIX Per-Stream SCTP reporting (Benoit CLaise)       ( 5 min)
       - draft-ietf-ipfix-export-per-sctp-stream-02.txt
           26 Jan 09
    b) Configuration Data Model                              ( 5 min)
       - draft-ietf-ipfix-configuration-model-01.txt
            3 Nov 08
    c) IPFIX Mediation: (Kobayashi Atsushi)                  (15 min)
       - draft-ietf-ipfix-mediators-problem-statement-02.txt
            4 Feb 09
       - draft-ietf-ipfix-mediators-framework-02.txt         (25 min)
           10 Feb 09

6. Other drafts                                         = 30 min
    a) Flow Selection (Lorenzo Peluso, Tanja Zseby)          (10 min)
        - draft-peluso-flowselection-tech-02

    b) IP Flow Anonymization Support (Elisa Bschi, Brian Trammel)
        - draft-boschi-ipfix-anon-02  12 Jan 09              (10 min)

    c) Handling Structured Data (Benoit Claise)
        - draft-claise-structured-data-in-ipfix-00.txt       (10 min)

7. Any Other Drafts ???                                 = 10 min

Presentation slides will be available at
  https://datatracker.ietf.org/public/meeting_materials.cgi?meeting_num=74
  (search for IPFIX in the Operations and Management Area)

Participation via jabber is offered at ipfix <at> jabber.ietf.org

--

-- 
---------------------------------------------------------------------
  Nevil Brownlee                    Computer Science Department | ITS
  Phone: +64 9 373 7599 x88941             The University of Auckland
  FAX: +64 9 373 7453   Private Bag 92019, Auckland 1142, New Zealand
_______________________________________________
IPFIX mailing list
IPFIX <at> ietf.org
https://www.ietf.org/mailman/listinfo/ipfix

10	June 2013
22	May 2013
32	April 2013
43	March 2013
41	February 2013
19	January 2013
54	December 2012
61	November 2012
75	October 2012
41	September 2012
43	August 2012
48	July 2012
42	June 2012
7	May 2012
39	April 2012
70	March 2012
63	February 2012
11	January 2012
15	December 2011
33	November 2011
42	October 2011
64	September 2011
68	August 2011
48	July 2011
26	June 2011
28	May 2011
36	April 2011
56	March 2011
16	February 2011
26	January 2011
25	December 2010
44	November 2010
73	October 2010
25	September 2010
20	August 2010
38	July 2010
11	June 2010
30	May 2010
20	April 2010
128	March 2010
37	February 2010
31	January 2010
22	December 2009
48	November 2009
55	October 2009
17	September 2009
24	August 2009
73	July 2009
87	June 2009
14	May 2009
33	April 2009
62	March 2009
38	February 2009
12	January 2009
1	December 2008
38	November 2008
22	October 2008
9	September 2008
18	August 2008
32	July 2008
29	June 2008
8	May 2008
15	April 2008
44	March 2008
29	February 2008
18	January 2008
7	December 2007
26	November 2007
20	October 2007
27	September 2007
36	August 2007
79	July 2007
23	June 2007
38	May 2007
12	April 2007
46	March 2007
21	February 2007
30	January 2007
84	December 2006
39	November 2006
111	October 2006
54	September 2006
7	August 2006
17	July 2006
41	June 2006
87	May 2006
72	April 2006
17	March 2006
1	January 2006
16	December 2005
1	September 2005
1	August 2005
3	July 2005
1	June 2005
33	May 2005
14	April 2005
59	March 2005
7	February 2005
3	December 2004
22	November 2004
18	October 2004
16	August 2004
13	July 2004
35	February 2004
94	January 2004
59	December 2003
152	November 2003
153	October 2003
10	September 2003
26	August 2003
32	July 2003
76	June 2003
143	May 2003
40	April 2003
17	March 2003
24	February 2003
34	January 2003
1	December 2002
96	November 2002
231	October 2002
20	September 2002
63	August 2002
27	July 2002
36	June 2002
23	May 2002
74	April 2002

[IPFIX] [Fwd: I-D ACTION:draft-claise-structured-data-in-ipfix-00.txt]

Re: [IPFIX] DRAFT Agenda for San Francisco IETF

Re: [IPFIX] DRAFT Agenda for San Francisco IETF

[IPFIX] IPFIX configuration: (D)TLS

Re: [IPFIX] IPFIX configuration: (D)TLS

Re: [IPFIX] IPFIX configuration: (D)TLS

Re: [IPFIX] IPFIX configuration: (D)TLS

Re: [IPFIX] IPFIX configuration: (D)TLS

Re: [IPFIX] IPFIX configuration: (D)TLS

[IPFIX] Updated agenda for San Francisco meeting

Mon	Tue	Wed	Thu	Fri	Sat	Sun

						1
2	3	4	5	6	7	8
9	10	11	12	13	14	15
16	17	18	19	20	21	22
23	24	25	26	27	28	29
30	31