Subject: [mile] Barry Leiba's No Objection on draft-ietf-mile-enum-reference-format-12: (with COMMENT)

From: "Barry Leiba" <[email-masked]>
Date: Sun, 04 Jan 2015 08:25:32 -0800

Barry Leiba has entered the following ballot position for
draft-ietf-mile-enum-reference-format-12: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
http://datatracker.ietf.org/doc/draft-ietf-mile-enum-reference-format/

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

None of these comments are highly important, and none are meant to block
the document.  Please consider these and discuss them with me if you
think it's appropriate... but I'll leave it to the
authors/shepherd/working group/AD to decide whether to make any changes. 
Thanks.

I'm not happy with the 2119 "SHOULD"s in the Security Considerations. 
None of them appear to be protocol-related: they're all sound advice, and
such advice should definitely be given, but it would fit better with both
2119 and reasonable understanding if these were just put in terms of sage
advice with reasons and consequences given (which you are giving;
thanks).

In particular, "producers ... SHOULD be careful to ensure ..." is
certainly not in compliance with 2119; I'd say "It is very important that
producers of IODEF [IODEF] content ensure a proper mapping...."

I'm not sure what "SHOULD be preferred" even means, so I think fixing
this one is important.  If what you mean is that if <some entity> is
receiving enumeration reference IDs and has a choice between a trusted
source and an untrusted one, it should use the trusted source, then
please say it that way, and don't use passive voice.

Similarly, "trust SHOULD extend from... to...": this would be far better
if we got rid of the passive voice and said that it's highly recommended
that <entity> use third parties for which there is a trust relationship
<that meets these criteria>.

In the IANA Considerations...

I note that you have ABNF grammar to define "abbreviation", and presume
that grammar is for the designated expert's use, and not really aimed at
IANA.  That's fine (just see below).

         Version: The version of the enumeration (i.e. the referenced
         specification) as a free-form string from the printable ASCII
         character set excepting white space. 

It might be good, I think, to have ABNF here as well, also for the
designated expert... lest some DE in the future wonder which characters
are part of "the printable ASCII character set" and which are "white
space".

Thank you for giving good instructions to the DE; that's important.

I would lost the "MUST", and just say that the designated expert will
review any specification that is associated with the request.  Again,
this isn't a protocol interop issue, which is what 2119 language is
generally for.

---

From: Kathleen Moriarty <[email-masked]>
Date: Mon, 5 Jan 2015 09:22:54 -0500

Hi,

Two points...

Sent from my iPhone

> On Jan 5, 2015, at 9:13 AM, "Black, David" <[email-masked]> wrote:
> 
> Barry,
> 
> [-mile list]
Adding mile back.  This is the new default for IESG reviews to increase transparency further.

> 
> Many thanks for the careful review.
> 
> Sure, we can fix those (and get rid of the "MUST" in the instructions to
> the Designated Expert) - the rewording suggestions are appreciated.
> 
> Meanwhile, IANA's not yet OK with this draft, for reasons that appear to be
> beyond our control.  On Dec 30, Pearl wrote:
> 
>> The authors have answered our questions, but we need a review of the new IODEF
>> schema (this request has been sent to the expert) and the new ns registration
>> request (this registry doesn't have an expert; the expert designation for
>> RFC 3688 is in process).
>> 
>> I believe that Kathleen Moriarty (DE) has reviewed and approved the requested IODEF 
>> schema registration.
> 
> although the above IANA comments don't seem to have made it into the datatracker.
> 
> The IESG agenda indicates that you're the (lucky) owner of the action item to
> find an expert for that RFC 3688 registry - could you give us some idea of
> what's likely to happen when on that? 

I am the DE and IANA did reach out to me.  I took some vacation time with knowledge of the schedule for the draft and will review the schema prior to Thursday.  I may assign additional experts as well (as the Responsible AD) for IODEF schemas, which are separate experts than the RFC3688 ones as set forth in RFC5070.

Thanks,
Kathleen

