Subject: [mile] next up: mile-template

From: Brian Trammell <[email-masked]>
Date: Wed, 1 Feb 2012 11:41:02 +0100

Hi, Kathleen, all,

Now that the WG work on 6045-bis and 6046-bis is complete, and (almost) in accordance with the charter, I believe the present revision of draft-ietf-mile-template to be ready for WGLC.

Many thanks, best regards,

Brian Trammell (as author of mile-template)

---

From: <[email-masked]>
Date: Wed, 1 Feb 2012 07:34:16 -0500

Hello,

We are starting a 2 week review period, the working group last call (WGLC) for draft-ietf-mile-template. Please review and comment to the MILE list on the template draft.  

This is a short one and is used to provide a template for all extensions defined in MILE.

http://tools.ietf.org/html/draft-ietf-mile-template-00

Last call on comments will end the morning of February 15th.

Thank you,
Kathleen (as WG chair)

-----Original Message-----
From: Brian Trammell [mailto:[email-masked]] 
Sent: Wednesday, February 01, 2012 5:41 AM
To: Moriarty, Kathleen
Cc: [email-masked]
Subject: next up: mile-template

Hi, Kathleen, all,

---

From: <[email-masked]>
Date: Mon, 6 Feb 2012 15:00:53 -0500

Hello!

For those of you who have not reviewed/commented on a draft, this would be an easy one to get your feet wet.  Feedback could be on grammar, whether the template is sufficient to provide enough information for developers using specifications for extensions following this specification, or any other nits or positive comments you have on the draft.

Thanks,
Kathleen

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: Wednesday, February 01, 2012 7:34 AM
To: [email-masked]
Cc: [email-masked]
Subject: [mile] Working group last call on Template draft

Hello,

Thank you,
Kathleen (as WG chair)

-----Original Message-----
From: Brian Trammell [mailto:[email-masked]] 
Sent: Wednesday, February 01, 2012 5:41 AM
To: Moriarty, Kathleen
Cc: [email-masked]
Subject: next up: mile-template

Hi, Kathleen, all,

Brian Trammell (as author of mile-template)
_______________________________________________
mile mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/mile

---

From: "Takeshi Takahashi" <[email-masked]>
Date: Tue, 7 Feb 2012 19:44:35 +0900

Hello Brian,

The template was very useful for me to prepare an initial version of the SCI
draft. Thank you.

Let me post one comment on the document template, especially on its Appendix
A:

Though I do not have any strong opinion, I felt that the "5. Examples" could
be put in the appendix II since I think the examples are supplementary
information.
I mean, appendix I is for schema while appendix II is for example.
(RFC 5901 actually puts the examples in the appendix II.)

Thank you.
Take

> Sent: Tuesday, February 07, 2012 5:01 AM
> To: [email-masked]; [email-masked]
> Cc: [email-masked]
> Subject: Re: [mile] Working group last call on Template draft
> 
> Hello!
> 
> For those of you who have not reviewed/commented on a draft, this would
> be an easy one to get your feet wet.  Feedback could be on grammar,
whether
> the template is sufficient to provide enough information for developers
> using specifications for extensions following this specification, or any
> other nits or positive comments you have on the draft.
> 
> Thanks,
> Kathleen
> 
> We are starting a 2 week review period, the working group last call (WGLC)
> for draft-ietf-mile-template. Please review and comment to the MILE list
> on the template draft.
> 
> Now that the WG work on 6045-bis and 6046-bis is complete, and (almost)
> in accordance with the charter, I believe the present revision of
> draft-ietf-mile-template to be ready for WGLC.
>

---

From: Brian Trammell <[email-masked]>
Date: Tue, 7 Feb 2012 13:26:55 +0100

Hi, Take,

Thanks for your comment! 

You're right, the examples belong in an appendix. When the doc template moved down, I didn't think to move the element examples as well.

I'll make this change in an -01 after the last call.

Cheers, Brian (as author)

Sent from my iPhone

---

From: Brian Trammell <[email-masked]>
Date: Tue, 7 Feb 2012 14:29:02 +0100

Hi, Take, all,

