Re: [Nea] AD review of draft-ietf-nea-pt-tls-04

[Paul Sangster <[e-mail]>]

I'll work to get out an revision ASAP.  Just a final comment on the thread below...

> -----Original Message-----
> From: Stephen Farrell [mailto:[e-mail]]
> Sent: Tuesday, May 29, 2012 3:24 AM
> To: [e-mail]
> Cc: Paul Sangster
> Subject: Re: [Nea] AD review of draft-ietf-nea-pt-tls-04
> 
>
 
<snip>

> >>
> >>>
> >>>>>
> >>>>> (13) section 6.1: you're asking IANA to act as a repository
> >>>>> for non-RFC specifications (sort-of), I think that's maybe
> >>>>> an innovation (not sure) that should be checked out with
> >>>>> IANA, or maybe you've done that or know of a precedent?
> >>>>
> >>>> [PS:] The IANA would just reference the permanent and readily
> >>> available specification in the repository even if it's not an IETF
> >>> document. I believe this was done in other NEA RFCs.
> >>>
> >>> This is the text I meant:
> >>>
> >>>   "However, in this latter
> >>>    case, the vendor MUST supply a copy to the IANA and authorize
> >>>    the IANA to archive this copy and make it freely available to
> >>>    all if at some point the document becomes no longer freely
> >>>    available to all through other channels."
> >>>
> >>> That's more than referencing, isn't it? But yes, its in
> >>> RFC 5793 all right, so leave it as is.
> >>>
> >>>>> (14) 6.2 & 6.3 - do you need to tell IANA or the DE that
> >>>>> entries with PEN value 0 need to be IETF stream RFCs,
> >>>>> or standards-track RFCs, or just RFCs or what? If you
> >>>>> want the DE to be able to add PEN=0 entries without
> >>>>> an RFC, I think saying that would be best.
> >>>>
> >>>> [PS:] We are following the RFC 5226 policies of "Specification
> >>> Required" which says a
> >>>> "permanent and readily available" document must be defined.  This
> >>> doesn't need to be an RFC.  This was thoroughly discussed by the WG
> in
> >>> the past and agreed to for previous NEA RFCs.
> >>>
> >>> But earlier (3.5) it said:
> >>>
> >>>       If the PT-TLS Message Type Vendor ID field has the value zero
> >>>       (0), then the PT-TLS Message Type field contains an IETF
> Standard
> >>>       PT-TLS Message Type, as listed in the IANA registry.
> >>>
> >>> "IETF standard" != "specification required" so the question stands.
> >>> (Could be that previous NEA RFCs contain this ambiguity, if it is
> >>> one. That would not mean we shouldn't fix it here.)
> >>
> >> [PS:] Good point, maybe that should say "IETF namespace" instead of
> "IETF standard".
> >
> > Well, I guess its just a matter of getting whatever is
> > the intent written down precisely, which can sometimes
> > show up some ambiguity in the intent:-)

[PS:] PA-TNC RFC did a little more complete job of explaining the namespace intentions.  Please take a look at RFC 5792 sections 2.1 and 2.2 and let us know whether you think those should be referenced (or duplicated in) PT-TLS.  The approach we're discussing is used by both PA-TNC and PB-TNC.

> >
> > The question here is does the specification required rule
> > apply to the addition of new entries with PEN=0? If yes,
> > then that's not an IETF namespace either since TCG or
> > whoever could do that. If no, then what rule does apply?
> >

[PS:] "For all of the IANA registries defined by this specification, new values are added to the registry by Expert Review with Specification Required, using the Designated Expert process defined in RFC 5226 [RFC5226]."  

If it helps we can stop referring the PT-TLS PEN=0 namespace as "IETF standard" and just informally call it the IETF's namespace since values using this namespace will at least have been expert reviewed in the IETF.

> 

<Snip>

> >>>
> >>>> Thanks,
> >>>> Paul
> >>>>
> >>
> >>
> > _______________________________________________
> > Nea mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/nea
> >
> >