> 
> Thanks,
> --David
> 
>> -----Original Message-----
>> From: mile [mailto:[email-masked]] On Behalf Of Barry Leiba
>> Sent: Sunday, January 04, 2015 11:26 AM
>> To: The IESG
>> Cc: [email-masked]; [email-masked]; draft-ietf-mile-enum-reference-
>> [email-masked]
>> Subject: [mile] Barry Leiba's No Objection on draft-ietf-mile-enum-reference-
>> format-12: (with COMMENT)
>> 
>> _______________________________________________
>> mile mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/mile
>

---

From: Kathleen Moriarty <[email-masked]>
Date: Mon, 5 Jan 2015 10:24:37 -0500

Barry,

> I am the DE and IANA did reach out to me.  I took some vacation time with knowledge of the schedule for the draft and will review the schema prior to Thursday.  I may assign additional experts as w…

It looks like the IANA Section added a URL of its own instead of using
the IODEF one that already exists and then didn't specify that the
IODEF expert would be used for this schema.  For other IODEF related
schemas, the URL was added within the set for IODEF, hence the IODEF
DE is used.  The way this is written now, the draft is asking for 2
XML schema reviews that will do pretty much the same thing (really
doesn't make sense), unless I am missing something (I don't think I
am).

In the XML registry we have:

IETF XML Registry
nsRFC 3688
Specification Required (Expert: Graham Klyne, Julian Reschke)
publicidRFC 3688
Specification Required (Expert: Graham Klyne, Julian Reschke)
rdfschema
Specification Required (Expert: Graham Klyne, Julian Reschke)
schemaRFC 3688, RFC 6685
Specification Required (Expert: Jari Urpalainen for non-IODEF schemas,
Kathleen Moriarty for IODEF schemas)

For a recently published IODEF related schema, the IANA section about
the URL puts it with IODEF (RFC7203):

This memo creates the following registry, which is managed by IANA:

      Name of the registry: "Structured Cybersecurity Information (SCI)
      Specifications"

      Name of its parent registry: "Incident Object Description Exchange
      Format (IODEF)"

      URL of the registry: <http://www.iana.org/assignments/iodef>

This one puts it out on it's own, but registers the namespace within
the IODEF set:

This memo creates the following registry for IANA to manage:

      Name of the Registry: "Security External Enumeration Registry"

      Location of Registry: https://www.iana.org/assignments/sec-ext-
      enum

There are good reasons to have this outside of IODEF as it may get
used in that way, but I don't think we need identical reviews
happening twice.  Would adding mention that this registry is reviewed
by the DE assigned for IODEF schemas suffice and get rid of that
problem?

I just wanted to make sure I'm not missing something and that worked
for you, Barry.

Thanks,
Kathleen

-- 

Best regards,
Kathleen

---

From: "Black, David" <[email-masked]>
Date: Mon, 5 Jan 2015 19:14:43 +0000

Sorry for chiming in, but I'm somewhat confused.

What I think I understand is:

a) IANA has expressed concern about this XML namespace registration request:

   Registration request for the IODEF enumeration reference format
   namespace:

   URI  : urn:ietf:params:xml:ns:iodef-enum-1.0

b) Kathleen is the designated IODEF expert reviewer for this related XML
schema registration request:

   Registration request for the IODEF enumeration reference format XML
   schema:

   URI  : urn:ietf:params:xml:schema:iodef-enum-1.0

If I understand Kathleen's concern, it's that one person should really
review both of the above IODEF-related registration requests together ...
which sounds like an eminently reasonable approach.

If I understand IANA's concern, that combined review doesn't happen right
now because only the XML schema registry has split reviewer responsibility
into IODEF (Kathleen) and non-IODEF (other reviewers) portions.

If so, then splitting XML namespace registry reviewer responsibility so that
one person can do both IODEF-related reviews seems like an obviously good
idea, especially as there's at least one more draft coming from the mile
WG with a similar pair of IODEF-related XML namespace and XML schema
registration requests (the 5070bis draft).

Do I understand the situation correctly?

Enjoy,
--David