Actually, on further consideration (and not on a bus), I think the best way to handle this would be to put _each_ of these in their own appendix, as follows:

   Appendix A.  Document Template . . . . . . . . . . . . . . . . . .  7
     A.1.  Introduction . . . . . . . . . . . . . . . . . . . . . . .  7
     A.2.  Terminology  . . . . . . . . . . . . . . . . . . . . . . .  7
     A.3.  Applicability  . . . . . . . . . . . . . . . . . . . . . .  8
     A.4.  Extension Definition . . . . . . . . . . . . . . . . . . .  8
       A.4.1.  IODEF Data Types . . . . . . . . . . . . . . . . . . .  9
     A.5.  Examples . . . . . . . . . . . . . . . . . . . . . . . . . 10
     A.6.  Security Considerations  . . . . . . . . . . . . . . . . . 10
     A.7.  IANA Considerations  . . . . . . . . . . . . . . . . . . . 10
     A.8.  Appendix: XML Schema Definition for Extension  . . . . . . 11
   Appendix B.  Example Enumerated Type Extension Definition:
                E.164 Address . . . . . . . . . . . . . . . . . . . . 11
   Appendix C.  Example Element Definition: Test  . . . . . . . . . . 11

Cheers,

Brian (as author)

---

From: "Takeshi Takahashi" <[email-masked]>
Date: Tue, 7 Feb 2012 23:28:23 +0900

Hi Brian,

That looks nice to me. I like the revision.

On the other hand, I actually wanted to say, "A.5. Examples", which
describes IODEF-Document examples, could be moved to Appendix (A.8 Appendiix
II).
So, the agenda could be as below, but I am also fine with the current one.

Appendix A.  Document Template . . . . . . . . . . . . . . . . . .  7
     A.1.  Introduction . . . . . . . . . . . . . . . . . . . . . . .  7
     A.2.  Terminology  . . . . . . . . . . . . . . . . . . . . . . .  7
     A.3.  Applicability  . . . . . . . . . . . . . . . . . . . . . .  8
     A.4.  Extension Definition . . . . . . . . . . . . . . . . . . .  8
       A.4.1.  IODEF Data Types . . . . . . . . . . . . . . . . . . .  9
     A.5.  Security Considerations  . . . . . . . . . . . . . . . . .xx
     A.6.  IANA Considerations  . . . . . . . . . . . . . . . . . . . xx
     A.7.  Appendix I: XML Schema Definition for Extension  . . . . . xx
     A.8.  Appendix II: Examples . . . . . . . . . . . . . . . . . . .xx
Appendix B.  Example Enumerated Type Extension Definition:
                E.164 Address . . . . . . . . . . . . . . . . . . . . 11
Appendix C.  Example Element Definition: Test  . . . . . . . . . . 11

I just thought this way could align with the structure of RFC 5901 (phishing
extension document), but I am also fine with the current one.

Thank you.
Take

> Sent: Tuesday, February 07, 2012 10:29 PM
> To: Takeshi Takahashi
> Cc: <[email-masked]>
> Actually, on further consideration (and not on a bus), I think the best
> way to handle this would be to put _each_ of these in their own appendix,
> as follows:
> 
> > You're right, the examples belong in an appendix. When the doc template
> moved down, I didn't think to move the element examples as well.
> >
> >> The template was very useful for me to prepare an initial version of
> >> the SCI draft. Thank you.
> >>
> >> Though I do not have any strong opinion, I felt that the "5.
> >> Examples" could be put in the appendix II since I think the examples
> >> are supplementary information.
> >>> From: [email-masked] [mailto:[email-masked]] On
> Behalf
> >>> Of [email-masked]
> >>> For those of you who have not reviewed/commented on a draft, this
> >>> would be an easy one to get your feet wet.  Feedback could be on
> >>> grammar,
> >> whether
> >>> the template is sufficient to provide enough information for
> >>> developers using specifications for extensions following this
> >>> specification, or any other nits or positive comments you have on
> the draft.
> >>>
> >>> Thanks,
> >>> Kathleen
> >>>
> >>> From: [email-masked] [mailto:[email-masked]] On
> Behalf
> >>> Of [email-masked]
> >>> We are starting a 2 week review period, the working group last call
> >>> (WGLC) for draft-ietf-mile-template. Please review and comment to
> >>> the MILE list on the template draft.
> >>>
> >>> Now that the WG work on 6045-bis and 6046-bis is complete, and
> >>> (almost) in accordance with the charter, I believe the present
> >>> revision of draft-ietf-mile-template to be ready for WGLC.
> >>>

---

From: Brian Trammell <[email-masked]>
Date: Tue, 7 Feb 2012 15:36:28 +0100

Hi, Take,