> From: Kathleen Moriarty [mailto:[email-masked]]
> Sent: Monday, January 05, 2015 10:25 AM
> To: Black, David
> Cc: Barry Leiba; The IESG; [email-masked]; draft-ietf-mile-enum-
> [email-masked]; [email-masked]
> Subject: Re: [mile] Barry Leiba's No Objection on draft-ietf-mile-enum-
> reference-format-12: (with COMMENT)
> 
> Barry,
> 
> > I am the DE and IANA did reach out to me.  I took some vacation time with
> knowledge of the schedule for the draft and will review the schema prior to
> Thursday.  I may assign additional experts as well (as the Responsible AD) for
> IODEF schemas, which are separate experts than the RFC3688 ones as set forth
> in RFC5070.
>

---

From: Kathleen Moriarty <[email-masked]>
Date: Mon, 5 Jan 2015 14:56:13 -0500

Barry,

I think my previous message may be the best for you to respond to in
order to shorten the amount of time we put into this.

David,

I'll see where I can help your understanding in line.  I had the issue
in my previous message.

>>       Location of Registry: https://www.iana.org/assignments/sec-ext-

This URL is not listed as part of the IODEF assignments and the other
MILE schemas are part of it as you can see from the SCI registration.
This is where this draft breaks out of IODEF and may be why IANA would
like an RFC3688 reviewer as well.

My question to Barry was to check if you and the other editors could
specify that this is IODEF related schema URL registration (even
though it can be used with other schemas - so can RID, so this is not
unique to this iodef-related schema) can be checked by the IODEF
schema DE.

Regards,
Kathleen

-- 

Best regards,
Kathleen

---

From: Kathleen Moriarty <[email-masked]>
Date: Mon, 5 Jan 2015 15:04:44 -0500

I just noticed one other issue that may be causing the problem, for
the namespace, the draft only specifies RFC3688 and not the draft
specific to iodef namespaces: RFC 6685 which is in the table of my
previous message from 10:24 this morning.  That says the DE for IODEF
reviews schemas registered in that space.  It doesn't preclude the
need for an RFC3688 reviewer, but I don't think we need too many
people doing the same thing, but it's Barry's call.

-- 

Best regards,
Kathleen

---

From: "Black, David" <[email-masked]>
Date: Mon, 5 Jan 2015 20:18:44 +0000

Kathleen,

> reviews schemas registered in that space.  

Thank you for finding that; we're making progress, but IANA was clear
that the cause of the "Not OK" IANA status is the *namespace* registration,
which is separate and different from the *schema* registration.

RFC 6685 covers only IODEF XML schema registrations; that's under control
here because IANA has already asked the IODEF designated expert (that would
be you) to review the schema registration, even though we didn't reference
RFC 6685 in the enumeration reference draft.

OTOH, RFC 6685 has nothing to say about IODEF XML namespace registrations.
In 20/20 hindsight, perhaps RFC 6685 should have covered both schema and
namespace registrations, but it didn't, so IANA is following instructions
and looking for an RFC 3688 reviewer for the namespace registration.

I hope that the two of us are in semi-violent agreement that two different
reviewers for IODEF XML schema and namespace registrations in the same draft
makes little sense.

Let's see if Barry concurs and what he might suggest as a course of action.

Thanks,
--David

> Sent: Monday, January 05, 2015 3:05 PM
> To: Black, David
> >>> >>> The authors have answered our questions, but we need a review of the
> new
> >>> IODEF
> >>> >> The IESG agenda indicates that you're the (lucky) owner of the action
> item
> >>> to

---

From: Kathleen Moriarty <[email-masked]>
Date: Mon, 5 Jan 2015 15:26:25 -0500

> which is separate and different from the *schema* registration.

Yes, that's clear.  But you don't have the RFC6685 reference, which
may help resolve this.

> and looking for an RFC 3688 reviewer for the namespace registration.

My other point earlier is that a separate URL assignment was also
requested, which makes this different from all of the other MILE
registrations with IANA, which used an existing iodef registration
(and all the namespaces were within the iodef namespace).  This is why
I asked Barry if a note would help or if he sees a need for multiple
experts to do essentially the same checks.

-- 

Best regards,
Kathleen