Ahhh... okay, I understand now, and, yes, that makes sense, too. I'll do that as well.

Cheers,

Brian

---

From: <[email-masked]>
Date: Fri, 10 Feb 2012 15:03:30 -0500

Brian,

I have a few WGLC comments, but I should begin by saying that I do like the result of combining the formerly separate template and iodef-xmlreg drafts.  In addition, the new guidance material that was added (sections 2 and 3) looks good.  Nice work!

(1) Process nit: It may be necessary for this draft to be both a standards track document and a BCP document in order for the registry update to respect previously defined process.  Rather than discuss this subtlety further here, I suggest leaving that as a question for the Area Director to consider during his review (Hi Sean).

(2) Security Considerations.  Section 4 should say that the security considerations for IODEF continue to apply to extensions and cite [RFC5070].  Section A.6 should advise that IODEF extension specifications do likewise.

(3) IANA Considerations for extensions.  I suggest adding a sentence or two to Section A.7 to observe that an IODEF extension may define a new registry (or even registries) if that's appropriate, e.g., as the SCI draft is already doing.  I would not cite the SCI draft as part of this, as such a reference should be informative (not normative) and so won't be particularly useful if the template draft is published as an RFC fairly quickly - the RFC Editor replaces filenames in informative references to Internet-Drafts with "Work in Progress."

Thanks,
--David
----------------------------------------------------
David L. Black, Distinguished Engineer
EMC Corporation, 176 South St., Hopkinton, MA  01748
+1 (508) 293-7953             FAX: +1 (508) 293-7786
[email-masked]        Mobile: +1 (978) 394-7754
----------------------------------------------------

---

From: Brian Trammell <[email-masked]>
Date: Mon, 13 Feb 2012 12:34:56 +0100

Hi, David,

Thanks for your review and comments; have applied (2) and (3) to the -01 working copy, and will await Sean's feedback on (1)...

Cheers,

Brian (as mile-template author)

---

From: <[email-masked]>
Date: Mon, 13 Feb 2012 15:41:44 -0600

In Section 3, when discussing extension types for enumerated lists, I think it might be useful to specifically reference section 5.1 of RFC 5070 as well. 

Under the "Example Enumerated Type Extension Definition," for the example given, "content format" applies in the context of Address@category, but it wouldn't work everywhere. For other extensible enumerated lists, such as those under Impact@type, the meaning of the ext-value might better be described by the term "value meaning" which should be generic enough to cover all the expectation-setting the various extensible lists can cover.

Thank you,

 - Tom Millar, US-CERT

[email-masked]
BB: [email-masked] / 202-631-1915
24x7: [email-masked] / 888-282-0870 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: Wednesday, February 01, 2012 07:34
To: [email-masked]
Cc: [email-masked]
Subject: [mile] Working group last call on Template draft

Hello,

Thank you,
Kathleen (as WG chair)

-----Original Message-----
From: Brian Trammell [mailto:[email-masked]]
Sent: Wednesday, February 01, 2012 5:41 AM
To: Moriarty, Kathleen
Cc: [email-masked]
Subject: next up: mile-template

Hi, Kathleen, all,

Brian Trammell (as author of mile-template) _______________________________________________
mile mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/mile

---

From: Brian Trammell <[email-masked]>
Date: Tue, 14 Feb 2012 09:20:40 +0100

Hi, Tom,

Thanks for the comments. Will incorporate in the -01 working copy (to be submitted after the end of the WGLC, tomorrow). 

With respect to the meaning of the ext-value, I think we need to explicitly address that this should describe semantics as well as representation; so how about "value meaning and encoding"?

Best regards,

Brian (author hat)

---

From: <[email-masked]>
Date: Tue, 14 Feb 2012 11:34:12 -0600

Does "encoding" mean more than we think it means? Maybe "Value meaning and format"

 - Tom Millar, US-CERT

-----Original Message-----
From: Brian Trammell [mailto:[email-masked]] 
Sent: Tuesday, February 14, 2012 03:21
To: Millar, Thomas R
Cc: [email-masked]; [email-masked]
Subject: Re: [mile] Working group last call on Template draft

Hi, Tom,

Best regards,

Brian (author hat)

---

From: Brian Trammell <[email-masked]>
Date: Tue, 14 Feb 2012 19:36:50 +0100

Hi, Thomas,

Point. Value meaning and format it is.

Cheers,

Brian (author hat)